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/Graphical Editor"

(Limitations)
 
(15 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Model transformations in Henshin are defined using matched transformation rules. There are currently two editors available for rules:
+
The '''graphical Henshin editor''' allows to specify transformation rules and transformation units as defined by the [[Henshin/Transformation Meta-Model|transformation meta-model]] in an intuitive and compact way. This article describes the basic usage of the graphical editor.
* a tree-based editor (EMF),
+
* an integrated graphical editor (GMF),
+
* a multi-view graphical editor (GEF).
+
The screenshot below shows the tree-based and the integrated graphical editor. They are both part of the Henshin SDK. The multi-view graphical editor is currently not delivered as part of the Henshin SDK, but it can be obtained from this [http://tfs.cs.tu-berlin.de/henshin/ website].
+
  
[[Image:Henshin_example_transformation_rule.png|400px|Henshin transformation rule]]
+
== Creating a Henshin Diagram ==
  
 +
If you want to create a new transformation from scratch using the graphical editor, simply open the ''New...'' wizard and select ''Henshin -> Henshin Diagram'' and follow the wizard. The wizard will create two files: ''filename.henshin'' and ''filename.henshin_diagram'', where you choose ''filename''. The ''*.henshin'' file contains the actual transformation, whereas the ''*.henshin_diagram'' only stores diagram information. You can also use the tree-based editor to edit the Henshin file directly. To use the graphical editor, you need to oben the Henshin diagram file.
 +
 +
If you already have a transformation in a ''*.henshin'' file and you want to create a diagram for it, do a right-click on the Henshin file and select ''Initialize henshin_diagram file...''. This will create and open the diagram file for you.
  
 
== Importing Models ==
 
== Importing Models ==
  
To define a transformation in either of the editors, you need to import EMF models first. This can be done using an action in the context menu of the tree-based and the graphical editor.In the graphical editor, all classes automatically appear in the palette on the right.
+
To define a transformation, you first need to import some EMF models. This can be done using an action in the context menu of the graphical editor, as shown below. When you have successfully imported a new package, all its classes automatically appear in the palette on the right-hand side of the graphical editor.
 +
 
 +
[[Image:Henshin-import-menu.png|Henshin Import Menu]]
 +
 
 +
 
 +
== Editing Transformation Rules ==
 +
 
 +
[[Image:Henshin-gmf-example-rule.png|right|Example Transformation Rule]]
  
== Tree-based Editor ==
+
The graphical editor offers an intuitive way of representing rules. In Henshin, objects are referred to as ''nodes'' and links between objects as ''edges''. A collection of nodes and edges forms a graph.
  
Henshin transformation rules mainly consists of two Graph objects, commonly referred to as LHS and RHS (left- and right-hand side), and mappings between nodes from the LHS and the RHS. The LHS is the graph pattern matched by the rule. The RHS describes the action of the rule, e.g. whether objects or links should be deleted. The mappings from the LHS to the RHS encode which objects should be preserved by the rule.
+
The control flow of an arbitrary number of rules is specified using [[Henshin/Units|units]].
  
== Graphical Editor ==
+
=== Actions ===
  
The graphical editor offers a more intuitive way of representing rules. Essentially, elements in a rule are annotated with actions such as <<create>>, <<delete>>, <<preserve>> and <<forbid>>. A screenshot of a simple, but not very meaningful, transformation rule in both editors is shown above. Supported element actions are:
+
In the graphical editor, a rule are depicted and edited as a '''single''' graph. To distinguish between node/edges which should be matched, deleted, created etc. by the rule, stereotypes are used. We refer to the stereotypes as ''actions''. Currently, the following actions are supported for nodes / edges / attributes:
* '''<<create>>''' a node or an edge, or set an attribute
+
<span style="color:gray">&laquo;preserve&raquo;</span>,
* '''<<delete>>''' a node or an edge
+
<span style="color:green">&laquo;create&raquo;</span>,
* '''<<forbid>>''' a node or an edge or a particular attribute value. Forbid actions can be parametrized to distinguish multiple ''negative application conditions'' (NACs). This essentially corresponds to logical AND vs. OR (more generally: first-order logic formulas over graph patterns). For instance, if there are two elements, one with the action <<forbid:1>> and the other one with <<forbid:2>>, then either of the two patterns must not be found. If both elements have the same (or no) forbid parameter, then the two elements must not be found together.
+
<span style="color:red">&laquo;delete&raquo;</span>,
 +
<span style="color:blue">&laquo;forbid&raquo;</span> and
 +
<span style="color:brown">&laquo;require&raquo;</span>.
 +
To change the action for an element in the rule, select the action label and use the keyboard to type the action (you don't need to type the surrounding &laquo;...&raquo;).
  
=== Transparent Container Objects ===
+
The actions <span style="color:blue">&laquo;forbid&raquo;</span> and <span style="color:brown">&laquo;require&raquo;</span> play a special role, as they are used respectively to specify Negative Application Conditions (NACs) and Positive Application Conditions (PACs). The two actions can be also parameterized to distinguish multiple NACs/PACs. For example, if there are two elements, one with the action <span style="color:blue">&laquo;forbid#1&raquo;</span> and the other one with <span style="color:blue">&laquo;forbid#2&raquo;</span>, then neither of the two objects must be present. If both elements have the same (or no) forbid parameter, then the two elements must not be found '''together'''. It works in the same way for <span style="color:brown">&laquo;require&raquo;</span>.
  
The graphical editor moreover supports so-called
+
=== Parameters and Transparent Containers ===
''transparent container objects''. In EMF, all objects should be part of a containment tree, i.e., every object should have a unique parent, except the root object. For flat graph-like structures, this would mean that you have to draw the parent object and the containment edges to all objects in a rule separately. Since this can be quite verbose, the graphical editor supports transparent parent objects. Simply parameterize the rule name with the type of the parent object and all objects in the rule will be automatically treated as children of an object of this type. This works only if the parent type defines canonical containment edges for all elements that are used in the rule.
+
  
The example below shows two the basic and the compact notation for the same rule ''AddEdge''. Note that in the compact version the rule name is specified as '''AddEdge:Graph''' which indicates that all nodes are contained in a Graph object.
+
[[Image:Henshin-parameters.png|right|Transformation rule with parameters and container object]]
  
[[Image:Henshin_graph_editor_containers.png|500px|Transformation rule with container object]]
+
To specify parameters of the rule, simply write the names of the parameters separated by commas and surrounded by (...) after the name of the rule in the title.
 +
The graphical editor moreover supports as a special feature to specify transparent containers. As a general rule in EMF, all objects should be part of a containment tree, i.e., every object should have a unique parent, except the root object. For flat graph-like structures, this would mean that you have to draw the parent object and the containment edges to all objects in a rule separately. Since this can be quite verbose, the graphical editor supports transparent container objects. Simply write the rule name and append '@' followed by the type of the parent object and all objects in the rule will be automatically treated as children of an object of this type. This works only if the parent type defines canonical containment edges for all elements that are used in the rule.
  
'''Update:'''
+
The example rule on the right matches an EClass with the name ''x'' and deletes it from its EPackage, and creates a new EClass with the name ''y'' and adds it to the EPackage. Note that we do not need to draw the EPackage node here explicitly.
Since version 0.7.1 the notation for root objects slightly changed. You now need to use '''@''' instead of ''':'''. Moreover you can now specify the parameters of the rule in brackets. See the example below. This rule matches an EClass with the ''x'' and deletes it from the EPackage, and creates a new EClass with the name ''y'' and adds it to the EPackage.
+
  
[[Image:Henshin-parameters.png|Transformation rule with parameters and container object]]
+
== Limitations ==
  
 +
The graphical editor currently supports [[Henshin/Transformation_Meta-Model#Advanced_concepts:_Application_conditions_and_rule_nesting|application conditions]] only with limited expressiveness: no nesting of application conditions, and no boolean combination of application conditions beyond basic conjunction and negation.
  
== Small Example ==
+
== Visual Multi-View Editor ==
  
The example rule above is called ''ReplaceBook'' and is defined in the context of a ''Library'' object. This means that all matched elements must be contained in a ''Library'' instance and newly created objects are automatically added to it. The rule matches two objects (plus a ''Library'' instance), one of type ''Writer'' and one of type ''Book''. The book is being deleted by this rule and a new instance of ''BookOnTape'' is created with the same title and author as the book. The ''name'' attribute of the ''Writer'' instance is converted to upper case. Moreover the rule cannot be applied if there exists a ''Borrower'' for the book or the category of the book is ''Mystery''. If all application conditions (positive and negative ones) are fulfilled, the rule can be applied. The changes are performed in a transaction and are therefore atomic.
+
An alternative [[Henshin/Multi-View Editor|multi-view graphical editor]] is currently developed at the TU Berlin and Uni Luxembourg. This multi-view editor is '''not''' yet part of the official Henshin toolset, but will be added in the future.
  
If you look at the tree-based editor, you see that the graphical notation is quite different from the underlying model. The Henshin transformation model allows you to define very complex in-place transformations. The graphical editor currently does not support all of the powerful language concepts, yet.
+
[[Category:Henshin]][[Category:Modeling]]

Latest revision as of 14:03, 12 February 2023

The graphical Henshin editor allows to specify transformation rules and transformation units as defined by the transformation meta-model in an intuitive and compact way. This article describes the basic usage of the graphical editor.

Creating a Henshin Diagram

If you want to create a new transformation from scratch using the graphical editor, simply open the New... wizard and select Henshin -> Henshin Diagram and follow the wizard. The wizard will create two files: filename.henshin and filename.henshin_diagram, where you choose filename. The *.henshin file contains the actual transformation, whereas the *.henshin_diagram only stores diagram information. You can also use the tree-based editor to edit the Henshin file directly. To use the graphical editor, you need to oben the Henshin diagram file.

If you already have a transformation in a *.henshin file and you want to create a diagram for it, do a right-click on the Henshin file and select Initialize henshin_diagram file.... This will create and open the diagram file for you.

Importing Models

To define a transformation, you first need to import some EMF models. This can be done using an action in the context menu of the graphical editor, as shown below. When you have successfully imported a new package, all its classes automatically appear in the palette on the right-hand side of the graphical editor.

Henshin Import Menu


Editing Transformation Rules

Example Transformation Rule

The graphical editor offers an intuitive way of representing rules. In Henshin, objects are referred to as nodes and links between objects as edges. A collection of nodes and edges forms a graph.

The control flow of an arbitrary number of rules is specified using units.

Actions

In the graphical editor, a rule are depicted and edited as a single graph. To distinguish between node/edges which should be matched, deleted, created etc. by the rule, stereotypes are used. We refer to the stereotypes as actions. Currently, the following actions are supported for nodes / edges / attributes: «preserve», «create», «delete», «forbid» and «require». To change the action for an element in the rule, select the action label and use the keyboard to type the action (you don't need to type the surrounding «...»).

The actions «forbid» and «require» play a special role, as they are used respectively to specify Negative Application Conditions (NACs) and Positive Application Conditions (PACs). The two actions can be also parameterized to distinguish multiple NACs/PACs. For example, if there are two elements, one with the action «forbid#1» and the other one with «forbid#2», then neither of the two objects must be present. If both elements have the same (or no) forbid parameter, then the two elements must not be found together. It works in the same way for «require».

Parameters and Transparent Containers

Transformation rule with parameters and container object

To specify parameters of the rule, simply write the names of the parameters separated by commas and surrounded by (...) after the name of the rule in the title. The graphical editor moreover supports as a special feature to specify transparent containers. As a general rule in EMF, all objects should be part of a containment tree, i.e., every object should have a unique parent, except the root object. For flat graph-like structures, this would mean that you have to draw the parent object and the containment edges to all objects in a rule separately. Since this can be quite verbose, the graphical editor supports transparent container objects. Simply write the rule name and append '@' followed by the type of the parent object and all objects in the rule will be automatically treated as children of an object of this type. This works only if the parent type defines canonical containment edges for all elements that are used in the rule.

The example rule on the right matches an EClass with the name x and deletes it from its EPackage, and creates a new EClass with the name y and adds it to the EPackage. Note that we do not need to draw the EPackage node here explicitly.

Limitations

The graphical editor currently supports application conditions only with limited expressiveness: no nesting of application conditions, and no boolean combination of application conditions beyond basic conjunction and negation.

Visual Multi-View Editor

An alternative multi-view graphical editor is currently developed at the TU Berlin and Uni Luxembourg. This multi-view editor is not yet part of the official Henshin toolset, but will be added in the future.

Back to the top