Locating Source Elements

In this step, the model elements in the TM are mapped into model ele- ments in source models. The mapping formally specifies how each concept (traceable element or trace link type) defined in the TIM relates to model elements in the other models. It is used to collect information from other models in order to automatically generate the project-wide TM. It could also be used to interpret the result of traceability analyses in terms of the source models in different domains. The mapping is expressed in a model which conforms to a mapping metamodel. The mapping model is similar to a Cor- respondence Model (CM) or Weaving Model (WM) in model composition [B´ezivin et al., 2006]. A CM or a WM is a model that explicitly describes the relationships between elements of different models, but is constructed specifically for model comparison or merging processes.

We captured the specific requirements for the mapping model regarding the context of this work and how it would be used in the proposed trace- ability solution. Accordingly, the metamodel

Figure 4.13: Generating the traceability model

– is defined at the metamodel level and refers to (Ecore) metamodels (R1)

– is used either to generate the TM and translate the result of trace queries in terms of the source models (R2)

– defines what element maps to what element (R3) – explains precisely how two elements are related (R4)

Additionally, we determined that in order to have complete information to generate the TM, the mapping model should capture two types of rela- tionships between models:

1. Relationships between a TM and other models, called Mapping En-

try in the model; they define how each element in TM is related to

elements in source models. For example, regarding the TIM for the IADDS project (Figure 4.8) and the partialTIM between requirement and safety domains (Figure 4.12), the ‘Assess’ trace link type, in the TIM, maps to the ‘UserStoryToAssessmentTL’ between ‘UserStory’ and ‘Assessment’, in the partialTIM between requirements and safety engineering domains.

2. Relationships between models except TM, called Equivalence Entry in the model; they define equivalent elements which are those elements that represent a common concept in different domains. For example, in the IADDS project, ‘SafetyStory’ in the requirements engineering domain (Figure 4.10) is equivalent to ‘DerivedSafetyRequirement’ in safety domain model (Figure 4.9).

Figure 4.14 shows the examples described above for each type of rela- tionships. A mapping relationship (highlighted in red) is defined between the TIM and the ReqSafety-partialTIM (the partialTIM between the re- quirements engineering and safety engineering domains). Two equivalent elements in requirements engineering and safety engineering domains are shown and highlighted in blue.

Figure 4.14: Graphical view of example relationships between the TIM and the ReqSafety-partialTIM

According to the above mentioned requirements and properties, the map- ping metamodel has been defined using Ecore, as depicted in Figure 4.15.

4.3.1.1 The Mapping Metamodel

In this section the concepts of the mapping metamodel are explained in detail.

Figure 4.15: Mapping Metamodel

MappingModel: Acts as the root of the mapping model. It defines a name and contains at least two ModeRefs which represent the TIM and other involved metamodels (Ecore metamodels). It also contains a number of MappingEntries and EnquvalenceEntries.

ModelRef: Represents a metamodel of the model used to generate the final TM. It defines name and contains a number of ModelElementRefs defin- ing the elements from this metamodel which are used in the mapping model. ModelElementRef: Represents an element of a metamodel which is used in the mapping model. It can be a model, a class, an attribute, or a reference.

MappingEntry: Represents a mapping between a model element in TIM with a model element in another metamodel. Each mapping defines two ModelElementRefs (as end points of the mapping) and a number of Defini- tions and Conditions.

EquivalenceEntry: Defines an equivalence relationship between two model elements from two different metamodels (other than the TIM). An EquivalenceEntry is a kind of MappingEntry with an additional reference (corrTraceLink) to the related partialTIM (which defines the equivalence traces between two related domains). This reference is required to find equivalent objects when generating project-wide TM.

Definition: A statement indicates how the two end points of a mapping are exactly related to each other (e.g. endPoint1.name=endPoint2.ID)

Condition: A statement specify the condition in which an entry is valid and used.

A ModelRef refers to metamodels and a ModelElementRef represents a type defined in the metamodels (requirement R1). The MappingEntry and EquivalenceEntry address the requirement R3 and the two relationship types necessary to generate the TM. With Definition and Condition users express how two elements are related (requirement R4) which is used to automati- cally populate the TM with correct and valid values for the model elements. A mapping model, which conforms to the above metamodel, is a high- level specification of the model transformation rules which are required to extract information from the source models, create the TM, and populate it with this information. The transformation is obtained by translating the mapping model into low-level, executable model operations. Section 5.2.4 explains how the mapping model is used to generate the TM.

4.3.1.2 Example

Figure 4.16 shows an example of mapping and equivalence entries from the case study which were explained above. As shown in the figure, the map- ping model works with four metamodels: the IADDS TIM, the metamodel for requirement and safety engineering domains, and the partialTIM be- tween Requirements and Safety domain, and so has four elements of type ModelRef representing each of them. The mapping entry, named ‘Assess- US2ASS’, maps the ‘Assess’ trace link type, in TIM, to the ‘UserStory- ToAssessmentTL’, in the partialTIM between requirement and safety en- gineering domain. It contains definitions indicating how to initialise the ‘Assess’ object in the generated model (reserved words start with ‘ ’). For example, the first definition indicates that the name of the ‘Assess’ object would be the same as the name of the source model element and the sec- ond definition says that the ‘traceLinkEnd1’ of the new object is equal to the ‘assessment’ property in the source model element. The equivalence entry, named ‘SafetyStory-DerivedSafetyReq’, shows that the ‘SafetyStory’ and ‘DerivedSafetyRequirement’ are equal and the correspondent trace link type is ‘SafetyStoryToDerivedSafetyReqEL’ which is defined in ReqSafety- PartialTIM (refer to Figure 4.12). The definitions for the equivalence entry indicate how each end point of the entry relates to the corresponding trace link.