Round-Trip-Engineering

An important practical aspect to be discussed in context of transformations is the so-calledRound-Trip

Engineering[Sendall and Küster04, Hettel et al.08]. Round-Trip Engineering means that a source

model and code generated from the model are kept synchronous. If changes are made in the code which affect the model, then the model is synchronized and vise-versa. In context of transformation between models, Round-Trip Engineering is also calledModel Synchronization.4

General Concepts It is important to understand that Round-Trip Engineering isnot equivalent to the sum of Forward Engineering (i.e. code generation) and Reverse Engineering.Reverse Engineering

[Tonella and Potrich04] usually means to (re-)construct a model from some given code, or more gen- erally, to derive an abstract model from a more concrete model. However, in Round-Trip Engineering the original source model should only be changed to that extent as necessary for synchronization – it is not useful to construct via Reverse Engineering a completely new source model which reflects the code but has nothing in common with the model specified originally by the modeler.

The basic steps in Round-Trip Engineering are [Sendall and Küster04]: 1. Deciding whether a model under consideration has been changed,

2. Deciding whether the changes cause any inconsistencies with the other models, and

3. Once inconsistencies have been detected, updating the other models so that they become con- sistent again.

4

In context of Model Driven Engineering code is treated as a specific kind of model as well – in the following the term “target model” refers to any kind of transformation result including code.

A change means that an element is either added, modified, or deleted. To synchronize models it is necessary to keep additional trace information, i.e. information to trace an element in the target model back to its causing element in the source model (see examples in [Sendall and Küster04]). In addition, it must be ensured that information added manually is not overwritten when synchronizing the models. These two requirements correspond to the postulated properties of model transformations from section 3.4.2:traceabilityandincremental consistency.

Incremental consistency on source code can be achieved by using a merge mechanisms as provided e.g. byJMerge[JMe] which is part of the EMF. Ideally, a tool does not only preserve the custom code but also updates the custom code when e.g. names of properties or operations have changed (using e.g. refactoring functionality like provided by the Eclipse Java Development Tools [JDT]).

For keeping trace information two common ways exist: Either augment the target model with the additional information, for instance comments in code containing specific tags, or store the trace information externally, for instance in an additional model.

Several tool support already exists like SyncATL [Xiong et al.07, Syn], a synchronization tool based on Eclipse supporting ATL. An important concept in this tool is to work on the modifications performed by the user on a model since the last transformation. Thus, it requires as input the 1) original source model, 2) the modified source model, 3) the modified target model, and 4) the transformation (the original target model can just be calculated from the original source model and the transforma- tion). The tool requires that each model element is always annotated with a unique identifier which can not be changed by the user. The synchronization process first calculates the modifications between original model and its modified version for both, source and target model. This calculation uses the IDs to distinguish whether e.g. a model element has been added or renamed. As result of the calcu- lation, an annotation is added to each element and property in the model to indicate the modification by one of this four tags: insert,delete,replace, ornone. The modifications on the target model are propagated back to the source model and merged with the modifications on the source model. The modifications in the resulting source model are then propagated to the target model and finally merged with the modified target model. In that way, both models are synchronized while preserving all modi- fication made by users on the source and the target model. For details, like merging rules, see [Xiong et al.07]. Basic concepts for differencing and merging models can also be found in various other work like [Abi-Antoun et al.08, Mehra et al.05].

Another important tool is theAtlas Model Weaver(AMW, [AMW]) based on Eclipse and ATL as

well. Its purpose is more general: AMW establishes links between two models and stores them in a so- calledWeaving Model. On that base various different use cases are available for download including support for traceability relationships between models and calculating the differences between two models.

Even with complete trace information there are still various cases where this information is not sufficient to synchronize the models. For instance, if an element is added to the target model, multiple alternative possibilities where to add corresponding elements in the source model may occur. Such cases can be solved for instance by rules for default behavior or by additional user input. More information on advanced issues can be found e.g. at [Oldevik et al.08].

Round-Trip Engineering for MML Basically, the general principles of Round-Trip Engineering can also be applied to MML. In particular, the ActionScript classes can be treated like any other kind of source code. But two specific problems must be considered: First, most existing solutions require annotations on the model and code. Thus, it must be ensured that it is possible to annotate elements in Flash Documents with custom data. Second, parts of the MML models reside on a quite high level

of abstraction compared to the generated Flash implementation. Thus, it must be discussed for which kind of modifications it is useful to propagate them back to the MML model. They are discussed in the following.

ActionScript classes can be handled like conventional source code and be annotated with com- ments. Annotations are important for Round-Trip Engineering, for instance to store trace information or for unique IDs to calculate modifications between models like in SyncATL (see above).

Fortunately, the Flash Java Script API enables to store additional information to the most important elements used in our structure: Data of any kind of primitive types can be added, read, and removed to

Flash Documents (methoddocument.addDataToDocument()), to all Library Items (item.addData()),

and some types of Elements on the Stage including MovieClip instances and Component instances

(element.setPersistentData(), see figure 7.6 for metaclass Element). These elements cover already

the major part of the generated structure as elements on the Stage are encapsulated into MovieClips (see “MML to Flash Model” on page 158).

Annotating the Flash elements with unique identifiers can help to ensure incremental consistency for Flash Documents. The basic idea is to calculate modifications on the Flash model. The JSFL file then propagates only these modifications to the Flash Documents. For instance, when a MovieClip is renamed in the model, the JSFL file searches for the MovieClip by its identifier and modifies its propertynamewhile leaving all other properties and content unchanged.

The second problem is the partially high level of abstraction. Thus, for some parts of the MML models it is not trivial to synchronize a MML models when changes appeared in the generated code. A general requirement is that modifications in the Flash application must comply to the generated structure for Flash applications. If a developer adds an element which does not fit to the intended structure at all, it is almost impossible to interpret its meaning in terms of the MML model.

The main MML elements can be handled as follows:

• MML Domain Classes are mapped 1:1 into ActionScript classes in the folder model. All

changes can be directly propagated to the MML Structure diagram just like in mappings from UML class diagrams to Java.

• An MML Scene is mapped to a large number of elements and code. Thus, even modifications

like renaming can become tedious in the code. It is often better to add new Scenes only in the model and re-generate the code. Modifying conventional class properties or class operations of the Scene’s ActionScript class is unproblematic and can be directly propagated to the MML model.

• Each AIO in MML is mapped to a MovieClip in the Scene and a listener class. Basically, it

should be possible to add, modify, or delete these MovieClips directly in Flash. The changes can be propagated to the model. The corresponding listener classes could then just be updated when re-generating code. However, it must be considered that adornments on the user interface should not be interpreted as AIOs in MML. A useful solution is that only MovieClips instances on the Stage having an instance name are interpreted as AIOs (in Flash, instances have no instance name by default) while all other elements are interpreted as adornments.

• MML Media Components are directly mapped into the foldermedia. Adding, deleting or re-

naming a Media Component directly in the foldermediais possible and can be propagated back to the model. However, the developer has to consider Media Instances which refer to this Media Component. Advanced modifications, concerning inner structure or different variations, are not propagated back to the model.

Of course, when the developer fills out generated placeholders or operation bodies, this has not to be propagated back to the model as specifying their content is not part of MML models.