Specifying Basic Refactorings and Detecting Structural Evolution Conflicts Using Critical Pair Analysis


Refactorings are program transformations that improve the software structure while preserving the external behaviour. In spite of this very useful property, refactorings can still give rise to structural conflicts when parallel evolutions to the same software are made by different developers. We explores this problem of structural evolution conflicts in a formal way by using graph transformation and critical pair analysis. Based on experiments carried out in the graph transformation tool AGG, we show how this formalism can be exploited to detect and resolve structural evolution conflicts.

Here, you see two typical conflict situations when refactoring. The first scenario shows a conflict between pull ups of two different variables with the same name but in different classes.

The second conflict occurs when a framework is refactored while it is already in usage. A method of a framework class which has been refined in a customers leaf class is renamed by the framework developer.



In the following, we show the graph transformation rules specifying the basic refactorings within  graph transformation system "Refactorings".  Thereafter,an overview of  the critical pairs are shown. They are discussed in "Detecting Structural Evolution Conflicts Using Critical Pair Analysis" by Tom Mens and Gabriele Taentzer, a submission for "Software Evolution through Transformations" a satellite workshop of the 2. ICGT in Rome, Italy, 2004.


The whole experiment is based on the following type graph.



Scenario 1:  Parallel Refactorings


Rule Create Superclass


Rule: Encapsulate Variable


Rule: Move Method


Rule: Move Variable


Rule: Pull Up Method


Rule: Pull Up Variable


Rule: Rename Class


Rule: Rename Method


Rule: Rename Variable


Scenario 2: Framework Refactorings


Rule: Add Class In Leaf


Rule: AddMethodIn LeafClass



Rule: AddVariableInLeafClass



Rule: RefineMethodInLeafClass