1. Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna, Austria phone: +43 (1) 58801-18804 (secretary), fax: +43 (1) 58801-18896 office@big.tuwien.ac.at, www.big.tuwien.ac.at Plug & Play Model Transformations – A DSL for Resolving Structural Metamodel Heterogeneities* M. Wimmer, A. Kusel, G. Kappel, W. Retschitzegger, J. Schönböck, and W. Schwinger 10 th Workshop on Domain-Specific Modeling, Reno, Nevada, USA Johannes Schönböck *This work has been partly funded by the Austrian Science Fund (FWF) under grant P21374-N13.

2. Introduction  Transformation languages are an essential prerequisite in MDE  Key challenge: resolution of recurring structural heterogeneities (resulting from applying different modeling constructs for expressing one semantic concept) MOps Motivation Introduction EvaluationFuture Work 2 Publication name:String kind:String university:String location:String LHS MM TechReport ConfPublication name:String university:String location:String RHS MM Split the object set kind=‘TechReport’ kind=‘ConfPublication’

3. Motivation  Currently model transformation languages are used to overcome structural heterogeneities  Transformation languages  Miss appropriate reuse facilities, i.e., predefined, configurable patterns  Force the transformation designer to deal with low-level intricacies of a certain language, i.e., miss abstraction facilities  Our approach: Application of abstract mappings  Specified on the basis of reusable components, called mapping operators (MOps)  Each MOp allows to resolve a certain kind of structural heterogeneity  Each MOp is typed to the core concepts of meta-metamodels, i.e., EClasses, EAttributes and EReferences, thereby achieving metamodel independence 3 Motivation Introduction EvaluationFuture Work MOps Advantages: Abstraction from code Transformation logic reuse by predefined components Reduction of specification overhead Platform independence – mapping can be executed by diverse transformation languages Advantages: Abstraction from code Transformation logic reuse by predefined components Reduction of specification overhead Platform independence – mapping can be executed by diverse transformation languages

4. Composite MOps – Blackbox View  Composite MOps provided for typical structural heterogeneities  High-level black-box mapping view to map classes only  Composite MOps consist of  Kernel MOps providing necessary expressivity  Additional Composite MOps 4 Publication name:String kind:String university:String location:String LHS MM TechReport ConfPublication name:String university:String location:String RHS MM Intention: split the object set C C Motivation Introduction EvaluationFuture Work MOps kind= ‘ TechReport ‘ kind= ‘ ConfPub ‘

5. Kernel MOps  Are the basic building blocks of each mapping  Provide expressivity for specifying model transformations, i.e., being a minimal set of required MOps to overcome structural heterogeneities  Provided for  Copying  Merging  Generating 5 C A A 2 A A C C R R 2 R R C C T 2 C C C C T 2 Cn C C A A 2 An A C C R R 2 Rn R C C R 2 0 R C A 2 0 A C T 2 0 C Motivation Introduction EvaluationFuture Work MOps * Note that splitting can be represented by several copying MOps

6. Composition of Kernel MOps 6 Copier consists of [1] C 2 C [0..*] 2AttributeMOps [0..*] 2RelationshipMOps cl C R attr [*] A C C C T 2 C C C C T R C AA C A 2 AttributeMOp RR 2 RelationshipMOp [*] [*] ref [*] attr [*] ref [*] Fixed Part of the Composite MOp  Gets pre-generated when applying the MOp Fixed Part of the Composite MOp  Gets pre-generated when applying the MOp Variable Part of the Composite MOp  Matching strategies or user-defined Variable Part of the Composite MOp  Matching strategies or user-defined C C C C C C C... Splitter consists of [2..*] Copiers Motivation Introduction EvaluationFuture Work MOps

7. Composite MOps – Whitebox View 7 Publication name:String kind:String university:String location:String LHS MM TechReport ConfPublication name:String university:String location:String RHS MM C C C C C Splitter contains Copier Composite MOps, which are automatically derived from the class binding in the black-box view Copier consists of a fixed, automatically generated class mappings and optional attribute and relationship mappings, partly generated by matching strategies Copier consists of a fixed, automatically generated class mappings and optional attribute and relationship mappings, partly generated by matching strategies C C T 2 C C C C T 2 A C A A 2 A A C A A 2 A A C A A 2 C A A 2 A A A A kind= ‘ TechReport ‘ kind= ‘ ConfPub ‘ Motivation Introduction EvaluationFuture Work MOps kind= ‘ TechReport ‘ kind= ‘ ConfPub ‘ A GeneratedUser-defined

8. iMOps – MOps dealing with Inheritance  Inheritance heavily used in Metamodels  Without inheritance between mapping, redundancy results  Inheritance between Mops  Submapping inherits the feature mappings of a supermapping  Submappings may refine the supermapping (add or override)  Inheritance between MOps is only allowed iff  Classes of the supermappings and the submappings are in an inheritance relationship in the MM or  All mappings have the same LHS class as input 8 Motivation Introduction EvaluationFuture Work MOps

9. Composite MOps – Inheritance 9 Publication name:String kind:String university:String location:String LHS MM TechReport ConfPublication university:String location:String RHS MM C C A A Publication name:String C C C T 2 C C C A A 2 A A kind= ‘ TechReport ‘ C C C T 2 C C C A A 2 A A kind= ‘ ConfPub ‘ AA A C A A 2 A A A C C T 2 C C C A A C A A 2 A A C A A 2 A A Redundant Specification Intention: inheritance hierarchy instead of an attribute Motivation Introduction EvaluationFuture Work MOps GeneratedUser-defined

10. Composite MOps – Inheritance  Diverse patterns might occur, when one MM uses inheritance whereas the other one does not  Represent well-known patterns from the area of object-relational transformations and refactorings 10 iMOpDescriptionKnown Uses A 2 I (Attribute2Inheritance) LHS MM encodes type information by attribute values; RHS MM provides explicit types in an inheritance hierarchy Replace Type Code with Subclasses One Inheritance Tree One Table I 2 A (Inheritance2Attribute) LHS MM provides explicit types in an inheritance hierarchy; RHS MM encodes type information by attribute values Replace Subclass with Fields One Inheritance Tree One Table TechReport ConfPublication university:String location:String Publication name:String Publication name:String kind:String university:String location:String Motivation Introduction EvaluationFuture Work MOps

11. Composite MOps – Inheritance 11 iMOpDescriptionKnown Uses R 2 I (Reference2Inheritance) LHS MM relates classes by references; RHS MM provides an explicit inheritance hierarchy Replace Delegation with Inheritance One Class One Table I 2 R (Inheritance2Reference) LHS MM provides explicit inheritance hierarchy; RHS MM relates classes by references Replace Inheritance with Delegation One Class One Table TechReport ConfPublication university:String location:String Publication name:String TechReport university:String ConfPublication location:String Publication name:String 1 1 publication Motivation Introduction EvaluationFuture Work MOps

12. Composite MOps – Inheritance 12 iMOpDescriptionKnown Uses C 2 I (Class2Inheritance) Independent LHS MM classes are contained in an inheritance hierarchy in RHS MM Extract Superclass One Inheritance Path One Table I 2 C (Inheritance2Class) LHS inheritance hierarchy is represented by independent RHS classes One Inheritance Path One Table TechReport university:String ConfPublication location:String name:String TechReport ConfPublication university:String location:String Publication name:String Motivation Introduction EvaluationFuture Work MOps

13. Implementation 13 AMW Editor MOps MM instance of produces implements Trafo ATL MM Executable ATL Code Executable ATL Code instance of Source MMTarget MM Mapping Platform-independent Model Platform-dependent Model MOps Motivation Introduction Evaluation Future Work

14. Evaluation – ActivityDiagram Migration Case Study of TTC 2010 14 Top-Level Composite MOps NumberPercentage Copier444,4 % VPartitioner111,1 % A2IA2I1 I2II2I1 VMerger222,2 % Total9100 % Kernel MOpsNumberPercentage C2CC2C1441,2 % Cn 2 C25,9 % 02A02A12,9 % A2AA2A514,7 % 02R02R25,9 % R2RR2R1029,4 % Total34100 % 29 (85,3 %) 2 (5,9 %) 3 (8,8 %) MOps Motivation Introduction Evaluation Future Work  Migration of UML Activity Diagrams from Version 1.4 to 2.2  # LHS classes: 15  # RHS clases: 17

15. 15 Top-Level Composite MOps Generated elements User-defined elements (despite nested composite MOps and arcs) 4 Copier4 C2Cs, 1 A2A, 3 R2Rs1 R2R 1 VPartitioner2 C2Cs, 1 A2A, 1 R2R3 R2Rs, 1 02A, 2 02Rs, 1 Function, 1 Condition A2IA2I5 C2Cs5 Conditions I2II2I3 C2Cs- VMerger2 Cn2Cs, 3 A2As, 2 R2Rs- Total (Kernel MOps)277 Evaluation – ActivityDiagram Migration Case Study of TTC 2010 MOps Motivation Introduction Evaluation Future Work

16.  Introduction of new composite MOps  Conduct several larger case studies  Introduce new composite MOps for newly occuring situations  Validation of Mappings  Enhance basic validation support currently basing on the MOps MM only  Usage of OCL constraints  Enabling Interactive Guidance  Introduce interactive guidance in two ways  Guidance „in the small“ by guiding the application of a certain MOp  Guidance „in the large“ by guiding the specification of a whole mapping  Debugging of Mappings  Currently ATL supported as execution language, introducing an impedance mismatch between specification and execution  Other transformation languages as TROPIC should be investigated 16 MOps Motivation Introduction Evaluation Future Work

17. Thank you for your attention! 17 http://www.modeltransformation.net