This document discusses model differencing, which is the ability to detect and represent changes between versions of a model. It begins by outlining the key challenges of model differencing and proposes decomposing the problem into calculation of differences, representation of differences, and applications of differences. It then examines approaches for representing differences, such as edit scripts and coloring, and proposes a difference metamodel for abstractly representing differences. The document concludes by discussing how difference models can be used for model patching and composition of differences.

1. Model Evolution and VersioningAlfonso PierantonioDipartimento di InformaticaUniversità degli Studi dell’Aquilaalfonso.pierantonio@univaq.it

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

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

4. 4Modeldifferences and evolutionModeldifferences and evolutionThere is no way to understand the rationale behind these modifications

5. 5Modeldifferences and evolutionModeldifferences and evolution

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

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

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

9. 9Modeldifferences and evolutionA satisfactory representation of differences can enables a wide range of applicationsModeldifferences and evolution

10. 10Modeldifferences and evolutionModeldifferences and evolutionModel 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

11. 11Model-drivenengineeringprovidesthe meanstoincrease the degreeofautomation

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

13. conformance, consistencyrelations amongmodelsAchieving the potential

14. Achieving the potential12Achievingthe greatPotential.

15. 13Achieving the potentialTurninginto a nightmare!

16. SummaryModel differencesMatching AlgorithmConflict ManagementEvolution in the large (model evolution)in the small (metamodel evolution)Conclusions14

17. ModeldifferencesModel Evolution and Versioning15

18. Model DifferencesIntroductionRepresentation RequirementsModel Difference ApproachesEdit Script, ColoringRepresenting Model DifferencesDifference Metamodel, Difference ModelsDifference ApplicationPatchesOperations with DifferencesDual, Sequential and Parallel CompositionConclusions and Future Work

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

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

21. IntroductionThe problem of model differencing can be decomposed in two subsequent phases1Calculation

22. IntroductionThe problem of model differencing can be decomposed in two subsequent phases12CalculationRepresentation

23. IntroductionThe outcome used for further applications by means of automated transformations and analysis123CalculationRepresentationApplications : Transformation & Analysis

24. IntroductionModel Difference Calculation1

25. IntroductionModel DifferenceRepresentation2

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

27. Representation Requirements

28. ApproachesThe representation of model differences can be divided into two main techniquesDirected deltas, represent delta documents as the sequence of the operations needed to obtain the new version from the old oneeg. edit scripts Symmetric deltas, show the result as the set of differences between the two compared versionseg. 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 oneCons: operational, proprietary format, tool dependent, lengthy, reduced readability

33. Approaches – Coloring (eg [Ohst et al 2003])Declarative and intuitiveCons: does not hold the following propertiesMinimalisticSelf-containedTransformativeCons: moreoververy verboseupdates 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 MMThe approach permits the representation of the following modificationsadditions: new elements are added to the final model deletions: some of the existing elements are deletedchanges: 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)MMMM2MMDMMD

38. Sample UML modelsVersion 1Version 2

39. Sample UML modelsuVersion 1The abstract class HTMLDocElemhas been addedVersion 2

40. Sample UML modelsVersion 1The operation dump() has been moved to HTMLDocElemvVersion 2

41. Sample UML modelswVersion 1The HTMLList class became subclassof HTMLDocElemVersion 2

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

43. Fragment of the Difference ModelThe abstract class HTMLDocElemhas been addedThe operation dump()has been moved from HTMLDocto HTMLDocElem

44. Fragment of the Difference ModelThe abstract class HTMLDocElemhas been addedThe operation dump() has been moved from HTMLDoc to HTMLDocElemThe HTMLList class became subclassof HTMLDocElem

45. Difference ApplicationOnce differences are calculated and represented, they can be applied over models as patchesThe 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

46. Difference ApplicationLet (M2 – M1) =  be a difference model, then patch(M) equalsM2 if M = M1 (reconstructive)M if M  M1 =  (idempotent)patch(M  M1)  (M/M1) if M  M1   (transformative)where patch(M) = patch(, M) and

47. patch: MMD  MM  MM

48. reconstructive  transformativeDifference ApplicationThe difference application patch is obtained by an automated higher-order transformation written in ATLFor each “base” metaclass MC in MMD, the following transformation rules are generated:AddedMC2MCChangedMC2MC UnchangedMC2MCMMD2ATLHOTpatchtransformationMMD

49. Difference ApplicationRule AddedMC2MCEach AddedMC induces a new MC instance in M2 and the corresponding structural features according to Rule ChangedMC2MCIt 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 ScenarioMM2MMDMMpatchtransformationMMD2ATLHOTMMD

51. Overall ScenarioMM2MMDMMM2conformsToconformsToM1patchtransformationMDconformsToMMD2ATLHOTMMD

52. Difference OperatorsDualGiven 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 OperatorsSequential Composition two or more subsequent modifications can be grouped in a single difference modelgiven 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1Parallel Compositiondistributed manipulations of the same artifacts can be merged in a model difference as long as they are parallel indipendent

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

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

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

57. Model Versioning - PatchesThe application of manipulations as patches demands for several propertiesSelf-containedness: The representation of differences should contain enough information to be applied to arbitrary inputsMinimality: The representation should not contain too much information thus locking the application to the initial contextTransformability: 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 ScenarioMM2MMDMMM2conformsToconformsToM1Application ModelpatchtransformationMDconformsToMMD2ATLHOTMMD

59. Overall ScenarioMM2MMDMMM2conformsToconformsToM1Application ModelpatchtransformationMDconformsToMMD2ATLHOTMMD

61. Model DifferencesModel differences are crucial for general model management and can disclose numerous opportunitiesOnce differences are represented as first-class entities, a number of operations can be defined on thempatches, dual, binary compositions, impact evaluation, etcA 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 semanticsFormalizing semantics is difficult, thus heuristics can provide some ad-hoc improvementAs soon we consider parallel composition the problem conflict specification, detection, and resolutionParallel composition may give place to conflicts whenever the differences are not parallel independentDepending on the process stage we may be interested in tuning false positives and negatives

63. SummaryModel differencesMatching AlgorithmConflict ManagementEvolution in the large (model evolution)in the small (metamodel evolution)Conclusions60

64. Model matchingModel Evolution and Versioning61

65. OutlineIntroductionModel matchingStatic Identity-Based MatchingSignature-Based MatchingSimilarity-Based MatchingLanguage-SpecificCase studyConclusions

66. IntroductionDifferencing mechanisms for supporting the evolution of model-based artifacts are becoming crucialDocument comparison algorithms provided by version control systems like CVS, and SVN have been shown to be inadequateCalculating model differences is a difficult task since it relies on model matching which can be reduced to the graph isomorphism problemNo 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. M1IntroductionM2

68. M1IntroductionM2Before calculating the differences a matching phase has to be performed to identify the elements which have to be compared

69. Model matchingThere are several requirements for model matching approaches including accuracylevel of abstractiontool independenceefficiencyuser effortExisting model matching approaches can be distinguished according to the following classificationStatic Identity-Based MatchingSignature-Based MatchingSimilarity-Based MatchingCustom Language-Specific Matching AlgorithmsThere is no single best solution to model matching

70. Static Identity-Based MatchingIt is assumed that each model element has a persistent and non-volatile unique identifier that is assigned to it upon creationA basic approach for matching models is to identify matching model elements based on their corresponding identitiesProsit requires no configuration from the user perspective

71. it is particularly fastConsit does not apply to models constructed independently of each other, and to model representation technologies that do not support maintenance of unique identitiesSignature-Based MatchingIt is signature calculated dynamically from the values of its features by means of a user-defined function specified using a model querying languageProsit can be used to compare models that have been constructed independently of each otherConsdevelopers need to specify a series of functions that calculate the identities of different types of model elementsSimilarity-Based MatchingIt treats models as typed attribute graphs and attempts to identify matching elements based on the aggregated similarity of their featuresSimilarity-based algorithms typically need to be provided with a configuration that specifies the relative weight of each featureProstyped attribute graph matching algorithms have been shown to produce more accurate resultsConssuch approaches fail to take into consideration the semantics of the modelling languageCustom Language-Specific Matching AlgorithmsThey are tailored to a particular modelling language (e.g. UML, StateCharts)They incorporate the semantics of the target languagee.g. when comparing UML models it only makes sense to compare two operations if the classes they belong to are already known to match (drastically reducing the number of comparisons)ProsThey provide more accurate results

72. They drastically reduce the search spaceConsDevelopers need to specify the complete matching algorithm manually or programmatically, which can be a particularly challenging taskCustom Language-Specific Matching AlgorithmsTo ease the development of custom matching algorithms, approaches such as EMF Compare and the Epsilon Comparison Language (ECL) can be combinedThey provide infrastructure whichcan automate the trivial parts of the comparison processenables developers to concentrate on the comparison logic onlyEven with such tool support, the effort required to implement a custom matching algorithm is still considerable

73. Some model matching approaches

74. Case studyModified version of M1Sample UML model M1the 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 Studentthe 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 effortEven the renaming of the attribute yearsOld can be correctly discoveredFragment of the differences calculated by TOPCASED tool

76. Case study > Signature-Based MatchingIt is not is not able to detect all the changesThe modifications to the School and Student classes have been detected as deletions and additions of new ones with new structural featuresDifferences calculated by EMFCompare

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

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

79. Case study > Custom Language-Specific Matching AlgorithmsAll the modifications are detectedwe 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 classesDifferences calculated by ECL

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

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

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

83. ECL: Epsilon Comparison LanguageThe 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 CompareA ECL specification defines a matching algorithm for EMF CompareThe specified rules permit to identify pairs of matching elements between two modelsECL is part of the Eclipse GMT project: http://www.eclipse.org/gmt/epsilon/doc/ecl/

84. ECL > Abstractsyntax

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

86. ECL > AbstractsyntaxThe 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 > AbstractsyntaxThe 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 > AbstractsyntaxThe 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 > AbstractsyntaxPre 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 syntaxConcrete syntaxof a MatchRuleConcrete syntaxof a Pre and Post block

91. ECL > Comparison OutcomeThe 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 treeSample Treemetamodel

95. Example (1) > calculated differences with the generic matching algorithmM1M2Tree b and all the containedtreeelements (Tree c, Tree d) havebeenremovedTree e and all the containedtreeelements (Tree c, Tree d) havebeenaddedNote 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 labelSample Treemetamodelrule Tree2Treematch l : T1!Treewith r : T2!Tree{compare : l.label = r.label}Sample ECL specification

97. Example (1) > calculated differences with the customized matching algorithmTree bhasbeenremovedTree ehasbeenaddedTreechasbeenmovedfromTree b toTreedTreed hasbeenmovedfromTreectoTreeeThis 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 matchingalgorithmruleClassmatch l : Left!Classwith r : Right!Class {compare : l.name = r.namedo {l.ownedOperation.doMatch(r.ownedOperation);}}@lazyruleOperationmatch l : Left!Operationwithr : Right!Operation {compare {-- First check to see if the names and the owning classes matchvarbasicMatch := l.name = r.name andl.class.matches(r.class);-- If we have only one operation in each class -- with that name they matchif (basicMatch) {if (l.class.hasOnlyOneOp(l.name) andr.class.hasOnlyOneOp(l.name)) {returntrue;} else { -- Else we have to check their parameters as wellreturnl.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) > beContentbeContent is an model-driven platform for designing and maintaining web applicationsA 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 finallythe 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 matchingalgorithmruleCustomEntitymatch 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() andenumerationFieldSet->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 migrationsA splitmodificationhasbeenoperated

113. Modeldifferencesforsupporting system migrationsGeneratedmigrationtool

114. Model MatchingThere is no single best solution to model matchingSelecting 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 differencingAccording to our experience, a custom matching algorithm based on infrastructure such as EMF Compare or ECL is deemed appropriate for high accuracy and performanceOur arguments are based on practical experience obtained through experimentation with several implementations of matching algorithms and tools

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

116. SummaryModel differencesMatching AlgorithmConflict ManagementEvolution in the large (model evolution)in the small (metamodel evolution)Conclusions115

117. Managing model conflicts in distributed development

118. Conflict ManagementIntroductionModel versioningDistributed developmentConflict management in MDERepresentation of model differencesA DSL for conflict specificationSyntaxSemanticsConclusions and future work

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

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

121. Introduction

122. IntroductionModeler #1

123. IntroductionModeler #1Modeler #2

124. Introduction / Distributed development

125. Introduction / Distributed developmentVisibility changed to private.

126. Introduction / Distributed developmentNew operation added.

127. Introduction / Distributed developmentNew constructor added.

128. Introduction / Distributed developmentPublic or private ?

129. Introduction / Distributed developmentSingleton design pattern introduction and violation

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

131. Conflict managementIdentification of changes occurred in each concurrent model version by means of some evolution representation approachConflict 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 managementIdentification of changes occurred in each concurrent model version by means of some evolution representation approachConflict 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 occurrencesConflict resolution is a strategy given to reconcile colliding manipulations, in general provided by the developer

133. A DSL for conflict specificationIt is relies on the model-based difference representation seen beforeThe 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 timeThe pattern language allows to specify regular expressions as names of the involved entitiesPatterns can declare and recall bound variables making it possible to refer to the properties of the current matchOther useful features are negative patterns and multiplicity of matches

134. A model-baseddifferencerepresentation[TOOLS07]

135. Difference metamodel example

136. Difference metamodel exampleMM2MMD

137. Sample modeldifferencerepresentation

138. Sample modeldifferencerepresentation

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

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

141. A DSL for conflict specificationMetamodel independent, relies on difference models and metamodels

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

143. Conflict reconciliation, applying well-known resolution criteriaConflict specification syntax / ExampleIf the left-hand side introduces the Singleton design pattern

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

145. Interpreting conflict specificationsThe definitions of conflicts are given precise semantics by means of OCLThe 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 modificationsOther 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 semanticsFor 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 patternThe engine looks for matches induced by the left-hand side patternFor each match a variable binding is operated on the right patternThe engine looks for matches induced by the current right-hand side pattern

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

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

152. Conflict ManagementThe 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 levelA model-based difference representation approach and a pattern language relying on it enable the management of distributed developmentModeling 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 looserLibraries of conflict specifications

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

154. SummaryModel differencesCalculationRepresentationVisualizationMatching AlgorithmConflict ManagementEvolution in the large (model evolution)in the small (metamodel evolution)Conclusions152

155. Evolution in the large and in the smallModel 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 changesCoordinated 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 adaptations154

157. Modeling languagesModeling languages can be used to specify problems, solutions and the mapping among them in the corresponding domainsabstractionDomain-specific modeling languagesPproblem domainSGeneral-purpose modeling languages,eg. UML solution domain

158. EvolutionAny 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. EvolutionAny 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 sparseUM 0.8UML 1.1UML 1.4UML 2.0UML 2.2UML 0.9UML 1.3UML 1.5UML 2.1.2199519972005200020032007

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

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

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

163. EvolutionI would like to discuss the problem of the evolution in model-driven development engineeringMDDMDE

164. EvolutionI would like to discuss the problem of the evolution in model-driven development engineeringThis talk analyzes the different kinds of co-adaptations distinguishing among co-evolution in the large and in the smallwhen a metamodel undergoes a modification, the conforming models require to be accordingly co-adaptedwhen 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. SummaryIntroductionEvolution in the Large: MetamodelEvolutionProblem-based adaptationSolution-based adaptationMetamodel change classificationTransformationaladaptationofmodelsEvolution in the Small: Application Model EvolutionData migrationAdaptation of specific assetsConclusions and future work

166. M3The “language” oflanguages,eg. EcoreMeta MetamodelThe modelinglanguage, typicallyusedtoengineerthe applicationdomain, eg. UWE, WebML, beContentM2Meta modeling architectureMetamodelsInstancemodelswhichrepresentproblems and solutions in the application domainM1ModelsTools(VisualEditors)Systems and applicationsrealizing the solutionin the applicationdomain, eg. portals, data-intensive web apps, etcTools(VisualEditors)Tools(VisualEditors)M0Tools(VisualEditors)Tools(VisualEditors)Tooln

167. M3M2M1M0Metamodel based toolsconformsToMeta MetamodelMetamodelconformsToModelbasedOneditsimplementedForTool

168. This is a domainP1

169. P2

170. P3Domainsusually do nothavecrispyboundariesThis is a domainP1

171. P2

172. P3This is a specific problem in the domaindomainP1

173. P2

174. P3Goal: formalize a modeling language for capturing the domain problemsdomainP1

175. P2

176. P3MetamodelGoal: formalize a modeling language for capturing the domain problemsdomainP1

177. P2

178. P3MetamodelGoal: formalize a modeling language for capturing the domain problemsdomainP1

179. P2

180. P3M3Model TransformationsconformsToconformsToMeta MetamodelconformsToM2tofromTarget MetamodelSource MetamodelTransformationLanguageconformsToconformsToconformsToM1Target ModelSource ModelTransformationRulessourcetargetexecTransformationEngineM0

181. MetamodelModel transformations map problems to solutionsdomainP1

182. P2

183. P3Model transformations map problems to solutionsS1domainP1

184. S2

185. P2

186. P3Metamodel

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

188. Metamodel evolutionSometimes metamodels must be adapted, extended or amended to better capture the problemsThis may happen because the domains are often only partially analyzed and several instances may be left outnew requirements must be considered which will result in a domain refinement or enlargementa more complete understanding of the domain is at hand

189. MetamodeldomainP1

190. P2

191. P3MetamodeldomainP1

192. P2

193. P3M3Model TransformationsconformsToconformsToMeta MetamodelconformsToM2tofromTarget MetamodelSource MetamodelTransformationLanguageconformsToconformsToconformsToM1Target ModelSource ModelTransformationRulessourcetargetexecTransformationEngineM0

194. M3Model TransformationsconformsToconformsToMeta MetamodelconformsToM2tofromTarget MetamodelSource MetamodelTransformationLanguageSource MetamodelconformsToconformsToconformsToM1Target ModelSource ModelTransformationRulessourcetargetexecTransformationEngineM0

195. Model TransformationsconformsToconformsToM3Meta MetamodelconformsToM2tofromTarget MetamodelSource MetamodelTransformationLanguageSource MetamodelconformsToconformsToconformsToM1Target ModelSource ModelTransformationRulessourcetargetexecTransformationEngineM0

196. Model TransformationsconformsToconformsToM3Meta MetamodelconformsToM2tofromTarget MetamodelSource MetamodelTransformationLanguageSource MetamodelconformsToconformsToconformsToM1Target ModelSource ModelTransformationRulessourcetargetexecTransformationEngineM0

197. Model TransformationsconformsToconformsToM3Meta MetamodelconformsToM2tofromTarget MetamodelSource MetamodelTransformationLanguageSource MetamodelconformsToconformsToconformsToM1Target ModelSource ModelTransformationRulessourcetargetexecTransformationEngineM0

198. Metamodel changesA metamodel can undergo a number of different kinds of modifications which are classified in Non-breakingBreaking The breaking modifications can be divided intoBreaking and resolvable: existing instances need to be co-adapted to conform to the new metamodel version. The co-evolution can be automatically operatedBreaking 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 changesBreaking and resolvable changes(extract meta-class)

202. Sample Petri Net metamodel changesBreaking and resolvable changes(extract meta-class)t1pt1tp1p1p2p1p2pt2tp2t2

203. Sample Petri Net metamodel changesBreaking and unresolvablechange(Addobligatorymetaproperty)

204. Sample Petri Net metamodel changesweight=?weight=?pt1tp1pt1tp1p1p2p1p2pt2tp2pt2tp2weight=?weight=?Breaking and unresolvablechange(Addobligatorymetaproperty)

205. Model difference representation

206. Metamodel difference representationSince 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 changesIn 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: exampleRestrictmetapropertychangeExtractmetaclasschangesΔ(0,1)

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

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

213. Transformationaladaptationofmodels: exampleCTRt1pt1tp1p1p2p1p2pt2tp2t2

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

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

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

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

218. Parallel dependent modifications

219. Parallel dependent modificationsThe 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 dependencesWe analyzed the kind of interdependencies among breaking resolvable and breaking unresolvable changesWe 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 dependencesSufficient criteria have been given to establish the correct scheduling of the conflicting changes

222. Resolving dependencesAn alternative approach ([1]) is based on a lazy evaluation mechanism which queues up adaptations which require unavailable informationWe have found that for KM3, Ecore, and MOF interdependencies are not circular and that they only depend on the meta metamodelThis 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. ApproachThis 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 permitsthe 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. SummaryIntroductionEvolution in the Large: Metamodel Evolution (XLE)Problem-based adaptationSolution-based adaptationMetamodel change classificationTransformationaladaptationofmodelsEvolution in the Small: Application Model Evolution (XSE)Data migrationAdaptation of specific assetsConclusions and future work

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

226. beContentbeContent is an model-driven platform for designing and maintaining web applicationsA 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 finallythe 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. beContentECLIPSE GMFAMMA TCSbeContentMetamodelECLIPSE EcoreACCELEOAMMA ATLACCELEO

228. beContent architectureBMLBTLround-trippingECLIPSE GMFAMMA TCSECLIPSE GMFAMMA TCSbeContentMetamodelbeContentMetamodelECLIPSE EcoreECLIPSE EcoreM2CM2MACCELEOAMMA ATLACCELEOAMMA ATLM2CM2CPHPMySQLACCELEOACCELEOACCELEOJ2EE/Liferay.NET

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

230. BMM – beContentMetamodel

231. BMM – beContentMetamodel

232. BMM – beContentMetamodel. . .Metamodel fragmentModel fragment

233. Problem: a simple text generationGenerate 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 generationGenerate a text file containing source code based on information which is retrieved from different instances of the same metaclassThis is not easy as it may appear as templating languages (in contrast with M2M languages) do not always have the querying power of OCLIn 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 metamodelMM v1.0MM v2.0

237. Problem: a simple text generationIn 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 beforethe manual adaptation of the toolsA possible workaround …

238. Hiding the metamodel refactoringΔMetamodel v1.0Metamodel v2.0conformsToconformsToadapt(Δ)Model (v2.0)Model (v1.0)M2TSource code

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

240. SummaryIntroductionEvolution in the Large: Metamodel Evolution (XLE)Problem-based adaptationSolution-based adaptationMetamodel change classificationTransformationaladaptationofmodelsEvolution in the Small: Application Model Evolution (XSE)Data migrationAdaptation of specific assetsConclusions and future work

241. Evolution in the smallManual modificationsModel (v1.0)Model (v2.0)TTSystem”System’