un-derlying rule pattern cannot be matched the application of model transformation and correspondence link creation rules should fix the problem.
When a correspondence link is identified as inconsistent in Step3user interac-tion can only be avoided if a powerful constraint solving mechanism is available in the general case. Finally, when model elements are identified as inconsistent in Step4there are two possibilities. When a model element violates the lower bound of a multiplicity constraint the application of model transformation rules creating the appropriate model elements in the other models as well as the required corre-spondence links should fix the problem. When a model element violates the upper bound of a multiplicity constraint the user is required to choose model elements that should be deleted.
List
Element
successor 0..*
0..1 elements
e2:Element l:List
e3:Element e1:Element
a. b.
Figure 7.10:a.Metamodel of linked lists,b.To be transformed source model
Since we want to transform the given list into an identical list we can focus on the source part of the model transformation rule and can omit the trivial cor-respondence link and target parts. Figure 7.11a depicts the source part of the declarative model integration rules. The first rule creates a newList. The sec-ond rule adds a firstElementto theList. The NAC ensures that theListhas no furtherElements. The last rule adds a successor to an existingElementof theList. The NAC ensures that onlyElementscan be provided with succes-sors that do not already have a successor. Thus, the example from Figure7.10b can be created by applying the first rule, then the second rule, and finally the last rule twice.
When deriving operational forward transformation rules from the declarative rules we have to deal with the NACs. Figure7.11b depicts the source part of the forward transformation rules if we decide to keep the NACs. Correspondingly, Figure7.11c3shows the forward transformation rules if we drop the NACs. In order to perform the desired forward transformation we have to transform each model element of the given source model by applying one of the given forward transformation rules as discussed in the preceding section.
We start withList l and apply the first forward transformation rule from Figure7.11b. After that we have to deal with one of theElements e1,e2, or e3. The application of the second rule is not possible as theListalready con-tains three elements and the rule is only applicable if theListcontains only one
3Disregard the given priorities for now.
l:List
<<create>>
l:List
e:Element :Element
<<create>>
l:List
e1:Element
:Element e2:Element
<<create>>
<<create>>
<<create>>
<<create>>
l:List
l:List
e:Element :Element
l:List
e1:Element
:Element e2:Element
l:List
l:List
e:Element
l:List
e1:Element e2:Element
Priority: low
Priority: medium
Priority: high
a. b. c.
Figure 7.11:a.Source part of the declarative model integration rules,b.Derived forward transformation rule parts with NACs, c. Derived forward transformation rule parts with priorities
Element. The application of the third rule is not possible as the transformation of anElement erequires that its predecessor has already been transformed be-fore. That means thatElement e3can only be transformed whenElement e2already has been transformed. Similarly, Element e2can only be trans-formed when Element e1already has been transformed. Due to the NACs Element e1cannot be transformed at all4. Therefore, transferring the NACs from the declarative rules to the operational rules does not result in an applicable set of rules.
Dropping the NACs (and disregarding the given priorities for now) the appli-cation of the first rule of Figure7.11c succeeds. We are now allowed to deal with each of theElementsof theListby applying the second rule of Figure7.11c.
The application of this rule to each of theElementssucceeds. Unfortunately, we end up with a target model that contains aListwhich in turn contains three Elementsthat are not related with each other which violates the constraints of our metamodel forLists. That means that our transformation has lost the infor-mation on the successor relationships which is not intended. Therefore, dropping
4Even appointing that NACs only regard already transformed model elements does not improve the situation. Doing so would allow us to apply the second rule to allElements e1,e2, ande3.
This results in an invalid target model as explained below.
the NACs of the declarative rules when deriving operational rules also does not result in a proper set of rules.
When we regard theprioritiesof the rules shown in Figure7.11c the transfor-mation happens as follows. Firstly, we deal with theListelement by applying the first rule as usual. For eachElementof the list we have now to consider applying the third rule since it has a higher priority than the second rule. When we try to apply the third rule toElement e3this element has to be postponed untilElement e2has been transformed. Correspondingly, the transformation ofe2has to be postponed untilElement e1has been transformed. The appli-cation of the third rule toe1is impossible ase1has no predecessor. Now we are allowed to apply the second rule toe1which succeeds. After that we can trans-form the postponedElements e2ande3by applying the third rule twice. The resultingListnow contains threeElementsthat are related to each other with the correct successor relationships. Thus, priorities allow us to correctly deal with a number of situations (if not all) where NACs would be desirable otherwise.
In this chapter we present the implementation of our approach as part of the MOFLON tool set. We start by giving a brief summary of MOFLON’s history and its goals. Then we describe MOFLON’s TGG support in detail. To this end we present the schema and the rule editors and how MOFLON generates code from a given TGG specification. Finally, we explain how the generated code can be applied in order to realize the desired integration of models.