Concrete syntax models are synthetic views on information structured according to a meta model and allow tailoring information representation to various needs. Synchronization approaches must keep overlapping information consistent and must retain unmapped information such as positioning of graphical elements. De ning a bidirectional and incremental transformation between these models is one possible solution. Selecting a transformation language and tooling is, however, di cult, because there is no universal solution. Therefore, we compare two opposing approaches: complementing QVT-O with coupled unidirectional transformations including trace transformations and Henshin-TGG with additional support for reusable nodes. We achieved bidirectional, incremental, and fully automated transformations between textual and graphical concrete syntax models of UML diagrams with both approaches. We compare them for our use case, as well as discuss and rate restrictions. Our ndings regarding the e ort in writing and maintaining transformations indicate a need for further research and tool support.
Copyright c by the paper's authors. Copying permitted for private and academic purposes. : Model name : CD
: Class name : Folder memberEnd : Association name : has : Property Our scenario [SH] covers the bidirectional and incremental transformation between two concrete syntax models for UML class diagrams. Figure 1 illustrates a simpli ed excerpt from the involved models and their relationships: a concrete graphical syntax (CGS) model on the left and a concrete textual syntax (CTS) model on the right describe the same UML class diagram. They refer to UML model elements of a third model in the middle. Regarding the model structure, the UML model is no abstract syntax but an existing model that is referred to as shown in Figure 1. The graphical model conforms to GMF Notation [Ecl17]. The textual model conforms to a meta model developed in the Cooperate project [Coo17]. The third UML model conforms to Eclipse UML.
We implemented the synchronization as a feature of the Cooperate modeling environment, which implied the following constraints: a) There is no information about edit operations except for model states. This implies a state-based instead of a delta-based synchronization. b) Editors enforce consistency between the UML model and the changed syntax model. For instance, the Papyrus UML editor [Ger+07] adjustes the CGS and the UML model automatically: adding a class in the editor means adding a class in the UML model and a shape in the graphical model. The same holds true for the textual editor. Therefore, model transformations must not alter a referred UML model that has already been changed by the editor. Instead, they have to keep the other concrete syntax model consistent with the changed model. c) There is no single model that holds all information about the concrete syntax representations. Bijective mappings are not possible. Therefore, transformations must either work in-place or merge the result model into the previous model state. Otherwise, unmapped content such as coordinates of graphical elements cannot be retained. d) Cross references from other models to the syntax models exist. The transformation has to maintain element identities in order to maintain existing cross references.
Besides these conceptual restrictions, we formulate restrictions based on the execution environment of the Cooperate modeling environment and organizational aspects: a) regular updates, b) support of Windows, Linux, and OS X, c) open source, d) executable as Eclipse plug-in, e) support of EMF, f) support of exogeneous transformations, and g) n-to-n cardinality. The extensive survey of Kahani and Cordy about model transformation languages and according tooling [KC15] presents a wide range of approaches. We relied on the information given in the survey and did not try to complement it, which most probably lead to the elimination of several approaches. Considering them will be future work. Filtering the approaches based on our restrictions revealed QVT-O [Obj16], Henshin-TGG [Ehr+15, chap. 12.4], and Melange [Deg+15]. Melange, however, utilizes a general purpose programming language which implies less concise transformations. We chose Henshin-TGG over plain Henshin because a comparison of TGG tools [Leb+14] pointed to this incremental approach. Additionally, it supports bidirectional transformations out-of-the-box. We selected QVT-O and Henshin-TGG for our comparison.
Query/View/Transformation (QVT) [Obj16] is a set of model transformation languages and semantics by the OMG. QVT-O (operational mappings) describes model transformations imperatively by unidirectional mapping operations. Operation signatures consist of context, parameters, and results. The body basically consists of OCL expressions, assignments, and mapping calls. Subsection 3.1 covers experimental incremental updates [Boy16].
Henshin-TGG [Ehr+15, chap. 12.4] builds upon the Eclipse-based Henshin graph transformation tooling [Are+10] and provides tool support for Triple Graph Grammars (TGGs) [Sch94]. TGGs describe transformations as set of graph pattern rules. Each rule describes a correspondence by mapping a left-hand graph pattern to a right-hand graph pattern. A correspondence graph connects both patterns to keep track of transformed elements. Giese and Wagner [GW06] showed that TGGs allow incremental transformations by combining consistency, deletion, and unidirectional transformation steps. Therefore, the TGG approach supports bidirectional and incremental transformations. Henshin-TGG provides an editor for TGG correspondence rules and an execution engine for EMF-based models. The execution engine performs forward and backward transformations, consistency checks, and integration of models based on rules derived from correspondence rules. Henshin-TGG implements incremental transformations by combining consistency checks, marking of inconsistent source graph elements, executing the transformation for marked elements, and deleting remaining inconsistent elements in the target graph. 3
In our case study, we synchronize two models representing a UML diagram with bidirectional and incremental transformations in a state-based way. We achieve this with complemented variants of QVT-O and Henshin-TGG, i.e. we leveraged existing mechanisms to work around restrictions rather than intrusively extending the approaches. We rst report on the realization with QVT-O in Subsection 3.1 and afterwards show how to achieve consistent models with Henshin-TGG in Subsection 3.2. 3.1
QVT-O is an imperative model transformation language that works unidirectionally and provides an experimental incremental update mode. In our usage scenario de ned in Section 2, we, however, need incremental and bidirectional transformations.
The incremental update mode is only documented informally in the Eclipse forums [Boy16]. The mode leverages previous execution traces. Traces hold all executed mapping operations, used context, parameters, and results. The transformation re-executes every mapping operation on the result object from the trace if the context and parameters match. This maintains the identity of the target elements. Transformation writers have, however, to de ne their mappings carefully as the informal documentation as well as Willink and Matragkas [WM15] state. The incremental update does not work for every valid QVT-O transformation: The transformation executor of QVT-O cannot always safely detect if it shall execute a mapping operation incrementally based on the information contained in the trace. Willink and Matragkas present trace model extensions to address the issues but these extensions have not been adopted by the OMG yet. Instead, we derived transformation restrictions that make the incremental update mode work as expected: a) Created model elements must not change in a way that in uences other mappings. For instance, the name of a class must not change after its creation if another mapping uses this name transitively in assignments or guards. b) There must not be mutable global context. c) Mutable lists must not be mapping inputs or its contents must not change. d) Multiple transformations or mappings must not be executed concurrently on the same model in memory. We discuss the in uence of these restrictions in Section 4.
To achieve bidirectional transformations with QVT-O, de ning an unidirectional transformation for each direction is a common approach [Pos+14]. This leads to an increased maintenance e ort but creates the expected results. This approach, however, does not work with the incremental update mode: during an incremental update, the trace of a previous transformation execution is fed back to the transformation engine. The traces of two separate model transformations are, however, not compatible because they describe the transformation for a di erent direction. If we run a transformation TT !G that transforms a textual model T to a graphical model G with a resulting trace RT !G, we cannot run a transformation for the opposite direction TG!T with trace RT !G.
Instead of deriving the traces from the model states as suggested by Ehrig et al. [EEH08] for TGGs, we enable incremental transformations for our coupled unidirectional transformations by transforming the traces of the transformations into traces for the opposite direction as shown in Figure 2a. More precisely, we create additional transformations TRT !G!RG!T and TRG!T !RT !G . After executing a transformation for the models, we execute the according trace transformation to gain consistency not only between the models but also between the traces. The consistent traces serve as input for the incremental update execution. Figure 2b demonstrates these steps: First, the transformation TT !G produces the textual from the graphical model, e.g. by transforming a shape into a class element. Second, the trace transformation TRT !G!RG!T transforms the trace record for mapping operation executions from the TT !G to the TG!T transformation by swapping input and outputs and changing the name of the executed mapping. For a sake of brevity, we do not show more complex trace transformations here but point to the available source code [Coo17].
Deleting elements requires additional treatment because the incremental update preserves unmapped elements. Elements deleted on one side lead to unmapped elements on the other side. To solve this issue, either a post processing step or a reset assignment has to be applied. The reset assignment operator := can completely re-assign multi-valued references. Unmapped elements disappear. This is only possible if a reference cannot include elements that should be retained and are not created by the transformation.
In order to execute the transformation later, serialization of the trace is possible. In this case, transformation writers have to choose unique mapping operation names to avoid ambiguities in the serialized trace because the trace only serializes the mapping name, package, and module but not the full signature. 3.2
The Henshin-TGG approach supports both bidirectional and incremental transformations out of the box. As stated before, a developer models the TGG patterns and then generates unidirectional rules from that patterns that are orchestrated to realize incrementality.
For our speci c usage scenario described in Section 2, we encountered problems using Henshin-TGG when both left hand graph and right hand graph have to contain the same UML element for matching. It is not possible to place the same element on both sides or match nodes based on their identity rather than equality with respect to the modeled relations and attributes. In our scenario, elements on both sides should refer to the very same UML elements. Therefore, we de ned the UML model as a second correspondence model besides the trace model.
Because our transformations only change the concrete syntax model elements but leave UML model elements unchanged, these elements correspond to the TGG advanced concept of so-called reusable nodes [GK10]. This concept makes it possible to create an outgoing reference to an existing element in the correspondence domain without creating the element. Henshin-TGG does not include this advanced concept, therefore we had to adopt both the TGG editor as well as the unidirectional rule generation.
Figure 3 shows the TGG rule for our running example, the derived forward TG!T and backward transformation rules TT !G, as well as the consistency rule CG$T . The shown TGG represents the mapping of a class in the CTS domain to a shape in the CGS domain. The UML class element in the correspondence domain of the TGG is a reusable node and thus marked with a h##i annotation. A reference to this element has to be present on both mapped elements. Moreover, the gure shows new elements with a h++i annotation, while the htri and [tr] are graph traversal marks used by Henshin-TGG in the unidirectional rules. 4
The approaches described in the previous section support our intended usage scenario. There are, however, limitations of their applicability and the e orts for writing and maintaining the transformations have to be considered. We rst report restrictions of the approaches using QVT-O and Henshin-TGG in Subsection 4.1. Afterwards, we determine the e ort of writing and maintaining the transformations and compare the approaches in Subsection 4.2. In Subsection 4.3, we discuss threats to validity. 4.1
The incremental update using QVT-O heavily relies on assumptions that hold for our use case but do not hold for arbitrary use cases. We argue, however, that those assumptions are often not hard to meet: Boyko provides guidelines for writing incremental transformations [Boy16] that help adhering to restrictions and are often already in use: usage of reset-assignments, and avoiding conditional assignments and assignments to result objects in init blocks. Often, transformation designers can follow the restrictions outlined by Willink and Matragkas [WM15] that match our guidelines described in Subsection 3.1: Mapping parameters can replace mutable global context. Reordering mapping rules and leveraging the trace model help avoiding mutable lists and objects. Concurrent transformations can be executed sequentially. As we pointed out, mapping operation names should be unique.
The alternative approach based on Henshin-TGG proved to be reliable as well. For realizing incremental transformations, however, it is necessary to have full model coverage when checking the consistency of graphs. This means developers have to write rules that cover every element, reference, and attribute of both models. Otherwise, the engine will delete those in the course of an incremental roundtrip transformation. Moreover, we encountered restrictions in matching and setting enum attributes and de ning unset references in EMF models.
Both approaches are applicable in our use case: Simple guidelines for adhering to QVT-O restrictions lower the burden to implement incremental transformations in practice. Henshin-TGG provides basic editing functionality that misses support for achieving required full element coverage. While Henshin-TGG has a strong theoretical foundation, mature tool support that needs no complements makes QVT-O better applicable in practice. In order to rate the e ort for writing transformations with both approaches, we collect the model transformation statements and according lines of code excluding empty and commented lines for our use case. The transformations cover 18 elements of the graphical and 20 elements of the textual diagram representation. Table 1 presents the results for the QVT-O approach. The source code of the transformations is available on Github [Coo17] in the de.cooperateproject.modeling.transformation.transformations bundle. The number of mappings of the transformation TT G matches the number of textual elements perfectly. For the opposite direction, this is not true because the same elements are mapped in slightly di erent ways within separate mappings. The LOC, however, do not grow with the same factor as the number of mappings. This indicates that the mappings become simpler. All in all, the bidirectional transformation requires 82 mappings and 24 queries with a total of about 750 LOC. The trace transformations that enable incremental execution more than double the LOC. This meets our expectations because a trace transformation has to incorporate the mapping logic of both directions, which is complex for transformation designers. Creating trace transformations can be considered a complex and costly task { even for experienced transformation designers. In contrast, writing model transformations is straight-forward with some basic knowledge.
For estimating the e ort required for creating the Henshin-TGG transformation, we collect the number of rules, negative application conditions (NAC), and the rule element count (REC). The TGG version of the transformation consists of 35 rules of which ten are unidirectional production rules used to create elements that have no correspondence. Four NACs had to be de ned for handling ambiguous rules that led to the excessive creation of nodes in the target graph. A modeler de nes a NAC by de ning an additional triple graph pattern and then maps the nodes in the NAC to nodes in triple graph rule pairwise. This makes modeling NACs complicated and prone to errors. The Henshin interpreter log can help nding recursively called rules that lead to excessive node creation. It is, however, hard to con gure for Henshin-TGG. Modelers can, however, create speci c trace models to persist additional references in the correspondence graph. This can help to avoid NACs for single side production rules, as a reference to the produced elements can be added to the trace of a parent node. Henshin-TGG, unlike other TGG engines, does not support the de nition of abstract rules that can be re ned for speci c cases. Modelers can, however, duplicate and change the rules manually. In some cases, a workaround can be using an attribute condition to avoid duplicates for similar subclasses of an abstract class. As only graphic editors exist for creating rules, the REC (nodes, references and attributes) can be considered similar to the LOC metric for text based transformation languages. In our scenario the overall REC is 614 elements.
Comparing LOC and REC is not trivial due to their di erent characteristics. Instead, we compare the number of mappings and rules: The QVT-O transformations require 72 mappings not considering abstract and trace mappings. Henshin-TGG requires 35 rules. Both transformations cover the whole scenario. This indicates that QVT-O requires a more ne-grained structuring than Henshin-TGG. The e ort for creating rules can bene t from the more coarse-grained structure possible in Henshin-TGG that avoids duplicating elements. Beginners, however, struggle nding the correct granularity. Moreover, Henshin-TGG does not allow resolving ambiguous rules by specifying the order of rule application. QVT-O simpli es this choice by making it explicit. The additional trace transformation in QVT-O, however, doubles the e ective e ort. Both approaches do not allow fast rule creation in our scenario. The increased e ort for Henshin-TGG is accidental because better tooling can heavily reduce the e ort. In contrast, the additional e ort for QVT-O trace transformations is essential in our scenario and hard to avoid, therefore. This means that a) the paradigm of specifying one bidirectional transformation as used by TGGs implies less e ort in creating model transformations than using coupled unidirectional transformations and that b) tool support is a major factor in considering e orts for transformation creation.
To rate the maintenance e ort for our transformations, we determine the changes required by a real evolutionary change in the textual meta model. A simpli ed version is illustrated in Figure 4: typed elements contain a type TypeReference
type DateTypeReference
UMLTypeReference
type type : DataType
TypedElement <<UML>>
Type type reference that can be either a data type reference or a reference to a UML type. The change removes the type reference class and all of its subclasses. Instead, the typed elements now refer to a UML type directly. This typical maintenance task lead to three removed meta model classes and ve changed references. For the QVT-O transformations, we collected the according changes from our code repository [Coo17, commit 93489a2]. Table 2 summarizes the required changes in the transformations. Transformation changes and trace transformation changes are related because trace transformations replay the e ects of the according transformations. Precisely, maintaining the transformation TT !G requires about the same e ort as maintaining the trace transformation in the opposite direction. Even if the ratio between model and trace transformation changes depends on many factors including the chosen transformation structure, there is a trend for considerably increased maintenance e orts caused by the trace transformations.
The above described meta model change also impacts the TGG implementation of the transformation. To estimate the e ort for adapting to the new meta model, we counted the number of a ected rules ( ve) and the change in rule element count (-19). For nding a ected rules, however, modelers have to inspect all rules of the TGG manually because the tooling lacks syntax checking that indicates deleted elements and search capabilities that allow locating elements quickly. This introduces considerable additional e ort in maintenance compared to QVT-O, especially for complex model transformations. Maintaining transformations with Henshin-TGG would bene t from the same tool support as QVT-O. A textual notation as available for eMo on [Leb+14] could provide a quick overview and ease maintenance as well.
In the context of our research project, we favored QVT-O over Henshin-TGG. The only reason for this decision is the mature tool support and active maintenance. We see bene ts of using TGGs with respect to a strong theoretical foundation and automatic generation of unidirectional transformations from a declarative speci cation. The bene ts, however, vanish in the light of weak tool support, which impedes applicability in practice. 4.3
The most important threat to validity is the small sample size of our study that prohibits statistically signi cant results. This holds true for recorded e orts, statements about applicability of the approaches, and the presentation of possible reasons for observed issues. Therefore, the presented results have to be seen as indicators that need further case studies for veri cation.
Our scenario is, however, realistic because it originates from an existing project. Additionally, an industrial project about synchronizing graphical and textual representations of a model [Mar+15] reported that incremental, bidirectional transformations can be a possible solution to similar problems. The change we used to determine the maintenance e ort is not synthetic but is part of recent development activity. We selected this change because of its corrective nature that implies targeted modi cations to reestablish correctness in a fast and e cient way. Therefore, we assume that the transformation adjustments did not include any unnecessary changes.
The transformation writers and the authors are the same persons. Therefore, some sort of bias cannot be neglected. Nevertheless, we tried to be as objective as possible: We estimated the e orts based on the numbers we derived from the created transformations and actual modi cations.
We see two areas of work related to our approaches: a) model synchronization using QVT-O and Henshin-TGG, and b) mapping of multiple models with di erent concrete syntaxes.
Cicchetti et al. [CCL11] tackle the view-update problem with delta-based model synchronization. Model comparison produces deltas that conform to generated delta meta models. Generated QVT-O transformations apply the deltas in an in-place transformation. The QVT-O transformations themselves are neither bidirectional nor incremental. Aranega et al. [AED11] do not perform model synchronization but discuss limitations in using QVT-O and its trace for this purpose. They use a customized trace model that records more information than the default trace model to address issues like reported by Willink and Matragkas [WM15], which we described above. In our approach, we adjusted our transformations to circumvent these issues.
Using QVT-O or TGGs is no novel approach in the eld of concrete syntax mapping. Elaasar and Labiche [EL11] used QVT-O mappings to map a UML diagram interchange model to a UML diagram graphics model. The former describes the layout information implied by the abstract syntax. The latter describes the layout information detailed for a concrete syntax. Even if unidirectional mappings degrade comprehensibility, the authors argue that ambiguities of the conceptual mappings are the core issue. Andres et al. [ALG07] use TGGs to transform parts of a graphical model into a textual view without focusing bidirectionality. They use TGGs to choose the trace model freely. Others [WM15; AED11] state this QVT weakness as well.
There is only little related work on our speci c use case of synchronizing textual and graphical concrete syntax models for UML. Maro et al. [Mar+15] synchronize graphical and textual views on excerpts of UML using the Atlas Transformation Language (ATL) but do not maintain layout information. They, however, suggest using incremental transformations to solve this issue. In a survey about textual modeling languages and tooling for UML [SG16], we found three approaches that support the roundtrip between textual and graphical representations. We estimate their e ort for creating the transformations considerable because, to the best of our knowledge, no dedicated model transformation language is used. 6
In this paper, we reported our experiences using QVT-O and Henshin-TGG for synchronizing models representing UML diagrams by a graphical and a textual concrete syntax. We described how to achieve incremental and bidirectional transformations for our use case. Precisely, we complemented QVT-O with trace transformations to achieve incrementality and coupled two unidirectional transformations to achieve bidirectionality. We complemented Henshin-TGG with support for reusable nodes. We discussed restrictions of the approaches and how to adhere to them. The e ort for creating and maintaining transformations using QVT-O can be high because of trace transformation overhead. We found that Henshin-TGG divides the e ort for creating transformations in half but requires considerable e ort for maintaining transformations after changes because of weak tool support.
Practitioners and researchers bene t from our three main contributions, i.e., summarized restrictions, reported experiences, and the case studies: The case studies provide practitioners with hints on how to extend existing tooling and which restrictions apply. Researchers can empirically evaluate if the approaches including the complements used in the case studies become more and easier applicable. The summarized restrictions and our experiences help practitioners to select an approach and give implementation guidelines. Researchers can create new or extended approaches to tackle discovered challenges.
In future work, we want to evaluate if generating QVT-O traces based on model states lowers the transformation creation and maintenance e ort compared to the trace transformation. Additionally, we plan to apply the approaches to more UML diagram types in order to validate that the restrictions hold in multiple, realistic use cases. With respect to Henshin-TGG, we aim to increase usability by improving the editing capabilities.
This work is funded by the German Federal Ministry of Labour and Social A airs under grant 01KM141108. [AED11] [Deg+15] Thomas Degueule et al. \Melange: A Meta-language for Modular and Reusable Development of DSLs".
In: Proceedings of SLE. 2015, pp. 25{36.
Eclipse Foundation. Eclipse Graphical Modeling Framework (GMF) Notation. https://www.eclipse. org/gmf-notation/. accessed 16.01.17. 2017.
Hartmut Ehrig, Karsten Ehrig, and Frank Hermann. \From Model Transformation to Model Integration based on the Algebraic Approach to Triple Graph Grammars". In: ECEASST 10 (2008).
Hartmut Ehrig et al. \Tool Support". In: Graph and Model Transformation: General Framework and Applications. 2015, pp. 351{399.
Maged Elaasar and Yvan Labiche. \Diagram De nition: A Case Study with the UML Class Diagram".
In: Proceedings of MODELS. 2011, pp. 364{378. [Are+10] [CCL11] [CH06] [Coo17] [Ecl17] [EEH08] [Ehr+15] [EL11] [GK10] [GW06] [KC15]
Joel Greenyer and Ekkart Kindler. \Comparing relational model transformation technologies: implementing query/view/transformation with triple graph grammars". In: SoSyM 9.1 (2010), p. 21. Holger Giese and Robert Wagner. \Incremental Model Synchronization with Triple Graph Grammars". In: Proceedings of MODELS. 2006, pp. 543{557.
Na seh Kahani and James R. Cordy. Comparison and Evaluation of Model Transformation Tools.
Tech. rep. 2015-627. School of Computing, Queens University Kingston, Ontario, 2015. [Leb+14] Erhan Leblebici et al. \A Comparison of Incremental Triple Graph Grammar Tools". In: ECEASST 67 (2014). [Mar+15] Salome Maro et al. \On integrating graphical and textual editors for a UML pro le based domain speci c language: an industrial experience". In: Proceedings of SLE. 2015, pp. 1{12. [Obj15] [Obj16] [Pos+14] [Sch94] [SG16] [SH] [WM15]
Object Management Group (OMG). Uni ed Modeling Language (UML) { Version 2.5. 2015. Object Management Group (OMG). Meta Object Facility (MOF) 2.0 Query/View/Transformation Speci cation { Version 1.3. 2016.
Christopher M. Poskitt et al. \Towards Rigorously Faking Bidirectional Model Transformations". In: Proceedings of AMT. 2014, pp. 70{75.
Andy Schurr. \Speci cation of Graph Translators with Triple Graph Grammars". In: Proceedings of WG. 1994, pp. 151{163.
Stephan Seifermann and Henning Groenda. \Survey on Textual Notations for the Uni ed Modeling Language". In: Proceedings of MODELSWARD. 2016, pp. 28{39. E. Willink and N. Matragkas. \QVT Traceability: What does it really mean?" In: Proceedings of AMT. invited talk. 2015.