1 / 22

Recommending Adaptive Changes for Framework Evolution

Recommending Adaptive Changes for Framework Evolution. Barthélémy Dagenais and Martin P. Robillard ICSE08. Dec 4 th , 2008 Presented by EJ Park. Framework Evolution. From simple refactoring to complete rearchitecture 80% of API-breaking is from refactoring

stew
Download Presentation

Recommending Adaptive Changes for Framework Evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Recommending Adaptive Changes for Framework Evolution Barthélémy Dagenais and Martin P. Robillard ICSE08 Dec 4th, 2008 Presented by EJ Park

  2. Framework Evolution • From simple refactoring to complete rearchitecture • 80% of API-breaking is from refactoring • Adapting a client program is required Framework New Version of Framework Client Program

  3. State-of-the-Art • Techniques for Framework Adaptive Changes • Automatic capturing and documenting changes • Providing migration paths • Deprecating existing methods and indicating new replacements • Limitation • Good for only refactoring • Refactoring only involves name and location change dimensions • Not always cost effective • Not good for internal and undocumented parts of framework • Hard for Non-trivial changes

  4. Contributions • A techniques for adaptive changes recommendation • The architecture of a complete system to track a framework’s evolution and infer non-trivial changes • An historical study on the redesign of a framework component in Eclipse

  5. Sample Scenario SemDiff: Implementation of their approach Project Eclipse 3.2 org.eclipse.jdt.internal.corext.util.TypeInfo (in org.eclipse.jdt.ui) Eclipse 3.3 Cannot Find TypeInfo anymore! ?? 3. Any other classes depend on TypeInfo class and now referring other package name? What should I do now? 1. Any class with the similar name? No 2. Any missing class in the same package but under a different name? No Yes but not proper replacement.

  6. SemDiff: Overview • Client-server application for Java • Server component for inferring high-level changes • Client component for producing recommendations Server Component Client Component

  7. Client Component: Adaptive Change Recommendation Compute the Confidence Value Using Call Differences Recommendations Remove Improper Recommendations Change Chains Caller Stability Spurious Call Removal Recommendations Show Recommendations

  8. Adaptive Change Recommendations:Computing the Confidence Value • Using Call Differences • Differences in outgoing calls for a given method during a framework’s history • Definition of Confidence Value • Example of Definitions • Output: Recommendations • Methods deprecated but still accessed by a subset of the framework • Methods replaced before being deleted

  9. Adaptive Change Recommendations:Removing Improper Recommendations • Change Chains • Caller Stability • Spurious Call Removal

  10. Adaptive Change Recommendations:Showing Recommendation • Ranked by the confidence value • Double click on a recommendation • User can understand better how each recommendation come out and how the framework was adapted to this change.

  11. Adaptive Change Recommendations:Complexity and Limitation • Factors for Computational Complexity • The number of methods that removed a call to the queried method • The number of different added calls • The maximum change chain length, • The maximum length of unstable callers • Limitation • Not working for root method • No grouping of recommendations • No guarantee of semantic equivalence

  12. Server Component:Analyzing Source Code History • Retrieving the files and change data for each version of the framework • Running several analyses to infer high-level changes such as structural and method call differences • Storing those high-level changes in a database for future use by recommendation system Server Component

  13. Analyzing Source Code History: Source Repositories • Repository Adapters retrieve information from CVS and SVN • SVN vs. CVS • SVN has the concept of change set • CVS does not group file changes and some processing of the repository log file is needed to infer change sets. • Detection of branches merge • Important to avoid analyzing the same change twice by detecting redundant changes

  14. Analyzing Source Code History: Change Analysis • For each change set, • StructDiff: a list of all methods that were added, removed and modified • CallDiff: the calls that were added or removed between two versions of each method identified by StructDiff

  15. Analyzing Source Code History: Partial Program Analysis • Incomplete type hierarchy • Subset of the program source code without the dependencies and the rest of the program • Three matching criteria for methods • The same name, # of parameters, type of parameters and target type. • The same name, # of parameters and type of parameters. • The same name and # of parameters • Enable the analysis of partial program • Soot Java static analysis framework • Java source parser, Polyglot

  16. Evaluation Questions • Can SemDiff recommend adaptive changes during framework’s evolution? • Is the confidence value for SemDiff good enough and free from false positives? • Can SemDiff detect changes better than refactorings?

  17. Historical Study Design • One Framework: Eclipse Java Development Tool Platform • org.eclipse.jdt.core and org.eclipse.jdt.ui from version 3.1 and 3.3 • Three client programs • Mylyn • Jboss IDE, • Jdt.debug.ui • SemDiff vs. RefactoringCrawler

  18. Evaluation Results • SemDiff performed better than RC • Relevant Recommendations: 89% • Confidence Value: 7.1 recommendations per request • Non-trivial Changes • 6% Change Chains and Caller Replacements, 67% Spurious Calls

  19. Summary of Evaluation • Can SemDiff recommend adaptive changes during framework’s evolution? • Yes • Is the confidence value for SemDiff good enough and free from false positives? • Yes • Can SemDiff detect changes better than refactorings? • Yes

  20. Threats to Validity • Only for Eclipse JDT • Multiple factors can affect their approach • Mitigated by confidence value • No assessment how the developers would have used their recommendations • Subject choice of client programs in experiments.

  21. Conclusion • Contributions • A techniques for adaptive changes recommendation • The architecture of a complete system to track a framework’s evolution and infer non-trivial changes • An historical study on the redesign of a framework component in Eclipse • Better performed than Refactoring • Better adaptive changes recommendation • Successfully locate methods from external libraries

  22. Future Work & Discussion • Improvement in adaptive change recommendations • Not working for root method • No grouping of recommendations • No guarantee of semantic equivalence • Extend experiments to the other frameworks

More Related