The definition of a rule construct consists of a name, the left-hand side and the right-hand side. The left-hand side is the condition under which the rule is used. It consists of one subgraph describing the positive application condition and zero or more subgraphs each describing a negative application condition (nac). The right-hand side consists of a single subgraph.
Usually a rule is used as an application condition for a pattern imple-mentation. In that case the rule just creates a concrete instance of a pattern implementation and attaches it to the host graph. Rules are also used for normal housekeeping tasks such as initializing and preprocessing for an appli-cation condition or a set of appliappli-cation conditions and cleaning up temporary attributes or edges.
For example, the initial version of the pattern a table corresponding to a classsays it should be applied once to each class in the source model. The ap-plication condition (visualized in Figure 4.7) is shown in Figure 4.8. Lines 2–6 define the left-hand side. It states that this rule is applied if there is a Class node in the graph. However, the negative application condition (lines 4–6)
Figure 4.7: Visualization of rule applyTableCorrespondingToClass
1 rule applyTableCorrespondingToClass {
2 // LHS
3 c:Class
4 nac
5 c:Class <--srcClass-- s:ClassRole
6 s <--.srcClass-- p:TableCorrespondingToClass
7 =>
8 // RHS
9 c:Class // preserve the class from LHS
10 tctc:TableCorrespondingToClass // instantiate pattern impl.
11
12 tctc.srcClass {bound=c.modelElement} // bind srcClass task
13
14 c <--srcClass-- tctc.srcClass // fulfill nac
15 }
Figure 4.8: Graph rewrite rule for TableCorrespondingToClass
states that the rule is not applied if the Class node is connected to a ClassRole node (a task node) from the pattern implementation TableCorresponding-ToClass. If such an unprocessed Class node is found, the right-hand side (lines 8–14) is performed.
The right-hand side creates an instance of the pattern implementation (line 10) and binds itssrcClass to the unprocessed class (line 12). Finally, on line 14, an edge labeled srcClass is created from the srcClass node to the class node. This last action ensures that if the rule is tried on the same class a second time, the negative application condition will disqualify the match. Otherwise the rule would be executed on the same class over and over again, forever.
If this rule is applied to the graph representing the class diagram in Fig-ure 4.4a, one instance of the pattern implementation is created for each of the source model classes. The instances are also partially bound, leaving in total three manual tasks, which have not been bound. When the graph is
translated into tasks for the MADE tool, there will be three interactive tasks for the user to perform: to select an existing table or create a new one for each of the source model classes.
4.6 Illustrative Scenario
We expand on the scenario in the previous chapter by filling in the evolu-tion of the model transformaevolu-tion definievolu-tion and the model transformaevolu-tion implementation. In the first iteration Debbies the Design Phase Experts and Archie the Transformation Architect had written the transformational patterns a table corresponding to a class and a column corresponding to an attribute. The next steps are for Archie and Peter the Transformation Pro-grammer to create the model transformation definition and the model trans-formation implementation.
At this point there is very little to design for the implementation. Archie and Peter decide that the implementation of the patterna table correspond-ing to a class will have one decision for each class: “Select a table or create a new table for class <className>.” In their opinion that is better than, for example, having the designer manually create tables and then asking one decision for each table: “Select the corresponding classes for table <table-Name>.” There is no understanding yet of what the user is supposed to base their decision on, so Archie and Peter do not need to worry about decision modeling.
Peter writes the pattern implementations and the application conditions based on the transformational patterns and the model transformation def-inition. The pattern implementation and the application condition for the pattern a table corresponding to a class were already shown in Figure 4.5, Figure 4.6, Figure 4.7 and Figure 4.8.
In the second iteration, Debbies and Archie had written four new trans-formational patterns regarding inheritance and modified the pattern a table corresponding to a class. The pattern was split into one pattern for mapping tables to classes and one pattern for creating new tables based on classes.
Archie and Peter decide that the implementation of the pattern inheri-tance interpretation will have one decision for each inheritance relationship, i.e. a superclass-subclass pair. The designer will be asked which of the in-heritance patternssubclass and superclass in separate tables,subclass merged into superclass’s table and superclass copied into subclass’s table should be applied in each case.
Peter writes the pattern implementations. The implementation fora table corresponding to a class is shown in Figure 4.9. Because the pattern
imple-1 pattern TableCorrespondingToClass {
2 context
3 srcClass:ClassRole ;
4 decision
5 tgtTable:TableRole ;
6 }
Figure 4.9: Modified TableCorrespondingToClass
mentation acts as a mapping only, there are just two task nodes and no edges or node attributes. The previous implementation for the pattern (Figure 4.6) is used as the implementation for the pattern a table derived from a class.
Chapter 5
Decision Modeling
Big yellow letters on the screen; a cold voice of the machine.
We’re drifting further away; nobody knows what to say.
And as we ask for a little help from a friend.
The only response we get is: “HUMAN DECISION REQUIRED”
– S.P.O.C.K., “Human decision required”,Speed of Light, 1998
5.1 Decision
The discussion on decision modeling for reuse of human decisions [III] and traceability across decisions [VI] in this chapter is based on the included publications.
An application designer is guided by some reasoning when she performs actions to finish a design phase. When a model transformation is developed, the actions are automated to the extent that the reasoning is understood. For the actions with incompletely understood reasoning, human decisions have to be added into the model transformation. For example, the designer may have to decide which columns in the tableStudent form the primary key.
We define human decision in a model transformation as any choice that the human operator has to make and that affects the outcome of the model transformation. A decision has more than one option to choose from, and tomake a decision is to choose one of the options. The consequences of the decision depend on the option chosen. We call that option the value of the decision. The reasoning behind making the decision is partly or completely unknown, but we assume it to be deterministic.
To the model transformation implementation the decisions seem like
non-deterministic rules. Each decision is replaced with one of its possible con-sequences, and without understanding about the reasoning the choice seems random.
Our definition of decision doe not say how the model transformation implementation should present the decisions. There is not necessarily one run-time question for one decision. In fact, one important goal of a semi-automatic model transformation implementation is to reduce the designer’s burden in making the decisions. The designer may be asked explicitly to make a decision, for example, to select the primary key for Student. A de-cision may be made implicitly by default values that can be changed or by indirect questions.
The decomposition of incompletely understood actions and reasoning into decisions is clearly not unique. For example, selecting the primary key for Student could be defined as one decision to choose between using existing columns or creating a surrogate key, and another decision to choose the actual columns if a surrogate is not used. It could also be defined as a single decision with options {create surrogate, columnSet1, columnSet2, . . .}. The decomposition might not even be done by classes, by, for example, having a single decision for choosing all the tables that should get a surrogate key.
Some decisions may be unique, but for most decisions there probably are other decisions that are of similar type, but affect a different part of the model. For example, the decisions to choose primary key columns for tables Student,Person and Teacher are similar, but focus on a different table. We call the type a decision kind and a decision is an instance of its decision kind. We call the focus of the decision (in this case the table) the target of the decision.