Translating the variation and human decisions in the transformational pat-terns into decision models is not a mechanical task. The Transformation Architect has to consider functional and non-functional aspects, such as us-ability and maintainus-ability.
The transformational patterns do not say how a decision is to be pre-sented to the user. That is part of the design of the model transformation.
For example, is the application designer asked for each table to “select the columns that form the primary key for [tablename]”, or is she asked for each column “is the column [columnname] part of the primary key?” Such design decisions affect the decision models and the model transformation greatly.
Because of the nature of the decision context, decision validity checking is conservative. If there is a possibility that a part of a model affects a decision, it should be part of the context. In some cases the “correct” decision context spans too large a portion of the model to be useful. For example, if nothing is known of what the decision is based on, the decision context is the entire model. Then any change invalidates the decision and reuse never happens.
In such situations it may be better to limit the decision context too much and advice the users. The decision context could be limited to only certain types of elements, for example. A user guide or other documentation should explain that changes to, e.g. associations are not taken into account for this decision kind. If the decision context is left empty, the decision is reused always. So, overlimiting the decision context trades precision for recall in decision validity checking.
It is sometimes practical to combine a decision kind’s pattern implemen-tation with another pattern implemenimplemen-tation. For example, two small decision kinds that are applied to the same targets and have the same decision con-texts could be combined into one decision kind. It reduces the amount of nearly identical graph rewrite rules and pattern implementations.
5.7 Illustrative Scenario
We build on the scenario from the two previous chapters and add explanations about the decision modeling. In the first iteration Debbies and Archie wrote the transformational patternsa table corresponding to a class and a column corresponding to an attribute. Archie and Peter create the necessary decision models as part of creating the model transformation definition.
The pattern implementationTableCorrespondingToClass(Figure 4.6) con-tains a decision to select or create a table. The understanding of what affects
1 pattern ChoosePrimaryKey {
2 visiting
3 target:TableRole, // the target of the decision
4 primaryKey:ColumnRole,
5 pkStereotype:StereotypeRole ; // consequences
6
7 primaryKey <--#_-- pkStereotype // which element to stereotype
8
9 primaryKey{#name="STI: primaryKey",#multiplicity="+", ...}
10 pkStereotype{#stereotypeName="STI: PrimaryKey" }
11 }
Figure 5.5: Initial version of the decision kind ChooseP rimaryKey
this decision is poor. Because the decision is needed for every class, Archie and Peter decide to save the application designer redundant work at the expense of the precision of the validity checking. They model the decision context to be just the target, which means the decision will be reused uncon-ditionally. They write instructions for the model transformation’s users and explain that the validity checking must be done manually.
The pattern implementation ColumnCorrespondingToAttribute contains only automatic tasks, so decision context is irrelevant. For the first version of ChoosePrimaryKey Archie and Peter decide to not define a decision context, because the transformational pattern primary key does not contain enough information. The pattern implementation is shown in Figure 5.5. All the nodes are listed under the section “visiting”, which means decision reuse is not attempted. The application rule is very similar to that shown in Figure 5.4, but there is no need to compute or assign the context (line 11).
In the second iteration the understanding of how the primary key is se-lected has improved. Archie and Peter leverage this by defining the decision context for ChoosePrimaryKey to be the set of columns in the class. The set can be computed and collected with two small helper rules (Figure 5.6.
The first one initializes a table with a node that is used for collecting the set.
The second rule adds each column to the table’s set by binding the column to a task node and then merging the node to the set collecting node. The pattern implementation itself was shown in Figure 5.3 and the applying rule in Figure 5.4.
In the third iteration Debbies add the option to create a surrogate key into the transformational pattern primary key. If a surrogate key is used, a column is added into the table and that column alone is used as the primary
1 rule initColumnSet {
2 t:Table // any table
3 nac
4 t:Table <--columnSet-- c:ColumnRole // but not yet initialized
5 =>
6 t:Table <--columnSet-- c:ColumnRole
7 }
8
9 rule collectColumnSet {
10 t:Table <--columnSet-- cr:ColumnRole // an initialized table
11 t --columns--> c:Column // with a column
12 nac
13 c:Column <--columnSet-- cr:ColumnRole // not yet included
14 =>
15 t:Table <--columnSet-- cr:ColumnRole // preserve LHS
16 t --columns--> c:Column // preserve LHS
17
18 cr2:ColumnRole{bound=c.modelElement} // bind column . . .
19 cr <+ cr2 // and add it to the set
20 }
Figure 5.6: Helper rules to collect columns of a table
key. The decision of whether to create the surrogate or use existing columns can be expected to not be affected by columns in other tables. Peter can combine that decision and the decision of which columns to choose into one pattern implementation, because they share the target and the context.
In the subsequent iterations Archie and Peter may have to rethink the decision validity condition forChoosePrimaryKey. As it is now, adding or re-moving any column invalidates the decisions. But would not the primary key be fine, if a column that had been left out of the primary key was removed?
Only the Debbies, if anyone, would be able to answer that.
With the feedback from applying the model transformation in each iter-ation the Debbies increase their awareness of their tacit knowledge and the understanding of the problems and solutions. The decision models improve over iterations just the same as the transformational patterns and the pattern implementations.
As can be seen in the examples presented here, changes to a transfor-mational pattern affect mostly the corresponding part in the transformation definition, decision models and the pattern implementations and rules. The changes leak only to the related patterns and even then relatively little.
Changes to the decision validity condition alone cause very small changes to the pattern implementation. Context nodes may have to be added or removed and it may be necessary to rethink which nodes are context, decision and visiting nodes. However, the relationships between the nodes and the properties that are set on nodes do not need to be altered. The graph rewrite rules that compute the decision context do change, but those rules can be separated from the rules that apply the pattern.
All in all, changes to decision models or decision validity conditions stay very local, supporting the claim that a transformational pattern can be used as a unit of refinement from the specification to the implementation of model transformational patterns.
Chapter 6
DReAMT Tool
Welcome to the machine.
– Pink Floyd, “Welcome to the Machine”,Wish You Were Here, 1975
6.1 Architecture
This chapter is based on an included publication [V]. The DReAMT tool is actually two tools, the interactive model transformation execution envi-ronment (DIMTEE) and the model transformation compiler (DMTC). The execution environment is built on top of a task-based tool MADE [21], which was discussed in Section 2.4. The compiler is a stand-alone program.
DIMTEE is integrated with MADE and the Eclipse UML2 component.
The UML2 component is based on the Eclipse Modeling Framework (EMF).
MADE is integrated with UML2Tools, which provides diagram editors on top of UML2. DMTC uses only common Python libraries. The components DIMTEE and DMTC consist of (light boxes at the top) and depend on (dark boxes at the bottom) are shown in Figure 6.1.
When the user launches a model transformation he gets a list of tasks.
Performing one task may bring new tasks to the list. When all the tasks have been performed, the transformation is finished. Much more happens behind the scenes. When the user launches the transformation, the execution en-vironment translates (UML2 Import in Figure 6.1) the relevant parts of the source model into graph form. It executes the transformation implementa-tion (given as a graph Grammar) on its graph rewrite system engine (GRS engine).
The graph grammar creates a task graph customized for transforming that source model. The task graph is translated (Task graph export) into a
Figure 6.1: DIMTEE and DMTC technology stacks
MADE concern and passed on to MADE task engine, which together with the MADE UI takes care of managing the task list and handling the user interface for performing tasks. The manual tasks are recorded, which allows saving the work and returning to it later.
The model transformation compiler parses (Parser) the model transfor-mation code and generates (Grammar generator) Java code. The compiled Java code (Grammar) is installed into the execution environment.
Currently the UML2 Import can translate model elements from UML2 class diagrams and activity diagrams. From a technical point of view it can translate any EMF model element, but for performance reasons it does not translate the entire source model. The code for UML2 Import is generated from a so called translation model. If the import functionality needs to be modified, it is done by editing the translation model. The purpose of the model and the code generation is to make developing the DReAMT tool easier, it is not meant to be used by model transformations writers.
The translation model defines what parts are included and how they are expressed in the resulting graph is defined. The translation model really describes how to reduce the source model to form a model fragment and uses an improved version of a reduction scheme called Implication-Projection [39].
The translation model is textual and contains implication rules, projec-tion rules and labeling rules for each model element type. Implicaprojec-tion rules dictate what part of an element’s neighbourhood is included, e.g. “[if you include a]Class =⇒ [include also] the attachedAssociationEnds”, “Associ-ationEnd =⇒ attached Classes, containing Association” and “Association
=⇒ contained AssociationEnds”.
Projection rules list the element properties that are to be translated, e.g.
for a class name and abstract. Labeling rules tell what name to use for
Figure 6.2: User interface of the interactive model transformation execution environment [V, Fig. 3] (same as Figure 2.1)
an edge between nodes and to which direction it should go. In the UML metamodel a link between two elements is bidirectional and has two names, one for navigating to each direction. In the graph a link is represented as a single directed labeled edge.