Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Henshin/Transformation Meta-Model"
(Created page with "The '''Henshin transformation meta-model''' defines the concepts used for the specification of model transformations in Henshin. Model transformations are defined in '''modul...") |
|||
| Line 6: | Line 6: | ||
'''Rules''' are the basic building blocks of model transformations in Henshin. A rule comprises two '''graphs''', a left-hand side (LHS) and a right-hand side (RHS). LHS and RHS specify model patterns on abstract syntax level. '''Nodes''' correspond to model elements, '''edges''' correspond to references between model elements. The LHS describes a pattern to be matched while the RHS specifies a change on the input model. Nodes and edges occurring in the LHS or RHS only are deleted or created, respectively. Nodes possess '''attributes'''. '''Attribute conditions''' can be defined whose expressions are evaluated by a JavaScript engine at runtime. | '''Rules''' are the basic building blocks of model transformations in Henshin. A rule comprises two '''graphs''', a left-hand side (LHS) and a right-hand side (RHS). LHS and RHS specify model patterns on abstract syntax level. '''Nodes''' correspond to model elements, '''edges''' correspond to references between model elements. The LHS describes a pattern to be matched while the RHS specifies a change on the input model. Nodes and edges occurring in the LHS or RHS only are deleted or created, respectively. Nodes possess '''attributes'''. '''Attribute conditions''' can be defined whose expressions are evaluated by a JavaScript engine at runtime. | ||
| − | + | '''Node mappings''' between LHS and RHS declare identity, i.e., nodes and edges being preserved. | |
'''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 target. It is possible to turn the gluing condition check off 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 connected to the dangling condition: A rule execution may not leave behind dangling edges, being edges with a missing target. It is possible to turn the gluing condition check off using the ''checkDangling'' Boolean flag. | ||
| Line 17: | Line 17: | ||
=== Control flow: Units === | === Control flow: Units === | ||
| − | + | [[Image:Henshin_Transformation_Units.png|right|x340px]] | |
In Henshin, control flow is specified using units. All other kinds of units have a fixed number of inner units, allowing for arbitrary nesting. The following unit types are available: | In Henshin, control flow is specified using units. All other kinds of units have a fixed number of inner units, allowing for arbitrary nesting. The following unit types are available: | ||
Revision as of 06:56, 2 June 2014
The Henshin transformation meta-model defines the concepts used for the specification of model transformations in Henshin.
Model transformations are defined in modules that comprise a set of units, being either transformation rules - atomic units - or composite units that allow to define a control flow.
Basic building blocks: Rules
Rules are the basic building blocks of model transformations in Henshin. A rule comprises two graphs, a left-hand side (LHS) and a right-hand side (RHS). LHS and RHS specify model patterns on abstract syntax level. Nodes correspond to model elements, edges correspond to references between model elements. The LHS describes a pattern to be matched while the RHS specifies a change on the input model. Nodes and edges occurring in the LHS or RHS only are deleted or created, respectively. Nodes possess attributes. Attribute conditions can be defined whose expressions are evaluated by a JavaScript engine at runtime. Node mappings between LHS and RHS declare identity, i.e., nodes and edges being preserved.
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 target. It is possible to turn the gluing condition check off using the checkDangling Boolean flag.
Injective matching: The injectiveMatching flag specifies whether the match-finder may assign two or more LHS nodes to the same model element. Per default, matching is set injective (e.g., it may not).
Application conditions: Rules may be equipped with positive and negative application conditions (PACs and NACs) being graph patterns which restrict the application of rules. NAC and PAC elements are not part of the match. Their true power emerges in combination with propositional operations (AND, OR, NOT) and with nesting even allowing to define conditions over conditions.
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.
Control flow: Units
In Henshin, control flow is specified using units. All other kinds of units have a fixed number of inner units, allowing for arbitrary nesting. The following unit types are available:
Sequential units have an arbitrary number of inner units that are executed in the given order. The Boolean flag strict determines the behavior if one of the inner units cannot be executed: In strict mode, the execution stops, otherwise, the next unit is executed. The Boolean flag rollback determines whether in the case of a stopped execution previous executions shall be reverted.
Priority Units have an arbitrary number of inner units that are checked in the given order for executability. One unit - the first one found to be executable - is executed.
Independent Units have an arbitrary number of inner units that are checked in nondeterministic order for executability. One unit - the first one found to be executable - is executed.
Loop Units have one inner unit. The inner unit is executed as often as it is executable.
Iterated Units have one inner unit. The inner unit is executed as often as specified in the iterations property.
ConditionalUnits have either two or three inner 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 only used for matching.
Run-time variability: Parametrization
Parameters allow to shape the behavior of units and rules with variable information that is typically not available before execution time. Parameters are defined as part of the rule and can then be used in elements of the rule, e.g., as attributes and in attribute conditions. Parameters can be set from the environment using the API or the graphical interpreter wizard. Parameters values set from the environment are used during matching. In turn, parameters that were not 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.
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.