AURA: A Hybrid Approach to Identify

Transcription

1 : A Hybrid to Identify Wei Wu 1, Yann-Gaël Guéhéneuc 1, Giuliano Antoniol 2, and Miryung Kim 3 1 Ptidej Team, DGIGL, École Polytechnique de Montréal, Canada 2 SOCCER Lab, DGIGL, École Polytechnique de Montréal, Canada 3 ECED, The University of Texas at Austin, USA wuwei@iro.umontreal.ca, yann-gael.gueheneuc@polymtl.ca, antoniol@ieee.org, miryung@ece.utexas.edu

2 2 / 30 Compilation Error final Graphics2D g2 =...; final Rectangle2D dataarea =...; final CategoryPlot plot =...; final ChartRenderingInfo info =...;... final AbstractCategoryItemRenderer renderer = new BarRenderer().initialise(g2, dataarea, plot, info);... Typical Questions The developer would wonder: did the method signature change? if not, how should she now initialize a renderer: one equivalent method? many new methods? just not the way anymore?

3 3 / 30

4 4 / 30 (1/4) JHotDraw package CH.ifa.draw.application; public class DrawApplication... { protected JMenu createeditmenu() {... Version 5.2: menu.add(new CutCommand("Cut", view()), Version 5.2: new MenuShortcut( x )); Version 5.3: menu.add(new UndoableCommand( Version 5.3: new CutCommand("Cut", this)), Version 5.3: new MenuShortcut( x ));... (1) CutCommand.CutCommand(DrawingView...) CutCommand.CutCommand(Alignment, DrawingEditor) and UndoableCommand.UndoableCommand(Command)

5 5 / 30 (2/4) JEdit package org.gjt.sp.jedit; public class GUIUtilities { public static JMenu loadmenu(...) { Version 4.1: DirectoryMenu.DirectoryMenu(...); Version 4.1: MarkersMenu.MarkersMenu(); Version 4.1: RecentDirectoriesMenu.RecentDirectoriesMenu( Version 4.2: EnhancedMenu.EnhancedMenu(...);... (1) DirectoryMenu.DirectoryMenu(...) and MarkersMenu.MarkersMenu() and RecentDirectoriesMenu.RecentDirectoriesMenu( EnhancedMenu.EnhancedMenu(...)

6 6 / 30 (3/4) JFreeChart package org.jfree.data; public class DefaultBoxAndWhiskerDataset { Version : public static... createnumberarray(...) { Version :... Version : } Version :... Version :... (1) DefaultBoxAndWhiskerDataset.createNumberArray(

7 7 / 30 (4/4) Eclipse public ReplaceEdit[] getmodifications(string source) {... Version 3.1: return Indents.getChangeIndentEdits(...); Version 3.3: return IndentManipulation.getChangeIndentEdits( } Version 3.1: class Indents { Version 3.3: class IndentManipulation { void getchangeindentedits(...) {... Version 3.1: int length= Indents.computeIndentLength(...); Version 3.3: int length= this.indexofindent(...);... (1) Indents.getChangeIndentEdits(...) IndentManipulation.getChangeIndentEdits(...) (2) Indents.computeIndentLength(...) IndentManipulation.indexOfIndent(...)

8 8 / 30 Main We want an approach that offers: one-to-many replacements (JHotDraw); many-to-one replacements (JEdit); simply-deleted methods (JFreeChart); cascade replacements (Eclipse). Additional We also want an approach that is: automatic and does not require framework developers involvement (FDI); system/contex independent no thresholds.

9 9 / 30 Features es One-to- Many- Simply- No Fully No many to-one deleted FDI Auto- Thres- Rules Rules Rules matic holds Chow et al. [1] SemDiff [2] Godfrey et al. [3] CatchUp! [4] M. Kim et al. [5] S. Kim et al. [6] Schäfer et al. [8] Diff-CatchUp [9]

10 10 / 30 (1/4) Inspiration uses: Call dependency, as in previous work by: Dagenais and Robillard [2]; Godfrey et al. [3]; Schäfer et al. [8]; Text similarity, as in previous work by: M. Kim et al. [5]; S. Kim et al. [6]; Xing and Stroulia [9].

11 11 / 30 (2/4) Assumptions We only consider method(s) in the same framework, excluding other vendors frameworks. We only use the old and new releases of a framework, not any of its client programs. A target method t can be replaced by: no method if it has been simply-deleted; one or more candidate methods, set {c}; A rule is a conjunction of method replacements, while M. Kim et al. s change-rules [5] are groups of similar changes.

12 12 / 30 (3/4) Underlying Techniques We use transitive call dependency analyses: let A be the number of anchors, i.e., methods calling target methods, then the confidence value is: CV(t, c) = A(t, c)/a(t); let KR(t) be the key-replacement method of t, i.e., the method that is most similar to t from the candidate replacement methods whose names are equal to t s or with CV(t, c) = 100%, then the support value is: S(t, c) = { m m {all the methods in the new release} m KR(t) m c }.

13 13 / 30 (4/4) Underlying Techniques We use Lawrie et al. s technique [7] to tokenize and compare method signatures: most of return types, declaring classes, method names, and parameter lists; Levenshtein distance; longest common subsequence (LCS)

14 14 / 30 (1/2) Steps Our algorithm divide in 6 steps (see pages ): 1. Global Data Set Generation: generates target method set, anchor set and candidate replacement method set. 2. Target Methods Classification: divides methods into those called by an anchor from the others. 3. Candidate Replacement Method Set Generation: uses call dependency to build sets. 4. Confidence Value Computation: build one-to-one, many-to-one, and one-to-many rules. 5. Text Similarity Only Rule Generation: uses text similarity for methods not called by anchors. 6. Simply-deleted Method Rule Identification: builds list of deleted methods.

15 15 / 30 (2/2) Implementation is implemented in Java, as an Eclipse plug-in, available at experiments/icse10b.

16 16 / 30 Hypothesis will find more relevant change rules than the previous approaches with comparable precision, i.e., it will have a better recall than and similar precision to those of the previous approaches.

17 17 / 30 (1/2) Precision and Recall Precision = {relevant rules} {retrieved rules} {retrieved rules} Recall = {relevant rules} {retrieved rules} {relevant rules} Problem We cannot know {relevant rules} without an expensive and error-prone manual analysis.

18 18 / 30 (2/2) Δs of Precision (P) and Recall (R) We introduce the manually-build set: {correct rules} X = {relevant rules} X {retrieved rules}x Then: ΔP(A, B) = Precision A Precision B Precision B = {correct rules} A {retrieved rules} B {retrieved rules} A {correct rules} B 1 ΔR(A, B) = Recall A Recall B Recall B = {correct rules} A {correct rules} B {correct rules} B

19 19 / 30 (1/6) Considered Rules We noticed that large numbers of target methods are deleted in new releases: on average 31.93% of rules are simple-deleted rules we include simply-deleted rules. We convert many-to-one rules into as many one-to-one rules.

20 20 / 30 (2/6) Subject Systems We reuse systems analysed in previous work to benefit from the sets {correct rules} X built by their authors. Systems Releases # Methods JFreeChart , ,197 JHotDraw 5.2 1, ,265 JEdit 4.1 2, ,547 Struts 1.1 5, ,111 org.eclipse.jdt.core ,439 org.eclipse.jdt.ui ,237

21 21 / 30 (3/6) Small/Medium Systems We benefit from existing sets {correct rules} X and compare precision, recall, and deltas. Systems M. Kim et al. [5] ΔR ΔP JHotDraw # Correct rule Precision 92.38% 99.00% 19.49% -6.69% JEdit # Correct rule Precision 80.18% 93.00% 64.29% % JFreeChart # Correct rule Precision 80.73% 78.00% 75.86% 3.50% Systems Schäfer et al. [8] ΔR ΔP JHotDraw # Correct rule Precision 92.38% 88.00% 10.23% 4.98% Struts # Correct rule Precision 96.56% 85.70% 95.49% 11.50% Total Precision of 88.25% Average ΔR 53.07% ΔP -0.10%

22 22 / 30 (4/6) Large System {retrieved rules} > 4, 500 we use the number of errors in scope, i.e., the number of compilation errors related to method and type replacements: to build {correct rules} ; to reuse {correct rules} SemDiff. Systems SemDiff [2] org.eclipse. # Errors in Scope 4 jdt.debug.ui # Found Rules # Correct Rules 4 4 Mylyn # Errors in Scope # Found Rules 2 2 # Correct Rules 1 2 JBossIDE # Errors in Scope # Found Rules 8 8 # Correct Rules 8 8 Precision 92.86% %

23 23 / 30 (5/6) Threats to Validity The following threats affect our comparisons: construct validity: errors in the algorithm and bias in the manual validation of rules implementation and data available on-line; internal validity: confounding factors that could affect the results of the study exploratory study and systematic comparison of with the previous approaches.

24 24 / 30 (6/6) Threats to Validity The following threats also affect our comparisons: conclusion validity: relation between the treatment and the outcome of the study unbiased measures and data provided by the authors of previous approaches; reliability validity: possibility of replicating the study details in the paper and studied systems and data available on-line; external validity: possibility to generalize our the results of the study five systems of different size, domains, and evaluated by previous approaches.

25 25 / 30 (1/4) Strengths has the following advantages over previous work: combination of call-dependency and text-similarity analyses; multi-iteration algorithm; three text similarity measures; many-to-one, one-to-many, simply-deleted rules; no threshold.

26 26 / 30 (2/4) Limitations Still, has the following limitations: it cannot detect one-to-many and many-to-one change rules for target methods called by no other method; it only generates change rules for methods. it assumes no major changes to the internal implementation of anchors.

27 27 / 30 (3/4) Future Work Consequently, future work includes to: analyze systems in other programming languages; develop heuristics that generate change rules for types and fields using inheritance relations and polymorphism; combine with approaches that use other matching techniques; present results in first-order relational logic rules, as introduced by M. Kim et al. [5]; perform usability studies of the efficacy of.

28 28 / 30 (4/4) Any questions, comments?

29 29 / 30 (1/2) K. Chow and D. Notkin. Semi-automatic update of applications in response to library changes. In ICSM 96: Proceedings of the 1996 International Conference on Software Maintenance, page 359, Washington, DC, USA, IEEE Computer Society. B. Dagenais and M. P. Robillard. Recommending adaptive changes for framework evolution. In ICSE 08: Proceedings of the 30th international conference on Software engineering, pages , New York, NY, USA, ACM. M. W. Godfrey and L. Zou. Using origin analysis to detect merging and splitting of source code entities. IEEE Trans. Softw. Eng., 31(2): , J. Henkel and A. Diwan. Catchup!: capturing and replaying refactorings to support api evolution. In ICSE 05: Proceedings of the 27th international conference on Software engineering, pages , New York, NY, USA, ACM. M. Kim, D. Notkin, and D. Grossman. Automatic inference of structural changes for matching across program versions. In ICSE 07: Proceedings of the 29th international conference on Software Engineering, pages , Washington, DC, USA, Not Available IEEE Computer Society. S. Kim, K. Pan, and E. J. Whitehead, Jr. When functions change their names: Automatic detection of origin relationships. In WCRE 05: Proceedings of the 12th Working Conference on Reverse Engineering, pages , Washington, DC, USA, IEEE Computer Society.

30 30 / 30 (2/2) D. Lawrie, H. Feild, and D. Binkley. Syntactic identifier conciseness and consistency. In Sixth IEEE International Workshop on Source Code Analysis and Manipulation., pages , Sept T. Schäfer, J. Jonas, and M. Mezini. Mining framework usage changes from instantiation code. In ICSE 08: Proceedings of the 30th international conference on Software engineering, pages , New York, NY, USA, May ACM. Z. Xing and E. Stroulia. API-evolution support with diff-catchup. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 33(12): , December 2007.