![]()
Specifying Basic Refactorings
|
SummaryRefactorings 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 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.
ScreenshotsThe whole experiment is based on the following type graph.![]() Scenario 1: Parallel RefactoringsRule 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 RefactoringsRule: Add Class In Leaf ![]() Rule: AddMethodIn LeafClass ![]() Rule: AddVariableInLeafClass ![]() Rule: RefineMethodInLeafClass ![]() The results of applying the critical pairs analysis algorithm to these refactorings are shown in table 1 below. It shows the number of conflicts which remain after reducing the set of critical pairs. ![]() |
Revision: