Model Transformation by Graph Transformation

1. Model Transformationby Graph Transformation Yan Yan CSE294 Seminar, Feb. 12th, 2010 University of California at San Diego

2. Outline • Model Transformation for MDA • Technologies • Graph Transformation • Case Study

3. Model Transformation • MDA (Model Driven Architecture) • An approach to develop software based on different models. • There are separate models for business logic, platform specific details, etc.. • Stepwise refinement and extension of models instead of programming all time • Model Transformation • Transforming, Integrating and synchronizing models • PIM  PSM is a model transformation issue.

4. Technologies Forward and backward transformations will be defined independently. • Operational way • Define instructions how the elements from source must be transformed into that of the target. • Most technologies • i.e. Borland Together, …. • Declarative way • Declaratively define the relation between two or more models. • QVT(Query/View/Transformation) Hard to verify correctness.

5. QVT • Properties • Support for declarative or operational specifications of model integration rules • Support for checking model consistency • Support for uni/bidirectional model transformations • Textual or graphical notation • Meta-model based • Compliant to OMG’s MOF standard • Support for code generation • Traceability support • Support for change propagation

6. QVT • A standard for model transformation defined by OMG (the Object Management Group) • A transformation language! • Implementation • QVT-Operational Mappings • Together, M2M, SmartQVT … • QVT-Relations • M2M (not yet released) • QVT-Core • OptimalJ (discontinued, 2008)

7. QVT-Declarative Way • Relationships between QVT metamodels • Relations • User-friendly, supports complex object pattern matching and object template creation. • Core • Basic infrastructure of the declarative part of QVT • Uses minimal extensions to EMOF and OCL • Only supports pattern matching It is EQUALLY powerful to Relations Language, only that describing MT using Core are more verbose. The most popular so far: Graph Transformation

8. Graph Transformation – Comparative Study Model Transformation by Graph Transformation: A Comparative Study, Gabriele Taentzer, et al. Technische University at Berlin, Germany, ACM/IEEE 8th International Conference on Model Driven Engineering Languages and Systems, 2005 • AGG • Algebraic Graph Transformation • Visual Editor • TGG • Triple Graph Grammars • AToM3, FUJABA, MOFLON • VIATRA • VIATRA2 • VMTS • VMTS http://tfs.cs.tu-berlin.de/agg Generation of Visual Editors as Eclipse PlugIns, KarstenEhrig, TU-Berlin, Germany, 20th. ASE, 2005 The VIATRA2 Transformation Framework, Model Transformation by Graph Transformation, DánielVarró, et al, Proceedings of the 2006 ACM symposium on Applied computing, 2006 A CASE tool supporting round-trip engineering. At its core is TGGs, for transformating back and forth between UML diagrams and java code.

9. Case Study - TGGs • TGGs is easier to apply. • QVT and TGGs have striking similarities. • Used by a transformation engine in different ways (application scenarios): • Forward and backward transformation • Keep track of change and propagate changes accordingly (model synchronization) • No inconsistencies • Only one single definition of the relation between two classes of models • Tool support • “Reconciling TGGs with QVT”, Joel Greenyer and Ekkart Kindler, MoDELS, 2005 To discuss main concepts of QVT and TGGs

10. An example • material-flow system  formal methods • Two connected tracks  Petri net

11. Relational Rules • A rule expressing the relation of model structures easy for model checking bidirectional incrementally propagate changes

12. Firstly, the root rule is needed to map the Project root model to a Petri net root model. Rules do NOT describe operationally how to transform models, which is up to a transformation engine to make them operational. Then, there are model structures newly created. Some further rules, etc..

13. QVT-Core Mappings • QVT-Relation  QVT-Core • abstract concrete • user-friendly no graphical syntax • QVT-Core is the foundation of the declarative QVT • QVT-Relation is equally powerful as QVT-Core • QVT-Relations and QVT-Core both use OCL expressions to describe model patterns.

14. QVT-Core Mappings P.120, QVT Specification, 07-07-07 Guard Pattern Mapping nodes Variable Domain areas Trace objects, trace nodes, trace variables Bottom Pattern

15. Textual Representation

16. TGG Rules • Assume two types of graphs given whose structure is specified by (single) graph grammars. • Software models  graphs • TGG rules • To specify how two types of graphs structurally correspond to each other • The correspondence is expressed by inserting a third graph grammar. • The simultaneous application of these corresponding graph grammars always results in structurally corresponding graphs.

17. TGG Rules Parse an existing graph with the graph grammar on one side of the TGG Create the target graph with the graph grammar on the other side of the TGG, and the correspon-dence graph. This collapsed representation is possible because TGGs use only non-deleting graph grammars domains

18. Two Differences • QVT does not have graphical syntax, while TGG rules have a graphical syntax. • Nodes, representing the model objects • Edges, representing the references between these objects. • QVT uses OCL expressions to specify literal values or values calculated from somewhere else, while TGG rules may utilize attribute value constraints to make things done.

19. Mapping QVT to TGGs Can be reused as variables in OCL expressions Variable  Node OCL Expression  Edge OCL expressions specifying attribute values will NOT be mapped to edges, but to Attribute Value Constraint.

20. Structural Mapping • QVT-Core domain areas  TGG domain sides • QVT-Core mapping areas  TGG correspondence column • QVT-Core patterns • Variables in guard patterns  nodes belonging to LHS and RHS • Variables in bottom patterns  nodes belonging to RHS only

21. Transformation Setting • A general transformation setting is necessary before designing a set of rules in QVT or TGG • The setting consists of references to : • the packages of the domain models • the packages of the correspondence or trace model • Finally adopted by QVT-Base package • One-on-one mapping at this level

22. Perform Model Transformation • Use TGG to transform QVT-Core Mappings into TGG Rules, then perform in TGG engine model transformations specified in QVT-Core

23. Implementation Steps • - to create and transform QVT and TGG rules, both a QVT and TGG meta-model is needed. • - implemented metamodels of the declarative QVT languages • - redesigned and reimplemented TGG metamodels • - to choose EMF as a basis • Reason 1: TGG tools already based on EMF. • Reason 2: many useful features and other interesting projects based on EMF, i.e. GMF. • - to generate GMF-editor • The TGG engine is also called TGG interpreter. • Integration of OCL is not yet completed.

24. Backward mapping • Only possible when: • QVT-Core supports multiple trace variables in the bottom pattern • The resulting QVT-Core would need to consider every domain area to be enforceable. (Because TGG rules do not specify if any domain is enforceable or not…) • A backward mapping might be interesting to evaluate advantages or disadvantages between the TGG interpreter and upcoming implementations of QVT-Relations..

25. Comparing Concepts • Though striking similarities and analogies: • Basic structure of QVT and TGGs coincide • Rough meaning of these concepts are the same • There are more or less significant differences • Philosophical level • Technical level • Conceptual level

26. Philosophical Differences • How a QVT mapping and a TGG rule are read • QVT: bottom to top • TGG: top to bottom (left to right) • - the real execution of a TGG rule is driven by the existing parts of a model so the result will not be different. • The way QVT and TGGs are applied in a concrete transformation scenario • QVT mappings are written with an application scenario in mind • TGG rules do not refer to the application scenario

27. Semantical Comparison • Assume that two models are in the relation specified by the QVT mappings resp. TGG rules. • TGGs • Every object in the two models has exactly one binding to a creating node of an applied TGG rule • QVT standard • It is not made clear whether there is at most one binding of each model object to a variable in a bottom pattern of exactly one application of a QVT maping.

28. Conceptual Differences • QVT : • Conceptually closely related to defining a set of variables and definition of relations among them. • Using OCL expressions and assignments. • QVT is very flexible and expressive due to the expressive power of OCL. • TGGs: • Graphical in nature, originate from the realm of graph grammars and graph transformations. • Model is considered with typed nodes and edges between them. • TGGs’ semantics is simple, precise and intuitive. • Other differences: • Check & enforce, constraints, etc..

29. Conceptual Differences • The differences impose some restrictions. • But most of them can be overcome by making extensions to TGGs. i.e. • Equipping TGGs with OCL constraints, the essence of a relation between two models can be specified in a graphical way; still, the expressive power of OCL is at hand when necessary.

30. Conclusion • Model transformation is core technology of MDA. Graph transformation is very helpful to perform model transformation. • TGGs is an excellent case study, for there are many conceptual and structural similarities between QVT and TGGs. QVT mappings can be transformed into TGG rules. • There are differences in the philosophy and concepts between QVT and TGGs. • Futuremore, QVT-Relations and TGGs….

31. Reconciling TGGs with QVT, Joel Greenyer and Ekkart Kindler, MoDELS, 2005 • Model Transformation by Graph Transformation: A Comparative Study, Gabriele Taentzer, et al. Technische University at Berlin, Germany, ACM/IEEE 8th International Conference on Model Driven Engineering Languages and Systems, 2005 • Model Transformation with Triple Graph Grammars, Alexander Königs, Model Transformations in Practice Satellite Workshop, 2005 • Graph-theoretic Concepts in Computer Science, Ernst Mayr, Günther Schmidt, Gottfried Tinhofer, 20th international workshop, WG 94', Herrsching, Germany, June, 1994 • Generation of Visual Editors as Eclipse PlugIns, KarstenEhrig, TU-Berlin, Germany, 20th. ASE, 2005 • The VIATRA2 Transformation Framework, Model Transformation by Graph Transformation, DánielVarró, et al, Budapest University of Technology and Economics, Budapest, Hungary, Proceedings of the 2006 ACM symposium on Applied computing, 2006

32. Q & A • Thanks!