Traceability in Model to Text Transformations Jon Oldevik, Tor Neple SINTEF Information and Communication Technology, Forskningsveien 1, 0314 Oslo, Norway {Jon.Oldevik, Tor.Neple@sintef.no Abstract. Traceability has been held as an important factor in Model Driven Development. This paper takes a look at traceability related to model to text transformations. This is done through presenting scenarios and needs for such traceability and presenting a possible solution to the challenge. Examples of how the proposed solution works have been included using concrete examples of models and transformations. Introduction The ability to create and maintain traces between artifacts in a Model Driven Development (MDD) setting has been presented a necessary capability in order to capitalize on the MDD paradigm. Traces between artifacts such as requirements, the use cases describing them, and the component diagrams describing their realization are scenarios that are plausible. This paper focuses on traces between the artifacts from the model world and artifacts that are text based. Text based artifacts are typically ASCII or ANSI based files, containing source code, markup language for documentation etc. The work presented in this paper should be seen in relation to the ongoing standardization effort on MOF Model to Text Transformations at the OMG [1]. An initial version of the work presented in this paper was part of a submission made by the authors to this RFP[2]. This paper is structured as follows; first the needs and requirements are discussed; then a solution is presented. The proposed solution is then instantiated through examples in order to illustrate the solution better. Background and Requirements A model-driven development scenario produces models at different abstraction level before producing source code based on detailed design models (PIM or PSM-models in MDA). The source code can then, depending on the level of detail of the models, be generated from the models. This leads to a strong need of having and maintaining traces between the model elements and the source code artifacts.
2 Jon Oldevik, Tor Neple Generated traces can be used for several purposes; documenting the link from implementation to model in order to show coverage; managing changes to models; managing changes to code; synchronizing models and code; performing impact analysis (what happens if). For the end user, the traceability mechanisms should be as transparent as possible, so as to allow focus on the core business; transformation and software engineering. A principle for allowing and honoring changes in generated artifacts is to distinguish protected and unprotected parts, e.g. to allow for the user to modify the unprotected while leaving the protected parts unchanged. This is a concern for the transformation architect. For the transformation user, the traceability is a concern when he/she needs to use it. Mechanisms for the end user to configure the traceability should be in place (turn in on/off and to set granularity of traceability). Traces generated in the trace model need to have certain properties in place in order to be useful. They need to reference the source model element that originated it. It also needs to reference the parts in the generated file set that is generated from this model element. Finally, it needs to reference the transformation rule that produced the trace. An end user can for instance find something wrong in the generated source code and easily find the model element(s) the code was generated from. If the error was not in the model it self, the trace into the rule in the transformation may be used to check whether the error was actually in the transformation. This latter case will probably be handled by the person responsible of writing the transformation. In the context of impact analysis, if a full traceability trace is in place from requirements through models to code, a user can see what parts of the model and code are possibly invalid after making a change to a requirement. This is an undertaking that would require a tool to work on a set of trace information that is generated by more than one tool. Conceptual Model The Trace metamodel defines a set of concepts that enables traceability between source model elements and locations in generated text files. This metamodel was developed as part of the work of defining a language for model to text transformations as a response to an OMG RFP [2] Central in the trace model is the logical segmentation of a file into blocks, some of which may be protected blocks. Blocks are identifiable units within a file. At the point in time when they are generated, the blocks may also have a specific location within the file. A protected block contains a set of segments which are relatively located within the block in terms of a starting and ending offset. These segments will allow traces from source model elements to the source file. Being part of a protected block, they can also be part of a manageable file in terms of change protection. Fig 1 shows the elements of the trace metamodel.
Traceability in Model to Text Transformations 3 Fig 1 Trace metamodel A trace contains a reference to the operation (transformation rule) that generated the trace and references to the originating model element and to the target traceable segment. The model element reference contains the id and name for the originating element. It also contains a feature reference, which points out a named feature within the model element (such as name for a Property class). Changes to source models are only an issue if the already generated text/code has been manually modified, and not yet synchronized with the model. In this case, traceability information can be used to synchronize modified text with newly generated text. Examples This section illustrates the usage of the trace metamodel given a very simple UML model containing a single class (Fig 2). Fig 2 Example model An example transformation to transform UML models such as this into Java classes is shown below. texttransformation UML2Java (in uml:"http://www.eclipse.org/uml2/1.0.0/uml") {
4 Jon Oldevik, Tor Neple uml.class::uml2javaclass () { file (self.name +.java ) 'public class ' + self.name ' {\n' self.ownedattribute->foreach(attr:uml.property) { attr.property2javaprivate () attr.propety2javagetter () '' { uml.property::property2javaprivate () { ' private ' + self.type.name + ' _' + self.name ';' uml.property::property2javagetter () { 'public ' + self.type.name + ' get' + self.name.firsttoupper() '() ' return _' + self.name + '; Using the example transformation, a single Java file (Person.java) is generated from the example model: public class Person { private String _name; public String getname () { return _name; Fig 3 shows an instance of the trace metamodel for this example.
Traceability in Model to Text Transformations 5 Fig 3 Trace model instance The trace instance contains six traces, which are linked to six corresponding traceable segments. Each trace references the originating transformation rule and a reference to the source model element. We see that the number of generated traces will be large for bigger models and more advanced transformations. (For example, the same transformation example executed on a model with 10 classes and 5 attributes would generate 260 trace instances.). All traces in the above model are generated relative to a single global block. When introducing unprotected areas where the user can modify code, the resulting trace model is split into several blocks. The modified transformation rule (property2javagetter) below contains one simple unprotected section. {' uml.property::property2javagetter () { 'public ' + self.type.name + ' get' + self.name.firsttoupper() '() unprotect { '// User code here' ' return _' + self.name + '; ' The resulting generated code will include codes that indicate the location where end users may modify; within the unprotected block. public class Person { private String _name; public String getname () { // #BID(7638444) Unprotected block // user code here // #EOB 7638444 return _name; The corresponding trace model instance will contain the same amount of traces, but two protected blocks instead of one. Fig 4 Trace model with protected blocks
6 Jon Oldevik, Tor Neple The positions of the segments are relative to each block. If a user modifies the generated file (within the unprotected area), only the position of the subsequent block(s) needs to be updated in the model in order to keep consistency. Conclusion This paper has presented a rather detailed design for handling traceability in model to text transformations, through a conceptual model. Through the presentation of example transformations, input models and resulting text artifacts and traceability model instances it has been shown that the approach is viable. As the examples show, the instances of the traceability model become quite large even for the small examples presented here. This will probably not be a practical problem as the models will be generated automatically and the information in them will be interpreted by tools rather than humans. In the current submission on MOF Model to Text Transformations [3] the details of how the traceability functionality is to be implemented has been removed. The proposal now only states what functionality is required from the transformation language. The approach presented in this paper is partly implemented in the MOFScript tool [4], which is now a part of the Eclipse GMT 1 project. In the context of interoperability between development tools it would be beneficial if metamodels for traceability were to be standardized. The idea of doing impact analysis based on traceability information illustrates this, as more than one tool may contribute to the traceability, and there is a need to be able to use this information in a consistent manner. Acknowledgement: The work presented in this paper undertaken as a part of the MODELWARE project. MODELWARE is a project co-funded by the European Commission under the "Information Society Technologies" Sixth Framework Programme (2002-2006). 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. References 1. OMG, MOF Model to Text Transformation Language RFP. 2004, Object Management Group. http://www.omg.org/cgi-bin/apps/doc?ad/04-04-07.pdf. 2. OMG, Revised submission to the MOF Model to Text Transformation RFP. 2005, Object Management Group. http://www.omg.org/cgi-bin/apps/doc?ad/05-11-03.pdf. 3. OMG, Revised submission for MOF Model to Text Transformation Language. 2006, Object Management Group. http://www.omg.org/cgi-bin/apps/doc?ad/06-04-03.pdf. 4. SINTEF, MOFScript. 2006. http://www.modelbased.net/mofscript/index.html. 1 Generative Model Transformer Project: http://www.eclipse.org/gmt