Variability-Based Model Transformation
4.2 Overview
4.2.1 Examples
4.2 Overview 75
«create»
:Method abstract=true name=m
«preserve»
:Class abstract=true name=src
«preserve»
:Class name=trg
«create»
:Annotation value="Dep"
«create»
:Method name=m
«preserve»
:Method name=m A: pullUp(src, trg, m)
«preserve»
:Method name=m
«preserve»
:Class name=src
3 1
«delete»
methods
«preserve»
:Class name=trg
2
«create»
methods
«preserve»
extends
B: pushDown(src, trg, m)
«preserve»
:Class name=src
6 4
«delete»
methods
«preserve»
:Class name=trg
«preserve» 5
extends
«create»
methods
«preserve»
:Method name=m
9 7
«delete»
methods
8
«create»
methods
«preserve»
extends
10
«create»
methods C: pushDownWithAbstract(src, trg, m)
«preserve»
:Method name=m
«preserve»
:Class name=src
23 20
«delete»
methods
«preserve»
:Field
21
«create»
methods
«preserve»
fields
25
«create»
methods
F: moveAndCreateDeprecatedDelegate(src, trg, m)
«preserve»
:Class name=trg
«preserve» 22
type
«create» 24
methods
«create»
:Method name=m
«preserve»
:Method name=m
«preserve»
:Class name=src
18 15
«delete»
methods
«preserve»
:Field
16
«create»
methods
«preserve»
fields
19
«create»
methods
E: moveAndCreateDelegate(src, trg, m)
«preserve»
:Class name=trg
«preserve» 17
type
«preserve»
:Method name=m
«preserve»
:Class name=src
14 11
«delete»
methods
«preserve»
:Field
12
«create»
methods
«preserve»
fields D: move(src, trg, m)
«preserve»
:Class name=trg
«preserve» 13
type
Figure 4.2:Refactoring rules for class models.
Rule Atakes as input two classes, one of them sub-classing the other, and a method. Each of these input objects is specified by its name. The rule moves the method from a sub-class to its super-class, by deleting it from the sub-class and adding it to the super-class. Similarly, Rule Bmoves a method from the super-class to one of its sub-classes. Rule Calso moves a method from the super- to a sub-class, but, in addition, creates an abstract method with the same name in the super-class.Rules D,E, andFmove a method across an association. The latter two rules also create a “wrapper” method of the same name in the source class.
Rule Fuses an annotation to mark this method as deprecated. Such rule sets are often created by cloning, that is, copying a rule and modifying it to fit the new purpose.
We consider the merge-refactoring of a rule set created using cloning.
The result is a rule set with variability-based (VB) rules in which the common portions are unified and the differences are explicated, as shown in Fig. 4.3. Specifically,Rules B andC are merged, producing a new VBRule B+C.Rules D, E, andF are merged into D+E+F. Rule A remains as is.
«create»
:Method abstract=true name=m
«preserve»
:Class name=trg
«preserve»
:Method name=m
«create»
method
B+C: pushDown(src, trg, m)
«preserve»
extends
«delete»
methods «create»
methods A: pullUp(src, trg, m)
«preserve»
:Method name=m
«preserve»
:Class name=src
«delete»
methods
«preserve»
:Class name=trg
«create»
methods
«preserve»
extends
«preserve»
:Class name=src
«preserve»
:Class name=trg
«create»
:Annotation value="Dep"
«create»
:Method name=m
«preserve»
:Method name=m
«delete»
methods
«preserve»
:Field
«create»
methods
«preserve»
fields
«create»
methods
D+E+F: move(src, trg, m)
«preserve»
type
«create»
annotation
«preserve»
:Class abstract=true name=src
26 27
28
29 30
32
31
33 34 35
38 37 36
A
xor(B,C)
xor(D,E,F)
Figure 4.3:Variability-based refactoring rules for class models.
Each VB rule has a set ofvariation points, corresponding to the names of the input rules: Rule B+Chas the variation pointsBandC. In addition, each rule has avariability modelspecifying relations between variation points, such as mutual exclusion: Rule B+C has the variability model xor(B,C). VB rules areconfiguredby binding each variation point to ei-thertrueorfalse. Portions of VB rules are annotated withpresence con-ditions. These portions are removed if the presence condition evaluates tofalsefor the given configuration. Element #32 and its incoming edge are removed in the configuration {C=false,B=true}. For conciseness, we omit the presence conditiontrue, e.g., for nodes #26-#28.
In this example, the VB rules are configured individually, either manu-ally by the user or automaticmanu-ally by client code, e.g., a model editor. The result of configuration is a “flat“ rule again – a process similar to that in product-line engineering approaches [26]. Alternatively,all rules of a rule set may be executed inbatch mode, i.e., considered simultaneously.
The following example deals with such a scenario.
4.2 Overview 77
C: RemoveRedundantNot-ReplaceForallInQuantified D: RemoveRedundantNot-ReplaceExistsInQuantified A: RemoveRedundantNot-ReplaceForallInBasic
«delete»
:BasicFormula
«preserve»
:BasicFormula
«preserve»
:QuantifiedFormula
«delete»
:BasicFormula
«preserve»
:Formula
«create»
nested
B: RemoveRedundantNot-ReplaceExistsInBasic
«delete»
operator
«preserve»
:Quantifier name="EXISTS"
16
«preserve»
:Quantifier name="FORALL"
15
«preserve»
:Operator name="NOT"
14
«create»
quantifier
«delete»
quantifier 11 10 9
12 13
«delete»
args
«delete»
args
«create»
args
«delete»
args
«delete»
nested
«delete»
operator
«delete»
:BasicFormula
«preserve»
:BasicFormula
«preserve»
:QuantifiedFormula
«delete»
:BasicFormula
«preserve»
:Formula
«delete»
nested
«delete»
operator
«preserve»
:Quantifier name="FORALL"
8
«preserve»
:Quantifier name="EXISTS"
7
«preserve»
:Operator name="NOT"
6
«create»
quantifier
«delete»
quantifier 3 2 1
4 5
«delete»
args
«delete»
args
«create»
args
«delete»
args
«create»
nested
«delete»
operator
«delete»
:BasicFormula
«preserve»
:QuantifiedFormula
«preserve»
:QuantifiedFormula
«delete»
:BasicFormula
«preserve»
:Formula
«create»
nested
«delete»
operator
«preserve»
:Quantifier name="EXISTS"
32
«preserve»
:Quantifier name="FORALL"
31
«preserve»
:Operator name="NOT"
30
«create»
quantifier
«delete»
quantifier 27 26 25
28 29
«delete»
args
«delete»
nested
«create»
args
«delete»
args
«delete»
nested
«delete»
operator
«delete»
:BasicFormula
«preserve»
:QuantifiedFormula
«preserve»
:QuantifiedFormula
«delete»
:BasicFormula
«preserve»
:Formula
«delete»
nested
«delete»
operator
«preserve»
:Quantifier name="FORALL"
24
«preserve»
:Quantifier name="EXISTS"
23
«preserve»
:Operator name="NOT"
22
«create»
quantifier
«delete»
quantifier 19 18 17
20 21
«delete»
args
«delete»
nested
«create»
args
«delete»
args
«create»
nested
«delete»
operator
Figure 4.4:Remove Double Negationoptimization rules.
Example 2: Variability-intensive optimization rules.
Consider a second example inspired by a set of real-life rules for op-timizing and simplifying first-order logic expressions [7], aimed to improve performance of engines that process these expressions, e.g., theorem provers or SAT solvers. Fig. 4.4 shows four transformation rules that simplify first-order logic formulas by removing redundant notsymbols and thus reducing the “depth” of a formula. Again, we present the rules in an integrated form, with the left- and right-hand sides of the transformation being represented in a graph labeled with the actionspreserve,delete, andcreate.
Rule Aremoves a¬∀¬segment of a formula and transforms it into an
∃segment. This is done by removing nodes #2, #4 and their correspond-ing edges, replaccorrespond-ing the quantifier of node #3 to be “exists” (node #7) rather than “forall” (node #8), and connecting the modified quantifier to the enclosing and the enclosed formulas – nodes #1 and #5, respec-tively. Similarly,Rule Bremoves a¬∃¬segment and transforms it into a∀ segment. Rules CandDdiffer fromAandBin the type and adja-cent edges of the topmost enclosing formula (nodes #1,9,17,25): basic vs. quantified. ABasicFormulahas an operator and a set of argument formulas, whereas aQuantifiedFormulahas a quantifier and nests exactly one other formula. Note that there exists a third kind of formula, Predi-cateFormula, that encloses no other formulas.
BasicFormula QuantifiedFormula
Formula
PredicateFormula name: String
Quantifier name: String Operator
name: String
operator quantifier
nested args
Variable name: String
var var
Literal name: String
1..* 1
1..* 1 1
1
Figure 4.5:Meta-model for first-order logic formulas.
Fig. 4.5 provides the meta-model for first-order logic formulas as used by these model transformation rules. Formulas are expressed as a set of atomic formulas – being either named predicate formulas or literals – that are combined through universal and existential quantifiers and Boolean operators. There are four kinds of formulas:
• Literals, being eitherTRUEorFALSE,
• Predicate formulas, comprising a name and a set of variables (e.g.
nameFand variableXconstituting predicate formulaF(X)),
• Basic formulas, linking a set of argument formulas through an operator (such asAND,OR,NOT), and
• Quantified formulas, nesting a formula while binding one of its variables to a quantifier (EXISTSorFORALL).
Fig. 4.6 shows an example first-order logic formulaφ= (¬∀x· ¬F(x))∧ true that can be simplified using one of the rules, namely,Rule A. The formula is represented as a model created using the meta-model shown in Fig. 4.5. The left-hand side of the figure depicts formula-specific elements. The right-hand side presents a library of “generic” reusable
4.2 Overview 79
:Quantifier name="FORALL"
42
:Operator name="NOT"
:BasicFormula33 :Literal
value="TRUE"
39
:QuantifiedFormula35
:BasicFormula36 args
args (:8x.:F(x)) ^ true
:Variable name="x"
38
:PredicateFormula name="F"
37
:Operator name="AND"
40
:Literal
value="FALSE"
44
:Quantifier name="EXISTS"
43
args
nested :BasicFormula34
operator
operator var
args
41
var
operator
quantifier
Figure 4.6:Example first-order logic formulaφ.
«delete»
:BasicFormula
«delete» :BasicFormula
«preserve» :QuantifiedFormula
«preserve» :Operator name="NOT"
«delete»
nested [quantified]
«preserve»
:Formula
A+B+C+D: RemoveRedundantNot
51
«create»
nested [quantified]
«delete»
quantifier [forall]
«create» quantifier [¬forall]
«create» quantifier [forall]
«delete»
quantifier [¬forall]
«delete» operator
48
«create» nested
47
«preserve» [¬quantified] :BasicFormula
45 «preserve» [quantified] :QuantifiedFormula
46
«delete»
args[¬quantified]
49
«delete»
args
50
«delete»
operator
«delete» nested
«delete»
args «preserve»
:Quantifier name="FORALL"
«preserve»
:Quantifier name="EXISTS"
53 52
«create»
args[¬quantified ]
true
Figure 4.7:Variability-basedRemove Double Negationoptimization rule.
first-order logic operators. Elements #1-#8 of Rule A match with the corresponding elements #33–#37, #41, #43, #42. We call this assignment a matchmA. FindingmAtriggers the application ofRule A, producing the formula(∃x·F(x)) ∧ true. Note thatmAis a valid match because PredicateFormula(node #5 in Fig. 4.6) is a sub-type ofFormula.
Fig. 4.7 shows a compactvariability-based rulethat represents all four in-dividual rules in Fig. 4.4. The differences between the classic rules are explicitly captured and represented by variation points. Rule elements areannotatedwithpresence conditions– Boolean formulas over the vari-ation points. In the visual representvari-ation, annotvari-ations are appended in square brackets to the names of their corresponding nodes and edges.
Again, for the simplicity of presentation, we omit the presence condi-tiontrue, e.g., for nodes #2-#8.
In this example, there are two variation points: (1) Theforallvariation point controls the direction of the quantifier inversion. When set to true, it corresponds to the¬∀¬to∃inversion, as in rulesAandC; when set to false, it corresponds to the ¬∃¬ to ∀ inversion, as in B and D. (2) Thequantifiedvariation point controls the enclosing formula and its adjacent edges. When set totrue, it corresponds to a formula of the type QuantifiedFormulawith outgoingnestededges, as inCandD; when set to false, it corresponds to a formula of the typeBasicFormulawith outgoing argsedges, as in rulesAandB. Note that this variation point cannot be captured using node sub-typing, as it affects edges with different types.
The variability model in this example is true since all configurations obtained by binding configuration points totrueorfalseare valid.
A variability-based rule can beconfiguredby setting variation point val-ues and then selecting all elements whose presence conditions eval-uate to true while removing those whose presence conditions eval-uate to false. In our example, configuring the rule with {forall=true;
quantified=false} produces Rule A in Fig. 4.4 while the configuration {forall=false;quantified=true} producesRule D.