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.
Difference between revisions of "Henshin/Transformation Meta-Model"
| Line 13: | Line 13: | ||
'''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). | '''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). | ||
| − | |||
=== Rule refinement === | === Rule refinement === | ||
| Line 19: | Line 18: | ||
[[Image:Henshin_Application_Conditions.png|right|550xpx]] | [[Image:Henshin_Application_Conditions.png|right|550xpx]] | ||
| − | '''Application conditions''': Rules may be equipped with application conditions, being graph patterns which restrict the application of rules. They may require the presence of additional elements or relationships not included in the main rule. In this case, they are referred to as | + | '''Application conditions''': Rules may be equipped with application conditions, being graph patterns which restrict the application of rules. They may require the presence of additional elements or relationships not included in the main rule. In this case, they are referred to as ''positive application conditions'' (PACs). They may also forbid the presence of elements or relationships. In this case, they are referred to as ''negative application conditions'' (NACs). 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 condition. |
| + | |||
| + | '''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 rules as ''multi rules''. During execution of a nested rule, the kernel rule will be matched once and used as a starting point to apply the multi rule as often as possible. Multi-node mappings allow to specify identity between kernel and multi rule nodes. | ||
=== Control flow: Units === | === Control flow: Units === | ||
Revision as of 11:13, 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.
Contents
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) graph. 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. The RHS specifies a change on the input model. Nodes and edges occurring in the LHS or RHS only are deleted or created, respectively. Node mappings between LHS and RHS declare identity, i.e., nodes and edges being preserved. Nodes possess attributes. Attribute conditions can be defined whose expressions are evaluated by a JavaScript engine at runtime.
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 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).
Rule refinement
Application conditions: Rules may be equipped with application conditions, being graph patterns which restrict the application of rules. They may require the presence of additional elements or relationships not included in the main rule. In this case, they are referred to as positive application conditions (PACs). They may also forbid the presence of elements or relationships. In this case, they are referred to as negative application conditions (NACs). 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 condition.
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 rules as multi rules. During execution of a nested rule, the kernel rule will be matched once and used as a starting point to apply the multi rule as often as possible. Multi-node mappings allow to specify identity between kernel and multi rule nodes.
Control flow: Units
In Henshin, control flow is specified using units. All other kinds of 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.
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.
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.
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.
Run-time variability: Parametrization
Parameters allow to shape the behavior of units and rules with variable information that is typically not present 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.