Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Henshin/Variability"

(Created page)
 
Line 1: Line 1:
'''Variability''' in Henshin rules allows to express families of rules that are substantially similar to each other in a compact representation.
+
Henshin's '''Variability''' concept allows to express families of rules that are substantially similar to each other in a compact representation.
 
This compact representation enables the convenient editing of multiple rule variants at once, as well as their efficient execution.
 
This compact representation enables the convenient editing of multiple rule variants at once, as well as their efficient execution.
  
 
== Example ==
 
== Example ==
Consider a family of three refactoringrules.
+
Consider a family of three refactoring rules.
The rules, shown in the left image below, express variants of the \textit{move method} refactoring for class models. The first rule specifies the relocation of a method between two classes.
+
The rules, shown in the left image below, express variants of the ''move method'' refactoring for class models. The first rule specifies the relocation of a method between two classes.
 
The second one additionally creates a wrapper method of the same name in the~source class.
 
The second one additionally creates a wrapper method of the same name in the~source class.
The third one adds an annotation to mark the wrapper method as~deprecated.
+
The third one adds an annotation to mark the wrapper method a ~deprecated.
  
 
<div><ul>  
 
<div><ul>  
<li style="display: inline-block;"> [[File:Henshin_vb_exampleClassic.png|thumb|none|450px|'''Three similar rules''']] </li>
+
<li style="display: inline-block;"> [[File:Henshin_vb_exampleClassic.png|thumb|none|500px|'''Three similar rules''']] </li>
 
<li style="display: inline-block; width: 20px;"> &nbsp; </li>
 
<li style="display: inline-block; width: 20px;"> &nbsp; </li>
<li style="display: inline-block;"> [[File:Henshin_vb_exampleCompact.png|thumb|none|400px|'''One rule with variability''']] </li>
+
<li style="display: inline-block;"> [[File:Henshin_vb_exampleCompact.png|thumb|none|350px|'''One rule with variability''']] </li>
 
</ul></div>
 
</ul></div>
  

Revision as of 09:17, 27 September 2019

Henshin's Variability concept allows to express families of rules that are substantially similar to each other in a compact representation. This compact representation enables the convenient editing of multiple rule variants at once, as well as their efficient execution.

Example

Consider a family of three refactoring rules. The rules, shown in the left image below, express variants of the move method refactoring for class models. The first rule specifies the relocation of a method between two classes. The second one additionally creates a wrapper method of the same name in the~source class. The third one adds an annotation to mark the wrapper method a ~deprecated.

  • Three similar rules
  •  
  • One rule with variability


These three rule variants can be expressed using one rule with variability, shown in the right figure. Several elements are annotated with presence conditions over the features wrapper and deprecate. The variants are obtained by configuring the rule, i.e., binding the features to true or false and removing elements whose presence condition evaluates to false. Configuration {wrapper=false; deprecate=false} yields the base rule, a rule isomorphic to rule moveMethod in the Figure above. The rules induced by the configurations {wrapper=true; deprecate=false} and {wrapper=true; deprecate=true} produce the additional variants. To avoid the illegal configuration {wrapper=false; deprecate=true}, the rule has a constraint called feature model, shown in the title bar, requiring wrapper to be true if deprecate is true.

Back to the top