<figure><img src="image_1.png" /></figure>

HAL
open science

# Partial Bidirectionalization of Model Transformation Languages

Soichiro Hidaka, Massimo Tisi

<figure><img src="image_2.png" /></figure>

## To cite this version:

Soichiro Hidaka, Massimo Tisi. Partial Bidirectionalization of Model Transformation Languages. MODELS '24: ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems, Sep 2024, Linz, Austria. pp.1-12, 10.1145/3640310.3674083. hal-05124577

HAL Id: hal-05124577

https://hal.science/hal-05124577v1

Submitted on 22 Jun 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_3.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Partial Bidirectionalization of Model Transformation Languages

Soichiro Hidaka

hidaka@hosei.ac.jp

Hosei University

Koganei-shi, Tokyo, Japan

Massimo Tisi

massimo.tisi@imt-atlantique.fr

IMT Atlantique, LS2N (UMR CNRS 6004)

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 behavior is generally considered more difficult to formulate and predict compared to the unidirectional case. In the bidirectionalization approach, 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. When possible, full bidirectionalization is desirable, but far from trivial.

In this paper we propose a partial bidirectionalization approach, by partial compilation of a unidirectional language into a bidirectional language, and coupled execution of the two language engines. Forward transformation is still complete, whereas the target updates that can be back-propagated are deletions and modifications of a well-defined part of the target model. While the extent of the bidirectionalization depends on the two coupled systems, in this paper we provide a general combination scheme and we briefly discuss its well-behavedness. Then we use our technique to bidirectionalize the ATL model-transformation language on top of the GRoundTram bidirectional graph-transformation system.

## CCS CONCEPTS

* Software and its engineering → Model-driven software engineering; Abstraction, modeling and modularity; Interoperability; Domain specific languages; Consistency.

## KEYWORDS

Model Transformation, Bidirectional Transformation, Bidirection- alization, Runtime Interoperation, Transformation Engines

### ACM Reference Format:

Soichiro Hidaka and Massimo Tisi. 2024. Partial Bidirectionalization of Model Transformation Languages. In *ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems (MODELS '24), September 22-27, 2024, Linz, Austria*. ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/3640310.3674083

## 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 [8]. Transformation engines apply such rules to automatically generate new models or update existing ones, keeping the 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 [4, 6, 9, 13, 15, 21, 25, 27, 29, 36, 38, 40, 48, 52]. 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 [11]. 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.

An alternative approach for the application of unidirectional transformation languages to bidirectional scenarios is the *bidirectionalization* of the unidirectional language [36, 48]. In this approach, users write one direction of the transformation by using the unidirectional transformation language they are used to. In both cases, 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 — bidirectionalization of unidirectional model transformations in its full set of the language — is in general not possible without imposing restrictions to model transformation languages, and existing work (e.g., [42]) mainly focused on extending the part of the unidirectional language that is bidirectionalized. Also note that the existing methods [36, 48] mentioned above do not target a model transformation language.

In this paper we take an approach similar to Sasano et al. [42] in that we use existing unidirectional model transformation languages as surface languages for transformation programmers, use automatic translation of the surface languages to existing bidirectional transformation languages and use the engine of the bidirectional language to propagate changes on the target models to the source models. However, in Sasano et al. [42] the expressiveness of the surface language in its forward direction was already limited to the part of the unidirectional language that was bidirectionalized, i.e.,

<footnote>Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).
MODELS '24, September 22-27, 2024, Linz, Austria
© 2024 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-0504-5/24/09
https://doi.org/10.1145/3640310.3674083</footnote>
the domain of the total translation that was used for bidirectional-
ization. The engine of the bidirectional language was responsible
for the forward direction, not just the backward direction. There
was no other way than to maximize the extent of the bidirection-
alization in order to relax the limitation in the forward direction.
Instead we propose a coupled<fnref n="1" /> execution of unidirectional and bidi-
rectional transformation engines to overcome the limitation. We
do no longer have to maximize the extent of the bidirectionaliza-
tion just to restore expressiveness in the forward direction. In our
approach, the user writes a unidirectional transformation in an
existing unidirectional language, and the unidirectional transfor-
mation engine performs the complete forward transformation with
its full expressiveness. A transformation compiler translates part
of the unidirectional transformation into an equivalent transfor-
mation 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.

Compared with related work, our approach: 1) does not require syntactic restrictions (as in Sasano et al. [42]) to the forward transformation language as long as the language satisfies the additivity property [19]; 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 (as in Xiong et al. [52]) to any of the two engines involved; 4) exhibits a easily user-predictable behavior (formally it satisfies a variation of well-behavedness property from Czarnecki et al. [7] which was not thoroughly discussed in Sasano et al. [42]).

We exemplify the proposed approach by building a bidirection-
alized version of the ATL model transformation language [23], on
top of the GRoundTram [16, 17] bidirectional graph-transformation
system by partially translating ATL to UnQL [5], the graph transfor-
mation language bidirectionalized [15] in the GRoundTram system.
The resulting tool is a contribution of its own and its source code
is freely available at the paper page.<fnref n="2" />

The paper is structured as follows: Section 2 introduces back-
ground and a running case for the paper; Section 3 describes the
approach and its application to the running case; Section 4 details
our integration of ATL and GRoundTram; Section 5 evaluates our
proposal; Section 6 compares the approach with related work and
Section 7 concludes the paper.

2 RUNNING CASE AND BACKGROUND

## 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 the trans-
formation between two well-known models [26]: a UML class dia-
gram and a relational schema. We can imagine, e.g., that the class
diagram is modeling the code of 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 transforma-
tion computes which tables and columns to produce for each UML
element. Figures 1a and 1b show the source and target metamodels
of the transformation<fnref n="3" /> in the MOF notation, and Fig. 3 two sample
corresponding models.

We suppose that both class model and relational schema may
be manually edited during the application development or main-
tenance, depending on the user background (software architect or
database expert) or the preferred tool (UML editor or database edi-
tor). An automated transformation system should make sure that
class model and relational schema are always synchronized. Hence
our scenario requires an MMT system working in two directions.

We propose to address the two synchronization 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 [23].

**Backward:** Part of the forward transformation is transpar-
ently 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 [15–17].

## 2.2 Specifying model transformations in ATL

In a first phase, the user develops in the ATL<fnref n="4" /> language the simple Class2Relational MMT in Listing 1.<fnref n="5" /> 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. Within each transformation rule, all expressions are written in the Object Constraint Language (OCL) [51]. Rules are composed of an *input pattern* and an *output pattern*. Input patterns (e.g. lines 5-6 and 13) are associated with OCL *guards* (e.g. line 6) that impose matching conditions on the input elements. Output patterns (e.g. lines 7-9 and 14-15) are associated with *bindings* (e.g. lines 8, 9 and 15), OCL expressions that define how to initialize properties of the elements created by the matched rule.

Rule Class2Table (lines 12-16) creates a table for each class, and
names it like the corresponding class. Rule Package2Schema (lines
4-10) transforms all non-empty packages into relational schemas
and initializes their list of tables. Source elements that are not
matched by any transformation rule (e.g. instances of **Attribute**
and **DataType**) are implicitly ignored.

<footnote n="1">¹Our coupling approach may be considered as a new pattern of coupled transformations, in the sense of Lämmel [30].</footnote>

<footnote n="2">²https://github.com/atlanmod/ATLGT.</footnote>

<footnote n="3">³The metamodels are adapted from the Class2Relational case study [26], which have important semantic differences with respect to full class diagram and relational schema metamodels. We perform further simplifications, in order to have minimal transformation rules in the following.</footnote>

<footnote n="4">⁴In this paper the term *ATL* refers to its rule-based declarative fragment of the entire ATL transformation language. The ATL engine supports also the execution of imperative instructions that we do not consider.</footnote>

<footnote n="5">⁵This transformation code is inspired by the ATL solution [26] to the Class2Relational case study [3], but simplified and adapted for illustrative purpose. Notably this version of the transformation does not support multivalued attributes.</footnote>
<figure><img src="image_4.png" /><figcaption>Figure 1: Metamodels of the case study</figcaption></figure>

```pascal
module Class2Relational;
create OUT : Relational from IN : ClassDiagram;

rule Package2Schema{
  from p:ClassDiagram!Package
  (not p.ownedElements.isEmpty())
  to out:Relational!Schema
  (name <- p.name,
   ownedElements <- p.ownedElements)
}

rule Class2Table {
  from c:ClassDiagram!Class
  to t:Relational!Table
  (name <- c.name)
}
```

<caption>Listing 1: Class2Relational in ATL (first version)</caption>

```pascal
select
letrec sfun ownedElements_Package2Schema({ownedElements:$g}) =
  {ownedElements:Class2Relational($g)}
| ownedElements_Package2Schema({$l:$g}) = {}
and sfun (* main function *)
Class2Relational({Package:$g}) =
  if (not empty{select {dummy:{T}} where {ownedElements:
      $e} in $g})
  then {Schema: (ownedElements_Package2Schema($g)
    U (select {name:$n} where {name:$n} in
      $g))}
  else {}
| Class2Relational({Class:$g}) =
  {Table: (select {name:$n} where {name:$n} in $g)}
| Class2Relational({$l:$g}) = {}
in Class2Relational($db)
```

<caption>Listing 2: Class2Relational in UnQL (first version)</caption>

Note that ATL rules implicitly interact for generating cross-references among target model elements. For example, at line 9 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 [23].

<figure><img src="image_5.png" /><figcaption>Figure 2: Syntax of UnQL</figcaption></figure>

## 2.3 GRoundTram

GRoundTram is an integrated framework for developing well-behaved bidirectional transformations expressed in the language UnQL+ [17, 18], which extends UnQL [5] to support more user-friendly syntactic sugar. This paper does not depend on this extension, and the listings are in simple UnQL. Fig. 2 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 optional bindings (`B`), and structural recursion (`sfun`) consisting of multiple clauses `fname({L:$g}) = T` separated by `|`. Bindings include graph pattern matching (`Gp` in `$g`) and Boolean conditions (`BC`). Conditions include usual logical connectives, label equality and emptiness check `isEmpty(T)` which is false if and only 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. The transformation consists of a `select` query without bindings with structural recursion functions (`sfuns`) as its template. Note that when the binding of `select` is omitted, select `T` and `T` have the same meaning. In the listing, the last definition (function `Class2Relational` at lines
```sql
rule Class2Table {
    from c:ClassDiagram:Class
to t:Relational:Table
    (name <- c.name, col <- c.attr.
     key <- c.attr->select(a | a.name.endsWith('Id')) )
}

rule DataType2Type {
    from d:ClassDiagram:DataType
    (ClassDiagram:Class.allInstances()
     -->select(c | c.name = d.name)--isEmpty())
to t:Relational:Type
    (name <- d.name)
}

rule SingleValuedAttribute2Column {
    from a:ClassDiagram:Attribute (not a.multivalued)
to c:Relational:Column
    (name <- a.owner.name+'-' +a.name,
     owner <- a.owner.
     type <- if a.type.oclIsTypeOf(ClassDiagram:DataType)
               then a.type else thisModule stringType endif )
}
```

<caption>Listing 3: Class2Relational in ATL (second version). In gray the parts that will not be translated to UnQL</caption>

5-14) 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-12). References between target elements are represented by definitions and calls of sibling mutually-recursive functions: `ownedElements_Package2Schema` is called at line 8 for the reference `ownedElements` in the rule `package2Schema` (lines 2-4). The 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. The predicate `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.

## 2.4 Partial Translation

The simple ATL rules in Listing 1 can be automatically translated to the equivalent UnQL code in Listing 2. But what if we need to translate arbitrary complex ATL rules? An ideal translator would be able to convert any ATL transformation into an UnQL transformation that is perfectly equivalent in the forward direction. Unfortunately, such an ideal translator from a unidirectional language to a bidirectional language is generally not available, and in our case it would be even unfeasible because of the difference in expressive power of the two languages, ATL and UnQL.

We exemplify this problem in a second phase of our use case: we imagine that a user extends the ATL transformation by adding the more complex rules in Listing 3. The resulting transformation

```sql
select
letrec sfun ownedElements_Package2Schema({ownedElements:$g}) = ...
and sfun col_Class2Table({attr:$g}) = {col:Class2Relational($g)}
| col_Class2Table({$l:$g}) = {}
and sfun owner_SingleAttribute2Column({owner:$g}) = {owner:
    Class2Relational($g)}
| owner_SingleAttribute2Column({$l:$g}) = {}
and sfun (* main function *)
    Class2Relational({Package:$g}) = ...
| Class2Relational({Class:$g}) =
    {Table: (... 
        Union col_Class2Table($g))
    | Class2Relational({Attribute:$g}) =
        if empty(select {dummy:})
            where {multivaluedITABoolean:$g'} in $g,
                {true:$d} in $g')
        then {Column:((select {name: {String: {$on ^ "-" ^ $n}}
            where {owner._name.String: {$on:$d}} in
                $g,
                {name.String: {$n:$d}} in $g)
        | owner_SingleAttribute2Column($g))}
        else {}}
    | Class2Relational({$l:$g}) = {}
    in Class2Relational($db)
```

<caption>Listing 4: Class2Relational in UnQL (second version)</caption>

is able to transform the models in Fig. 3, represented in abstract syntax as object diagrams.

Rule `Class2Table` is extended and now it initializes 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 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 applying our current ATL-to-UnQL translator (described in Section 4) the ATL transformation in Listings 1 and 3. The gray background in Listing 3 highlights the parts of the unidirectional transformation that are not handled by the translator. We show only the code that corresponds to Listing 3 (we omit by ellipses the code that is not changed w.r.t. Listing 1).

Among the clauses in the main function `Class2Relational` at lines 7-22 that corresponds to the ATL module `Class2Relational`, the clause for the ATL rule `SingleValuedAttribute2Column` (lines 12-20) is added, while the clause for `DataType2Type` is missing by the partiality of the translation. At the ATL 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.
<figure><img src="image_6.png" /><figcaption>Figure 3: Sample models in object-diagram syntax. Corresponding elements have the same position in the two models. As we discuss in Section 3, updates to elements with dashed lines are not backward-propagable.</figcaption></figure>

Similarly, in the clause for the rule `SingleAttribute2Column` (lines 12-20), no code is generated for type output pattern element.

We want to perform bidirectional synchronization of class diagram and relational schema by using `GRoundTram` and the existing `ATL-to-UnQL` translator. Because of the partiality of the `ATL-to-UnQL` translator, the bidirectional synchronization is not trivial. The forward direction is not problematic: every change the user performs to the class diagram can be propagated to the relational schema by simply running the `ATL` transformation again. The backward direction instead is more complex. After the user performs a change to the relational schema, it is not easy to be sure that the change will be correctly propagated to the class diagram. Intuitively, we expect some of the changes to be correctly backward-propagated by running the backward direction of `GRoundTram`. Other changes instead will be impacted by the missing code during the `ATL-to-UnQL` translation, possibly creating inconsistencies between the models. For the most problematic changes, we can expect that every time we execute the forward or backward direction we obtain a different model, so the synchronization never converges.

In the rest of the paper will propose an original way to connect the transformation engines and design the `ATL-to-UnQL` translator (and in general any unidirectional-to-bidirectional translator). Thanks to this design we can clearly identify which changes to the target model are correctly back-propagated, despite the partiality of the translation. For those back-propagable changes, the synchronization converges.

## 3 BIDIRECTIONALIZATION BY RUNTIME INTEROPERATION

Our strategy for bidirectionalization is to combine the execution of a popular and powerful unidirectional model transformation language with the execution of an existing bidirectional transformation language with well-defined bidirectional properties. A user writes a 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. For example, some approaches may prefer sub-Turing-complete expressiveness to achieve other desirable properties such as guaranteed termination of the transformation in both directions [20]. 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. 4 shows a global view on our approach. We run the unidirectional (UX in the figure) and bidirectional (BX in the figure) transformations 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 providing a general method to keep the two transformation systems consistent with each other. In the Class2Relational example, thanks to such synchronization a user will be able to generate the relational model in Fig. 3a, to update it (e.g., by renaming a table or removing 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 the UX technical space. When the transformation languages have different data models, we suppose to have an invertible transformation (in the sense of strong invertibility [10]) between these data models (UX to BX Data Model). In our case study, `ATL` transforms models (i.e., typed, attributed and directed graphs) as the ones presented in Fig. 3. The graphs transformed by `GRoundTram` are rooted and edge-labeled. Here we use the encoding of models in `GRoundTram` described in previous work [17, 18].

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). The generation is loosely-coupled [22] in the sense that the transformation logic remains unchanged while the identifier-generation logic is injected transparently via the *Tracer* higher-order transformation (HOT) [47]. The resulting transformation (UX w/ Traces) is executed
<figure><img src="image_7.png" /><figcaption>Figure 4: Overview of the approach. Models are rectangles, transformations are rounded rectangles and HOTs are double rounded rectangles. Incoming/outgoing arrows represent respectively input/output flows of artifacts (i.e., input/output models of transformations and input/output transformations of HOTs).</figcaption></figure>

```xml
rule Class2Table {
  from c:ClassDiagram!Class
  to t:Relational!Table
  (name<-c.name, col<-c.attr,
   key<-c.attr->select(a | a.name.endsWith('Id')),
   __xmiID__ <- 'IN'.concat(c.__xmiID__.concat('.Class2Table.t')))
}
```

<caption>Listing 5: Class2Table with identifier injection in ATL</caption>

```xml
select
  letrec sfun col_Class2Table({attr:$g}) = {col: Class2Relational($g)}
  | col_Class2Table({$l:$g}) = {}
  and sfun (* main function *)
  | Class2Relational({Class:$g}) =
      {Table:((select {name:String:$n} where {name_:$n} in $g)
        U col_Class2Table($g)
        U (select {xmi_id: {String: {"IN""$id"".Class2Table.t"
          ):{}}}
          where {xmi_id_:_{$id:$dummy}} in $g) ))
  | Class2Relational({$l:$g}) = {}
  in Class2Relational($db)
```

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 the Class2Relational 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 w/ Traces*: w.r.t. the version in Listing 3 the injected binding at line 6 (highlighted) assigns an identifier to the newly created table, computed by concatenating the identifier of the source model ('IN'), 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 language by a partial translator (*UX to BX Partial Transl.*). It is important to note that **the translator must be able to translate the identifier generation logic injected in the unidirectional transformation to the bidirectional transformation language, generating identical model element identifiers (BX - Fwd Dir. w/ Traces).** In this way we are able to retrieve corresponding elements in the two technical spaces by coinciding identifiers. In the running example, Listing 6 is translated from Listing 5. The only difference w.r.t. Listing 4 are the highlighted lines 8-9 that generate the new id of the model element, being the direct translation of line 6 in Listing 5.

In the Class2Relational example, the gray background in *Listings* 3 highlights the partiality of the *UX to BX Partial Transl.* at

<caption>Listing 6: Class2Table with identifier injection in UnQL</caption>

both the rule level and the binding level. ATL rules with complex guards are not translated to 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 complex bindings are not translated: 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 are not supported by our 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 by the bidirectional transformation must be submodels of the target models of the corresponding unidirectional system (see Section 4).** Intuitively, the property 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 Fig. 3b 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,
<figure><img src="image_8.png" /><figcaption>Figure 5: Syntax of the filtered subset of ATL</figcaption></figure>

DataType2Type rule, type binding, key binding). Submodel 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.

At this point the system allows the user to perform updates to the propagable part of the target model (Target Update). We currently support only deletions and modification of the propagable part. After target updates the backward direction of Fig. 4 starts by 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 Dir. w/ Traces) to create an Updated Source Model, by taking into account the original source model, target submodel and updated version of the target model, and maintaining the identifier correspondence. Finally the Updated Source Model is translated to the UX technical space, and shown to the user as the output of the backward transformation.

# 4 ATL ON GROUNDTRAM

We apply our approach to the integration ATL and GRoundTram. Models are EMF models conforming to Ecore metamodels serialized in XMI format, graphs are edge-labeled graphs [5] conforming to the KM3 [24] metamodel implemented as graph schema [18], serialized to GraphViz DOT format [17]. Invertible translations between models and graphs are taken from previous work [17, 18].

As we said in Section 3, the key property we want to guarantee in the translation is that target models generated by the bidirectional UnQL transformation are submodels of the target models of the original unidirectional ATL transformation. We achieve this in two steps. We first filter the full ATL transformation, to generate a transformation in the translatable subset of ATL, shown in Fig. 5. An ATL rule which is not a matched rule, or has an input pattern that does not match with the production rule inPat (e.g., its guard includes unsupported OCL such as a let expression) is entirely discarded. For each ATL rule that is not discarded, its sequence of bindings is filtered as follows. A binding whose OCL expression on the right hand side of ← does not match with the production rule oclExp (e.g., it includes unsupported OCL such as a let expression) is entirely discarded. Since both these filterings discard rules and bindings in their entirety, the filtered ATL transformation produces submodels of the original one (this general property of ATL is discussed in [19] as

additivity in the rule and binding contexts). Then, we fully translate the filtered ATL transformation to UnQL. Since the obtained UnQL transformation is equivalent to the filtered ATL in the forward direction, we obtain the desired outcome: the UnQL transformation produces submodels of the original ATL transformation.

For the full translation step we use an improved version of the translator of ATL to UnQL from our previous work [42]. We support a bigger subset of ATL than Sasano et al., and we include the translation of guards. The translated UnQL is more robust in the sense that cycles are better maintained, translation is metamodel-directed, and graph-model transformation is clearly defined based on XMI. Sasano et al. translated each ATL rule to a non-recursive query that is wrapped with singly-recursive query, which are sequentially composed to form the translated UnQL, like Class2Table followed by Attribute2Column. Due to the limitation of the structural recursion in UnQL, the inner non-recursive query could not activate unlimited recursive transformation steps for the connected model elements. We instead generate a flat structure of mutually recursive structural recursion for all ATL rules, so that each rule is translated to one clause of the common main structural recursion. Auxiliary sibling mutual structural recursions are also generated to "relay" the recursion of the main structural recursion beyond references.

The resulting translation generates the UnQL transformation in Listing 4 from the ATL in Listing 3, except that it is augmented with explicit model element identifier generation as in Listing 6 correspondingly to the id-generation logic like in Listing 5, and post-processing to eliminate edges encoding dangling references to untranslated model elements.

## 4.1 Partiality of the translation

In future work, we aim at reducing the partiality of the translation from ATL to UnQL, further extending the ATL subset in Fig. 5. Here we detail the reasons for such partiality and why it can not be completely eliminated. Note that several ATL features are not included in Fig. 5 (like rule inheritance and OCL helpers, useful to factorize commonly used OCL expressions) and not discussed in the following, as they may be in principle bidirectionalized but they are simply not yet supported at the current state of the translator.

**Expressive power.** The ATL language is Turing-complete [1], while UnQL is at most as expressive as first-order logic extended with transitive closure [5] albeit its termination properties (any transformation in UnQL terminates by construction, and any transformation in GRoundTram terminates in both forward and backward directions). This gap prohibits total translation from ATL to UnQL. Essentially no fragment that exceeds the expressive power can be translated.

**Bisimulation genericity of UnQL transformations.** The UnQL data model is based on bisimulation equivalence, where order and duplicates of subgraphs of a node is disregarded. Therefore, ordered features in the models cannot be (at least directly) encoded. To be consistent with this, every UnQL transformation is guaranteed to be bisimulation generic [5], meaning that it transforms any two bisimilar graphs to bisimilar graphs. Therefore, ATL transformation having order-aware OCL expressions like accessing first member of the ordered sequence is not translatable. For the same reason,
duplicate-aware transformation like counting of elements is not translated. Note that order sequence could be encoded. In this case, order-aware transformation would be possible based on such encoding. Note also that this restriction applies only at the transformation level. Duplicates of model elements are managed by XMI identifiers in our framework and duplicates introduced by the forward transformation in GRoundTram is removed by the built-in contractor.

**Recursions in OCL.** Even though UnQL has recursive functions traversing graphs, the recursion scheme is limited to the form of structural recursion function [5] *f* that satisfies the following equations.

$$ 
\begin{aligned}
f ( \{ \} ) &= \{ \} \\
f ( \{ l : g \} ) &= ( l, g ) \odot f ( g ) \\
f ( g_1 \cup g_2 ) &= f ( g_1 ) \cup f ( g_2 )
\end{aligned}
 $$

These equations show that *f* is a homomorphism. The function *f* returns empty graph for empty inputs (first equation). If the input is an edge labeled *l* connecting to subgraph *g*, *f* returns the final result by combining *l* and *g* and the result of the recursive call on *g* (second equation) by a certain $\odot$ operator<fnref n="6" />. If the input is the union of two graphs, then the result is the union of the recursive calls on these graphs (third equation).

The second equation suggests that recursive call is strictly limited to the subgraph (*g*) that is accessible from the target node of the edge (labeled *l*). Recursive calls like $f(\{a: \{b: g\}\})$ are disallowed. This restriction guarantees the termination of transformation in UnQL, producing finite graphs.

Moreover, the results of the recursive calls can only be used by constructors, and not passed as arguments to other functions or predicates. So $h(f(g))$ is disallowed. Such composition is only allowed outside of recursive calls. It is also worth noting that it is not permitted to call the outer functions from their nested inner functions, as in the following example. In this example, the function *g* defined inside the body of the function *f* calls *f*, which is illegal.

1. select

2. letrec sfun $f(\{a: $g\}) =$

3. letrec sfun $g(\{a: $g\}) = f($g)$

4. in $g($g)$

5. in $f($db)$

Therefore, an OCL expression containing recursions that do not fit into the above recursion scheme is not translatable.

**Cycle creation in transformation.** Creation of cyclic links may be used in model transformations, like the following cross-references among output elements in the *to* part in the rule.

from s1 : ...

to t1 : Relational (... t2 ...)

t2 : Relational (... t1 ...)

This pattern cannot be translated to original UnQL, since UnQL is unable to create cycles in general. More precisely, UnQL is not able to close a cycle in the transformation, while the above rule indirectly closes the cycle by connecting mutual references between t1 and t2.

**Multiple traversals from a node.** In ATL, model elements can be traversed multiple times, e.g., in output-pattern bindings as in the following one from Listing 3 line 19.

name <-s.owner.name +'_'+s.name

As long as these references access the values of primitive data types, they can be encoded as a single **select** construct, like

1. select {name: {String: {($s_1 ^ _ ^ $s_2):{}}}}

2. where {owner.name.String: {$s_1 : $dummy}} in $g,

3. {name.String: {$s_2 : $dummy'}} in $g

This translation performs multiple traversals from the same graph variables using multiple **where** clauses. If the original ATL binding traverses source model elements instead of primitive values, then this translation cannot be used. In this case, ATL automatically triggers other rules to convert these source model elements to target model elements. Encoding this behavior in UnQL requires structural recursion. So the traversal is implemented using sibling **sfuns**, the returned value from which cannot be traversed because of the limitation on structural recursions.

# 5 EVALUATION AND DISCUSSION

In this section we evaluate the proposed approach based on three dimension: we experimentally assess the amount of transformation code that can be bidirectionalized (Section 5.1), we give the main points of a formal proof of the well-behavedness of the global system (Section 5.2), and we discuss the applicability of our approach to other languages (Section 5.3).

## 5.1 Bidirectionalization extent

To test our framework and give a practical assessment of the extent of the bidirectionalization, we applied our approach to a corpus of ATL model transformations. The ATL transformation zoo<fnref n="7" /> lists 103 transformation projects. In total these projects include 256 distinct transformation files. Among these files we selected all the transformations that are treatable by our approach, i.e., standard ATL transformations with one input and one output model (ATL files can be also used to define queries, libraries, refining transformations and multi-model transformations, that are not supported). The result of this selection is a set of 126 transformations, with size that ranges between 15 and 5381 lines of code (LOCs), with average 422.40 LOCs and standard deviation 637.13 LOCs.

For each one of these transformations we measured the ratio among the LOCs of the bidirectional part, over the total LOCs of the original transformation. Fig. 6 shows a summary of the experimentation (the full results are available on the paper website<fnref n="8" />). We highlight some interesting aspects of the results:

* The part that can be automatically bidirectionalized by our approach is significant, amounting in average to the 32.88% of LOCs of the ATL files (min 0.13, max 100.00, stdev 31.25).

* A large set of transformations have a low bidirectionalization rate (43 transformations are bidirectionalized for less than 10% LOCs and 18 for 10%-20% LOCs). These are transformations that use complex OCL expressions throughout

<footnote n="6">⁶The $\odot$ operator corresponds to the body expression of the structural recursion operator *rec* in UnCAL which is the underlying graph calculus.</footnote>

<footnote n="7">⁷https://www.eclipse.org/atl/atlTransformations/</footnote>

<footnote n="8">⁸https://github.com/atlanmod/ATLGT/blob/master/docs/ATL_zoo_projections.csv</footnote>
<figure><img src="image_9.png" /><figcaption>Figure 6: Distribution of the transformations of the ATL zoo by percentage of bidirectionalized LOCs</figcaption></figure>

most rules, because of the complexity of the task and the experience of the programmer.

* Over the set of remaining transformations, the amount of bidirectionalization seems to be quite evenly distributed between 20% and 100% of the transformation LOCs.

In practice, our partially bidirectional ATL transformations are particularly useful for ATL users who need to back-propagate only updates to some properties (attribute values or links) of the target graph (i.e., no insertion of new target elements).

We are especially interested in applying partial bidirectional transformations to the engineering of digital twins, that we believe to be a particularly important application area today. In such use case: 1) ATL is used to encode a complex forward transformation from an abstract model of the structure and state of the digital twin to its concrete (e.g., 3D) representation; 2) at the runtime of the digital twin, the user wants to update only some attribute values (e.g., position and orientation of some physical elements) and links (e.g., connections among some physical elements) of the target model; 3) we want these changes to be back-propagated to the abstract models in a well-behaved way. Our current tool is applicable in this use case, since our ATL-to-UnQL translator is able to translate the UX code that produces the editable properties (in this case, they are simply derived from corresponding ones in the abstract model). After the back-propagation, the rest of the representation model is automatically updated by the complex UX transformation, and the framework guarantees global well-behavedness.

Finally, depending on the application, different solutions to manage edits on the non-bidirectionalized part are possible, i.e. manual implementation of the rest of the reversibility or manual back-propagation. However, we have not yet investigated how to mitigate the drawbacks of these solutions, hence we currently prefer to apply the approach where such edits can be disallowed.

## 5.2 Well-behavedness

In general it is desirable to produce transformation systems that are well-behaved [7], i.e. where a round-trip in the bidirectional transformation system does not have surprising effects. Formally, there are several variants of well-behavedness in literature and in this paper we use a weaker one. Given a bidirectional transformation specification as expression *t*, we denote its forward interpretation (forward semantics) by $\mathcal{F}[[t]]$ and its backward interpretation (backward semantics) by $\mathcal{B}[[t]]$, respectively. We use these notations to define well-behavedness.

**DEFINITION 1 (WELL-BEHAVEDNESS).** Given a transformation expression *t*, the pair of its forward semantics $\mathcal{F}[[t]]: S \to V$ which is a total function from source artifact (e.g., models or graphs) to target artifact, and its backward semantics $\mathcal{B}[[t]]: S \times V \to 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.

$$ \begin{aligned} \mathcal{F}[[t]]a_s &= a_t & \Rightarrow \mathcal{B}[[t]](a_s, a_t) &= a_s & (\text{GETPUT}) \\ \mathcal{B}[[t]](a_s, a'_t) &= a'_s & \Rightarrow \mathcal{B}[[t]](a_s, \mathcal{F}[[t]]a'_s) &= a'_s & (\text{WPUTGET}) \end{aligned} $$

$\text{GETPUT}$ [2, 12] says that if the forward transformation of a source artifact $a_s \in S$ results in the target artifact $a_t$, then the backward transformation without updating the target artifact results in $a_s$, i.e., no change on the target side leads to no change on the source side. $\text{WPUTGET}$ says that, if the backward transformation from $a'_t$ relative to the original source artifact $a_s$ results in $a'_s$, another backward transformation from the result of the forward transformation of the updated source artifact $a'_s$, relative to the same original source artifact $a_s$, results in the same updated source $a'_s$ again, i.e., the two target side updates — one from $a_t = \mathcal{F}[[t]]a_s$ to $a'_t$, and the other from $a_t = \mathcal{F}[[t]]a_s$ to $\mathcal{F}[[t]]a'_s$, — have the same effect on the source side. $\text{WPUTGET}$ can be observed in a language that allows forward transformation to duplicate part of the source model while user updates only one of the duplicates [14]. Such duplicates make $a'_t$ and $\mathcal{F}[[t]]a'_s$ differ. $\text{WPUTGET}$ [17] corresponds to Weak Invertibility by Diskin et al. [10] that is a weaker variant of $\text{PUTGET}$ [2, 12] that corresponds to Correctness [44].

We aim at showing that our global transformation system exhibits the well-behavedness property. For space limitations, here we give only the main ideas of the proof. We start by proving that well-behavedness of a coupled system (unidirectional model transformation in the language $\mathcal{L}_{UX}$ built on top of bidirectional graph transformation in the language $\mathcal{L}_{BX}$) is guaranteed if the system exhibit these four properties:

**Property 1: Additivity of $\mathcal{L}_{UX}$**. The unidirectional language $\mathcal{L}_{UX}$ has a particular modularity property, i.e. additivity, that requires a transformation syntactically included in another transformation *T* to produce submodels of the ones produced by *T* [19].

**Property 2: Invertible transformation between data models.**
We can build an invertible (in the sense of strong invertibility [10]) transformation between the data models of $\mathcal{L}_{UX}$ and the underlying bidirectional language $\mathcal{L}_{BX}$.

**Property 3: Soundness of the $\mathcal{L}_{UX}$ to $\mathcal{L}_{BX}$ translation.**
We can build a translator of part of a transformation in $\mathcal{L}_{UX}$ to $\mathcal{L}_{BX}$ such that 1) the models produced the (partial)
transformations in $\mathcal{L}_{UX}$ coincide with the ones produced by
the forward direction of corresponding transformations in
$\mathcal{L}_{BX}$, and 2) the *graphs* produced by the forward direction
of transformations in $\mathcal{L}_{BX}$ coincide with the ones produced
by the corresponding (partial) transformations in $\mathcal{L}_{UX}$.

**Property 4: Well-behavedness of L<sub>BX</sub>.** Any transformation written in L<sub>BX</sub> is well-behaved.

Intuitively, Property 1 introduces "partial" transformations (transformations syntactically included in others) in $\mathcal{L}_{UX}$, and guarantees that their output can be clearly identified in the output of the full transformation. Properties 2/3 allow for fully translating partial transformations to $\mathcal{L}_{BX}$. As a result, $\mathcal{L}_{UX}$ and $\mathcal{L}_{BX}$ can be executed in parallel and the well-behavedness of $\mathcal{L}_{BX}$ from Property 4 can be "lifted" to the whole system.

Then we show that these properties hold for our combination of
ATL and GRoundTram:

*Additivity of ATL (Property 1).* As we describe in Hidaka et al. [19], additivity of ATL can be derived by the informal specifications of ATL. Intuitively, ATL satisfies additivity because the more rules the transformation has, and the more output-pattern elements the rule has, the more target elements are included in the target model, and the more bindings each output pattern element has, the more features are assigned in the target model elements. Note that for each source element, no more than one rule is applied. If no rule is applicable to a source element, then no target element is produced from the source element. If more than one rule is applicable to a source element, then a run-time error occurs. Since the target model is not defined in such cases, such cases are not taken into account when reasoning about additivity. Instead, we start from a complete well-formed transformation and remove rules by projection.

*Invertible transformation between models and graphs (Property 2).*
This property is satisfied by the encoding of models as graphs in
previous work [17, 18].

*Soundness of the ATL to UnQL Translation (Property 3).* We show
that the target model created by GRoundTram through forward
transformation of translated UnQL is isomorphic to the target model
created by the ATL transformation.

*Well-behavedness of GRoundTram (Property 4).* This property is
already shown in Hidaka et al. [15, 17].

Since we have all the properties necessary to deduce well-
behavedness, we conclude that the entire bidirectional model
transformation system is well-behaved. □

The well-behavedness property of the combined system clearly
depends on the well-behavedness property of the BX system. In
this section we proved that if the BX system satisfies GETPUT and
WPUTGET, then the combined system satisfies the same properties.
We say that we "lift" these properties to the whole system. We
believe that other well-behavedness properties are lifted as well by
our approach, but we do not have corresponding proofs so far. We
are especially interested in coupling with BX systems that satisfy
PUTGET, or other stronger versions of WPUTGET. PUTGET implies
WPUTGET, hence it follows that this combined system satisfies
WPUTGET. However, we think that lifting (strong) PUTGET would

require an additional hypothesis on the information shared between
the translatable and untranslatable part.

Finally, while the weakness of WPUTGET may allow for undesired BX behaviors, usually those behaviors are avoided by specific choices in the design of BX languages/engines. In our approach, these choices of the BX engine are inherited by the combined UX/BX system.

**5.3 Applicability to other languages**

In this paper we present evidence of the practical applicability of
the approach to ATL and GRoundTram. While we intentionally
designed our system in order to respect the four properties given in
Section 5.2, they are generally not uncommon in model-driven engineering: Property 1 is satisfied by other UX model-transformation languages besides ATL (e.g., Epsilon ETL [28], CoqTL [46]); Property 2 is easily satisfiable because models can be represented as node-attributed edge-labeled graphs, and attributes of nodes can be represented as node labels, we can use well-known encoding of node-labeled graphs by edge-labeled graphs (for example, [see 5, Paragraph "Review of graph simulation and bisimulation" in Section 4.1 Value equivalence]) to encode models in low level representations; 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 is common among BX languages ([7, 39] for general arguments, and [53] for a more recent example).

**6 RELATED WORK**

Bidirectionalization [31, 32, 36, 37, 48–50] allows users to write
one direction of the transformation by using the unidirectional
transformation language they are used to. For example, Matsuda
et al. [36] find a backward transformation corresponding to the
given forward transformation, and Voigtländer [48] shows that
a backward transformation can be constructed from a forward
transformation. The two approaches are later combined [49, 50],
while Matsuda and Wang [37] (revisited later in this section) is an
extension of Voigtländer [48] in a sense. Full bidirectionalization
(bidirectionalizing full set of the language) of the unidirectional
model transformation is in general not possible without imposing
restrictions to the forward transformation language.

Related work on bidirectionalization of ATL (Sasano et al. [42], Macedo and Cunha [33] and Xiong et al. [52]) has an all-or-nothing approach. Only a subset of the ATL syntax is supported, and if a given ATL transformation does not fit in this subset, it is not bidirectionalized at all. The user may try to write an equivalent transformation using only the supported subset of ATL, but there is no guarantee that this is simple, or possible at all. Instead our approach does not impose restrictions to the declarative ATL/OCL syntax and library. A transformation that is not bidirectionalized at all by related work, would be partially bidirectionalized by our approach. More in detail, Sasano et al. [42] fully bidirectionalized a small (e.g., without guards) subset of ATL by translating it to bidirectionalized UnQL graph transformation [16, 17]. The subset of ATL supported by Macedo and Cunha [33] and by Xiong et al. [52] is not explicitly defined. Macedo and Cunha [33] state: "we
apply our bidirectionalization technique to a significative subset of ATL" and "non-unique lazy rules are currently not supported" [33]. In the paper, they show rule semantics only for rules with single input/output pattern elements. Xiong et al. [52] state that "only a small portion of the ATL standard library is supported".<fnref n="9" /> Since these tools are not maintained, they do not support any addition to ATL since 2010.<fnref n="10" /> While extending existing approaches to cover the full ATL is a valuable research subject, we want to introduce the idea of an alternative approach that embraces this partiality. The drawback of our proposal is that the bidirectionalizable part supported by our (current) ATL-to-UnQL compiler is limited (in average 32.88% in the ATL zoo). Both Macedo and Cunha [33] and Xiong et al. [52] can back-propagate more updates when the ATL transformation fits in their subset.

Changes to model-views [35] are made back-propagable by, e.g., Semeráth et al. [43]. This research area is closely related to transformation bidirectionalization. Semeráth et al.'s approach, as well as Macedo and Cunha [33]'s, are solver based, so they can enumerate multiple candidate source models that are consistent with the target model. Although we instantiated our approach using GRoundTram as our bidirectional transformation engine, which automatically return only one source model, we do not restrict the choice of the engine, provided that they can be integrated with its unidirectional counterpart, to satisfy the four properties described in Section 5.2. Again, existing approaches do not explicitly address partial support of the forward view language.

The idea of partially translating programs has been studied, for example by Pinter et al. [41] and Magnusson [34]. Magnusson's objective is to accelerate the execution of a sequential program by partially translating it to another intermediate representation, and the rest runs ordinarily. The control is passed between the two representations, so there is no overlap between the executions of the two representations. Performance improvement also motivated Pinter et al. [41], where the dynamic nature of the source language semantics prevented its total compilation before execution. In our setting, the original and the translated program run concurrently and the results are merged. Our objective is to bidirectionalize the source program, and we have provided an integration framework, in addition to a translation, between these two programs.

Matsuda and Wang [38], based on their previous work [37], integrated unidirectional and bidirectional part in a single language, while we aim at coordinating the execution of separate unidirectional and bidirectional languages.

Stevens [45] mentions partial transformation with a different meaning, since her partiality refers to the idea of tolerating imperfect consistency between source and target. Her notion of subspace is interesting; subspace is a subset of the domain or codomain of the transformation in which the user agreed to stay during update propagation. The subspace also characterizes the degree of consistency in that an element within a subspace is more/less compatible than the others outside the subspace. In our setting, the target subspace consists of the subset of the codomain covered by target models within which only the submodel created by the partially translated transformation is modified, because only the submodel is allowed

to be updated, though we do not use this subspace to characterize the degree of consistency. We disallow the modification outside of the subspace – Stevens’ partiality is not supported.<fnref n="11" />

# 7 CONCLUSION AND FUTURE WORK

We proposed to bidirectionalize unidirectional model transformation languages by partial compilation to bidirectional languages and coupled execution of the two language engines. Users can write the transformation in the unidirectional languages they are used to, while deletions and modifications on well-separated subregions of the target models are back-propagated by the bidirectional engine. Insertions in the target model are currently not supported.

We applied our approach to combine ATL and GRoundTram, but any other combination satisfying the properties described in this paper is possible. Application of the approach to new languages requires to develop a partial mapping from the unidirectional language to the bidirectional one. This requires in general a significant effort, depending on the chosen languages. The developer needs to clearly identify the translatable fragment and totally translate it. A small datamodel gap simplifies the translation.

In future work, we plan to extend the translatable part of ATL, experiment with different pairs of languages and use the properties of the approach to provide user-friendly feedback in model editors for bidirectional systems.

# ACKNOWLEDGMENTS

We thank Frédéric Jouault, Zheng Cheng and the members of IPL for their valuable comments and suggestions. This research was funded by the National Institute of Informatics and JSPS KAKENHI Grant 26330096, 15KK0017 (in conjunction with Zaigai Kenshuin system of Hosei University), 19H04088, 24K14903.

# REFERENCES

[1] Ahmad Salim Al-Sibahi. 2015. On the Computational Expressiveness of Model Transformation Languages. ITU Technical Report Series TR-2015-184 (2015).

[2] F. Bancilhon and N. Spyratos. 1981. Update Semantics of Relational Views. ACM Trans. Database Syst. 6, 4 (Dec. 1981), 557-575. https://doi.org/10.1145/319628.319634

[3] Jean Bézivin, Bernhard Rumpe, Andy Schürr, and Laurence Tratt. 2006. Model Transformations in Practice Workshop. In Satellite Events at the MoDELS 2005 Conference, Jean-Michel Bruel (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 120-127.

[4] Peter Braun and Frank Marschall. 2003. Transforming Object Oriented Models with BOTL. Electronic Notes in Theoretical Computer Science 72, 3 (2003), 103-117. https://doi.org/DOI:10.1016/S1571-0661(04)80615-7 GT-VMT'2002, Graph Transformation and Visual Modeling Techniques (First International Conference on Graph Transformation).

[5] Peter Buneman, Mary F. Fernandez, and Dan Suciu. 2000. UnQL: a query language and algebra for semistructured data based on structural recursion. VLDB Journal: Very Large Data Bases 9, 1 (2000), 76-110.

[6] D.M.J.B.J. Cretin, Nate Foster, and M.G.B.C. Pierce. 2010. Matching Lenses: Alignment and View Update. cis.upenn.edu (2010). http://www.cis.upenn.edu/~jbcpierce/papers/alignment.pdf

[7] Krzysztof Czarnecki, J. Nathan Foster, Zhenjiang Hu, Ralf Lämmel, Andy Schürr, and James F. Terwilliger. 2009. Bidirectional Transformations: A Cross-Discipline Perspective. In ICMT'09, 260-283.

[8] Krzysztof Czarnecki and Simon Helsen. 2006. Feature-based survey of model transformation Approaches. IBM Syst. J. 45, 3 (July 2006), 621-645. https://doi.org/10.1147/sj.453.0621

<footnote n="11">¹¹The WPUTGET property itself does tolerate imperfect consistency though, if the transformation duplicates (part of) model elements. To be perfectly consistent, these duplicates are simultaneously updated to the identical values, but the backward transformation accepts (tolerates) the update to identical values on only a subset of these duplicates.</footnote>

<footnote n="9">⁹https://xiongyingfei.github.io/modelSynchronization.html</footnote>

<footnote n="10">¹⁰https://wiki.eclipse.org/ATL/VM_Comparison</footnote>
[9] M.D. Del Fabro, B. Jézivin, F. Jouault, E. Breton, and G. Gueltas. 2005. AMW: a generic model weaver. In Proc. of the 1ères Journées sur l'Ingénierie Dirigée par les Modèles. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.1294

[10] Zinovy Diskin, Yingfei Xiong, Krzysztof Czarnecki, Hartmut Ehrig, Frank Herrmann, and Fernando Orejas. 2011. From State- to Delta-Based Bidirectional Model Transformations: The Symmetric Case. In MODELS'11. 304-318.

[11] Romina Eramo, Alfonso Pierantonio, and Gianni Rosa. 2014. Uncertainty in Bidirectional Transformations. In Proc. 6th International Workshop on Modeling in Software Engineering (MISE) (Hyderabad, India). ACM, 37-42. https://doi.org/10.1145/2593770.2593772

[12] J. Nathan Foster, Michael B. Greenwald, Jonathan T. Moore, Benjamin C. Pierce, and Alan Schmitt. 2007. Combinators for bidirectional tree transformations: A linguistic approach to the view-update problem. ACM Trans. Program. Lang. Syst. 29, 3 (2007).

[13] Holger Giese and Robert Wagner. 2008. From model transformation to incremental bidirectional model synchronization. Software & Systems Modeling 8, 1 (2008), 21-43. https://doi.org/10.1007/s10270-008-0089-9

[14] Soichiro Hidaka, Martin Billes, Quang Minh Tran, and Kazutaka Matsuda. 2015. Trace-based Approach to Editability and Correspondence Analysis for Bidirectional Graph Transformations. In Proc. 4th International Workshop on Bidirectional Transformations, L'Aquila, Italy, July 24 (CEUR Workshop Proceedigns, Vol. 1396). 51-65. http://ceur-ws.org/Vol-1396/p51-hidaka.pdf

[15] Soichiro Hidaka, Zhenjiang Hu, Kazuhiro Inaba, Hiroyuki Kato, Kazutaka Matsuda, and Keisuke Nakano. 2010. Bidirectionalizing graph transformations. In ICFP'10. ACM, 205-216.

[16] Soichiro Hidaka, Zhenjiang Hu, Kazuhiro Inaba, Hiroyuki Kato, and Keisuke Nakano. 2011. GRoundTram: An Integrated Framework for Developing Well-Behaved Bidirectional Model Transformations (short paper). In ASE'11 (Oread, Lawrence, Kansas, USA). IEEE, 480-483.

[17] Soichiro Hidaka, Zhenjiang Hu, Kazuhiro Inaba, Hiroyuki Kato, and Keisuke Nakano. 2013. GRoundTram: An integrated framework for developing well-behaved bidirectional model transformations. Progress in Informatics 10 (March 2013), 131-148. https://doi.org/10.2201/NiiPi.2013.10.7

[18] Soichiro Hidaka, Zhenjiang Hu, Hiroyuki Kato, and Keisuke Nakano. 2009. Towards a compositional approach to model transformation for software development. In SAC'09: Proceedings of the 2009 ACM symposium on Applied Computing (Honolulu, Hawaii). ACM, New York, NY, USA, 468-475.

[19] Soichiro Hidaka, Frédéric Jouault, and Massimo Tisi. 2017. On Additivity in Transformation Languages. In MODELS'17. 23-33. https://doi.org/10.1109/MODELS.2017.21

[20] Soichiro Hidaka, Massimo Tisi, Jordi Cabot, and Zhenjiang Hu. 2015. Feature-based classification of bidirectional transformation approaches. Software & Systems Modeling (2015), 1-22. https://doi.org/10.1007/s10270-014-0450-0

[21] Zhenjiang Hu, Shin-Cheng Mu, and Masato Takeichi. 2008. A Programmable Editor for Developing Structured Documents based on Bidirectional Transformations. Higher-Order and Symbolic Computation 21, 1-2 (2008), 89-118.

[22] Frédéric Jouault. 2005. Loosely coupled traceability for ATL. In ECMDA Traceability Workshop (ECMDA-TW). 29-37.

[23] Frédéric Jouault, Freddy Allilaire, Jean Bézivin, and Ivan Kurtev. 2008. ATL: A model transformation tool. Sci. Comput. Program. 72, 1-2 (June 2008), 31-39.

[24] Frédéric Jouault and Jean Bézivin. 2006. KM3: a DSL for metamodel specification. In 8th IFIP international conference on formal methods for open object-based distributed systems (Bologna, Italy) (LNCS, Vol. 4037). 171-185.

[25] Frédéric Jouault, Jean Bézivin, and Ivan Kurtev. 2006. TCS:: a DSL for the specification of textual concrete syntaxes in model engineering. In Proceedings of the 5th international conference on Generative programming and component engineering. ACM, New York, New York, USA, 254. https://doi.org/10.1145/1173706.1173744

[26] Frédéric Jouault and Ivan Kurtev. 2006. Transforming Models with ATL. In Satellite Events at the MODELS 2005 Conference, Jean-Michel Bruel (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 128-138.

[27] Hsiang-Shang Ko, Tao Zan, and Zhenjiang Hu. 2016. BiGUL: A Formally Verified Core Language for Putback-Based Bidirectional Programming. In Proceedings of the 2016 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation (St. Petersburg, FL, USA) (PEPM '16). ACM, New York, NY, USA, 61-72. https://doi.org/10.1145/2847538.2847544

[28] Dimitrios S Kolovos, Richard F Paige, and Fiona AC Polack. 2008. The epsilon transformation language. In Theory and practice of model transformations. Springer, 46-60.

[29] A. Königs. 2005. Model Transformation with Triple Graph Grammars. In Model Transformations in Practice Satellite Workshop of MODELS. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.2894&rep=rep1&type=pdf

[30] Ralf Lämmel. 2016. Coupled Software Transformations Revisited. In Proceedings of the 2016 ACM SIGPLAN International Conference on Software Language Engineering (SLE 2016). 239-252. https://doi.org/10.1145/2997364.2997366

[31] Dongxi Liu, Zhenjiang Hu, and Masato Takeichi. 2007. Bidirectional Interpretation of XQuery. In Proceedings of the 2007 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-based Program Manipulation (Nice, France) (PEPM '07).

ACM, New York, NY, USA, 21-30. https://doi.org/10.1145/1244381.1244386

[32] Dongxi Liu, Zhenjiang Hu, and Masato Takeichi. 2013. An expressive bidirectional transformation language for XQuery view update. Progress in Informatics 10 (March 2013), 89-129. https://doi.org/10.2201/NiiPi.2013.10.6

[33] Nuno Macedo and Alcino Cunha. 2016. Least-change bidirectional model transformation with QVT-R and ATL. Softw. Syst. Model. 15, 3 (Jul 2016), 783-810. https://doi.org/10.1007/s10270-014-0437-x

[34] Peter Magnusson. 1993. Partial Translation. Technical Report T93:05. The Swedish Institute of Computer Science.

[35] Kristóf Marussy, Oszkár Semeráth, and Dániel Varró. 2018. Incremental View Model Synchronization Using Partial Models. In MODELS'18 (Copenhagen, Denmark). ACM, New York, NY, USA, 323-333. https://doi.org/10.1145/3239372.3239412

[36] Kazutaka Matsuda, Zhenjiang Hu, Keisuke Nakano, Makoto Hamana, and Masato Takeichi. 2007. Bidirectionalization Transformation based on Automatic Derivation of View Complement Functions. In ICFP 2007 (Freiburg, Germany). 47-58.

[37] Kazutaka Matsuda and Meng Wang. 2015. Applicable Bidirectional Programming with Lenses. In ICFP 2015 (Vancouver, BC, Canada). 62-74. https://doi.org/10.1145/2784731.2784750

[38] Kazutaka Matsuda and Meng Wang. 2018. HOBIiT: Programming Lenses Without Using Lens Combinators. In Programming Languages and Systems, Amal Ahmed (Ed.). Springer International Publishing, Cham, 31-59.

[39] Keisuke Nakano. 2021. A Tangled Web of 12 Lens Laws. In Reversible Computation - 13th International Conference, RC 2021, Proceedings (Lecture Notes in Computer Science). Springer, Germany, 185-203. https://doi.org/10.1007/978-3-030-79837-6_11

[40] Object Management Group. 2008. Query/View/Transformation Specification. Version 1.0. http://www.omg.org/spec/QVT/1.0/

[41] Ron Y. Pinter, Pina Vortman, and Zvi Weiss. 1991. Partial Compilation of REXX. IBM Systems Journal 30, 3 (1991), 312-321. https://doi.org/10.1147/sj.303.0312

[42] Isao Sasano, Zhenjiang Hu, Soichiro Hidaka, Kazuhiro Inaba, Hiroyuki Kato, and Keisuke Nakano. 2011. Toward Bidirectionalization of ATL with GRoundTram. In ICMT (LNCS, Vol. 6707). Springer, 138-151.

[43] Oszkár Semeráth, Csaba Debreceni, Ákos Horváth, and Dániel Varró. 2016. Incremental backward change propagation of view models by logic solvers. In Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems (Saint-malo, France) (MODELS '16). Association for Computing Machinery, New York, NY, USA, 306-316. https://doi.org/10.1145/2976767.2976788

[44] Perdita Stevens. 2010. Bidirectional model transformations in QVT: semantic issues and open questions. Software and System Modeling 9, 1 (2010), 7-20.

[45] Perdita Stevens. 2014. Bidirectionally Tolerating Inconsistency: Partial Transformations. In Proceedings of the 17th International Conference on Fundamental Approaches to Software Engineering - Volume 8411. Springer-Verlag New York, Inc., New York, NY, USA, 32-46. https://doi.org/10.1007/978-3-642-54804-8_3

[46] Massimo Tisi and Zheng Cheng. 2018. CoqTL: An Internal DSL for Model Transformation in Coq. In Theory and Practice of Model Transformation, Arend Rensink and Jesús Sánchez Cuadrado (Eds.). Springer International Publishing, Cham, 142-156.

[47] Massimo Tisi, Frédéric Jouault, Piero Fraternali, Stefano Ceri, and Jean Bézivin. 2009. On the Use of Higher-Order Model Transformations. In ECMDA-FA'09 (Enschede, The Netherlands) (LNCS, Vol. 5562), 18-33.

[48] Janis Voigtländer. 2009. Bidirectionalization for free! (Pearl). In POPL '09: ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (Savannah, GA, USA). ACM, New York, NY, USA, 165-176.

[49] Janis Voigtländer, Zhenjiang Hu, Kazutaka Matsuda, and Meng Wang. 2010. Combining Syntactic and Semantic Bidirectionalization. In ICFP'10 (Baltimore, Maryland, USA). ACM, New York, NY, USA, 181-192. https://doi.org/10.1145/1863543.1863571

[50] Janis Voigtländer, Zhenjiang Hu, Kazutaka Matsuda, and Meng Wang. 2013. Enhancing semantic bidirectionalization via shape bidirectionalizer plug-ins. Journal of Functional Programming 23, 5 (2013), 515-551. https://doi.org/10.1017/S0956796813000130

[51] Jos B Warmer and Anneke G Kleppe. 1998. The Object Constraint Language: Precise Modeling With UML. Addison-Wesley Professional.

[52] Yingfei Xiong, Dongxi Liu, Zhenjiang Hu, Haiyan Zhao, Masato Takeichi, and Hong Mei. 2007. Towards automatic model synchronization from model transformations. ASE '07 (2007), 164. https://doi.org/10.1145/1321631.1321657

[53] Xing Zhang and Zhenjiang Hu. 2022. Towards bidirectional live programming for incomplete programs. In ICSE'22 (Pittsburgh, Pennsylvania). ACM, New York, NY, USA, 2154-2164. https://doi.org/10.1145/3510003.3510195