ECMDA Traceability Workshop (ECMDA-TW) 2005 Proceedings

Transcription

1 ECMDA Traceability Workshop (ECMDA-TW) 2005 Proceedings November 8 th 2005, Nuremberg, Germany This workshop was organised in collaboration with the European Conference on Model Driven Architecture - Foundations and Applications. Organisers: Jon Oldevik and Jan Aagedal, SINTEF {jon.oldevik / jan.aagedal at sintef.no} ISBN

2 TITLE SINTEF REPORT SINTEF ICT Address: NO-7465 Trondheim, NORWAY Location: Forskningsveien 1 Telephone: Fax: Enterprise No.: NO MVA ECMDA Traceability Workshop Proceedings AUTHOR(S) Jon Oldevik, Jan Aagedal CLIENT(S) ECMDA Traceability Workshop REPORT NO. CLASSIFICATION CLIENTS REF. STF90 A05133 Open CLASS. THIS PAGE ISBN ECMDA Traceability Workshop PROJECT NO. 90B / 0 NO. OF PAGES/APPENDICES ELECTRONIC FILE CODE PROJECT MANAGER (NAME, SIGN.) CHECKED BY (NAME, SIGN.) ECMDA-TW Proceedings Jan Aagedal Tor Neple FILE CODE DATE APPROVED BY (NAME, POSITION, SIGN.) Bjørn Skjellaug, Research Director ABSTRACT This report contains the proceedings of the ECMDA Traceability Workshop. The papers within target various aspects of traceability in model-driven development. KEYWORDS ENGLISH NORWEGIAN GROUP 1 ICT IKT GROUP 2 Information Systems Informasjonssystemer SELECTED BY AUTHOR Traceability Sporbarhet

3 Table of contents Introduction 5 Operational Semantics for Traceability 7-14 Supporting Modular Transformation Units with Precise Transformation Traceability Metadata Loosely Coupled Traceability for ATL Survey of Traceability Models in IT projects The Need for a Unifying Traceability Scheme Tracing Process Model Evolution: A Semi-Formal Process Modeling Approach ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 3 of 66

4 Page 4 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

5 Introduction In their Policy on Traceability, NIST defines some general properties of traceability; Traceability requires the establishment of an unbroken chain of comparisons to stated references. In software engineering, this has traditionally been associated to the ability to link project requirements to corresponding design artefacts, resulting software, and associated test cases. The management of traceability has thus been a part of requirements engineering. Now, in the age of model-driven engineering, the value chain of traceability is extended to include more levels of development artefacts; triggered by the increased automation of the software engineering lifecycle. Languages and tools for model transformation, such as QVT and MOF Model to Text are emerging, gradually enabling an increased use of standard mechanisms for automation in software engineering. The needs for traceability mechanisms that can seamlessly provide the trace information between automated artifacts is obvious. This workshop presents and discusses practical and theoretical issues associated with languages, mechanisms, tools, and processes that address the management and application of traceability in model-driven development. We hope that the workshop papers act as catalysts for fruitful discussions on aspects such as the usage of new model-driven technology to facilitate traceability, change management of models, impact analysis of model modifications, and other solutions, applications, and research challenges of traceability in model-driven engineering. Acknowledgment: The organisation of the ECMDA-TW workshop was made possible through the MODELWARE project (IST Project ). MODELWARE is a project co-funded by the European Commission under the "Information Society Technologies" Sixth Framework Programme ( ). Information included in this document reflects only the author s views. The European Community is not liable for any use that may be made of the information contained herein. ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 5 of 66

6 Page 6 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

7 Operational Semantics for Traceability Netta Aizenbud-Reshef 1, Richard F. Paige 2, Julia Rubin 1, Yael Shaham-Gafni 1 and Dimitrios S. Kolovos 2 1 IBM Haifa Research Labs, Israel 2 Department of Computer Science, University of York, UK neta@il.ibm.com, paige@cs.york.ac.uk, mjulia@il.ibm.com, yaelsg@il.ibm.com, dkolovos@cs.york.ac.uk Abstract. Traceability is a relationship between entities that are produced during development. Different types of traceability are used in practice, with different characteristics and properties: there is no single notion of traceability that is usable in all situations. In this paper we present an approach for defining an operational semantics for traceability in UML, in order to more precisely capture the intended meaning of different types of traceability, and to enable richer tool support for managing and monitoring traceability, perhaps by making use of consistency checking technology. 1. Introduction The Unified Modelling Language (UML) defines a number of relationships between modelling elements. Most widely used are associations and generalizations, but the most general-purpose of these relationships is the dependency. In UML 2.0, the general-purpose dependency relationship can be specialized in a number of ways by adding stereotypes to more precisely describe the different types of dependency that are of interest to the modeller, e.g., abstraction, usage, and realization. Dependency relationships are used in a variety of ways: to leave modelling decisions unconstrained; to capture non-determinism; to capture high-level modelling decisions (e.g., regarding system architecture). Dependency relationships can also be used, importantly, to capture and infer traceability information. In general, dependencies can be definitional and inferred. A definitional dependency exists between modelling artifacts by definition (e.g., a Java class that implements a Java interface must contain implementations of methods declared in the interface). A definitional dependency is either valid or invalid; if one of its related artifacts has changed, it may not be clear if the dependency is still valid thus, some action must be taken to either validate the dependency, or re-establish it. An inferred dependency exists between artifacts if the artifacts satisfy a rule describing the dependency; this can be done automatically or manually, and if the rule is not satisfied then some action must be taken to re-establish the dependency. Traceability is used and interpreted in a number of ways, particularly in the requirements engineering field for documenting that a system satisfies (or is ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 7 of 66

8 consistent with) requirements. When using a precisely defined modelling language like UML, it is feasible and useful to more precisely define the meaning of traceability. A precise semantics for traceability will allow developers to more accurately capture the intended meaning of a specific traceability relationship (as well as its side-effects), and will enable the production of richer tool support for managing and monitoring traceability. The aim of this paper is to precisely describe the semantics of traceability in UML. The semantics proposed is operational, rather than declarative, with the intent that the semantics identified will prove to be helpful in contributing to automated consistency management of UML models. The semantics is expressed in terms of event-conditionaction triples [12], which are explained and justified in the next section. We commence with a brief review of traceability in the literature (considering reference models in particular and also specific instances of traceability relationships). We then present the operational semantics and its two variants, preventative and reactive. From this, we more precisely define the three characteristic attributes of the semantics, and give examples. We then conclude with a discussion of future work, particularly on tool support and its relationship to behavioural modelling, e.g., in UML. Though this paper presents traceability in the context of UML, there is nothing inherent in its ideas that make it restricted to this context. For example, the ideas could easily be applied to MOF 1.3 (which, e.g., has a DependsOn association). More generally, any modelling language possessing a dependency relationship of some kind could benefit from the ideas on semantics in this paper. 2. The Semantics of Traceability In UML 2.0 the dependency relationships, and specializations thereupon (such as abstraction, usage, realization and substitution), infer several types of traceability each with a different semantics. Currently the semantics are described informally in English. We propose to provide an operational semantics for traceability relationships. 2.1 Traceability Traceability is a relationship between entities: a set of source entities, and a set of target entities. Different types of relationships can be defined between different types of entities. Ramesh & Jarke [9] propose a reference model, based on empirical observations, comprising the most important kinds of traceability links for various development artifacts and tasks. For example, Scenarios describe Requirements, System Requirements are derived from User Requirements, System Components satisfy Requirements, and Verification Procedures verify that Requirements are satisfied. Letelier [4] presents a reference metamodel for requirements traceability that extends the UML metamodel, integrating non UML artifacts such as text elements and test specifications. Examples of traceability relationships in this metamodel are: A RationaleSpecification is rationaleof TraceableSpecification, Page 8 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

9 RequirementsSpecification is validatedby TestSpecification, and Stakeholder is responsibleof TraceableSpecification. Each of the relationships in the examples above has a different name hinting at different semantics and different intended use. 2.2 Operational Semantics A key concern and question that we must ask is: why are different types of traceability relationships needed? More precisely, we should ask: why isn't one traceability relationship sufficient? The answer lies in the intended use for the relationships that are defined. Traceability has three main uses: 1. Querying: e.g. impact analysis, coverage queries [8]. 2. Following links along the life cycle of a project. For example, if we want to determine the requirement that a particular acceptance test is checking [6]. 3. Keeping the system and its documentation up to date, in a consistent state [7]. In Model-Driven Development (e.g., with MDA) documentation will include precisely defined models, e.g., as written in UML. The role of a traceability semantics is to help with these tasks: More precisely, a semantics for traceability will help developers focus their queries (i.e., it will help them write more precise queries, ideally more quickly); it will help developers find the right link to follow when they want to determine the relationships between entities (or, particularly, if they want to quickly and informally determine that a traceability relationship exists between artifacts); and to support automation of consistency management (e.g., to help ensure that different versions of UML models do not contain inconsistent information; for example, two different versions of a class diagram between which a traceability relationship exists may need to be consistent according to a specific set of rules). An operational semantics primarily helps with the last usage of traceability. An operational semantics for a traceability link describes: what information must be maintained between the related elements; what actions should be triggered when something occurs that affects one or more of the related elements what actions should be triggered when something relevant occurs impacting on the relationship itself in order to ensure the relationship is still valid according to its semantics. Based on this, we define two types of semantics for traceability: 1. Preventative semantics 2. Reactive semantics ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 9 of 66

10 Preventative semantics describes things that should not happen. For example, consider the dependency in Figure 1, if a Java class A imports Java class B, class B must not be deleted before the import dependency is removed. A imports B Figure 1: Example of an "imports" relationship Reactive semantics describe what should be triggered when something happens to one or more of the related elements or to the relationship itself. For example if attribute B is derived from attribute A, whenever the value of A changes B needs to be recomputed. This type of relationship is illustrated in Figure 2: A derived B Figure 2: Example of the "derived" relationship 2.3 Semantic Properties A semantic property of a traceability relationship is a triplet: {event, condition, actions} where: event involves an element or a relationship (these are expanded upon in the next section); condition is a logical constraint, which in general is used to define the conditions under which the event takes place. Conditions can also be used to capture constraints on the context. actions can be either preventative or reactive actions. The operational semantics of a traceability relationship is defined by a set of one or more semantic properties. Such triplets are used because they provide a computational model for semantics: when to evaluate, and how to react. The condition provides the logic of the semantics, in the sense that the condition defines the state properties that hold between the related artifacts. There are substantial similarities between a semantic property and the notion of a Page 10 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

11 consistency rule. A consistency rule expresses conditions that two or more consistent models must satisfy. The main difference between a consistency rule and a semantic property is that the latter includes triggering events [4], whereas the former does not triggering events in consistency rules are left implicit and the notion of when a rule should be checked and should be true is not precisely defined. Work on adding action semantics to the Meta Object Facility (MOF) in the context of UML and the Model- Driven Architecture is of use in more precisely capturing when consistency rules should be true. The combination of a MOF action semantics and consistency rules should be roughly equivalent to the notion of a semantic property, and conceivably the former could be used to help implement the latter in a generic, tool-independent way. 2.4 Events Events in semantic properties involve elements or relationships. An event indicates an occurrence of a change in a model; one or more elements in the model are changed in some way. There are three categories of primitive events that can be identified, and these can be applied to either elements or relationships: Create events: an element or a relationship is created. Note that create events can cascade: creating a relationship may in turn create new elements (e.g., attaching an element to an end of a relationship). Update events: an existing element or relationship is modified in some way (e.g., names of attributes of a class are modified; role multiplicities of an association are changed). Delete events: an existing element or relationship is deleted. As with create events, delete events may cascade: for example, deleting an element at the end of an association may generate new delete events for the association. In terms of the usual categorization of primitive events as create, read, update, or delete, we note that we are only omitting read events. Read events do not generate new information relevant to preserving or monitoring traceability (or consistency) and as such they can be omitted safely from this categorization. Primitive events can be composed into a Composite Event, using various operators, such as logical and temporal operators. This classification appears to be broadly compatible with the MOF 2.0 Facility and Object Lifecycle specification [14] and as such could be encoded in MOF (and thereafter UML) compliant tools. 2.5 Conditions Conditions are used for providing fine-grained control of events. Adding conditions to an event provides further classification of the event, and also more precise details as to when the event is applicable. ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 11 of 66

12 For example, assume that we have a "calls" relationship between a method invocation and a method definition: there are some changes in the method definition that may require the method invocation to change, whereas there may be other changes to the method definition that do not. method definition calls method invocation Figure 3: Example of a "calls" relationship In this example the generic update event is: "Java method definition changed". Using conditions we can differentiate between the event "Java method definition return type changed", and "Java method definition parameter added". A simple Boolean expression suffices for a condition in this particular case. 2.6 Actions Actions can be either preventative or reactive. A reactive action describes what should be done when a specific event has occurred. A preventative action describes events that should not occur. Preventative actions are similar to the process of consistency via monitoring, wherein a development environment (implicitly or explicitly) monitors the state of a model to ensure that the actions taken by a user (e.g., adding new elements, changing relationships) cannot introduce inconsistencies. We can define a set of primitive or atomic actions which provide the building blocks for defining the operational semantics of a traceability relationship. Inspiration for such actions can come from the proposals for action semantics in UML. The UML action semantics describes a comprehensive set of around 60 actions, some of which may not be applicable in the traceability context (e.g., actions that encode programmatic idioms like while-loops and guarded commands). Surveying the list of actions suggests that actions like the following will be of value in an operational semantics for traceability; of course, this is an initial list and additions will likely need to be made, since our approach is pragmatic and aims to be extensible: users should be able to add (potentially domain-specific) actions as they see fit. Preventative actions: 1. Must not delete element or relationship. 2. Must not change element or relationship. 3. Must not create new element or relationship (e.g., in a particular UML diagram certain elements or relationships should not be possible to create, because they are illegal or because they cannot be effectively traced). Reactive actions: Page 12 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

13 1. (Re)generate an element or relationship, e.g., because new information is available. A good example of generate is code generation: given a Java program an executable is generated; given a model, tests can be automatically generated. Once the model or Java program has been updated, the executable or tests must be regenerated. For example, a new method may be available in a class because a message sent in an interaction diagram implies that it is available. Regeneration may, in a sense, be similar to incremental compilation. 2. (Re)compute derived values. For example, given a class and instances of a class, where the class has a derived value, a change in the declaration of the derived attribute should trigger a recomputation of the value of the attribute in all instances. 3. Delete an element or relationship. 4. Notify an element or relationship. Notification is typically used for actions that cannot be handled automatically, e.g., when a change occurs that requires human intervention (such as responding to a bug report). 5. Fix or modify an element or relationship. 6. Mark in error state, e.g., that an inconsistency exists and should be resolved at a later time. 7. Synchronize. The intent with synchronization is that there are two elements, at different abstraction levels, that must be kept synchronized, e.g., a UML class and a Java interface/implementation. If changes are made to the UML these must be reflected in Java. This is not a straightforward generation relationship as it must take into account manual additions to the Java. This is sometimes called a change propagating relationship; Tratt explores a prototype implementation in his Converge language [13]. 3. Conclusion We have outlined an approach to precisely defining the operational semantics of traceability relationships. The key observation of this paper is that the notion of traceability that is of interest to a modeller should be captured using a set of semantic properties. These properties correspondingly identify the events that produce traceability information, the conditions under which these events may arise, and the actions that should be taken in order to maintain traceability information. The parallels between semantic properties and consistency rules were noted; this suggests that a unified toolset for consistency and traceability management is feasible and useful. It seems likely that such a toolset could be derived building on a mechanism for capturing rules and conditions (e.g., an OCL engine) and actions (e.g., a MOF action semantics with suitably aware tools). We expect that our ongoing work on model composition and MOF action semantics will allow us to produce such a toolset in the near future, and anticipate using traceability as a case study in which to fully explore the importance and utility of behavioural modelling at the metamodel level. ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 13 of 66

14 References 1. Object Management Group. Model-Driven Architecture Specification, available at last accessed June Object Management Group. Meta Object Facility Specification, available at last accessed July Berndtsson M. and Lings B., Logical Event and ECA Rules, Technical Report HS-IDA- TR , Dept. of Computer Science, University of Skövde, Sweden, Cleland-Huang, J., Chang, C.K., Christensen, M, "Event-based traceability for managing evolutionary change", IEEE Transactions on Software Engineering, 29(9) pp , Sept Letelier, P., "A Framework for Requirements Traceability in UML-based Projects", Proceedings of the 1st International Workshop on Traceability in Emerging Forms of of Software Engineering (TFFSE 2002), September Lindvall, M. and Sandahl, K. "Practical Implications of Traceability", Software Practice and Experience,26(10), pp , Olsson T. and Grundy J., "Supporting traceability and inconsistency management between software artifacts", Proceedings of the 2002 IASTED International Conference on Software Engineering and Applications, November O Neal, James S., and Carver, Doris L., "Analyzing the impact of changing requirements", Proceedings of the IEEE International Conference on Software Maintenance, November Ramesh, B., Jarke, M., "Toward Reference Models for Requirements Traceability", IEEE Transactions On Software Engineering, vol. 27, no. 1, January Paige, R.F., Kolovos, D.S., and Polack, F.A.C., Refinement via Consistency in MDA, Proceedings of Refinenet Workshop (Refinenet 2005), ENTCS, April Paige, R.F., Kolovos, D.S., and Polack, F.A.C. Adding an Action Semantics to MOF, to be submitted September Schwinger W., Logical Events in ECA Rules, Master Thesis, Dept. of Computer Science, University of Skövde, Sweden, Tratt, L. The Converge Programming Language, King s College London Technical Report TR-05-01, Object Management Group. MOF 2.0 Facility and Object Lifecycle, Page 14 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

15 Supporting Modular Transformation Units with Precise Transformation Traceability Metadata Bert Vanhooff 1 and Yolande Berbers 1 Katholieke Universiteit Leuven, Celestijnenlaan 200A, 3001 Leuven, Belgium {bert.vanhooff, yolande.berbers}@cs.kuleuven.be Abstract. The Model Driven Architecture (MDA) initiative of the OMG heavily promotes the use of abstract models for software development. A key ingredient of the MDA is the automation of transformations on these models. Inserting semantically rich transformation traceability links into our models allows us to better comprehend the exact effects of the applied transformations. Empowering each transformation unit to insert its own specific traceability links provides subsequent transformation units with the ability to make use of that traceability information to improve their own actions. In addition, this permits us to better modularize transformations into smaller and more reusable units that, to a certain extent, depend on each other. In this paper, we define a UML transformation traceability profile that allows the addition of semantically rich traceability links into UML models. 1 Introduction The Model Driven Architecture (MDA) [1] is well-known as the approach of the OMG (Object Management Group) towards Model Driven Engineering (MDE) or Model Driven Development (MDD) of software. Their contribution to the MDE/MDD community is twofold. Firstly they provide an elaborate description of their vision toward MDD and secondly they provide a suite of technology specifications that can be used to support that vision. In short the MDA vision consists of the following three parts; accompanying technologies are listed in brackets: 1. Specifying modeling languages using the technique of metamodeling (Meta Object Facility - MOF [2]). 2. Modeling the envisioned system in an abstract (platform independent) fashion and marking this model with extra information (Unified Modeling Language - UML and UML Profiles [3], or any other MOF defined language). 3. (Semi-)automatically transforming these models into new more concrete models (Query/Views/Transformations - QVT [4], [12]). At this point the UML (point 2) is probably the most used technology within the MDA technology space. It allows to completely model a software system. Unfortunately such a model can not be run directly (although there are some ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 15 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th

16 exceptions xuml [5]). It needs to be translated to code for a concrete platform (such as Java) in order to be useful. How such a translation should be done is specified in model transformation specifications (point 3). These specifications contain precise rules, describing how to relate source model elements to target model elements. A model transformation is seldom a monolithic block but is rather composed of smaller, what we like to call, chained transformation units. More information on transformations is given in section 2.1. For now it should be adequate to see transformation units as building blocks of transformations. This paper deals with the storage of transformation traceability metadata directly into UML models so that transformation units can depend on that information in order to improve their own element mappings. Transformation traceability links provide us with a complete or partial history of model changes caused by the transformation units that were executed against a model. Such traceability links can be used to reason about past transformations. We believe that it can be beneficial to allow transformation units themselves to make use of these traces. We will discuss how individual transformation units can be made more modular and as a consequence easier to maintain and reuse when we allow them to depend on traceability links left behind by past transformations. The next section contains a discussion on model transformations and how a transformation can be composed out of smaller units that may depend on each other. This section also includes an example of a dependable transformation chain and rounds up with a discussion of requirements for our traceability mechanism. In section 3 we describe a UML profile that supports our approach to transformation traceability and give an example of its application. We will wrap up this paper by drawing conclusions and discussing future work. 2 Model Transformations We have to clearly define what we understand by model transformations in the context of this paper. According to [6] we can classify the transformations that we are considering as endogenous UML transformations. This means that the source and the target of the transformations are both models in the UML. UML-to-UML transformations often require a model to be enriched using the UML profiling mechanism. A UML profile enables the attachment of additional, well-defined, information to model elements. This information can be used by transformations to specify their actions more precisely. Profiles are also suited to further constrain the use of model elements, so that they can effectively be used to describe pre- and postconditions of a transformation unit. A deeper discussion about how this can be done exactly is designated as our future work. In this section we first discuss the dependable transformation chain. Next we present an example that illustrates the previous concept. Finally we sum up the features that we require of a transformation traceability mechanism. Page 16 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

17 2.1 Dependable Transformation Chain The ultimate goal of the MDA is to start from highly abstract models and gradually move to more concrete models in order to eventually end up with models that can straightforwardly be implemented on a concrete technology platform. In the ideal case a complete model transformation is accomplished using a chain of small and reusable (possibly off-the-shelf) transformation units. We refer to transformation units as reusable transformation building blocks that implement a concrete transformation, preferably delimited to one concern such as logging, persistency and security. Each transformation unit applies well-defined, limited changes to a model. Good practice in software engineering shows us that it is useful to separate specification (what) from implementation (how). Transformation units adhere to this practice by externally specifying what they require and what they provide in terms of model characteristics, without having to refer to their implementation. In this paper we look at one aspect/characteristic of models that can be used in the external specification of a transformation unit, namely traceability information. Of course this type of information is also used to simplify transformation implementation but we do not address this in detail. (a) Independent course-grained chain (b) Dependable fine-grained chain Fig. 1. Conceptual transformation chain We argue that it is beneficial to denote precise dependencies between subsequent transformations units. Figure 1 shows two versions of the same transformation. The transformation unit execution order is indicated using full arrows, while dependencies are indicated with dotted lines. The first figure is composed of two independent transformation units the order of their execution does not matter. The second version consists of four units, from which transformation unit TFb relies on some model properties that are delivered (guaranteed) by TFa. TFd and TFc are related in a similar manner. One can immediately see that the transformation units of the second transformation are much smaller and hence should be easier to create and to maintain. ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 17 of 66

18 Transformation dependencies should be described explicitly at a high enough level so that transformation units don t rely on each other s implicit low level implementation details. By this we mean that they can only rely on externally quantifiable properties of the model without knowing the implementation details of other units. This implies that each transformation unit should clearly define what one can expect (require) from its provided output, without directly referring to other units (see provided, required in the figure). Such a philosophy is comparable to component based software engineering, which promotes the use of software units that only have explicitly defined dependencies in terms of provided and required interfaces. In this paper we will talk about transformation unit dependencies related to traceability information: TFb requires traceability information of type X to be present in the model, no matter who provides it. This formulation implies loosely coupled transformation units and requires that the structure of the traceability information is defined at a higher level than the transformation itself. In the following section we give a concrete example of how subsequent transformation units can use each other s traceability links. We also argue that sometimes it is even required for transformation units to be aware of each other s operations on the model. 2.2 Example To get a better grasp of transformation traceability dependencies we introduce an example transformation chain. The transformation units in this chain make use of profiles to guide their actions. The chain is constructed out of two transformation units (see figure 2a). The first one (GetSetTF ) adds a simple get- or set-operation to a class for each attribute that is marked with the Get or Set stereotype (both members of the GetSetProfile, not further defined here). The subsequent transformation unit (PersistTF ) adds persistency logic. Every attribute that is stereotyped with Save will be stored by the generated logic whenever the value of an attribute, stereotyped with SaveTR (SaveTRigger), is modified. PersistTF requires get/set related traceability links to be present in its input model, in this case provided by GetSetTF. This dependency is further explained in the next paragraphs. An attribute value should only be changed through its corresponding setoperation. Since all set-operations are generated by the (GetSetTF ) transformation unit, we can enforce this behavior. The PersistTF transformation unit can than rely on that set-operation to detect an attribute value change. This creates a dependency between the two units: PersistTF should add its persistency logic to each generated set-operation that corresponds to an attribute marked with SaveTR. To allow PersistTF to do this, (GetSetTF ) has to leave behind enough information in order to find a set-operation for each attribute of interest. In fact PersistTF does not care who (which transformation unit or person) inserts that information in the model, it just states the type of traceability information required. Page 18 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

19 (a) The two transformation units... (b)...and their effects on a class. Fig. 2. A chain of two dependable transformation units. Figure 2b shows the effects of the two transformation units on a single class named Car. After execution of the GetSetTF transformation unit, get- and setoperations are added. Interesting transformation traces are shown by dotted lines. In this case they indicate the link between a get- or set-operation and its corresponding attribute. Next, the PersistTF transformation unit adds the SaveObject() operation to the class. Added transformation traces indicate that this operation saves both attributes (Speed and Type) and is executed whenever the SetSpeed() operation is called. The operations from within which SaveObject() must be called (certain set-operations) can only be derived from the transformation traceability links left behind by GetSetTF. Nevertheless, we must nuance this last statement. When using MDA/UML to its fullest one could locate each operation that modifies an attribute value from the actions (from the UML action semantics) that belong to that operation, without needing the transformation traces. Even than these explicit traces should offer the advantage of easier, more concise transformation implementations. This example perfectly illustrates why transformations are sometimes required to be aware of each other. Take for example the Speed attribute. It is annotated with Set and SaveTR. If the GetSetTF and the PersistTF transformation units were unaware of each other, they would both have to generate a set-operation for that same attribute. The GetSetTF has to generate one because the Set stereotype directly says so. PersistTF has to generate one in order to have a single point to detect modifications of the Speed attribute. We can also see from this example that transformation traceability links generated by different transformation units or even within one transformation unit can have different semantics. While they all indicate a source/target relationship, this relationship can be (has to be) refined in order to specify its semantics ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 19 of 66

20 more precisely. For example a transformation traceability link between a getoperation and its associated attribute could be described as destination reads the value of source. In the same way, a traceability link between the SaveObject() operation and its calling operations, could be described as destination is invoked when source is invoked. In general each traceability link has a is derived from relationship. The next section will identify the requirements that we desire from our transformation traceability approach. 2.3 Transformation Traceability Approach Many existing transformation languages already offer some kind of traceability mechanisms. Some of these languages are discussed and compared, with regard to traceability, to our approach in section 4. We want to position our approach relative to two transformation features as described in [6]: 1. Relationship between source and target: In place update (destructive or extension only) Creation of a new target model 2. Traceability links: Dedicated support by the transformation tool (automatically or manually added; links stored in the source or target model or externally) Manually coded using the same mechanisms as for other kinds of links (with links stored in the source or target model or externally) We would like to be able to access all valuable information that has ever been added to a model. This means that even model elements that have been made obsolete by a transformation unit still need to be available. They could for example be useful in understanding and adapting a transformation at a later stage. Accordingly we cannot allow source elements to be permanently deleted because that action would remove potentially valuable information. In addition, if the model travels somewhere, the traceability information should travel along with it. This implies that all information should be stored in the model itself and not as an external or semi-external artifact. We think that traceability is an important enough concern to support traceability links as first order entities. Because of its importance, all traceability information should be stored as an integral part of the model. The insertion of such information should, to a certain extent, be handled by the transformation units themselves since they know best where to add useful information and what kind of information to add. In addition this is the only way to prevent an abundance of purposeless traceability links we only want to know about the interesting links. The two former paragraphs indicate that our approach to transformations and traceability cannot be precisely classified in either one of the aforementioned categories. We can best describe our desired approach as non-destructive in place update with the ability to mark elements as deleted and with dedicated support Page 20 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

21 for traceability links stored in the model. In this fashion all information stays in one model; removed elements are just marked as such. We can summarize four important requirements that our transformation traceability mechanism possesses: 1. Transformation traceability information needs to be left behind by all transformation units, for each important change they make to the model. 2. Traceability links need to be extended with transformation unit specific information to create semantically rich links. 3. All information needs to be kept in the UML model itself, in a transformation technology independent manner. In this fashion all tools can operate on the model, even if they don t understand the extra information. 4. It needs to be possible to easily add trace links manually for non-automatic transformations or manual adaptations of transformation results. The next section contains a description of how the UML profiling mechanism can be used to add traceability links to our models, fulfilling these requirements. 3 Transformation Traceability Profile The UML offers inherent support for extending itself through profiles. Using stereotypes and tagged values we can, to some extent, add our own semantics to existing UML elements. This mechanism suffices to add traceability support to the language. We will discuss our basic traceability profile, followed by ways in which it should be extended for specific purposes. 3.1 The Basic Profile Figure 3 shows the metamodel we created to support our traceability mechanism and its mapping to a UML profile. An ElementMapping depicts a relationship between zero or more InputElements and one or more OutputElements. It can be thought of as a basic (atomic) unit of transformation. Input- and OutputElements are both types of model elements (TFElement). A collection of InputElements acts as an information source from which one or more OutputElements can be derived. An InputElement has a deleted attribute that can be set to true if the element needs to be removed from the model. In this fashion an element is never lost permanently. An ElementMapping can be assigned a transformation class (TFType) such as refactoring, refinement, merging etc. All ElementMappings are owned by their creating TransformationUnit, which can contain additional information describing the transformation unit. What this information should be exactly will not be further described here since it is closely related to describing more general transformation dependencies as in the dependable transformation chain. This will be further investigated in future work. The Uses and Replaces classes are two specialized ElementMappings. Uses depicts that the target elements use the ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 21 of 66

22 Fig. 3. The transformation traceability metamodel and its mapping to a UML profile. Page 22 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

23 source elements in a way and that the source elements are untouched while Replaces depicts that the source elements are replaced by the target elements, so all source elements are marked as deleted. The concepts presented in the metamodel need to be mapped to appropriate stereotypes and tagged values. The relationship between Input- and OutputElements is represented as the stereotype (Mapping) of the UML Dependency element. The association of a ElementMapping to its TransformationUnit is represented by the CreatedBy stereotype, also as a type of Dependency. The TransformationUnit itself is represented as a Comment element. Probably this will be changed in future versions. Finally we have a stereotype Deleted that can be applied to each UML Element. To align the semantics of the profile exactly to those of the metamodel it is required to introduce some additional constraints. These constraints can be written in the Object Constraint Language (OCL) [7]. Due to space restrictions and since these constraints are not essential to understanding the model, we do not discuss them here. The metamodel and consequently the profile are deliberately kept very basic. The profile offers the following concepts: Dependencies between source and target elements; dependencies between a mapping and the transformation unit that created it; marking of source elements as deleted. These capabilities readily fulfill requirement 1. Of course applying a profile does not automatically take care of inserting the right links. The insertion of the profile constructs remains the responsibility of the transformation units. If a transformation unit wants to insert more specific traceability links we can easily extend the profile, which addresses requirement 2. The use of a profile also ensures transformation technology independency (requirement 3) and allows for easy manual editing (requirement 4). In addition it should not be very difficult for existing UML tools to selectively show or hide Deleted-stereotyped elements or selected types of traceability links. A further discussion about extending the TFTraceProfile, including an example, can be found in the next subsection. 3.2 Extending the Profile The power of the traceability profile lies in its extensions. If a transformation unit wants to leave behind useful information, it needs to extend the traceability profile. Because the concepts in the traceability profile are so generic they need to be enriched with transformation specific information. In practice this will most frequently come down to a specialization of the Mapping stereotype. In that fashion different types of traceability links can be introduced. All these different links can convey there own specific semantic meaning. There are two possibilities to extend the traceability profile. We can define a completely new, transformation unit specific, profile based on TFTraceProfile. This derived profile will than only contain new types of traceability links ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 23 of 66

24 with a specific semantic meaning. Alternatively we can add traceability links to existing profiles by creating a new profile that imports both the elements of the existing profile and those of TFTraceProfile. It makes sense to extend an existing profile with the traceability profile if it is applied to a model as part of the result of a transformation. Figure 4 gives an example of such a profile extension. In this example we take the existing GetSetProfile (see subsection 2.2 for a short explanation) and the TFTraceProfile to create the TracedGetSetProfile. The TracedGetSetProfile needs to define some new Mappings, give them a useful meaning and further constrain their use. We define two subclasses of the Mapping stereotype, named Reads and Writes. These two associate generated get- and set-operations with their respective attributes. This implies some additional constraints, which we do not discuss here. Using these semantically richer traceability links, a subsequent transformation unit can easily search which operations read or modify any given attribute and possibly add extra logic to these operations. Fig. 4. The TracedGetSet profile. 4 Related Work The use of traceability information in models can be subdivided into two areas, namely requirements traceability and transformation traceability. Although these two areas have some overlap, our approach tends more towards the second one. Requirements traceability [8] is used particularly in software evolution management. When a stakeholder issues a new or changed requirement we want to be able to easily localize the (modeling) artifacts that are influenced by that requirement. Managing the links between (textual) requirements and implementing artifacts at several levels throughout the development process is generally Page 24 of 66 ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005

25 referred to as requirements traceability. A more specific flavor of the general requirements traceability, the refinement/abstraction relationship, is discussed in [9]. A reference metamodel for representing requirements traceability links within the UML is described in [8]. The authors of that paper choose to integrate their mechanisms into the UML in order to represent all software artifacts in one model. In a sense transformation traceability can also be seen as a specific type of requirements traceability and can be integrated with and augment other approaches. Our approach is targeted towards the tracing of model changes by transformations without taking regard to requirement documents. As a consequence our approach is more related to the traceability mechanisms of model transformation languages and tools. We discuss and compare three of them here: the IBM Model Transformation Framework [10], the Atlas Transformation Language [11] and the latest Query/View/Transformation (QVT) proposal issued by the QVT-Merge group [12]. The MTF provides a declarative-only transformation language that performs bidirectional mapping and reconciliation of model elements. During the mapping and resolution process, existing model elements are related and new ones are created to conform to the described relations. The related model elements are kept together using run-time constructs called mappings. These mappings are only used internally in the transformation engine. The user can only influence them slightly by directly changing the transformation implementation itself. Even than this has no advantage because he cannot access them further down the transformation chain. The ATL is, in contrast to the MTF, a hybrid language. This means that both declarative and imperative constructs can be used to specify a transformation. Like the MTF, the ATL automatically keeps track of internal transformation traces between related model elements (TraceLinks). Again, the user has little influence on the creation or usage of the links. In [13] the possibility of the ATL engine to export the generated traceability links is mentioned. This enables subsequent transformations to use these links by designating the traceability model itself as an extra input. We do not have a clear understanding of the feasibility of such an approach. QVT in its current incarnation seems to be a more powerful transformation language compared to MTF and ATL. Unfortunately it currently is only a paper specification without any usable form of tool support. The language is comparable to the ATL because of its hybrid nature. QVT also automatically creates traceability links between related elements. As an added advantage, the user can use these links (implicitly) at run-time to dynamically find and modify certain already transformed model elements. Future actions can than be based on the result of such queries. The current proposal includes several examples on how the user can influence the creation of traceability links by restructuring his transformation. In our approach, a traceability link is typed by a stereotype specification, independent of a transformation (language) implementation. This is in contrast to the three transformation approaches, QVT, MTF and ATL, mentioned here. ECMDA-TW 2005 Proceedings, Nuremberg November 8th 2005 Page 25 of 66