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 Adapting a client program is required 2 Framework Client Program New Version of Framework

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 3

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 4

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

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

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

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 8

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

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. 10

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 11

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 12 Server Component

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 13

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 14

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 15

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? 16

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 17

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 18

Summary of Evaluation 19 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

Threats to Validity 20 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.

Conclusion 21 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

Future Work & Discussion 22 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