Finding refactorings via change metrics

DemeyerSerge,; DucasseStéphane,; Nierstrasz, Oscar

doi:10.1145/354222.353183

Cited by 48 publications

(19 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…It is hard to discover the changes in a large system and many authors suggest that tools should be used to detect changes. For instance, Demeyer et al [12] describe how they used metrics tools to discover refactorings. However, most API changes follow a long deprecate-replace-remove cycle to preserve backwards compatibility.…”

Section: Collecting the Datamentioning

confidence: 99%

“…The current tool support [12][13][14][15] for detecting and classifying structural evolution is very limited: only a few types of refactorings (mostly merging and splitting) were attempted to be detected. Therefore, to do a comprehensive qualitative analysis of the breaking changes, the manual method seems the only alternative.…”

Section: Dig and R Johnsonmentioning

confidence: 99%

“…Therefore, to do a comprehensive qualitative analysis of the breaking changes, the manual method seems the only alternative. We double-checked our quantitative analysis by using a tool (Van [16]) and heuristics (as in [12]). For each type of refactoring, we wrote queries in Van that return those structures suspected of that specific refactoring.…”

Section: Dig and R Johnsonmentioning

confidence: 99%

“…There exists some limited tool support for detecting and classifying structural evolution. Detection of class splitting and merging was the main target of the tools described in [12][13][14][15]. Clone detection can be used to detect some refactorings such as renaming or moved method.…”

Section: Related Workmentioning

confidence: 99%

See 3 more Smart Citations

How do APIs evolve? A story of refactoring

Dig

Johnson

2006

J. Softw. Maint. Evol.: Res. Pract.

196

168

View full text Add to dashboard Cite

Frameworks and libraries change their APIs. Migrating an application to the new API is tedious and disrupts the development process. Although some tools and ideas have been proposed to solve the evolution of APIs, most updates are done manually. To better understand the requirements for migration tools, we studied the API changes of four frameworks and one library. We discovered that the changes that break existing applications are not random, but tend to fall into particular categories. Over 80% of these changes are refactorings. This suggests that refactoring-based migration tools should be used to update applications.way to update component-based applications. This paper is the beginning of our quest to meet the needs of both component and application developers. What is a suitable representation for the changes that happened in a component? Can it be gathered automatically? Does this representation carry both the syntax and the semantics of changes? Can it lead to safe, automatic updating of component-based applications? How much of the effort spent on updating component-based applications can be saved?Although there are principles of software evolution that are true for software in any language, programming languages have an impact on software evolution. We are particularly interested in the evolution of object-oriented components (we refer to both the library and framework as components, unless a distinction is necessary). Classes contain a mixture of private and public methods. The public methods are those that are meant to be used by application programmers. The set of public methods of a class library make up its application programmer interface (API). Changes to private methods and classes do not pose a problem to application developers; they only care about changes to the API.An important kind of change to object-oriented software is a refactoring [4]. Refactorings are program transformations that change the structure of a program but not its behavior. Refactorings include renaming classes or methods, moving methods or variables between classes, and splitting methods or classes. A refactoring that changes the interface of an object must change all of its clients to use the new interface. When a class library that is reused in many systems is refactored, the systems that reuse it must change. However, those developing the library often do not know all of the systems that reuse it. The new version of the library is a refactoring from their point of view, but not from the point of view of the application developers who are their customers.The original work on refactoring was motivated by framework evolution. Opdyke and Johnson [5] looked at the Choices operating system and the kind of refactorings that occurred as it evolved. Graver [6] studied an object-oriented compiler framework as it went through three iterations. Tokuda and Batory [7] describe the evolution of two frameworks, focusing on how large architectural changes can be accomplished by a sequence of refactorings.However, none of these studies d...

show abstract

Section: Collecting the Datamentioning

confidence: 99%

Section: Dig and R Johnsonmentioning

confidence: 99%

Section: Dig and R Johnsonmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

How do APIs evolve? A story of refactoring

Dig

Johnson

2006

J. Softw. Maint. Evol.: Res. Pract.

196

168

View full text Add to dashboard Cite

show abstract

“…We list three approaches that focus on finding different types of changes. Demeyer et al used the structural measurements to detect refactorings such as rename method or move method [16]. They represented each version with a set of metrics and then identified changes based on analyzing the change in the measurements.…”

Section: Two Versions Comparisonmentioning

confidence: 99%

Modeling history to analyze software evolution

Gîrba

Ducasse

2006

J. Softw. Maint. Evol.: Res. Pract.

Self Cite

View full text Add to dashboard Cite

The histories of software systems hold useful information when reasoning about the systems at hand or when reasoning about general laws of software evolution. Over the past 30 years, research has been increasingly spent on understanding software evolution. However, the approaches developed so far do not rely on an explicit meta-model and, thus, they make it difficult to reuse or compare their results. We argue that there is a need for an explicit meta-model for software evolution analysis. We present a survey of the evolution analyses and deduce a set of requirements that an evolution meta-model should have. We define Hismo, a meta-model in which history is modeled as an explicit entity. Hismo adds a time layer on top of structural information, and provides a common infrastructure for expressing and combining evolution analyses and structural analyses. We validate the usefulness of our meta-model by presenting how different analyses are expressed on it.what changes appeared in the system [2]. Some basic services were also added to model extra or meta information such as who changed files and why. However, only very rudimentary models were used to represent this information-typically a few unstructured lines of text to be inserted in a log file.Whereas versioning systems enabled the history of each source file to be recorded independently, configuration management systems attempted to record the history of software products as a collection of versioned source files. Research on configuration management was very active in the 1980s and 1990s, but the emphasis was still on controlling and recording software evolution.The importance of modeling and analyzing software evolution began to be recognized in the early 1970s with the work of Lehman and Belady [3]. However, it was not until recent years that extensive research was spent on exploiting the wealth of information residing in versioning repositories for different purposes such as reverse engineering or cost prediction. Problems such as software aging [4] and code decaying [5] gained increasing recognition both in academia and in industry.Various approaches have been proposed to analyze aspects of software evolution for purposes such as identifying driving forces in software evolution or reverse engineering. Each of these approaches typically focuses on only some traits of software evolution, and most of these approaches rely on ad hoc models (i.e., models that are not described by an explicit meta-model) or their meta-model is specific to the goals of the supported analysis.By a meta-model we mean a specification model for a class of systems under study where each system in the class is itself a valid model expressed in a certain modeling language [6]. By model we mean a simplification of a system built with an intended goal in mind [7]. A meta-model describes the way the domain can be represented by the model; that is, it provides bricks for the analysis. An explicit meta-model allows those bricks to be understood. Understanding the bricks allows for the compari...

show abstract

Anti‐bloater class restructuring: An exploratory study

Machado

Paula‐Sobrinho

Maia

2022

J Software Evolu Process

View full text Add to dashboard Cite

Proper software modularization still poses challenges to developers. One of the symptoms of inappropriate modularization is the large size of object-oriented classes.In that case, a possible solution would be class restructuring with refactorings, such as Extract Class, Extract Super-Class, or Move Method. However, class refactoring is challenging because of the possible side effects of improper changes. In this context, more effective decision support systems on which classes are worthwhile for restructuring to improve modularity are still lacking. This work focuses on exploring possible alternatives for supporting decision on class restructuring. A prospective study was performed on selected kinds of restructuring, aiming at determining what types of strategies are typically adopted to restructure bloated classes and which classes developers decided to restructure. Then, we proposed and evaluated a predictive model for indicating which classes to restructure, aiming at delivering a restructuring guide on those classes. Finally, we conducted a qualitative study to evaluate the perception of developers on such guides based on predictions for real software. The results have shown situations in which the proposed predictions could help the restructuring process but also elucidated possible improvements and limitations.

show abstract

Finding refactorings via change metrics

Cited by 48 publications

References 13 publications

How do APIs evolve? A story of refactoring

How do APIs evolve? A story of refactoring

Modeling history to analyze software evolution

Anti‐bloater class restructuring: An exploratory study

Contact Info

Product

Resources

About