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
