Automatic Inference of Structural Changes for Matching across Program Versions

Kim, Miryung; Notkin, David; Grossman, Dan

doi:10.1109/icse.2007.20

Cited by 106 publications

(91 citation statements)

References 39 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our results indicate that most of the time, refactorings are tightly intermixed with other refactorings or manual edits before reaching VCS. This could severely undermine the effectiveness of refactoring inference tools that are based on VCS snapshots [10,11,21,29,49,50]. Our findings serve as a strong motivation to build a refactoring inference tool based on the precise, fine-grained data collected by CodingTracker and compare its accuracy against the existing snapshot-based tools.…”

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 99%

“…Kim et al [29] proposed summarizing the structural changes between different versions of a source code file as high-level change rules. Change rules provide a cohesive description of related changes beyond deletion, addition, and removal of a textual element.…”

Section: Tools For Reconstructing Program Changesmentioning

confidence: 99%

“…Many tools [10,11,21,29,49,50] compare a program's snapshots stored in VCS to infer the refactorings applied to it. As the first step, such a tool employs different similarity measures to match the refactored program entities in the two compared snapshots.…”

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 99%

See 2 more Smart Citations

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

Negara

Vakilian

Chen

et al. 2012

ECOOP 2012 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Researchers use file-based Version Control System (VCS) as the primary source of code evolution data. VCSs are widely used by developers, thus, researchers get easy access to historical data of many projects. Although it is convenient, research based on VCS data is incomplete and imprecise. Moreover, answering questions that correlate code changes with other activities (e.g., test runs, refactoring) is impossible. Our tool, CodingTracker, non-intrusively records fine-grained and diverse data during code development. CodingTracker collected data from 24 developers: 1,652 hours of development, 23,002 committed files, and 314,085 testcase runs. This allows us to answer: How much code evolution data is not stored in VCS? How much do developers intersperse refactorings and edits in the same commit? How frequently do developers fix failing tests by changing the test itself? How many changes are committed to VCS without being tested? What is the temporal and spacial locality of changes?

show abstract

Section: How Much Do Developers Intersperse Refactorings and Edits Inmentioning

confidence: 99%

Section: Tools For Reconstructing Program Changesmentioning

confidence: 99%

See 1 more Smart Citation

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

Negara

Vakilian

Chen

et al. 2012

ECOOP 2012 – Object-Oriented Programming

View full text Add to dashboard Cite

show abstract

“…Several approaches have been proposed to address the Application Programming Interface (API) evolution problem [9], [14], [25], [28], [32]. The objective is to retrieve correspondences between elements (often methods) of different versions of a considered API.…”

Section: Api Evolutionmentioning

confidence: 99%

“…The first is to recover the evolution of the design between the two considered versions and then infer information about how specific calls should be modified; for example [32] uses the results of UMLDiff [30], [31] to provide such information. The second is to consider the elements separately and compute similarity measures to attach some level of likelihood to the fact that an element A1 from the old version has been replaced by element A2 [14], [25], [28], [9].…”

Section: Api Evolutionmentioning

confidence: 99%

MADMatch: Many-to-Many Approximate Diagram Matching for Design Comparison

Kpodjedo

Ricca

Galinier

et al. 2013

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Abstract-Matching algorithms play a fundamental role in many important but difficult software engineering activities, especially design evolution analysis and model comparison. We present MADMatch, a fast and scalable Many-to-many Approximate Diagram Matching approach based on an Error-Tolerant Graph matching (ETGM) formulation. Diagrams are represented as graphs, costs are assigned to possible differences between two given graphs, and the goal is to retrieve the cheapest matching. We address the resulting optimisation problem with a tabu search enhanced by the novel use of lexical and structural information. Through several case studies with different types of diagrams and tasks, we show that our generic approach obtains better results than dedicated state-of-the-art algorithms, such as AURA, PLTSDiff or UMLDiff, on the exact same datasets used to introduce (and evaluate) these algorithms.

show abstract

Understanding systematic and collaborative code changes by mining evolutionary trajectory patterns

Jiang

Peng

Wang

et al. 2017

J Software Evolu Process

View full text Add to dashboard Cite

The life cycle of a large-scale software system can undergo many releases. Each release often involves hundreds or thousands of revisions committed by many developers over time. Many code changes are made in a systematic and collaborative way. However, such systematic and collaborative code changes are often undocumented and hidden in the evolution history of a software system. It is desirable to recover commonalities and associations among dispersed code changes in the evolutionary trajectory of a software system. In this paper, we present Summarizing Evolutionary Trajectory by Grouping and Aggregation (SETGA), an approach to summarizing historical commit records as trajectory patterns by grouping and aggregating relevant code changes committed over time. The SETGA extracts change operations from a series of commit records from version control systems. It then groups extracted change operations by their common properties from different dimensions such as change operation types, developers, and change locations.After that, SETGA aggregates relevant change operation groups by mining various associations among them. We implement SETGA and conduct an empirical study with 3 open-source systems.We investigate underlying evolution rules and problems that can be revealed by the identified patterns and analyze the evolution of trajectory patterns in different periods. The results show that SETGA can identify various types of trajectory patterns that are useful for software evolution management and quality assurance.

show abstract

Automatic Inference of Structural Changes for Matching across Program Versions

Abstract: Mapping code elements in one version of a program to corresponding code elements in another version

Cited by 106 publications

References 39 publications

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

MADMatch: Many-to-Many Approximate Diagram Matching for Design Comparison

Understanding systematic and collaborative code changes by mining evolutionary trajectory patterns

Contact Info

Product

Resources

About