Towards Incremental Round-Trip Engineering Using Model Transformations

Thomas Buchmann and Bernhard WestfechtelUniversity of Bayreuth

Chair of Applied Computer Science IBayreuth, Germany

firstname.lastname@uni-bayreuth.de

Abstract—Model-driven software engineering is supportedwith the help of model transformations. At present, thetechnology for defining and executing uni-directional batchtransformations seems to be well developed, while bi-directionaland incremental transformations are more difficult to handle.In this paper, we present a bi-directional and incrementaltransformation tool for round-trip engineering between classdiagrams and Java source code. Our focus lies on the model-driven construction of this tool with the help of a set of modeltransformation tools. Thus, our work serves as a case study ofapplying and composing existing model transformation tools.

Keywords-round-trip engineering; model transformations;model-driven engineering;

I. INTRODUCTION

Model-driven software engineering puts strong emphasison the development of high-level models rather than onlow-level source code. In an idealized forward engineeringprocess, an initial requirements model is transformed in aseries of steps into a working implementation. However, inpractice changes may have to be propagated back, resultingin a round-trip engineering process. Furthermore, while largeparts of an application may be generated from models, itmay still be necessary to complement generated code withmanual implementations.

In this paper, we examine a standard use case: incrementalround-trip engineering between design models and sourcecode (Figure 1). More specifically, we address the couplingbetween a UML class diagram and Java source code. Bothmodel and code may be edited concurrently, and changesmay be propagated back and forth to maintain consistency.

Model-driven software engineering may be applied suc-cessfully only if end users such as designers and pro-grammers are supported by powerful tools. Unfortunately,development of tools for model-driven software engineeringrequires considerable effort. Thus, tool providers essentiallyface the same problem as end users: they need powerfulmeta tools to reduce their implementation effort.

In response to this need, a variety of languages andtools for model transformations have been developed andrealized. Using these languages, a tool may define a modeltransformation at a high level of abstraction, eliminatingthe need for a laborious implementation in a conventionalprogramming language.

UML Model Java Source Code

edit edit

Modeler Programmer

Figure 1. Round-trip support between design model and source code

The work presented in this paper was carried out in thecontext of the Valkyrie project, which is dedicated to thedevelopment of a UML-based environment for model-drivensoftware engineering [1]. The main focus of Valkyrie lieson the provision of model editing and model transformationtools. It is important to notice that Valkyrie is built not onlyfor, but also with model-driven engineering. To reduce theimplementation effort, we reuse existing technology as faras possible.

As part of the Valkyrie environment, we built a toolfor incremental round-trip engineering between UML classdiagrams and Java source code. In this paper, we describehow we applied and composed existing model transfor-mation tools to provide the round-trip engineering toolto end users of the Valkyrie environment. Unfortunately,there is no single model transformation tool available whichsupports incremental and bi-directional model-to-text trans-formations. Therefore, we had to use multiple tools andcompose them in an effective way.

Thus, the work presented in this paper may serve as a casestudy for applying existing model transformation technology.The case study provides some insight into strengths andweaknesses of the employed model transformation tools.Furthermore, it simultaneously serves as an example ofengineering with model transformations.

II. APPROACH

Our round-trip engineering tool demands for incrementalbi-directional transformation between model and text. Ex-isting model transformation approaches do not meet thisrequirement, as the following brief discussion demonstrates.

Template-based code generation supports the generationof source code by templates which mix static and dy-namic fragments. Tools such as the EMF code generator[2] were built with this technology. Many model-to-texttransformation tools have been realized with the help oftemplate languages such as JET, XPAND, or Mof2Text [3].With the help of templates, uni-directional model-to-texttransformations may be defined. Tools such as e.g. Acceleo,which is based on the Mof2Text standard, in addition supportincremental propagation of model changes to the sourcecode.

ATL [4] is a popular tool for defining model-to-modeltransformations. However, ATL primarily focuses on uni-directional batch transformations. In addition, ATL allowsfor the definition of in-place transformations on a singlemodel. Only recently proposals have been made for addingbi-directional transformations [5], but those approaches arejust prototypical.

Query View Transformations (QVT) [6] is an OMGspecification for model-to-model transformations. The spec-ification comprises both a procedural language — QVTOperations — and a declarative language — QVT Relations.Only the latter supports incremental bi-directional model-to-model transformations: In QVT Relations, which has beenimplemented e.g. in the tool medini QVT1, a single set oftransformation rules may be defined which may be executedin both directions (even incrementally). In QVT Operations,each of the directions would have to be realized by a separatetransformation definition, and the transformation writer isresponsible for specifying mutually inverse transformations.

Triple graph grammars (TGGs) [7] support incrementalbi-directional model-to-model transformations, as well. Thebasic idea behind TGGs is to interpret both source andtarget models as graphs and additionally maintain a cor-respondence graph whose nodes reference correspondingelements from both source and target graphs, respectively.The construction of triple graphs is described with a set ofproduction rules which are used to describe the simultaneousextension of the involved domains of the triple graph.The rules themselves do not contain any information abouta transformation direction, which makes TGGs an idealcandidate for bi-directional and incremental transformationproblems, like the one that is subject of this paper. Toolsupport in the Eclipse context is provided for example byMoTE [8], an extension to MDELab, eMoflon [9], EMorF[10], or TGG Interpreter [11].

Both QVT Relations and TGGs may be used to syn-chronize models; however, the Java source code is nativelyrepresented as text. Thus, a text-to-model transformationis also required for our round-trip engineering tool. ForJava, this transformation is provided by the MoDisco tool,which offers a parser transforming Java source code into

1http://projects.ikv.de/qvt

an instance of the MoDisco [12] Java metamodel. Thismetamodel provides a higher level of abstraction than thepure Java abstract syntax tree. Furthermore, it is based onEcore which allows to use existing model transformationtools in the Eclipse world.

Using some of the model transformation tools mentionedabove, we realized our round-trip engineering tool in thefollowing way:

1) For bi-directional and incremental model synchroniza-tion, we employed the TGG Interpreter, which is usedto maintain consistency between the UML model andthe Java model. Alternatively, we could have selecteda tool for QVT Relations; this is planned as futurework.

2) For uni-directional and incremental model-to-texttransformation, we selected Acceleo, which is basedon the Mof2Text standard.

3) Finally, for the inverse transformation we reused andadapted the MoDisco discoverer such that it operatesincrementally.

An important design issue concerns the division of laboramong the components involved in the transformations. Withthe help of the TGG, a purely structural transformation isperformed, i.e., the transformation deals only with the struc-ture (mapping of UML to Java classes, primitive propertiesto fields, etc.). Behavior is addressed only by the Acceleo-based code generator. In particular, the code generator intro-duces the access methods for properties which are requiredto correctly implement the semantics of associations. In thisway, the TGG rules are simplified significantly, and provenmodel-to-text technology may be used to generate methodbodies (it would be quite awkward to do this in the TGGrules).

III. EXAMPLE

In the following we sketch an example usage scenario anddescribe how the different models involved in the round-trip process interact. Let us start with plain Java sourcecode. The upper left box in Figure 2 shows two simple Javaclasses. The classes ClassA and ClassB both contain twoattributes of primitive and non-primitive type, respectively.Furthermore, ClassA also contains a method doSmth(). Afterthe source code files have been modified, the MoDisco Javadiscoverer is used to create the MoDisco Java model (Step1 in Figure 2). Please note, that we needed to adapt theMoDisco framework in order to work in an incrementalmode, i.e. in case of subsequent changes to the sourcecode, the existing Java model instance gets updated ratherthan created from scratch over and over again. After theJava model has been created, a TGG transformation isexecuted to create a corresponding UML model (Step 2).The non-primitive attributes have been transformed into anassociation connecting both classes. After that, the usermodifies the class diagram and adds a method run() to class

Java source code

MoDisco Java model

MoDisco Java model MoDisco Java

model

UML model

UML model

Figure 2. Round-trip usage example

ClassB. After this change, the TGG transformation is exe-cuted in the opposite direction to update the MoDisco Javamodel. Furthermore, the (incremental) M2T transformationis performed to update the Java source code accordingly.After that, the user implements the method doSmth(). Thischange triggers the MoDisco discoverer, which updatesthe Java model. After Step 3, the Java model now alsocontains accessor methods for attributes or associations suchas e.g. getCounter() and the body of doSmth() (not shown).Accessor methods can be identified using the Javadoc tag@accessor as shown in Figure 2. Please notice that the UMLmodel is not changed because the updates of the Java codeand model are not relevant for the UML model. Now theuser decides to modify the source code and to change thename of the method run() to execute(). Furthermore, the useradds another method named printLogFile() to ClassB. Afterthe source code has been modified, the MoDisco Java modelgets updated in Step 4. Afterwards, the TGG transformationis executed to update the UML model accordingly (Step 5).The result is shown in the bottom right box of Figure 2,which depicts the cutout of the class diagram.

IV. MODEL AND CODE SYNCHRONIZATION WITH TGGS

Our modeling tool Valkyrie uses the UML2 metamodelprovided by Eclipse MDT project2. For representing Javaprograms, MoDisco provides an Ecore-based Java model.

The structure of both models involved in the round-trip engineering process is similar. They both use packagesto group elements belonging to the same namespace. Aspecialized package, the so called Model is used as rootobject in both models. This fact helps to keep the TGG

2http://www.eclipse.org/modeling/mdt/?project=uml2

Figure 3. TGG rule for classes

rules relatively simple in most cases. In the following, wepresent a sample TGG rule to match UML and Java classesrespectively. Due to space restrictions, it is impossible toshow all of them. Furthermore, lots of rules have the samestructure, like rules for classes, interfaces, enumerations,datatypes or the inheritance hierarchies between these types.

UML class ↔ Java class: Figure 3 shows the TGGrule to match UML classes to Java classes nested in theircorresponding containers — UML packages and Java pack-ages, respectively. Each TGG rule describes a synchronousextension of the source graph (on the left), the correspon-dence graph (in the middle), and the target graph (on theright). Nodes are attached to the respective graphs by edgesconnecting them to domain nodes (on the top). The left-handand right-hand sides of a rule are shown in a single diagram.Nodes and edges to be created are shown in green color andare annotated with ++. Yellow boxes represent OCL attributeconstraints. Here, they are used to ensure that both classeshave the same name and to ensure that the visibilities ofboth classes match. From the synchronous rule, two directedrules are derived which create a UML class from a Java classand vice versa. Furthermore, the TGG interpreter propagatesmodifications such as name changes. Thus, incrementalchange propagations in both directions come for free withoutthe need for an explicit specification. In the directed rules,the name constraints shown in Figure 3 are used for attributeassignment. For example, in the forward rule the UML classalready exists, and its name is fixed. The name of the Javaclass is assigned the value specified in its attached constraint,which simultaneously satisfies the constraint of the UMLclass as a postcondition.

UML association ↔ Java fields: As stated above, prop-erties referring to non-primitive types are considered as asso-ciation ends. In the UML, an association must have at leasttwo ends which are represented by properties referring tothe corresponding types involved in the association. There isno equivalent for an association in Java. The correspondingassociation ends are expressed by fields with the respective

Figure 4. TGG rule for bidirectional associations

types. Eventually, like in our tool Valkyrie, accessor methodsare also generated which ensure the referential integrity ofbidirectional associations, or which preserve containmentsemantics. However, generation of these methods is handledby the M2T transformation rather than by the TGG. Figure 4shows one of the TGG rules for transforming associations.The rule assumes that the association is binary (Valkyriecurrently supports only binary ones) and bi-directional.Furthermore, both association ends must be owned by therespective classifiers, they must be single-valued, and theparticipating classifiers must be different. The associationends are represented by the properties named end1 andend2 respectively. They refer to the corresponding fielddeclarations fd and fd2 in the Java model. The propertiesare connected to the Association using the non-containmentmemberEnd reference. Furthermore, the ends are owned bythe involved classifiers type1 and type2. These classifiersrefer to their corresponding counterparts in the Java modeljavaType1 and javaType2. Features like names and visibilityof the corresponding elements are handled in a similar wayas described for the previous rules.

In order to instruct the subsequent M2T transformation,annotations are added to the Java model for preserving infor-mation which would otherwise be lost in the transformationfrom the UML model to the Java model.

V. CONCLUSION AND FUTURE WORK

In this paper, we presented our approach to realize incre-mental round-trip engineering between models and sourcecode in model-driven development processes. The solutionof this problem demands for bi-directional and incrementalmodel transformations. In our first implementation, we usedTGGs for this purpose. The TGG operates on an interme-diate language model for Java provided by the MoDiscoframework [12]. TGG rules are used to describe correspon-dences between the respective model elements in a declara-tive way. Using the TGG-interpreter engine [11], these rulesare executed at runtime whenever one of the involved models

are changed. Since QVT relational also provides support forbi-directional incremental model transformations, we willinvestigate in future work how good or bad QVT-r performscompared to TGGs on this specific use case.

REFERENCES

[1] T. Buchmann, “Valkyrie: A UML-Based Model-Driven En-vironment for Model-Driven Software Engineering,” in Pro-ceedings of the 7th International Conference on SoftwareParadigm Trends (ICSOFT 2012), Rome, Italy, 2012, pp.147–157.

[2] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks,EMF Eclipse Modeling Framework, 2nd ed., ser. The EclipseSeries. Boston, MA: Addison-Wesley, 2009.

[3] OMG, MOF Model to Text Transformation Language, Version1.0, formal/2008-01 ed., OMG, Needham, MA, Jan. 2008.

[4] F. Jouault, F. Allilaire, J. Bezivin, and I. Kurtev, “ATL: Amodel transformation tool,” Science of Computer Program-ming, vol. 72, pp. 31–39, 2008, special Issue on ExperimentalSoftware and Toolkits (EST).

[5] I. Sasano, Z. Hu, S. Hidaka, K. Inaba, H. Kato, andK. Nakano, “Toward bidirectionalization of ATL with ground-tram,” in Proceedings of the 4th International Conference onTheory and Practice of Model Transformations (ICMT 2011),ser. LNCS 6707, Zurich, Switzerland, 2011, pp. 138–151.

[6] OMG, Meta Object Facility (MOF) 2.0 Query/View/Trans-formation, v1.1, formal/2011-01-01 ed., Object ManagementGroup, Needham, MA, Jan. 2011.

[7] A. Schurr, “Specification of Graph Translators with TripleGraph Grammars,” in Proceedings of the 20th InternationalWorkshop on Graph-Theoretic Concepts in Computer Science(WG 1994), ser. LNCS, vol. 903, Herrsching, Germany, 1994,pp. 151–163.

[8] H. Giese, S. Hildebrandt, and L. Lambers, “Bridging thegap between formal semantics and implementation of triplegraph grammars - ensuring conformance of relational modeltransformation specifications and implementations,” Softwareand Systems Modeling, 2012, online First.

[9] A. Anjorin, M. Lauder, and A. Schurr, “eMoflon: A Metamod-elling and Model Transformation Tool,” in Joint Proceedingsof the Co-located Events at ECMFA 2012, Copenhagen,Denmark, 2012.

[10] L. Klassen and R. Wagner, “EMorF - a tool for model trans-formations,” in Proceedings of the 7th International Workshopon Graph Based Tools (GraBaTs 2012), ser. ECEASST 54,Bremen, Germany, 2012.

[11] E. Kindler and R. Wagner, “Triple graph grammars: Concepts,extensions, implementations, and application scenarios,” Soft-ware Engineering Group, Department of Computer Science,University of Paderborn, Tech. Rep. tr-ri-07-284, June 2007.

[12] H. Bruneliere, J. Cabot, F. Jouault, and F. Madiot, “MoDisco:a generic and extensible framework for model driven reverseengineering,” in Proceedings of the IEEE/ACM InternationalConference on Automated Software Engineering (ASE 2010),Antwerp, Belgium, 2010, pp. 173–174.