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 On using In-place Transformations for Model Co-evolution* M. Wimmer, A. Kusel, J. Schönböck, W. Retschitzegger, W. Schwinger, and G. Kappel 2nd International Workshop on Model Transformation with ATL Johannes Schönböck *This work has been partly funded by the Austrian Science Fund (FWF) under grant P21374-N13.

2. Introduction 2  Metamodel evolution and model co-evolution are essential for the adoption of MDE in practice Approach Motivation Introduction ExampleFuture Work Original Metamodel Original Models conform to Revised Metamodel evolution Co-evolved Models conform to co-evolution How to perform the co-evolution process?

3. Current Approaches for Co-evolution (1/2) Dedicated Co-evolution languages such as COPE* 3 Original Metamodel Original Models conform to Revised Metamodel Co-evolved Models conform to co-evolution 1 1 User has to learn a new language Approach Motivation Introduction ExampleFuture Work *M. Herrmannsdoerfer, S. Benz, and E. Juergens. COPE - Automating Coupled Evolution of Metamodels and Models. In Proceedings of the 23rd European Conference on Object-Oriented Programming (ECOOP'09), pages 52-76. Springer-Verlag, 2009.

4. Current Approaches for Co-evolution (2/2) Employment of M2M transformation languages 4 2 2 Original Metamodel Original Models conform to Revised Metamodel Co-evolved Models conform to co-evolution Copying of unchanged elements is necessary Approach Motivation Introduction ExampleFuture Work

5.  Employment of in-place transformations for co-evolution No new language has to be learned No rules for copy operations are needed  Prerequisite for this approach Allow all models (orginal and co-evolved) to be conformant to one metamodel (merge of original and evolved metamodel)  Proposed Process (work in progress) Approach (1/2) 5 Automatic Metamodel Merge Co-evolution by in-place transformation Automatic check-out transformation 1 1 2 2 3 3 Approach Motivation Introduction ExampleFuture Work

6. Approach (2/2)  Step 1: Automatic Metamodel Merge  Step 2: Co-evolution by in-place transformation Elements get only added but never deleted (done by step 3) Therefore a merge of the original and the co-evolved model arises  Step 3 : Automatic check-out transformation 6 Original MM Evolved MM Original MM  Evolved MM Original Model Original Model  Co-evolved Model Co-evolved Model load check-out merge 1 1 2 2 3 3 In-place trafo for co-evolution conforms to Approach Motivation Introduction ExampleFuture Work

7. Evolution Example 7 NamedElement attributes 0..* isAbstract: Boolean Class name : String Attribute ID_AttributeDesc_Attribute Reference upperMult: Int lowerMult: Int type : String references type 0..* 1..1 opposite extends 0..1 NamedElement attributes 0..* isAbstract: Boolean Class name : String AttributeReference upperMult: Int lowerMult: Int type : String id: Boolean type 1..1 superClass 0..1 Association refEnds2..3 Original Metamodel Evolved Metamodel Modeling of ternary Associations 1 1 Change Attribute Type dynamically Inheritance Feature renamed to superClass to be more platform-independent 2 2 3 3 Approach Motivation Introduction Example Future Work

8. Step 1 – Automatic Metamodel Merge (first proposal) (1/2)  Classes Are merged, if they exhibit the same name If classes are merged, the merged class gets the union of the features and superclasses of the original classes  Features Are only merged, if they are fully equivalent, i.e., same name, same type, same multiplicity constraints, same unique constraints, … 8 Original MM Evolved MM Original MM  Evolved MM Original Model Original Model  Co-evolved Model Co-evolved Model load check-out merge 1 1 2 2 3 3 In-place trafo for co-evolution conforms to Approach Motivation Introduction Example Future Work

9. Step 1 – Automatic Metamodel Merge (2/2) 9 opposite Original MM  Evolved MM NamedElement attributes 0..* isAbstract: Boolean Class name : String AttributeReference upperMulti: Int lowerMulti: Int type : String id: Boolean type 1..1 superClass 0..1 Association refEnds2..3 ID_AttributeDesc_Attribute extends 0..1 1..1 references 0..*  Result of merge phase for the example Approach Motivation Introduction Example Future Work

10. Step 2 – Co-evolution by in-place Transformation (1/4)  Usually a co-evolution transformation consists of Create Operations, Update Operations and Delete Operations  The proposed approach needs only create (adding) and update operations, since delete operations are realized during the final check-out transformation, in case of projection  Only selection scenario requires delete operation 10 Original MM Evolved MM Original MM  Evolved MM Original Model Original Model  Co-evolved Model Co-evolved Model load check-out merge 1 1 2 2 3 3 In-place trafo for co-evolution conforms to Approach Motivation Introduction Example Future Work

11. Step 2 – Co-evolution by in-place Transformation (2/4) 11 NamedElement attributes 0..* isAbstract: Boolean Class name : String Attribute ID_AttributeDesc_Attribute Reference upperMult: Int lowerMult: Int type : String references type 0..* 1..1 opposite extends 0..1 NamedElement attributes 0..* isAbstract: Boolean Class name : String AttributeReference upperMult: Int lowerMult: Int type : String id: Boolean type 1..1 superClass 0..1 Association refEnds2..3 Original Metamodel Evolved Metamodel Modeling of ternary Associations 1 1 Change Attribute Type dynamically Inheritance Feature renamed to superClass to be more platform-independent 2 2 3 3 NAC LHS ref1 : Reference ref2 : Reference 1 : opposite Rule 1 assoc1: Association name = x+ “2“ + y 3 : refEnds RHS ref1 : Reference ref2 : Reference 4 : refEnds assoc2 : Association 2 : opposite name = x name = y 2 : opposite1 : opposite ref1 : Reference ref2: Reference 5 : refEnds6 : refEnds Rule 2 LHS cl1 : Class att2 : Attribute name = x type = t id = true 2 : attributes cl1 : Class att1: ID_Attribute RHS 1 : attributes name = x type = t Rule 3 LHS cl1 : Class att2 : Attribute name = x type = t id = false 2 : attributes cl1 : Class att1: Desc_Attribute RHS 1 : attributes name = x type = t Rule 4 LHS superCl : Class subCl: Class 2 : superClass RHS superCl : Class subCl: Class 1 : extends Approach Motivation Introduction Example Future Work

12. module CoEvolution; create OUT : MM refining IN : MM; --Rule 1 rule GenerateAssociations { from ref1 : MM!Reference, ref2 : MM!Reference (ref1.opposite = ref2) -- missing NAC to dummy : MM!Reference, assoc : MM!Association (refEnds <- Set{ref1,ref2}) } --Rule 2 rule GenerateAttributes { from id_att : MM!ID_Attribute to dummy : MM!ID_Attribute, att : MM!Attribute ( name <- id_att.name, type <- id_att.type, id <- true, class <- id_att.class ) } Step 2 – Co-evolution by in-place Transformation (3/4) ATL Refinement Mode as in-place transformation language 12 Too many Association objects get generated, since no unique lazy rule is allowed in the ATL refinement mode (and no imperative code) Approach Motivation Introduction Example Future Work Old objects must be explicitly kept C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Original Model C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Model after Rule 1 A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Model after Rule 2 A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds I3:Attribute name=‘id‘ type=‘Integer‘ id=true attributes

13. Step 2 – Co-evolution by in-place Transformation (4/4) ATL Refinement Mode as in-place transformation language 13 --Rule 3 rule GenerateAttributes { from id_att : MM!Desc_Attribute to dummy : MM!Desc_Attribute, att : MM!Attribute ( name <- id_att.name, type <- id_att.type, id <- false, class <- id_att.class ) } --Rule 4 rule setSuperClassRefs { from c1 : MM!Class to c2 : MM!Class ( superClass <- c1.extends ) } Old objects must be explicitly kept Approach Motivation Introduction Example Future Work C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Model after Rule 3 A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds I3:Attribute name=‘id‘ type=‘Integer‘ id=true attributes I4:Attribute name=‘name‘ type=‘String‘ id=false attributes C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Model after Rule 4 A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds I3:Attribute name=‘id‘ type=‘Integer‘ id=true attributes I4:Attribute name=‘name‘ type=‘String‘ id=false attributes superClass

14. Step 3 – Automatic Check-out Transformation  Is responsible for pruning the elements that no longer covered by the evolved metamodel, i.e., out-dated model elements 14 Original MM Evolved MM Original MM  Evolved MM Original Model Original Model  Co-evolved Model Co-evolved Model load check-out merge 1 1 2 2 3 3 In-place trafo for co-evolution conforms to Original MM Check-out load Original Model Elements Original MM  Evolved MM Evolved MM Added Elements stemming from the Evolution In-place Trafo for co-evolution Approach Motivation Introduction Example Future Work C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references Model after check-out transformation A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds I3:Attribute name=‘id‘ type=‘Integer‘ id=true attributes I4:Attribute name=‘name‘ type=‘String‘ id=false attributes superClass

15.  Merge algorithm can be implemented by using an ATL M2M transformation  Based on the Ecore meta-metamodel  Automatically generated  In-place transformation rules  Restrictions of ATL refinement mode prohibits specification of co- evolution rules  No queryable execution state, no type change, no imperative code  Verification of approach using AGG graph transformation language  Check-out transformation can be implemented using a Higher-Order transformation  Generates matched rules for classes of the evolved model  Feature assignments for corresponding features Lessons Learned of Example 15 Co-evolution rules in AGG Approach Motivation Introduction Example Future Work

16.  Investigate on improving ATL Refinement Mode  Improvement of Merging Algorithm  EMF Compare to find renames (and automatic derivation of copy operation)  Generate skeleton transformations by tracking and analyzing the metamodel edit operations  Application of the approach to more complex evolution scenarios  Case studies with students of MDE course 16 Approach Motivation Introduction Example Future Work

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

18. Backup 18

19. 19 C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Original Model

20. 20 C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Model after Rule 1 A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds

21. 21 C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Model after Rule 2 A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds I3:Attribute name=‘id‘ type=‘Integer‘ id=true attributes

22. 22 C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Model after Rule 3 A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds I3:Attribute name=‘id‘ type=‘Integer‘ id=true attributes I4:Attribute name=‘name‘ type=‘String‘ id=false attributes

23. 23 C1:Class name=‘Person‘ isAbstract = true C2:Class name=‘Man‘ isAbstract=false C3:Class name=‘Woman‘ isAbstract=false extends R1:Reference name=‘wife‘ upperMulti=1 lowerMulti=0 R2:Reference name=‘husband‘ upperMulti=1 lowerMulti=0 opposite references type I1:ID_Attribute name=‘id‘ type=‘Integer‘ I2:Desc_Attribute name=‘name‘ type=‘String‘ attributes Model after Rule 4 A1:Association name=‘wife_husband‘ A2:Association name=‘husband_wife‘ refEnds I3:Attribute name=‘id‘ type=‘Integer‘ id=true attributes I4:Attribute name=‘name‘ type=‘String‘ id=false attributes superClass