Technical Report. Partial Bidirectionalization of Model Transformation Languages.

Transcription

1 Technical Report Partial Bidirectionalization of Model Transformation Languages Sochiro Hidaka and Massimo Tisi December 13th, 2016 Notes Submitted to the Journal of Science of Computer Programming on December 13th, This journal paper is an extended version of the conference paper Partial Bidirectionalization of Model Transformation Languages under review at FASE 2017 at the moment of the journal submission, but later rejected. The conference paper was resubmitted with additional content to the 10th International Conference on Model Transformation with title Translationbased Partial Bidirectionalization of Model Transformation Languages. The ICMT submission includes original contents that are not present in the journal submission: presentation of a working tool implementation and demonstration on a complete example with non-trivial bidirectional behavior. In case of acceptance of the ICMT and SCP submissions, the camera ready of this journal paper will be updated to reference the ICMT publication instead of the FASE submission.

2 Partial Bidirectionalization of Model Transformation Languages Sochiro Hidaka Hosei University, Tokyo, Japan Massimo Tisi AtlanMod team (Inria, Mines Nantes, LINA), Nantes, France Abstract While most model-transformation languages in Model-Driven Engineering are unidirectional, bidirectionality is valuable when artifacts need two-way synchronization. Although several bidirectional transformation engines have been developed, their semantics is generally considered more difficult to express and predict compared to the unidirectional case. When possible, full bidirectionalization of unidirectional langages where users write the forward direction of their transformations in the same unidirectional language they are used to, and obtain a system that (besides performing the complete forward transformation) can automatically propagate in the backward direction the target updates would be desirable, but it would be far from trivial. In this paper we propose a partial bidirectionalization by partial compilation towards bidirectional languages and coupled execution of the two language engines. Forward transformation is still complete, whereas the propagable subset of target updates are well-defined in the backward direction. While the extent of the bidirectionalization depends on the two coupled systems, in this paper we provide a general combination scheme and we discuss its well-behavedness. This is an extended version of the Partial Bidirectionalization of Model Transformation Languages submitted to FASE addresses: hidaka@hosei.ac.jp (Sochiro Hidaka), massimo.tisi@inria.fr (Massimo Tisi) Preprint submitted to Science of Computer Programming December 13, 2016

3 We formally prove that the resulting system is well-behaved when four applicability conditions are satisfied. We show that real-world transformation systems like the ATL model-transformation language and the GRoundTram bidirectional graph-transformation system satisfy these conditions, then we use our technique to bidirectionalize the first on top of the second. Keywords: Bidirectionalization, Runtime Interoperation, Transformation Engines 2010 MSC: 68N99 1. Introduction In the field of Model-Driven Engineering (MDE), model-transformation languages (MTLs) have been designed to facilitate the expression of relationships between models, in the form of transformation rules (Czarnecki & Helsen, 2006). Transformation engines apply such rules to automatically generate new models or update existing ones, keeping the transformation s source and target models consistent. In several applications, synchronization between models needs to be bidirectional, as modifications can be performed in both sides of the transformation and global consistency has to be guaranteed. For this reason several bidirectional transformation languages have been developed, both within and outside the MDE community (Hidaka et al., 2015). However, taking into account the bidirectional semantics during the development of the model transformation adds a significant layer of complexity to the transformation design: execution properties of a bidirectional system are generally more complex and it is more difficult for the developer to predict the exact system behavior (Eramo et al., 2014). Because of this, several MTLs are unidirectional, and focus on providing an efficient solution for the unidirectional scenario. It is still possible to achieve bidirectionality in these languages, by separately writing two opposite transformations. However this raises other reasons of complexity, since users need to verify case by case the consistency of the two unidirectional transformations, and keep their evolution coupled. 2

4 An alternative approach for the application of unidirectional transformation languages to bidirectional scenarios is the bidirectionalization of the unidirectional language (Matsuda et al., 2007; Voigtländer, 2009). In this approach, users write one direction of the transformation by using the unidirectional transformation language they are used to. The language is overloaded with a bidirectional semantics so that the resulting system is equivalent to the unidirectional system in the forward direction, but it exhibits the additional capability of propagating in the backward direction a set of changes to the target models. Full bidirectionalization of the unidirectional model transformation is in general not possible without imposing restrictions to the model transformation language, and existing work (Sasano et al., 2011) is mainly focused on extending the part of the unidirectional language that is bidirectionalized. In this paper we do not aim at maximizing the extent of the bidirectionalization, instead we propose a coupled 1 execution of unidirectional and bidirectional transformation engines. The user writes a unidirectional transformation in an existing unidirectional language, and the unidirectional transformation engine performs the complete forward transformation with its full expressiveness. A transformation compiler translates part of the unidirectional transformation into an equivalent transformation in an existing bidirectional language. The unidirectional and bidirectional transformation engines are executed in parallel and the system performs seamless synchronization between the respective models. The semantic gap caused by partial compilation makes the full system alignment challenging. With respect to related work, our approach: 1) does not require restrictions to the forward transformation semantics; 2) clearly distinguishes the parts of the target models whose updates are subject to backward-propagation by the underlying bidirectional transformation engine; 3) does not require modifications to any of the two engines involved; 4) exhibits a easily user-predictable behavior 1 Our coupling approach may be considered as a new pattern of coupled transformations, in the sense of Lämmel (2016). 3

5 (formally it satisfies a variation of well-behavedness property from (Czarnecki et al., 2009)). We define the conditions for the applicability of our approach in terms of properties that need to be respected by the two transformation engines and by the partial translation. We prove that a system respecting these properties has a globally well-behaved bidirectional semantics. We exemplify the proposed approach by building a bidirectionalized version of the ATL model transformation language (Jouault et al., 2008), on top of the GRoundTram (Hidaka et al., 2011, 2013b) bidirectional graph-transformation system by partially translating ATL to UnQL (Buneman et al., 2000), the graph transformation language bidirectionalized (Hidaka et al., 2010) in the GRound- Tram system. The resulting tool is a contribution of its own and its source code is freely available at the paper page 2. The paper is structured as follows: Section 2 introduces a running case for the paper; Section 3 describes the approach and its application to the running case; Section 4 formalizes the applicability conditions for our approach and proves that global well-behavedness follows from them; Section 5 shows that our integration of ATL and GRoundTram satisfies the applicability conditions; Section 6 compares the approach with related work and Section 7 concludes the paper. 2. Running Case 2.1. User scenario Our research effort aims at simplifying the coupled evolution of model artifacts in MDE, hence it is applicable whenever some (e.g., software, system, physical, data) models are maintained and evolve while staying consistent with each other. To illustrate our approach, we refer in this paper to a simple example that considers two well-known models: a UML class diagram and a relational schema. We can imagine, e.g., that the class diagram is modeling the code of 2 4

6 Package Datatype +name = String ownedelements 0..* Classifier +name = String type 1 Class Attribute +name = String +multivalued = Boolean owner attr 0..* Schema +name = String ownedelements 0..* col Table 0..* +name = String key 0..1 Column +name = String type 0..1 Type +name = String (a) Class diagram metamodel (b) Relational metamodel Figure 1: Metamodels of the case study an object-oriented program and the relational schema (that models tables in a relational database) represents its persistence layer. The user wants to develop a model-to-model transformation (MMT) to express the relation between the UML classes of the application s data model and the relational tables, according to an object-persistence policy. The transformation computes which tables and attributes to produce for each UML element. Figures 1a and 1b show the source and target metamodels of the transformation, while Figures 4a and 4b show an instance of each metamodel 3. We suppose that both the class model and the relational schema may be manually edited during the application development or maintenance, depending on the user background (software architect or database expert) or the preferred tool (UML diagram editor or database editor). While application code will have to be manually evolved, an automated system should make sure that classes and tables of the data model are always synchronized. Hence our scenario requires a MMT system working in two directions. We propose to address the two synchronisation directions by using two tools: Forward: The user writes the forward transformation using a unidirectional MMT language and the unidirectional engine performs forward transformation. In our case study we use the ATL language for this direction (Jouault et al., 2008). 3 While in figure we show models in their abstract object-diagram notation, we can imagine them to be rendered in their particular graphical concrete syntax by the editing tools. 5

7 Backward: Part of the forward transformation is transparently compiled into a bidirectional transformation language. A bidirectional engine performs backward propagation of target updates. In our case study this role will be filled by the GRoundTram graph-transformation engine (Hidaka et al., 2010, 2011, 2013b) ATL In a first phase, the user develops in the ATL language the simple MMT transformation in Listing 1 that transforms the Class model in Fig. 2a into the Relational model in Fig. 2b 4. 1 module Class 2Relatio nal ; 2 create OUT : Relational from IN : ClassDiagram ; 3 4 rule Package2Schema { 5 from p : C l a s s D i a g r a m! P a c k a g e ( not p. o w n e d E l e m e n t s. i s E m p t y ( ) ) 6 to out : Relational! Schema 7 ( name< p. name, ownedelements < p. ownedelements ) 8 } 9 10 rule C l a s s 2 T a b l e { 11 from c : C l a s s D i a g r a m! Class 12 to t : R e l a t i o n a l! Table 13 ( name< c. name ) 14 } Listing 1: Class2Relational in ATL An ATL transformation (module) is constituted by a set of rules that describe how elements of the target model are generated when patterns in the source model are matched. The Object Constraint Language OCL (Warmer & Kleppe, 1998) is used as expression language in the transformation rules. Rules are composed of an input pattern and an output pattern. Input patterns are 4 This transformation code is inspired from the Class2Relational case study ( dcs.kcl.ac.uk/events/mtip05), the de-facto standard example for model transformations, but simplified and adapted for illustrative purpose. Notably this version of the transformation does not support multivalued attributes. 6

8 : Package name = Families ownedelements ownedelements : Class : Class name = Family name = Person (a) Sample ClassDiagram model : Schema name = Families ownedelements ownedelements : Table : Table name = Family name = Person (b) Sample Relational model Figure 2: Sample models (shown in object-diagram syntax). Corresponding elements have the same position in the two models. associated with OCL guards that impose matching conditions on the input elements. Output patterns are associated with bindings, OCL expressions that define how to initialize properties of the elements created by the matched rule. Rule Class2Table (lines 10-14) creates a table for each class, and names it like the corresponding class. Rule Package2Schema (lines 4-8) transforms all non-empty packages into relational schemas and initializes their list of tables. Note that ATL rules implicitly interact for generating crossreferences among target model elements. E.g., at line 7 the binding ownedelements<-p.ownedelements states that the tables of the schema to generate correspond to the classes of the matched package (p): in practice, the result of the transformation of these classes, by any rule, will be added as tables of the schema. Listing 1 exemplifies the core subset of the ATL language, for an illustration of the complete language we refer the reader to (Jouault et al., 2008) GRoundTram GRoundTram is an integrated framework for developing well-behaved bidirectional transformations expressed in the language UnQL (Buneman et al., 2000). Figure 3 shows the syntax of UnQL. It has templates (T ) at the top level to produce rooted graphs with labeled (L) branches ({L : T,..., L : T }), union of templates (T T ), graph variable reference ($g), conditionals, SQL-like select (select) queries with bindings (B), and structural recursion (sfun). Bindings include graph pattern matching (Gp in $G) and Boolean conditions (BC). 7

9 (template) T ::= {L : T,..., L : T } T T $g if BC then T else T select T where B,..., B letrec sfun fname(l : $G) =... in fname(t ) (binding) B ::= Gp in T BC (condition) BC ::= not BC BC and BC BC or BC L = L isempty(t ) (label) L ::= $l a (label pattern) Lp ::= $l Rp (graph pattern) Gp ::= $G {Lp : Gp,..., Lp : Gp} (regular path pat.) Rp ::= a Rp.Rp (Rp Rp) Rp? Rp Rp+ Figure 3: Syntax of UnQL Conditions include usual logical connectives, label equality and emptiness check isempty(t ) which is false if there is at least one edge reachable from the root of the graph generated by T. Label expressions include label constants and variable ($l) bound by the label patterns in the graph patterns and the argument of structural recursion. Graph patterns bind the entire subgraph $G or labels on the branches and following subgraphs {Lp : Gp,..., Lp : Gp}. Label patterns may include regular expressions of the labels (Rp) along the path traversing multiple edges. Listing 2 shows the UnQL transformation that corresponds to the ATL transformation in Listing 1. It transforms the graph encoding of the Class model in Fig. 2a to the graph encoding of the Relational model in 2b. The transformation consists of structural recursion functions (sfuns). In the listing, the last definition (function Class2Relational at lines 5-15) is the main function that corresponds to the ATL module Class2Relational. Its clauses generate elements according to different ATL rules Package2Schema (lines 6-10) and Class2Table (lines 11-13). References between target elements are represented by definition and call of sibling mutually-recursive functions: ownedelements Package2Schema is called at line 8 for the reference ownedelements in 8

10 1 select 2 letrec sfun ownedelements_package2schema({ownedelements :$g}) = 3 {ownedelements : Class2Relational($g )} 4 ownedelements_package2schema({$l :$g}) = {} 5 and sfun (* main function *) 6 Class2Relational({Package :$g}) = 7 if (not isempty(select {dummy:{}} where {ownedelements :$g} in $g ) 8 then {Schema : (ownedelements_package2schema($g ) 9 (select {name :$g} where {name :$g} in $g ))} 10 else {} 11 Class2Relational({Class :$g}) = 12 {Table:(( select {name :$g} where {name :$g} in $g ) 13 col_class2table($g ))} 14 Class2Relational({$l :$g}) = {} 15 in Class2Relational($db) Listing 2: Class2Relational transformation in UnQL the rule package2schema (lines 2-4). SQL-like select expressions (lines 9 and 12) perform shallow copy of primitive data type values by capturing the subgraph under label name and creating the new edge with the same label and the same subgraph. The conditional expression if (lines 7-10) with the graph emptiness predicate isempty checks the existence of particular subgraph patterns, and is used to express the ATL guard. The select expression produces a graph with as many edges (since the edge name does not matter, we label them dummy) as the number of the bindings of $g for each subgraph patterns found by the where clause. isempty evaluates to true if no such patterns are found. The where clause allows regular expressions on labels for complex pattern matching: we use it to encode traversals of attributes and references in OCL expressions. GRoundTram extends UnQL as UnQL+ to support more user-friendly syntactic sugars (Hidaka et al., 2009, 2013b) but this paper does not depend on the extension Partial Translation The simple ATL rules in Listing 1 may be automatically translated to the equivalent UnQL code in Listing 2. An ideal translator would be able to con- 9

11 : Package name = Families ownedelements ownedelements : Attribute : Class type attr : Class name = family name = Family name = Person multivalued = false type attr attr attr : Attribute : Attribute : Attribute name = name name = personid name = members multivalued = false multivalued = false multivalued = true type type : DataType name = String : Schema name = Families ownedelements ownedelements : Table : Column attr : Table name = Family name = Person family name = Person attr attr key : Column : Column name = Family name name = Person personid type type type : Type name = String (a) Sample ClassDiagram model (b) Sample Relational model Figure 4: Sample models (shown in object-diagram syntax). Corresponding elements have the same position in the two models. Updates to elements with dashed lines are not backwardpropagable. vert any ATL transformation into an UnQL transformation that is perfectly equivalent in the forward direction. Unfortunately such an ideal translator is generally not available, and in our case it would be even unfeasible because of the difference in expressive power of the two languages. We exemplify this problem in a second phase of our use case: we imagine that the user extends the ATL transformation by adding the more complex rules in Listing 3. The resulting transformation is able to transform the models in Fig rule C l a s s 2 T a b l e { 2 from c : C l a s s D i a g r a m! Class 3 to t : R e l a t i o n a l! Table 4 ( name< c. name, col< c. attr, 5 key< c. attr >s e l e c t ( a a. name. e n d s W i t h ( Id ) ) ) 6 } 7 8 rule D a t a T y p e 2 T y p e { 9 from d : C l a s s D i a g r a m! D a t a T y p e 10 ( ClassDiagram! Class. allinstances ( ) 11 >s e l e c t ( c c. name = d. name ) >i s E m p t y ( ) ) 12 to t : R e l a t i o n a l! Type 13 ( name< d. name ) 14 } rule S i n g l e V a l u e d A t t r i b u t e 2 C o l u m n { 17 from a : C l a s s D i a g r a m! A t t r i b u t e ( not a. m u l t i v a l u e d ) 10

12 1 select 2 letrec sfun ownedelements_package2schema({ownedelements :$g}) =... 3 and sfun col_class2table({attr :$g}) = {col: Class2Relational($g )} 4 col_class2table({$l :$g}) = {} 5 and sfun owner_singleattribute2column({owner :$g}) = {owner : Class2Relational($g )} 6 owner_singleattribute2column({$l :$g}) = {} 7 and sfun (* main function *) 8 Class2Relational({Package :$g}) =... 9 Class2Relational({Class :$g}) = 10 {Table:( col_class2table($g ))} 12 Class2Relational({Attribute :$g}) = 13 if isempty(select {dummy:{}} 14 where {multivalued. Boolean :$g } in $g, 15 {true:$d} in $g ) 16 then {Column:(( select {name:{string:{$on ˆ $n}}} 17 where {owner._name. String:{$on :$d}} in $g, 18 {name. String:{$n :$d}} in $g ) 19 owner_singleattribute2column($g ))} 20 else {} 21 Class2Relational({$l :$g}) = {} 22 in Class2Relational($db) Listing 4: Class2Relational transformation (corresponding to Listing 3) in UnQL 18 to c : R e l a t i o n a l! C o l u m n 19 ( name< a. o w n e r. name+ _ +a. name, 20 owner< a. owner, 21 type< i f a. type. o c l I s T y p e O f ( C l a s s D i a g r a m! D a t a T y p e ) 22 then a. type e l s e t h i s M o d u l e. s t r i n g T y p e endif ) 23 } Listing 3: Class2Relational in ATL Rule Class2Table is extended and now it initialises the list of columns with the respectively transformed attributes (line 4) and selects as table key the attribute whose name ends by the string Id, if any (line 5). The new rule SingleValuedAttribute2Column (lines 16-23) selects input model elements of type Attribute (line 17) and transforms them into output elements of type Column (line 18). A guard (line 17) imposes to match only attributes that are not multivalued (multivalued attributes would have a more 11

13 complex representation in the relational schema). A first binding (line 19) computes the column name as the concatenation of class and attribute name; a second one (line 20) imposes that the owner of the Column corresponds to the owner of the Attribute; a third one (lines 21-22) states that if the attribute has a primitive type (DataType) then the type of the column should correspond to the type of the attribute (String otherwise). The new rule DataType2Type (lines 8-14) copies into relational types the class diagram types, but only if no class exists with the same name of the type, to avoid conflicts. Listing 4 shows the UnQL transformation that would result by partial translation of ATL transformation in Listing 1, completed by the rules in Listing 3 (precisely, the gray background in Listing 3 highlights the parts of the unidirectional transformation that are not translated to UnQL). The parts that corresponds to Listing 1 is omitted by ellipses to focus on the part that corresponds to Listing 3 in particular, we concentrate on the idea of partial translation here. Among the clauses in the main function Class2Relational at lines 7-22) that corresponds to the ATL module Class2Relational, the clause for the rule SingleValuedAttribute2Column (lines 12-20) is added, while the clause for DataType2Type is missing by the partiality of the translation. At the binding level, in the clause for the rule Class2Table (lines 9-11), the function col Class2Table called at line 11 for the output pattern element col is added, while no code is generated for key by the partiality. Similarly, in the clause for the rule SingleAttribute2Column (lines 12-20), no code is generated for type output pattern element. The basic idea of partial translation is thus when we drop a rule from the ATL code, a clause is dropped from the main function of the UnQL code. Likewise, an UnQL expression (and possibly a function that is called in the expression) is dropped when an ATL output pattern element is dropped. 12

14 UX Transf. UX Technical Space BX Source Model UX to BX Data Model Tracer UX Transf. w/ Traces Partial UX to BX Transl. Target Update Target Model w/ Traces Updated Target Model w/ Traces UX to BX Data Model Technical Space Source Model BX Fwd Transf. w/ Traces BX Bwd Transf. Target Model w/ Traces Sub- Updated Target Model w/ Traces w/ Traces Figure 5: Overview of the approach (models are rectangles, transformations are rounded rectangles and HOTs are double rounded rectangles) 3. Bidirectionalization by Runtime Interoperation Our strategy for bidirectionalization is to combine a popular and powerful unidirectional model transformation language with an existing bidirectional transformation language with well-defined bidirectional properties. The user writes the transformation in the unidirectional language and does not need any knowledge of the bidirectional language, since the bidirectional system is executed completely behind the scenes. The bidirectional transformation language may sacrifice expressive power for the capability of back-propagating updates on the target. We tolerate the expressivity gap between the two languages by partially translating the unidirectional transformation language into the bidirectional transformation language. In this paper we do not aim at minimizing the partiality of this translation but at defining a well-behaved interoperation of the two engines. Fig. 5 shows a global view on our approach. We run the unidirectional (UX in figure) and bidirectional (BX in figure) transformation systems in parallel, maintaining their artifacts in separate technical spaces. Because of partial translation the UX and BX transformations are not equivalent and our challenge is 13

15 providing a generic method to keep the two transformation systems consistent with each other. Thanks to such synchronization the user of our example will be able to generate the relational model in Figure 4a, to update it (e.g., by renaming a table or adding a column) and to see the change propagated to the class diagram (correspondingly, as a renamed class or an added attribute). A full system roundtrip starts from a source model in one of the two technical spaces. When the transformation languages have different data models, we need a clearly defined bidirectional transformation (UX to BX Data Model) between these data models. In our case study, ATL transforms models (i.e., typed, attributed and directed graphs) as the ones presented in Figure 4. The graph data model used by GRoundTram is rooted and edge-labeled. We use the encoding of models in GRoundTram described in previous work (Hidaka et al., 2009, 2013b). Once the correspondence among the data models is defined, we need a mechanism to align the execution of the two engines. Our solution is the injection of a stable generation of model element identifiers within the unidirectional transformation (UX Transf.). The generation is loosely-coupled (Jouault, 2005) in the sense that the translation logic remains unchanged while the identifiergeneration logic is injected transparently via the Tracer higher-order transformation (HOT) (Tisi et al., 2009). The resulting transformation (UX Transf. w/ Traces) is executed on the source model to produce a target model with stable traceability information. Stability here means that, given identical input model and transformation, identical identifiers are produced. In our example the Tracer HOT augments the rules in Listing 3 with bindings computing element identifiers. Listing 5 shows the result for rule Class2Table as it would appear in UX Transf. w/ Traces: w.r.t. the version in Listing 3 the injected binding at line 6 (in gray) assigns an identifier to the newly created table, computed by concatenating the identifier of the matched Class (c. xmiid ), the name of the rule (Class2Table) and the name of the output pattern element (t). The unidirectional transformation is then translated to the bidirectional lan- 14

16 guage by a translation HOT (Partial UX to BX Transl.). It is important to note that the trace generation logic embedded in the unidirectional transformation is also translated to the bidirectional transformation language, generating identical model element identifiers (BX Fwd Transf. w/ Traces). In this way we are able to retrieve corresponding elements in the two technical spaces by coincident identifiers. In the running example, Listing 6 is translated from Listing 5. The only difference w.r.t. Listing 4 are lines 8-9 (in gray) that generate the new id of the model element, being the direct translation of line 6 in Listing 5. In our example, the gray background in Listings 3 highlights the partiality of the UX to BX HOT at both the rule level and the binding level. We assume that ATL rules with complex guards are not translatable in UnQL: e.g., in Listing 4 we have no corresponding clause for the rule DataType2Type because the current ATL to UnQL compiler can not translate the OCL operation allinstances(). Analogously we assume that complex bindings are not translatable: e.g., the bindings of key and type, respectively in the rules Class2Table and SingleValuedAttribute2Column, are not translated to Listing 4, since string comprehension and type introspection is not supported by the current ATL to UnQL compiler. Given the partiality of the translation, the target model of the forward bidirectional transformation is in general different from the target model of the original unidirectional one. However in the design of our translator from ATL to UnQL, we impose a strict property to the partial translation: the target models generated from the bidirectional transformation need to be strictly included 1 rule C l a s s 2 T a b l e { 2 from c : C l a s s D i a g r a m! Class 3 to t : R e l a t i o n a l! Table 4 ( name< c. name, col< c. attr, 5 key< c. attr >s e l e c t ( a a. name. e n d s W i t h ( Id ) ), 6 x m i I D < IN. c o n c a t ( c. x m i I D. c o n c a t (. C l a s s 2 T a b l e. t ) ) ) 7 } Listing 5: Class2Table with identifier injection in ATL 15

17 1 select 2 letrec sfun col_class2table({attr:$g}) = {col: Class2Relational($g)} 3 col_class2table({$l :$g}) = {} 4 and sfun (* main function *) 5 Class2Relational({Class:$g}) = 6 {Table:((select {name:string:$g} where {name._:$g} in $g) 7 col_class2table($g) 8 (select {xmi_id:{string:{("in"ˆ$idˆ".class2table.t"):{}}}} 9 where {xmi_id._:{$id :$dummy}} in $g) )} 10 Class2Relational({$l :$g}) = {} 11 in Class2Relational($db) Listing 6: Class2Table with identifier injection in UnQL in the target models of the corresponding unidirectional system. The property will be formally discussed in the next section, but intuitively it aims to provide a clear separation of updatable and not updatable parts in the target model and make the system user-predictable. In the running case, the elements depicted with continuous lines in the right side of Fig. 4a are common to the target models of both the systems. The elements with dashed lines (Type elements, key references and type references) are exclusively produced by the unidirectional language, since the ATL code that produces them is not translated to UnQL (respectively, DataType2Type rule, type binding, key binding). Submodel (formally defined in Sec. 4) matching is guided by the identifiers produced in the previous step. In our current approach the target model editor uses this information to forbid updates to the non-propagable part. Finally, the cycle in Fig. 5 closes by receiving updates to the propagable part of the target model (Target Update), and transforming the updated target model to the bidirectional system (UX to BX Data Model). The bidirectional system will then be able to apply backward transformation (BX Bwd Transf. w/ Traces) to update the source, by taking into account the source model, target submodel and updated version of the target model, and maintaining the identifier correspondence. 16

18 4. Well-Behavedness under Partial Translation In our approach only a subset of the unidirectional transformation language L U is translated, since not all the language constructs can be bidirectionalized due to the limited expressive power of the target language. In this section we formally prove that the global system we described in Fig. 5 is well-behaved (Czarnecki et al., 2009) if its components exhibit certain properties. Intuitively we can make the whole system well-behaved if: 1) the unidirectional language L U has a modularity property that we call rule additivity, 2) we can build strongly invertible transformation between the data models of L U and L B, 3) we can build a translator of the part of L U to L B such that the models produced by transformations in L B coincide with the ones produced by corresponding (partial) transformations in L U, 4) the underlying bidirectional language L B is well-behaved. These properties are sufficient to couple any two transformation systems so that updates to the target model of the unidirectional system are reflected through the bidirectional system. In Section 5 we will present evidence of the practical applicability of the approach by showing that these four properties are satisfied by ATL, GRound- Tram and the translation we have built. While we intentionally designed our system in order to respect the four properties, they are generally not uncommon in model-driven engineering: Property 1 is satisfied by other popular UX model-transformation languages besides ATL (e.g., Epsilon ETL (Kolovos et al., 2008)); Property 2 is easily satisfiable by encoding models in low level representations, like well-known encoding of node-labeled graphs by edge-labeled graphs; given Property 2, Property 3 is satisfiable by design of the translator (this requires a significant effort, in general depending on the chosen languages, but is still satisfiable given stable generation of model element identifiers in Section 3); Property 4 (or analogous) is common among BX languages (Czarnecki et al., 2009). In the rest of this section, we first introduce definitions relevant to our construction (Sec.4.1). Then we introduce the above-mentioned properties in detail (Sec. 4.2). We prove the overall well-behavedness (Sec. 4.3) based on 17

19 these properties Definitions We first recap well-behavedness (Czarnecki et al., 2009), that intuitively states that a round-trip in a bidirectional transformation system does not have surprising effects. Definition 1 (Well-behavedness). Given a transformation expression t, the pair of its forward semantics F[[t] : S V which is a total function from source artifact (e.g., models or graphs) to target artifact, and its backward semantics B[[t]] : S V S which is a partial function from target artifact to source artifact, w.r.t. the original source artifact is well-behaved if the following two properties hold. F[[t]]a s = a t B[[t]](a s, a t ) = a s B[[t]](a s, a t) = a s B[[t]](a s, F[[t]a s) = a s It is worth noting that the original source artifact a s (GetPut) (WPutGet) S is needed to recover the information that may had been discarded by the forward transformation (Czarnecki et al., 2009). WPutGet (Hidaka et al., 2013b) corresponds to Weak Invertibility by Diskin et al. (2011b) that is a weaker variant of Put- Get (Foster et al., 2007) that corresponds to Correctness (Stevens, 2010). B[[t]](a s, a t) = a s F[[t]]a s = a t (PutGet) Diagrammatically, GetPut, PutGet and WPutGet would be respectively represented (a la (Johnson & Rosebrugh, 2014)) by S id S id F [t ] B [t ] S V S B [t ] F [t ] Note that (f g)x = (f x, g x). S V V π 2 S S S π 2 π 1 B [t ] id F [t ] B [t ] S V S V π 1 π 1 S 18

20 However, to simplify presentation we avoid the product such as S V and allowing functions to take arguments from different places using dotted lines as the figure of WPutGet on the right. The aim of this paper is to build a global transformation system (unidirectional model transformation S S B [t ] F [t ] V B [t ] V in L U on top of bidirectional graph transformation in L B ) that exhibits the well-behavedness property. Since PutGet implies WPutGet, any L B with PutGet can be used instead of the one with WPutGet. So we only discuss WPutGet in this paper to show that L B with WPutGet implies overall WPutGet. L B with Put- Get would imply overall PutGet, but it is not proved in this paper. We formally define a model as a set of elements and labeled references. Definition 2 (Models). A model m consists of the set m.v of model elements (nodes) and set of labeled references (edges) m.e m.v Labels m.v where Labels is the set of all possible labels. Under partial translation we first project the transformation T to a transformation that is fully translated. To clearly distinguish the target of the projected transformation and that of the original transformation, we make the former embedded in the latter. This embedding is represented by the following submodel relation between models. Definition 3 (Submodel Relation ( M )). m is a submodel of m, denoted by m M m, if there is a following inclusion morphism (see for example Ehrig et al. (2006))f : m m: (e 1, l, e 2 ) m.e. (f(e 1 ), l, f(e 2 )) m.e Intuitively, bigger models have more model elements and more features for corresponding model elements (i.e., elements with the same identifier as described in Section 3). In the rest of the paper we will instantiate the M relationship 19

21 between models by using set inclusion relationship between their sets of model elements. Definition 4 (Model Transformation). Model transformation T consists of set of rules T.R. We need the following relationship between the transformation T L U and its translatable part T 0. Definition 5 (Inclusion Relation of Model Transformations ( MT )). Model transformation T 0 L U is included in model transformation T L U, denoted by T 0 MT T, if there is an inclusion morphism f from T 0.R to T.R. In the rest of the paper we will instantiate the relation MT between transformations by using set inclusion relationship between their sets of rules Required Properties We require a transformation included in another transformation T to produce submodels of the ones produced by T. To this purpose we introduce the notion of rule additivity, linking the inclusion between transformations T 0 and T to the one between the models they produce, as below. Definition 6 (Rule Additivity). A model transformation language L U is rule additive for the inclusion relation MT between model transformations T 0, T : MM S MM T in L U, if for all models m s MM S, T 0 MT T implies T 0 m s M T m s. Property 1 (Rule additivity of Model Transformation Language). L U is rule additive. Rules may further contain components like bindings in ATL, as we instantiate in Sec Even in such a case, we call this relation rule additivity for simplicity. Rule additivity of the unidirectional language is a key property of our approach, since we base on it our notion of partiality of the bidirectionalization. Formally, a projection function will be used to extract the part of the transformation that we are able to fully translate. 20

22 Definition 7 (Model Transformation Projection (Π)). A function Π : L U L U is called model transformation projection if ΠT MT T for T L U. Since ΠT MT T, rule additivity of L U implies ΠT m M T m for T L U. In other words, for rule-additive languages a model transformation projection produces submodels of the original transformation, providing a clean decomposition of the L U and L B output. Given relation R MM T MM T s.t. m 0 M m (m 0, m) R, rule additivity can be represented by the diagrams on the right. The two diagrams have the same meaning but we use both in the discussion of Def. 8, the first one directly, and the second one (with a double arrow M notation) indirectly by MM S (ΠT ) T R MM S T ΠT MM T M MM T referring the shape of the diagram. Notice the difference between MM T and MM T. Since the target models produced by the projected transformation may lack some model elements or features because of the partiality, the corresponding metamodel should be relaxed to allow the absence of these elements and properties. We do this by changing all the mandatory features to optional (and likewise the lower bound of multiplicity constraints to zero). To avoid clutter we do not make these differences explicit in the rest of this paper. Next we need a strongly invertible (Diskin et al., 2011b) mapping between models and graphs, i.e., we need the pair of model to graph translation M G : GS MM GS and graph to model translation M G : (GS )GS MM to form a bidirectional transformation where GS represents graph schema. takes as input the original graph (i.e., the graph before the M G conversion), in addition to the (possibly updated) model, while M G may take the original graph as additional input, if any. In this bidirectional transformation, M G corresponds to forward transformation and M G to backward transformation satisfying the following: Property 2 (Bidirectional transformation between Models and Graphs). M G M G g ( M G g) G g (MGGetPut) 21

23 ( M G ( M G m)) M m (MGCreateGet) ( M G ( M G g m)) M m (MGPutGet) M G g ( M G g g ) G g (MGDGetPut) where G denotes graph equivalence (isomorphism) and M denotes equivalence between models as isomorphism of node-attributed graphs. MGCreateGet corresponds to the case where the original graph is not available. In this case, node identities in the graph are generated by M G arbitrarily but MGCreateGet ensures that the model m is recovered by M G.5 It corresponds to strong invertibility in Diskin et al. (2011b). The graph isomorphism is not easy to decide in general, so we assume a distinguished attribute in the model element to uniquely identify the element, and that the identifier is translated bijectively through M G and M G. In the rest of the paper, we simply use = instead of M assuming these identifiers. For the transformation produced by projection, we require the soundness of the translation of the transformation: given model transformation T : MM S MM T, translation : L U L B from model transformation to graph transformation, model to graph translation M G, graph to model translation M G, and translated forward graph transformation F [ T ]] : GS S GS T, where GS S and GS T represent source and target graph schema, respectively, we require that if we convert source model to graph, perform the graph transformation, and convert back to model, that is the same as directly transform the source model by model transformation. Property 3 (Soundness of Total Translation). T L U and T L B satisfies T = M G F [ T ]] M G. 5 MGDGetPut is similar to the property of Asymmetric Delta Lens by Diskin et al. with dget as variation of get, and in the opposite direction. 22

24 It can be represented by the diagram on the right. It is worth noting that when T is an identity transformation, it still holds by MGCreateGet in Property 2. MM S T M G GS S F [ T ] MM T M G GS T Partial translation on T L U is implemented as ΠT. Consequently, the range of Π should be within the domain of, i.e., ran(π) dom( ). Finally, we require that L B is well-behaved (Def. 1). Property 4 (Well-behavedness of underlying bidirectional graph transformation). Given a graph transformation t L B, the pair of its forward and backward semantics F[[t]] : GS S GS T, B[[t]] : GS S GS T GS S is well-behaved. M 5 G MM S T0=ΠT 1 T M G MM T MM T 2 UMMT GS S 6 F[ T0 ] GS T U MMT M MM T 3 B[T ](, )MMS (13) M G 8 MM S 7 B[ T0 ](, ) 9 (14) T U MMT M 4 M G T 0 GS T MM T MM T M G (11) B[T0 ](, ) MMS (10) MM T B[ T 0 ](, ) (12) B[ T0 ](GS S, ) GS S F[ T 0 ] GS T Figure 6: Commuting diagram for bidirectional transformation based on partial translation of model transformation T 4.3. Proof of Well-Behavedness We then construct the bidirectional model transformation. The forward transformation is simply T L U. For backward transformation, we need the 23

25 following notion of model restriction to translate updates on models to those on its submodel w.r.t. the submodel before the update. Definition 8 (Model Restriction). Restriction of model m 1 MM with m 2 MM, denoted by m 1 m2, is a submodel of m 1 induced by the subset of nodes (model elements) in m 1 that have nodes in m 2 with matching identifiers. Since the restriction is computed by inducing using identifiers 6, the restriction maintains (i.e., as a semi-maintainer by Meertens (1998)) the submodel relation M by satisfying the following properties: m 0 M m m m0 = m 0 m m0 = m 0 m 0 M m (RHippo) (RCorrect) The former says that the restriction with its submodel yields the submodel itself, or equivalently, if there is no update on the model, no update is translated to its submodel, and the latter says that the result of restriction is a submodel of the updated model. The former corresponds to Hippocraticness and the latter to Correctness by Stevens (2010). Based on RHippo and RCorrect, with respect to its submodel, the submodel relation holds between models before and after the restriction operation. Given relation R M MM MM s.t. m 0 M m (m 0, m) R M, RHippo can be represented by the first commuting diagram below: 7 starting from a pair (m 0, m) R M, the upper path yields (π 1 (m 0, m), π 2 (m 0, m)) = m m0 while the lower path yields π 1 (m 0, m) = m 0. With a slight abuse of the notation to simplify the object at the top of the diagram (R M ), we let the restriction operator takes the second argument from the bottom (MM ), instead 6 Though this definition disregards model element insertion, it can be easily extended by allowing additional access to the model before update, say, m 1, and define the restriction to be m 1 \ ( m 1 \ m 2 ). 7 The direction of the arrow is different between the inclusion morphism and restriction computation. Also note that the arrow in the commuting diagram is drawn between metamodels, while the inclusion morphism used to define M would be drawn between models. 24

26 of the first component at the top, which is equivalent (both are m 0 ), obtaining the second diagram below. π 1 π 2 R M MM π 1 R M MM R M MM If we combine this diagram with the first diagram of rule additivity, we obtain the first commuting diagram below. By the property of, the diagram is simplified to obtain the second diagram. π 2 MM T (ΠT MM ) T π 1 S R M MM T MM ΠT S MM T We further require that the part of the target exclusively generated by L U π 2 π 1 T MM T is not updated by the user. Given this requirement, the restriction operator satisfies the following property 8. m, m 0 MM. m, m 0 MM. m 0 M m m 0 M m m \ m 0 = m \ m 0 m m0 = m 0 (restrict) It says that, when restriction operation of the model m with respect to its original submodel m 0 is carried out with updates in which the residual part of the submodel (m \ m 0 ) is kept unchanged yields its submodel. The restriction m 1 m2 operator is instantiated for each data model of the model transformation language. Now we define the backward model transformation. Definition 9 (Backward Model Transformation). Given source model m s MM S, updated target model m t MM T, T L U, its projector Π, model to graph transformation M G, graph to model transformation M G, : L U L B and backward graph transformation B[[ ]](, ) : GS S GS T GS S, the backward 8 A useless operator which, when there is an update, always returns empty model would satisfy RHippo and RCorrect. This property excludes such case. 25

27 model transformation B[[T ]](, ) : MM S MM T MM S is implemented by B[[T ]](m s, m t) = M G (B[[ ΠT ]](g s, M G (F[[ ΠT ]]g s, m t (ΠT )ms ))) where g s = M G (m s) Given the previous definitions, bidirectional model transformation in the global system can be performed by the concrete sequence of steps shown below. 1. Perform forward model transformation T m s to get m t. 2. Update m t to m t with m t = u m t, where u U MM is an update function on models that conform to metamodel MM. 3. Compute the restriction m t T0m s where T 0 = ΠT. 4. Obtain g t by converting the restricted model to graph with M G. 5. Obtain g s = M G m s. 6. Perform forward graph transformation F [ T 0 ]]g s to obtain trace information needed for the next step. 7. Perform backward graph transformation B [ T 0 ]](g s, g t) to obtain g s. 8. Obtain the updated source model m s as M G g s. 9. As post processing, perform forward model transformation T m s to get m t as the final updated target model, which may be different from m t 9. The following lemmas hold on the system built using the backward transformation in Def. 9. Lemma 1. Given L U and L B with Properties 1, 2, 3 and 4, the pair of T L U and backward model transformation B[[T ]](, ) as defined by Def. 9 satisfies the GetPut property. 9 m t and m t may disagree when forward transformation duplicates part of the source model while user updates only one of the duplicates (handled as explained in the paragraph following Theorem 1 and in footnote 6). We take m t WPutGet ensures that m t and m t as the final updated target model in this case. has the same effect in updating source model. 26

28 Proof. We show B[[T ]](m s, T m s ) = m s. LHS = { Def. 9, T 0 = ΠT } M G (B[[ T 0 ]]( M G (m s), M G (F[[ T 0 ]] M G (m s), T m s T0 m s ))) = { T 0 m s M T m s (Property 1), (RHippo) } M G (B[[ T 0 ]]( M G (m s), M G (F[[ T 0 ]] M G (m s), T 0 m s ))) = { T 0 = M G F[[ T 0 ]] M G (Property 3) } M G (B[[ T 0 ]]( M G (m s), M G (F[[ T 0 ]] M G (m s), M G (F[[ T 0 ]] M G (m s))))) = { Property 2(MGGetPut) } M G (B[[ T 0 ]]( M G (m s), F[[ T 0 ]] M G (m s))) = { Property 4(GetPut) } M G (M G (m s)) = { Property 2(MGCreateGet) } m s = RHS Lemma 2. Given L U and L B with Properties 1, 2, 3 and 4, the pair of T L U and backward model transformation B[[T ]](, ) as defined by Def. 9 satisfies the WPutGet property. In this proof, we use shorthands and for M G and M G, to avoid clutter. Proof. We show B[[T ]](m s, m t) = B[[T ]](m s, T (B[[T ]](m s, m t))). Let 27

29 g t = F[[ T 0 ]] m s. RHS = { Def. 9, T 0 = ΠT } B[[T ]](m s, T ( (B [ T 0 ]]( (m s ), (g t, m t T0 m s ))))) = { Def. 9, T 0 = ΠT } (B[[ T 0 ]( m s, (g t, T ( (B[[ T 0 ]]( m s, (m t T0 m s )))) T0 m s ))) = { Property 1, Property restrict } (B[[ T 0 ]( (m s ), (g t, T 0 ( (B[[ T 0 ]]( (m s ), (g t, m t T0 m s ))))))) { } Property 2(MGDGetPut, i.e., ( gt ) ( g t ) = id ) and Property 3, i.e., F[[ T 0 ]]= T 0 = (B[[ T 0 ]( (m s ), F[[ T 0 ](B[[ T 0 ]]( (m s ), (g t, m t T0 m s ))))) = { Property 4(WPutGet) } (B[[ T 0 ]( (m s ), (g t, m t T0 m s ))) = { Def. 9, T 0 = ΠT } LHS It is now obvious that L U on top of L B is well-behaved. Theorem 1 (Well-behavedness of Model Transformation). Given L U and L B with Properties 1, 2, 3 and 4, the pair of T L U and backward transformation B[[T ]](, ) defined by Def. 9 is well behaved. Proof. The pair satisfies the GetPut and WPutGet properties by Lemma 1 and Lemma 2. Theorem 1 and other related properties can be concisely illustrated by the commuting diagram in Fig. 6 by composing the diagrams we have presented so far. We try to render the same kind of arrows in parallel. In the diagram, the front plane represents the graph technical space, while the back plane represents the model technical space. Artifacts are converted between the two technical spaces by M G and M G. WPutGet in the graph technical space (Prop. 4) can be represented by the commuting triangular diagram at the bottom of the front 28