Recommending Adaptive Changes for Framework Evolution

Dagenais, Barthélémy; Robillard, Martin P.

doi:10.1145/2000799.2000805

Cited by 117 publications

(110 citation statements)

References 31 publications

Supporting

Mentioning

108

Contrasting

Order By: Relevance

“…Kim et al's (2007) compute LCS of the target methods and its replacement to measure the difference between them. SemDiff (Dagenais andRobillard 2011), Schäfer et al (2008), and AURA (Wu et al 2010) use call-dependency relations measured by confidence value and various presentations of text similarity. HiMa (Meng et al 2012) uses call-dependency relations and natural-language-analysis-filtered comments of consecutive commits.…”

Section: Featuresmentioning

confidence: 99%

“…Diff-CatchUp (Xing and Stroulia 2007) defined three sets of heuristics for class, method, and fields, respectively to order the possible replacement methods. SemDiff (Dagenais andRobillard 2011) andSchäfer et al (2008) first use confidence values to preselect the possible replacement methods, then use text similarity to rank them.…”

Section: Matching Techniquesmentioning

confidence: 99%

“…First, Java is supported by most framework API evolution approaches (Dagenais and Robillard 2011;Kim et al 2007;Meng et al 2012;Schäfer et al 2008;Wu et al 2010;Xing and Stroulia 2006). Second, by using programs with which we are familiar, we can more easily identify correct and imperfect change rules and better evaluate the results of the subjects on the tasks in the experiment.…”

Section: Objectsmentioning

confidence: 99%

“…If we had asked the subjects to perform real framework upgrading tasks, finding work-arounds and testing would have increased the precision and the time spent. However, following previous works on change-rules for framework APIs (Dagenais and Robillard 2011;Kim et al 2007;Meng et al 2012;Schäfer et al 2008;Wu et al 2010;Xing and Stroulia 2007), we assume that providing more accurate replacement methods can only help developers by reducing (1) the time spent understanding the new framework, (2) the time spent performing the changes necessary to adapt their programs, and (3) the overall time spent in the cycle {search-forreplacement, change, test}. Yet, in addition to the threats to the validity to our experiment discussed in Section 6, it is possible that other factors impact the accuracy and time of the overall cycle and future work is necessary (1) to study these factors in details, (2) to understand how time is spread throughout the cycle, and (3) to assess the impact of the change rules (and of their accuracy) on the whole cycle.…”

Section: Experiments Vs Real Tasksmentioning

confidence: 99%

“…Thus, to avoid the extra work for framework developers, other approaches automatically identify change rules that describe a matching between target methods, i.e. methods existing in the old release of a framework but not in the new one, and replacement methods in the new release (Antoniol et al 2004;Dagenais and Robillard 2011;Demeyer et al 2000;Dig et al 2006;Fluri and Gall 2006;Godfrey and Zou 2005;Kataoka et al 2001;Kim et al 2005Kim et al , 2007Malpohl et al 2000;Meng et al 2012;Schäfer et al 2008;Weißgerber and Diehl 2006;Wu et al 2010;Xing and Stroulia 2006). The change rules generated by these approaches are imperfect or not all of them are correct.…”

mentioning

confidence: 99%

See 4 more Smart Citations

The impact of imperfect change rules on framework API evolution identification: an empirical study

Serveaux

Guéhéneuc

et al. 2014

Empir Software Eng

View full text Add to dashboard Cite

Software frameworks keep evolving. It is often time-consuming for developers to keep their client code up-to-date. Not all frameworks have documentation about the upgrading process. Many approaches have been proposed to ease the impact of non-documented framework evolution on developers by identifying change rules between two releases of a framework, but these change rules are imperfect, i.e., not 100 % correct. To the best of our knowledge, there is no empirical study to show the usefulness of these imperfect change rules. Therefore, we design and conduct an experiment to evaluate their impact. In the experiment, the subjects must find the replacements of 21 missing methods in the new releases of three open-source frameworks with the help of (1) all-correct, (2) imperfect, and (3) no change rules. The statistical analysis results show that the precision of the replacements found by the subjects with the three sets of change rules are significantly different. The precision with all-correct change rules is the highest while that with no change rules is the lowest, while imperfect change rules give a precision in between. The effect size of the difference between the subjects with no and imperfect change rules is large and that between the subjects with imperfect and correct change rules is moderate. The results of this study show that the change rules generated by framework API evolution approaches do help developers, even they are not always correct. The imperfect change rules can be used by developers upgrading their code when documentation is not available or as a complement to Empir Software Eng partial documentation. The moderate difference between results from subjects with imperfect and all-correct change rules also suggests that improving precision of change rules will still help developers.

show abstract

Section: Featuresmentioning

confidence: 99%

Section: Matching Techniquesmentioning

confidence: 99%

Section: Objectsmentioning

confidence: 99%

Section: Experiments Vs Real Tasksmentioning

confidence: 99%

mentioning

confidence: 99%

See 3 more Smart Citations

The impact of imperfect change rules on framework API evolution identification: an empirical study

Serveaux

Guéhéneuc

et al. 2014

Empir Software Eng

View full text Add to dashboard Cite

show abstract

Watch out for this commit! A study of influential software changes

Kim

et al. 2019

J Software Evolu Process

View full text Add to dashboard Cite

One single code change can significantly influence a wide range of software systems and their users. For example, (a) adding a new feature can spread defects in several modules, while (b) changing an API method can improve the performance of all client programs. Unfortunately, developers often may not clearly know whether code changes are influential at commit time. This paper investigates influential software changes and proposes an approach to identify them immediately when they are applied. Our goals are to (a) identify existing influential changes (ICs) in software projects, (b) understand their characteristics, and (c) build a classification model of ICs to help developers find and address them early. We first conduct a post‐mortem analysis to discover existing influential changes by using intuitions (eg, changes referred by other changes). Then, we re‐categorize all identified changes through an open‐card sorting process. Subsequently, we conduct a survey with about 100 developers to finalize a taxonomy. Finally, from our ground truth, we extract features, including metrics such as the complexity of changes and file centrality in co‐change graphs to build machine learning classifiers. The experiment results show that our classification model with random samples achieves 86.8% precision, 74% recall, and 80.4% F‐measure, respectively.

show abstract

A recommendation system for repairing violations detected by static architecture conformance checking

et al. 2013

View full text Add to dashboard Cite

SummaryThis paper describes a recommendation system that provides refactoring guidelines for maintainers when tackling architectural erosion. The paper formalizes 32 refactoring recommendations to repair violations raised by static architecture conformance checking approaches; it describes a tool—called ArchFix—that triggers the proposed recommendations; and it evaluates the application of this tool in two industrial‐strength systems. For the first system—a 21 KLOC open‐source strategic management system—our approach has indicated correct refactoring recommendations for 31 out of 41 violations detected as the result of an architecture conformance process. For the second system—a 728 KLOC customer care system used by a major telecommunication company—our approach has triggered correct recommendations for 624 out of 787 violations, as asserted by the system's architect. Moreover, the architects have scored 82% of these recommendations as having moderate or major complexity. Copyright © 2013 John Wiley & Sons, Ltd.

show abstract

Recommending Adaptive Changes for Framework Evolution

Cited by 117 publications

References 31 publications

The impact of imperfect change rules on framework API evolution identification: an empirical study

The impact of imperfect change rules on framework API evolution identification: an empirical study

Watch out for this commit! A study of influential software changes

A recommendation system for repairing violations detected by static architecture conformance checking

Contact Info

Product

Resources

About