Dynamic Model Transformation

As explained in Section 4.3.2, the TM is generated automatically by a model transformation operation. The transformation takes the source models and the mapping model, as its input models, and generates the project-wide TM

Figure 5.6: The list provided to users to select the endpoints of an entry as the output model. The dynamic model transformation is published in the final tooling and provided to the traceability users to create the TM.

Basically, there are two options for how to implement and perform the transformation as depicted in Figure 5.7.

1. Generate transformation rules, based on the mapping model, and then use them to generate the TM

This option is a higher-order transformation (HOT), which takes a transformation model as input and produces a transformation model as output [Tisi et al., 2009]. In the context of this work, the mapping model is the transformation model which is transformed into an ex- ecutable transformation model. Regarding the target transformation model (e.g. ETL in our infrastructure), a M2M or M2T transforma- tion language can be used to generate the target transformation, which is thereafter executed on the source models and generates the TM. 2. Develop a domain-specific transformation which performs the trans-

formation dynamically (on-the-fly)

A domain-specific transformation performs customised transformation for particular purposes, in comparison to usual transformation. In this case, a domain-specific transformation is developed with a general model operation language (e.g. EOL). The transformation dynam- ically infers the transformation rules from the mapping model and

executes them at run-time. Rules are applied on the source models and the TM is accordingly populated. This way, the TM is generated gradually while the transformation is executed.

(a) Option 1

(b) Option 2

Figure 5.7: The two options to generate the TM

We chose the second option and decided to implement and perform the required model transformation using EOL, which we call it dynamic model

transformation, instead of transforming the mapping model into an ETL

module (HOT). The first reason for this decision was to minimise the ad- ditional models and model operations as much as possible. This is because even if they are created or executed automatically they increase the com- plexity and cost of dealing with change to keep them consistent and updated. In the first option, there would be two model operations: an EGL program used to generate transformation rules in ETL which are thereafter used to generate the TM. In the second case, there is just an EOL program which does the transformation to build the TM.

Additionally, we discovered two recurring patterns for the transformation rules:

1. Create an object of subtype of TraceableElement or TraceLink in the TM in respect to a defined object of type EClass in a source model. 2. Create an object of subtype of TraceLink in the TM for a given asso-

ciation between two objects in a source model.

In this respect, we determined that although the first pattern can be easily implemented by ETL, it would be too complex to explain the rules for the second pattern in ETL and we need to explain some parts of the transfor- mation within user-defined operations which are implemented using EOL. Although ETL is a hybrid language that implements a task-specific rule definition and execution scheme and also inherits the imperative features of EOL to handle complex transformations, we found that describing the required transformation in context of ETL would increase the complexity of

the solution. This is because, as we wanted to generate the transformation rules automatically, we needed to develop a complex EGL program to gen- erate a complex ETL program which should be tested and verified to check if it generates the correct output or not. On the other hand, the second rule pattern is important and frequently used in the context of this work. This is because, fundamentally, we intend to derive trace links from gen- eral relationships between elements and objects in other models. Therefore, we decided to develop an EOL program to perform the transformation to generate the TM.

Listing 5.5 shows part of the EOL program used for dynamic model trans- formation. The complete code of the transformation is provided in Ap- pendix E. The core of the transformation is iterating over mapping entries (Listing 5.5 the for statement in line 13) and for each entry creating and initialising a new element in the output traceability model. At each itera- tion, the source metamodel and its model is determined based on the value of endPoint2 for the entry (line 16 and 23). Then, according to the pattern of the mapping, the correspondent element is created or updated in the TM. For example, in line 25, the if statement shows the case in which an EClass in the TIM has been mapped to an EClass in one of the source metamod- els. In this case, for each object of type the EClass in the metamodel, an object of type the correspondent EClass in created and added to the TM (lines 29-34). The output of the transformation is a project-wide TM which conforms to the project-specific TIM (defined in line 6 in Listing 5.5).

Alongside the transformation, a utility model, so called equivalences, is generated which shows each model element in the TM is related to which model element from other models. This model is used to find the equivalent element to an element in the source models and use it in the transformation. For example, assume in model M, there are two model elements X and Y and there is also a 1-1 association between them. Both X and Y have an equivalent model element in the TM: X’ and Y’. Now, if we have to define a trace link between X’ and Y’ because of the existing association between X and Y, we need to find X’ and Y’, the equivalent elements to X and Y which have already been created in the TM, and then create a trace link between these two elements (X’ and Y’). The equivalence model is used to find X’ and Y’.

1 ...

2 //input: mapping model

3 var mappingModel : Any = inputMappingModel!MappingModel.all()

.first();

4

5 //output: traceability model

6 var traceabilityModel = ecoreUtil.create(TIM.theMetaModel);

7 traceabilityModel.name = mappingModel.name;

8 emfTool.createModel(traceabilityModel, " outputTraceabilityModel");

9 ...

10

11 //iterate over mapping entries

12 var entry : inputMappingModel!MappingEntry;

13 for (entry in mappingEntries) { 14 //endPoint1 always refers to TIM

15 var endPoint1 : inputMappingModel!ModelElementRef = entry. endPoint1;

16 var endPoint2 : inputMappingModel!ModelElementRef = entry. endPoint2;

17 var definitions = entry.definitions;

18 var conditions = entry.conditions; 19

20 //Select the elements belong to the specified source model

21 var inModelElements = sourceModelElements.get(endPoint2. owner.name);

22

23 //select the elements from the source model

24 var inModelElements = sourceModelElements.select(el | el.

eContainer().eClass().name = sourceMetaModel. theMetaModel.name).asSet();

25

26 if (endPoint1.type = inputMappingModel!ModelElementType# Clazz and endPoint2.type = inputMappingModel!

ModelElementType#Clazz) {

27 inputElements = inModelElements.select(el | el.eClass().

name = endPoint2.theElement.name);

28

29 var outElements : Sequence = new Sequence;

30 for (element : Any in inputElements) {

31 var outElement = outputTraceabilityModel.createInstance( endPoint1.theElement.name);

32 ...

33 }

34 ... 35 }

Listing 5.5: Part of the dynamic model transformation to generate the TM The next section (5.2.5) explains how the introduced traceability analy- sis language is defined and implemented in the prototype. Additionally, it demonstrates the execution semantics of the language in detail.