This document discusses managing co-evolution in model-driven engineering (MDE). It defines that metamodels are living entities that change over time, and when metamodels change, related artifacts like models, transformations, and generic tools must adapt to remain valid. It identifies different relations between metamodels and artifacts that can be affected by metamodel changes, like the conformance of models to metamodels. It also classifies different types of changes and adaptations that may be needed. The document then introduces EMFMigrate, a programmatic approach using a domain-specific language to specify migration strategies using rules to adapt affected artifacts when metamodels change in a consistent, reusable way.

1. What is needed for managing co-evolution in MDE? Dipartimento di InformaticaUniversità degli Studi dell’Aquila – Italy alfonso.pierantonio@univaq.it Davide Di Ruscio, Ludovico Iovino, Alfonso Pierantonio

2. Outline Introduction Scenario Changing a metamodel does not come alone: Metamodel/model co-evolution Metamodel/transformation co-evolution Metamodel/generic artifacts co-evolution Co-evolution dimensions EMFMigrate Migration programs and rules Example Conclusions Slideshare: http://slidesha.re/jvOm9m IWMCP2011 - June 30, 2011 - Zurich

3. Introduction In MDE a domain-specific modeling language (DSML) consists of a collection of coordinated models abstractand concrete syntaxes of the language further aspects including semantic mapping(s) The abstract syntax of DSMLs is typically expressed in terms of metamodels EclipseModelingFramework (EMF) 3 IWMCP2011 - June 30, 2011 - Zurich

4. Introduction Metamodels are the building blocks of any model development environment The entities defined upon metamodels include Models Model and Text Transformations Syntax-directed and diagrammatic editors Model differencing and analysis tools Given a metamodel a number of metamodel-dependent artifacts are usually designed and implemented, eg. GMF Editors Code generators IWMCP2011 - June 30, 2011 - Zurich

5. Scenario IWMCP2011 - June 30, 2011 - Zurich

6. Scenario IWMCP2011 - June 30, 2011 - Zurich Metamodels are living entities which are constantly changing

7. Scenario IWMCP2011 - June 30, 2011 - Zurich Whenever a metamodel undergoes modifications, all the corresponding entities must be accordingly adapted in order to remain valid.

8. Changing a metamodel does not come alone A number of relations which characterize the kind of rippleeffecthavebeenidentified conformsTothe conformance relation betweenmetamodels and models domainConformsTothe relation between a transformation and the metamodels it operates on dependsOnanyarbitrary relation between a metamodel and modeling artifacts (eg. GMF models or Java code) IWMCP2011 - June 30, 2011 - Zurich

9. Changing a metamodel does not come alone A number of relations which characterize the kind of rippleeffecthavebeenidentified conformsTothe conformance relation betweenmetamodels and models domainConformsTothe relation betweena transformation and the metamodels it operates on dependsOnany arbitrary relation between a metamodel and modeling artifacts (eg. GMF models or Java code) IWMCP2011 - June 30, 2011 - Zurich When a metamodel changes these relations might be affected and the corresponding artifacts might be no longer valid

10. conformsTo: Metamodel/model co-evolution Issue Changes in the metamodel might compromise the validity of the existing models which need to be consistently adapted to restore the conformance relation Classification of changes non-breaking changes breaking and resolvable changes breaking and unresolvable changes IWMCP2011 - June 30, 2011 - Zurich [EDOC 2008]

11. domainConformsTo: Metamodel/Transformation co-evolution Issue inconsistencies arise when elements in the considered transformation no longer satisfy the domain conformance relation Classification of adaptations fully automated partially automated fully semantic [Levendovszkyet al] IWMCP2011 - June 30, 2011 - Zurich

12. dependsOn: Metamodel/genericartifactco-evolution Issue Each different tool relies on a different dependsOn relation which is assumed by the tool implementation, eg GMF editors are developed starting from a set of models coupled with the considered metamodel Classification adaptation result Unsound, the adapted artifact is broken Uncomplete, the adapted artifact lacks capabilities Sound, the adapted artifact is complete IWMCP2011 - June 30, 2011 - Zurich [SLE 2010]

13. Co-evolution dimensions IWMCP2011 - June 30, 2011 - Zurich

14. Existing approaches Existing approaches are based on different techniques for migrating the affected artifacts operation-based pros: Locality: artifact and metamodel may be migrated together cons: Change recorders are required, thus change traces can be unavailable Redundancy in multiple migrations state-based pros: Interoperability among different platforms cons: Differencing accuracy, heuristics instead of semantics Usually based on HOTs, lack of flexibility IWMCP2011 - June 30, 2011 - Zurich

15. It is a programmatic approach consisting of a DSLfor specifying migration strategies for any kind of artifacts The migration strategies can be specified and collected in libraries, each formalizing a specific relation conformsTo domainConformsTo dependsOn Extension and customization are possible by means of linguistic features (refine, override) for deviating from default migration strategies IWMCP2011 - June 30, 2011 - Zurich

16. IWMCP2011 - June 30, 2011 - Zurich

17. Migration After a metamodeldifference (Delta) iseithercalculated or defined, the migrationstrategydefinedby a library (and itssubsequentextensions) ofrules can beusedtoadapt the correspondingartifacts IWMCP2011 - June 30, 2011 - Zurich

18. A migration program While adapting an artifact A conforming to MM, a rule mri is applied whenever the guardiis detected on the metamodel Delta IWMCP2011 - June 30, 2011 - Zurich rewriting rules, in-place transformations

19. Migration rules The body of a migration rule consists of a sequence of rewriting rules like the following s[guard] -> t1[assign1]; t2[assign2]; …tn[assignn] where s, t1, …,tnrefer to metaclasses of the considered artifact metamodel(e.g. ATL, TCS), and guardis a booleanexpression which has to be true in order to rewrite swith t1, t2, and tn. IWMCP2011 - June 30, 2011 - Zurich

20. A simple ATL migrationrule IWMCP2011 - June 30, 2011 - Zurich

21. IWMCP2011 - June 30, 2011 - Zurich

22. Rule guard, it detects change patterns on the metamodel delta IWMCP2011 - June 30, 2011 - Zurich

23. rewriting guard, it detects patterns on the artifact to be adapted IWMCP2011 - June 30, 2011 - Zurich

24. IWMCP2011 - June 30, 2011 - Zurich

25. Conclusions Co-evolution between metamodel/model has been intensively investigated over the last years Co-evolutionbetweenmetamodel/modelis just onepossible case, plentyofothercases are demandingsupport Using different techniques for different cases is still possible but requires too much effort, reduces regularity, and demands familiarity with too many notations and systems We proposed EMFMigrate a comprehensive and generic approach for any kind of co/evolution problem in MDE IWMCP2011 - June 30, 2011 - Zurich

26. Whatisneeded? A uniform and consistentapproachfordealingwithanykindofdependency in model-drivendevelopmentenvironment A programmaticyetdeclarativeapproachtodefine default migrationstrategies Extensionmechanismforcustomizing default behavioraccordingtomigrationrequirement Toolsupport and integration, usability, etc. IWMCP2011 - June 30, 2011 - Zurich

27. What is needed for managing co-evolution in MDE? Dipartimento di InformaticaUniversità degli Studi dell’Aquila – Italy alfonso.pierantonio@univaq.it Davide Di Ruscio, Ludovico Iovino, Alfonso Pierantonio Questions ?