Creating Transformation Rules

To create a new set of transformation rules, use the appropriate wizard. Select File->New... and select the MoTE TGG Rule Project. The following wizard shows up:

MoTE TGG Rule Project Wizard

In this wizard, you have to specify several information about the transformation rules. Project name is obviously the name of the new project. Java base package specifies, which package prefix the generated code will have. Source Metamodel URI and Target Metamodel URI specify the URIs of the source and target metamodels. You can click the Browse Package Registry buttons to select the metamodel from the EMF package registry. Both metamodels have to be registered with the EMF package regisry. Below you have to select the type of the root nodes of both models. In the following, we will use a transformation from SDL block diagrams to UML class diagrams. Therefore, BlockDiagram and UMLClassDiagram are the root nodes of these models.

After clicking finish, the project will be created and some initial files will be generated. The *.tgg file contains the actual TGG rules. Initially, it only contains the axiom of the TGG. You create a graphical view by right-clicking the *.tgg file and selecting TGG->Initialize tggdiag diagram file. In the wizard, you have to select the TGG rule for which to generate the diagram. A *.tggdiag file shows only a single TGG rule, while the *.tgg file contains all of the actual rules. To create additional TGG rules, open the *.tgg file and add another TGGRuleelement to the TGGDiagram. After that, create a *.tggdiag file for the new rule as described before.

The *.ecore contains the metamodel of the correspondence nodes. Initially, it contains a class CorrAxiomfor the correspondence nodes created by the axiom, and a class CorrRule for correspondence nodes created by ordinary TGG rules. You can add additional classes and use them in your TGG rules. You can also use inheritance. However, each type of correspondence node must directly or indirectly inherit from TGGNode.

There are also two *.workflow files. These can be executed by right-clicking them and selecting Execute Workflow to automatically perform certain tasks. generate operational rules.workflow triggers the generation of Story Diagrams and Java code from the TGG. You have to execute this workflow each time you make a change to the TGG rules or the correspondence metamodel. generate test case project.workflow generates a test case project that you can use to create test cases for your transformation rules. For more information, see Testing TGG Rules.

If you open generate operational rules.workflow, you can configure several properties. The URIs of the TGG file, the correspondence metamodel, the project name, and the Java base package are set based on the information entered in the wizard. The selected generationStrategy determines the features that the generated transformation rules will support. The default value is SimpleTransformationGenerationStrategy. This generates operational transformation rules that only support model transformation. Alternatively, you can set generationStrategyto SynchronizationStrategy. This will generate operational rules that also support model synchronization.

After creating the TGG rules and generating the operational rules, you have to deploy the rule set plugin before you can use it. It is also not possible to open the generate Story Diagrams before deploying the plugin. To do so, export it to a plug-in using the Export... wizard. Place the *.jar file in the dropins folder of your Eclipse. Alternatively, you can simply start a new Eclipse instance from your current Eclipse workbench. Your transformation rule set should now be available in the drop down list of the model transformation dialog.

The plug-in de.hpi.sam.mote.sdl2uml already contains a complete transformation rule set as an example. Install the MoTE Examples and execute the SDL2UML Example TGG Rules wizard to extract it to your workspace.

Note:

All TGG rules must satisfy the following conditions:

• The general structure of all TGG rules (not the axiom) must adhere to this scheme:

  
  
  

  • A rule must contain at least one correspondence node in its application condition.
  • A rule must create exactly one correspondence node.
  • A rule must contain at least one model element in each domain in its application condition.
  • A rule must create at least one model element in each domain.
  • Every model element in the application condition must be connected to exactly one correspondence in the application condition.
  • Every created model element must be connected to the created correspondence node.
  • There must be at least on link between an element of the application condition and a created element in each model domain.
• The axiom must create exactly one correspondence node and at least one model element in each model domain.
• In attribute assignments, referring directly to elements of the other model domain should be avoided. Instead, RuleVariables should be used as an intermediate variable. A RuleVariable has a name and type and specifications how to compute the variable's value for the forward and backward direction.