The exact meaning of the relationship depends on the context in which it is ... provides a flexible trace model definition that allows customization of artefacts and.
Towards a Generic Solution for Traceability in MDD Ståle Walderhaug, Ulrik Johansen, Erlend Stav, Jan Aagedal SINTEF ICT, Norway {stale.waldehaug | ulrik.johansen | erlend.stav | jan.aagedal}@sintef.no}
Abstract. Traceability is an important feature in model-driven development. Many research initiatives are currently investigating how to collect, store and utilize traceability information to improve the quality of the MDD process, and there is a need to unify the results from these initiatives. This paper proposes a generic solution for traceability that offers a set of services that is meant to cover both the specification and appliance of traceability. Our proposed traceability solution is specified as a metamodel with guidelines and templates for use. An example of how the solution can be integrated in a model-driven development project is given.
Introduction Model Driven Development (MDD) seeks to use models to represent all artefacts that are involved in the system engineering process. Example of such artefacts can be a system requirement, a software component or a business policy document. These artefacts are used in a MDD process to implement and document the desired functionality of the (information) system. During this process, relationships between the artefacts are created both automatically (e.g., during model transformation) and manually (e.g., explicit dependency between a document and a system requirement). To maintain and control these relations, a traceability solution should be a part of every MDD framework [1]. Traceability can be defined as: “…a relationship between entities: a set of source entities, and a set of target entities. The exact meaning of the relationship depends on the context in which it is used.” [2] Much work has been done to identify and describe how traceability should be defined. Ramesh et al suggests a reference model for requirements traceability in [3]. They define a simple metamodel that is comprised of three layers: 1) metamodel defining which traceability models that can be defined; 2) a set of reference traceability models that can be customized; and 3) a database of actual traces, recorded under the chosen models. They elaborate this metamodel with focus on requirements traceability. Letelier presents a UML-based metamodel for requirements traceability that is translated into a UML profile for easy CASE tool application in [4]. In [5], Champeau et al present a conceptual UML traceability model that includes both requirements and other model elements. They state that there is a need for a
2
Ståle Walderhaug, Ulrik Johansen, Erlend Stav, Jan Aagedal
flexible navigation and query mechanism for trace relations, but that there is no tool support for this. Aizenbud-Reshef et al discuss the operational semantics of traceability in [6] using the Event-Condition-Action triple from [7] to describe the semantic property of a traceability relationship. They conclude that semantics is important for a successful implementation of a traceability system for MDD. Despite of these research efforts, it seems that there is little that ties the work to a common direction concerning traceability functionality and trace artefact and relation types definition. This is clearly stated by Limón et al in [8]: “There is a lack of a commonly accepted traceability definition further than the term definition, a standard way of specifying traceability among items, and a traceability type classification; besides, conflicts among a number of approaches exist.” Concerning “traceability type classification” we assume that a stronger focus on how the defined artefact and relation types are used is important, because the traceability information has limited or no value if the created trace relations are incomplete, irrelevant or unavailable to the users. The trace information should be shared between tools, organisations and projects, and product life-time phases. We will address these issues by proposing a generic solution for traceability in model-driven development that: − provides a flexible trace model definition that allows customization of artefacts and relationships − supports the whole lifetime of the artefacts − supports tracing of artefacts across different tools We conclude that the set of services: trace model management, trace creation, trace use and trace monitoring can support any kinds of artefacts and relations in a heterogeneous MDD environment. The solution has not yet been prototyped or evaluated. This paper is organized in five sections. Following this introduction, the next section describes traceability in MDD with focus on the metamodel and the core services. The third section describes an example where traceability is integrated. Then the suggested solution is discussed in section four, before concluding remarks and comments on future work are given.
Traceability in Model Driven Development In a model-driven development process, tracing the artefacts is important because of the extensive use of model transformation and code generation[1, 9-12]. The traceability information can be utilized for many purposes during the lifetime of an artefact, e.g. to improve transformation or perform trace analysis. A traceability solution to be used in MDD must incorporate concepts for definition of traceable artefacts, automatic and manual trace management (create, modify and delete), and support a rich set of trace analysis services such as impact and coverage analysis, and trace query and navigation. These concepts must be supported by the trace model that
Towards a Generic Solution for Traceability in MDD
3
a traceability solution implements. As the trace model may be subject for change, the underlying traceability metamodel need to be flexible, scalable and at the same time provide a semantically rich foundation for easy definition of a powerful trace model. The Traceability Metamodel, System and Use packages Before describing the services in more detail we present the Traceability Metamodel, Traceability System and Traceability Use packages, which represent the basis for describing the Traceability Services.
Fig. 1. The Traceability Metamodel, System and use packages The Traceability Metamodel package defines a basis for defining trace models and consists of four classes: − The TraceModel specifies which model artefacts that can be traced (TraceableArtefactType), and which traces of model artefacts (ArtefactTraceType) and relations between model artefacts (RelationTraceType) that can be created. − TraceableArtefactType defines the mapping of a specific model artefact type to a corresponding traceable artefact type. The model artefact type is the type of the actual modelling elements that shall be traced and must have a corresponding traceable artefact type definition in the trace model.
4
Ståle Walderhaug, Ulrik Johansen, Erlend Stav, Jan Aagedal
− ArtefactTraceType defines a specific trace type for a TraceableArtefactType. The definition may e.g. specify what attributes that shall be traced and what types of actions to be executed when such a trace occur. − RelationTraceType defines a specific trace type for a certain relation between a source and a target artefact type. The definition may e.g. specify what attributes that shall be traced and what types of actions to be executed when such a trace occur. The Traceability System package defines a basis for creating, storing and using traces (i.e. trace repository) based on a trace model definition, and consists of the following classes: − TraceRepository is responsible for managing the trace information, which is represented by the collection of TraceableArtefact, ArtefactTrace and RelationTrace entities. − TraceableArtefact defines the type to be instantiated when a model artefact shall be traced. A TraceableArtefact refers a corresponding TraceableArtefactType defined in the trace model. − ArtefactTrace defines the type to be instantiated when a specific trace related to a traceable artefact occurs. An ArtefactTrace refers to a corresponding ArtefactTraceType defined in the trace model. − RelationTrace defines the type to be instantiated when a specific trace related to a relation between two related traceable artefacts occurs. A TraceRelation refers to a corresponding TraceRelationType defined in the trace model. − TraceSession is a session administrator when traceability is provided to users as a service. Multiple users may use traceability simultaneously, and each user will be assigned a TraceSession entity. The Traceability Use package defines a basis for users to interface the trace repository and includes two classes: TraceClient and TraceSubscriber. TraceClient is the user (e.g., an artefact modelling tool) of the functionality provided by the Traceability System, while the TraceSubscriber is the client side representation of the optional Subscribe/Notification service. A single metaclass from EMOF is included to specify how a unique identification of TraceableArtefact can be provided. Traceability Services Based on the previously defined packages we define the following four core services for MDD traceability: − TraceModel Management: Management of a TraceModel that defines how and what types of artefacts (TraceableArtefactType) that can be traced (ArtefactTraceType and RelationTraceType). − Trace Creation: The users’ (TraceClient) creation of traceable artefacts (TraceableArtefact), traces and relations between these (ArtefactTrace and RelationTrace), and keeping these in a repository (TraceRepository).
Towards a Generic Solution for Traceability in MDD
5
− Trace Use: This includes any functionality supported by a trace repository concerning querying and analyzing the set of traceable artefacts and relations managed by the repository. − Trace Monitoring: Traceability users may request to be informed (notifications) about certain events that occur as a result of certain trace repository events and situations. The Trace Model Management service involves three main tasks: 1) Specification of traceable artefact types: e.g., UML Model, textual descriptions (such as source code); 2) Specification of artefact trace types (e.g., versioning of specific documents); and 3) Specification of relation trace types (e.g., Refine, Transform, Evolves_to, Generation, Justifies, Modifies, Uses, Implements, Owns, Executes and Validates). When defining the trace model, it is important to take into consideration the use context for the trace model to be defined, because artefacts or traces using the same definitions may be applied within different context [2]. The following relevant context related aspects are identified: − Stakeholders: Stakeholders are the users of traceability. Different stakeholders may use different artefacts and trace links, or they may use the same but maybe with different semantics and importance. Example stakeholders are: Authorities, Owner, Producer, Developer, Customer and User. − Lifecycle phase: Lifecycle phases identify different periods in time that are closely related to both use of traceability and to relevance for different stakeholders. As for stakeholders, different lifecycle phases may have relevance for different artefact and link types, or the same artefact and link types but maybe with different semantics and importance. Example lifecycle phases are: Pre-study, Requirement, Development, Implementation, Test, Installation, Use and Maintenance, and Decommission. − Granularity level: Granularity level specifies the degree of detailing that the traces shall have. Granularity level is also an aspect that is closely related to the different stakeholder needs concerning traces use. Example granularity aspect types can be: Time, Confidence, Logical grouping and Aggregation level. As an aid in defining the trace model, four templates is provided for specifying the trace model, the traceable artefact types, the artefact trace types and the relation trace types. Specifying trace models using the templates should leave it as a simple mapping task to convert the template content to a formalised corresponding UML definition according to what is defined in the Traceability Metamodel package. Specification of a trace model traceModelName: informalDescription Background; Purpose; Context; Dependencies; Functionality; Appliance traceModelVersion . Specification of traceable artefact types Name informalDescription Purpose; Context; Attributes (relates to “modelAttributes”);
6
Ståle Walderhaug, Ulrik Johansen, Erlend Stav, Jan Aagedal
modelArtefactType
modelAttributes
modelToTraceable ArtefactMapping
Sources of attribute values (relates to “modelArtefactType”); Examples This specifies either of two alternatives: - Referring a modelling element in a formal defined model. E.g. referring a “namedElement” in an EMOF based model. In this case the model attribute names and types may be extracted from the referred metamodel and need not to be specified by the modelAttributes property. - An informal user specified name is defined to identify this artefact type. In this case the model attribute names and types must be specified by the modelAttributes property. If specification of model element attributes is not implicit through the modelArtefactType property they must be specified here as a list of names and types. Specifies the traceable artefact attributes. Attributes that are defined here are those attributes that may be assigned value through trace creation, and which will become retrievable and searchable when using the created trace information.
Specification of artefact trace types Name informalDescription Purpose; Uses; Attributes (relates to “content”); Sources of attribute values (relates to “content”); Conditions for artefact occurrence (relates to “sourceArtefactType”); Consequences of artefact trace occurrence (relates to “actions”); Examples sourceArtefactType content Specifies exactly what set of attributes that shall be assigned values when a trace of this type is created. Attribute specification may use two sources for specification, i.e. the TraceableArtefactType referred by sourceArtefactType or specifying a name and type for attribute. actions Specifies exactly what set of actions that may be triggered when either a trace associated to this artefact trace type is created, or when the corresponding traceable artefact type is created. Each action specification consists of two parts: a condition for triggering the action, and the action specification. Specification of relation trace types Name Same as for artefact trace types described above informalDescription Same as for artefact trace types described above sourceArtefactType targetArtefactType contents Same as for artefact trace types described above actions Same as for artefact trace types described above The Trace Creation service enables users to create traceable artefacts and traces related to these. Traces are the actual documentation of the lifetime evolution of, and
Towards a Generic Solution for Traceability in MDD
7
the relations between traceable artefacts. The TraceModel, defines what traces shall be created and in which situations. Traces creation are partially a responsibility of the applications (e.g. a modelling tool) that create and manage traceable artefacts, but traces may also be created implicitly as results of occurring events or situations defined as actions in the trace model. E.g. a tool creating a modelling element that shall be traced is also responsible for the instantiation of a corresponding TraceableArtefact instance representing the modelling element in the trace repository. The interface used by applications for traces creation is defined by the Traceability System package classes, and the interface is the same, independent of how the trace model is specified. This implies a standardised traceability use interface common for any application generating traces. The Trace Use service provides a set of functions for using the traceability information in the trace repository. It is important to explicitly differ between the creation of traces and how the traces shall be used. This because the traces only must contain sufficient information for intended use, but the information may be used in a lot of different ways. E.g. collection and aggregation of the traces in one way may give the result of an impact analysis, while collection and aggregation of the same information another way may give the result of a coverage analysis. The created traces are structured information that represents traceable artefacts and relations between these. Structured trace information makes it possible to perform collection and aggregation of the traces. It is reasonable to assume that storing the traces in a database and using the database query language to collect and aggregate information represents a flexible and powerful way to utilise traces in different ways. The last service is Trace Monitoring. Using the traces as described in the previous implies to first create traces and thereafter make use of the traces. Sometimes this is not a satisfying solution, because it may be desirable to immediately be informed when a specific event or situation concerning trace creation has occurred. E.g. assume that both a modelling element representing an UML class diagram and the corresponding generated Java code for that class diagram are defined as traceable artefacts. A traceable relation between these is defined by a RelationTraceType. It may be desirable to define this type so that when the class diagram is updated a notification stating that the corresponding Java code should be updated is generated. This notification may e.g. be used to trigger a transformation tool to generate an updated version. Specification of trace monitoring is a part of the trace model definition, while their use is related to creation of traces. Consistency via traceability monitoring is also described in [6].
Example: Traceability Solution for System X This section shows an example use of a traceability solution (TS) based on what previously has been described. TS in this context imply an executable implementation of the traceability concepts as previously described used by applications as e.g. modelling tools. Figure 2 is used as basis to illustrate and describe practical use of the TS.
8
Ståle Walderhaug, Ulrik Johansen, Erlend Stav, Jan Aagedal
Fig. 2. Traceability Solution for System X
Figure 2 indicates the use of TS in two different contexts. First it is used during the development phases for a system development (i.e. the part of the figure contained within System Modelling Environment), and also by an operational instance of the modelled system (i.e. Application_X on the SystemX PC). The common basic traceability functionality is the same in both situations, but the trace models that are used are different (i.e. indicated as TS X-1 for System Modelling Environment and TS X-2 for System X). TS X-1 and TS X-2 are the trace repository instances used by the tools for generation of traces. The figure indicates that two different development tools (i.e. Tool_a and Tool_b) are used during system development, and that these tools are sited at different computers (i.e. PC_a and PC_b). For Tool_a the used TS X-1 is located at the same computer as the tool itself, while for Tool_b the used TS X-1 is located at a remote server computer. The interface between the modelling tools (Tool_a and Tool_b) and TS X-1 instances are standardised (named API_X) and independent whether TS X-1 is local or remote to the application. Despite that different tools modify the same traceable artefacts and create traces for these, the created traces can be integrated within the same trace repository context. This is indicated by the connection between the two TS X-1 instances by the interface API_Dist. The developed system model is indicated as System X. Requirements, Use Cases, Class diagrams and Program code are indicated as artefacts that are traced. The relations between the artefacts being traced are indicated as REFINEMENT, DEPENDENCY and TRANSFORM relation trace types, and in addition an EVOLVES_TO artefact trace type for the whole system model is indicated. The selections of trace artefacts, artefact trace types and relations trace types are very simplified in relation to what will be a realistic situation. The system model shown in the figure will be the basis for the definition of the trace model to be used by both modelling tools (Tool_a and Tool_b), containing the
Towards a Generic Solution for Traceability in MDD
9
definition of TraceableArtefactTypes, ArtefactTraceTypes and RelationTraceTypes as described previously in the document. The trace model for the operational system (i.e. SystemX) is not indicated in the figure. Relevant artefacts to be traced will e.g. be instances of the modelled classes, running operating system processes and so on. As a summary the figure indicates that the described traceability solution is generic and may be applied for different purposes depending on the trace model definition, it has a generic standardised interface to the application which is independent of the used trace model, and it is a multi-user solution where created traces related to the same artefacts to be traced are integrated logically within the same trace repository.
Discussion The need for a traceability solution in systems engineering is well documented. We have presented a metamodel and a solution for MDD traceability that is tool and domain independent. The TraceModel Management service allows detailed configuration of parameters to be traced and actions to be executed on certain events. We also provide trace model templates that allow the user to specify the context in which the specific types (TraceableArtefactType, ArtefactTraceType or RelationTraceType) should be used, thus providing both a domain and context customization interface. These types constitute the semantics of the traceability solution. This event and action mechanism is in line with the operational semantics for traceability presented by Aizenbud-Reshef [6]. Our traceability solution further describes how the traceability information can be captured and shared between tools and organizations. A TraceRepository will store the traceability information and provide a service interface for external tools. As the traceability information is stored in a separate repository, this opens for lifetime tracing of the artefacts and sharing between different artefact tools. A similar solution is described by Mason et al [13] where different CASE tools can export data to a common Workspace. When a traceable artefact, artefact trace or relation trace is created, updated or deleted in the TraceRepository, one or more specified actions can be triggered. The TraceRepository service interface will also include services for querying the traceability information. Navigation and analysis services such as change impact and coverage can be implemented based on queries to the trace repository. Keeping the information in the trace repository up to date is the responsibility of the artefact tools (TraceClient). For traceability information synchronization between trace client and the repository, the TraceRepository will provide an interface for both write and read trace information. Synchronization of models (artefacts) may be implemented similar to source-target synchronization as described in[10].
Concluding remarks and future work We have described a traceability solution for model-driven development that supports any kind of artefacts and traces. The metamodel is flexible and opens for user/domain
10
Ståle Walderhaug, Ulrik Johansen, Erlend Stav, Jan Aagedal
customization. A traceability repository based on using a formal trace model is well documented in the literature and makes it possible to share traceability information between tools and implementing advanced analysis and monitoring services. In order to achieve the intended purpose of traceability, integration with artefact tools is a prerequisite. We have described a conceptual solution for tool integration. The work presented in this paper is carried out as a part of the Modelware project1. Parts of the traceability solution is planned to be implemented and tested as a part of the Modelware project demonstration. To evaluate the proposed solution it is necessary to implement and evaluate a system where several tools and artefacts are being traced from initial project phases to deployment and maintenance.
References 1. Oldevik, J., Transformation Composition Modelling Framework. Lecture Notes in Computer Science. 2005. 108-114. 2. Shaham-Gafni, Y. and A. Hartman, ModelWare Traceability: A Survey (draft). 2005, IBM Haifa Research Lab. 3. Ramesh, B. and M. Jarke, Toward Reference Models for Requirements Traceability. IEEE Trans. Softw. Eng., 2001. 27(1): p. 58-93. 4. Letelier, P. A Framework for Requirements Traceability in UML-based Projects. in Proceedings of the1st International Workshop on Traceability, co-located with ASE 2002. 2002. Edinburgh, Scotland, UK 5. Champeau, J. and E. Rochefort. Model Engineering and Traceability. in UML 2003 SIVOES-MDA Workshop. 2003. San Francisco, California, USA.http://wwwverimag.imag.fr/EVENTS/2003/SIVOES-MDA/Papers/Champeau.pdf 6. Aizenbud-Reshef, N., et al. Operational Semantics for Traceability. in European Conference on Model Driven Architecture - Traceability Workshop 2005. Nuremberg, Germany 7. Schwinger, W., Logical Events in ECA Rules, Dept. of Computer Science., University of Skövde: Skövde, Sweeden, 1995. 8. Limón, A.E. and J. Garbajosa. The Need for a Unifying Traceability Scheme. in European Conference on Model Driven Architecture - Traceability Workshop 2005. Nuremberg, 2005 9. Vanhooff, B. and Y. Berbers. Supporting Modular Transformation Units with Precise Transformation Traceability Metadata. in European Conference on Model Driven Architecture - Traceability Workshop 2005 Nuremberg, Germany 10.Ivkovic, I. and K. Kontogiannis. Tracing evolution changes of software artifacts through model synchronization. in Proceedings of the 20th IEEE International Conference on Software Maintenance, 2004. . http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1357809 11.Gonzalez-Baixauli, B., M.A. Laguna, and Y. Crespo. Product Lines, Features, and MDD. 1st European Workshop on Model Transformation (EWMT 05). 2005. http://www.giro.infor.uva.es/Publications/2005/GLC05/Gonzalez_2.pdf 12.Desfray, P., MDA – When a major software industry trend meets our toolset, implemented since 1994. 2003, SOFTEAM. p. 12. 13.Mason, P., et al. Meta-modelling approach to traceability for avionics: a framework for managing the engineering of computer based aerospace systems. 2003
1
Modelware project homepage: http://www.modelware-ist.org/
