Skip to main content
Jump to: navigation, search

Difference between revisions of "Henshin/Graphical Editor"

m
Line 1: Line 1:
Model transformations in Henshin are defined using matched transformation rules. There are currently two rules editors available: a tree-based editor (EMF) and a graphical one (GMF). A screenshot of a simple, but not very meaningful, transformation rule in both editors is shown below.
+
Model transformations in Henshin are defined using matched transformation rules. There are currently two editors available for rules: a tree-based editor (EMF) and a graphical one (GMF).
 +
 
 +
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 maapings from the LHS to the RHS encode which objects should be preserved by the rule.
 +
 
 +
The graphical editor uses 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 below. Note that you need to import EMF models first in both editors. This can be done using the context menu. In the graphical editor, all classes automatically appear in the palette on the right.
  
 
[[Image:Henshin_example_transformation_rule.png]]
 
[[Image:Henshin_example_transformation_rule.png]]
  
The rule is called ''Test'' and it matches two object, one of type ''Library'' and one of type ''Writer''. Additionally, the writer instance must be contained in the library instance via the ''writers'' containment reference, and its ''name'' attribute must be set to "Smith". The last condition that must be fulfilled for that rule to be applicable is that the library instance must not contain a instance of type ''Book'' in its ''books'' containment reference.
+
The examplerule is called ''Test'' and it matches two objects, one of type ''Library'' and one of type ''Writer''. Additionally, the writer instance must be contained in the library instance via the ''writers'' containment reference, and its ''name'' attribute must be set to "Smith". The last condition that must be fulfilled for that rule to be applicable is that the library instance must not contain a instance of type ''Book'' in its ''books'' containment reference.
  
 
If these conditions are all fulfilled, the rule can be applied. It performs the following actions in an atomic step: delete the writer instance from the library and create and add a book instance to the library. Note that you can also define attribute calculations (not shown in this example).
 
If these conditions are all fulfilled, the rule can be applied. It performs the following actions in an atomic step: delete the writer instance from the library and create and add a book instance to the library. Note that you can also define attribute calculations (not shown in this example).
  
 
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.
 
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.

Revision as of 12:18, 4 August 2010

Model transformations in Henshin are defined using matched transformation rules. There are currently two editors available for rules: a tree-based editor (EMF) and a graphical one (GMF).

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 maapings from the LHS to the RHS encode which objects should be preserved by the rule.

The graphical editor uses 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 below. Note that you need to import EMF models first in both editors. This can be done using the context menu. In the graphical editor, all classes automatically appear in the palette on the right.

Henshin example transformation rule.png

The examplerule is called Test and it matches two objects, one of type Library and one of type Writer. Additionally, the writer instance must be contained in the library instance via the writers containment reference, and its name attribute must be set to "Smith". The last condition that must be fulfilled for that rule to be applicable is that the library instance must not contain a instance of type Book in its books containment reference.

If these conditions are all fulfilled, the rule can be applied. It performs the following actions in an atomic step: delete the writer instance from the library and create and add a book instance to the library. Note that you can also define attribute calculations (not shown in this example).

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.

Back to the top