Lean requirements traceability automation enabled by model-driven engineering

A. Traceability challenges

The work presented by Gotel & Finkelstein (1994) is a cornerstone paper in requirements traceability research. Its authors describe the main problems of requirements traceability, including the lack of a common understanding, the need to allocate time and resources, and the gathering and maintenance of trace information.

Rempel & Mäder (2016) also focus on traceability difficulties, providing an assessment model and a comprehensive classification of possible traceability problems and assessment criteria for systematically detecting those problems.

A more recent literature review was carried out by Tufail et al. (2017). This review focused on requirements traceability techniques, models, and tools, offering detailed analysis and comparison and providing a set of comparative tables. It distinguished, among other things, between traceability metamodels, traceability process models and traceability information models. The work included a general list of 10 traceability challenges, and a more detailed analysis of traceability tools.

The present article focuses on the way its proposed approach could address traceability problems and challenges and overcome what are ostensibly the most relevant challenges identified in the above-mentioned papers, namely: the automatic generation of traces (Ch.#1), tool support for trace model maintenance (Ch.#2), return of investment (ROI) measurement (Ch.#3) and demonstration of the benefits of traceability in real examples managed by real users (Ch.#4).

The efficient management of traceability is another key factor to consider when combining data from different sources to generate more complete, improved and more accurate information. As such, it is also critical for information fusion. For information fusion to be successful, it is necessary to know the origin of the information in order to trace it in case of any change in the future. Trace management tools are therefore critical to guarantee the correct maintenance of fused information.

B. Metamodeling traceability

Several metamodels have been published during the last two decades covering different aspects of traceability, and in particular related to requirements traceability. As in the metamodel comparison of Carniel & Pegoraro (2018), in the present study a set of criteria were defined for comparing the metamodels relevant to the objectives in question. These criteria include support for: (1) textual, graphical and/or model representation of requirements, (2) associations between traceable elements, (3) horizontal and vertical traces, (4) definition of an algorithm or rules, (5) trace maintenance (6) change impact analysis.

Most research and most metamodels in the field of traceability (e.g., Haouam & Meslati, 2016; Walderhaug, Hartvigsen & Stav, 2010; Sousa et al., 2008; Goknil, Kurtev & Van Den Berg, 2014) have to date focused on the creation of traces, i.e., on aspects (1), (2) and (3) above, but have neglected monitoring and maintenance, i.e., aspects (4), (5) and (6), which are the focus of the present work (see Fig. 3). The main approaches to traceability maintenance (Briand, Labiche & Yuea, 2009; Boronat, Carsí & Ramos, 2005; Cleland-Huang, 2006; Kassab, Ormandjieva & Daneva, 2009; Drivalos-Matragkas et al., 2010) are briefly discussed below.

Drivalos-Matragkas et al. (2010) graphically represent a tracing metamodeling language that covers tracing and maintenance concepts in a manner similar to that of the metamodel envisioned in the present study. Their approach, however, is state-based, unlike that of the present study, which is event-based and focuses on the detection of dangling links.

Briand, Labiche & Yuea (2009) focus on changes between two versions of a UML model (vertical traces only) and analyze the impact of those changes using formally defined impact analysis rules (written in Object Constraint Language). Traces between model elements are not included as first citizens in their metamodel.

Boronat, Carsí & Ramos (2005) had as their objective to provide generic traceability support to solve specific problems such as change propagation. Their metamodel provides a metaclass manipulation rule for each trace link, but change management is not included at metamodel level.

Cleland-Huang (2006) propose an event-based approach to traceability maintenance using observation to detect changes in the requirements models. These observes check then potential changes in the trace links. Potential changes in the trace links are then checked Unfortunately, this work provides no graphical representation of the approach.

Kassab, Ormandjieva & Daneva (2009) consider the tracing not only of functional requirements (FR) but also of non-functional requirements (NFR). Their metamodel includes metaclasses for both types of requirements and their associations, but metaclasses for change management are missing. Instead, they opt for XML-based representation and XQuery implementation for traceability management.

C. Integration of automated trace management in MDE tools

Traceability integration in a model-driven approach requires the definition or extension of metamodels and transformation rules for the automated generation and analysis of traces. The work involved in establishing these definitions is limited and required only once for each tool supporting a development methodology. The advantages of using a model-driven engineering approach are widely documented in the literature (Winkler & Pilgrim, 2010; Escalona et al., 2007; García-García et al., 2015). In particular, Winkler & Pilgrim (2010) provide an overview of research and practice in traceability and requirements engineering focusing on use of MDD for trace generation. The information presented is classified into four categories: basics, working with traces, practice, and solutions. The work addresses the generic use of traceability information, its visualization, and its usability, but does not address the exchange and analysis of such information.

Cleland-Huang (2006) focused on links between, on the one hand, textual documents and models and, on the other, documents and code. Walderhaug, Hartvigsen & Stav (2010) instead propose a generic MDD traceability solution based on guidelines and templates. The links proposed by Cleland-Huang (2006) are generated automatically but require acceptance or rejection by the users of the proposed tools. The main issues are the amount, granularity and quality of the links generated, so the authors discuss a set of metrics for evaluating the effectiveness of automated traceability. Although the amount of trace links generated in their approach is limited, the problem remains of how to maintain a list of links that may have become outdated due to the modification of artifacts.

In contrast to these approaches, Briand, Labiche & Yuea (2009) present a horizontal and vertical traceability impact analysis based on metamodeling and OCL constraints. Their metamodel includes tracing and monitoring concepts similar to those in the present study, but is dependent on the type of representation selected for the concepts (UMLDiagram and ClassDiagram, for example). However, this proposal focuses exclusively on change impact analysis, ignoring other traceability-related practices.

As part of the AMPLE project, Anquetil et al. (2010) presented a traceability metamodel focusing on trace links, trace context and model artifact types, while Goknil, Kurtev & Van Den Berg (2014) presented a metamodel that relates requirements and architecture models through traces (the approach proposed in the present study is even more generalizable than this, as it has no restrictions regarding model types). Traces are generated automatically but in an iterative process. The associated tool, which supports generation and validation, is based on model transformations in ATL and term rewriting logic in Maude. Another formal approach based on Maude is that adopted in a MOMENT project that uses QVT for model transformations and OCL constraints (Boronat, Carsí & Ramos, 2005) for the definition of generic operators. Haouam & Meslati (2016) describe a traceability maintenance approach based on model comparison, change detection, classification, and link evolution. Here, traces are generated automatically and the updating process is (semi)-automatic.

D. Use of traceability in real software development projects

Reports on the use of traceability in real software development projects are difficult to find. Many approaches are illustrated using textbook examples, as is the case of Walderhaug, Hartvigsen & Stav (2010) and Briand, Labiche & Yuea (2009). In contrast, the approach proposed in the present study has been used in several real software development projects. A systematic evaluation is not included in this paper as it is still work in progress.

The present approach also differs from that of Walderhaug, Hartvigsen & Stav (2010), who focused on a conceptual solution for tool integration and implemented a set of plug-ins for the Eclipse platform using Rational Software Architecture (RSA), insofar that its goal was to facilitate the extension of development tools without using complementary tools.

The survey by Winkler & Pilgrim (2010) focuses on traceability in the areas of both MDE and requirements engineering. The authors mention the gap between industry and the solutions proposed by academic researchers, and highlight the need to support traceability as part of development processes.

One interesting work on best practices for the establishment of automated traceability in enterprises is that presented by Cleland-Huang (2006), in which the following criteria were established to make automated traceability possible in industry: the establishment of an appropriate environment, the creation of traceable documents, and automated trace processes. The second criteria is not relevant for an MDE approach.

Haouam & Meslati (2016) validate their work with a study focusing on two research issues: the reduction of the manual effort required to generate and maintain traces, and maintenance quality in comparison with manually maintained traces.

A. Building upon an MDE approach

The Model-Driven Engineering paradigm consists of raising the abstraction level of software development. It is based on models, transformations, and appropriate modeling and transformation languages. Models are the key artifacts during definition, design, implementation, and deployment. There are two kinds of modeling: metamodeling and design level modeling, corresponding to two different levels of abstraction and providing, respectively, abstract and concrete syntaxes.

At first glance, this would appear to introduce a high degree of complexity, but that is not the case. Source and target metamodels define the relationship between concepts and need to be modelled only once. In the same way, model transformations are only defined once, unless the metamodel changes.

At design level, target models are generated automatically from source models, which are constructed on the underlying source metamodel. This means that additional modeling efforts are not needed, no matter how many models the transformations are applied to. Following the same principles, traces can be recorded during the transformation-based process which generates the target models. A set of traces constitutes a trace model, which can be generated automatically once the tracing rules are established: i.e., once the relationships between software artifacts of the same or different levels of abstraction are known.

The present study focused on bidirectional traces, traces going both backwards and forwards: i.e., from the origins through development and specification to subsequent deployment and use, and back to the initial requirements. It also distinguished between vertical, horizontal and evolution traces. Vertical and horizontal traceability refers to relationships between software artifacts at different or the same levels of abstraction and is also known as intra and inter traceability. Evolution traces are links that indicate different versions of the same software artifact. Examples of traces are shown in Fig. 4.

To implement an MDE approach (Brambilla, Cabot & Wimmer, 2012; OMG, 2021, https://www.omg.org), metamodels are represented using different languages, such as the Unified Modeling Language (UML) and Domain Specific Language (DSL). The languages most frequently used to specify transformations are Query-View-Transformation (QVT) and the Atlas Transformation Language (ATL). Modeling and metamodeling activities are supported by frameworks like Eclipse or UML CASE tools like Enterprise Architect or MagicDraw, while environments like SmartQVT and EMF (Eclipse Modeling Framework) for ATL can be chosen to support the transformations and the tracing process.

There are different ways to represent traces. One of the most commonly used techniques is the traceability matrix (TM). More challenging issues are how to maintain consistency in the TMs required for the target models in case of changes in the source models and the implications that changes in the target models may have for the source models. It is always possible to completely regenerate target models and TMs, but this solution is neither economic nor possible if the target models have been adjusted.

The following sections describe the proposed MDE approach. It is an approach that goes beyond the automatic generation of target software to actually document all traces resulting from the generation process, and manage those traces in order to discover and repair inconsistencies and identify conflicts when source or target software models are modified.

The approach is described at three different levels of abstraction: (1) a general theoretical level, independent of specific software development techniques and technologies, (2) a practical, methodological, level that is tool-dependent but project-independent, and (3) a project-related example.

For the theoretical level, a metamodel was developed which describes relationships in an MDE-based approach to traceability management (see Section B below). The practical and project-related levels are presented later, in the Tool Support for Model-Driven Traceability section.

B. Metamodel for traceability

Traceability management comprises the creation and maintenance of tracing models. Maintenance refers to changes in the models of the different software development phases. A (semi)formal specification of this traceability management approach was obtained using metamodeling as the description technique.

The proposed metamodel is similar to several existing metamodels mentioned in the Related Work section. However, it differs in its explicit metamodeling of the traceability mechanism and the change management elements. These are represented by the metaclasses TraceRules, Change, Warning and Error (see Fig. 3).

The key aspects in traceability management are identification of products from the specific contexts to be traced and the creation and monitoring of the traces detected. These aspects are represented in the metamodel shown in Fig. 3 as context, tracing, and monitoring models, represented in turn by the UML classes ContextModel, TraceModel and MonitoringModel.

Although colors have no semantic value in UML models, they are used in Fig. 3 to visualize the different aspects addressed by the metamodel: the context— that is to say, the models of the software development process (requirements, design, testing…)—is depicted in yellow, the traces in orange, and the monitoring of the models’ evolution in green.

The trace model is modelled as a composite of trace links relating elements of a source context model (for example, a requirement use case model) with the elements of a target context model (for example, a class model in the design phase). The related elements in the context model are the so-called “traceable” elements in the metamodel. These concepts are represented in the metamodel by the classes TraceableElement and TraceLink.

The relationship between source and target elements is based on predefined trace rules, which are explicitly metamodeled by the class TraceRule. Although denominated rules, they may comprise any type of algorithms for the creation or checking of traces.

TraceableElement describes any artifact in a context model and is identified by its attribute name. In the example of the patient (Fig. 1), for instance, a TraceableElement might be the storage requirement (SR-01), the class (CL-01) or the database table (TL-01), but also their attributes.

TraceLink and TraceRule are characterized by an ID and the definition of an algorithm. Every TraceLink has at least one source and one target TraceElement. TraceLink(s) for a software system are generated based on the TraceRule(s) definition for a specific methodology. A trace rule provides a formal description of the relationship between different elements of metamodels. In the example of the patient, a TraceLink would therefore be the relationship between the Patient Storage Requirement (SR-01) and the Patient Class in the analysis model (CL-01).

The proposed metamodel supports bidirectional TraceLink(s). Source and Target represent the directions in which transformations are executed to create the links. Vertical and horizontal links are both supported, depending on whether Source and Target belong to different versions of the same model or to different models.

Each context model consists of a set of traceable elements, while a tracing model is the set of trace links. ContextModel is therefore specified as a composite of TraceableElement(s), and TracingModel as a composite of TraceLink(s) and TraceRule(s).

The proposed metamodel includes explicit change management, indicating the impact changes have on the models. Context models are therefore monitored to detect changes in their traceable elements. Changes imply the need for traceability maintenance 0. Each modification of an element in a source context model is analyzed and may result in the automatic modification of the target context models and, if possible, of the corresponding trace links. Similarly, changes in a target context model may have implications for the source models. In both cases, a warning message alerts the user about the changes. If a conflict cannot be resolved, i.e., adjustments cannot be uniquely identified, an error message will be generated since a user decision is required.

In the example cited previously, the inclusion of the new European Health Identification Number attribute in SR-01 causes a change in both the class and the table because it requires a new attribute to be added to each of them.

The concepts described above regarding the monitoring and evolution of models are included in the traceability metamodel as a set of metaclasses and relationships. Unlike existing traceability metamodels, the proposed metamodel explicitly models the impact of changes, including those in the MonitoringModel, Change, Warning and Error classes. An error indicates that the associated trace link is no longer valid and constitutes a special instance of warning, so the relationship is specified as an inheritance.

Just as the ContextModel is specified as a composite of TraceableElement(s) and the TracingModel is specified as a composite of TraceLink(s) and TraceRule(s), the MonitoringModel is defined as a composite of Change(s).

C. Applying the MDE-based traceability approach

The traceability metamodel presented in the previous section is what is known in MDE terminology as a platform-independent model (PIM); that is to say, it is independent of the technology selected to develop the software. Even more importantly, it is also independent of the methodology used for the software development. This means that any model-driven software modeling methodology can implement traceability, instantiating our traceability metamodel and implementing the automated generation and monitoring of traces in the tool that supports the corresponding methodology.

This section describes a process for integrating traceability management in an existing methodology M with tool support T. In this process, it is important to distinguish the following roles:

• Methodology Expert is the person who manages or defines a concrete methodology M and who will implement the extension of M in the corresponding tool in order to support traceability.

• Developer is the person or team who uses methodology M and tool T to define their software projects.

The process of enriching methodology M with the proposed MDE-based traceability approach is mainly an activity that has to be performed just once by the methodology expert, or, exceptionally, more than once in the case of improvements to M. It consists of the following steps. For a graphical overview, see Fig. 5.

1. Selection of the subset of artifacts in methodology M that tool T has to trace, and storage of the corresponding information in, for example, a traceability matrix. These selected artifacts are instances of Traceable Elements (see Fig. 3).

2. Identification of the traces, based on the transformations observed between the artifacts selected in Step 1. Using these TraceLinks, the methodology expert has to define the TraceRules. These rules establish which artifact A is traced with which other artifact B, and its conditions, so that changing A necessarily implies modifying B to maintain information consistency. These rules are in general transparent for the developer, who uses the methodology M support tool to implement projects but has no knowledge of the rules that are used to generate the traces.

3. For monitoring, the process needs to identify the changes in TraceableElement(s) in the models, and the consequences of those changes. It must then decide if an automated solution of conflicts is possible: i.e., if a warning or error message should be communicated to the developer. This is an event-based approach to traceability maintenance.

4. The methodology M support tool then has to enable the management of Warning and Error messages.

5. The methodology expert has to define the way the MonitoringModel will be displayed to developers, by selecting, for example, a traceability matrix.

To summarize, a traceability support tool has to be able to (1) store trace links according to the trace rules in an appropriate format, e.g., a traceability matrix, (2) monitor the traces if source or target models are changed, and (3) display warning and error messages when conflicts are detected.

It can thus be concluded that the application of the proposed traceability management approach is a task that has to be defined and implemented by the methodology expert. Once integrated in the tool, it will be transparent to software developers, who will only see a monitoring mechanism for dealing with trace conflicts.

A. Brief overview

NDT is an MDE methodology that mainly focuses on web system requirements and analysis. Well-accepted in the industry (Escalona et al., 2007), its tool is implemented as an Enterprise Arquitect plug-in (García-García et al., 2015) and covers all phases of the software development life cycle. The latest version of NDT was improved with Design Thinking principles such as user empathy, early user incorporation, and the generation of prototypes. It supports three main phases in the software development lifecycle: conception, definition/design, and operation. Each of these phases is divided into a set of activities, such as functional requirements, capture, or architecture definition.

In this paper, NDT is used to show how the proposed approach allows for an extension of MDE-based software development methodologies integrating traceability support. The paper also shows how this traceability approach can then be used in enterprise projects. It does not aim to present a complete description of the NDT lifecycle. In this case, priority was given to the definition/design phase, focusing on three activities: design, construction, and verification and validation. The example shown corresponds to design activity.

The team’s main tasks during this activity were to define, analyze and design the following set of models for the future system:

• Functional Requirements, represented as a set of use cases that can be enriched with activity diagrams or scenarios.

• Conceptual Models, for the static view of the system.

• Mockups, to represent the screens of the system to be built. These were derived by transformations from prototypes and provide trace links between design and software conception.

• Non-Functional Requirements, used to document aspects of the system like usability, reliability, and security.

• Functional Testing, which was automatically derived from the functional requirements by transformations and offered a first validation of the requirements.

• Interaction Flow Model (IFM), which provided the relationships with all the other models and was the basis from which the architecture model was derived.

• Architecture Model, which made it possible to represent the software architecture—that is to say, the relationships between software components coded in different programming languages—and, more specifically, to model the model-view-controller pattern. Micro services and event-driven patterns will be considered in future versions.

B. Extending the methodology

The NDT models were built using the elements provided by the corresponding metamodels of the methodology, a so-called Domain Specific Language (DSL). Just as elements of the metamodels are related, so are those of the NDT model. These relationships are the basis for defining transformations and trace rules. The development team is able to see that an artifact is connected to others of the same system, but cannot see the metamodels.

In the first phase, prototypes are defined and, from these prototypes use cases can be generated. From the use cases, the methodology allows functional test cases to be generated. If the team detects an error or a problem in a functional test case, they can trace it back and find which user(s) validated the prototype in the Software Conception phase. In this regard, trace generation is automatic and trace management is semiautomatic, since the team needs to intervene to find a solution for any traceability problems that are detected.

Models of each phase are connected to other models of the same phase and to models of other phases—these are the horizontal and vertical traces mentioned earlier. These rules have now been specifically established and hardcoded within the tool. The traces are depicted in Fig. 4 which, to aid readability, shows only a representative excerpt of models corresponding to the Software Definition phase and a limited number of relationships. Figure 4 includes Functional Requirements, Mockups, Functional Testing and IFM models. A relationship between two elements in the figure means that there is dependency between those two elements. One of them is the source and the other is the target of the trace. For instance, the relationship marked with a number 5 means that the use cases are directly related to functional tests, and that a TraceLink (see Fig. 4) should exist between them.

In Fig. 4, only vertical traces are included, as the example used only relationship types 2, 3 and 5, but the NDT suite also supports other kinds of traces, like horizontal and evolution traces. These relationships were used to implement the design basis for the ContextModel and the TraceModel (see Fig. 3).

Figure 6 shows a specific trace coded in the NDT suite. Specifically, it depicts the trace that was established between Step and UIStep from ScenarioDiagram, and TestStep and TestUIStep from FunctionalTest.

C. Example

To visualize the use of the proposed traceability metamodel, this section presents one of the real industrial software projects in which this traceability approach was applied. The objective of the iMedea project (G7 Innovation, 2021) is to create a software solution for clinical history management in human reproduction environments. It is a highly complex system that supports all functional requirements for the study and treatment of reproductive problems and diseases, and also non-functional requirements such as a complex data security system, support for medical standards and 24*7*365 maintenance mechanisms.

The system includes more than 75 different use cases, including in vitro fertilizations, human sperm donation and human artificial insemination processes.

Here, the proposed traceability management approach is illustrated in the functional requirement “Anamnesis creation”, although the same approach was used for all the system’s requirements. The first time a patient attends a clinic, a set of standardized data corresponding to that patient’s clinical history is collected. That data set is called the anamnesis, or medical history. Figure 7 shows an activity diagram illustrating a simplified version of this use case. It represents the main flow (depicted with a thick line) and an alternative flow (the thin line). Whenever a new patient is registered, a gynecologist (iMedea user) will perform the anamnesis as a first step in collecting a large amount of data from the patient.

When the user selects the option “Anamnesis” the system displays the corresponding form. The user inputs the required information and the system checks that the data is correct and complete. If it is, the system creates the anamnesis and returns to the starting point. If not, an error message is generated and the system returns to the anamnesis form.

D. How traceability is implemented

The methodology outlined in Section A is fully integrated into the NDT suite, a set of tools that supports development teams in the application of MDE technology and traceability. The tool and the example described above in Section C were used to validate the proposed approach.

The tools required for implementing traceability were:

• NDT-Profile. As explained in the previous section, concepts used for each type of model in the methodology are modelled as metaclasses. A set of metamodels was defined for these related concepts. The metamodels, too, were interrelated. For each metamodel, a specific UML Profile was created which defined a DSL (Gutiérrez, Escalona & Mejías, 2011) that could be used in practice to model without requiring familiarity with metamodels. Actually, NDT offers a set of tools that can be used to draw different models, including prototypes, functional requirements, and test cases, while ensuring that the metamodels are correctly instantiated. This tool made it possible to implement the DSLs as an Enterprise Architect plugin. Relating this tool with the metamodel of the proposed traceability approach (see Fig. 3), it was also possible to build the ContextModel and its TraceableElements (the yellow area in Fig. 3).

• NDT-Driver. This tool supports the MDE generation of models: i.e., the obtaining of target elements from source elements. It implements the transformations defined in the methodology in C# language. The creation of the TracingModel (the orange area in Fig. 3) with the corresponding TraceLink(s) is a completely automatic activity. Whenever a transformation is executed, this tool stores the source, the target, and their relationship in an internal data base so that the relationship can be updated to reflect future changes or product evolution.

• NDT-Quality. This tool permits the automatic checking of models. It is the tool in charge of the MonitoringModel identifying the changes (the green area in Fig. 3). It deals with each error by sending a warning if a change is detected, or an error message to the team if a problem is detected and cannot be solved automatically. Conflicts are thus resolved semi–automatically, while conflict detection is automatic.

Traceability is implemented in this tool environment by automatically generated bidirectional relationships. For this purpose, a set of trace rules was used which followed the schema provided by the traceability metamodel presented in Fig. 3. Figure 8 shows an UML object diagram with nine different trace rules, which in turn represent the relationships in the UML diagram between the elements of the different design models shown in Fig. 4. Each number in Fig. 8 refers to a relationship in Fig. 4. The example shown in Fig. 9 explains how relationships were automatically generated. One of the transformations generated functional tests from the activity diagrams associated with use cases (see the relationships numbered 2, 3 and 5 in Fig. 8). For each path in the activity diagram, a scenario was generated corresponding to a test case. The diagram in Fig. 7 shows a main path and an alternative path, conditioned by a loop. The tool could be configured to guarantee the desired degree of coverage. In this case, it was configured to consider only one loop and to generate only two test cases. The tests generated automatically were those corresponding to the diagrams depicted in Fig. 9.

E. Automated generation of traces

The objective of this work was not to describe in detail the method of generating tests but to analyze how relationships are created. For more details on the process of systematic evidence generation, the reader is referred to Gutiérrez, Escalona & Mejías (2011). At least one TestUIStep is generated from each UIStep and at least one TestStep is generated from each Step. In this case, as the loop was not considered, only one element was generated for each UIStep and for each Step. In the generation process, a scenario, represented as a simple activity diagram, shows the steps that a user should execute in order to partially validate a part of the activity diagram represented in Fig. 7. In the previous scenarios, decisions and values were predefined by the transformation that generates each test. Thus, although the decision element is retained for the sake of readability, only one path is given for each test.

With this in mind, the following sequence diagram shows how the tools interact to generate these relationships (see Fig. 10).

When the developer creates the UIStep “Creation Anamnesis” and executes the transformation to generate test cases, the plug-in NDT-Driver asks NDT-Quality if the corresponding activity diagram is consistent and conforms to the relevant methodological principles. If it is OK, the TestUIStep “Creation Anamnesis” is created, together with a TraceLink object that stores this relationship (denominated StepTL in Fig. 7). The developer is notified of the correctness. The same process is performed several times, depending on the loops and decisions (in this example, only twice) for each activity in the activity diagram.

TraceLinks can be visualized in two different ways. Firstly, clicking on an element traces all elements related to that element. In this example, Fig. 11 shows the trace elements when the “Creation Anamnesis” activity is selected.

Secondly, the tool displays TraceLinks in a way not specifically oriented to each artifact, thus offering a global trace matrix that shows how all the sources are related to all the targets. The tool can be configured to select a set of sources and a set of targets. In this example, relationships between UIStep(s) and TestUIStep(s) were selected. The resulting matrix is shown in Fig. 12.

F. Automated monitoring of traces

Once TraceLink(s) have been created, the Quality plug-in checks consistency whenever a change is made—for instance, if a new activity like “Fill in personal patient data” is added to the activity diagram in Fig. 7. The updated activity diagram is shown in Fig. 13.

If the project is checked again or the project is closed, an error message will be displayed indicating that some information was lost for TestUIStep(s). The trace rule establishes that for each UIStep there has to be at least one TestUIStep. If this relationship is broken, an error is therefore caused. When this happens, the user could automatically navigate to a support panel that helps them to find and understand the error and to solve it. The quality control plug-in verifies that each Change is performed according to the TraceRule(s); it also generates Error(s) and Warning(s). If an inconsistency is detected, a message is sent to the developer with a recommendation to re-execute or update the transformations. The sequence diagram in Fig. 14 illustrates the process described above.

In the traceability matrix shown in Fig. 15, the problem can clearly be seen: one of the UISteps is not connected to any TestUIStep(s).

In the matrix, the developer could click on “Fill in personal patient data” to navigate to this artifact and perform the appropriate act to keep the traceability consistent.

Alternatively, the developer could save the project with errors, which can be solved in future editions, to continue with the project. This would guarantee that all artifacts and models in the project are consistent.

The three tools presented above help to manage all aspects of the proposed traceability metamodel: creation of the ContextModel by the developer, generation of the TracingModel, analysis of changes following the MonitoringModel, and submission of error messages. They make (semi-)automatic traceability definition and management possible, and demonstrate that the proposed model-driven approach is capable of supporting those processes.