Once the TIM has been defined, traceability information can be collected and recorded in a traceability model. But, as discussed before, consider- able amount of required information to support traceability is provided and available in models in different context or domains. Although these models might be defined for other purposes (not explicitly for traceability), they could provide traceability-related data. This section focuses on such infor- mation scattered in different domains, generally called as traceability-related
information, and discusses how this information can be used to generate a
project-wide traceability model. In this context, related traceability infor- mation is investigated to prepare the prerequisites to generate and populate the final traceability model.
As mentioned before, the required information, which supports traceabil- ity, could be represented in various formats (e.g. plain text, XML files) with different underlying structures and metamodels. To support analyses and an overall MDE approach to developing tools, we need to provide a model-based view of the non-model information (wherever it is possible and reasonable) as a prerequisite of generating a TM; this can be challenging. However, we focus on those models that are available and that information which can be automatically transformed to models: there are several types of model in different domains (e.g., requirements models, safety analysis models) that provide substantial traceability information. Our approach does not restrict the types of model that can be considered in a traceability solution, but in the illustrative example that follows we consider a specific set of models. 4.2.1 Investigate Available Information
Based on the TIM, available information (models) are investigated to find out how much of the required information is provided and available, in which ways, and how it can be used.
In general, there are two types of information:
1. Domain-specific information: information which is specific or lim- ited to one domain
2. Multi-domain information: information which covers two or more domains
For example, considering the general development process of the example project, the following information was available and provided in the involved engineering domains:
1. Requirements Engineering: Software System Requirements (plain text), Properties and Constraints (plain text), User Stories (tabular format)
2. Safety Engineering: Hazards (tabular format), Derived Safety Require- ments (tabular format), Safety Analysis Models, and the relationship between Hazards and Derived Safety Requirements
3. Software Engineering (Development): Architecture Model, Class Dia- grams, Test Cases, Code Segments
In addition to the above domain-specific information, the following multi- domain information is defined and provided:
1. Relationship between Hazard and User Story (in tabular format) 2. Relationship between Safety Story and User Story (in tabular format) As the result of this investigation, the available information including models and trace link types either within or between domains which sup- ports traceability is identified. Additionally, the investigation will identify the missing information which is essential to generate a complete project- wide traceability model such as models or a formal relationship between two concepts. This requires us to provide currently not provided data or concepts. The missing information is divided into two parts: that which is limited to a single domain; and that which relates to multiple domains, such as the relationship between concepts in different domains. Each of them has to be dealt with differently. We now elaborate on this in more detail. 4.2.2 Domain-Specific Information
As mentioned before, domain-specific information represents concepts and their relations within the context of a domain. In this respect, the informa- tion available as a model can be directly used to extract traceability infor- mation. On the other hand, to define and collect missing domain-specific traceability-related information –not available either in the form of a model or in any other format– one of the following alternatives could be applied.
1. Extend existing metamodels. In some cases, it is reasonable and possible to extend existing models to include missing information. For example, the missing info is a number of simple attributes. In these cases, the correspondence metamodels are extended by defining or adding new objects, attributes, and relationships (as associations or objects), and describing required constraints. Consequently, the target models have to be updated or regenerated according to the new meta- model. Nevertheless, depending on the type and size of changes in metamodels, particular practice need to be applied to update models with valid additional or new data.
2. Define new metamodels. In some cases, it is not possible to work with existing metamodels: 1. there is no artefact (in any format) which covers even partially related information to the missing one, 2. there are non-model artefacts covering missing information, for exam- ple within other tools (e.g. requirements management tools such as DOORS) or arbitrary structured documents (e.g. spreadsheets), and 3. the engineer cannot alter the metamodels with the new concepts (e.g. due to limited access, regulations). In these cases, new metamod- els have to be defined (from scratch) and instantiated as new (domain) models which include the missing information.
In the first case, depending on the type of the information and also possible and available ways for collecting data, required information could be captured by any heuristic method. The new models thereafter can be used and manipulated similar to other artefacts in the project. In the other two cases, different model transformation techniques (M2M, M2T, T2M) can be applied to transform the non-model arte- facts or models into the new models which also include the comple- mentary new data (missing information). For example, a spreadsheet, which is a common format for preparing documents in a project, can be transformed into desired models with user-defined T2M trans- formations or available tools specifically developed for this purpose (e.g. [Francis et al., 2013]). Most of the existing tools provide the fea- ture to export their data into spreadsheets. For example, DOORS, as the most widely used tool in industry to manage requirements and record traces between them, allows users to export the description of requirements and their relations to different formats including spread- sheet. The generated spreadsheets can be used to generate or populate the new models representing the missing information.
In these cases, maintaining the consistency between original artefacts or models with the new models is a challenge which is extensively studied in the context of MDE under co-evolution subject (e.g. [Rose, 2011]). Automatic model transformations partially address this is- sue, as they can be re-executed whenever any of the original artefacts change. This is possible when it does not invalidate the extra data previously and independently inserted into new models.
4.2.2.1 Example
Regarding the available information and their format (mostly provided in textual format in tables) in the example project, we define a new metamodel for each domain which defines the information in that domain. Existing in- formation (tables) is then transformed into new domain models. Figure 4.9 and Figure 4.10 depict the main artefacts in safety and requirements engi-
neering domain as the metamodel for these domain models. The metamod- els also show the association relationships between concepts in each domain which are later on translated into trace link types in the TIM.
Figure 4.9: The metamodel for the safety domain
Figure 4.10: The metamodel for the requirements engineering domain
4.2.3 Multi-Domain Information
After investigating the required information in each domain and provid- ing the information as models, the multi-domain information is considered. Multi-domain information encompasses concepts from different domains. It mainly represents the relationships existing between two domains. One of the main unavailable traceability-related data is a precise and formal defini- tion of the relationships between domains. The available traceability-related information (mainly trace links) is usually limited to one domain. In this respect, we focus on the relations between domains.
To represent the relationships between domains, so called inter-domain trace links, we propose building a traceability model –so called partialTM–
between pairs of domains to keep record of inter-domain trace links. We define a traceability information model for each partialTM. Each traceabil- ity information model –called partialTIM– formally or explicitly defines the inter-domain trace link types. Basically, a partialTIM is defined by extend- ing the CoreTIM; each partialTIM can be considered as a slice of the main TIM only containing those elements that are directly related to each other (with a trace link). Figure 4.11 conceptually shows the relationship between partialTIMs and the main TIM.
Figure 4.11: How a TIM and partialTIMs are related
A partialTIM clearly specifies the required trace link types and the type of trace link ends for each trace link type. There are two kinds of inter-domain traces:
1. Equivalence trace: This type of trace shows equivalent concepts in two domains. In this case, a concept from one domain is redefined and reused in another domain (possibly with new name), though they represent an identical concept.
2. Relationship trace: These traces are used to show relationships be- tween elements from two different domains that are related to each other, in some way, but they are not equivalent.
Although, in this thesis, partialTIMs are defined manually, they can be defined semi-automatically by using different type of model management operations, for example, by comparing traceable entities, defined in a TIM and linked directly with a trace link type, with available entities defined in different domains. Through such comparison, it is possible to identify potential relationships between two domains and, hence, a partialTIM. A partialTIM can also be defined based on the available onthologies, which provide description of concepts in different domains, and available knowledge
of how concepts of anthologies are related. These would specify the potential partialTIMs.
Inter-domain trace links can be identified and captured manually or semi- automatically (i.e. through model comparison). In the manual case, the user manually defines the traces between domains based on the correspon- dent partialTIM, while in the latter form traces are identified with model comparison. In this case, the users might need to check the identified traces to select valid traces to be recorded.
4.2.3.1 Example
In the IADDS project, we define the required traceability metamodels for the inter-domain trace link types. Figure 4.12 shows the partialTIM between the requirements engineering and safety engineering domains which defines a relationship trace link type, named ‘UserStoryToAssessmentTL’, between ‘UserStory’ and ‘Assessment’ in addition to an equivalence trace link type, named ‘SafetyStoryToDerivedSafetyReqEL’, between ‘SafetyStory’ and ‘De- rivedSafetyRequirement’. In this example, the trace links are captured and recorded manually.
Figure 4.12: The partialTIM between requirement and safety engineering domain (ReqSafety-partialTIM)