Metamodel of simple SDL block diagrams
Triple graph grammars combine three common graph grammars, which describe how to derive a source model, a target model, and a correspondence model in parallel. The correspondence model stores traceability links between corresponding source and target model elements.
To illustrate the following explanations we use the example meta models below: Simple versions of SDL block diagrams are transformed into simple UML class diagrams. Each block in the block diagram corresponds to a class with the same name in the class diagram. A special correspondence model connects corresponding elements in the block and the class diagram.
Metamodel of simple SDL block diagrams
Metamodel of simple UML class diagrams
Metamodel of the correspondence model
TGGs consist of a set of rules, which create new elements depending on the application context, and an axiom, which serves as a starting point for the application of the transformation rules.
Example triple graph grammer for the transformation of block diagrams to class diagrams.
The axiom serves as the start graph of the graph grammar. It creates the root elements of the two models. The left-hand-side (LHS) and right-hand-side (RHS) of the transformation rule are combined in this notation. All elements that occur on the LHS and the RHS are colored black. These elements form the application context of the rule and are not modified during rule application. All elements that belong only to the RHS are colored green and marked with ++. These elements are created by the rule. Rules that delete elements are not used in the context of model transformation with TGGs.
A TGG rule consists of three domains. The left and right domains contain elements belonging to the source and target models respectively. The middle domain describes a transformation on the correspondence model. If all elements on the LHS of the rule can be matched to existing elements in the models, the rule can be applied and the elements of the RHS are created.
Before model transformation using TGGs can be performed, operational rules have to be derived from the declarative TGG rules. These operational rules perform the actual model transformation. Three transformation directions are possible for TGGs: Forward, backward and mapping transformations. The forward and backward transformations generate the target and correspondence models from the source model. The forward transformation defines the left domain of the TGG rules as the source model, the backward transformation uses the right domain as the source. The mapping transformation only generates the correspondence model from existing source and target models. For each of these directions another set of operational rules has to be derived. These operational rules also take care of creating the next links between correspondence nodes. These links do not appear in the TGG rules since they are always required and deriving them automatically ensures that they are consistently used and cannot be forgotten when modeling the rules.
Operational rules for forward transformation derived from the TGG.
All elements that belong to the source domain of a TGG rule are now also part of the application context of the corresponding operational rule. If all elements of the application context can be matched in the existing models, the rule can be applied, effectively transforming the source elements. One of the correspondence nodes in the application context is marked as the input node (omitted in the figure because there is only one correspondence node in the application context of any rule). This node is used as the starting point for the pattern matching process, which looks for elements in the three models that match the application context of the rule.
The transformation system consists of two parts: The operational rules, that are compiled into an Eclipse plugin, and a transformation engine, that loads the rules from the plugin and controls rule application. When performing batch transformation, the transformation engine works according to the following scheme:
Execute axiom to create root correspondence node;
Create a queue, put the root correspondence node in the queue;
while (queue is not empty)
{
Remove first correspondence node N from queue;
forall rules r that require the type of correspondence node N
{
Execute r for N in application context;
Put direct successors of correspondence node N in the queue if they are not already contained;
}
}
To transform a model, the axiom is executed first, which creates the root elements of the correspondence and target models. Afterwards, all rules are executed that require the type of the just created correspondence node in their application context to transform additional elements. This creates new correspondence nodes. Then, all transformation rules are executed that require the type of these correspondence nodes in their application context. This process is repeated until no rule creates new correspondence nodes.
The transformation system can also perform model synchronization instead of model transformation. Then, the rules first check for modifications. In case the existing elements in the source, correspondence, and target models fully comply to the rule, nothing is changed. If a modification is encountered, the rule modifies the correspondence and target models, accordingly. New source elements are simply transformed and added to the target and correspondence models. Modified attribute values are also propagated. Other structural changes, like moving an element, are synchronized by first trying to adjust only links in the target model. If this fails, the corresponding target elements are deleted and recreated. Then, the consistency of subsequent model elements is checked and reestablished if needed.
Instead of starting at the root correspondence node (like in case of a transformation), the algorithm can start the synchronization directly at the correspondence nodes belonging to the modified elements, thus restricting synchronization to the affected elements and saving effort. Furthermore, if the synchronization system recognizes that a modification did not influence consistency of subsequent elements, consistency of these elements is not checked again. To notice when a model element is modified, we use EMF's change notification mechanism. An event listener is registered at each source and target model element. If a change notification event is received, the correspondence node belonging to the modified model element and its parent node are put into the transformation engine's queue.