Digging the Development Dust for Refactorings

Abstract

Software repositories are rich sources of information about the software development process. Mining the information stored in them has been shown to provide interesting insights into the history of the software development and evolution. Several different types of information have been extracted and analyzed from different points of view. However, these types of information have not been sufficiently cross-examined to understand how they might complement each other. In this paper, we present a systematic analysis of four aspects of the software repository of an open source project -source-code metrics, identifiers, return-on-investment estimates, and design differencing -to collect evidence about refactorings that may have happened during the project development.In the context of this case study, we comparatively examine how informative each piece of information is towards understanding the refactoring history of the project and how costly it is to obtain. Motivation and IntroductionSoftware repositories are rich sources of information about the software-development process, and mining this information has been shown to provide interesting insights into the lifecycle of a project and the design rationale underlying its evolution. Several different types of information have been extracted and analyzed to collect evidence about different system properties and various trends and events in the process through which it was developed and evolved.For example, researchers have worked on assessing different system qualities. Bevan and Whitehead [1] developed a method for detecting "unstable" areas of software, i.e., areas modified more frequently than average, based on static dependence graphs. Inspired by chaos theory, Hassan and Holt [8] devised a system-complexity metric based on the software-development process: their study of the CVS history of several open-source projects showed that, indeed, a chaotic/complex development process negatively affects the quality of the source-code product.A lot of work has also been devoted to recognizing "change patterns" in the software evolution history. Module co-evolution has been studied as a means for predicting the impact of changes [16, 20, 21]. Godfrey and Zou [7] have shown how to detect merging and splitting of files and functions in procedural code using origin analysis. Especially interesting to the research community are refactorings, i.e., behavior-preserving structural change patterns [5,10,14]. Demeyer's group has had a long-term focus on detecting refactorings. They initially proposed a set of heuristics for recognizing the general type of refactoring that a system has gone through based on changes in the source-code size [4]. They then proceeded to investigate the use of clone-detection to identify move and renaming refactorings [15]. In our own work with design differencing [17,19], we have shown how the UMLDiff algorithm for semantic tree differencing of UML class diagrams can reveal the elementary design changes between two software versions, which can then b...

A Case Study on the Impact of Refactoring on Quality and Productivity in an Agile Team

“…We aggregate metrics at a system level (we add up all single classes) and compute their overall changes per day in the case of product metrics and the total time spent for coding per day in the case of effort. The way we aggregate metrics is a first approach and could be refined: We could for example identify the classes affected by refactoring using a technique presented in [12], [30] and use only them for analyzing changes in quality and productivity. Whether this would change our findings, has to be assessed in a future analysis.…”

“…Nevertheless, there is almost no solid, empirical, and quantitative evidence of such claim, apart from a small case study, where it appeared that refactoring decreased the long-term productivity [1]. Recently Schofield et al [30] performed a return on investment analysis on an open source project in order to estimate savings in effort, given a specific (beneficial) code change. They found that, most of the time, refactorings have beneficial impacts on maintenance activities, and thus are motivated from an economic perspective.…”

Differencing logical UML models

“…Name similarity is a "safe" indicator that e 1 and e 2 are the same entity: in our experience with several case studies (Schofield et al 2006, Xing and Stroulia 2004a, 2005b, 2006b, very rarely is a model element removed and a new element with the same name but different element type and different behavior is added to the system. UMLDiff recognizes same-name model elements of the same type first and uses them as initial "landmarks" to subsequently recognize renamed and moved elements.…”

“…UMLDiff is at the core of our design-evolution analysis work (Schofield et al 2006;Xing and Stroulia 2004a, 2004b, 2005a, 2005c, 2006a, 2006b, 2006c, which has been implemented in the JDEvAn (Java Design Evolution and Analysis) tool (http://www.cs.ualberta.ca/~xing/jdevan.html). In addition to UMLDiff, JDEvAn also includes: a fact extractor that crawls the software versions to extract the models required as input by UMLDiff, a database back-end to store the extracted models and the UMLDiff change facts, several special-purpose analyses to infer more complex phenomena based on the UMLDiff change facts, and visualization modules for intuitively communicating, exploring and analyzing the discovered information.…”

Comparison of similarity metrics for refactoring detection

“…Their UMLDiff algorithm is capable of detecting some basic structural changes in the system such as the addition, removal, renaming or moving of UML entities. More complex structural changes can be found using a suit of queries that try to find a composition of elementary changes [23,17].…”