Presented by: Ashgan Fararooy

Referenced Papers and Related Work on:

Possible Related Papers

Automatic Inference of Structural Changes for Matching Across Program Versions

An Approach to Software Evolution Based on Semantic Change

Understanding source code evolution using abstract syntax tree matching

Recomposition - Coordinating a Web of Software Dependencies

Identifying the Semantic and Textual Differences Between Two Versions of The Program

Visualizing and Querying Software Structures

Miryung Kim, David Notkin,

Dan Grossman

Abstract Goal: Mapping code elements in one

version of a program to corresponding code elements in another version

A fundamental building block for many software engineering tools

Tools that match code elements or identify structural changes (refactorings and API changes):

• Version merging tools• Regression testing tools• Profile propagation tools

Abstract Two important limitations of such tools

Having difficulty disambiguating among many potential matches or refactoring candidates

Hard to analyze their outcome due to an unstructured representation of results

Proposed approach to overcome these limitations: Represent structural changes as a set of

high-level change rules Automatically infer likely change rules and

determines method-level matches based on the rules

Motivation

Interest in mining software repositories is demanding more effective and systematic matching techniques

The unstructured, usually lengthy, list of matches or refactorings may prevent the result of existing tools from being broadly used in mining software repository research

Background To match code elements, the differences

between two programs must be identified

Computing semantic differences is undecidable

Tools typically approximate matching via syntactic similarity

Existing refactoring reconstruction tools look for code changes that match a predefined set of refactoring patterns

Problem: either too many refactoring candidates or no candidates

Change Rules

Question: “Given two versions of a program, what changes occurred with respect to a particular vocabulary of changes?”

A change vocabulary characterizes the applications for which the matching results can be used

For example, “diff” defines a change vocabulary in terms of delete, add, and move line

Change Rules The paper introduces a change vocabulary with

the goal of representing groups of related homogeneous changes precisely

The core of their change vocabulary is a change rule consisting of a quantifier and a scope to which a low-level transformation applies

“For all x in (scope − exceptions),t(x),” where t is a transformation, scope is a set of code elements, and exceptions is a subset of scope

Their change vocabulary describes structural changes at or above the level of a method header

Change Rules

Transformation Samples:

Change Rules

Change Rule Samples:

All methods whose class name either includes Plot or JThermometer changed their package name from chart to chart.plot:

Change Rules

Change Rule Samples:

All methods that match the chart.*Plot.get*Range() pattern take an additional ValueAxis argument, except the getVerticalRange method in the MarkerPlot class:

Rule-based Matching

The paper defines a matching between two versions of a program by a set of change rules

The scope of one rule may overlap with the scope of another rule as some methods undergo more than one transformation

The inference algorithm ensures that it infers a set of rules such that the application order of rules does not matter

The methods that are not matched by any rules are deleted or added methods

Applications of Change Rules

Bug Finding

Assisted Documentation

API Evolution Analysis

API Update

Identifying Related Changes

Evaluation & Conclusion

By applying their tool to several open source projects, the authors show that it identifies matches that are difficult to find using other approaches

They also show their approach produces more concise results than other approaches

They claim their approach is the first to automatically infer structural changes and represent them concisely as a set of rules

Rebecca E. Grinter

Abstract

Revisiting the concept of "recomposition”:All the work that development organizations do to make sure that their product fits together and into a broader environment of other technologies

Technologies, such as Configuration Management (CM) systems, can ameliorate some of a software development team’s need to engage in recomposition

Technological solutions do not scale to address other kinds of recomposition needs

Summary

The paper focuses on various organizational responses to the need for recomposition

Describes how those responses are manifested in the day-to-day communications and responsibilities of individuals throughout the organization

Highlights how changes in an organization complicate recomposition

Conclusion

The paper concludes with a discussion ofthree features of software developmentwork that are revealed by recomposition:

• The affects of environmental disturbances on development work

• The types of dependencies that require recomposition

• The images of organizations required to manage the recomposition