Bidirectional model transformations (bx) are mechanisms for auto-matically restoring consistency between multiple concurrently modified models. They are, however, challenging to implement; many model transformation languages not supporting them at all. In this paper, we propose an approach for automatically obtaining the consistency guarantees of bx without the complexities of a bx language. First, we show how to “fake” true bidirectionality using pairs of unidirectional transformations and inter-model consistency constraints in Epsilon. Then, we propose to automatically verify that these transformations are consistency preserving — thus indistinguishable from true bx — by defining translations to graph rewrite rules and nested conditions, and leveraging recent proof calculi for graph transformation verification

Dodds, Mike

Paige, Richard F.

Poskitt, Christopher M.

Rensink, Arend

Bidirectional model transformations (bx) are mechanisms for automatically restoring consistency between multiple concurrently modified models. They are, however, challenging to implement; many model transformation languages not supporting them at all. In this paper, we propose an approach for automatically obtaining the consistency guarantees of bx without the complexities of a bx language. First, we show how to “fake” true bidirectionality using pairs of unidirectional transformations and inter-model consistency constraints in Epsilon. Then, we propose to automatically verify that these transformations are consistency preserving—thus indistinguishable from true bx—by defining translations to graph rewrite rules and nested conditions, and leveraging recent proof calculi for graph transformation verification

Christopher M. Poskitt

Mike Dodds

Richard F. Paige

Arend Rensink

CiteSeerX

Towards Rigorously Faking Bidirectional Model Transformations

Bidirectional model transformations (bx) are mechanisms for auto-matically restoring consistency between multiple concurrently modified models. They are, however, challenging to implement; many model transformation languages not supporting them at all. In this paper, we propose an approach for automatically obtaining the consistency guarantees of bx without the complexities of a bx language. First, we show how to “fake‿ true bidirectionality using pairs of unidirectional transformations and inter-model consistency constraints in Epsilon. Then, we propose to automatically verify that these transformations are consistency preserving — thus indistinguishable from true bx — by defining translations to graph rewrite rules and nested conditions, and leveraging recent proof calculi for graph transformation verification

University of Twente Research Information

Towards Rigorously Faking Bidirectional ModelTransformationsChristopher M. Poskitt1?, Mike Dodds2, Richard F. Paige2, and Arend Rensink31 Department of Computer Science, ETH Zürich, Switzerland2 Department of Computer Science, The University of York, UK3 Department of Computer Science, University of Twente, The NetherlandsAbstract. Bidirectional model transformations (bx) are mechanisms for auto-matically restoring consistency between multiple concurrently modified models.They are, however, challenging to implement; many model transformation lan-guages not supporting them at all. In this paper, we propose an approach forautomatically obtaining the consistency guarantees of bx without the complex-ities of a bx language. First, we show how to “fake” true bidirectionality usingpairs of unidirectional transformations and inter-model consistency constraints inEpsilon. Then, we propose to automatically verify that these transformations areconsistency preserving—thus indistinguishable from true bx—by defining trans-lations to graph rewrite rules and nested conditions, and leveraging recent proofcalculi for graph transformation verification.1 Introduction and MotivationModel transformations are operations for automatically translating models conform-ing to one language (i.e. a metamodel) into models conforming to another, in a waythat maintains some sense of consistency between them. At their most basic, modeltransformations are unidirectional: given a source model (e.g. some high-level yet user-modifiable view of a system), they generate a target model (perhaps a lower-level view,such as code) whose data is “consistent” with the source, in a sense that is either leftimplicit, or captured by textual constraints or an inter-model consistency relation.Many situations arise where the source and target models may both be modified byusers in concurrent engineering activities, e.g. when integrating parts of systems thatare modelled separately but must remain consistent. Bidirectional model transforma-tions (bx) [5,17] are a mechanism for automatically restoring inter-model consistencyin such a scenario; in particular, bx simultaneously describe transformations in bothdirections—from source to target and target to source—with their compatibility guar-anteed by construction [5].While this advantage is certainly an attractive one, bx are challenging to implementon account of the inherent complexity that they must encode. Model transformation lan-guages supporting them often do so with conditions: some require that bx are bijective(e.g. BOTL [3]), essentially restricting their use to models presenting identical data in? Received funding from the European Research Council under the European Union’s SeventhFramework Programme (FP7/2007-2013) / ERC Grant agreement no. 291389.different ways, whereas others require users to work with specific formalisms such astriple graph grammars (e.g. MOFLON [1]). The QVT-R language—part of the OMG’sQueries, Views, and Transformations standard—allows bx to be expressed, but suffersan ambiguous semantics [18] and limited tool support (the most successful ones oftendeparting from the original semantics [11]). Moreover, many modern transformationlanguages do not provide any support for bx (e.g. ATL [9]), meaning that users must ex-press them as two separate unidirectional transformations. While this seems a practicalworkaround, it comes with the major risk that the compatibility of the transformationsmight not be maintained over time.A trade-off between the benefits (but complexity) of bx and the practicality (butpossible incoherence) of unidirectional transformations can be achieved in Epsilon, aplatform of interoperable model management languages. Epsilon has languages sup-porting the specification of unidirectional transformations in either a rule-based (ETL),update-in-place (EWL), or operational (EOL) [12] style. Furthermore, it provides aninter-model consistency language (EVL [10]) that can be used to express and evaluateconstraints between models conforming to different metamodels. With these languagestogether, bx can be “faked” in a practical way, by: (1) defining pairs of unidirectionaltransformations for separately updating the source and target models; and (2) defining“consistency” via inter-model constraints in EVL, the violation of which will triggerappropriate transformations to restore consistency.Although this process gives us a means of checking consistency and automaticallytriggering a transformation to restore it, we lack the important guarantee that bx giveus: the compatibility of the transformations. It might be the case that after the executionof one transformation, the other does not actually restore consistency, leading to furtherEVL violations. How do we check for, and maintain, compatibility?We aim to address this shortcoming and obtain the guarantees of bx without the needfor bx languages. Instead, we will use rigorous proof techniques to verify that faked bxare consistency preserving, and thus indistinguishable to users from true bx. To this end,we propose to apply techniques from graph transformation verification. Given a fakedbx in Epsilon, we will model the unidirectional transformations as graph transformationrules, and EVL constraints as nested graph conditions [7]. Then, by leveraging graphtransformation proof calculi [8,14,15] in a weakest precondition style, we aim to auto-matically prove compatibility of the unidirectional transformations with respect to theEVL constraints. Furthermore, we aim to exploit the model checker GROOVE [6] toautomatically search for counterexamples when consistency preservation does not hold.The overarching goal of our work is to achieve the ideal that Stevens [17] con-templated in her survey of bx: that “if a framework existed in which it were possibleto write the directions of a transformation separately and then check, easily, that theywere coherent, we might be able to have the best of both worlds.”2 Example bx in Epsilon: Class Diagrams to DatabasesTo illustrate the ideas of our proposal, we recall a common model transformation prob-lem that concerns the consistency of class diagram and relational database models(CD2RDBM). Class diagram models conform to a simple language describing famil-iar object-oriented concepts (e.g. classes, attributes, relationships), whereas relationaldatabase models conform to a language describing how databases are constructed (e.g.tables, columns, primary keys). Here, consistency is defined in terms of a correspon-dence between the data in the models, e.g. every table n corresponds to a class n, andevery column m corresponds to an attribute m. Figure 1 contains two simple modelsthat are consistent in this sense (we omit the metamodels for lack of space).:Classname = "users":Attributepkey = Truename = "id":Attributepkey = Falsename = "username"feature feature:Tablename = "users":Columnname = "id":Columnname = "username"pkey columnFig. 1. Two consistent CD and RDB modelsUsers of the models shouldbe able to create new classes (ortables) whilst maintaining inter-model consistency. A bx wouldbe well suited for this: upon thecreation of a new class (resp. ta-ble), a table (resp. class) shouldbe created with the same nameto restore consistency. We canfake this simple bx in Epsilon with a pair of unidirectional transformations (one forupdating the class diagram model, one for updating the relational database) and a set ofEVL constraints. For the former, we can use the Epsilon Wizard Language (EWL) to de-fine a pair of update-in-place transformations, AddClass and AddTable (for simplicity,here we assume the new class/table name newName to be pre-determined and unique,but Epsilon does support the capturing and sharing of such data between wizards).wizard AddClass {do {var c : new Class ;c .name = newName ;self .Class .all .first ( ) .contents .add (c ) ;}}wizard AddTable {do {var table : new Table ;table .name = newName ;self .Table .all .first ( ) .contents .add (table ) ;}}Using the Epsilon Validation Language (EVL), we express the relevant notion of inter-model consistency: that for every class n, there exists a table named n (and vice versa).If one of the constraints is violated, Epsilon can automatically trigger the relevant trans-formation to attempt to restore consistency. For example, after executing the transfor-mation AddClass, the constraint TableExists will be violated, indicating that thetransformation AddTable should be executed to restore consistency.context OO !Class {constraint TableExists {check : DB !Table .all .select (t |t .name= self .name ) .size ( ) > 0}}context DB !Table {constraint ClassExists {check : OO !Class .all .select (c |c .name= self .name ) .size ( ) > 0}}This example of a bx, “faked” in Epsilon, is a deliberately simple one chosen to illustratethe concepts. Note even that the CD2RDBM problem can lead to more interesting (i.e.less symmetric) bx, e.g. manipulating inheritance in the class model.3 Checking Compatibility of the TransformationsThe critical difference between the “faked” bx in the previous section and a true bx isthe absence of guarantees about the compatibility of the transformations: upon the vio-lation of TableExists, for example, does the execution of AddTable actually restoreconsistency? For this simple example, a manual inspection will quickly confirm that thetransformations are indeed compatible in this sense. But what about more intricate bx?And what about bx that evolve and change over time? For the Epsilon-based approachto be a convincing alternative to a bx language, it is imperative that the compatibility (ornot) of the transformations can be checked, and—crucially—that this can be done in asimple and automatic way. To this end, we propose to leverage and adapt some recentdevelopments in the verification of graph transformations.Graph transformation is a computation abstraction: the state of a computation isrepresented as a graph, and the computational steps as applications of rules (i.e. akin tostring rewriting in Chomsky grammars, but lifted to graphs). Modelling a problem usinggraph transformation brings an immediate benefit in visualisation, but also an importantone in terms of semantics: the abstraction has a well-developed algebraic theory thatcan be used for formal reasoning. This has been exploited to facilitate the verificationof graph transformation systems, i.e. calculi for systematically proving specificationsabout graph properties before and after any execution of some given rules. Further-more, such calculi have been generalised to graph programs [13], which augment theabstraction with expressions over labels and familiar control constructs (e.g. sequentialcomposition, branching) for restricting the application of rules.Habel et al. [7,8] developed weakest precondition calculi for proving specificationsof the form {pre} P {post}, which express that if a graph satisfies the preconditionpre, then any graph resulting from the execution of graph program P will satisfy thepostcondition post; these pre- and postconditions expressed using nested conditions,a graphical formalism for first-order (FO) structural properties over graphs. They de-fined constructions that, given a nested condition post and program P , would return aweakest liberal precondition Wlp(P, post), representing the weakest property that musthold for successful executions of P to establish post. The specification would then be(dis)proven by checking the validity of pre ⇒ Wlp(P, post) in an automatic FO the-orem prover. Poskitt and Plump developed proof calculi in a similar spirit, separatelyaddressing two extensions: programs and properties involving attribute manipulation[14,15], and reasoning about non-local structural properties [16].We aim to exploit this work to check the compatibility of transformations in theEpsilon approach to bx. In particular, we are developing automatic translations of EWLtransformations to graph programs (denoted PS , PT for the source and target updatesrespectively), and translations from EVL constraints to nested conditions (denoted evl).Then, the task of checking compatibility of the transformations, as shown in Figure 2,reduces to proving the specifications {evl} PS ; PT {evl} and {evl} PT ; PS {evl}(here we assume the input graphs to be disjoint unions of the two models). Intuitively:if the models are consistent to start with, and executing the transformations in eitherorder maintains consistency, then the transformations are compatible.The technical challenges of the process fall into two main parts: computing theabstractions, and checking validity. Defining translations for the former requires care:we need to determine how much of the EWL language can be handled, we need toensure that the graph-based semantics we abstract them to is “correct”, and we need toadapt the proof technology to our specific needs. The work in [14,15,16], for example,does not presently support type graphs (causing more effort to encode conformance to"faked" BX in EpsilonEVL constraints to nested conditionsmodel transformations to graph programsWLP constructionPSFO validityFO validityevl )Wlp(PS ; PT , evl)evl )Wlp(PT ; PS , evl)compatibleyesyes????no / loopno / loopevlPTFig. 2. Overview of the process for checking compatibility of the transformationsmetamodels). Similar concerns must be addressed for the translations of EVL to nestedconditions (we can take inspiration from recent work on such translations for core OCL[2]). For the challenge of checking validity, we aim to leverage existing FO theoremprovers (e.g. Vampire) as much as possible, adapting existing translations of nestedconditions to FO logic [7,14]. Given the undecidability of FO validity, we also aim toexplore the use of the GROOVE model checker [6] in finding counterexamples whenthe theorem provers respond with “no”, or do not appear to terminate.Our example bx for the CD2RDBM problem is easily translated into graph programsand nested conditions, as given in Figure 3. The programs PS , PT are the individualrules creating respectively a class or table node labelled newName (here, ∅ denotes theempty graph, indicating that the rules can be applied without first matching any struc-ture, i.e. unconditionally). The nested condition evl, given on the right, expresses thatfor every class (resp. table) node, there is a table (resp. class) node with the same name(we do not define here a formal interpretation, but note that x, y are variables, and thatthe numbers indicate when nodes are the same down the nesting of the formula). Werethe weakest liberal preconditions to be constructed, we would find:Wlp(PS ;PT , evl) ≡Wlp(PT ;PS , evl) ≡ evl.Since evl ⇒ evl is clearly valid, both {evl} PS ; PT {evl} and {evl} PT ; PS {evl}must hold, and—assuming correctness of the abstractions—the original EWL transfor-mations are therefore compatible with respect to the EVL constraints.8( , 9( )):Classname = x :Classname = x :Tablename = x1 18( , 9( )):Tablename = y :Tablename = y :Classname = y2 2:Classname = newName; ):Tablename = newName; ) ^Fig. 3. Our CD2RDBM bx expressed as graph transformation rules and a nested condition4 Next StepsAfter further exploring the CD2RDBM example, we will identify a selection of bx casestudies—from the community repository [4] and beyond—that exhibit a broader rangeof characteristics and challenges to address. We will implement these bx using EWLtransformations and EVL constraints, then manually translate them into graph trans-formations and nested conditions. These will serve as a proof of concept, but also asguidance, helping us to determine how far we should adapt the proof calculi to supportour goals (e.g. introducing type graphs for capturing the metamodels). After imple-menting the weakest precondition calculations and translations to FO logic, we willdesign and implement automatic translations from Epsilon bx to their correspondinggraph-based abstractions, initially focusing on a core (but expressive) subset of the lan-guages. Finally, we will explore the use of GROOVE in finding counterexamples whenverification fails, by exploring executions of the graph transformation rules.References1. Amelunxen, C., Königs, A., Rötschke, T., Schürr, A.: MOFLON: A standard-compliantmetamodeling framework with graph transformations. In: ECMDA-FA 2006. LNCS, vol.4066, pp. 361–375. Springer (2006)2. Arendt, T., Habel, A., Radke, H., Taentzer, G.: From core OCL invariants to nested graphconstraints. In: ICGT 2014. LNCS, vol. 8571, pp. 97–112. Springer (2014)3. Braun, P., Marschall, F.: Transforming object oriented models with BOTL. In: GT-VMT2002. ENTCS, vol. 72, pp. 103–117. Elsevier (2003)4. Cheney, J., McKinna, J., Stevens, P., Gibbons, J.: Towards a repository of Bx examples. In:EDBT/ICDT Workshops. vol. 1133, pp. 87–91. CEUR-WS.org (2014)5. Czarnecki, K., Foster, J.N., Hu, Z., Lämmel, R., Schürr, A., Terwilliger, J.F.: Bidirectionaltransformations: A cross-discipline perspective. In: ICMT 2009. LNCS, vol. 5563, pp. 260–283. Springer (2009)6. Ghamarian, A.H., de Mol, M., Rensink, A., Zambon, E., Zimakova, M.: Modelling and anal-ysis using GROOVE. Software Tools for Technology Transfer 14(1), 15–40 (2012)7. Habel, A., Pennemann, K.H.: Correctness of high-level transformation systems relative tonested conditions. Mathematical Structures in Computer Science 19(2), 245–296 (2009)8. Habel, A., Pennemann, K.H., Rensink, A.: Weakest preconditions for high-level programs.In: ICGT 2006. LNCS, vol. 4178, pp. 445–460. Springer (2006)9. Jouault, F., Allilaire, F., Bézivin, J., Kurtev, I.: ATL: A model transformation tool. Scienceof Computer Programming 72(1-2), 31–39 (2008)10. Kolovos, D.S., Paige, R.F., Polack, F.A.C.: On the evolution of OCL for capturing structuralconstraints in modelling languages. In: Rigorous Methods for Software Construction andAnalysis. LNCS, vol. 5115, pp. 204–218. Springer (2009)11. Macedo, N., Cunha, A.: Implementing QVT-R bidirectional model transformations usingAlloy. In: FASE 2013. LNCS, vol. 7793, pp. 297–311. Springer (2013)12. Paige, R.F., Kolovos, D.S., Rose, L.M., Drivalos, N., Polack, F.A.C.: The design of a concep-tual framework and technical infrastructure for model management language engineering. In:ICECCS 2009. pp. 162–171. IEEE Computer Society (2009)13. Plump, D.: The design of GP 2. In: WRS 2011. EPTCS, vol. 82, pp. 1–16 (2012)14. Poskitt, C.M.: Verification of Graph Programs. Ph.D. thesis, The University of York (2013)15. Poskitt, C.M., Plump, D.: Hoare-style verification of graph programs. Fundamenta Informat-icae 118(1-2), 135–175 (2012)16. Poskitt, C.M., Plump, D.: Verifying monadic second-order properties of graph programs. In:ICGT 2014. LNCS, vol. 8571, pp. 33–48. Springer (2014)17. Stevens, P.: A landscape of bidirectional model transformations. In: GTTSE 2007. LNCS,vol. 5235, pp. 408–424. Springer (2007)18. Stevens, P.: Bidirectional model transformations in QVT: semantic issues and open ques-tions. Software and System Modeling 9(1), 7–20 (2010)

Towards rigorously faking bidirectional model transformations

Abstract

Similar works

Full text

Available Versions

CiteSeerX

University of Twente Research Information

Institutional Knowledge at Singapore Management University

White Rose Research Online

Repository for Publications and Research Data