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)
 
 
(4 intermediate revisions by the same user not shown)
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 as 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|<br />'''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|<br />'''One rule with variability''']] </li>
 
</ul></div>
 
</ul></div>
  
Line 21: Line 21:
 
The rules induced by the configurations ''{wrapper=true; deprecate=false}'' and ''{wrapper=true; deprecate=true}'' produce the additional variants.
 
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.
 
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.
 +
 +
 +
== Integration with editor ==
 +
 +
A user interface supporting the management of rules with variability is integrated with the default user interface of Henshin.
 +
The main components of this user interface, a graphical editor and its attached ''properties'' view, are shown in the left of the image below.
 +
As custom components, we provide the ''variability'' and ''sanitizing'' views, shown in the right.
 +
The variability view comprises features for the definition and configuration of variability points.
 +
The variant produced from the current configuration is displayed in the editor.
 +
The sanitizing view can be used to sanitize legacy transformations.
 +
 +
<div><ul>
 +
<li style="display: inline-block; margin-bottom: 10px;"> [[File:Henshin_vb_perspective.png|thumb|none|500px|'''Henshin with variability-specific views''']] </li>
 +
</ul></div>
 +
 +
The variability view allows features in a rule to be created and deleted.
 +
To view and edit  variants individually, the user configures the rule by setting the bindings for these features. Three literals are supported: ''true'', ''false'', and
 +
''unbound''.
 +
Per default, each variability point is ''unbound'', yielding the maximal rule, all elements regardless of their annotations.
 +
Configurations are validated against the given variability model, ''deprecate -> wrapper'' in this case.
 +
Invalid configurations and rules lead to error messages being displayed.
 +
 +
To navigate  variants efficiently, frequently used configurations can be saved as favorites using the [[File:star_grey.png|15px]] button in the toolbar.
 +
The star  appears in yellow if a favored configuration is currently active.
 +
Each configuration has a user-specified name.
 +
In the figure to the right the user has created two favorites, ''WrapperWithDeprecate'' and ''WrapperWithoutDeprecate'',
 +
the latter one being active.
 +
Upon selection, the configuration is loaded and shown in the table at the bottom of the view.
 +
 +
A ''view mode'' feature allows to access distinguished variants rapidly.
 +
In the ''maximum rule'' mode,  represented by the [[File:rule_full.png|15px]] icon, all elements included in the rule are shown regardless of the configuration.
 +
In the ''variant mode'' ([[File:rule_configured.png|15px]]), elements absent in the current configuration are concealed.
 +
In the ''base rule'' mode ([[File:rule_base.png|15px]]), elements with a non-empty presence condition are concealed.
 +
 +
To further improve the handling of variability, the view allows the users to choose a ''concealing strategy'', depicted in the figure below.  First, elements can be turned invisible. This avoids a cluttered representation of the rule and lets users focus on the variant at hand.
 +
On the other hand, to allow the comparison of a variant with the full rule, users may choose to have the elements toned down instead.
 +
 +
 +
<div><ul>
 +
<li style="display: inline-block;"> [[File:Vbrule fade.png|thumb|none|300px|<br />'''Conceal by fading''']] </li>
 +
<li style="display: inline-block; width: 20px;"> &nbsp; </li>
 +
<li style="display: inline-block;"> [[File:Vbrule invisible.png|thumb|none|300px|<br />'''Conceal by hiding''']] </li>
 +
</ul></div>
 +
 +
 +
Using the [[File:creation_mode.png|15px]] button, users can select an ''editing mode'' to define which variants are affected by edits to the rule.
 +
The supported options are: all variants, variants included in the selected configuration, or variants associated to the current view mode.
 +
In particular, the editing mode determines which presence condition is assigned during the addition or deletion of elements to a rule.
 +
 +
'''Context menus''': Additional context menu entries allow to manage variability at the level of individual elements.
 +
Multiple nodes, edges and attributes can be selected and moved to a different configuration simultaneously.
 +
 +
 +
== Relevant Literature ==
 +
 +
''A Tool Environment for Managing Families of Model Transformation Rules.'' Daniel Strüber, Stefan Schulz. In: ICGT 2016: International Conference on Graph Transformation. Springer International. pp. 89-101. [https://www.uni-marburg.de/fb12/arbeitsgruppen/swt/forschung/publikationen/2016/strsch16.pdf PDF]
 +
 +
''A Variability-Based Approach to Reusable and Efficient Model Transformations.'' Daniel Strüber, Julia Rubin, Marsha Chechik, Gabriele Taentzer. In: FASE 2015: International Conference on Fundamental Approaches to Software Engineering. Springer. pp. 283-298. [https://www.uni-marburg.de/fb12/arbeitsgruppen/swt/forschung/publikationen/2015/SRCT15.pdf PDF]

Latest revision as of 10:47, 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 as 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.


Integration with editor

A user interface supporting the management of rules with variability is integrated with the default user interface of Henshin. The main components of this user interface, a graphical editor and its attached properties view, are shown in the left of the image below. As custom components, we provide the variability and sanitizing views, shown in the right. The variability view comprises features for the definition and configuration of variability points. The variant produced from the current configuration is displayed in the editor. The sanitizing view can be used to sanitize legacy transformations.

  • Henshin with variability-specific views

The variability view allows features in a rule to be created and deleted. To view and edit variants individually, the user configures the rule by setting the bindings for these features. Three literals are supported: true, false, and unbound. Per default, each variability point is unbound, yielding the maximal rule, all elements regardless of their annotations. Configurations are validated against the given variability model, deprecate -> wrapper in this case. Invalid configurations and rules lead to error messages being displayed.

To navigate variants efficiently, frequently used configurations can be saved as favorites using the Star grey.png button in the toolbar. The star appears in yellow if a favored configuration is currently active. Each configuration has a user-specified name. In the figure to the right the user has created two favorites, WrapperWithDeprecate and WrapperWithoutDeprecate, the latter one being active. Upon selection, the configuration is loaded and shown in the table at the bottom of the view.

A view mode feature allows to access distinguished variants rapidly. In the maximum rule mode, represented by the Rule full.png icon, all elements included in the rule are shown regardless of the configuration. In the variant mode (Rule configured.png), elements absent in the current configuration are concealed. In the base rule mode (Rule base.png), elements with a non-empty presence condition are concealed.

To further improve the handling of variability, the view allows the users to choose a concealing strategy, depicted in the figure below. First, elements can be turned invisible. This avoids a cluttered representation of the rule and lets users focus on the variant at hand. On the other hand, to allow the comparison of a variant with the full rule, users may choose to have the elements toned down instead.



  • Conceal by fading
  •  

  • Conceal by hiding


Using the Creation mode.png button, users can select an editing mode to define which variants are affected by edits to the rule. The supported options are: all variants, variants included in the selected configuration, or variants associated to the current view mode. In particular, the editing mode determines which presence condition is assigned during the addition or deletion of elements to a rule.

Context menus: Additional context menu entries allow to manage variability at the level of individual elements. Multiple nodes, edges and attributes can be selected and moved to a different configuration simultaneously.


Relevant Literature

A Tool Environment for Managing Families of Model Transformation Rules. Daniel Strüber, Stefan Schulz. In: ICGT 2016: International Conference on Graph Transformation. Springer International. pp. 89-101. PDF

A Variability-Based Approach to Reusable and Efficient Model Transformations. Daniel Strüber, Julia Rubin, Marsha Chechik, Gabriele Taentzer. In: FASE 2015: International Conference on Fundamental Approaches to Software Engineering. Springer. pp. 283-298. PDF

Copyright © Eclipse Foundation, Inc. All Rights Reserved.