Shane Sendall Software Modeling & Verification Lab. Computer Science Department

1. Combining Generative and Graph Transformation Techniques for Model Transformation: An Effective Alliance? Shane Sendall Software Modeling & Verification Lab. Computer Science Department University of Geneva Switzerland Shane.Sendall@cui.unige.ch

2. Overview • Model Transformation • Overview of Gmorph • Graph Transformation/Generative Programming • Closing Remarks Shane Sendall, CUI, University of Geneva

3. Model Transformation—What A model transformation applies one or more rules according to the presence of certain patterns of elements in the set of source models, resulting in a set of target models. The application of a rule results in any number of the following: • the creation of a new model fragment • the deletion of an existing model fragment • the modification of an existing model fragment (where model fragment is any thing from a model to a model element) In the context of MDA, model transformation can be categorized as: language translation and model evolution Shane Sendall, CUI, University of Geneva

4. Genermorphous (Gmorph) • Gmorph is a language (still under development) for specifying and executing model transformations Goal: • push imperative approach toward some advantages of declarative approaches, such as, pattern matching, rule application, etc. Context: • an experimental language that is not “fully featured”; it does not address all aspects that are useful for mainstream model transformation, e.g., reuse mechanisms, well-formedness checks, concurrent application of rules, etc. Shane Sendall, CUI, University of Geneva

5. Genermorphous (Gmorph) • A hybrid approach that offers a (partially) visual transformation language, which address both model evolution and translation categories: • Rule Specification language (mixture of Graph Transformation Rules and Generative Programming Principles) • Rule Composition language (small imperative language: choice, sequence, iteration) • Relation to QVT: results from Gmorph could be fed back into a QVT language Shane Sendall, CUI, University of Geneva

6. E A B C D C D Graph Transformation •  Graph Rewriting • LHS (graph) = left-hand side of rule = pattern • RHS (graph) = right-hand side of rule = pattern • (Interface = intersection of LHS & RHS) • Steps taken in applying a rule • match, remove, glue, embed RHS LHS Shane Sendall, CUI, University of Geneva

7. GT: relevance to Gmorph • LHS and RHS • Give a ‘before’ and ‘after’ view of rule application • For model evolution transformations: rule is a graph rewrite Shane Sendall, CUI, University of Geneva

8. Generative Programming • A generative programming consists of three parts: a problem space, a solution space, and the configuration knowledge. • Problem space defines the appropriate domain-specific concepts and features. • Solution space defines the target model elements that can be generated and all possible variations. • Configuration knowledge specifies illegal feature combinations, default settings, default dependencies, construction rules, and optimization rules. Shane Sendall, CUI, University of Geneva

9. GP: relevance to Gmorph • Ability to handle variations in source model element matching and target model generation (language translation) • Parameterization and “open-world” model of matching • Default and configuration information are part of specification Shane Sendall, CUI, University of Geneva

10. Closing Remarks and Future Directions • Issues • Pattern matching at instance level • Optional and multiple matches • Transitive closure and sequence of matches • Ability to easily define mappings between instances: • Current approach: 1-to-1, 1-to-many, many-to-1 by traversal of LHS • Interesting alternative: an attribute grammar-like approach, which implicitly traverses LHS Shane Sendall, CUI, University of Geneva

11. Closing Remarks and Future Directions • Issues • Reversing transformations and model updating (round-tripping) => (persistent) relations • Separation between rule language and rule composition language => to be fine-tuned with usage • A concrete syntax that doesn’t distort the concrete syntax of source model too much (work back from metamodel instance view) Shane Sendall, CUI, University of Geneva

12. Shane Sendall, CUI, University of Geneva

13. Example using Gmorph • Problem: Transform a Java package and its contained abstract classes to a UML package and UML classes that correspond to these Java classes. Shane Sendall, CUI, University of Geneva

14. LHS of Gmorph Rule Spec Metamodel: JavaNB javaP:JavaPackage Additional Selection Conditions: context JC ensure: self.isInterface = false and -- JC classes must not be interfaces self.modifier = ModifierKind::abstract -- JC classes must be abstract /javaPackage X, 0..* /classes 0..* /JC:JavaClass /declaredBy /JF:Field /features Shane Sendall, CUI, University of Geneva

15. RHS of Gmorph Rule Spec Metamodel: UML umlP:Package /ownedMember A, 0..* 0..* /owningPackage /UC:Class /AT:Attribute /ownedAttribute /class Shane Sendall, CUI, University of Geneva

16. RHS of Gmorph Rule Spec Metamodel: UML <umlP> <UC> {A, 0..*} <AT> {0..*} Shane Sendall, CUI, University of Geneva

17. LHS/RHS of Gmorph Rule Spec Metamodel: JavaNB Metamodel: UML umlP:Package javaP:JavaPackage Additional Selection Conditions: context JC ensure: self.isInterface = false and -- JC classes must not be interfaces self.modifier = ModifierKind::abstract -- JC classes must be abstract /javaPackage /ownedMember A, 0..* X, 0..* /classes 0..* 0..* /owningPackage /JC:JavaClass /UC:Class /AT:Attribute /declaredBy /JF:Field /ownedAttribute /features /class Shane Sendall, CUI, University of Geneva

18. Gmorph Rule Script Transform Rule: JavaNB-to-UML_PackageMapping (in javaP: JavaNB::Package, out umlP: UML::Package) Instance Mapping: javaP --> umlP; mapeach x in X onto a in A { x.JC --> a.UC; mapeach srcField in x.JC.features onto tgtAttr in a.ownedAttribute { srcField --> tgtAttr; } } Type Mapping: UML::Package <-> JavaNB::Package { } UML::Class <-> JavaNB::JavaClass { LHS.name <-> RHS.simpleName | LHS.isRoot <- RHS.superClassName.size() = 0 | … } Shane Sendall, CUI, University of Geneva

19. Gmorph Rule Script (cont’d) -- Type Mapping (cont’d) UML::Attribute <-> JavaNB::Field { LHS.name <-> RHS.name | LHS.scope <-> RHS.scope | LHS.visibility <-> RHS.visibility | false -> RHS.isVolatile | LHS.isDerived <- false | … } UML::VisibilityKind <-> JavaNB::VisibilityKind { LHS.vk_public <-> RHS.public | LHS.vk_protected <-> RHS.protected | LHS.vk_private <-> RHS.private | LHS.vk_package <-> RHS.package } … Shane Sendall, CUI, University of Geneva

20. Closing Remarks and Future Directions • Advantages of Gmorph • cognitive and practical advantages for concrete syntax approach (WYSIWYG) and explicit LHS and RHS (the before and after transformation view) • Patterns described as object structures works well with “imperative” style traversal Shane Sendall, CUI, University of Geneva

21. Other Approaches • IBM/DSTC QVT (logic language) • Reversibility (due to unification) • Usability, Performance? • QVTP (relation-based approach) • Nice expression of 1-to-1 language translation • Awkward for complex model evolution trans.? • Sun/Compuware QVT (logic language?) • Reversibility, modularity • Feasibility of using OCL to fully describe LHS/RHS? • UMLX • Graphical notation based on Graph Transformation • Feasibility of encoding complex trans. graphically? • Language translation transformations? Shane Sendall, CUI, University of Geneva

22. Matching Features • Additional Features • Optional matches for one or more p-elements • p-element/group of p-elements are optionally matched (matching is mandatory by default) • Maximum possible number of p-element matches are made • Multiple matches for one or more p-elements • Collection of tuples (tuple of p-elements scoped by matching container) • Transitive closure matches for one or more p-elements • Collection of tuples • Fixpoint iteration • Sequence of matches for one or more p-elements • Sequence of tuples • Ordered according to specified criteria Shane Sendall, CUI, University of Geneva

23. OMG’s Model Driven Architecture Initiative • Three levels: • Platform Independent Model(s) • Platform Specific Model(s) • Code & Deployment/Configuration Information • The big issues in automation support for MDA: • Consistency and synchronization between levels (vertical and horizontal) • Support in construction tasks • MOF 2.0 Query/View/Transformation Standardization Shane Sendall, CUI, University of Geneva

24. Model Transformation—Why Categories: • Model Translation • inter-model mapping, synthesis, splitting, and updating • Model Evolution • source model is target model (same/copy) Examples in MDA: • Model Synchronization, Refinement, and Forward and Reverse Engineering PIM PSM PSM Shane Sendall, CUI, University of Geneva

25. Model Transformation—Why Examples (cont’d) • Synthesis of views • E.g., bringing together the protocol view with the operation view to form the behavior model • Generation of Views • E.g., generating a scenario from a statemachine • Application of Software Patterns and Refactoring • E.g., applying the Singleton design pattern to a design model ProtocolView UML StateDiagram UML SequenceDiagram BehaviorModel Operation View Shane Sendall, CUI, University of Geneva

26. Model Transformation—How • Declarative approaches • Logic languages • Graph Rewriting languages • Relation/Mapping languages • Imperative, direct model manipulation approaches • <your favorite mainstream language> + API to model repository of tool • XML-based approaches • XSLT (and co.)/XMI.difference (XMI -> XMI) • Generative approaches • Template/Frame languages • Transformation generator languages • Hybrid approaches • Mix declarative and imperative styles Shane Sendall, CUI, University of Geneva

27. E A B C D C D Graph Transformation •  Graph Rewriting • LHS (graph) = left-hand side of rule = pattern • RHS (graph) = right-hand side of rule = pattern • (Interface = intersection of LHS & RHS) • Steps taken in applying a rule • match, remove, glue, embed RHS LHS Shane Sendall, CUI, University of Geneva

28. Graph Transformation Issues • Dangling Edges • Commutativity of rules • Triggering Conditions • Embedding rules • Efficient algorithms for LHS matching • Reversibility of rules (RHS  LHS) Shane Sendall, CUI, University of Geneva

29. JavaNB Metamodel Shane Sendall, CUI, University of Geneva