This is my lecture at the MDE Diploma of the Ecole des Mines in Nantes

1. Model Evolution and Versioning Alfonso Pierantonio Dipartimento di InformaticaUniversità degli Studi dell’Aquila alfonso.pierantonio@univaq.it

2. 2 Objectives Model-DrivenEngineeringrequires mature and adequatemodel management in ordertoachieveits full potential. Thiscannotleaveaside the problemofmodeldifferencing. Thislecturewillprovideinsights on the problemofmodeldifferencingoutlining the potentialsofitsapplication.

3. 3 Modeldifferences and evolution Modeldifferences and evolution The ability to detect and represent structural changes in subsequent versions of a (meta) model

4. 4 Modeldifferences and evolution Modeldifferences and evolution There is no way to understand the rationale behind these modifications

5. 5 Modeldifferences and evolution Modeldifferences and evolution

6. 6 Modeldifferences and evolution Modeldifferences and evolution ? Q1: How to detect such evolution ?

7. 7 Modeldifferences and evolution Modeldifferences and evolution ? Q2: How to represent it in sucha way it can be conveyed to model transformations ?

8. 8 Modeldifferences and evolution Modeldifferences and evolution ? Q3: Which kind of applications can be realized by representing the evolution by means of models ?

9. 9 Modeldifferences and evolution A satisfactory representation of differences can enables a wide range of applications Modeldifferences and evolution

10. 10 Modeldifferences and evolution Modeldifferences and evolution Model evolution may require the adaptation of artefacts which are not directly generable from the model Metamodel evolution requires models, transformations, and tools (eg. GMF editors) to be consistently adapted

12. Indeed, the metamodelarchitecture and the formalrelationshipsamongthe layers can fruitfullybeexplotedtothisend

13. conformance, consistencyrelations amongmodelsAchieving the potential

14. Achieving the potential 12 Achieving the great Potential.

15. 13 Achieving the potential Turninginto a nightmare!

16. Summary Model differences Matching Algorithm Conflict Management Evolution in the large (model evolution) in the small (metamodel evolution) Conclusions 14

17. Modeldifferences Model Evolution and Versioning 15

18. Model Differences Introduction Representation Requirements Model Difference Approaches Edit Script, Coloring Representing Model Differences Difference Metamodel, Difference Models Difference Application Patches Operations with Differences Dual, Sequential and Parallel Composition Conclusions and Future Work

19. Introduction The problem of model differences is intrinsically complex and requires specialized algorithms and notations Any solution should necessarily present a high degree of separation between three relevant aspects calculation, a procedure, method or algorithm able to compare two distinct models representation, the outcome of the calculation must be represented in some form visualization, model differences often requires to be visualized in a human-readable notation In currentproposals the distinctionbetween the three aspects are often blurred thus compromising the adoption of generic modelling techniques

20. Introduction The problem of model differencing can be decomposed in two subsequent phases

21. Introduction The problem of model differencing can be decomposed in two subsequent phases 1 Calculation

22. Introduction The problem of model differencing can be decomposed in two subsequent phases 1 2 Calculation Representation

23. Introduction The outcome used for further applications by means of automated transformations and analysis 1 2 3 Calculation Representation Applications : Transformation & Analysis

24. Introduction Model Difference Calculation 1

25. Introduction Model DifferenceRepresentation 2

26. Introduction Thus, the aim is to find a suitable representation for model differences which is independent from the metamodel the models are conforming to abstracts from the calculation method used for differencing the models, regardless whether it is based on persistent ids or structural similarity the outcome of a differencing operation must be usable in automated transformation or analysis

27. Representation Requirements

28. Approaches The representation of model differences can be divided into two main techniques Directed deltas, represent delta documents as the sequence of the operations needed to obtain the new version from the old one eg. edit scripts Symmetric deltas, show the result as the set of differences between the two compared versions eg. coloring [Mens 2002]

29. Approaches – Example version 1 (M1)

30. Approaches – Example version 2 (M2) version 1 (M1)

31. Approaches – Example version 2 (M2) version 1 (M1)

32. Approaches – Edit Scripts (eg [Porres et al 2003]) Sequence of actions able to reconstruct the final model starting from the initial one Cons: operational, proprietary format, tool dependent, lengthy, reduced readability

33. Approaches – Coloring (eg [Ohst et al 2003]) Declarative and intuitive Cons: does not hold the following properties Minimalistic Self-contained Transformative Cons: moreover very verbose updates difficult to represent

34. Approaches – Summary

35. Difference Metamodel (1/3) Given two models M1 and M2 conforming to a metamodelMM, their difference (M2 – M1) conforms to a metamodelMMD that is derived from MM The approach permits the representation of the following modifications additions: new elements are added to the final model deletions: some of the existing elements are deleted changes: a new version of the model can consist of some updates of already existing elements

36. Difference Metamodel (2/3)

37. Difference Metamodel (3/3) MM MM2MMD MMD

38. Sample UML models Version 1 Version 2

39. Sample UML models u Version 1 The abstract class HTMLDocElemhas been added Version 2

40. Sample UML models Version 1 The operation dump() has been moved to HTMLDocElem v Version 2

41. Sample UML models w Version 1 The HTMLList class became subclassof HTMLDocElem Version 2

42. Fragment of the Difference Model The abstract class HTMLDocElemhas been added

43. Fragment of the Difference Model The abstract class HTMLDocElemhas been added The operation dump()has been moved from HTMLDocto HTMLDocElem

44. Fragment of the Difference Model The abstract class HTMLDocElemhas been added The operation dump() has been moved from HTMLDoc to HTMLDocElem The HTMLList class became subclassof HTMLDocElem

45. Difference Application Once differences are calculated and represented, they can be applied over models as patches The difference application is intended to “reconstruct” the final model starting from the initial one “patch” any model conforming to the base metamodel for reproducing the modifications

47. patch: MMD  MM  MM

49. Difference Application Rule AddedMC2MC Each AddedMC induces a new MC instance in M2 and the corresponding structural features according to  Rule ChangedMC2MC It updates MC elements in M1 according to the ChangedMCelements in  Rule UnchangedMC2MC It serves for propagating in M2 the context of M1, ie what is left unchanged by  No rules are required for DeletedMC elements since they are simply ignored by the UnchangedMC2MCrule

50. Overall Scenario MM2MMD MM patchtransformation MMD2ATL HOT MMD

51. Overall Scenario MM2MMD MM M2 conformsTo conformsTo M1 patchtransformation MD conformsTo MMD2ATL HOT MMD

52. Difference Operators Dual Given a difference model, it is useful to automatically define its inverse, ie if (M2 – M1) =  the dual -1is such that patch-1(M2) = M1  -1

53. Difference Operators Sequential Composition two or more subsequent modifications can be grouped in a single difference model given 1 = (M2 – M1) and 2 = (M3 – M2) then the sequential composition 1 ; 2 is defined in such a way that patch1; 2 = patch2 patch1 Parallel Composition distributed manipulations of the same artifacts can be merged in a model difference as long as they are parallel indipendent

54. Model Versioning - Patches An interesting scenario discloses when arbitrary models are allowed as input for difference application

55. Model Versioning - Patches An interesting scenario discloses when arbitrary models are allowed as input for difference application

56. Model Versioning - Patches An interesting scenario discloses when arbitrary models are allowed as input for difference application ?

57. Model Versioning - Patches The application of manipulations as patches demands for several properties Self-containedness: The representation of differences should contain enough information to be applied to arbitrary inputs Minimality: The representation should not contain too much information thus locking the application to the initial context Transformability: The application engine should allow several degrees of fuzziness, i.e. it should be able to reproduce a certain modification to appropriate arbitrary entities

58. Overall Scenario MM2MMD MM M2 conformsTo conformsTo M1 Application Model patchtransformation MD conformsTo MMD2ATL HOT MMD

59. Overall Scenario MM2MMD MM M2 conformsTo conformsTo M1 Application Model patchtransformation MD conformsTo MMD2ATL HOT MMD

61. Model Differences Model differences are crucial for general model management and can disclose numerous opportunities Once differences are represented as first-class entities, a number of operations can be defined on them patches, dual, binary compositions, impact evaluation, etc A proof of concept has been implemented on the Eclipse/AMMA platform (http://www.eclipse.org/m2m/atl/usecases/MMIndApproachtoDiffRep)

62. What comes next ? One of the problems of generic differencing methods is that matching algorithms are not always accurate since they are agnostic of the metamodel underlying semantics Formalizing semantics is difficult, thus heuristics can provide some ad-hoc improvement As soon we consider parallel composition the problem conflict specification, detection, and resolution Parallel composition may give place to conflicts whenever the differences are not parallel independent Depending on the process stage we may be interested in tuning false positives and negatives

63. Summary Model differences Matching Algorithm Conflict Management Evolution in the large (model evolution) in the small (metamodel evolution) Conclusions 60

64. Model matching Model Evolution and Versioning 61

65. Outline Introduction Model matching Static Identity-Based Matching Signature-Based Matching Similarity-Based Matching Language-Specific Case study Conclusions

66. Introduction Differencing mechanisms for supporting the evolution of model-based artifacts are becoming crucial Document comparison algorithms provided by version control systems like CVS, and SVN have been shown to be inadequate Calculating model differences is a difficult task since it relies on model matching which can be reduced to the graph isomorphism problem No efficient (i.e., polynomial-bound) algorithm for graph isomorphism is known and it has been conjectured that no such algorithm can exist [Ronald C. Read, Derek G. Corneil. The graph isomorphism disease. Journal of Graph Theory, 1(4):339-363, 2006]

67. M1 Introduction M2

68. M1 Introduction M2 Before calculating the differences a matching phase has to be performed to identify the elements which have to be compared

69. Model matching There are several requirements for model matching approaches including accuracy level of abstraction tool independence efficiency user effort Existing model matching approaches can be distinguished according to the following classification Static Identity-Based Matching Signature-Based Matching Similarity-Based Matching Custom Language-Specific Matching Algorithms There is no single best solution to model matching

73. Some model matching approaches

74. Case study Modified version of M1 Sample UML model M1 the classes School and Student have been moved to a new package administration; the parameter student of the operation register in the class School has been modified by changing its type from String to Student; the attribute surname has been added in the class Student the attribute yearsOld has been renamed to age; the class Person has been added in the new package administration; the package inventory has been added in the package school

75. Case study > Static identity-based matching It is able to detect all the modifications without any user effort Even the renaming of the attribute yearsOld can be correctly discovered Fragment of the differences calculated by TOPCASED tool

76. Case study > Signature-Based Matching It is not is not able to detect all the changes The modifications to the School and Student classes have been detected as deletions and additions of new ones with new structural features Differences calculated by EMFCompare

77. Case study > Signature-Based Matching It is not is not able to detect all the changes The modifications to the School and Student classes have been detected as deletions and additions of new ones with new structural features Although it is still possible to build the final model starting from the initial, any analysis cannot rely on the missing tracing information Differences calculated by EMFCompare

78. Case study > Similarity-Based Matching All the differences have been correctly detected but the renaming of the attribute yearsOld Such a modification is detected as a deletion of the yearsOld attribute and an addition of the age one there is not a match between them that can be specified in general with respect to the semantics of UML Differences calculated by SiDiff

79. Case study > Custom Language-Specific Matching Algorithms All the modifications are detected we explicitly specified a rule that matches two attributes belonging to matching classes even if they don’t have the same name, as long as their types match and they are also the only attributes of this type within their respective classes Differences calculated by ECL

80. EMF Compare EMF Compare is an EMFT component providing out-of-the-box model comparison and merging capabilities

81. EMF Compare > Architectural Issues Since its begining the EMF Compare component has been designed so that every part of the process is extensible

82. EMF Compare > Architectural Issues Since its begining the EMF Compare component has been designed so that every part of the process is extensible How we can easily implement a matching algorithm capable of encompassing designer-defined heuristics (without too much effort) ?

83. ECL: Epsilon Comparison Language The aim of the Epsilon Comparison Language (ECL) is to enable users to specify comparison algorithms in a rule-based manner ECL is a hybrid rule-based language which is used in combination with EMF Compare A ECL specification defines a matching algorithm for EMF Compare The specified rules permit to identify pairs of matching elements between two models ECL is part of the Eclipse GMT project: http://www.eclipse.org/gmt/epsilon/doc/ecl/

84. ECL > Abstractsyntax

85. ECL > Abstractsyntax A match rule has three parts: - the guard part; - the compare part; - the do part;

86. ECL > Abstractsyntax The guard part is an EOL expression or statement block that further limits the applicability of the rule to an even narrower range of elements than that specified by the left and right Parameters

87. ECL > Abstractsyntax The compare part is an EOL expression or statement block that is responsible for comparing a pair of elements and deciding if they match or not

88. ECL > Abstractsyntax The do part is an EOL expression or block that is executed if the compare part returns true to perform any additional actions required

89. ECL > Abstractsyntax Pre and Post blocks are named blocks of EOL statements which as discussed in the sequel are executed before and after the match-rules have been executed respectively.

90. ECL > Concrete syntax Concrete syntaxof a MatchRule Concrete syntaxof a Pre and Post block

91. ECL > Comparison Outcome The result of comparing two models with ECL is a model containing a trace (MatchTrace) that consists of a number of matches (Match) Each match holds a reference to the objects from the two models that have been compared (left and right), a boolean value that indicates if they have been found to be matching or not, a reference to the rule that has made the decision, and a Map (info) thatis used to hold any additional information required by the user

92. ECL > MatchTrace

93. Example (1)

94. Example (1) Let us consider a labeled tree Sample Treemetamodel

95. Example (1) > calculated differences with the generic matching algorithm M1 M2 Tree b and all the containedtreeelements (Tree c, Tree d) havebeenremoved Tree e and all the containedtreeelements (Tree c, Tree d) havebeenadded Note that Tree c and Tree d in M1 and M2 are different trees

96. Example (1) The rule specifies that for two Tree nodes (l and r) to match, they should have the same label Sample Treemetamodel rule Tree2Tree match l : T1!Treewith r : T2!Tree { compare : l.label = r.label } Sample ECL specification

97. Example (1) > calculated differences with the customized matching algorithm Tree bhasbeenremoved Tree ehasbeenadded TreechasbeenmovedfromTree b toTreed Treed hasbeenmovedfromTreectoTreee This faithfully reflects the designer intentions, i.e. Tree c and Tree d in M1 and M2 are the same!

98. Example (2) > calculated differences with the generic matching algorithm <Class> c3 and <Package> org (and itsdescendents) havebeenremoved <Class> c1 and <Class> c3 havebeenadded

99. Example (2) > customizationof the matchingalgorithm ruleClass match l : Left!Classwith r : Right!Class { compare : l.name = r.name do { l.ownedOperation.doMatch(r.ownedOperation); } } @lazy ruleOperation match l : Left!Operationwithr : Right!Operation { compare { -- First check to see if the names and the owning classes match varbasicMatch := l.name = r.name andl.class.matches(r.class); -- If we have only one operation in each class -- with that name they match if (basicMatch) { if (l.class.hasOnlyOneOp(l.name) andr.class.hasOnlyOneOp(l.name)) { returntrue;} else { -- Else we have to check their parameters as well returnl.ownedParameter.matches(r.ownedParameter); }} elsereturnfalse; } do {l.ownedParameter.doMatch(r.ownedParameter);} }

100. Example(2) > results with the customized matching algorithm <Class> c3 and <Package> org havebeenremoved <Class> c1hasbeenmovedfrom<Package> org to<Model> m2 <Operation> op1() hasbeenadded in <Class> c1 <Class> c2 hasbeenadded

101. Example(3) > 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.

102. Example (4) > sample beContentmodel

103. Example (4) > refinedbeContentmodel

104. Example (4) > calculated differences with the generic matching algorithm

105. Example (4) > customizationof the matchingalgorithm ruleCustomEntity match l : Left!CustomEntitywith r : Right!CustomEntity { compare : l.name.fuzzyMatch(r.name) orl.isSplit(r) … } … operationLeft!CustomEntityisSplit(r : Right!CustomEntity) : Boolean { varenumerationFieldSet : OrderedSet(Enumeration) = self.fields.select(e | e.isTypeOf(Left!Enumeration)); varisSplit : Boolean = false; isSplit = not (Right!CustomEntity.allInstances()->select(e | e.superType.isDefined() and enumerationFieldSet->exists(c | c.isDefined() andc.literals->exists(l | l.name = e.nameande.superType.name = r.name)) ) )->isEmpty(); returnisSplit; }

106. Example (4) > calculated differences with the customized matching algorithm

107. Modeldifferencesforsupporting system migrations

108. Modeldifferencesforsupporting system migrations

109. Modeldifferencesforsupporting system migrations

110. Modeldifferencesforsupporting system migrations

111. Modeldifferencesforsupporting system migrations

112. Modeldifferencesforsupporting system migrations A splitmodificationhasbeenoperated

113. Modeldifferencesforsupporting system migrations Generatedmigrationtool

114. Model Matching There is no single best solution to model matching Selecting a model matching approach for the problem at stake involves deciding on a trade-off between the required accuracy and the effort necessary to accomplish the differencing According to our experience, a custom matching algorithm based on infrastructure such as EMF Compare or ECL is deemed appropriate for high accuracy and performance Our arguments are based on practical experience obtained through experimentation with several implementations of matching algorithms and tools

115. Discussion Especially when dealing with general purpose modeling language, it might be interesting to use also taxonomic/ontology systems, such as WordNet This would have two advantages Ease the task of defining correspondences among names whose meaning is “close” enough Would permit to discover relations which are otherwise hidden in the model

116. Summary Model differences Matching Algorithm Conflict Management Evolution in the large (model evolution) in the small (metamodel evolution) Conclusions 115

117. Managing model conflicts in distributed development

118. Conflict Management Introduction Model versioning Distributed development Conflict management in MDE Representation of model differences A DSL for conflict specification Syntax Semantics Conclusions and future work

119. Introduction Model Driven Engineering (MDE) aims at shifting the focus of software development from coding to modeling and considers models as primary artifacts Complex software systems are developed in distributed environments which demands a precise discipline in the management of model versions Conflict management is an unavoidable aspect when dealing with distributed versions of the same artifact

120. Introduction We propose a Domain-Specific Language for conflict management which is intended to define conflicts related to the underlying domain-specific semantics and provide different tolerance degree to collisions depending on the particular stage of modeling process

121. Introduction

122. Introduction Modeler #1

123. Introduction Modeler #1 Modeler #2

124. Introduction / Distributed development

125. Introduction / Distributed development Visibility changed to private.

126. Introduction / Distributed development New operation added.

127. Introduction / Distributed development New constructor added.

128. Introduction / Distributed development Public or private ?

129. Introduction / Distributed development Singleton design pattern introduction and violation

130. Conflict management Identification of changes occurred in each concurrent model version by means of some evolution representation approach

131. Conflict management Identification of changes occurred in each concurrent model version by means of some evolution representation approach Conflict detection is based on the comparison between concurrent versions of the modifications It usually relies on a priori analyses of the domain entailing a predefined set of problems and thus admitting false positive and false negative occurrences

132. Conflict management Identification of changes occurred in each concurrent model version by means of some evolution representation approach Conflict detection is based on the comparison between concurrent versions and usually relies on a priori analyses of the domain entailing a predefined set of problems and thus admitting false positive and false negative occurrences Conflict resolution is a strategy given to reconcile colliding manipulations, in general provided by the developer

133. A DSL for conflict specification It is relies on the model-based difference representation seen before The conflicts are specified as a left-hand side and a right-hand side representing delta pattern pairs which can not occur in the concurrent modifications at the same time The pattern language allows to specify regular expressions as names of the involved entities Patterns can declare and recall bound variables making it possible to refer to the properties of the current match Other useful features are negative patterns and multiplicity of matches

134. A model-baseddifferencerepresentation [TOOLS07]

135. Difference metamodel example

136. Difference metamodel example MM2MMD

137. Sample modeldifferencerepresentation

138. Sample modeldifferencerepresentation

139. A DSL for conflict specification Metamodel independent, relies on difference models and metamodels

140. A DSL for conflict specification Metamodelindependent, relies on difference models and metamodels Conflict specification, fine-tunes false positives and negatives and adds fuzziness to conflict management

142. Conflict specification, fine-tunes false positives and negatives and adds fuzziness to conflict management

144. Conflict specification syntax / Example If the right-hand side violates the Singleton If the left-hand side introduces the Singleton design pattern

145. Interpreting conflict specifications The definitions of conflicts are given precise semantics by means of OCL The graphical representation of OCL expressions is not new and has taken inspiration from the work on Join Point Designation Diagrams (JPDDs) [SHU05] OCL constructs are embedded in ATL transformations to build rules able to detect interfering modifications Other possible semantics can be given mapping the diagrammatic definition of conflicts toward corresponding rules for instance by graph transformations or declarative techniques

146. Conflict specification semantics

147. Conflict specification semantics For each match of the left pattern …

148. Conflict specification semantics … find a corresponding match of the right pattern

149. Conflict specification semantics … find a corresponding match of the right pattern The engine looks for matches induced by the left-hand side pattern For each match a variable binding is operated on the right pattern The engine looks for matches induced by the current right-hand side pattern

150. Conflict specification semantics For each DifferenceElement… … matching rules for metaattributes are applied

151. Conflict specification semantics For each DifferenceElement… … matching rules for metaattributes are applied … matching rules for structural properties (including relations) are applied

152. Conflict Management The proposed work is an excerpt of the dissertation of Antonio Cicchetti defended in 2007 and proposes a structural approach for dealing with conflicts not detectable from the syntax level A model-based difference representation approach and a pattern language relying on it enable the management of distributed development Modeling activities requires different levels of strictness in detecting conflicts depending on the stage of the development: for instance at the beginning it might be preferable to be looser Libraries of conflict specifications

153. Conflict Management A prototypical implementation of the approach based on the AMMA platform is available at http://www.di.univaq.it/cicchetti/conflictManagement.php The approach needs a usability validation which encompasses larger population of conflict cases The DSL could be improved introducing unary conflicts The specification of resolution strategies have to be further investigated, like defining a reconciliation process or minimizing the conflicting portions

154. Summary Model differences Calculation Representation Visualization Matching Algorithm Conflict Management Evolution in the large (model evolution) in the small (metamodel evolution) Conclusions 152

155. Evolution in the large and in the small Model Evolution and Versioning

156. Introduction Model Driven Engineering (MDE) is increasingly gaining acceptance in the development of software 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 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 154

158. 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

159. 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 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

160. 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

161. 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

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

163. Evolution I would like to discuss the problem of the evolution in model-driven development engineering MDD MDE

164. Evolution I would like to discuss the problem of the evolution in model-driven development 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

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

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

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

169. P2

171. P2

173. P2

175. P2

177. P2

179. P2

182. P2

184. S2

185. P2

186. P3Metamodel

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

188. 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 refinement or enlargement a more complete understanding of the domain is at hand

190. P2

192. P2

194. M3 Model Transformations conformsTo conformsTo 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

195. 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

196. 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

197. 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

198. Metamodel changes A metamodel can undergo a number of different kinds of modifications which are classified in Non-breaking Breaking The breaking modifications can be divided into Breaking and resolvable: existing instances need to be co-adapted to conform to the new metamodel version. The co-evolution can be automatically operated Breaking and unresolvable: the necessary co-adaptation of existing models can not be automatically computed due to the need of further information [Paige at al 2007]

199. Metamodel changes classification

200. Sample Petri Net metamodel changes

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

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

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

204. 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)

205. Model difference representation

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

207. Sample metamodeldifferencerepresentation

208. 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

209. Transformationaladaptationofmodels: example Δ(0,1)

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

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

212. 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

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

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

215. 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

216. 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

217. 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

218. Parallel dependent modifications

219. 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 Arc metaclass of MM2)

220. 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]

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

222. 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

223. 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

224. 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

225. 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

226. 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.

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

228. 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

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

230. BMM – beContentMetamodel

231. BMM – beContentMetamodel

232. BMM – beContentMetamodel . . . Metamodel fragment Model fragment

233. 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

234. Problem: a simple text generation . . . ...

235. 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

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

237. 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 …

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

239. 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 :-)

240. 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

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

242. 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

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

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

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

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

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

248. Evolution in the small: beContent example Δ

249. 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

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

251. 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

252. 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

254. Bibliography CédricBrun and Alfonso Pierantonio. Model differences in the eclipse modeling framework. The European Journal for the Informatics Professional (UPGRADE), Monograph on Model-Driven Software Development (Eds. J.Bézivin, A.Vallecillo, J.García-Molina, and G.Rossi), 9(2):29–34, 2008. Antonio Cicchetti, Davide Di Ruscio, and Alfonso Pierantonio. A metamodelindependentapproach to difference representation. Journal of Object Technology, 6(9):165–185, 2007. Antonio Cicchetti, Davide Di Ruscio and Alfonso Pierantonio, ModelPatches in Model-DrivenEngineering, in: MoDSE-MCCM Workshop, ACM/IEEE 12th International Conference on ModelDrivenEngineeringLanguages and Systems (MODELS 2009), Denver, Colorado, USA, 2009 Dimitrios S. Kolovos, Davide Di Ruscio, Richard F. Paige and Alfonso Pierantonio, DifferentModelsforModelMatching: An analysisofapproachestosupportmodeldifferencing, in: 2nd Workshop on Comparison and Versioningof Software Models (CVSM'09), ACM/IEEE International Conference on Software Engineering (ICSE), Vancouver, Canada, 2009 Antonio Cicchetti, Davide Di Ruscio, and Alfonso Pierantonio. ManagingModelConflictsin Distributed Development. In ACM/IEEE 11th International Conference on Model Driven Engineering Languages and Systems (MoDELS 2008), LNCS 5301, pp. 311–325, 2008 A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, AutomatingCo-evolution in Model-DrivenEngineering. Procs. EDOC 2008, Munich, Germany Antonio Cicchetti, Davide Di Ruscio, Ludovico Iovino, Alfonso Pierantonio, ManagingevolvingWebapplications, Technical Report Dipartimento di Informatica, Università degli Studi dell’Aquila, May 2010 B. Gruschko, D. Kolovos, and R. Paige. Towards Synchronizing Models with Evolving Metamodels. In Procs of the Work. MODSE, 2007. G. Wachsmuth. Metamodel Adaptation and Model Coadaptation. In E. Ernst, editor, Proceedings of the 21st ECOOP, volume 4069 of LNCS. Springer-Verlag, July 2007. 240 Model Differences and Evolution

255. Contact Information Prof. Alfonso PierantonioDipartimento di InformaticaUniversità degli Studi dell’AquilaI-67100 L’Aquila, Italy alfonso.pierantonio@univaq.ithttp://www.di.univaq.it/alfonso Research Interests:CoupledEvolutionofModels, Tranformations and Tools, BidirectionalTransformations, ModelVersioning 241 Model Differences and Evolution