Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Like this presentation? Why not share!

1,565 views

Published on

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

No Downloads

Total views

1,565

On SlideShare

0

From Embeds

0

Number of Embeds

5

Shares

0

Downloads

0

Comments

0

Likes

2

No embeds

No notes for slide

- 1. Model Evolution and Versioning<br />Alfonso Pierantonio<br />Dipartimento di InformaticaUniversità degli Studi dell’Aquila<br />alfonso.pierantonio@univaq.it<br />
- 2. 2<br />Objectives<br />Model-DrivenEngineeringrequires mature and adequatemodel management in ordertoachieveits full potential. <br />Thiscannotleaveaside the problemofmodeldifferencing.<br />Thislecturewillprovideinsights on the problemofmodeldifferencingoutlining the potentialsofitsapplication.<br />
- 3. 3<br />Modeldifferences and evolution<br />Modeldifferences and evolution<br />The ability to detect and represent structural changes in subsequent versions of a (meta) model<br />
- 4. 4<br />Modeldifferences and evolution<br />Modeldifferences and evolution<br />There is no way to understand the rationale behind these modifications<br />
- 5. 5<br />Modeldifferences and evolution<br />Modeldifferences and evolution<br />
- 6. 6<br />Modeldifferences and evolution<br />Modeldifferences and evolution<br />?<br />Q1: How to detect such evolution ?<br />
- 7. 7<br />Modeldifferences and evolution<br />Modeldifferences and evolution<br />?<br />Q2: How to represent it in sucha way it can be conveyed to model transformations ?<br />
- 8. 8<br />Modeldifferences and evolution<br />Modeldifferences and evolution<br />?<br />Q3: Which kind of applications can be realized by representing the evolution by means of models ?<br />
- 9. 9<br />Modeldifferences and evolution<br />A satisfactory representation of differences can enables a wide range of applications<br />Modeldifferences and evolution<br />
- 10. 10<br />Modeldifferences and evolution<br />Modeldifferences and evolution<br />Model evolution may require the adaptation of artefacts which are not directly generable from the model <br />Metamodel evolution requires models, transformations, and tools (eg. GMF editors) to be consistently adapted<br />
- 11. 11<br /><ul><li>Model-drivenengineeringprovidesthe meanstoincrease the degreeofautomation
- 12. Indeed, the metamodelarchitecture and the formalrelationshipsamongthe layers can fruitfullybeexplotedtothisend
- 13. conformance, consistencyrelations amongmodels</li></ul>Achieving the potential<br />
- 14. Achieving the potential<br />12<br />Achieving<br />the <br />great<br />Potential.<br />
- 15. 13<br />Achieving the potential<br />Turninginto a nightmare!<br />
- 16. Summary<br />Model differences<br />Matching Algorithm<br />Conflict Management<br />Evolution <br />in the large (model evolution)<br />in the small (metamodel evolution)<br />Conclusions<br />14<br />
- 17. Modeldifferences<br />Model Evolution and Versioning<br />15<br />
- 18. Model Differences<br />Introduction<br />Representation Requirements<br />Model Difference Approaches<br />Edit Script, Coloring<br />Representing Model Differences<br />Difference Metamodel, Difference Models<br />Difference Application<br />Patches<br />Operations with Differences<br />Dual, Sequential and Parallel Composition<br />Conclusions and Future Work<br />
- 19. Introduction<br />The problem of model differences is intrinsically complex and requires specialized algorithms and notations<br />Any solution should necessarily present a high degree of separation between three relevant aspects<br />calculation, a procedure, method or algorithm able to compare two distinct models <br />representation, the outcome of the calculation must be represented in some form<br />visualization, model differences often requires to be visualized in a human-readable notation<br />In currentproposals the distinctionbetween the three aspects are often blurred thus compromising the adoption of generic modelling techniques<br />
- 20. Introduction<br />The problem of model differencing can be decomposed in two subsequent phases<br />
- 21. Introduction<br />The problem of model differencing can be decomposed in two subsequent phases<br />1<br />Calculation<br />
- 22. Introduction<br />The problem of model differencing can be decomposed in two subsequent phases<br />1<br />2<br />Calculation<br />Representation<br />
- 23. Introduction<br />The outcome used for further applications by means of automated transformations and analysis<br />1<br />2<br />3<br />Calculation<br />Representation<br />Applications : Transformation & Analysis<br />
- 24. Introduction<br />Model Difference Calculation<br />1<br />
- 25. Introduction<br />Model DifferenceRepresentation<br />2<br />
- 26. Introduction<br />Thus, the aim is to find a suitable representation for model differences which<br />is independent from the metamodel the models are conforming to<br />abstracts from the calculation method used for differencing the models, regardless whether it is based on persistent ids or structural similarity<br />the outcome of a differencing operation must be usable in automated transformation or analysis<br />
- 27. Representation Requirements<br />
- 28. Approaches<br />The representation of model differences can be divided into two main techniques<br />Directed deltas, represent delta documents as the sequence of the operations needed to obtain the new version from the old one<br />eg. edit scripts <br />Symmetric deltas, show the result as the set of differences between the two compared versions<br />eg. coloring <br />[Mens 2002]<br />
- 29. Approaches – Example <br />version 1 (M1) <br />
- 30. Approaches – Example <br />version 2 (M2)<br />version 1 (M1) <br />
- 31. Approaches – Example <br />version 2 (M2) <br />version 1 (M1) <br />
- 32. Approaches – Edit Scripts (eg [Porres et al 2003])<br />Sequence of actions able to reconstruct the final model starting from the initial one<br />Cons: operational, proprietary format, tool dependent, lengthy, reduced readability<br />
- 33. Approaches – Coloring (eg [Ohst et al 2003])<br />Declarative and intuitive<br />Cons: does not hold the following properties<br />Minimalistic<br />Self-contained<br />Transformative<br />Cons: moreover<br />very verbose<br />updates difficult to represent<br />
- 34. Approaches – Summary<br />
- 35. Difference Metamodel (1/3)<br />Given two models M1 and M2 conforming to a metamodelMM, their difference (M2 – M1) conforms to a metamodelMMD that is derived from MM<br />The approach permits the representation of the following modifications<br />additions: new elements are added to the final model <br />deletions: some of the existing elements are deleted<br />changes: a new version of the model can consist of some updates of already existing elements<br />
- 36. Difference Metamodel (2/3) <br />
- 37. Difference Metamodel (3/3)<br />MM<br />MM2MMD<br />MMD <br />
- 38. Sample UML models<br />Version 1<br />Version 2<br />
- 39. Sample UML models<br />u<br />Version 1<br />The abstract class HTMLDocElemhas been added<br />Version 2<br />
- 40. Sample UML models<br />Version 1<br />The operation dump() has been moved to HTMLDocElem<br />v<br />Version 2<br />
- 41. Sample UML models<br />w<br />Version 1<br />The HTMLList class became subclassof HTMLDocElem<br />Version 2<br />
- 42. Fragment of the Difference Model <br />The abstract class HTMLDocElemhas been added<br />
- 43. Fragment of the Difference Model<br />The abstract class HTMLDocElemhas been added<br />The operation dump()has been moved from HTMLDocto HTMLDocElem<br />
- 44. Fragment of the Difference Model<br />The abstract class HTMLDocElemhas been added<br />The operation dump() has been moved from HTMLDoc to HTMLDocElem<br />The HTMLList class became subclassof HTMLDocElem<br />
- 45. Difference Application<br />Once differences are calculated and represented, they can be applied over models as patches<br />The difference application is intended to <br />“reconstruct” the final model starting from the initial one<br />“patch” any model conforming to the base metamodel for reproducing the modifications<br />
- 46. Difference Application<br />Let (M2 – M1) = be a difference model, then patch(M) equals<br />M2 if M = M1 (reconstructive)<br />M if M M1 = (idempotent)<br />patch(M M1) (M/M1) if M M1 (transformative)<br />where <br /><ul><li>patch(M) = patch(, M) and
- 47. patch: MMD MM MM
- 48. reconstructive transformative</li></li></ul><li>Difference Application<br />The difference application patch is obtained by an automated higher-order transformation written in ATL<br />For each “base” metaclass MC in MMD, the following transformation rules are generated:<br />AddedMC2MC<br />ChangedMC2MC <br />UnchangedMC2MC<br />MMD2ATL<br />HOT<br />patchtransformation<br />MMD<br />
- 49. Difference Application<br />Rule AddedMC2MC<br />Each AddedMC induces a new MC instance in M2 and the corresponding structural features according to <br />Rule ChangedMC2MC<br />It updates MC elements in M1 according to the ChangedMCelements in <br />Rule UnchangedMC2MC <br />It serves for propagating in M2 the context of M1, ie what is left unchanged by <br />No rules are required for DeletedMC elements since they are simply ignored by the UnchangedMC2MCrule<br />
- 50. Overall Scenario<br />MM2MMD<br />MM<br />patchtransformation<br />MMD2ATL<br />HOT<br />MMD<br />
- 51. Overall Scenario<br />MM2MMD<br />MM<br />M2<br />conformsTo<br />conformsTo<br />M1<br />patchtransformation<br />MD<br />conformsTo<br />MMD2ATL<br />HOT<br />MMD<br />
- 52. Difference Operators<br />Dual<br />Given a difference model, it is useful to automatically define its inverse, ie if (M2 – M1) = the dual -1is such that <br />patch-1(M2) = M1<br /><br />-1<br />
- 53. Difference Operators<br />Sequential Composition <br />two or more subsequent modifications can be grouped in a single difference model<br />given 1 = (M2 – M1) and 2 = (M3 – M2) then the sequential composition 1 ; 2 is defined in such a way that <br />patch1; 2 = patch2 patch1<br />Parallel Composition<br />distributed manipulations of the same artifacts can be merged in a model difference as long as they are parallel indipendent<br />
- 54. Model Versioning - Patches<br />An interesting scenario discloses when arbitrary models are allowed as input for difference application<br />
- 55. Model Versioning - Patches<br />An interesting scenario discloses when arbitrary models are allowed as input for difference application<br />
- 56. Model Versioning - Patches<br />An interesting scenario discloses when arbitrary models are allowed as input for difference application<br />?<br />
- 57. Model Versioning - Patches<br />The application of manipulations as patches demands for several properties<br />Self-containedness: The representation of differences should contain enough information to be applied to arbitrary inputs<br />Minimality: The representation should not contain too much information thus locking the application to the initial context<br />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<br />
- 58. Overall Scenario<br />MM2MMD<br />MM<br />M2<br />conformsTo<br />conformsTo<br />M1<br />Application Model<br />patchtransformation<br />MD<br />conformsTo<br />MMD2ATL<br />HOT<br />MMD<br />
- 59. Overall Scenario<br />MM2MMD<br />MM<br />M2<br />conformsTo<br />conformsTo<br />M1<br />Application Model<br />patchtransformation<br />MD<br />conformsTo<br />MMD2ATL<br />HOT<br />MMD<br />
- 60.
- 61. Model Differences<br />Model differences are crucial for general model management and can disclose numerous opportunities<br />Once differences are represented as first-class entities, a number of operations can be defined on them<br />patches, dual, binary compositions, impact evaluation, etc<br />A proof of concept has been implemented on the Eclipse/AMMA platform <br />(http://www.eclipse.org/m2m/atl/usecases/MMIndApproachtoDiffRep)<br />
- 62. What comes next ?<br />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<br />Formalizing semantics is difficult, thus heuristics can provide some ad-hoc improvement<br />As soon we consider parallel composition the problem conflict specification, detection, and resolution<br />Parallel composition may give place to conflicts whenever the differences are not parallel independent<br />Depending on the process stage we may be interested in tuning false positives and negatives <br />
- 63. Summary<br />Model differences<br />Matching Algorithm<br />Conflict Management<br />Evolution <br />in the large (model evolution)<br />in the small (metamodel evolution)<br />Conclusions<br />60<br />
- 64. Model matching<br />Model Evolution and Versioning<br />61<br />
- 65. Outline<br />Introduction<br />Model matching<br />Static Identity-Based Matching<br />Signature-Based Matching<br />Similarity-Based Matching<br />Language-Specific<br />Case study<br />Conclusions<br />
- 66. Introduction<br />Differencing mechanisms for supporting the evolution of model-based artifacts are becoming crucial<br />Document comparison algorithms provided by version control systems like CVS, and SVN have been shown to be inadequate<br />Calculating model differences is a difficult task since it relies on model matching which can be reduced to the graph isomorphism problem<br />No efficient (i.e., polynomial-bound) algorithm for graph isomorphism is known and it has been conjectured that no such algorithm can exist<br /> [Ronald C. Read, Derek G. Corneil. The graph isomorphism disease. Journal of Graph Theory, 1(4):339-363, 2006]<br />
- 67. M1<br />Introduction<br />M2<br />
- 68. M1<br />Introduction<br />M2<br />Before calculating the differences a matching phase has to be performed to identify the elements which have to be compared<br />
- 69. Model matching<br />There are several requirements for model matching approaches including <br />accuracy<br />level of abstraction<br />tool independence<br />efficiency<br />user effort<br />Existing model matching approaches can be distinguished according to the following classification<br />Static Identity-Based Matching<br />Signature-Based Matching<br />Similarity-Based Matching<br />Custom Language-Specific Matching Algorithms<br />There is no single best solution to model matching<br />
- 70. Static Identity-Based Matching<br />It is assumed that each model element has a persistent and non-volatile unique identifier that is assigned to it upon creation<br />A basic approach for matching models is to identify matching model elements based on their corresponding identities<br />Pros<br /><ul><li>it requires no configuration from the user perspective
- 71. it is particularly fast</li></ul>Cons<br /><ul><li>it does not apply to models constructed independently of each other, and to model representation technologies that do not support maintenance of unique identities</li></li></ul><li>Signature-Based Matching<br />It is signature calculated dynamically from the values of its features by means of a user-defined function specified using a model querying language<br />Pros<br /><ul><li>it can be used to compare models that have been constructed independently of each other</li></ul>Cons<br /><ul><li>developers need to specify a series of functions that calculate the identities of different types of model elements</li></li></ul><li>Similarity-Based Matching<br />It treats models as typed attribute graphs and attempts to identify matching elements based on the aggregated similarity of their features<br />Similarity-based algorithms typically need to be provided with a configuration that specifies the relative weight of each feature<br />Pros<br /><ul><li>typed attribute graph matching algorithms have been shown to produce more accurate results</li></ul>Cons<br /><ul><li>such approaches fail to take into consideration the semantics of the modelling language</li></li></ul><li>Custom Language-Specific Matching Algorithms<br />They are tailored to a particular modelling language (e.g. UML, StateCharts)<br />They incorporate the semantics of the target language<br />e.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)<br />Pros<br /><ul><li>They provide more accurate results
- 72. They drastically reduce the search space</li></ul>Cons<br /><ul><li>Developers need to specify the complete matching algorithm manually or programmatically, which can be a particularly challenging task</li></li></ul><li>Custom Language-Specific Matching Algorithms<br />To ease the development of custom matching algorithms, approaches such as EMF Compare and the Epsilon Comparison Language (ECL) can be combined<br />They provide infrastructure which<br />can automate the trivial parts of the comparison process<br />enables developers to concentrate on the comparison logic only<br />Even with such tool support, the effort required to implement a custom matching algorithm is still considerable<br />
- 73. Some model matching approaches<br />
- 74. Case study<br />Modified version of M1<br />Sample UML model M1<br />the classes School and Student have been moved to a new package administration;<br />the parameter student of the operation register in the class School has been modified by changing its type from String to Student;<br />the attribute surname has been added in the class Student<br />the attribute yearsOld has been renamed to age;<br />the class Person has been added in the new package administration;<br />the package inventory has been added in the package school<br />
- 75. Case study > Static identity-based matching <br />It is able to detect all the modifications without any user effort<br />Even the renaming of the attribute yearsOld can be correctly discovered<br />Fragment of the differences calculated by TOPCASED tool<br />
- 76. Case study > Signature-Based Matching<br />It is not is not able to detect all the changes<br />The modifications to the School and Student classes have been detected as deletions and additions of new ones with new structural features<br />Differences calculated by EMFCompare<br />
- 77. Case study > Signature-Based Matching<br />It is not is not able to detect all the changes<br />The modifications to the School and Student classes have been detected as deletions and additions of new ones with new structural features<br />Although it is still possible to build the final model starting from the initial, any analysis cannot rely on the missing tracing information<br />Differences calculated by EMFCompare<br />
- 78. Case study > Similarity-Based Matching<br />All the differences have been correctly detected but the renaming of the attribute yearsOld<br />Such a modification is detected as a deletion of the yearsOld attribute and an addition of the age one<br />there is not a match between them that can be specified in general with respect to the semantics of UML<br />Differences calculated by SiDiff<br />
- 79. Case study > Custom Language-Specific Matching Algorithms<br />All the modifications are detected<br />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<br />Differences calculated by ECL<br />
- 80. EMF Compare<br />EMF Compare is an EMFT component providing out-of-the-box model comparison and merging capabilities<br />
- 81. EMF Compare > Architectural Issues<br />Since its begining the EMF Compare component has been designed so that every part of the process is extensible<br />
- 82. EMF Compare > Architectural Issues<br />Since its begining the EMF Compare component has been designed so that every part of the process is extensible<br />How we can easily implement a matching algorithm capable of encompassing designer-defined heuristics (without too much effort) ?<br />
- 83. ECL: Epsilon Comparison Language<br />The aim of the Epsilon Comparison Language (ECL) is to enable users to specify comparison algorithms in a rule-based manner <br />ECL is a hybrid rule-based language which is used in combination with EMF Compare<br />A ECL specification defines a matching algorithm for EMF Compare<br />The specified rules permit to identify pairs of matching elements between two models<br />ECL is part of the Eclipse GMT project: http://www.eclipse.org/gmt/epsilon/doc/ecl/<br />
- 84. ECL > Abstractsyntax<br />
- 85. ECL > Abstractsyntax<br />A match rule has three parts: <br />- the guard part;<br />- the compare part; <br />- the do part;<br />
- 86. ECL > Abstractsyntax<br />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<br />
- 87. ECL > Abstractsyntax<br />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 <br />
- 88. ECL > Abstractsyntax<br />The do part is an EOL expression or block that is executed if the compare part returns true to perform any additional actions required<br />
- 89. ECL > Abstractsyntax<br />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.<br />
- 90. ECL > Concrete syntax<br />Concrete syntaxof a MatchRule<br />Concrete syntaxof a Pre and Post block<br />
- 91. ECL > Comparison Outcome<br />The result of comparing two models with ECL is a model containing <br />a trace (MatchTrace) that consists of a number of matches (Match)<br />Each match holds <br />a reference to the objects from the two models that have been compared (left and right), <br />a boolean value that indicates if they have been found to be matching or not, <br />a reference to the rule that has made the decision, <br />and a Map (info) thatis used to hold any additional information required by the user<br />
- 92. ECL > MatchTrace<br />
- 93. Example (1)<br />
- 94. Example (1)<br />Let us consider a labeled tree<br />Sample Treemetamodel<br />
- 95. Example (1) > calculated differences with the generic matching algorithm<br />M1<br />M2<br />Tree b and all the containedtreeelements (Tree c, Tree d) havebeenremoved<br />Tree e and all the containedtreeelements (Tree c, Tree d) havebeenadded<br />Note that Tree c and Tree d in M1 and M2 are different trees<br />
- 96. Example (1)<br />The rule specifies that for two Tree nodes (l and r) to match, they should have the same label<br />Sample Treemetamodel<br />rule Tree2Tree<br />match l : T1!Treewith r : T2!Tree<br />{<br />compare : l.label = r.label<br />}<br />Sample ECL specification<br />
- 97. Example (1) > calculated differences with the customized matching algorithm<br />Tree bhasbeenremoved<br />Tree ehasbeenadded<br />TreechasbeenmovedfromTree b toTreed<br />Treed hasbeenmovedfromTreectoTreee<br />This faithfully reflects the designer intentions, i.e. Tree c and Tree d in M1 and M2 are the same! <br />
- 98. Example (2) > calculated differences with the generic matching algorithm<br /><Class> c3 and <Package> org (and itsdescendents) havebeenremoved<br /><Class> c1 and <Class> c3 havebeenadded<br />
- 99. Example (2) > customizationof the matchingalgorithm<br />ruleClass<br />match l : Left!Classwith r : Right!Class {<br />compare : l.name = r.name<br />do {<br />l.ownedOperation.doMatch(r.ownedOperation);<br />}<br />}<br />@lazy<br />ruleOperation<br />match l : Left!Operationwithr : Right!Operation {<br />compare {<br />-- First check to see if the names and the owning classes match<br />varbasicMatch := l.name = r.name andl.class.matches(r.class);<br />-- If we have only one operation in each class <br />-- with that name they match<br />if (basicMatch) {<br />if (l.class.hasOnlyOneOp(l.name) andr.class.hasOnlyOneOp(l.name)) {<br />returntrue;}<br /> else {<br /> -- Else we have to check their parameters as well<br />returnl.ownedParameter.matches(r.ownedParameter);<br />}}<br />elsereturnfalse;<br />}<br />do {l.ownedParameter.doMatch(r.ownedParameter);}<br />}<br />
- 100. Example(2) > results with the customized matching algorithm<br /><Class> c3 and <Package> org havebeenremoved<br /><Class> c1hasbeenmovedfrom<Package> org to<Model> m2<br /><Operation> op1() hasbeenadded in <Class> c1 <br /><Class> c2 hasbeenadded<br />
- 101. Example(3) > beContent<br />beContent is an model-driven platform for designing and maintaining web applications<br />A beContent model consists mainly of the declarative and coordinated specification of three different concerns:<br />the data view is the description of the relational model of the data, in essence it describes the metadata of the application;<br />the content view describes the data sources and how the content is retrieved and aggregated in pages; and finally<br />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.<br />
- 102. Example (4) > sample beContentmodel<br />
- 103. Example (4) > refinedbeContentmodel<br />
- 104. Example (4) > calculated differences with the generic matching algorithm<br />
- 105. Example (4) > customizationof the matchingalgorithm<br />ruleCustomEntity<br />match l : Left!CustomEntitywith r : Right!CustomEntity {<br />compare : l.name.fuzzyMatch(r.name) orl.isSplit(r)<br />…<br />}<br />…<br />operationLeft!CustomEntityisSplit(r : Right!CustomEntity) : Boolean {<br />varenumerationFieldSet : OrderedSet(Enumeration) = self.fields.select(e | e.isTypeOf(Left!Enumeration));<br />varisSplit : Boolean = false;<br />isSplit = not (Right!CustomEntity.allInstances()->select(e | e.superType.isDefined() <br />and<br />enumerationFieldSet->exists(c | c.isDefined() andc.literals->exists(l | l.name = e.nameande.superType.name = r.name))<br /> )<br /> )->isEmpty();<br />returnisSplit; <br />}<br />
- 106. Example (4) > calculated differences with the customized matching algorithm<br />
- 107. Modeldifferencesforsupporting system migrations<br />
- 108. Modeldifferencesforsupporting system migrations<br />
- 109. Modeldifferencesforsupporting system migrations<br />
- 110. Modeldifferencesforsupporting system migrations<br />
- 111. Modeldifferencesforsupporting system migrations<br />
- 112. Modeldifferencesforsupporting system migrations<br />A splitmodificationhasbeenoperated<br />
- 113. Modeldifferencesforsupporting system migrations<br />Generatedmigrationtool<br />
- 114. Model Matching<br />There is no single best solution to model matching<br />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<br />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<br />Our arguments are based on practical experience obtained through experimentation with several implementations of matching algorithms and tools<br />
- 115. Discussion<br />Especially when dealing with general purpose modeling language, it might be interesting to use also taxonomic/ontology systems, such as WordNet<br />This would have two advantages<br />Ease the task of defining correspondences among names whose meaning is “close” enough<br />Would permit to discover relations which are otherwise hidden in the model<br />
- 116. Summary<br />Model differences<br />Matching Algorithm<br />Conflict Management<br />Evolution <br />in the large (model evolution)<br />in the small (metamodel evolution)<br />Conclusions<br />115<br />
- 117. Managing model conflicts in distributed development<br />
- 118. Conflict Management<br />Introduction<br />Model versioning<br />Distributed development<br />Conflict management in MDE<br />Representation of model differences<br />A DSL for conflict specification<br />Syntax<br />Semantics<br />Conclusions and future work<br />
- 119. Introduction<br />Model Driven Engineering (MDE) aims at shifting the focus of software development from coding to modeling and considers models as primary artifacts<br />Complex software systems are developed in distributed environments which demands a precise discipline in the management of model versions<br />Conflict management is an unavoidable aspect when dealing with distributed versions of the same artifact<br />
- 120. Introduction<br />We propose a Domain-Specific Language for conflict management which is intended to <br />define conflicts related to the underlying domain-specific semantics and<br />provide different tolerance degree to collisions depending on the particular stage of modeling process<br />
- 121. Introduction<br />
- 122. Introduction<br />Modeler #1<br />
- 123. Introduction<br />Modeler #1<br />Modeler #2<br />
- 124. Introduction / Distributed development<br />
- 125. Introduction / Distributed development<br />Visibility changed to private.<br />
- 126. Introduction / Distributed development<br />New operation added.<br />
- 127. Introduction / Distributed development<br />New constructor added.<br />
- 128. Introduction / Distributed development<br />Public or private ?<br />
- 129. Introduction / Distributed development<br />Singleton design pattern introduction and violation<br />
- 130. Conflict management<br />Identification of changes occurred in each concurrent model version by means of some evolution representation approach<br />
- 131. Conflict management<br />Identification of changes occurred in each concurrent model version by means of some evolution representation approach<br />Conflict detection is based on the comparison between concurrent versions of the modifications <br />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<br />
- 132. Conflict management<br />Identification of changes occurred in each concurrent model version by means of some evolution representation approach<br />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<br />Conflict resolution is a strategy given to reconcile colliding manipulations, in general provided by the developer<br />
- 133. A DSL for conflict specification<br />It is relies on the model-based difference representation seen before<br />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<br />The pattern language allows to specify regular expressions as names of the involved entities<br />Patterns can declare and recall bound variables making it possible to refer to the properties of the current match<br />Other useful features are negative patterns and multiplicity of matches<br />
- 134. A model-baseddifferencerepresentation<br />[TOOLS07]<br />
- 135. Difference metamodel example<br />
- 136. Difference metamodel example<br />MM2MMD<br />
- 137. Sample modeldifferencerepresentation<br />
- 138. Sample modeldifferencerepresentation<br />
- 139. A DSL for conflict specification<br />Metamodel independent, relies on difference models and metamodels<br />
- 140. A DSL for conflict specification<br />Metamodelindependent, relies on difference models and metamodels<br />Conflict specification, fine-tunes false positives and negatives and adds fuzziness to conflict management<br />
- 141. A DSL for conflict specification<br /><ul><li>Metamodel 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 criteria</li></li></ul><li>Conflict specification syntax / Example<br />If the left-hand side <br />introduces the Singleton <br />design pattern<br />
- 144. Conflict specification syntax / Example<br />If the right-hand side <br />violates the Singleton<br />If the left-hand side <br />introduces the Singleton <br />design pattern<br />
- 145. Interpreting conflict specifications<br />The definitions of conflicts are given precise semantics by means of OCL<br />The graphical representation of OCL expressions is not new and has taken inspiration from the work on Join Point Designation Diagrams (JPDDs) [SHU05]<br />OCL constructs are embedded in ATL transformations to build rules able to detect interfering modifications<br />Other possible semantics can be given mapping the diagrammatic definition of conflicts toward corresponding rules for instance by graph transformations or declarative techniques<br />
- 146. Conflict specification semantics<br />
- 147. Conflict specification semantics<br />For each match of the left pattern …<br />
- 148. Conflict specification semantics<br />… find a corresponding match of the right pattern<br />
- 149. Conflict specification semantics<br />… find a corresponding match of the right pattern<br />The engine looks for matches induced by the left-hand side pattern<br />For each match a variable binding is operated on the right pattern<br />The engine looks for matches induced by the current right-hand side pattern<br />
- 150. Conflict specification semantics<br />For each DifferenceElement…<br />… matching rules for metaattributes are applied<br />
- 151. Conflict specification semantics<br />For each DifferenceElement…<br />… matching rules for metaattributes are applied<br />… matching rules for structural properties (including relations) are applied<br />
- 152. Conflict Management<br />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<br />A model-based difference representation approach and a pattern language relying on it enable the management of distributed development<br />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<br />Libraries of conflict specifications<br />
- 153. Conflict Management<br />A prototypical implementation of the approach based on the AMMA platform is available at http://www.di.univaq.it/cicchetti/conflictManagement.php<br />The approach needs a usability validation which encompasses larger population of conflict cases<br />The DSL could be improved introducing unary conflicts<br />The specification of resolution strategies have to be further investigated, like defining a reconciliation process or minimizing the conflicting portions<br />
- 154. Summary<br />Model differences<br />Calculation<br />Representation<br />Visualization<br />Matching Algorithm<br />Conflict Management<br />Evolution <br />in the large (model evolution)<br />in the small (metamodel evolution)<br />Conclusions<br />152<br />
- 155. Evolution in the large and in the small<br />Model Evolution and Versioning<br />
- 156. Introduction <br />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<br />Coordinated collections of models and modeling languages are used to describe web applications on different abstraction levels and from different perspectives <br />Models and metamodels are not preserved from the evolutionary pressure which inevitably affects almost any artifacts, possibly causing a cascade of adaptations<br />154<br />
- 157. Modeling languages<br />Modeling languages can be used to specify problems, solutions and the mapping among them in the corresponding domains<br />abstraction<br />Domain-specific modeling languages<br /><ul><li>P</li></ul>problem domain<br /><ul><li>S</li></ul>General-purpose modeling languages,<br />eg. UML <br />solution domain<br />
- 158. Evolution<br />Any modeling language can be subject to different evolutionary pressures <br />The evolution of general-purpose modeling languages (GPMLs) is comparable to that of general-purpose languages and tend to be monotone and sparse<br />
- 159. Evolution<br />Any modeling language can be subject to different evolutionary pressures <br />The evolution of general-purpose modeling languages (GPMLs) is comparable to that of general-purpose languages and tend to be monotone and sparse<br />UM 0.8<br />UML 1.1<br />UML 1.4<br />UML 2.0<br />UML 2.2<br />UML 0.9<br />UML 1.3<br />UML 1.5<br />UML 2.1.2<br />1995<br />1997<br />2005<br />2000<br />2003<br />2007<br />
- 160. Evolution<br />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<br />Moreover, they require specific support tools which have to be adapted according to the metamodel evolution<br />
- 161. Evolution<br />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<br />Moreover, they require specific support tools which have to be adapted according to the metamodel evolution<br />
- 162. Evolution<br />I would like to discuss the problem of the evolution in model-driven development<br />
- 163. Evolution<br />I would like to discuss the problem of the evolution in model-driven development engineering<br />MDD<br />MDE<br />
- 164. Evolution<br />I would like to discuss the problem of the evolution in model-driven development engineering<br />This talk analyzes the different kinds of co-adaptations distinguishing among co-evolution in the large and in the small<br />when a metamodel undergoes a modification, the conforming models require to be accordingly co-adapted<br />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<br />
- 165. Summary<br />Introduction<br />Evolution in the Large: MetamodelEvolution<br />Problem-based adaptation<br />Solution-based adaptation<br />Metamodel change classification<br />Transformationaladaptationofmodels<br />Evolution in the Small: Application Model Evolution<br />Data migration<br />Adaptation of specific assets<br />Conclusions and future work<br />
- 166. M3<br />The “language” oflanguages,<br />eg. Ecore<br />Meta Metamodel<br />The modelinglanguage, typicallyusedtoengineerthe applicationdomain, eg. UWE, WebML, beContent<br />M2<br />Meta modeling architecture<br />Metamodels<br />Instancemodelswhichrepresentproblems and solutions in the application domain<br />M1<br />Models<br />Tools<br />(VisualEditors)<br />Systems and applicationsrealizing the solutionin the applicationdomain, eg. portals, data-intensive web apps, etc<br />Tools<br />(VisualEditors)<br />Tools<br />(VisualEditors)<br />M0<br />Tools<br />(VisualEditors)<br />Tools<br />(VisualEditors)<br />Tooln<br />
- 167. M3<br />M2<br />M1<br />M0<br />Metamodel based tools<br />conformsTo<br />Meta Metamodel<br />Metamodel<br />conformsTo<br />Model<br />basedOn<br />edits<br />implementedFor<br />Tool<br />
- 168. This is a domain<br /><ul><li>P1
- 169. P2
- 170. P3</li></li></ul><li>Domainsusually do nothavecrispyboundaries<br />This is a domain<br /><ul><li>P1
- 171. P2
- 172. P3</li></li></ul><li>This is a specific problem in the domain<br />domain<br /><ul><li>P1
- 173. P2
- 174. P3</li></li></ul><li>Goal: formalize a modeling language for capturing the domain problems<br />domain<br /><ul><li>P1
- 175. P2
- 176. P3</li></li></ul><li>Metamodel<br />Goal: formalize a modeling language for capturing the domain problems<br />domain<br /><ul><li>P1
- 177. P2
- 178. P3</li></li></ul><li>Metamodel<br />Goal: formalize a modeling language for capturing the domain problems<br />domain<br /><ul><li>P1
- 179. P2
- 180. P3</li></li></ul><li>M3<br />Model Transformations<br />conformsTo<br />conformsTo<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />from<br />Target Metamodel<br />Source Metamodel<br />TransformationLanguage<br />conformsTo<br />conformsTo<br />conformsTo<br />M1<br />Target Model<br />Source Model<br />TransformationRules<br />source<br />target<br />exec<br />TransformationEngine<br />M0<br />
- 181. Metamodel<br />Model transformations map problems to solutions<br />domain<br /><ul><li>P1
- 182. P2
- 183. P3</li></li></ul><li>Model transformations map problems to solutions<br /><ul><li>S1</li></ul>domain<br /><ul><li>P1
- 184. S2
- 185. P2
- 186. P3</li></ul>Metamodel<br />
- 187. Metamodel evolution<br />Sometimes metamodels must be adapted, extended or amended to better capture the problems<br />
- 188. Metamodel evolution<br />Sometimes metamodels must be adapted, extended or amended to better capture the problems<br />This may happen because <br />the domains are often only partially analyzed and several instances may be left out<br />new requirements must be considered which will result in a domain refinement or enlargement<br />a more complete understanding of the domain is at hand<br />
- 189. Metamodel<br />domain<br /><ul><li>P1
- 190. P2
- 191. P3</li></li></ul><li>Metamodel<br />domain<br /><ul><li>P1
- 192. P2
- 193. P3</li></li></ul><li>M3<br />Model Transformations<br />conformsTo<br />conformsTo<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />from<br />Target Metamodel<br />Source Metamodel<br />TransformationLanguage<br />conformsTo<br />conformsTo<br />conformsTo<br />M1<br />Target Model<br />Source Model<br />TransformationRules<br />source<br />target<br />exec<br />TransformationEngine<br />M0<br />
- 194. M3<br />Model Transformations<br />conformsTo<br />conformsTo<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />from<br />Target Metamodel<br />Source Metamodel<br />TransformationLanguage<br />Source Metamodel<br />conformsTo<br />conformsTo<br />conformsTo<br />M1<br />Target Model<br />Source Model<br />TransformationRules<br />source<br />target<br />exec<br />TransformationEngine<br />M0<br />
- 195. Model Transformations<br />conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />from<br />Target Metamodel<br />Source Metamodel<br />TransformationLanguage<br />Source Metamodel<br />conformsTo<br />conformsTo<br />conformsTo<br />M1<br />Target Model<br />Source Model<br />TransformationRules<br />source<br />target<br />exec<br />TransformationEngine<br />M0<br />
- 196. Model Transformations<br />conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />from<br />Target Metamodel<br />Source Metamodel<br />TransformationLanguage<br />Source Metamodel<br />conformsTo<br />conformsTo<br />conformsTo<br />M1<br />Target Model<br />Source Model<br />TransformationRules<br />source<br />target<br />exec<br />TransformationEngine<br />M0<br />
- 197. Model Transformations<br />conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />from<br />Target Metamodel<br />Source Metamodel<br />TransformationLanguage<br />Source Metamodel<br />conformsTo<br />conformsTo<br />conformsTo<br />M1<br />Target Model<br />Source Model<br />TransformationRules<br />source<br />target<br />exec<br />TransformationEngine<br />M0<br />
- 198. Metamodel changes<br />A metamodel can undergo a number of different kinds of modifications which are classified in <br />Non-breaking<br />Breaking <br />The breaking modifications can be divided into<br />Breaking and resolvable: existing instances need to be co-adapted to conform to the new metamodel version. The co-evolution can be automatically operated<br />Breaking and unresolvable: the necessary co-adaptation of existing models can not be automatically computed due to the need of further information<br />[Paige at al 2007]<br />
- 199. Metamodel changes classification<br />
- 200. Sample Petri Net metamodel changes<br />
- 201. Sample Petri Net metamodel changes<br />Breaking and resolvable changes<br />(extract meta-class)<br />
- 202. Sample Petri Net metamodel changes<br />Breaking and resolvable changes<br />(extract meta-class)<br />t1<br />pt1<br />tp1<br />p1<br />p2<br />p1<br />p2<br />pt2<br />tp2<br />t2<br />
- 203. Sample Petri Net metamodel changes<br />Breaking and unresolvablechange<br />(Addobligatorymetaproperty)<br />
- 204. Sample Petri Net metamodel changes<br />weight=?<br />weight=?<br />pt1<br />tp1<br />pt1<br />tp1<br />p1<br />p2<br />p1<br />p2<br />pt2<br />tp2<br />pt2<br />tp2<br />weight=?<br />weight=?<br />Breaking and unresolvablechange<br />(Addobligatorymetaproperty)<br />
- 205. Model difference representation<br />
- 206. Metamodel difference representation<br />Since a meta-model is a model itself, metamodel differences can be represented by exploiting the previously mentioned approach<br />
- 207. Sample metamodeldifferencerepresentation<br />
- 208. Transformational adaptation of models<br />Δ consist of an arbitrary combination of the atomic changes<br />In order to distinguish them the following steps are performed:<br />automatic decomposition of Δ in two disjoint (sub) models, ΔR and Δ¬R, which denote breaking resolvable and unresolvable changes;<br />if ΔR and Δ¬R are parallel independent then we separately generate the corresponding co-evolutions;<br />if ΔR and Δ¬R are parallel dependent, they are further refined to identify and isolate the interdependencies causing the interferences<br />
- 209. Transformationaladaptationofmodels: example<br />Δ(0,1)<br />
- 210. Transformationaladaptationofmodels: example<br />Restrictmetapropertychange<br />Extractmetaclasschanges<br />Δ(0,1)<br />
- 211. Transformationaladaptationofmodels: example<br />moduleH_R;<br />createOUT : ATL from Delta : KM3Diff;<br />ruleCreateRenaming {<br />…<br />}<br />ruleCreateExtractMetaClass{<br />…<br />}<br />…<br />HR<br />ΔR(0,1)<br />
- 212. Transformationaladaptationofmodels: example<br />moduleH_R;<br />createOUT : ATL from Delta : KM3Diff;<br />ruleCreateRenaming {<br />…<br />}<br />ruleCreateExtractMetaClass{<br />…<br />}<br />…<br />HR<br />module CTR;<br />create OUT : MM1 from IN : MM0;<br />…<br />rulecreatePTArc(s : OclAny, n : OclAny) {<br />…<br />}<br />rulecreateTPArc(s : OclAny, n : OclAny) {<br />…<br />}<br />ΔR(0,1)<br />CTR<br />
- 213. Transformationaladaptationofmodels: example<br />CTR<br />t1<br />pt1<br />tp1<br />p1<br />p2<br />p1<br />p2<br />pt2<br />tp2<br />t2<br />
- 214. Transformationaladaptationofmodels: example<br />module H_NR;<br />createOUT : ATL from Delta : KM3Diff;<br />rule CreateRestrictMetaproperty{ …<br />}<br />ruleAddObligatoryMetaclass{<br />…<br />}<br />…<br />Δ¬R(0,1)<br />H¬R<br />
- 215. Transformationaladaptationofmodels: example<br />module H_NR;<br />createOUT : ATL from Delta : KM3Diff;<br />rule CreateRestrictMetaproperty{ …<br />}<br />ruleAddObligatoryMetaclass{<br />…<br />}<br />…<br />Δ¬R(0,1)<br />H¬R<br />module CTR;<br />create OUT : MM1 from IN : MM0;<br />…helper context MM2!Net def:createPlaceInstances() : Sequence (MM2!Place) =<br />if (thisModule.placeInstances < 1) then<br />thisModule.createPlace(self) ->asSequence() ->union(self.createPlaceInstances())<br />else<br />Sequence{}<br />endif;<br />…<br />CT¬R<br />
- 216. Parallel dependent modifications<br />The automatic co-adaptation of models relies on the parallel independence of breaking resolvable and unresolvable modifications, or more formally<br />ΔR|Δ¬R = ΔR;Δ¬R +Δ¬R;ΔR<br />where + denotes the non-deterministic choice<br />
- 217. Parallel dependent modifications<br />The automatic co-adaptation of models relies on the parallel independence of breaking resolvable and unresolvable modifications, or more formally<br />ΔR|Δ¬R = ΔR;Δ¬R +Δ¬R;ΔR<br />where + denotes the non-deterministic choice<br />Bad news: the parallel independence of changes is not assured, ie. multiple changes can be interdependent one another<br />
- 218. Parallel dependent modifications<br />
- 219. Parallel dependent modifications<br />The differences between MM2 and MM0 are not parallel independent (although the sub steps MM0−MM1 and MM1 − MM2 are directly manageable)<br />The interdependenciesbetween the atomic changes in MM2 − MM0 have to be isolated (i.e. the attribute weight of the Arc metaclass of MM2)<br />
- 220. Resolving dependences<br />We analyzed the kind of interdependencies among breaking resolvable and breaking unresolvable changes<br />We found out that these interdependencies do not depend on the specific metamodel, rather only on the meta metamodel (eg. Ecore, MOF, KM3)<br />[ICMT 2009]<br />
- 221. Resolving dependences<br />Sufficient criteria have been given to establish the correct scheduling of the conflicting changes<br />
- 222. Resolving dependences<br />An alternative approach ([1]) is based on a lazy evaluation mechanism which queues up adaptations which require unavailable information<br />We have found that for KM3, Ecore, and MOF interdependencies are not circular and that they only depend on the meta metamodel<br />This implies that it is possible to find the exact scheduling of the adaptation steps w/o queuing them<br />[1] Narayanan, Levendovszky, Balasubramanian, Karsai: Domain ModelMigrationtoManageMetamodelEvolution, MoDELS 2009<br />
- 223. Approach<br />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<br />the management of complex metamodel modifications (in contrast with current approaches)<br />the complete automatic adaptation of models (breaking non resolvable via transformation refinements)<br />We are currently working on the migration of UWE models<br />
- 224. Summary<br />Introduction<br />Evolution in the Large: Metamodel Evolution (XLE)<br />Problem-based adaptation<br />Solution-based adaptation<br />Metamodel change classification<br />Transformationaladaptationofmodels<br />Evolution in the Small: Application Model Evolution (XSE)<br />Data migration<br />Adaptation of specific assets<br />Conclusions and future work<br />
- 225. Solution-based adaptation<br />The chosen generic modeling platform – intended as a set of languages, systems, and transformation paradigms – may affect the metamodel life-cycle<br />In fact, sometimes metamodels must be changed in order to permit solutions which are otherwise not admissible<br />
- 226. beContent<br />beContent is an model-driven platform for designing and maintaining web applications<br />A beContent model consists mainly of the declarative and coordinated specification of three different concerns:<br />the data view is the description of the relational model of the data, in essence it describes the metadata of the application;<br />the content view describes the data sources and how the content is retrieved and aggregated in pages; and finally<br />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.<br />
- 227. beContent<br />ECLIPSE GMF<br />AMMA TCS<br />beContentMetamodel<br />ECLIPSE Ecore<br />ACCELEO<br />AMMA ATL<br />ACCELEO<br />
- 228. beContent architecture<br />BML<br />BTL<br />round-tripping<br />ECLIPSE GMF<br />AMMA TCS<br />ECLIPSE GMF<br />AMMA TCS<br />beContentMetamodel<br />beContentMetamodel<br />ECLIPSE Ecore<br />ECLIPSE Ecore<br />M2C<br />M2M<br />ACCELEO<br />AMMA ATL<br />ACCELEO<br />AMMA ATL<br />M2C<br />M2C<br />PHPMySQL<br />ACCELEO<br />ACCELEO<br />ACCELEO<br />J2EE/Liferay<br />.NET<br />
- 229. BML – beContent Modeling Language<br />[demo at ICWE 2009]<br />
- 230. BMM – beContentMetamodel<br />
- 231. BMM – beContentMetamodel<br />
- 232. BMM – beContentMetamodel<br />. . .<br />Metamodel fragment<br />Model fragment<br />
- 233. Problem: a simple text generation<br />Generate a text file containing source code based on information which is retrieved from different instances of the same metaclass<br />
- 234. Problem: a simple text generation<br />. . .<br />...<br />
- 235. Problem: a simple text generation<br />Generate a text file containing source code based on information which is retrieved from different instances of the same metaclass<br />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<br />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<br />
- 236. Refactoring the metamodel<br />MM v1.0<br />MM v2.0<br />
- 237. Problem: a simple text generation<br />In this scenario, a simple change of the metamodel from v1.0 to v2.0 is already pretty troublesome as it would require <br />the adaptation of the models, which can be performed automatically as shown before<br />the manual adaptation of the tools<br />A possible workaround …<br />
- 238. Hiding the metamodel refactoring<br />Δ<br />Metamodel v1.0<br />Metamodel v2.0<br />conformsTo<br />conformsTo<br />adapt(Δ)<br />Model (v2.0)<br />Model (v1.0)<br />M2T<br />Source code<br />
- 239. Evolution in the large – open questions<br />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<br />Metamodel difference calculation: it is very difficult, none of the available approaches are really satisfactory because of domain semantics, similarity metrics, etc<br />Update: we are having interesting result by combining EMF Compare and ECL for Ecoremetamodels differencing<br />Overriding default adaptation with ad-hoc refactorings<br />Semantics preserving ?<br />Validation, everybody is very keen on keeping her/his models secret :-)<br />
- 240. Summary<br />Introduction<br />Evolution in the Large: Metamodel Evolution (XLE)<br />Problem-based adaptation<br />Solution-based adaptation<br />Metamodel change classification<br />Transformationaladaptationofmodels<br />Evolution in the Small: Application Model Evolution (XSE)<br />Data migration<br />Adaptation of specific assets<br />Conclusions and future work<br />
- 241. Evolution in the small<br />Manual modifications<br />Model (v1.0)<br />Model (v2.0)<br />T<br />T<br />System”<br />System’<br />
- 242. Evolution in the small<br />Regenerating the whole system may require lots of time which reduce the usability for the designers, possibile solutions are incremental/live transformations<br />Not all the aspects can be generated or derived by the models, eg. a model modification may require <br />a data migration procedure<br />a consistency check of the graphic templates<br />Typically transformations encode knowledge about the underlying platform and architecture, eg.<br />persistent classes and serialized objects in Java must be in sync<br />
- 243. Evolution in the small<br />Δ<br />M1<br />M2<br />T<br />T<br />System2<br />System1<br />
- 244. Evolution in the small<br />Δ<br />M1<br />M2<br />T<br />T<br />System2<br />System1<br />uses<br />uses<br />data1<br />data2<br />
- 245. Evolution in the small<br />Δ<br />M1<br />M2<br />T<br />T<br />System2<br />System1<br />uses<br />uses<br />data1<br />data2<br />migration<br />(evolutionrollbackauxfunctions)<br />
- 246. Evolution in the small<br />Δ<br />M1<br />M2<br />T<br />T<br />System2<br />System1<br />T’<br />uses<br />uses<br />data1<br />data2<br />migration (Δ)<br />
- 247. Evolution in the small: beContent example<br />Manual modifications<br />Simple data refactoring<br />birthday is deleted<br />a new reference is added<br />
- 248. Evolution in the small: beContent example<br />Δ<br />
- 249. Evolution in the small: beContent example<br />This is a special case in beContent as the underlying framework is able to detect new tables to be created<br />
- 250. Evolution in the small: beContent example<br />ALTER TABLE Person ADD (zodiac INT UNSIGNED NOT NULL);<br />ALTER TABLE PersonDROP COLUMN birthday;<br />
- 251. Evolution in the small: beContent example<br />As the difference model is a model, it is possible to generate anything based on its content<br />eg. a configuration for a migration wizard to assist the designer<br />
- 252. Conclusions<br />Using DSML (in contrast with a GPML) has the advantage to increase the degree of automation by exploiting the metamodeling hierarchy<br />The evolution of models and metamodels is almost unavoidable if they are inherently part of the process (as both main actors and instruments)<br />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<br />
- 253.
- 254. Bibliography<br />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.<br />Antonio Cicchetti, Davide Di Ruscio, and Alfonso Pierantonio. A metamodelindependentapproach to difference representation. Journal of Object Technology, 6(9):165–185, 2007.<br />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<br />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<br />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<br />A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, AutomatingCo-evolution in Model-DrivenEngineering. Procs. EDOC 2008, Munich, Germany<br />Antonio Cicchetti, Davide Di Ruscio, Ludovico Iovino, Alfonso Pierantonio, ManagingevolvingWebapplications, Technical Report Dipartimento di Informatica, Università degli Studi dell’Aquila, May 2010<br />B. Gruschko, D. Kolovos, and R. Paige. Towards Synchronizing Models with Evolving Metamodels. In Procs of the Work. MODSE, 2007.<br />G. Wachsmuth. Metamodel Adaptation and Model Coadaptation. In E. Ernst, editor, Proceedings of the 21st ECOOP, volume 4069 of LNCS. Springer-Verlag, July 2007.<br />240<br />Model Differences and Evolution<br />
- 255. Contact Information<br />Prof. Alfonso PierantonioDipartimento di InformaticaUniversità degli Studi dell’AquilaI-67100 L’Aquila, Italy<br />alfonso.pierantonio@univaq.ithttp://www.di.univaq.it/alfonso<br />Research Interests:CoupledEvolutionofModels, Tranformations and Tools, BidirectionalTransformations, ModelVersioning<br />241<br />Model Differences and Evolution<br />

No public clipboards found for this slide

×
### Save the most important slides with Clipping

Clipping is a handy way to collect and organize the most important slides from a presentation. You can keep your great finds in clipboards organized around topics.

Be the first to comment