Skip to main content
Jump to: navigation, search

Difference between revisions of "Henshin/Graphical Editor"

Line 1: Line 1:
The graphical Henshin editor allows to define transformation rules and transformation units in an intuitive and compact way. The website the basic usage of the graphical editor.
+
The graphical Henshin editor allows to define transformation rules and transformation units in an intuitive and compact way. This website describes the basic usage of the graphical editor.
  
 
== Creating a Henshin Diagram ==
 
== Creating a Henshin Diagram ==
Line 17: Line 17:
  
 
The graphical editor offers an intuitive way of representing rules. Essentially, elements in a rule are annotated with stereotypes which are also called ''actions''. Currently supported actions  are:
 
The graphical editor offers an intuitive way of representing rules. Essentially, elements in a rule are annotated with stereotypes which are also called ''actions''. Currently supported actions  are:
* '''<<create>>''' a node or an edge, or set an attribute
+
* <span style="color:green">&laquo;create&raquo;</span> a node or an edge, or set an attribute
* '''<<delete>>''' a node or an edge
+
* <span style="color:red">&laquo;delete&raquo;</span> a node or an edge
* '''<<forbid>>''' a node or an edge or a particular attribute value.  
+
* <span style="color:blue">&laquo;forbid&raquo;</span> a node or an edge or a particular attribute value.  
* '''<<require>>''' a node or an edge or a particular attribute value.  
+
* <span style="color:brown">&laquo;require&raquo;</span> a node or an edge or a particular attribute value.  
  
Forbid and require actions can be parameterized 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.
+
Forbid and require actions can be parameterized 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 <span style="color:blue">&laquo;forbid:1&raquo;</span> and the other one with <span style="color:blue">&laquo;forbid:2&raquo;</span>, 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.
  
 
=== Transparent Container Objects ===
 
=== Transparent Container Objects ===

Revision as of 17:20, 5 December 2011

The graphical Henshin editor allows to define transformation rules and transformation units in an intuitive and compact way. This website 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

The graphical editor offers an intuitive way of representing rules. Essentially, elements in a rule are annotated with stereotypes which are also called actions. Currently supported actions are:

  • «create» a node or an edge, or set an attribute
  • «delete» a node or an edge
  • «forbid» a node or an edge or a particular attribute value.
  • «require» a node or an edge or a particular attribute value.

Forbid and require actions can be parameterized 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.

Transparent Container Objects

The graphical editor moreover supports so-called 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.

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.

Transformation rule with parameters and container object

Limitations

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, but we hope that almost all relevant features will be covered soon.

Multi-View Editor

An alternative multi-view graphical editor is currently developed at the TU-Berlin. This multi-view editor is not yet part of the official Henshin toolset, but will be added in the future. The multi-view graphical editor can be obtained from this URL: http://tfs.cs.tu-berlin.de/henshin/.

Back to the top