The document discusses improving change history-based recommendations for software by accounting for transformations between versions. It proposes an Extended Change History-Based (ECHB) approach that detects transformations using method similarity and uses the original entity's history for recommendations. An evaluation compares the ECHB approach to a baseline Change History-Based (CHB) approach using the Eclipse project, finding the ECHB approach works better at the method-level and provides valid recommendations in more cases involving potential transformations, though CHB maintains higher precision and recall for a given input.

1. Using Method Similarity over Versions to Improve Predictions based on Change History BhavyaRawal

2. The Eclipse Project Open source toolkit for designing toolkits 25 releases so far 419 packages 24 million LOC Over 380 committers 8 years of development Distributed team 2

3. Bug Fixing in Eclipse Bug #230 – Interface field correction doesn't offer to create the field 3

4. Learning from History Change history based recommender approaches exploit rich project history [Ying et al., Zimmerman et al., etc.] What is a recommendation? Programmers who changed Foo.java also changed… Example change pattern in Eclipse: {ASTResolving.java, NewMethodCompletionProposal.java} Both classes part of solution for Bug #230 4

5. Ying et al.’s CHB approach CVS Change Sets {Foo.java, Bar.java, build.xml, …} {Foo.java, …, build.xml…} {Foo.java, Bar.java, …} {Foo.java, Bar.java,} ……………………………….. ……… Frequent Pattern Mining Frequent Pattern: {Foo.java, Bar.java, build.xml} Changing Foo.java? Programmers who changed Foo.java also changed Bar.java and build.xml 5

6. Shortcomings of Ying et al.’s Approach CVS Change Sets {Foo.java, Bar.java, build.xml, …} {Foo.java, …, build.xml…} {Foo.java, Bar.java, …} {Foo.java, Bar.java,} ……………………………….. ……… Frequent Pattern Mining Frequent Pattern: {Foo.java, Bar.java, build.xml} Changing Foo1.java? Major Refactoring Foo.java Foo1.java Sorry! No recommendations for Foo1.java 6

8. Change in name/location results in loss of history

9. Transformedentities will not result in valid recommendationsA transformation is a set of operations performed on or using p software entities in a given version, resulting in q software entities in the successive version. 7

10. Proposed Solution Extending CHB Detect transformations Use original entity’s history for recomm. Compare CHB against Extended CHB (ECHB) We use Ying et al.’s approach as Baseline CHB Test CHB and ECHB for different granularities File-level Method-level 8

14. file-level9

15. Evaluation of the 6 Approaches Generate Frequent Patterns Select 20 modification tasks to test quality of approaches 10

16. Evaluation of the Approaches CHB, SB, ECHB evaluated on real tasks Technique Pick modification task and identify solution set For each entity in solution set Use entity as input to obtain recommendations Compare recommendations against solution set Repeat for other modification tasks 11

17. Measuring the quality of recommendations? R S All entities in a system Correct recommendations Evaluated the 3 approaches on Precision and Recalland Throughput Precision =|R ∩ S| / |R| Recall=|R∩ S| / |S| Throughput=|Inputs resulting in recomm.| |Total Inputs| Correctly returned recommendations Returned recommendations 12

19. Difficulties in recreating their work

20. Problems in finding solution set,

21. counting the number of recommendations

22. technique for finding average precision and recall 13

23. Results: CHB File-level v/s Method-level Higher precision for method-level CHB Higher recall for file-levelCHB Higher throughput for file-levelCHB 14

24. Extending CHB How do we detect Transformations? Transformed entities share facts with its parent entity. Method Facts: Name, Return Type, Parameters, Callers, Callees public ProgressStatusgetProgressUpdate (boolean complete, IProgressMonitor monitor) public ProgressStatusgetBriefProgressUpdate (IProgressMonitor monitor) 15 Version n-1 Version n

25. AB Extending CHB Transformed entities share facts with its parent entity. Method Facts: Name, Return Type, Parameters, Callers, Callees Caller A Transformed Callee B Version n Version n-1 16

26. DetectingTransformations over 2 Versions Two pass approach to detect transformations Eliminate unchanged methods Compare remaining methods Method-pair Similarity based on individual fact-similarity Name similarity, Caller Similarity etc. Individual fact similarity Param(m1): {int, Str} Param(m2): {int, Str, bool} Parameter Similarity = 2/3 = 0.67 Facts(m1) ∩ Facts(m2) Facts(m1) ∪ Facts(m2) 17

28. Detected similar methods form recomm.

29. File-level SB approach

30. Detect similar classes using method-pair similarity

31. Detected similar classes form recomm.

32. Experiments use versions 2.0 and 2.1 of Eclipse18

33. ECHB Approach 19

35. Best Match(BM) and Threshold(TH)

36. BM variation provides better results

37. ECHB approach works better for method-level20

38. ECHB Selected Results Method-level BM Variation Selected inputs based on transformation cond. Input exists in Version 2.1 but not in Version 2.0 ECHB versus CHB Results Throughput: 49% versus 14% Precision: 9% versus 47% Recall: 18% versus 13% 21

39. Summary CHB approaches do not take transformations into account Including transformations can provide better recomm. Recreated Ying et al.’s CHB approach For file-level and method-level granularity ECHB extends CHB by incorporating transformations 22

40. Takeaway Method-level ECHB approach provides valid recomm. in 35% more cases compared to CHB in the event of a potential transformation. However, for a given input CHB provides significantly higher precision rates and slightly higher recall rates compared to ECHB. 23