
<h1>Henshin Example: Simple Class Modeling Refactoring</h1>

<p>
<small><i>contributed by Thorsten Arendt and Kristopher Born</i></small>
</p>

<p>
This is an example for the Critical Pair Analysis(CPA) in Henshin. It is 
described in the paper <i>Analyzing Conflicts and Dependencies of Rule-Based 
Transformations in Henshin</i> submitted to FASE 2015. We explain how to use 
the analysis (wizard and programmatically) to find all potential conflicts and 
dependencies in a set of rules.
</p>

<p>
The transformation model and source code can be found
<a href="http://git.eclipse.org/c/henshin/org.eclipse.emft.henshin.git/tree/plugins/org.eclipse.emf.henshin.examples/src/org/eclipse/emf/henshin/examples/simpleclassmodelingrefactoring">here</a>.
</p>


<h2>Metamodel</h2>

<p>
<a href="simpleclassmodelingrefactoring/classModel.png"><image src="simpleclassmodelingrefactoring/classModel.png" align="center" width="639" /></a>
<br>
The metamodel is defined in the file <i>ClassModel.ecore</i>. We used 
the Ecore Tools to draw a diagram (depicted above). 
The diagram is stored in the file <i>ClassModel.ecore_diagram</i>.
</p>

<p>
The EMF Ecore specification of a simple class modeling language can be used to model 
the main static aspects of a given domain. Such a <i>Model</i> consists of a number 
of <i>Classes</i> where each one can have a number of <i>Attributes</i>. Finally, 
a class may be associated to other classes by <i>references</i>.
</p>

<h2>Refactoring Transformation Rules</h2>

<p>
<a href="simpleclassmodelingrefactoring/refactoringRules.png"><image src="simpleclassmodelingrefactoring/refactoringRules.png" align="right" width="400" /></a>
Since refactoring is a specific kind of model transformation, refactorings for EMF-based 
models can be specified in Henshin and then integrated into a model refactoring framework 
such as <a href="http://www.eclipse.org/emf-refactor/">EMF Refactor</a>. 
Rule <i>Add Attribute</i> inserts a new attribute into an exiting class whose name is 
given by parameter clName</i>. Rule <i>Move Attribute</i> shifts an attribute from its 
owning class to an associated one along the corresponding reference. Finally, rule
<i>Remove Empty Class</i> deletes an existing class if it has no relation to further 
model elements, i.e., the class has neither attributes or references nor it is referenced 
by another class.
</p>

<h2>Scenario</h2>

<p>
<a href="simpleclassmodelingrefactoring/scenario.png"><image src="simpleclassmodelingrefactoring/scenario.png" align="right" width="300" /></a>
Lets assume that a software developer wants to know which refactoring rules need to be 
applied in order to restructure a class model. More specifically, we refer to the class 
model shown in the following figure representing an early analysis model in the development 
of an address book system.
</p>

<p>
Typically, many different refactoring rules may be applicable, and it is not easy to find 
out the best way to apply these rules. On the one hand, simultaneous applications of specific 
refactoring rules may not be possible due to parallel dependencies between them, and on the 
other hand, some refactoring rules may sequentially depend on other ones. Considering the 
refactorings and the class model presented above, we observe the following:
<ul>
Class <i>Account</i> is not used so far and makes no sense. Two refactorings are applicable here. 
Either the class is extended by a new <i>attribute</i>, e.g. <i>accountnumber</i>, or it is 
removed from the model (refactorings <i>Add Attribute</i> respectively <i>Remove Empty Class</i>). 
However, if one refactoring is executed the other becomes inapplicable, i.e., these refactorings are in conflict.
</ul>
<ul>
Attribute <i>landlineNo</i> of class Person should be shifted to either class <i>Home</i> or 
class <i>Office</i> (both by using refactoring <i>Move Attribute</i>). However, if it is shifted 
to class <i>Home</i> the other refactoring becomes inapplicable (and vice versa). 
This means, refactoring <i>Move Attribute</i> is in conflict with itself.
</ul>
</p>

<h2>Applying the Critical Pair Analysis</h2>

<p>
The CPA in Henshin can be used in two different ways: Its application programming interface (API) 
can be used to integrate the CPA into other tools of different application domains. In addition, 
a user interface (UI) is provided supporting domain experts in developing rules by providing the 
CPA interactively.
</p>

<h3>Execution using the CPA Wizard</h3>

<p>
The CPA is called on a Henshin file in the Eclipse Package Explorer (Right click &rarr; Henshin 
&rarr; Calculate Critical Pairs).
</p>

<a href="simpleclassmodelingrefactoring/callCPAWizard.png"><image src="simpleclassmodelingrefactoring/callCPAWizard.png" align="center" width="300" /></a>

<p>
This brings up a wizard to specify the rule set to be analyzed and the kind of critical 
pairs that shall be analyzed. 
</p>

<a href="simpleclassmodelingrefactoring/CPAWizard.png"><image src="simpleclassmodelingrefactoring/CPAWizard.png" align="center" width="300" /></a>

<p>
After the CPA, a dedicated results view provides an overview on all conflicts and dependencies 
found. The resulting list of critical pairs is ordered along conflicts and dependencies as well 
as rule pairs. For each pair, a set of conflicts (dependencies) is listed named by their kinds. 
</p>

<a href="simpleclassmodelingrefactoring/CPAResultView.png"><image src="simpleclassmodelingrefactoring/CPAResultView.png" align="right" width="300" /></a>

<p>
Here, three conflics are found. The conflicts of the first and the third rule pair in the results 
view present a <i>produce-forbid-conflict</i> and a <i>delete-use-conflict</i>, as informally 
described in item (1) at the scenario description above. Item (2) of the running example describes 
the <i>delete-use-conflict</i> for rule pair (<i>Move Attribute</i>, <i>Move Attribute</i>) which 
is also listed in the CPA results view.
</p>

<p>
For each critical pair, a minimal EMF model can be viewed after double-clicking on a specific 
conflict (dependency). The following figure shows a minimal model in the tree-based Ecore instance editor.
</p>

<a href="simpleclassmodelingrefactoring/CPAEditor.png"><image src="simpleclassmodelingrefactoring/CPAEditor.png" align="center" width="600" /></a>

<p>
The minimal model (see center of the figure above) is related to the first <i>produce-forbid-conflict</i> 
of the example. Both rules (shown on the left- and the right-hand-side of the figure above; here 
using the tree-based Henshin editor) overlap in model elements of types <i>Class</i> and <i>Attribute</i>. 
Element <i>Attribute</i> is marked by hash tags to state that it causes the conflict. 
Numbers indicate corresponding matches of rule nodes to model nodes. 
</p>


<h3>Execution using the API</h3>

<p>
The usage of the API is straightforward. There are two main steps to obtain a 
result: (1) Initialize the meta-model and the rules, and (2) start the execution 
of the conflict (dependency) analysis. The following figure shows the 
corresponding API. 
</p>

<a href="simpleclassmodelingrefactoring/ICriticalPairAnalysis.png"><image src="simpleclassmodelingrefactoring/ICriticalPairAnalysis.png" align="center" width="471" /></a>

<p>
The initialization can be done with one or two rule sets containing Henshin 
transformation rules. Providing one rule set using method 
<i>init( List<Rule> rules, CPAOptions options)</i> leads to the analysis of all 
combinations between them leading to a quadratic number of pairs. Passing two 
sets of rules using method <i>init( List<Rule> r1, List<Rule> r2, CPAOptions options)</i> 
is useful to define sequences of rules which means that only conflicts 
(dependencies) with rules of set <i>r1</i> as first rule an rules of set <i>r2</i> 
as second rule are analyzed. Another parameter is the <i>CPAOptions</i>. 
Generally it can be used with its default values. In detail, this provides 
options to stop the calculation after finding a first conflict (dependency) 
[isComplete], to ignore critical pairs of same rules [ignore], and to reduce the 
result by critical pairs which are based on the same match [reduceSameMatch]. 
After rule initialization, an optional check can be performed (method <i>check()</i>). 
This proves for instance whether the passed rules are based on a common meta model. 
The calculation of the conflicts (dependencies) starts by the corresponding methods 
<i>runConflictAnalysis()</i> and <i>runDependencyAnalysis()</i>. Since the 
calculation can be time-consuming the interface provides additionally the methods 
<i>runConflictAnalysis(IProgressMonitor monitor)</i> and 
<i>runDependencyAnalysis(IProgressMonitor monitor)</i> to get feedback by the monitor.
</p>

<p>The following figure shows the results API.</p>

<a href="simpleclassmodelingrefactoring/CPAResultAPI.png"><image src="simpleclassmodelingrefactoring/CPAResultAPI.png" align="center" width="400" /></a>

<p>
All conflicts (dependencies) are within the container <i>CPAResult</i>. Conflict 
and Dependency are concrete instances of the general concept <i>CriticalPair</i>. 
A critical pair always contains two rules and a minimal model showing the 
conflict or dependency. Two mappings are required to map rule elements to 
corresponding ones in the minimal model. Although <i>Dependency</i> and 
<i>Conflict</i> share this requirement, it is not part of a critical pair in 
general, since different mappings are reported. A conflict is based on the 
left-hand sides (LHSs) of both rules, such that both mappings are <i>matches</i>. 
A dependency is based on the right-hand side (RHS) of the first rule <i>r1</i> 
and the LHS of the second rule <i>r2</i>. Therefore, the first mapping is a 
<i>comatch</i> of RHS to the minimal model. Finally, there are different kinds 
of conflicts and dependencies as introduced above. Two enumerations list these 
kinds (see following figure). Note that dependency and conflict kinds are 
strictly separated.
</p>

<a href="simpleclassmodelingrefactoring/CPKinds.png"><image src="simpleclassmodelingrefactoring/CPKinds.png" align="center" width="429" /></a>