Model Driven Engineering (MDE) is increasingly gaining acceptance in the development of software systems as a mean to leverage abstraction and render business logic resilient to technological changes. Coordinated collections of models and modeling languages are used to describe applications on different abstraction levels and from different perspectives. In general, both models and metamodels are not preserved from the evolutionary pressure which inevitably affects almost any artifacts, possibly causing a cascade of adaptations which severely affects the modeling languages or the model population. This talk analyzes the different kinds of co-adaptations which are required, distinguishing among co-evolution in the large and in the small. In particular, the coupling between models and metamodels implies that when a metamodel undergoes a modification, the conforming models require to be accordingly co-adapted. Analogously, whenever a new version of a model is produced, the generated application may require an explicit adaptation of the generated artifacts, especially when specific assets are not directly reflected by the models and transformations, as for instance when dealing with serialized objects or with page content which is persistently stored in a database.

1. Evolution in the Large and in the Small in Model-Driven Development

2. Introduction Model Driven Engineering (MDE) is increasingly gaining acceptance in the development of software as a mean to leverage abstraction and render business logic resilientto technological changes Coordinated collections of models and modeling languages are used to describe web applications on different abstraction levels and from different perspectives Models and metamodels are not preserved from the evolutionary pressure which inevitably affects almost any artifacts, possibly causing a cascade of adaptations

4. Evolution Any modeling language can be subject to different evolutionary pressures The evolution of general-purpose modeling languages (GPMLs) is comparable to that of general-purpose languages and tend to be monotone and sparse

5. Evolution Any modeling language can be subject to different evolutionary pressures The evolution of general-purpose modeling languages (GPMLs) is comparable to that of general-purpose languages and tend to be monotone and sparseNote: problems with profiles in different versions of UML UM 0.8 UML 1.1 UML 1.4 UML 2.0 UML 2.2 UML 0.9 UML 1.3 UML 1.5 UML 2.1.2 1995 1997 2005 2000 2003 2007

6. Evolution The evolution of domain-specific modeling languages (DSMLs) is more rapid and elaborated as they tend to have a living corpus comparable to that of software Moreover, they require specific support tools which have to be adapted according to the metamodel evolution

7. Evolution The evolution of domain-specific modeling languages (DSMLs) is more rapid and elaborated as they tend to have a living corpus comparable to that of software Moreover, they require specific support tools which have to be adapted according to the metamodel evolution

8. Evolution I would like to discuss the problem of the evolution in model-driven development

9. Evolution I would like to discuss the problem of the evolution in model-drivendevelopment

10. Evolution I would like to discuss the problem of the evolution in model-drivendevelopment engineering

12. MDD

13. MDD MDE MDE MDD

14. MDD MDE MDE MDD We have not yet seen the full application deployment of MDE! [J. Bezivin keynote at SLE 2009]

15. Evolution I would like to discuss the problem of the evolution in model-drivendevelopment engineering This talk analyzes the different kinds of co-adaptations distinguishing among co-evolution in the large and in the small when a metamodel undergoes a modification, the conforming models require to be accordingly co-adapted when a new version of a model is produced, the application may require an explicit adaptation of those assets which are not directly reflected by the models and transformations

16. Summary Introduction Evolution in the Large: Metamodel Evolution (XLE) Problem-based adaptation Solution-based adaptation Metamodel change classification Transformationaladaptationofmodels Evolution in the Small: Application Model Evolution (XSE) Data migration Adaptation of specific assets Conclusions and future work

17. Summary Introduction Evolution in the Large: Metamodel Evolution (XLE) Problem-based adaptation Solution-based adaptation Metamodel change classification Transformationaladaptationofmodels Evolution in the Small: Application Model Evolution (XSE) Data migration Adaptation of specific assets Conclusions and future work

18. M3 The “language” oflanguages, eg. Ecore Meta Metamodel The modelinglanguage, typicallyusedtoengineerthe application domain, eg. UWE, WebML, beContent M2 Meta modeling architecture Metamodels M1 Instancemodelswhichrepresentproblems and solutions in the application domain Models Tools (VisualEditors) Tools (VisualEditors) Tools (VisualEditors) Systems and applicationsrealizing the solutionin the application domain, eg. portals, data-intensive web apps, etc M0 Tools (VisualEditors) Tools (VisualEditors) Tool

19. M3 M2 M1 M0 Metamodel based tools conformsTo Meta Metamodel Metamodel conformsTo Model basedOn edits implementedFor Tool

21. P2

23. P2

25. P2

27. P2

29. P2

31. P2

34. P2

36. S2

37. P2

38. P3Metamodel

39. Metamodel evolution Sometimes metamodels must be adapted, extended or amended to better capture the problems

40. Metamodel evolution Sometimes metamodels must be adapted, extended or amended to better capture the problems

41. Metamodel evolution Sometimes metamodels must be adapted, extended or amended to better capture the problems This may happen because the domains are often only partially analyzed and several instances may be left out new requirements must be considered which will result in a domain refinementor enlargement a more complete understanding of the domain is at hand

43. P2

45. P2

47. conformsTo conformsTo M3 Meta Metamodel conformsTo M2 Model Transformations to from Target Metamodel Source Metamodel TransformationLanguage Source Metamodel conformsTo conformsTo conformsTo M1 Target Model Source Model TransformationRules source target exec TransformationEngine M0

48. Model Transformations conformsTo conformsTo M3 Meta Metamodel conformsTo M2 to from Target Metamodel Source Metamodel TransformationLanguage Source Metamodel conformsTo conformsTo conformsTo M1 Target Model Source Model TransformationRules source target exec TransformationEngine M0

49. Model Transformations conformsTo conformsTo M3 Meta Metamodel conformsTo M2 to from Target Metamodel Source Metamodel TransformationLanguage Source Metamodel conformsTo conformsTo conformsTo M1 Target Model Source Model TransformationRules source target exec TransformationEngine M0

50. Model Transformations conformsTo conformsTo M3 Meta Metamodel conformsTo M2 to from Target Metamodel Source Metamodel TransformationLanguage Source Metamodel conformsTo conformsTo conformsTo M1 Target Model Source Model TransformationRules source target exec TransformationEngine M0

52. Metamodel changes classification

53. Sample Petri Net metamodel changes

54. Sample Petri Net metamodel changes Breaking and resolvable changes (extract meta-class)

55. Sample Petri Net metamodel changes Breaking and resolvable changes (extract meta-class) t1 pt1 tp1 p1 p2 p1 p2 pt2 tp2 t2

56. Sample Petri Net metamodel changes Breaking and unresolvablechange (Addobligatorymetaproperty)

57. Sample Petri Net metamodel changes weight=? weight=? pt1 tp1 pt1 tp1 p1 p2 p1 p2 pt2 tp2 pt2 tp2 weight=? weight=? Breaking and unresolvablechange (Addobligatorymetaproperty)

58. Model difference representation [TOOLS EUROPE 2007] ([Vallecillo et al 2008])

59. Metamodel difference representation Since a meta-model is a model itself, metamodel differences can be represented by exploiting the previously mentioned approach

60. Sample metamodel difference representation

61. Transformational adaptation of models Δ consist of an arbitrary combination of the atomic changes In order to distinguish them the following steps are performed: automatic decomposition of Δ in two disjoint (sub) models, ΔR and Δ¬R, which denote breaking resolvable and unresolvable changes; if ΔR and Δ¬R are parallel independent then we separately generate the corresponding co-evolutions; if ΔR and Δ¬R are parallel dependent, they are further refined to identify and isolate the interdependencies causing the interferences [EDOC 2008]

62. Transformationaladaptationofmodels: example Δ(0,1)

63. Transformationaladaptationofmodels: example Restrictmetapropertychange Extractmetaclasschanges Δ(0,1)

64. Transformationaladaptationofmodels: example moduleH_R; createOUT : ATL from Delta : KM3Diff; ruleCreateRenaming { … } ruleCreateExtractMetaClass{ … } … HR ΔR(0,1)

65. Transformationaladaptationofmodels: example moduleH_R; createOUT : ATL from Delta : KM3Diff; ruleCreateRenaming { … } ruleCreateExtractMetaClass{ … } … HR module CTR; create OUT : MM1 from IN : MM0; … rulecreatePTArc(s : OclAny, n : OclAny) { … } rulecreateTPArc(s : OclAny, n : OclAny) { … } ΔR(0,1) CTR

66. Transformationaladaptationofmodels: example t1 pt1 tp1 CTR p1 p2 p1 p2 pt2 tp2 t2

67. Transformationaladaptationofmodels: example module H_NR; createOUT : ATL from Delta : KM3Diff; rule CreateRestrictMetaproperty{ … } ruleAddObligatoryMetaclass{ … } … Δ¬R(0,1) H¬R

68. Transformationaladaptationofmodels: example module H_NR; createOUT : ATL from Delta : KM3Diff; rule CreateRestrictMetaproperty{ … } ruleAddObligatoryMetaclass{ … } … Δ¬R(0,1) H¬R module CTR; create OUT : MM1 from IN : MM0; …helper context MM2!Net def:createPlaceInstances() : Sequence (MM2!Place) = if (thisModule.placeInstances < 1) then thisModule.createPlace(self) ->asSequence() ->union(self.createPlaceInstances()) else Sequence{} endif; … CT¬R

69. Parallel dependent modifications The automatic co-adaptation of models relies on the parallel independence of breaking resolvable and unresolvable modifications, or more formally ΔR|Δ¬R = ΔR;Δ¬R +Δ¬R;ΔR where + denotes the non-deterministic choice

70. Parallel dependent modifications The automatic co-adaptation of models relies on the parallel independence of breaking resolvable and unresolvable modifications, or more formally ΔR|Δ¬R = ΔR;Δ¬R +Δ¬R;ΔR where + denotes the non-deterministic choice Bad news: the parallel independence of changes is not assured, ie. multiple changes can be interdependent one another

71. Parallel dependent modifications

72. Parallel dependent modifications The differences between MM2 and MM0 are not parallel independent (although the sub steps MM0−MM1 and MM1 − MM2 are directly manageable) The interdependenciesbetween the atomic changes in MM2 − MM0 have to be isolated (i.e. the attribute weight of the Arcmetaclass of MM2)

73. Resolving dependences We analyzed the kind of interdependencies among breaking resolvable and breaking unresolvable changes We found out that these interdependencies do not depend on the specific metamodel, rather only on the meta metamodel (eg. Ecore, MOF, KM3) [ICMT 2009]

74. Resolving dependences Sufficient criteria have been given to establish the correct scheduling of the conflicting changes

75. Resolving dependences An alternative approach ([1]) is based on a lazy evaluation mechanism which queues up adaptations which require unavailable information We have found that for KM3, Ecore, and MOF interdependencies are not circular and that they only depend on the meta metamodel This implies that it is possible to find the exact scheduling of the adaptation steps w/o queuing them [1] Narayanan, Levendovszky, Balasubramanian, Karsai: Domain ModelMigrationtoManageMetamodelEvolution, MoDELS 2009

76. Approach This is a general approach which can be applied to any metamodel (so far it works for KM3 metamodels, Ecore and MOF are under study), it permits the management of complex metamodel modifications (in contrast with current approaches) the complete automatic adaptation of models (breaking non resolvable via transformation refinements) We are currently working on the migration of UWE models

77. Summary Introduction Evolution in the Large: Metamodel Evolution (XLE) Problem-based adaptation Solution-based adaptation Metamodel change classification Transformationaladaptationofmodels Evolution in the Small: Application Model Evolution (XSE) Data migration Adaptation of specific assets Conclusions and future work

78. Solution-based adaptation The chosen generic modeling platform – intended as a set of languages, systems, and transformation paradigms – may affect the metamodel life-cycle In fact, sometimes metamodels must be changed in order to permit solutions which are otherwise not admissible

79. beContent beContent is an model-driven platform for designing and maintaining web applications A beContent model consists mainly of the declarative and coordinated specification of three different concerns: the data view is the description of the relational model of the data, in essence it describes the metadata of the application; the content view describes the data sources and how the content is retrieved and aggregated in pages; and finally the interaction view specifies how to manipulate the information entered in the forms, the validation constraints, and additional information which may affect the interaction between the user and the application.

80. beContent ECLIPSE GMF AMMA TCS beContentMetamodel ECLIPSE Ecore ACCELEO AMMA ATL ACCELEO

81. beContent architecture BML BTL round-tripping ECLIPSE GMF AMMA TCS ECLIPSE GMF AMMA TCS beContentMetamodel beContentMetamodel ECLIPSE Ecore ECLIPSE Ecore M2C M2M ACCELEO AMMA ATL ACCELEO AMMA ATL M2C M2C PHPMySQL ACCELEO ACCELEO ACCELEO J2EE/Liferay .NET

82. BML – beContent Modeling Language [demo at ICWE 2009]

83. BMM – beContentMetamodel

84. BMM – beContentMetamodel

85. BMM – beContentMetamodel . . . Metamodel fragment Model fragment

86. Problem: a simple text generation Generate a text file containing source code based on information which is retrieved from different instances of the same metaclass

87. Problem: a simple text generation . . . ...

88. Problem: a simple text generation Generate a text file containing source code based on information which is retrieved from different instances of the same metaclass This is not easy as it may appear as templating languages (in contrast with M2M languages) do not always have the querying power of OCL In particular, this can be achieved either using external Java helpers or changing the metamodel in such a way these instances must be within a container

89. Refactoring the metamodel MM v1.0 MM v2.0

90. Problem: a simple text generation In this scenario, a simple change of the metamodel from v1.0 to v2.0 is already pretty troublesome as it would require the adaptation of the models, which can be performed automatically as shown before the manual adaptation of the tools A possible workaround …

91. Hiding the metamodel refactoring Δ Metamodel v1.0 Metamodel v2.0 conformsTo conformsTo adapt(Δ) Model (v2.0) Model (v1.0) M2T Source code

92. Evolution in the large – open questions Automating the co-adaptation of models is only one aspect of the evolution of metamodels, nevertheless it is already very complex and presents open questions Metamodel difference calculation: it is very difficult, none of the available approaches are really satisfactory because of domain semantics, similarity metrics, etc Update: we are having interesting result by combining EMF Compare and ECL for Ecoremetamodels differencing Overriding default adaptation with ad-hoc refactorings Semantics preserving ? Validation, everybody is very keen on keeping her/his models secret :-)

93. Summary Introduction Evolution in the Large: Metamodel Evolution (XLE) Problem-based adaptation Solution-based adaptation Metamodel change classification Transformationaladaptationofmodels Evolution in the Small: Application Model Evolution (XSE) Data migration Adaptation of specific assets Conclusions and future work

94. Evolution in the small Manual modifications Model (v1.0) Model (v2.0) T T System” System’

95. Evolution in the small Regenerating the whole system may require lots of time which reduce the usability for the designers, possibile solutions are incremental/live transformations Not all the aspects can be generated or derived by the models, eg. a model modification may require a data migration procedure a consistency check of the graphic templates Typically transformations encode knowledge about the underlying platform and architecture, eg. persistent classes and serialized objects in Java must be in sync

96. Evolution in the small Δ M1 M2 T T System2 System1

97. Evolution in the small Δ M1 M2 T T System2 System1 uses uses data1 data2

98. Evolution in the small Δ M1 M2 T T System2 System1 uses uses data1 data2 migration (evolutionrollbackauxfunctions)

99. Evolution in the small Δ M1 M2 T T System2 System1 T’ uses uses data1 data2 migration (Δ)

100. Evolution in the small: beContent example Manual modifications Simple data refactoring birthday is deleted a new reference is added

101. Evolution in the small: beContent example Δ

102. Evolution in the small: beContent example This is a special case in beContent as the underlying framework is able to detect new tables to be created

103. Evolution in the small: beContent example ALTER TABLE Person ADD (zodiac INT UNSIGNED NOT NULL); ALTER TABLE PersonDROP COLUMN birthday;

104. Evolution in the small: beContent example As the difference model is a model, it is possible to generate anything based on its content eg. a configuration for a migration wizard to assist the designer

105. Conclusions Using DSML (in contrast with a GPML) has the advantage to increase the degree of automation by exploiting the metamodeling hierarchy The evolution of models and metamodels is almost unavoidable if they are inherently part of the process (as both main actors and instruments) In order to automate the coupled-evolution which takes place at different levels in the metamodeling hierarchy is necessary to have a formal representation of model differences

106. Thank you!

107. Some References A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, AutomatingCo-evolution in Model-DrivenEngineering. Procs. EDOC 2008, Munich, Germany A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, Meta-modelDifferencesforSupportingModelCo-evolution. Procs. MoDSE 2008, Atene, Greece A. Cicchetti, D. Di Ruscio, A. Pierantonio, A MetamodelIndependentApproachtoDifferenceRepresentation, Procs. TOOLS EUROPE 2007, Zurich, Switzerland A. Cicchetti, D. Di Ruscio, and A. Pierantonio. Managingdependentchanges in coupledevolution, toappear in Procs. ICMT 2009, Zurich, Switzerland D.S.Kolovos, D. Di Ruscio, R.F. Paige, A. Pierantonio. DifferentModelsforModelMatching: An analysisofapproachestosupportmodeldifferencing, Procs. CVSM'09, Vancouver, Canada