A DReAMT model transformation is given as a text file, which the model transformation compiler compiles into a Java source file calledgrammar.java.
That is compiled into a Java class and installed into the model transformation execution environment by copying it over the old class file. Currently only one model transformation can be installed at a time.
The text file contains the definitions of the pattern implementations and the application condition rules. For each pattern implementation the com-piler generates a factory function in Java. When the function is invoked, it creates the nodes and edges defined in the pattern implementation, sets node attributes and adds mapping data. The data is used in decision reuse when recovering the mappings from the previous execution of the model transfor-mation.
DMTC automatically assigns an identifier to each pattern implementation and for each task node in it. A node’s mapping data is a triple of the pattern implementation’s and the task’s identifiers as well as a number signifying the instance of the pattern implementation. For example, if the identifier for the pattern implementation TableCorrespondingToClass is 42, the identifiers for its tasks srcClass and tgtTable are 1 and 2 and it is the fourth time the pattern implementation is instantiated, the triples are (42,4,1) and (42,4,2).
The mapping data is added to the task nodes and later exported into the tasks in the MADE concern. The tasks are bound to model elements, say
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 6.3: Rule applyTableCorrespondingToClass (same as Fig-ure 4.8)
C4 and T4, and the tasks from the third instantiation are bound to C3 and T3. The mapping data makes it possible to see that the mapping entries are (C4, T4) and (C3, T3) and not, for example, (C4, T3) and (C3, T4).
For an application condition rule the compiler generates a class with one method for finding a match for the LHS and another for carrying out the graph modifications implied by the RHS. In addition, the compiler generates one method for each negative application condition in the rule. It does only very basic optimization.
The compiler statically chooses a search strategy based on a few simple heuristics and produces a depth-first match-finding algorithm. The algorithm treats the nodes in the LHS as a sequence of variables, and the types, prop-erties and edges as constraints. It finds a concrete node that satisfies the constraints for one variable and descends to the next variable. If there are no suitable nodes left, the algorithm backtracks to the previous variable. If a full match is found, it is returned as a tuple of nodes.
The rule applyTableCorrespondingToClass is shown in Figure 6.3. The rule is the same as in Figure 4.8 and is repeated here solely for the reader’s convenience. A pseudo-code for the algorithm generated for finding a match for the LHS and for the negative application condition is shown in Figure 6.4.
The rule’s positive application condition (line 3) requires only the exis-tence of a node with type Class. The match() method (lines 1–8) tries to find such a node by trying each node in the graph in order (lines 2–6) to
1 method match()
2 for c in Nodes // go through candidates forc
3 if c.type != "Class" // isccandidate Class?
4 continue
5 if nac_1(c) // a match, but does nac match, too?
6 continue
7 return tuple(c) // match found
8 return null // search exhausted
9
10 method nac_1(c)
11 for edge_1 in c.inEdges // check cfor an edge . . .
12 if edge_1.type != "srcClass" // labeled srcClass and . . .
13 continue
14 Node s = edge_1.source
15 if s.type != "ClassRole" // from aClassRole node
16 continue
17 for edge_2 in s.inEdges // checksfor an edge . . .
18 if edge_2.type != ".srcClass" // labeled.srcClass and . . .
19 continue
20 Node p = edge_2.source
21 if p.type != "TableCorrespondingToClass" // from atctc
22 continue
23 return True // match found for nac
24 return False // search exhausted
Figure 6.4: Pseudo-code for LHS and nac matching algorithm
see if it is of type Class (lines 3–4). If the node is of some other type, the algorithm skips to the next node.
The rule’s negative application condition (lines 5–6) must not hold. The graph must not contain a ClassRole node and aTableCorrespondingToClass node so that the edge constraints are true. If the match() method finds a match, it checks negative application condition (lines 5–6). If the nac is found, the match is not valid. The actual check is in the method nac_1(), which does a match-finding generated with the exact same method as the positive application condition.
Thenac_1()method goes through theClass node’s incoming edges look-ing for the right label (lines 12–13). It checks the source end of the edge to see if it is a ClassRole (lines 14-16). If these both hold, it goes through the
ClassRole node’s incoming edges (lines 17–23) looking for an edge labeled .srcClass from a TableCorrespondingToClass node.
The generated customized match algorithm essentially goes through all structurally valid node and edge combinations and checks that the given type and attribute conditions hold. If a check fails, the code tries the next valid combination. This naive matching algorithm is very inefficient. The actual implementation is a little better, but essentially it works as described here. It does not choose a search strategy dynamically, analyze dependencies between rules or use information about the modeling language. Optimizing the match algorithm has not been a priority.
The right-hand side of the rule (lines 8–14) implies that a new instance of the pattern implementation TableCorrespondingToClass needs to be created (line 10), its role srcClass needs to be bound to the class found (line 12) and an edge from the role to the Class node needs to be created (line 14). No nodes or edges need to be removed, as the left-hand side only contains one node and that is on the right-hand side, too.
The compiler will generate a call to the pattern implementation’s factory function, the binding and the edge creation. As the very last action, the compiler generates function calls for the decision reuse attempts. The calls will compare the created pattern implementation instances’ (in this case just one) context to the recovered mapping’s entries. If a matching entry is found, the decision nodes are bound to the recovered values.
Chapter 7 Applications
HALO Purely for Pets Derma Dream is a soothing, all-purpose oint-ment effective on skin conditions, rashes, insect bites, cuts and abra-sions. It provides lasting coverage and a protective barrier against in-fections [. . . ] For Dogs, Cats, Birds, Rabbits, Ferrets, Gerbils, Ham-sters, Snakes, Iguanas, Lizards, Monkeys, Horses, Pigs, and anyone else with skin!
[This] topical ointment [can be] used for any problem skin condition.
[It is] soothing, anti-fungal and anti-bacterial. [It heals] cuts, wounds, abrasions, and scabby areas overnight.
Apply directly to affected area once or twice daily. [. . . ] Use liberally.
– An advertisement for HALO Pets Derma Dream Natural Healing Salve Rashes, Insect Bites, Cuts And Abrasions
7.1 Applications of DReAMT
We have applied DReAMT in three research studies to evaluate the approach and the tool. In the first study [IV], DReAMT was used to provide tool sup-port for a new process for building so called ReSTful web service [37] applica-tion programming interfaces (APIs). In the second study [VII, pp. 3–12], the DReAMT tool was used as a component in a business process modeling tool.
A DReAMT model transformation was used to transform a business process that was expressed as an activity diagram into an XML-form understood by a process and task engine. In the third study [VII, pp. 12–17], the DReAMT process was used to develop a model transformation that assists in creating model (in)consistency rules based on two metamodels.
Figure 7.1: Process for building ReSTful services [IV, Fig. 2]