Keywords

1 Introduction

In model-driven development (MDD; see, e.g., [2, 3]), numerous models and transformations on different abstraction levels need to be taken into account. The high number of models involved originate from a layered modeling architecture (i.e. metamodels, MMs) as well as from refinements (i.e. transformations) from generic to implementation-centric model representations [4]. On the one hand, the need for model transformations is inherent to the abstraction mechanism in MDD to represent platform-specific concepts (e.g., statements in a programming language) as platform-independent models [5]. On the other hand, model transformation necessities stem also from, for instance, changes in MMs (e.g., changes from the original MM to a new MM are implemented by model-to-model transformations, M2M) or the support for multiple platforms (e.g., platform-specific textual representations, such as, source code or configuration and deployment documents, are provided by different model-to-text transformations, M2T).

MDD-based artifacts are frequently subject to change and evolve over time [6]. In most cases, the evolution of (meta)models and model transformations is a manual process [7]. Individually maintain and manually evolve MDD specifications is a tedious and error-prone task [8, 9]. For instance, consider an evolution of a MM and accompanying constraints. First, all instance models need to be migrated in order to conform to the new MM definition. Furthermore, all model transformations need to be adapted (e.g., due to model type changes). Moreover, tests need to be rewritten to check that the generated source code fulfills the specified constraints.

The artifacts which make up a MDD process (models, M2M/M2T transformations, model and transformation constraints etc.)—although highly interdependent—are autonomously maintained. Changes in one artifact (e.g., in a model) are not automatically reflected in other dependent artifacts (e.g., in a M2T transformation). The barrier for a tight integration of MDD-based artifacts stems from two limitations of current approaches: (1) Model transformations are unidirectional and changes can be propagated in one direction only (e.g., a model change is reflected in generated code); (2) changes can only be propagated into output artifacts of transformations (e.g., models), not into transformation definitions themselves.

In order to overcome these co-evolution problems, our approach, on the one hand, is based on (1) establishing bidirectional transformations (BX) between modeling artifacts (see, e.g., [8]). BX is a mechanism for maintaining the consistency of two (or more) related sources of information. A BX between two sources of information A and B (e.g., two different models) comprises a pair of unidirectional transformations: one from A to B (forward transformation) and another from B to A (backward transformation) [10].

On the other hand, we apply (2) higher-order transformations (HOTs) on first-class model representations of transformation specifications [11]. A HOT “is a model transformation such that its input and/or output models are themselves transformation models. [...] This demands the representation of the transformation as a model conforming to a transformation MM” [11].

In this way, we are able to propagate changes in two directions (1): From a source model to a target model and vice versa. These changes can be propagated into models on the same or on different abstraction levels. Furthermore, we ensure not only the co-evolution of models, but (2) model transformations, as well. We represent transformation definitions as models and are able to propagate changes into horizontal and vertical model transformations (i.e. transformations between models on the same and on different abstraction levels).

Our contributions are as follows:

  • A Method for MDD-based Co-evolution: Our approach of bidirectional higher-order transformation (B-HOT) for the co-evolution of model artifacts builds on former work [12–15]. This paper presents first enhancement steps which will allow for coupling, synchronization, and tracing of all model artifacts involved in a MDD process.

  • Integrated Tool Support: We provide initial prototypes for an integrated MDD-based tool support for B-HOTs via the Eclipse IDE. Our implementations build on well-established MDD tools (e.g., Eclipse EMF [16], ATL [17], Epsilon [18])Footnote 1.

  • Conformance between BX and MDD: To facilitate reproduction and transferability, we present an approach independent of any transformation language and we prepare for generalizations according to OMG specifications, for example, MOF [19], QVT [20], MOFM2T [21]. Besides integrated BX and MDD tooling, we also want to contribute to establish a common terminology to bridge the gap between the BX and MDD communities [10, 22].

The remainder of this paper is structured as follows. Section 2 reviews traditional model-driven architectures and explains why current approaches cannot sufficiently cope with the co-evolution of multiple MDD-based artifacts. Section 3 describes our approach to overcome the shortcomings of current methods. Requirements of our approach are discussed in Sect. 4. Our initial MDD-based developments are briefly explained in Sect. 5. Section 6 concludes the paper by discussing implications and mentioning limitations of our approach as well as pointing to ongoing and future work.

2 Current Approaches

A traditional model-driven architecture (MDA), as proposed by the OMG [23, 24] and as supported by a variety of tools, is sketched in Fig. 1. MMs provide the reference frame to which instance models must conform to, for example, a UML class model conforms to its MM defined in the UML specification [25]. M2M transformations are applied over one or more input models with the purpose of generating one or more output models conforming to the same or different MMs. A typical M2M transformation example is the generation of platform-specific models (PSMs) from platform-independent models (PIMs). As models are a means for abstraction, they mostly do not capture enough implementation details to be directly executable. Hence, M2T transformations generate textual artifacts (e.g., source code, configuration documents) which can be deployed on a specific platform.

Fig. 1.
figure 1

Traditional model-driven architecture.

Full size image

When a MDD-based artifact evolves, changes must be reflected in all dependent (meta)models, transformations, and platform artifacts. The complexity of change operations increases with the number of different MMs and models (e.g., due to different modeling languages), M2M transformations (e.g., due to intermediary model representations), and M2T transformations (e.g., due to multiple supported platforms) involved. Current approaches cannot sufficiently cope with the co-evolution of multiple MDD-based artifacts because of restrictions to express and propagate changes which manifest in (1) unidirectional model transformations and (2) disregarding transformation definitions as first-class models (see Fig. 1). An example for evolution mismatches is the inability to reflect changes in generated platform artifacts back to their corresponding instance models. For example, in Eclipse EMF, changes to the generated Java source code may be lost when executing the unidirectional M2T transformation once again. Furthermore, by default, the generation templates (i.e. Java Emitter Templates, JETs) cannot be easily adapted, excluding the possibility to reflect changes in the code generator logic (i.e. transformation definitions are not treated as first-class artifacts).

Yu et al. [26] provide a platform-specific (i.e. Java-bound) solution for the co-evolution problem stated above. In the approach, BX is used to synchronize models with generated and user-modified code. Prerequisites are that the platform-specific language encodes a textual duplicate of the PIM (i.e. @model annotations) and that a MM representation exists for the platform-specific language (i.e. a Java Ecore MM).

To establish BX, triple graph grammars [27] are commonly employed in MDD for keeping related models consistent (see, e.g., [28]). Triple graph transformations relate a source and a target graph (i.e. a model) by some correspondence graph. In this way, source and target graphs are coupled which provides a basic structure for their co-evolution.

Wachsmuth [29] considers MM/model co-evolution as a step-wise adaptation of MMs (via transformation relations) and instance-preservation of models. Instead of describing the co-evolution of models as a transformation between two MMs, Wimmer et al. [30] employ in-place transformations. Herrmannsdoerfer et al. [31] present a framework to model the co-evolution of MMs/models via the composition of coupled transactions to adapt the MM and specify the corresponding model migrations.

Furthermore, state-based MM/model co-evolution approaches, for instance, adopt HOTs which take a difference model obtained by comparing two MMs and generate a model transformation able to produce the co-evolution of involved models [9].

Although all of these co-evolution methods cope with model transformation restrictions, a combined and uniform solution is missing, so far. Either the approaches provide only one-way co-evolution possibilities (i.e. unidirectional) or only for a subset of MDD artifacts (e.g., only MM/model co-evolution). Therefore, in the next section, we propose a generic approach for co-evolving MDD-related artifacts.

3 Model Co-evolution via B-HOT

With our approach (Fig. 2 provides an overview) we want to overcome shortcomings of current methods and offer a generic solution for co-evolving MDD artifacts. The upper part of Fig. 2 reflects a traditional MDA. Model co-evolution is achieved by integrating (1) BX capabilities (lower part of Fig. 2) and (2) support for HOTs into the MDA.

Fig. 2.
figure 2

Overview of our model co-evolution approach.

Full size image

As an example, consider a model transformation from an object-oriented representation (e.g., a class diagram) to a relational database model. For instance, both MMs are defined in a MOF-based language (see upper part of Fig. 2). Hence, their instance models (e.g., using Ecore as technological projection) conform to the (E)MOF MM. A transformation (e.g., specified via ATL or ETL) is applied to class models and generates database models. This forward transformation proves useful in one case only: Changes in evolving class models should be reflected in database models, as well. Updates in database models cannot be propagated back to their source class models. A coupling of both representations limits the target model to be read-only (otherwise changes get lost when re-executing the transformation).

In our approach, we integrate BX capabilities by reusing native MDD concepts. Every transformation is represented as a first-class model conforming to a transformation MM. B-HOTs (see Fig. 2) provide for the mapping of unidirectional MDD-based transformation models (e.g. defined via ATL or ETL) into a bidirectional graph transformation model (and vice versa). Reconsidering the BX of the class-to-database model transformation example, in a next step, both source and target models (i.e. class and database models) are mapped to a graph structure (defined via UnCAL [32], a graph algebra). Source and target graph schemas are represented as MOF-based MMs. In order to establish bidirectionality between the class-to-database transformation, the unidirectional transformation model need to be mapped to a bidirectional transformation model. This is done via a B-HOT (defined via \(\mathrm{UnQL}^{+}\) [13], a SQL-like graph query/transformation language) which provides the forward and backward transformations between two transformation specifications (in our example, transformation models specified in ATL/ETL and \(\mathrm{UnQL}^{+}\)). The result of the B-HOT is a BX specification (again defined via \(\mathrm{UnQL}^{+}\)) which provides both, a forward transformation from class to database graphs as well as a corresponding backward transformation. Thus, changes in the database graph can be propagated back to the class graph. As the transformation of models to graphs is also bidirectional, updated class and database graphs can be represented in their initial model-based forms. Therefore, a BX of source and target models (class and database models in our example) is established. The backward database-to-class transformation is distinct to the BX and no corresponding MDD-based transformation equivalent exists (i.e. no backward transformation defined via, e.g., ATL or ETL). Therefore, as a last step, the backward transformation (in \(\mathrm{UnQL}^{+}\)) must be represented in its original MDD-based form (in ATL, ETL) via the B-HOT mapping (see Fig. 2).

We discuss co-evolution properties of our approach according to the following four categories.

Model Relations: Our approach establishes BX-based relations between models, graphs, and model and graph representations. The mapping relation between traditional MDD-based transformations and BX representations (B-HOT) allows to add BX support in traditional MDAs. Furthermore, relations are not restricted to one source and one target artifact only, but can be used for the transformation of multiple dependent models/graphs, as well (see also compositional BX down below). The coupling of models via BX allows, on the one hand, to establish synchronization definitions and, on the other hand, to collect transformation traces. As many modeling artifacts make up a MDD process, keeping models consistent is of special importance. Moreover, trace information are a relevant source for documentation and debugging purposes.

Model Co-evolution Scenarios: Our approach supports any M2M relation and any number of MM-layers. Horizontal co-evolution examples are, for instance, the synchronization of different MMs or different instance models. Vertical co-evolution examples are, for instance, keeping instance models and corresponding MMs or PIMs and PSMs consistent. Consider, for example, a PIM representing a MM of an object-oriented system and a Java-based MM as its PSM equivalent. Both MMs are synchronized via a B-HOT keeping them consistent. In this case, changes in the PIM can be propagated into the PSM (and vice versa). If the Java-based MM needs to be modified (e.g., due to the release of a new Java version), these changes—when affecting the object-oriented system representation, as well—can be propagated back into the PIM via the B-HOT. Moreover, transformation models permit to propagate changes also in horizontal and vertical M2M and M2T transformation definitions, for instance, for the co-evolution of MMs and transformation models or different transformation models. Referring to the example of synchronizing a general object-oriented MM and a Java-based MM, consider that their instance models are transformed into a textual object-oriented representation and Java source code, respectively. Changes in the Java-based MM (again, e.g., because of a new Java version) must also be reflected in its M2T transformation (e.g., type changes). Via a B-HOT between the PIM and PSM M2T transformations, changes in one of the M2T transformations can be propagated into the other M2T transformation keeping them consistent.

Language-independent Integration: Our approach is not dependent on a specific model transformation language, i.e. it does not matter if the model transformation is defined via ATL, ETL, or any other language. This is because we do not integrate bidirectionality into a model transformation language directly. The B-HOT definition serves as a language-specific binding between the concepts of the unidirectional MDD-based transformation and the bidirectional graph transformation. These bindings must be specified only once for each MDD-based transformation language (e.g., ATL, ETL) and facilitate reuse of our approach.

BX Properties: We develop B-HOTs via a functional bidirectional graph transformation language named \(\mathrm{UnQL}^{+}\) [13]. \(\mathrm{UnQL}^{+}\) is an extension of UnQL [32], a graph querying language based on structural recursion (which can be expressed in first-order logic extended with transitive closure) [33]. The BX ensures the well-behavedness of forward and backward transformations (i.e. that they are consistent with each other) and satisfy the round-trip property [10]. As the BX does not restrict forward transformations to be information preserving, a backward transformation requires not only the modified target graph/model, but also the original source graph/model. Large BX can be developed in a compositional way of reusing existing information (e.g., via intermediate models). Compositional BX can be employed, on the one hand, for a pair of consecutive transformations, where the output of transformation A is the input of transformation B; for example, the output of the source model-to-graph transformation is fed into the forward source-to-target graph transformation (see Fig. 2). On the other hand, compositional BX can be used for a pair of transformations that share an identical input model, for instance, transformations from one PIM to multiple PSMs [12].

4 B-HOT Requirements

This paper provides a first step to make co-evolution in MDD via B-HOTs possible. Initial work regarding the methodology and accompanying tool support has been performed, but is far from being finalized. In this section, we list challenging requirements for the implementation of our approach. We present completed work and discuss prerequisites for future developments.

Transformation MMs: Our B-HOT approach relies on transformation (meta)models. MDD-based M2M transformation MMs exist, for instance, for ATL [11] and for a subset of the Epsilon-language family [34]. Regarding M2T transformations, Hoisl et al. [15] extended the Epsilon model representations of Wei [34]. The BX framework [13] does not need MM representations for the \(\mathrm{UnQL}^{+}\) and UnCAL languages. Syntax definitions in Backus-Naur Form (BNF) exist for both languages and need to be mapped to EMOF-compliant (e.g. Ecore-based) MM representations (ongoing work; see also Sects. 5 and 6).

MM-specific Bindings: For a B-HOT, language-specific bindings need to be established between uni- and bidirectional transformation MMs. Initial work provides a unidirectional transformation from a subset of the ATL language to \(\mathrm{UnQL}^{+}\) (excluding imperative code and OCL expressions of ATL). This transformation does not take the model representation of ATL into account [14]Footnote 2. Thus, language-specific bindings for, for instance, ATL and/or ETL to \(\mathrm{UnQL}^{+}\) and/or UnCAL via B-HOT is future work. Furthermore, a first prototype exists for the BX of model-to-graph representations (Ecore-based models to UnCAL and vice versa), but needs improvements (future work).

Round-tripping of Transformation Definitions: Our B-HOT approach demands transformation models as input. In contrast, most model transformation engines cannot execute model representations of transformation definitions. Therefore, the round-tripping of executable (i.e. text-based) transformation specifications and their model representations must be provided. For M2M transformations, “an ATL transformation is itself a model, conforming to the ATL MM” [11]. Furthermore, Wei [34] developed initial round-tripping support for an Epsilon subset which was extended for M2T transformations (i.e. EGL) by Hoisl et al. [15]. Currently, the automatically derived backward transformation of a BX can neither be expressed as \(\mathrm{UnQL}^{+}\) or UnCAL textual statements nor via corresponding model representations (future work).

Generic Mappings: Prototype developments define transformations in a specific language as implementation vehicle (e.g., ATL, ETL). To support uptake and transferability of our approach we need to establish mappings to OMG specifications (see also Fig. 2). Hoisl et al. [15] provide mappings between EGL-based M2T transformation concepts used for the prototype and the MOFM2T specification. As future work, uni-/bidirectional M2M transformation concepts (e.g., ATL, ETL, \(\mathrm{UnQL}^{+}\)) will be mapped to the QVT specification.

Development Support: Initial support for the requirements-driven testing of (meta)models and model transformations via scenarios is provided by Sobernig et al. [35] and is extended/evaluated by Hoisl et al. [36, 37]. Furthermore, validation for source and target models as well as for BX is presented by Hidaka et al. [13]. We have started implementing an IDE (e.g., a text editor) to support the development of \(\mathrm{UnQL}^{+}\) BX (see Sect. 5) and UnCAL-based graphs (future work). For this task, we have chosen Eclipse Xtext as candidate framework because it combines the grammar specification for a textual syntax with an Ecore-based model representation and provides for an Eclipse-based IDE.

Combine BX and MDD: Model (i.e. graph) transformations are important to both BX and MDD [10, 22]. Our approach allows to integrate BX into MDD, thereby reusing native methods and tools for both. We want to support the creation of a shared terminology [10] via the generalization and mapping of language-specific uni-/bidirectional transformation concepts to OMG specifications. After our developments have matured, as future work, we need to provide for a larger case study to show that our approach works in practice.

5 Prototypical MDD-Based Support for \(\mathrm{UnQL}^{+}\)

This section introduces our initial MDD-based developments for the \(\mathrm{UnQL}^{+}\) BX language: an Ecore-based \(\mathrm{UnQL}^{+}\) MM (see Fig. 3), an Xtext grammar specification for the \(\mathrm{UnQL}^{+}\) textual syntax (see Listing 1), and editors to support the development of \(\mathrm{UnQL}^{+}\) BX in both textual and model-based syntax notations (see the example text- and model-based transformation definitions in Listing 2 and Fig. 4, respectively)Footnote 3 These developments are based on Eclipse EMF and matured versions will fulfill the following B-HOT requirements (see Sect. 4): The mapping of BNF-compliant/Xtext-based \(\mathrm{UnQL}^{+}\) grammar definitions to EMOF-compliant/Ecore-based MM representations. This allows the specification of an \(UnQL^{+}\) BX MM with two corresponding and interchangeable concrete syntax variants (textual and model-based). As the Xtext grammar describes how an Ecore model is derived from a textual notation, round-tripping of \(UnQL^{+}\) BX definitions is partially fulfilled (i.e. transformations specified textually are automatically mapped to their model representations). Furthermore, the implemented software artifacts (e.g., text/model editors) support the development of \(UnQL^{+}\) BX.

Fig. 3.
figure 3

Ecore-based \(\mathrm{UnQL}^{+}\) MM (excerpt).

Full size image

Figure 3 shows an excerpt of the Ecore-based \(\mathrm{UnQL}^{+}\) MM. For this, the BNF grammar of \(\mathrm{UnQL}^{+}\) was mapped to a model representation consisting of (abstract) classes and class attributes as well as containment references and inheritance relationships between these classes. From Fig. 3 it can be seen that four different Statement types can be contained in an UnQLplus expression: Selection, Replacement, Deletion, and Extension. All of these statements operate on graphs (Template); for example, to select a graph based on certain conditions.

Listing 1 shows an excerpt of the Xtext grammar for the \(\mathrm{UnQL}^{+}\) textual syntax. The grammar definition of \(\mathrm{UnQL}^{+}\) was translated from BNF to Xtext and aligned to match the Ecore model concepts. The entry rule on lines 7–8 in Listing 1 defines that an UnQLplus expression contains Statements. The Statement rule (lines 10–12) delegates in line 11 to the four alternative statement rules (defined later) and specifies the syntax of an optional condition (line 12). As examples, the syntax of two statements is specified in the Selection rule (lines 14–15) and in the Replacement rule (lines 17–18). Furthermore, the definition of graphs is shown in lines 22–23 (Template rule) and lines 25–33 (TemplateExpression rule), respectively (delegated rules are omitted).

figure a

With the Ecore MM and the Xtext grammar defined in Fig. 3 and Listing 1, it is possible to provide editor support for textual as well as model-based \(\mathrm{UnQL}^{+}\) BX. Listing 2 shows an example class-to-database \(\mathrm{UnQL}^{+}\) BX replacing attributes by columns (excerpt taken from Hidaka et al. [13]). The BX in Listing 2 makes use of Selection (e.g., starting from line 1 and line 3) and Replacement statements (starting from line 7). The \(\mathrm{UnQL}^{+}\) BX was created using our Eclipse-based textual editor providing features, such as, syntax coloring, auto completion, error detection, and so forth. In this way, it is ensured that developed \(\mathrm{UnQL}^{+}\) BX conform to the Xtext grammar defined in Listing 1. A benefit of using the editor to write \(\mathrm{UnQL}^{+}\) BX is the early detection and immediate correction of syntactical errors.

figure b
Fig. 4.
figure 4

Tree-based view on example class-to-database \(\mathrm{UnQL}^{+}\) BX model (excerpt).

Full size image

Figure 4 shows an excerpt of a tree-based view on a model representation of the same class-to-database \(\mathrm{UnQL}^{+}\) BX example introduced in Listing 2. Via the Ecore MM and the corresponding Xtext grammar, a model representation can be derived from textual \(\mathrm{UnQL}^{+}\) BX definitions. This instance model conforms to the Ecore-based \(\mathrm{UnQL}^{+}\) MM in the same way as a textual \(\mathrm{UnQL}^{+}\) BX definition conforms to the Xtext grammar. The representation of transformation models (e.g., expressing \(\mathrm{UnQL}^{+}\) BX as models as exemplified in Fig. 4) is one of the main requirements to realize our B-HOT approach.

6 Concluding Discussion

In this paper, we presented an approach for model co-evolution by combining BX and HOT for MDD. The developed method (B-HOT) intends to overcome current limitations for model co-evolution as transformations are represented as models and model transformations are bidirectionalized. In our approach, models are coupled via BX providing the benefit that synchronization of models is ensured via forward/backward transformations. Another advantage is that changes can be propagated into model transformations keeping them consistent with their evolving dependent artifacts (MMs, model instances). Our approach of integrating BX into MDD is generic and can be applied to any model transformation language via binding specifications.

With our work and according to the feature-based classification of BX approaches presented in [38], we combine graph-based and MDD-based artifact representations involved in BX. In particular, the employed demonstrator BX framework (GRoundTram) is based on graphs, while metamodels in Eclipse approximate the MOF specification (implemented via Ecore models). Therefore, the technical space of GRoundTram needs to cope with MDD-based artifact representations, as well. In GRoundTram (for further BX approaches and their characteristic features see [38]), the correspondence relation between source and target artifacts is defined via user-provided unidirectional transformation specifications. In this case, the backward transformation is not explicitly stated (see also Sect. 4) and is automatically derived by the bidirectional engine (inversion). Thus, the results of the computed backward transformation needs to be conceptualized in the technical space of GRoundTram (i.e. represented in \(\mathrm{UnQL}^{+}\) or UnCAL). The proposed B-HOT approach presented in this paper demands to switch from an implicit to an explicit representation of the backward transformation.

Please note that BX approaches (see, e.g., [38]) differ in terms of feature characteristics and implementation methods, for example, according to the technical space (e.g., text-, graph-, MDD-based), the directionality of the consistency definition (e.g., unidirectional, bidirectional transformation specifications), the representation of changes (e.g., state-, operation-based), or the definition of the backward transformation (e.g., explicit, implicit) [38]. Although we focus in this paper specifically on one BX approach (i.e. GRoundTram), other BX methods which conceptually conform to the requirements discussed in the former paragraph as well as in Sect. 4 are candidates for consideration, as well.

A drawback of our proposal is that the efforts of creating initial modeling and transformation artifacts can be high. Transformation MMs may have to be defined for the intended target language. Currently, no bindings for transformation languages exist. Although these have to be defined only once for each language, this is a barrier for uptake. Transformation engines might not execute transformation models directly making model/text round-tripping functions necessary (but again these can be reused per language). Adequate tool support must be provided to facilitate the development of models and transformations.

Currently, we are developing an EMOF-based MM for the \(\mathrm{UnQL}^{+}\) BX language (in Ecore). In parallel, we transfer the BNF-based grammar definition to Xtext. This will ensure the consistent mapping of transformations written in \(\mathrm{UnQL}^{+}\) to their modeling equivalents. An editor to support the definition of \(\mathrm{UnQL}^{+}\) statements will be provided, as well. Initial developments (see also Sect. 5) are available at the URLs mentioned in the footnote of Sect. 1 and are continuously updated. \(\mathrm{UnQL}^{+}\) concepts will be mapped to the QVT-Relations language in the near future.