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/Transformation Meta-Model"

(Advanced concepts: Application conditions and rule nesting)
(40 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
The '''Henshin transformation meta-model''' defines the concepts used for the specification of model transformations in Henshin.
 
The '''Henshin transformation meta-model''' defines the concepts used for the specification of model transformations in Henshin.
  
Model transformations are specified in terms of '''modules''' that comprise a set of units, being either transformation rules - atomic units - or composite units that allow to define a control flow.  
+
A complete specification is encapsulated by a '''module'''. A module is a container for a set of units. There are two kinds of units: rules and composite units. Rule specify atomic building blocks for transformations. Composite units enable the orchestration of multiple rules in a control flow.
 +
 
  
 
=== Basic building blocks: Rules ===
 
=== Basic building blocks: Rules ===
 
[[Image:Henshin Transformatin Modules.png|right|550xpx]]
 
[[Image:Henshin Transformatin Modules.png|right|550xpx]]
  
'''Rules''' are the basic building blocks for model transformations. A rule comprises two graphs, a left-hand side (LHS) and a right-hand side (RHS) graph. The LHS describes a pattern to be matched in the input model. The RHS specifies a change on the input model. LHS and RHS specify model patterns on the abstract syntax level:  Nodes represent model elements, edges represent references between model elements. Nodes and edges occurring in the LHS or RHS only are deleted or created, respectively. Node mappings between LHS and RHS declare identity, that is, nodes and edges being preserved. Nodes possess attributes representing the attributes of the respective model elements. Attribute conditions can be defined whose expressions are evaluated by a JavaScript engine at runtime.
+
'''Rules''' are the basic building blocks for model transformations. A rule comprises two graphs, a left-hand side (LHS) and a right-hand side (RHS) graph. The LHS describes a pattern to be matched in the input model. The RHS specifies a change on the input model. LHS and RHS specify model patterns on the abstract syntax level:  Nodes represent model elements, edges represent references between model elements. Nodes and edges occurring in the LHS or RHS only are deleted or created, respectively. Node mappings between LHS and RHS declare identity, that is, nodes and edges being preserved. Nodes possess attributes representing the attributes of the respective model elements. Their values may either be literals - e.g. 0 or "Hello" -, parameters, or JavaScript expressions, being evaluated by a JavaScript engine at runtime.  Nodes, edges and attributes have a type, being a class, reference or attribute in an EMF model. Attribute conditions can impose additional boolean conditions that are bound to the rule.
  
For conciseness, the [[Henshin Graphical Editor|graphical editor]] merges LHS and RHS into an integrated representation: Nodes and edges are annotated with a <span style="color:gray">&laquo;preserve&raquo;</span>, <span style="color:green">&laquo;create&raquo;</span>, or  <span style="color:red">&laquo;delete&raquo;</span> tag depending on their containment in LHS or RHS graphs.  
+
For conciseness, the [[Henshin/Graphical Editor|graphical editor]] merges LHS and RHS into an integrated representation: Nodes and edges are annotated with a <span style="color:gray">&laquo;preserve&raquo;</span>, <span style="color:green">&laquo;create&raquo;</span>, or  <span style="color:red">&laquo;delete&raquo;</span> tag depending on their containment in LHS or RHS graphs.  
  
'''Dangling condition''': A common beginner-level problem is that rules are deemed unexecutable by the Henshin interpreter despite looking correct at the surface. This behavior is often connected to the dangling condition: A rule execution may not leave behind dangling edges, being edges with a missing source or target. It is possible to turn off the gluing condition check using the ''checkDangling'' Boolean flag.
+
'''Dangling condition''': A common beginner-level problem is that rules are deemed unexecutable by the Henshin interpreter despite looking correct at the surface. This behavior is often related to the dangling condition: A rule execution may not leave behind dangling edges, being edges with a missing source or target. It is possible to turn off the gluing condition check using the ''checkDangling'' Boolean flag. Setting the flag to false will lead to the interpreter deleting the dangling edges.
  
 
'''Injective matching''': The ''injectiveMatching'' flag specifies whether the match-finder is supposed to find matches that assign two or more LHS nodes to the same model element. Per default, matching is set injective (that is, not supposed to assign nodes to the same model element).
 
'''Injective matching''': The ''injectiveMatching'' flag specifies whether the match-finder is supposed to find matches that assign two or more LHS nodes to the same model element. Per default, matching is set injective (that is, not supposed to assign nodes to the same model element).
 +
 +
'''Edges''': A few remarks on edges:  First, rules do not maintain mappings of edges between different rule graphs: Edges are considered identical if their types and their source and target nodes are identical. Second, if a reference has an ''EOpposite'' reference, it is not required to specify an edge for the opposite reference: By its default behavior, EMF ensures that changes involving one of the EOpposites will be propagated onto the other. Third, in ''ordered'' references, the positions of list entries can be modified using the ''index'' attribute. An example is shown in [http://www.ckrause.org/2013/05/henshin-098-working-with-lists.html this article].
  
 
=== Advanced concepts: Application conditions and rule nesting ===
 
=== Advanced concepts: Application conditions and rule nesting ===
Line 18: Line 21:
 
[[Image:Henshin_Application_Conditions.png|right|550xpx]]
 
[[Image:Henshin_Application_Conditions.png|right|550xpx]]
  
'''Application conditions''' are graph patterns that restrict the LHS of a given rule. They may require the presence of additional elements or relationships not included in the LHS. In this case, they are referred to as ''positive application conditions'' (PACs). Furthermore, they may forbid the presence of elements or relationships. In this case, they are referred to as ''negative application conditions'' (NACs). Consequently, the [[Henshin Graphical Editor|graphical editor]] displays PAC elements with a <span style="color:brown">&laquo;require&raquo;</span> and NAC elements with a <span style="color:blue">&laquo;forbid&raquo;</span> tag. Application conditions can be arbitarily nested using the propositional operators ''Or'', ''And'', ''Xor'', and  ''Not''. Whether an application condition graph represents a NAC or a PAC is determined by its containment in a ''Not'' formula.<br>
+
'''Application conditions''' are graph patterns that restrict the LHS of a given rule. They may require the presence of additional elements or relationships not included in the LHS. In this case, they are referred to as ''positive application conditions'' (PACs). Furthermore, they may forbid the presence of elements or relationships. In this case, they are referred to as ''negative application conditions'' (NACs). Consequently, the [[Henshin/Graphical Editor|graphical editor]] displays PAC elements with a <span style="color:brown">&laquo;require&raquo;</span> and NAC elements with a <span style="color:blue">&laquo;forbid&raquo;</span> tag. Application conditions can be arbitarily nested using the propositional operators ''Or'', ''And'', ''Xor'', and  ''Not''. Whether an application condition graph represents a NAC or a PAC is determined by whether it is contained in a ''Not'' formula.<br>
Since both LHS and PACs specify graph patterns required to be present, you may ask now if PACs just add a syntactic sugar on top of the LHS. This is not the case: PACs (and NACs) are used to constrain the matching of the LHS. However, they are not part of the computed match. A match only contains mappings for LHS nodes. This distinction is particularly relevant in scenarios where you want to apply a rule ''for each calculated match'' (also confer rule-nesting). For an example, please refer to [https://www.eclipse.org/henshin/examples.php?example=giraph-movies Movies].<br>
+
Since LHS and PACs specify graph patterns required to be present, you may ask now if PACs just add a syntactic sugar on top of the LHS. This is not the case: PACs (and NACs) are used to constrain the matching of the LHS. However, they are not part of the computed match. A match only contains mappings for LHS nodes. This is particularly important in scenarios where you want to apply a rule for each computed match (compare ''rule-nesting'', described below). For an example, please refer to [https://www.eclipse.org/henshin/examples.php?example=giraph-movies Movies].<br>
 
Identity of nodes in different graphs, including LHS, PAC, and NAC graphs, can be specified using mappings.
 
Identity of nodes in different graphs, including LHS, PAC, and NAC graphs, can be specified using mappings.
The graphical editor maintains these mappings implicitly: For each LHS node connected to a PAC or NAC node, it creates a mapped node inside the NAC or PAC.<br>
+
The graphical editor maintains these mappings implicitly: For each LHS node, it creates a mapped node inside the NAC or PAC.<br>
 
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=bank Bank Accounts], [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB], [https://www.eclipse.org/henshin/examples.php?example=java2statemachine Java2StateMachine],  [https://www.eclipse.org/henshin/examples.php?example=ecore2genmodel Ecore2Genmodel], [https://www.eclipse.org/henshin/examples.php?example=combpattern Grid & Comb Pattern], [https://www.eclipse.org/henshin/examples.php?example=gossipinggirls Gossiping Girls], [https://www.eclipse.org/henshin/examples.php?example=probbroadcast Probabilistic Broadcast], [https://www.eclipse.org/henshin/examples.php?example=giraph-movies Movies]
 
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=bank Bank Accounts], [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB], [https://www.eclipse.org/henshin/examples.php?example=java2statemachine Java2StateMachine],  [https://www.eclipse.org/henshin/examples.php?example=ecore2genmodel Ecore2Genmodel], [https://www.eclipse.org/henshin/examples.php?example=combpattern Grid & Comb Pattern], [https://www.eclipse.org/henshin/examples.php?example=gossipinggirls Gossiping Girls], [https://www.eclipse.org/henshin/examples.php?example=probbroadcast Probabilistic Broadcast], [https://www.eclipse.org/henshin/examples.php?example=giraph-movies Movies]
  
'''Rule-nesting''' is a powerful concept providing a for-each operator for rules. In nested rules, the outer rule is referred to as ''kernel rule'' and the inner rule as ''multi rule''.  During execution of a nested rule, the kernel rule is matched and executed once. Afterards, the match is used as a starting point to match the multi-rule as often as possible and execute it for each match. Multi mappings allow to specify identity between kernel and multi-rule nodes. In the [[Henshin Graphical Editor|graphical editor]], multi-rule nodes are indicated by a layered representation and an asterisk (*). Multiple layers of rule-nesting are allowed. The graphical editor shows the path constituted by the nested rules in the title bar of the respective nodes. An extensive example for multiple-layer rule-nesting is found in [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB].<br>
+
'''Rule-nesting''' is a powerful concept providing a for-each operator for rules. In nested rules, the outer rule is referred to as ''kernel rule'' and the inner rule as ''multi rule''.  During execution of a nested rule, the kernel rule is matched and executed once. Afterwards, the match is used as a starting point to match the multi-rule as often as possible and execute it for each match. Multi mappings allow to specify identity between kernel and multi-rule nodes. In the [[Henshin/Graphical Editor|graphical editor]], multi-rule nodes are indicated by a layered representation and an asterisk (*). Multiple layers of rule-nesting are allowed. The graphical editor shows the path constituted by the nested rules in the title bar of the respective nodes. An extensive example for multiple-layer rule-nesting is found in [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB].<br>
 
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=bank Bank Accounts], [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB], [https://www.eclipse.org/henshin/examples.php?example=gossipinggirls Gossiping Girls], [https://www.eclipse.org/henshin/examples.php?example=probbroadcast Probabilistic Broadcast]<br >
 
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=bank Bank Accounts], [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB], [https://www.eclipse.org/henshin/examples.php?example=gossipinggirls Gossiping Girls], [https://www.eclipse.org/henshin/examples.php?example=probbroadcast Probabilistic Broadcast]<br >
 
''Further Reading: Biermann, Ermel, Taentzer. "Formal foundation of consistent EMF model transformations by algebraic graph transformation." Software & Systems Modeling 11.2 (2012): 227-250. Chapter 5. [http://link.springer.com/article/10.1007/s10270-011-0199-7 SpringerLink]''
 
''Further Reading: Biermann, Ermel, Taentzer. "Formal foundation of consistent EMF model transformations by algebraic graph transformation." Software & Systems Modeling 11.2 (2012): 227-250. Chapter 5. [http://link.springer.com/article/10.1007/s10270-011-0199-7 SpringerLink]''
Line 30: Line 33:
 
=== Control flow: Units ===
 
=== Control flow: Units ===
 
[[Image:Henshin_Transformation_Units.png|right|550xpx]]
 
[[Image:Henshin_Transformation_Units.png|right|550xpx]]
 +
 +
''Main article (with examples): [[Henshin/Units|Units]]''
  
 
In Henshin, control flow is specified using units. Units have a fixed number of sub-units, allowing for arbitrary nesting. The following unit types are available:
 
In Henshin, control flow is specified using units. Units have a fixed number of sub-units, allowing for arbitrary nesting. The following unit types are available:
  
'''Sequential units''' have an arbitrary number of sub-units that are executed in the given order. The Boolean flag ''strict'' determines the behavior if one of the sub-units cannot be executed: In strict mode, the execution stops, otherwise, the next sub-unit is executed. The Boolean flag ''rollback'' determines whether in the case of a stopped execution previous executions are reverted. <br>
+
'''Loop Units''' have one sub-unit. The sub-unit is executed as often as it is executable.
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB], [https://www.eclipse.org/henshin/examples.php?example=java2statemachine Java2StateMachine],  [https://www.eclipse.org/henshin/examples.php?example=ecore2genmodel Ecore2Genmodel], [https://www.eclipse.org/henshin/examples.php?example=combpattern Grid & Comb Pattern], [https://www.eclipse.org/henshin/examples.php?example=giraph-movies Movies]
+
 
 +
'''Iterated Units''' have one sub-unit. The sub-unit is executed as often as specified in the ''iterations'' property. The Boolean flag ''strict'' determines the behavior if not all of the specified iterations can be executed: In strict mode the execution is considered unsuccessful in this case, otherwise, the execution is considered successful if at least one iteration has been executed successfully. The Boolean flag ''rollback'' determines whether, in case of an unsuccessful unit execution, successful iterations are reverted.
 +
 
 +
'''ConditionalUnits''' have either two or three sub-units: ''if'', ''then'', (and ''else''). If a match for the ''if'' unit can be found, the ''then'' unit is executed. Otherwise, if present, the ''else'' unit is executed. Note that any changes specified in the if unit are performed; if you don't want to specify changes, you can use a rule with ''preserve'' nodes only.
 +
 
 +
'''Sequential units''' have an arbitrary number of sub-units that are executed in the given order. The Boolean flag ''strict'' determines the behavior if one of the sub-units cannot be executed: In strict mode, the execution stops, otherwise, the next sub-unit is executed. The Boolean flag ''rollback'' determines whether in the case of a stopped execution previous executions are reverted. Stopped executions are always considered unsuccessful. Otherwise, executions are considered successful if at least one sub-unit has been executed successfully, or if the unit contains no sub-units.
 +
 
 +
'''Priority Units''' have an arbitrary number of sub-units that are checked in the given order for executability. One sub-unit - the first one found to be executable - is executed.
 +
 
 +
'''Independent Units''' have an arbitrary number of sub-units that are checked in nondeterministic order for executability. One sub-unit - the first one found to be executable - is executed.
 +
 
 +
=== Execution-time variability: Parameters ===
  
'''Priority Units''' have an arbitrary number of sub-units that are checked in the given order for executability. One sub-unit - the first one found to be executable - is executed. <br>
+
''Main article (with examples): [[Henshin/Parameters|Parameters]]''
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=java2statemachine Java2StateMachine]
+
  
'''Independent Units''' have an arbitrary number of sub-units that are checked in nondeterministic order for executability. One sub-unit - the first one found to be executable - is executed. <br>
+
[[Image:Henshin_Parameters.png|right|370xpx]]
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=ecore2genmodel Ecore2Genmodel]
+
  
'''Loop Units''' have one sub-unit. The sub-unit is executed as often as it is executable.<br>
+
'''Parameters''' allow to shape the behavior of units, including rules, with variable information. A unit can have an arbitary number of parameters. Parameters have a name, a description, a kind, and, optionally, a type. The kind specifies the time when the parameter is bound to a concrete value, and whether the parameter is intended to be accessed after the unit has been applied. There are four parameter kinds (''in'', ''out'', ''inout'', ''var'') and an additional legacy parameter kind (''unknown''):
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=java2statemachine Java2StateMachine], [https://www.eclipse.org/henshin/examples.php?example=ecore2genmodel Ecore2Genmodel]
+
  
'''Iterated Units''' have one sub-unit. The sub-unit is executed as often as specified in the ''iterations'' property.<br>
+
* ''in'' parameters need to be set externally before the unit application; they cannot be read once the unit has been applied,
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=combpattern Grid & Comb Pattern]
+
* ''out'' parameters are set automatically during the unit application; they are intended to be read once the unit has been applied,
 +
* ''inout'' parameters need to be set externally before the unit application; they are intended to be read once the unit has been applied,
 +
* ''var'' parameters (variables) are set automatically during the unit application; they cannot be read once the unit has been applied,
 +
* ''unknown'' parameters can either be set externally before or automatically during the unit application; they may be read once the unit has been applied.
  
'''ConditionalUnits''' have either two or three sub-units: ''if'', ''then'', (and ''else''). If a match for the ''if'' unit can be found, the ''then'' unit is executed. Otherwise, if present, the ''else'' unit is executed. Note that any changes specified in the if unit are ignored; it is used for matching only.<br>
+
The type of a parameter is an arbitrary ''EClassifier'', that is, either an ''EDataType'' such as ''EString'', ''EInt'' or ''EBoolean'', or any ''EClass''.
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=java2statemachine Java2StateMachine]
+
  
=== Execution-time variability: Parametrization ===
+
Declared parameters are ''used'' inside the unit by referencing them by name. Parameters can be used at any place in the unit where a string value is expected: in rules, this is the case for node names, attribute values, edge indices, and attribute conditions. In iterated units, this is the case for the ''iterations'' condition.
  
[[Image:Henshin_Parameters.png|right|300xpx]]
+
[[Image:Henshin_Annotations.png|right|310xpx]]
  
'''Parameters''' allow to shape the behavior of units and rules with variable information that is typically not present before execution time. Parameters are defined in the parameter list of a unit. Once defined, they can be accessed by properties inside the unit - for instance, inside the ''iterations'' condition, attribute values, or attribute conditions. Parameters are accessed by name reference in String values. In the [[Henshin Graphical Editor|graphical editor]], the parameter list is shown and edited in the title bar of a unit, following in brackets after the unit name.
+
=== Adding meta-information: Annotations ===
  
At execution time, the variable information is passed in by setting the parameters. Parameters can be set externally using the API or the graphical interpreter wizard. Parameters values that have been set externally are used during matching. In turn, parameters not set externally before matching are set by the matchfinder to the values found in the respective objects. This can be used to propagate values between LHS and RHS elements.  <br>
+
'''Annotations''' are a mechanism for supporting non-intrusive extensions of the Henshin language: Each model element from a Henshin module can be annotated with Annotations. To this end, each metaclass transitively inherits from a metaclass ''Model Element'', which has an arbitrary number of annotations. An annotation has a key and a value, both being strings.
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=bank Bank Accounts], [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB], [https://www.eclipse.org/henshin/examples.php?example=ecore2genmodel Ecore2Genmodel], [https://www.eclipse.org/henshin/examples.php?example=combpattern Grid & Comb Pattern], [https://www.eclipse.org/henshin/examples.php?example=gossipinggirls Gossiping Girls], [https://www.eclipse.org/henshin/examples.php?example=probbroadcast Probabilistic Broadcast]
+
  
'''Parameter mappings''': In order to pass parameter values from outer to inner units, it is required to define parameter mappings. A parameter mapping assigns a source parameter to a target parameter. <br>
+
''Example:'' In Henshin's [[Henshin/Variant Management|variant management]] feature, variant management information is added to rules and rule elements via annotations.
''Examples:'' [https://www.eclipse.org/henshin/examples.php?example=ecore2rdb Ecore2RDB], [https://www.eclipse.org/henshin/examples.php?example=ecore2genmodel Ecore2Genmodel], [https://www.eclipse.org/henshin/examples.php?example=combpattern Grid & Comb Pattern]
+
  
[[Category:Henshin]]
+
[[Category:Henshin]][[Category:Modeling]]

Revision as of 08:52, 10 January 2020

The Henshin transformation meta-model defines the concepts used for the specification of model transformations in Henshin.

A complete specification is encapsulated by a module. A module is a container for a set of units. There are two kinds of units: rules and composite units. Rule specify atomic building blocks for transformations. Composite units enable the orchestration of multiple rules in a control flow.


Basic building blocks: Rules

Henshin Transformation Modules.png

Rules are the basic building blocks for model transformations. A rule comprises two graphs, a left-hand side (LHS) and a right-hand side (RHS) graph. The LHS describes a pattern to be matched in the input model. The RHS specifies a change on the input model. LHS and RHS specify model patterns on the abstract syntax level: Nodes represent model elements, edges represent references between model elements. Nodes and edges occurring in the LHS or RHS only are deleted or created, respectively. Node mappings between LHS and RHS declare identity, that is, nodes and edges being preserved. Nodes possess attributes representing the attributes of the respective model elements. Their values may either be literals - e.g. 0 or "Hello" -, parameters, or JavaScript expressions, being evaluated by a JavaScript engine at runtime. Nodes, edges and attributes have a type, being a class, reference or attribute in an EMF model. Attribute conditions can impose additional boolean conditions that are bound to the rule.

For conciseness, the graphical editor merges LHS and RHS into an integrated representation: Nodes and edges are annotated with a «preserve», «create», or «delete» tag depending on their containment in LHS or RHS graphs.

Dangling condition: A common beginner-level problem is that rules are deemed unexecutable by the Henshin interpreter despite looking correct at the surface. This behavior is often related to the dangling condition: A rule execution may not leave behind dangling edges, being edges with a missing source or target. It is possible to turn off the gluing condition check using the checkDangling Boolean flag. Setting the flag to false will lead to the interpreter deleting the dangling edges.

Injective matching: The injectiveMatching flag specifies whether the match-finder is supposed to find matches that assign two or more LHS nodes to the same model element. Per default, matching is set injective (that is, not supposed to assign nodes to the same model element).

Edges: A few remarks on edges: First, rules do not maintain mappings of edges between different rule graphs: Edges are considered identical if their types and their source and target nodes are identical. Second, if a reference has an EOpposite reference, it is not required to specify an edge for the opposite reference: By its default behavior, EMF ensures that changes involving one of the EOpposites will be propagated onto the other. Third, in ordered references, the positions of list entries can be modified using the index attribute. An example is shown in this article.

Advanced concepts: Application conditions and rule nesting

Henshin Application Conditions.png

Application conditions are graph patterns that restrict the LHS of a given rule. They may require the presence of additional elements or relationships not included in the LHS. In this case, they are referred to as positive application conditions (PACs). Furthermore, they may forbid the presence of elements or relationships. In this case, they are referred to as negative application conditions (NACs). Consequently, the graphical editor displays PAC elements with a «require» and NAC elements with a «forbid» tag. Application conditions can be arbitarily nested using the propositional operators Or, And, Xor, and Not. Whether an application condition graph represents a NAC or a PAC is determined by whether it is contained in a Not formula.
Since LHS and PACs specify graph patterns required to be present, you may ask now if PACs just add a syntactic sugar on top of the LHS. This is not the case: PACs (and NACs) are used to constrain the matching of the LHS. However, they are not part of the computed match. A match only contains mappings for LHS nodes. This is particularly important in scenarios where you want to apply a rule for each computed match (compare rule-nesting, described below). For an example, please refer to Movies.
Identity of nodes in different graphs, including LHS, PAC, and NAC graphs, can be specified using mappings. The graphical editor maintains these mappings implicitly: For each LHS node, it creates a mapped node inside the NAC or PAC.
Examples: Bank Accounts, Ecore2RDB, Java2StateMachine, Ecore2Genmodel, Grid & Comb Pattern, Gossiping Girls, Probabilistic Broadcast, Movies

Rule-nesting is a powerful concept providing a for-each operator for rules. In nested rules, the outer rule is referred to as kernel rule and the inner rule as multi rule. During execution of a nested rule, the kernel rule is matched and executed once. Afterwards, the match is used as a starting point to match the multi-rule as often as possible and execute it for each match. Multi mappings allow to specify identity between kernel and multi-rule nodes. In the graphical editor, multi-rule nodes are indicated by a layered representation and an asterisk (*). Multiple layers of rule-nesting are allowed. The graphical editor shows the path constituted by the nested rules in the title bar of the respective nodes. An extensive example for multiple-layer rule-nesting is found in Ecore2RDB.
Examples: Bank Accounts, Ecore2RDB, Gossiping Girls, Probabilistic Broadcast
Further Reading: Biermann, Ermel, Taentzer. "Formal foundation of consistent EMF model transformations by algebraic graph transformation." Software & Systems Modeling 11.2 (2012): 227-250. Chapter 5. SpringerLink

Control flow: Units

Henshin Transformation Units.png

Main article (with examples): Units

In Henshin, control flow is specified using units. Units have a fixed number of sub-units, allowing for arbitrary nesting. The following unit types are available:

Loop Units have one sub-unit. The sub-unit is executed as often as it is executable.

Iterated Units have one sub-unit. The sub-unit is executed as often as specified in the iterations property. The Boolean flag strict determines the behavior if not all of the specified iterations can be executed: In strict mode the execution is considered unsuccessful in this case, otherwise, the execution is considered successful if at least one iteration has been executed successfully. The Boolean flag rollback determines whether, in case of an unsuccessful unit execution, successful iterations are reverted.

ConditionalUnits have either two or three sub-units: if, then, (and else). If a match for the if unit can be found, the then unit is executed. Otherwise, if present, the else unit is executed. Note that any changes specified in the if unit are performed; if you don't want to specify changes, you can use a rule with preserve nodes only.

Sequential units have an arbitrary number of sub-units that are executed in the given order. The Boolean flag strict determines the behavior if one of the sub-units cannot be executed: In strict mode, the execution stops, otherwise, the next sub-unit is executed. The Boolean flag rollback determines whether in the case of a stopped execution previous executions are reverted. Stopped executions are always considered unsuccessful. Otherwise, executions are considered successful if at least one sub-unit has been executed successfully, or if the unit contains no sub-units.

Priority Units have an arbitrary number of sub-units that are checked in the given order for executability. One sub-unit - the first one found to be executable - is executed.

Independent Units have an arbitrary number of sub-units that are checked in nondeterministic order for executability. One sub-unit - the first one found to be executable - is executed.

Execution-time variability: Parameters

Main article (with examples): Parameters

Henshin Parameters.png

Parameters allow to shape the behavior of units, including rules, with variable information. A unit can have an arbitary number of parameters. Parameters have a name, a description, a kind, and, optionally, a type. The kind specifies the time when the parameter is bound to a concrete value, and whether the parameter is intended to be accessed after the unit has been applied. There are four parameter kinds (in, out, inout, var) and an additional legacy parameter kind (unknown):

  • in parameters need to be set externally before the unit application; they cannot be read once the unit has been applied,
  • out parameters are set automatically during the unit application; they are intended to be read once the unit has been applied,
  • inout parameters need to be set externally before the unit application; they are intended to be read once the unit has been applied,
  • var parameters (variables) are set automatically during the unit application; they cannot be read once the unit has been applied,
  • unknown parameters can either be set externally before or automatically during the unit application; they may be read once the unit has been applied.

The type of a parameter is an arbitrary EClassifier, that is, either an EDataType such as EString, EInt or EBoolean, or any EClass.

Declared parameters are used inside the unit by referencing them by name. Parameters can be used at any place in the unit where a string value is expected: in rules, this is the case for node names, attribute values, edge indices, and attribute conditions. In iterated units, this is the case for the iterations condition.

Henshin Annotations.png

Adding meta-information: Annotations

Annotations are a mechanism for supporting non-intrusive extensions of the Henshin language: Each model element from a Henshin module can be annotated with Annotations. To this end, each metaclass transitively inherits from a metaclass Model Element, which has an arbitrary number of annotations. An annotation has a key and a value, both being strings.

Example: In Henshin's variant management feature, variant management information is added to rules and rule elements via annotations.

Back to the top