Maintaining Invariant Traceability through Bidirectional Transformations

Yijun Yu1, Yu Lin2, Zhenjiang Hu3, Soichiro Hidaka3, Hiroyuki Kato3, and Lionel Montrieux1

1 Department of Computing, The Open University, Milton Keynes, United Kingdom2 Department of Computer Science, University of Illinois at Urbana-Champaign, USA

3 National Institute of Informatics, Tokyo, Japan

Abstract—Following the “convention over configuration”paradigm, model-driven development (MDD) generates code toimplement the “default” behaviour that has been specified by atemplate separate from the input model, reducing the decisioneffort of developers. For flexibility, users of MDD are allowedto customise the model and the generated code in parallel. Asynchronisation of changed model or code is maintained byreflecting them on the other end of the code generation, aslong as the traceability is unchanged. However, such invarianttraceability between corresponding model and code elementscan be violated either when (a) users of MDD protect customchanges from the generated code, or when (b) developers ofMDD change the template for generating the default behaviour.

A mismatch between user and template code is inevitable asthey evolve for their own purposes. In this paper, we propose atwo-layered invariant traceability framework that reduces thenumber of mismatches through bidirectional transformations.On top of existing vertical (model↔code) synchronisations be-tween a model and the template code, a horizontal (code↔code)synchronisation between user and template code is supported,aligning the changes in both directions. Our blinkit tool isevaluated using the data set available from the CVS repositoriesof a MDD project: Eclipse MDT/GMF.

I. INTRODUCTION

Aiming at productivity, “convention over configuration”is a software design paradigm meant to reduce the decisioneffort of developers while preserving flexibility. Followingthis paradigm, model-driven development (MDD) of soft-ware projects (e.g., Eclipse Modeling Framework, EMF)generates code from models to implement the “default”behaviour, which is specified by a template separate from theinput model. As users of MDD, programmers are allowed tocustomise the generated code, and the modellers are allowedto modify the models further. To support the eventualround-trip synchronisation of model and code [1], markersfor traceability correspondence (e.g., @generated) areinserted at the beginning of the generated methods byMDD, indicating to the programmers that all changes to themodel and the template will be reflected by the annotatedmethod. In other words, any change made by programmerson such methods will get lost after another round of codegeneration. In order to protect such changes in the user codefrom getting lost, programmers are allowed to modify the@generated marker to @generated NOT, instructingthe code generators to skip the user-specified methods.

This technique is common in MDD practice. Anotherexample is the Acceleo Model2Text project, which uses

“[protected] ... [/protected]” annotations toenclose user-specified parts for arbitrary textual outputs. Toillustrate this problematic use in development, we use EMF,the Eclipse Modeling Framework (EMF) ∗ as an exemplarMDD framework: The template code is generated by EMFfirst, later refined manually into functioning user code. Onceprogrammers change the model and regenerate the templatecode, its traceability to the user code becomes necessary.

Ideally, a round-trip engineering approach should supportthe correct propagation of changes in both directions [2].Current state-of-the-art MDD tools such as EMF main-tain the synchronisation of model and code by reflect-ing changes in both directions. However, such invarianttraceability links between corresponding model and codeelements can be easily violated either when (a) users ofMDD protect custom changes from the generated code bychanging @generated to @generated NOT or when (b)developers of MDD change the template for generating thedefault behaviour for those @generated methods, losingall users’ change(s). In either case, a better solution wouldbe to preserve the changes made by the users as well as thechanges made on the model as long as they are consistent.In Section III, a detailed example will illustrate the problemssuch a mismatch can cause.

We consider in this paper that the mismatch problembetween user-modified and template-generated (hereafter“user” and “template”) codes is inevitable as they evolvefor their own purposes, and propose a two-layered invarianttraceability framework that merges the changes when possi-ble through bidirectional transformations. The first layer ofthe framework synchronises the structural changes betweenthe model and the template code at the API level vertically(denoted by model↔code) using existing state-of-the-artMDD tools such as EMF; the second layer synchronisesthe behavioural changes between the template code and theuser code inside the method bodies horizontally (denoted bycode↔code) if users wish to preserve both types of changes.Aligning these changes in both directions, our blinkittool is evaluated using the data set available from the CVSrepositories of the Eclipse MDD projects EMF and GMF.

To effectively use the invariant traceability frame-work, users only need to insert a traceability annotation@generated INV, instructing the code generator to au-

∗See http://www.eclipse.org/modeling/emf

978-1-4673-1067-3/12/$31.00 c© 2012 IEEE ICSE 2012, Zurich, Switzerland540

tomatically (a) compute the differences between the currenttemplate and user-modified methods; and (b) derive a bidi-rectional transformation for future code generation to reflectchanges of the model or changes of the template back tothe user’s methods. The tool raises warnings when there areinconsistencies between the template and the user code.

A prototype has been successfully applied to changesrecorded in the evolution of the GMF framework from itsCVS repository, which shows that our new approach ofround-trip engineering is promising and potentially usefulin practice. Fig. 1 presents an overview of blinkit whenit is applied to the case study of EMF/GMF, where EMFis the synchronisation framework for vertical traceabilityand blinkit is the horizontal synchronisation counterpart.Examples indicate that when the complementary changes totemplates and user-modified code are conflicting or redun-dant, our tool can avoid some dead code redundancies andraise some warnings as compilation errors.

Our major technical contributions are listed as follows:

• From a user’s perspective, a new type of annotations@generated INV is supported as explicit mark-ers for automatic maintenance of invariant trace-ability between template (@generated) and user(@generated NOT) code, whereas @generatedNOT marked methods only keep user’s change whileignoring changes made to the model.

• A novel algorithm is proposed for automatically gener-ating a one-pass bidirectional transformation from themeaningful differences between the template code andarbitrarily modified user code such that the round-triprelation between the structures of the model and thecode can be correctly maintained.

• An empirical study on a CVS repository of the state-of-the-art MDD project GMF highlights the benefits ofmaintaining invariant traceability links, especially whenthere are 178 changes to the @model parts that havean impact on the bodies of 54% of the 28,070 revisionsof methods marked by @generated NOT.

Compared to existing MDD and traceability approaches,blinkit derives invariant transformations automaticallyfrom meaningful changes in the source code [3]. Unlike ourinitial work that proposes to apply bidirectional transforma-tions directly on class diagrams and Java code [4], this worktakes full advantages of the state-of-art synchronisations ofmany-to-many vertical traceability links between the modeland the template code, such that the horizontal bidirectionaltransformations are applied only to the method bodies rele-vant to the user-modified behaviours. Since the template andthe user method code are at the same level of abstraction,blinkit is allowed to derive a forward transformationfrom the user method to the generated method. Our initialwork [4] needs to monitor the execution logs of user-specified ATL transformations, which is no longer needed.

CVS  (GMF)   Generated  

elements  (EMF  @generated)  

v2  v1  

Modeling  elements  

(EMF  @model)  

v2  v1  

User  modified  elements  (EMF  @generated  INV)  

v2  v1  

Horizontal  Bidirec2onal    Sync.  

ver=cal  sync.  (EMF)  

Figure 1. An overview of the horizontal and vertical traceability links inthe bidirectional invariant traceability framework: blink. V1 and V2 aretwo revisions of model, template or user codes extracted from the CVSrepository of a software development project using EMF code generation.

The remainder of this paper is organised as follows:Section II gives preliminary knowledge on EMF and in-troduces the bidirectional transformation mechanism. Sec-tion III provides one example to illustrate the synchronisa-tion problem of invariant traceability. Section IV overviewsthe round-trip process for horizontal and vertical invarianttraceability and indicates the position of blinkit in theoverall process. Section V describes the technical details ofblinkit, the generation of bidirectional transformationsfrom meaningful changes, and the one-pass optimisation forefficiency. Section VI presents the observations of the CVSevolution history of the GMF project to show the number ofcases where the @generated INV markers can be useful.Section VII compares related work, Section VIII concludes.

II. BACKGROUND

A. EMF as a State-of-the-Art MDD FrameworkThe Eclipse Modeling Framework (EMF) is a MDD

framework and a code generation facility for buildingEclipse tools and other applications around a structuredmodel. From a meta-model, EMF generates default (i.e.,template) Eclipse plugin tools that consist of Java classesfor manipulating a model, along with Java adapter classesfor viewing and editing a model. From a rather complexmeta-model, it is impractical to generate all the source codebecause programmers may customise the default behaviourby modifying some parts of the code in order to achieve theirown goals. Using EMF, the template code is generated first,and later refined manually into functioning user code. Onceprogrammers change the model and regenerate the templatecode, traceability to and from the user code is needed.

The MDD part of the EMF consists of one code gen-eration component (i.e., JMerge) to generate source codefrom a meta-model (i.e., .ecore). The template used by thecode generator is specified in the JavaJET template languagesimilar to that of JSP, which will bind the template variableswith the default values specified in the corresponding .gen-model configuration files. There is no one-to-one mapping

541

1

2

a

3

b

4

c

5

a

a

c

6

d

Figure 2. A simple rooted and edge-labelled graph

between a class operation and a Java method in this codegeneration: a class in the class model can be implementedin multiple classes in the model, impl, util, edit, andeditor packages, scattered across the generated model,edit, editor, and test plugins. In addition, there willbe Package and Factory classes created and instantiatedby the classes in the model. It is hard to maintain such many-to-many relations using traditional traceability techniques.

EMF is used in this study both as a subject matter anda component of our solution. Parts of the EMF tool werealso generated using the EMF code generator. It can beseen from the existing EMF implementation that developersmarked some methods as @generated NOT to preservethe changes that cannot be generated from the Ecore modelsalone. It can therefore be expected that the code generatedfrom EMF will be modified by users.

B. Bidirectional Transformation

We use GRoundTram [5] to do bidirectional graph trans-formations. This well-behaved framework guarantees theround-trip property in bidirectional model transformations.

A model transformation is described in UnQL+ [6], anextension of the SQL-like graph query language UnQL [7]with three graph update constructs to achieve efficiency andexpressiveness, namely Replacing, Deleting, and Extending.The model transformation is then desugared to the corealgebra (UnCal) which consists of a set of constructorsfor building graphs and a powerful structural recursion formanipulating graphs. This graph algebra can have clearbidirectional semantics and be efficiently evaluated in abidirectional manner [8]. Graphs (models) in UnQL+ arerooted and edge-labelled (i.e. all information is stored aslabels on edges rather than on nodes and the labels on nodeshave no particular meaning), and represented in UnCAL orthe standard Dot format which can be visualised and editedby the popular Graphviz tool [9].

To illustrate UnQL+, consider a simple graph $db (theroot is the node 1) in Fig. 2. We can select the subgraphpointed by the edge labelled b from the root by

select $g where {b : $g} in $db,

delete the subgraph rooted at node 5 reached by b.a by

delete b.a → in $db,

and insert a subgraph G under the node reached from thepath a.a by

extend a.a → with G in $db.

III. A MOTIVATING EXAMPLE

To illustrate the problem concretely, we use a constructedexample here. Suppose an EMF user initially specifies asimple model that consists of one Entity class with asingle name attribute. Using the code generation featureof EMF, she will obtain a default implementation whichconsists of 8 compilation units in Java (Fig. 3).

⇒

Figure 3. Default code generated from the EMF meta-model

Fig. 4 lists parts of the generated code. The EntityJava interface has getter and setter methods for the nameattribute. They are commented with @generated annota-tions which indicate that the methods are part of the defaultimplementation. Similarly, such @generated annotationsare added to every generated element in the code, e.g., shownin the skeleton of EntityImpl Java class.

The annotation @generated defines a single-trip trace-ability contract from the model to the annotated codeelement. A change in the model or a change in the mod-elling framework can be propagated to the generated code;however, a change in the generated code will not cause achange to the reflected model and will thus be discardedupon next code generation.

Because the default implementation is not always desired,the code generation shall keep user specified changes aslong as they are not inside the range of generated trace-ability, the set of methods marked by @generated thatkeeps the changes of generated templates. This can beachieved by adapting the @generated annotation into@generated NOT, a non-binding traceability that reflectsprogrammers’ intention that it will not be changed whenthe implementation code is regenerated. Note that such non-binding traceability indicated by @generated NOT is stilldifferent from those without any annotation at all: Withoutsuch an annotation, EMF will generate new implementationof a method body following the templates.

This workaround does not work when a user parametrisesthe toString() method to append an additional typeto the returned result. To guard the method from be-ing overwritten by future code generations, the annotation

542

1 package example ;2 import org . e c l i p s e . emf . e c o r e . EObjec t ;3 /∗ ∗ @model ∗ /4 p u b l i c i n t e r f a c e E n t i t y ex tends EObjec t {5 /∗ ∗ @model ∗ / p u b l i c S t r i n g getName ( ) ;6 /∗ ∗ @generated ∗ / void setName ( S t r i n g v a l u e ) ;7 }1 package example . impl ;2 import example . E n t i t y ;3 . . .4 /∗ ∗ @generated ∗ /5 p u b l i c c l a s s E n t i t y I m p l ex tends EObjec t Impl

implements E n t i t y {6 . . .7 /∗ ∗ @generated ∗ /8 p r o t e c t e d S t r i n g name = NAME EDEFAULT;9 . . .

10 /∗ ∗ @generated ∗ /11 p u b l i c S t r i n g getName ( ) { re turn name ; }12 /∗ ∗ @generated ∗ /13 p u b l i c vo id setName ( S t r i n g newName ) { . . . }14 . . .15 /∗ ∗ @generated ∗ /16 @Override17 p u b l i c S t r i n g t o S t r i n g ( ) {18 i f ( e I s P r o x y ( ) ) re turn super . t o S t r i n g ( ) ;19 S t r i n g B u f f e r r e s u l t = new S t r i n g B u f f e r ( super

. t o S t r i n g ( ) ) ;20 r e s u l t . append ( ” ( name : ” ) ;21 r e s u l t . append ( name ) ;22 r e s u l t . append ( ’ ) ’ ) ;23 re turn r e s u l t . t o S t r i n g ( ) ;24 }25 } / / E n t i t y I m p l

Figure 4. Parts of the generated code in Fig. 3

@generated NOT is used. She also applies a RenameMethod refactoring, changing the getName method intogetID. The modified parts are shown in Fig. 5. Propagatingthese changes back to the model, the name attribute willbe renamed into iD automatically, following the namingconvention that attribute identifiers start with a lower casecharacter.

Code regeneration results in the changes in Fig. 6: thesetter methods and the implementations of both getter/settermethods are modified according to the default implementa-tion of the new model. These are expected. However, twounexpected changes are not desirable. First, a compilationerror results from the change in the default implementation,where the attribute name used in the user controlled codeno longer exists. Second, the default implementation ofthe toString() method is generated with the originalsignature, which will of course become dead code since theuser has already modified all call sites of toString()to reflect the insertion of the new type. Similarly, the userspecified toString() method can also become dead code,if it is no longer invoked by the new default implementation.

Compilation errors are relatively easy to spot by theprogrammer with the aid of the Eclipse IDE, but the deadcode problems are more subtle because the IDE will notcomplain. Therefore, it will be more difficult for developersto notice the consequences.

1 /∗ ∗ @model ∗ /2 p u b l i c i n t e r f a c e E n t i t y ex tends EObjec t {3 /∗ ∗ @model ∗ / p u b l i c S t r i n g g e t Name

:ID ( ) ;

4 /∗ ∗ @generated ∗ / p u b l i c vo id setName ( ) ;5 }6 . . .7 /∗ ∗ @generated ∗ /8 p u b l i c c l a s s E n t i t y I m p l ex tends EObjec t Impl

implements E n t i t y {9 /∗ ∗ @generated ∗ /

10 p u b l i c S t r i n g g e t Name::ID ( ) { re turn name ; }

11 . . .12 /∗ ∗ @generated

::::NOT∗ /

13 @Override14 p u b l i c S t r i n g t o S t r i n g (

::::String

:::type ) {

15 i f ( e I s P r o x y ( ) ) re turn super . t o S t r i n g ( ) ;16 S t r i n g B u f f e r r e s u l t = new S t r i n g B u f f e r ( super

. t o S t r i n g ( ) ) ;17 r e s u l t . append ( ” ( name : ” ) ;18 r e s u l t . append ( name ) ;19 r e s u l t . append ( ’ ) ’ ) ;20

:::::::::::::result.append(type);

21 re turn r e s u l t . t o S t r i n g ( ) ;22 }23 } / / E n t i t y I m p l

⇓

Figure 5. User modifications to the generated code: insertions are

:::::::underlined and the deletions are stroked out; the changes are reflected

Ideally, the user should be able to specify which partsof her changes to the code need to be kept rather thanoverwritten by code generation. For this purpose, a newannotation for invariant traceability (@generated INV)will be used in our proposed approach. As a result, Fig. 7illustrates the changes to be propagated to users’ code afterour approach of bidirectional transformations is adopted.

IV. OVERVIEW OF blinkit

The prototype blinkit† supports our idea of main-taining the traceability of the user code and templatecode through bidirectional transformations. Fig. 8 givesan overview of the dataflow of the components insideblinkit. Dashed arrows represent the external changesmade by developers or vertical synchronisations betweenmodels and template code, whilst the open- or close-endedsolid arrows represent forward and backward transforma-tions, respectively. First, developers define an original EMFmodel and synchronise with the template code from the EMFengine ( 1©). Developers may modify the template code intouser code to meet their requirements and mark some partsof their code with the @generated INV annotation ( 2©).Developers can change the model if needed ( 3©) and re-synchronise the code using EMF ( 4©). Note that, withoutblinkit, ( 4©) may lose developers’ modifications.

Having the above steps performed by developers,blinkit will generate a bidirectional transformation in the

†blinkit can be found at http://computing-research.open.ac.uk/linkit/

543

⇒ ⇒

1 /∗ ∗ @model ∗ /2 p u b l i c i n t e r f a c e E n t i t y ex tends EObjec t {3 /∗ ∗ @model ∗ / p u b l i c S t r i n g ge t ID ( ) ;4 /∗ ∗ @generated ∗ / p u b l i c vo id s e t Name

::ID ( ) ;

5 }6 . . .7 /∗ ∗ @generated ∗ /8 p u b l i c c l a s s E n t i t y I m p l ex tends EObjec t Impl

implements E n t i t y {9 /∗ ∗ @generated ∗ /

10 p u b l i c S t r i n g ge t ID ( ) { re turn name::iD ; }

11 . . .12

::::::::::/**@generated*/

13::::public

::::String

:::::::toString()

::{

14:if::::::::(eIsProxy())

:::::return

:::::::::::super.toString();

15::::::::StringBuffer

::::result

:=::::

new::::::::::::::::::::StringBuffer(super.toString());

16::::::::::result.append(”

:::(iD:

::”);

17::::::::::::result.append(iD);

18::::::::::::result.append(’)’);

19::::return

:::::::::::result.toString();

20:}

21 /∗ ∗ @generated NOT ∗ /22 p u b l i c S t r i n g t o S t r i n g ( S t r i n g t y p e ) {23 i f ( e I s P r o x y ( ) ) re turn super . t o S t r i n g ( ) ;24 S t r i n g B u f f e r r e s u l t = new S t r i n g B u f f e r ( super

. t o S t r i n g ( ) ) ;25 r e s u l t . append ( ” ( name : ” ) ;26 r e s u l t . append ( name ) ;27 r e s u l t . append ( ’ ) ’ ) ;28 r e s u l t . append ( t y p e ) ;29 re turn r e s u l t . t o S t r i n g ( ) ;30 }31 } / / E n t i t y I m p l

Figure 6. Regenerated code from the model: insertions are:::::::underlined and

the deletions are stroked out, the compilation error is doubly underlined.

UnQL+ language by comparing the user code (denoted byU ′) and the original template code (denoted by T ). The for-ward transformation uses this generated transformation. Werepresent the code by specific graphs and compare the graphsto generate UnQL+ (see Section V-A) to take the modifieduser code (denoted by U ′) as input, which generates anintermediate code that will be the same as the template codeT , such that the trace information stored by the forwardtransformation can be applied to the corresponding backwardtransformation. In the backward transformation, the interme-diate code T and the modified template code (denoted by T ′)are used as inputs and the output is the merged code (denotedby T ′⊕U ′), which not only reflects the changes made to themodel but also conserves the modifications applied by thedevelopers in 2©. The intermediate code is the same as thetemplate code in our approach. We do not substitute it by the

1 /∗ ∗ @model ∗ /2 p u b l i c i n t e r f a c e E n t i t y ex tends EObjec t {3 /∗ ∗ @model ∗ / p u b l i c S t r i n g g e t Name

:ID ( ) ;

4 /∗ ∗ @generated ∗ / p u b l i c vo id setName ( ) ;5 }6 . . .7 /∗ ∗ @generated ∗ /8 p u b l i c c l a s s E n t i t y I m p l ex tends EObjec t Impl

implements E n t i t y {9 /∗ ∗ @generated ∗ /

10 p u b l i c S t r i n g g e t Name::ID ( ) { re turn name ; }

11 . . .12 /∗ ∗ @generated

:::INV∗ /

13 @Override14 p u b l i c S t r i n g t o S t r i n g (

::::String

:::type ) {

15 i f ( e I s P r o x y ( ) ) re turn super . t o S t r i n g ( ) ;16 S t r i n g B u f f e r r e s u l t = new S t r i n g B u f f e r ( super

. t o S t r i n g ( ) ) ;17 r e s u l t . append ( ” ( name : ” ) ;18 r e s u l t . append ( name ) ;19 r e s u l t . append ( ’ ) ’ ) ;20

:::::::::::::result.append(type);

21 re turn r e s u l t . t o S t r i n g ( ) ;22 }23 } / / E n t i t y I m p l

⇓1 /∗ ∗ @model ∗ /2 p u b l i c i n t e r f a c e E n t i t y ex tends EObjec t {3 /∗ ∗ @model ∗ / p u b l i c S t r i n g ge t ID ( ) ;4 /∗ ∗ @generated ∗ / p u b l i c vo id s e t Name

::ID ( ) ;

5 }6 . . .7 /∗ ∗ @generated ∗ /8 p u b l i c c l a s s E n t i t y I m p l ex tends EObjec t Impl

implements E n t i t y {9 /∗ ∗ @generated ∗ /

10 p u b l i c S t r i n g ge t ID ( ) { re turn name::iD ; }

11 . . .12 /∗ ∗ @generated INV ∗ /13 p u b l i c S t r i n g t o S t r i n g ( S t r i n g t y p e ) {14 i f ( e I s P r o x y ( ) ) re turn super . t o S t r i n g ( ) ;15 S t r i n g B u f f e r r e s u l t = new S t r i n g B u f f e r ( super

. t o S t r i n g ( ) ) ;16 r e s u l t . append ( ” ( name

:iD : ” ) ;

17 r e s u l t . append ( name:iD ) ;

18 r e s u l t . append ( ’ ) ’ ) ;19 r e s u l t . append ( t y p e ) ;20 re turn r e s u l t . t o S t r i n g ( ) ;21 }22 } / / E n t i t y I m p l

Figure 7. The use of invariant traceability to propagate changes in thebackward direction resulting in T ′ + U ′.

template code because it separates the forward and backwardtransformation and makes the transformation process clearer.

V. IMPLEMENTATION OF blinkit

We will illustrate the implementation of blinkit by firstexplaining the overall process, then providing details for thecritical steps for correctness and efficiency.

A. The Overall Process

We use GRoundTram‡ to perform bidirectional transfor-mations and to keep the traceability of the template anduser method bodies. GRoundTram adopts input graphs

‡See http://www.biglab.org

544

Original  model  

Template  code  (T)  

1

User-­‐modified  code  (U’)  

2

Modified  model  

Modified  Template  code  (T’)  

UnQL+  transforma=on  €

Merged  Code  (T’        U’)    

Δ  MCT  

GRoundTram  

3

4

External Changes

Forward transf.

Backward transf. Optional Check

Meaningful Diff

Figure 8. The data flows inside blinkit

which are represented in UnCal or Dot format. Thus,in order to perform bidirectional transformations on Javacode generated by EMF through GRoundTram, we firsttranslate Java code into UnCal or Dot (i.e. using UnCalor Dot to represent Java source code). When translating Javacode into UnCal or Dot, we adopt the EMF model as anintermediate representation of Java code since EMF model ismuch more navigable than specific abstract syntax trees andcan be manipulated more easily. After we get the UnCal orDot graphs, we can generate UnQL+ [10] automatically andperform bidirectional transformations using GRoundTram.

To achieve such a round-trip process, our frameworkinvolves four engineering steps on either side of the for-ward/backward directions to support the code↔code hori-zontal synchronisation between the evolving template anduser code (see Fig. 9). Without loss of generality, in the fol-lowing we denote the template-generated and user-modifiedcodes as T and U ′, the modified template codes as T ′, andthe merged code as T ′ ⊕ U ′, respectively.

1) Given that Java codes T, T ′ were generated and syn-chronised from the model using EMF’s built-in verti-cal synchronisation with user’s Java codes U ′ exceptfor those methods that are marked by @generatedINV, we first parse all the @generated INV meth-ods in T, T ′, U ′ using the JaMoPP parser on topof the EMFtext framework §. The differences be-tween T and U ′ are obtained using the API ofthe EMFcompare framework ¶ after the meaningfuldifferences were preprocessed using mct‖. Here thedifferences are a comprehensive representation of coderather than editing operations;

2) The EMF models of T, T ′, U ′ are translated into ourspecific UnCal graphs using Ecore’s reflection API,and as a by-product, an UnQL+ transformation isgenerated from the meaningful differences between Tand U ′ using the algorithm in Fig. 10;

§See http://www.jamopp.org¶See http://www.eclipse.org/emf/compare‖See http://computing-research.open.ac.uk/mct [3]

3) The UnCal graphs of T, T ′, U ′ are transformed intoDot graphs by GRoundTram, which preserves thepaths from the graph root to any node on the UnCalgraphs in the equivalent Dot graphs;

4) Using the generated UnQL+ transformation and theDot graphs of U ′ as inputs, the GRoundTram systemalso performs a forward transformation to output agroup of Dot graphs that represent T , guaranteed bythe one-pass optimisation described in Section V-C;

5) Backwards, using the same UnQL+ transformation onthe Dot graphs of the modified template code T ′,and the internal graph traceability between T and U ′

kept by the forward transformations that performs abackward transformation to output the Dot graphs thatrepresent the merged user code, denoted by T ′ ⊕ U ′;

6) Path-equivalent Uncal graphs corresponding to T ′⊕U ′; are re-generated from the resulting Dot graphs;

7) An equivalent EMF model of those Uncal graphsfor T ′ ⊕ U ′ is obtained using an Xtext parser ∗∗ ofUncal to process its abstract syntax using EMF API;

8) Finally, the merged Java code T ′⊕U ′ is obtained fromthe EMF model using JaMoPP’s pretty-print function.

Since we have a TXL-based parser to generate Dotgraphs [3], our presented technique is not limited to EMFbased external representations of Java. As long as a codegeneration framework for vertical synchronisation is avail-able, it will be possible to adapt our horizontal synchornisa-tion framework. However, we do not intend to implement thevertical synchonisation baseline because it will be complexto maintain one-to-many traceability links invariant.

To apply our approach effectively, one can initially at-tach INV to all @generated Java methods as a trivialidentity bi-transformation. Once an inconsistency warning israised, the marker can be modified to either @generatedor @generated NOT incrementally, in order to preservetemplate- or user-modified changes respectively. Users in-troducing @generated INV are currently responsible forresolving the warnings.

Figure 9. The multi-tier architecture of blinkit

B. Generating Correct UnQL+ Transformations

To enable the use of UnQL+ on MDD, we need tomake sure that translating the artifacts between the code,the UnCal graphs and node-traced graphs such as Graphviz

∗∗See http://www.eclipse.org/Xtext

545

Dot does not lose information. This can be done in a multi-tier fashion [11], and one critical step is to guarantee thecorrectness of the horizontal (code↔code) synchronisation,that is to generate a correct UnQL+ bidirectional transfor-mation from the meaningful differences between the originaltemplate code and the modified user code.

1: function UNQLGENERATOR(dotUser, dotTemplate)2: rootUser ← the root node of dotUser

3: rootTemplate← the root node of dotTemplate

4: MatchingDot(rootUser, rootTemplate)5: end function6: function MATCHINGDOT(nodeUser, nodeTemplate)7: edgeSetUser ← outgoing edges of nodeUser

8: edgeSetTemplate← outgoing edges of nodeTemplate

9: for all edgeUser ∈ edgeSetUser do10: flag = false11: childNodeUser ← target node of edgeUser

12: for all edgeTemplate ∈ edgeSetTemplate do13: if edgeUser = edgeTemplate then14: flag = true15: childNodeTemplate←16: the target node of edgeTemplate

17: MatchingDot(childNodeUser, childNodeTemplate)18: end if19: end for20: if flag = false then21: DeleteConstructor(childNodeUser)22: end if23: end for24: for all edgeTemplate ∈ edgeSetTemplate do25: flag = false26: childNodeTemplate← target node of edgeTemplate

27: for all edgeUser ∈ edgeSetUser do28: if edgeTemplate = edgeUser then29: flag = true30: end if31: end for32: if flag = false then33: ExtendConstructor(childNodeTemplate)34: end if35: end for36: end function

Figure 10. Procedure of generating UnQL+

We can then use the Dot graphs as inputs to performbidirectional transformations: GRoundTram needs to usebidirectional transformations specified in the UnQL+ graphtransformation language. As we said in Section IV, UnQL+is used in forward transformations to convert user code intointermediate code which is the same as template code. Weimplemented an algorithm shown in Fig. 10 to generatethe UnQL+ transformation automatically in order to reducedevelopers’ burden. After representing the Java code that wewant to synchronise using Dot graphs, we can compute the

differences between the Dot graphs and such differencescan be used to generate UnQL+ automatically.

The UnQL+ generated by our approach only containsDeleting and Extending operations. Replacing operationscan be replaced by a Deleting and an Extending operation.The UnQLGenerator algorithm starts node matching fromthe root in the Dot graphs. For each node pair, we comparetheir outgoing edges’ labels. If we find one edge whichexists in the user’s graph but does not exist in the template’sgraph, that means deletion occurs and we will generate aDeleting operation to delete the subgraph beneath the nodeunder comparison (Lines 20-22 in Fig. 10); if the two edgeshave the same labels, we will do node matching for theirchildren recursively (Lines 13-18). Similarly, for those edgesthat the template’s graph has but the user’s graph does not,we need an Extending operation (Lines 32-34). For theExtending operation, we have to record the subgraph thatneeds to be inserted. To generate UnQL+ transformations,path information composed by edge labels is needed in orderto denote which part should be deleted or inserted. Since thelabels on the outgoing edges of one node are different fromeach other in our Dot graphs, such paths which reflect thechanges between two Dot graphs are unique. We have toobtain such paths to generate UnQL+ transformations andthe uniqueness of the paths guarantees the correctness of ourUnQL+ generated algorithm (i.e. if there are two outgoingedges of a node with the same label, this algorithm may notgenerate the desired UnQL+ transformation).

An example is shown to illustrate this algorithm (Fig. 11).We transform the graph shown in Fig. 11(a) into the one inFig. 11(d). We have to delete the edge e, g and subgraph2, and insert the edge h and subgraph 4. The algorithmfirst generates Deleting operations which could transformFig. 11(a) into Fig. 11(b). Note that the Deleting operationscontain the deletion of subgraph 3 and edge f though theyshould not be deleted. This is because when the algorithmdeletes the edge g, it will also delete its pointed subgraphs(subgraph 3) and the edges connected to those subgraphs(edge f ). Then when generating the Extending operation,the algorithm not only inserts the edge h and subgraph 4,but also inserts the edge f and subgraph 3 again. This extradeletion and insertion may reduce the transformation’s effi-ciency and more efficient algorithms should be explored inthe future work. Comparison algorithms for trees and graphsbased on dynamic programming [12] may be adopted.

C. Derivation of a One-Pass Transformation

The automatically generated UnQL+ transformations arenot optimal. One performance bottleneck is that there aretypically multiple pairs of different elements, leading to mul-tiple basic editing operations composed sequentially. Ideally,these operations should be composed in parallel as onesingle graph transformation such that GRoundTram couldobtain results in one pass of traversing the graph structure. In

546

1

2 3

S u b g r a p h 1

4

a b c

d e f g

1

2 3

S u b g r a p h 2

4

S u b g r a p h 3

a b c

d e f g

1

2 3 4

S u b g r a p h 3

a b

c

d f

h

1

2 3 4

a b c

d f

h

( a ) ( b )

( c ) ( d )

D e l e t i n g

E x t e n d i n g

S u b g r a p h 2 S u b g r a p h 3 S u b g r a p h 1

S u b g r a p h 1 S u b g r a p h 4 S u b g r a p h 1 S u b g r a p h 3 S u b g r a p h 1

Figure 11. An example to illustrate the algortihm in Fig. 10

theory, the composition of general UnQL+ transformationshas to be sequential. However, the transformations we ob-tained from the diff results have nice properties that make itpossible to compose the basic operations in parallel withoutintroducing any side effect. The rationale is given below.

Let e1, e2, . . . , en be a sequence of the editing operationsobtained above, where any two editing operations, ei andej , are independent in the sense that neither insertion nordeletion is done on a previously inserted/deleted part. Thiscan be formalised as ∀i, j : ei ◦ ej = ej ◦ ei holds.

We show that any editing sequence can be automaticallytransformed to a one-pass traversal of graphs. Our algorithmconsists of two steps: We first map the editing sequence toa composition of a set of graph transformations where eachgraph transformation corresponds to an editing operation,and then try to fuse the composition into a single one-passgraph traversal in terms of a structural recursion in UnCal.

1) Mapping from Editing Sequence to Composition ofGraph Transformations: First, each editing operation cor-responds to a simple graph transformation in UnQL+. Let pdenote the path from the root to the node n (i.e., a sequenceof edge labels from the root to the node n) in the graph $db.Then, the editing operation e($db) for deleting a subgraph{l : $g} rooted at the node n can be translated to E($db):

delete p→ {l : $g} in $db

and the edition operation e′($db) for inserting a subgraphG to the node n to E′($db):

extend p→ $g with G in $db.

Now a sequence of editing operations e1, e2, . . . , en cor-responds to the composition of graph transformations ofE1($db), E2($db), . . . , En($db), that is,

E1(E2(. . . (En($db))).

2) Fusion of Composition of Graph Transformations:GRoundTram provides a powerful fusion mechanism thatcan automatically fuse a composition of graph transfor-mations into one so that unnecessary exchange of graphstructures between the individual graph transformations canbe saved. We could apply this general fusion mechanism,

but we can do better based on the fact that each graphtransformation is independent from each other. Thus wedevelop a specialised but more efficient fusion algorithm.

Our idea is to construct an action tree from the editingsequence and then map the action tree to a one-pass trans-formation. For an action tree, leaves are marked with twoaction markers D(l) and I(G), denoting respectively thedeletion of a graph pointed by the edge l when possibleand the insertion of a graph G. Fig. 12 gives an example

Figure 12. An action tree

action tree, which describes the intention of that composedtransformation: Given a graph, for the node reached by thepath of a.b do deletion, for the node reached by the pathb.a do deletion, and for the node reached by the path b.c doinsertion. In fact, an action tree is a tree automaton that canbe mapped to a structural recursion in UnCal that traversesgraphs only once [7].

Let us show that a sequence of editing operations can berepresented by an action tree. First, it is clear that a singleediting operation can be represented by a simple actiontree (which is actually a tree where each node has just asingle child). Now given two action trees t1 and t2, wecan combine them to merge(t1, t2), satisfying that (1) anyaction in t1 or t2 appears in merge(t1, t2) and any action inmerge(t1, t2) appears in t1 or t2 and (2) there is no node thathas two outgoing edges with the same labels. The algorithmmerge(t1, t2) is defined as follows:

merge((), t2) = t2merge(t1, ()) = t1merge(t1 ∪ t′1, t2) = merge(t1,merge(t′1, t2))merge({l : t1}, {l : t′2} ∪ t2) = {l : merge(t1, t

′2)} ∪ t2

merge({l : t1}, t2) = {l : t1} ∪ t2

With this merge operation, we can merge all editing opera-tions into an action tree.

VI. EVALUATION

In order to evaluate the benefits of the framework, weassess two research questions. First, does blinkit workcorrectly on the examples without human intervention?Second, given that the illustrative example is constructed,are there realistic cases in an open-source MDD softwaredevelopment project where invariant traceability links can besynchronised using blinkit? The first question needs tobe answered first since only a working blinkit prototypecan bring benefits to the users. To answer these questions,we conducted two sets of experiments:

547

Correctness. In the 1st experiment we create a modelusing EMF as illustrated earlier and generate the default Javasource code. There is only 1 class (i.e., Entity) and 1 attribute(i.e., name) respectively in the EMF meta-model, the codegenerated by EMF has 2 classes (i.e., Entity, EntityPackage)and 1 attribute (i.e., name) annotated by @model. In termsof the number of @generated attributes, there are respec-tively 8 classes, 48 attributes and 10 methods generated in3 packages. Currently, blinkit only supports synchroni-sation between method bodies, which users are more likelyto change in order to introduce different behaviours.

To evaluate the correctness of blinkit, we manuallymodified those 9 methods annotated by @generatedinto @generated INV. The blinkit tool generated an‘identity’ UnQL+ transformation for each invariant traceabil-ity @generated INV. Then we manually modified indi-vidual @generated INV methods by adding, removing,and replacing some statements to simulate a possible changeby the user. In parallel, we applied the Rename Class andthe Rename Method refactorings to the 3 elements in themodel that were annotated by the @model markers to seewhether they have an impact on the user-modified code.

The simulated changes to the newly generated templatecode may conflict with the changes introduced by the user,e.g., by renaming “name” to “iD”. In those cases thechanges should be merged by blinkit. For correctness,we checked the merged results manually to see whetherthey preserve both changes in the model and in the usercode. When the changes of the @model did not affect thechanges to the @generated INV elements by the user,all changes introduced by the user were preserved.

Intersection of the changes in @generated NOT,@generated and @model. To answer the second ques-tion, we first extracted all revisions of Java code fromthe CVS repository of the GMF project††, which spansabout 6 years period between 2005/08/14 and 2011/08/13.According to this repository, there have been 28,070 revi-sions including all the ones before the deleted files wereplaced in the Attic subfolders. In order to understandhow many times the model parts have changed, we relyon the EMF convention that all modelling elements inthe generated template code have been annotated with the@model markers. Therefore, we extracted the interface APIsthat were marked by @model using the normalisation andclone detection technique reported in our earlier work [3].This way, all meaningful differences for the model can befound among the 1185 pairs of possible revisions (we onlycompare those revisions on the same files). There are 178pairs of meaningful changes, ranging from 2005/08/14 till2011/02/28, and no more changes after that. Fig. 13 showsthe distribution of the 178 @model changes over this period.

††See http://archive.eclipse.org

Figure 13. The distribution of @model changes in the CVS repositoryindicates that meta-models used in the GMF project is stabilising.

Next, we used a different normalisation on the same data-set, this time filtering only those methods that have beenannotated by @generated NOT markers amongst 1,314Java classes. For these Java methods, we moved their im-plementation in the body into the <!-begin-user-doc>... <!--end-user-doc> pairs in the Javadoc com-ments, and changed their annotations into @generatedsuch that the code generator will overwrite the user codewith the template code, while the user modifications arestill available in the comment. Finally, we compared thedifferences between the template and user codes, in orderto see whether the changed @model elements appear inthese method bodies. If they do, then we have confirmedthat the bidirectional transformation could be useful inpractice because the user code was indeed different fromthe template code, and those differences would interact withthe modification of the model in the immediate revisionsfollowing the timestamps.

Throughout the data-set, we found that 15,223 revisionsamongst the total of 28,070 revisions (i.e., 54%) will beinfluenced by the changes of the @model elements. Thereare 146,415 modified model elements referenced by the@generated NOT methods in the revisions. Therefore,on average 146, 415/15, 223 = 9.61 modified modellingelements are referenced by the @generated NOT methodbodies in every Java revision file.

We list threats to validity and some limitations below:Construct validity: Instead of synchronising changes for

the whole classes or packages, we focus on synchronisingchanges to the method bodies. The reason for this choiceis practical as most of the time users would customise thebehaviour of the default class, rather than rewriting themcompletely. A modification to method bodies is also oftenrequired because the template code would otherwise raiseUnsupportedOperationException.

External validity: blinkit is built on existing open-source MDD toolsets EMF, EMFtext, JaMoPP and atransformation system TXL. It also integrates two researchprototypes GRoundTram [5] and mct [3] which are freelyavailable to download. The subject case study is also anopen-source one whose CVS repository is publicly available.

Internal validity: Although studying committed changeson models in the GMF repository may be conservative, it

548

is the only available source that we can rely on. It can beargued that the editing changes outside the repository presentmore synchronisation opportunities, however we have toestimate the benefits of our solution conservatively withoutempirically monitoring developers over their shoulders.

VII. RELATED WORK

Precise traceability. Automated software document-codetraceability recovery has been studied by researchersfrom many angles since requirements traceability wasproposed [2]: The review of the best practises in thisfield [13] suggests that automated techniques such as vectorspaces [14], [15], LSI [16] are useful when part of the data-set relies on ambiguous documentation such as requirements,manuals and bug reports. It is expensive to obtain expertjudgements for large applications [17] and to obtain high-quality inputs [18]. Incremental techniques have been pro-posed to analyse evolving traceability links [16] for betterefficiency, however, precision cannot be greatly improved.Auxiliary information from programs such as call-graphs ortraces [18] or XML-based (xlinkit) rules [19] could helpimprove the precision to some extent, but it is still largely ex-pensive to gain better results through feedback [20]. On theother hand, the abstraction gap between models and code ismuch narrower that that between requirements document andcode, thus precise tracing has been considered through main-taining semi-automated refactorings [21]. However, suchrefactorings are also expensive to construct, thus affordableonly for medium-sized security software applications. Herewe address the problem for general software projects thatscales while MDD has been applied.

Invariant traceability for model/code co-evolution.When projects evolve, MDD methods face additional chal-lenges: not only do artifacts such as models or code changeover time, their changes also need to be propagated inorder to maintain consistency even when artifacts are atdifferent levels of abstraction. Co-evolution needs to bestudied between models and code, between behaviouraland structural models, or even between code and program-ming languages [22]. Modifications to a model must bereflected on the corresponding code in order to keep themodel and the code synchronised. Code generators existto automatically generate code from UML models [23]–[25]. In practice, however, code is often updated manuallyafter it has been generated, and it is therefore necessaryto reflect those changes back to the corresponding model.Round-trip engineering (RTE) is one way to synchroniseUML diagrams and code [26]. However, combining codegeneration and reverse engineering approaches is still notsufficient: Changing independently, models and code needto be merged first; Secondly, since models are generallyat a higher level of abstraction than code, not all changesmade to the code can be reflected back to models. Giese andWagner [27] use triple graph grammars for RTE, but their

approach is limited to elements that have a correspondencein the model. Other approaches, like Van Paesschen et al.’s[28], assume that both artifacts can be represented in acommon representation. Fujaba [29] is yet another RTEapproach that can generate Java code from UML classdiagrams, and regenerated class diagrams from modifiedJava code, as long as developers follow Fujaba’s namingconventions and implementation concepts. State-of-the-artRTE tools such as EMF/GMF make use of annotations toseparate the portions of generated and user modified code,yet it is largely manual to maintain the correspondence of@generated NOT elements. The co-evolution of GMFproject has been studied [30] for synchronising the EMFmeta-models (model↔model) used by the project. Althoughwe also use the same case study to evaluate the benefits, ourfocus is on automating the code↔code synchronisations.

Studied by broad communities of programming language,software engineering, and database, bidirectional transfor-mations [31], [32] are potentially applicable to softwaredevelopment, including model synchronisation [4], [33],round-trip engineering [34], software evolution [35], andmultiple-view software development [36]. To make thempractical and scalable, we propose a two-layer bidirectionaltransformation framework that hides difficulties in writingbidirectional transformations by deriving it automaticallyfrom a sequence of editing operations, and by widening theapplicability by treating general graphs.

VIII. CONCLUSIONS AND FUTURE WORK

In this paper, we presented a model-driven developmentmethod, supported by the blinkit prototype, to maintainthe traceability between model and code invariant by gener-ating a bidirectional transformation for each method anno-tated by @generated INV. We tested the framework withthe example shown in Section III and observed empiricallyhow often blinkit can be used to maintain the invarianttraceability based on the data-set of the CVS repository ofGMF: we observed that applying the method earlier coulddeliver more benefit since its meta-models change morefrequently; we also found that more changes were derivedfrom the evolving model than from the evolving template.

Current work considers a basic form of invariant trace-ability where all meaningful changes are synchronised, re-gardless of whether they were derived from the templateor from the model. Our future work will extend the syntaxand semantics of @generated INV to differentiate modelchanges from template changes.

ACKNOWLEDGEMENT

The work is supported in part by EU Se-cureChange (http://www.securechange.eu), MicrosoftSEIF (http://sead1.open.ac.uk/seif), and NII BiG(http://www.biglab.org) projects. We also thank ourcolleagues Michael Jackson and Thein Than Tun for earlierdiscussions about the @generated NOT problem.

549

REFERENCES

[1] L. Angyal, L. Lengyel, and H. Charaf, “A SynchronizingTechnique for Syntactic Model-Code Round-Trip Engineer-ing,” in ECBS ’08, 2008. pp. 463–472.

[2] O. C. Z. Gotel and A. C. W. Finkelstein, “An analysis ofthe requirements traceability problem,” in RE’94, 1994, pp.94–101.

[3] Y. Yu, T. T. Tun, and B. Nuseibeh, “Specifying and detectingmeaningful changes in programs,” in ASE’11, 2011, pp. 273-282.

[4] Y. Xiong, D. Liu, Z. Hu, H. Zhao, M. Takeichi, and H. Mei,“Towards automatic model synchronization from model trans-formations,” in ASE’07, 2007, pp. 164–173.

[5] S. Hidaka, Z. Hu, K. Inaba, H. Kato, and K. Nakano,“GRoundTram: An integrated framework for developing well-behaved bidirectional model transformations” in ASE’11,2011, pp. 480-483.

[6] S. Hidaka, Z. Hu, H. Kato, and K. Nakano, “Towards acompositional approach to model transformation for softwaredevelopment,” in SAC ’09, 2009, pp. 468–475.

[7] P. Buneman, M. F. Fernandez, and D. Suciu, “UnQL: aquery language and algebra for semistructured data based onstructural recursion,” VLDB Journal: Very Large Data Bases,vol. 9, no. 1, pp. 76–110, 2000.

[8] S. Hidaka, Z. Hu, K. Inaba, H. Kato, K. Matsuda, andK. Nakano, “Bidirectionalizing graph transformations,” inICFP’10, 2010, pp. 205–216.

[9] J. Ellson, E. R. Gansner, E. Koutsofios, S. C. North, andG. Woodhull, “Graphviz and dynagraph - static and dynamicgraph drawing tools,” in Graph Drawing Software. Springer-Verlag, 2003, pp. 127–148.

[10] P. Buneman, M. Fernandez, and D. Suciu, “UnQL: a querylanguage and algebra for semistructured data based on struc-tural recursion,” VLDB J., vol. 9, no. 1, pp. 76–110, 2000.

[11] Y. Yu, Y. Lin, Z. Hu, S. Hidaka, H. Kato, and L. Mon-trieux, “blinkit: Maintaining invariant traceability throughbidirectional transformations – a technical report,” The OpenUniversity, Tech. Rep. TR2011/09, September 2011.

[12] W. Yang, “Identifying syntactic differences between twoprograms,” in Software - Practice and Experience, vol. 21,1991, pp. 739–755.

[13] J. Cleland-Huang, B. Berenbach, S. Clark, R. Settimi, andE. Romanova, “Best practices for automated traceability,”IEEE Computer, vol. 40, no. 6, pp. 27–35, 2007.

[14] J. H. Hayes, A. Dekhtyar, and S. K. Sundaram, “Advancingcandidate link generation for requirements tracing: The studyof methods,” IEEE Trans. Software Eng., vol. 32, no. 1, pp.4–19, 2006.

[15] G. Antoniol, G. Canfora, G. Casazza, A. D. Lucia, andE. Merlo, “Recovering traceability links between code anddocumentation,” IEEE Trans. Software Eng., vol. 28, no. 10,pp. 970–983, 2002.

[16] H. Jiang, T. N. Nguyen, I.-X. Chen, H. Jaygarl, and C. K.Chang, “Incremental latent semantic indexing for automatictraceability link evolution management,” in ASE’08, 2008, pp.59–68.

[17] G. Antoniol, J. H. Hayes, Y.-G. Gueheneuc, and M. D. Penta,“Reuse or rewrite: Combining textual, static, and dynamicanalyses to assess the cost of keeping a system up-to-date,”in ICSM’08, 2008, pp. 147–156.

[18] A. Egyed and P. Grunbacher, “Supporting software under-standing with automated requirements traceability,” Inter-national Journal of Software Engineering and KnowledgeEngineering, vol. 15, no. 5, pp. 783–810, 2005.

[19] C. Nentwich, L. Capra, W. Emmerich, and A. Finkelstein,“xlinkit: a consistency checking and smart link generationservice,” ACM Trans. Internet Techn., vol. 2, no. 2, pp. 151–185, 2002.

[20] A. D. Lucia, F. Fasano, R. Oliveto, and G. Tortora, “Recover-ing traceability links in software artifact management systemsusing information retrieval methods,” ACM Trans. Softw. Eng.Methodol., vol. 16, no. 4, 2007.

[21] Y. Yu, J. Jurjens, and J. Mylopoulos, “Traceability for themaintenance of secure software,” in ICSM’08, 2008, pp. 297–306.

[22] T. Mens, M. Wermelinger, S. Ducasse, S. Demeyer,R. Hirschfeld, and M. Jazayeri, “Challenges in softwareevolution,” in IWPSE ’05, 2005, pp. 13–22.

[23] A. Rountev, O. Volgin, and M. Reddoch, “Static control-flowanalysis for reverse engineering of uml sequence diagrams,”in PASTE ’05, 2005, pp. 96–102.

[24] M. Keschenau, “Reverse engineering of UML specificationsfrom Java programs,” in OOPSLA’04, 2004, pp. 326–327.

[25] Y.-G. Gueheneuc, “A reverse engineering tool for preciseclass diagrams,” in CASCON ’04, 2004, pp. 28–41.

[26] T. Hettel, M. Lawley, and K. Raymond, “Model synchro-nisation: Definitions for round-trip engineering,” in Theoryand Practice of Model Transformations, ser. Lecture Notesin Computer Science. 2008, vol. 5063, pp. 31–45.

[27] H. Giese and R. Wagner, “Incremental model synchronizationwith triple graph grammars,” in Model Driven EngineeringLanguages and Systems, ser. Lecture Notes in ComputerScience. 2006, vol. 4199, pp. 543–557.

[28] E. Van Paesschen, W. De Meuter, and M. D’Hondt, “Self-Sync: A dynamic round-trip engineering environment,” inModel Driven Engineering Languages and Systems, ser. Lec-ture Notes in Computer Science. 2005, vol. 3713, pp. 633–647.

[29] T. Klein, U. A. Nickel, J. Niere, and A. Zundorf, “From UMLto Java and back again,” University of Paderborn, Tech. Rep.,1999.

[30] D. D. Ruscio, R. Lammel, and A. Pierantonio, “Automatedco-evolution of GMF editor models,” in SLE, ser. LectureNotes in Computer Science, vol. 6563, 2010, pp. 143–162.

[31] K. Czarnecki, J. N. Foster, Z. Hu, R. Lammel, A. Schurr,and J. F. Terwilliger, “Bidirectional transformations: A cross-discipline perspective,” in ICMT’09, 2009, pp. 260–283.

[32] Z. Hu, A. Schurr, P. Stevens, and J. F. Terwilliger, “Dagstuhlseminar on bidirectional transformations (BX),” SIGMODRecord, vol. 40, no. 1, pp. 35–39, 2011.

[33] M. Antkiewicz and K. Czarnecki, “Design space of hetero-geneous synchronization,” in GTTSE ’07, 2007, pp. 3-46.

[34] Michal Antkiewicz and Krzysztof Czarnecki, “Framework-specific modeling languages with round-trip engineering,” inMoDELS’06, 2006, pp. 692–706.

[35] R. Lammel, “Coupled Software Transformations (ExtendedAbstract),” in IWSET’04, 2004, pp. 31-35.

[36] M. Garcia, “Bidirectional synchronization of multiple viewsof software models,” in DSML’08, vol. 324, 2008, pp. 7–19.

550