Step 3: Define the TIM

Once the traceability goals have been determined (step 1) and the related concepts in the project have been identified (step 2), the TIM is defined.

Figure 4.6: Part of the EMF model for the GQM model depicted in Fig. 4.4

According to [Espinoza et al., 2006], a TIM formally describes

– Traceable Elements: the objects that should be traced (captured and recorded)

– Trace Links: permitted traceability link types – Constraints: validity requirements

A TIM is defined at the abstraction level of traceability: it defines trace- able elements and valid trace link types between them, regardless of elements or associations not involved in traceability. Therefore, a TIM is a simple (but possibly a large) metamodel which specifies traceable concepts and relations between them through defining trace link types for the project. It also spec- ifies validity constraints that can not be specified by the metamodel itself. These constraints can be specified using any constraint language compati- ble with the metamodelling infrastructure. As discussed before, traceability models (instances of TIM) are conceptually related to other models in the project, as they contain concepts in common. However, TIMs are described independently from other models.

Through several experiments in defining or studying project-specific or domain-specific TIMs, we have identified the recurring patterns in the struc- ture and characteristics of traceability metamodels as discussed in [Taromi- rad et al., 2013]. Fundamentally, a TIM is defined from a traceability per- spective and is totally independent from development artefacts. Therefore, it usually includes elements and relations which are already defined and recorded in other models in the project. Additionally, a traceable element defines the minimum information required to support traceability queries

(i.e. name and ID) rather than containing all the properties and informa- tion for the associated concept. Therefore, the TIM can be used as the reference to collect required traceability information in the form of a TM which conforms to the TIM.

These recurring patterns led us to develop a core traceability metamodel –called CoreTIM– with the aforementioned characteristics. The CoreTIM defines the basic structure of a TIM and defines the fundamental elements which have to be included in a traceability metamodel. The core metamodel is to be extended and completed by users to include project-specific concepts and semantics. In the following section, we will introduce the CoreTIM and how it is extended and used in a particular project.

4.1.3.1 CoreTIM

The abstract syntax of the CoreTIM has been defined using Ecore and is illustrated in Figure 4.7 (with an example extension). In this section, the concepts of the coreTIM are explained in more detail.

Figure 4.7: Abstract syntax of CoreTIM

TraceabilityModel: Acts as the root of a traceability model. It contains a number of TraceableElements and TraceLinks and could be renamed to the user-defined name in the context of the project.

TraceableElement: Represents a traceable object which may be the end of a traceability link. It defines a name and can be associated to a number of the original traceable concept, which are represented conceptually by this TraceableElement. The class is extended, in the context of the given project, to specify the project-specific traceable concepts (e.g. class X and Y in Fig. 4.7). Note that at this step, the type of the associated target model element is not specified. This information will be identified and defined

later on during identifying the relationships between TM and other models (discussed in Section 4.3).

TraceLink: Represents a traceability link between two elements. It de- fines name and is extended to define concrete valid trace link types in the project. Each subclass (e.g. class XYTraceLink in Fig. 4.7) has two refer- ences to TraceableElements, named traceLinkEnd1 and traceLinkEnd2, to clearly specify the type of the trace link ends. traceLinkEnd1 and traceLink-

End2 represent the source and the target of the trace link respectively.

The TIM is also accompanied by constraints. Structural constraints, such as cardinality of references, can be expressed within the metamodel. For more complicated and non-structural constraints, such as constraints defined in terms of attributes and their values, model validation languages (e.g. OCL [Object Management Group, 2012] and EVL [Kolovos et al., 2009]) can be used. A typical example of complex constraints, in the context of traceability metamodels, is to describe the following condition: Assume that A, B, and C are TraceableElements, R1 is a TraceLink between A and B, R2 is a TraceLink between B and C, and R3 is a TraceLink between A and

C. Also, there are a, b and c of type A, B, and C respectively. Then, the condition is that if there is a trace link of type R1 between a and b, and a

link of type of R2 between b and c, there should be a trace link of type R3

between a and c.

4.1.3.2 Project-Specific TIM

A project-specific traceability metamodel is defined by extending the CoreTIM. The extension defines the project-specific TraceableElements and TraceLinks and expresses the specific constraints regarding the project in hand. Note that, at this step, the type of the original traceable concepts (targets reference in a TraceableElement) is not specified in the metamodel. The type of these concepts in terms of target model elements is defined in later steps in which engineers identify the relationships between the TM and other models in the project. After these steps, the TIM is updated to provide an accurate and semantically rich project-specific traceability metamodel.

A project-specific TIM can also define other concepts in addition to the traceable elements and trace link types. An engineer may need to record when a trace link is created and who creates it, or she might want to attach a note to each trace link to provide arbitrary information about a link. Such information has to be specified in the traceability metamodel which is an extension to the CoreTIM, so called ExtendedCoreTIM. An ExtendedCore- TIM defines additional classes, attributes, and associations with respect to the specified needs and preferences. It is then enriched with project-specific TraceableElements and TraceLinks.

For example, consider the goal-oriented approach used to identify traceability-related concepts and define a TIM accordingly. The GQM model

can be considered as the context or rationale for why a TIM is defined in its current way. So, a project-specific TIM can define an entity called Contex-

t/Rationale which can be attached to any entities and shows why an entity

is defined. Accordingly, a Context/Rationale for the whole TIM (root of the model: TraceabilityModel) or any element of it could have a reference to the GQM model of a project or an element of it. In Section 5.2.2, we illus- trate an example of extending CoreTIM through attaching GQM models to a traceability metamodel.

The project-specific TIM for the example project was defined based on traceability goals. As discussed in Section 1.1.1, traceability is a manda- tory requirement of safety standards (i.e. DO-178B RTCA and EUROCAE [1992]). In such systems, traceability from hazards to derived safety re- quirements and to implementation supports the safety argument to show that the system is operationally safe. In this context, we defined our trace- ability goal as ‘providing evidence for the safety argument: the implemen- tation is safe’. Based on the project development activities and artefacts, the project-specific traceability information model was defined accordingly. Fig. 4.8 depicts the TIM for the IADDS project based on the traceability goals.

As illustrated in Figure 4.8, the root of the TIM, ‘IADDSTraceabili- tyModel’, consists of concepts to be traced (‘TraceableElements’), such as ‘UserStory’, ‘DevelopmentModel’, and ‘Hazard’, and trace link types (‘TraceLinks’) which are defined between specific traceable elements, such as ‘Satisfy’ and ‘Mitigate’.

In the safety domain, hazards are categorised into two groups based on the result of safety analyses: mitigated and unmitigated. In the case of mit- igated hazards, at least one derived safety requirement is defined to prevent the hazard from occuring. In contrast, when a hazard cannot be prevented it is classified as unmitigated, hence there is no derived safety requirement for that hazard. Considering this, in the TIM for IADDS project, the ‘Hazard’ has an additional attribute called mitigated, indicating if the hazard is miti- gated or not. Accordingly, if a hazard is classified as mitigated there should be at least one element of type ‘SafetyStory’ and a link of type ‘Mitigate’ between the hazard and the safety story. This constraint is an example of complex inter-model constraints, which can be described with model vali- dation languages (EVL in our example project). Listing 4.1 shows the EVL code for this constraint. Other validation languages that allow evaluation of expressions over heterogeneous models (e.g. XLinkit [Nentwich et al., 2002]) could also be used.

1 context IADDSTIM!Hazard {

2 guard : self.mitigated

3 constraint LinkedToSafetyStory {

4 check : Mitigate.all().exists(

5 m | m.traceLinkEnd2 = self

6 and

7 m.traceLinkEnd1.isDefined());

8 message : "Hazard ‘" + self + "’ should be linked to at least one SafetyStory";

9 }

10 }

Listing 4.1: Example EVL constraint in the TIM in IADDS

As mentioned before, if we consider the TIM, it is observed that the trace- able elements contain requirements engineering, software development, and safety engineering artefacts, which most of them are recorded and available in the related context (domain). The TIM provides a comprehensive view of all the required traceability information by including them in one integrated metamodel.

Accordingly, we suggest extracting traceability information from available information (other models) and automatically create a traceability model which conforms to the TIM. Before explaining the steps to extract and create the traceability model, the available traceability information in dif- ferent domains will be studied in more detail; this appears in the next sec- tion (4.2). Then, the proposed approach to generate the TM is introduced

in Section 4.3.