# Difference between revisions of "Henshin/Graphical Editor"

Line 3: | Line 3: | ||

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. | 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 | + | 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 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 example rule is called '' | + | The example rule 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''. Not that the <<forbid>> actions can be parameterized to distinguish the negative application conditions (NACs). This essientially corresponds to logical AND vs. OR (more generally: first-order logic formulas over graph patterns). 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. |

− | + | ||

− | + | ||

− | + | ||

− | If all | + | |

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 09:34, 8 September 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 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 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.

The example rule 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*. Not that the <<forbid>> actions can be parameterized to distinguish the negative application conditions (NACs). This essientially corresponds to logical AND vs. OR (more generally: first-order logic formulas over graph patterns). 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.

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.