Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Evolution in the Large and in the Small in Model-Driven Development <br />
Introduction <br />Model Driven Engineering (MDE) is increasingly gaining acceptance in the development of software as a m...
Modeling languages<br />Modeling languages can be used to specify problems, solutions and the mapping among them in the co...
Evolution<br />Any modeling language can be subject to different evolutionary pressures <br />The evolution of general-pur...
Evolution<br />Any modeling language can be subject to different evolutionary pressures <br />The evolution of general-pur...
Evolution<br />The evolution of domain-specific modeling languages (DSMLs) is more rapid and elaborated as they tend to ha...
Evolution<br />The evolution of domain-specific modeling languages (DSMLs) is more rapid and elaborated as they tend to ha...
Evolution<br />I would like to discuss the problem of the evolution in model-driven development<br />
Evolution<br />I would like to discuss the problem of the evolution in model-drivendevelopment<br />
Evolution<br />I would like to discuss the problem of the evolution in model-drivendevelopment engineering<br />
MDD<br />
MDD<br />MDE<br />MDE<br /> MDD<br />
MDD<br />MDE<br />MDE<br /> MDD<br />We have not yet seen the full application deployment of MDE!<br />[J. Bezivin keynote...
Evolution<br />I would like to discuss the problem of the evolution in model-drivendevelopment engineering<br />This talk ...
Summary<br />Introduction<br />Evolution in the Large: Metamodel Evolution (XLE)<br />Problem-based adaptation<br />Soluti...
Summary<br />Introduction<br />Evolution in the Large: Metamodel Evolution (XLE)<br />Problem-based adaptation<br />Soluti...
M3<br />The “language” oflanguages,<br />eg. Ecore<br />Meta Metamodel<br />The modelinglanguage, typicallyusedtoengineert...
M3<br />M2<br />M1<br />M0<br />Metamodel based tools<br />conformsTo<br />Meta Metamodel<br />Metamodel<br />conformsTo<b...
This is a domain<br /><ul><li>P1
P2
P3</li></li></ul><li>Domains usually do not have crispy boundaries.<br />This is a domain<br /><ul><li>P1
P2
P3</li></li></ul><li>This is a specific problem in the domain<br />domain<br /><ul><li>P1
P2
P3</li></li></ul><li>Goal: 	to formalize a modeling language for capturing the domain problems<br />domain<br /><ul><li>P1
P2
P3</li></li></ul><li>Metamodel<br />Goal: 	to formalize a modeling language for capturing the domain problems<br />domain<...
P2
P3</li></li></ul><li>Metamodel<br />Problem: 	the domain and the metamodel do not have the same semantics<br />domain<br /...
P2
P3</li></li></ul><li>conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />Model Transformat...
Metamodel<br />Model transformations map problems to solutions<br />domain<br /><ul><li>P1
P2
P3</li></li></ul><li>Model transformations map problems to solutions<br /><ul><li>S1</li></ul>domain<br /><ul><li>P1
S2
P2
P3</li></ul>Metamodel<br />
Metamodel evolution<br />Sometimes metamodels must be adapted, extended or amended to better capture the problems<br />
Metamodel evolution<br />Sometimes metamodels must be adapted, extended or amended to better capture the problems<br />
Metamodel evolution<br />Sometimes metamodels must be adapted, extended or amended to better capture the problems<br />Thi...
Metamodel<br />domain<br /><ul><li>P1
P2
P3</li></li></ul><li>Metamodel<br />domain<br /><ul><li>P1
P2
P3</li></li></ul><li>conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />Model Transformat...
conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />Model Transformations<br />to<br />fro...
Model Transformations<br />conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />fro...
Model Transformations<br />conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />fro...
Model Transformations<br />conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />to<br />fro...
Metamodel changes<br /><ul><li>A metamodel can undergo a number of different kinds of modifications which are classified i...
Metamodel changes classification<br />
Sample Petri Net metamodel changes<br />
Sample Petri Net metamodel changes<br />Breaking and resolvable changes<br />(extract meta-class)<br />
Sample Petri Net metamodel changes<br />Breaking and resolvable changes<br />(extract meta-class)<br />t1<br />pt1<br />tp...
Sample Petri Net metamodel changes<br />Breaking and unresolvablechange<br />(Addobligatorymetaproperty)<br />
Sample Petri Net metamodel changes<br />weight=?<br />weight=?<br />pt1<br />tp1<br />pt1<br />tp1<br />p1<br />p2<br />p1...
Model difference representation<br />[TOOLS EUROPE 2007]<br />([Vallecillo et al 2008])<br />
Metamodel difference representation<br />Since a meta-model is a model itself, metamodel differences can be represented by...
Sample metamodel difference representation<br />
Transformational adaptation of models<br />Δ consist of an arbitrary combination of the atomic changes<br />In order to di...
Transformationaladaptationofmodels: example<br />Δ(0,1)<br />
Transformationaladaptationofmodels: example<br />Restrictmetapropertychange<br />Extractmetaclasschanges<br />Δ(0,1)<br />
Transformationaladaptationofmodels: example<br />moduleH_R;<br />createOUT : ATL from Delta : KM3Diff;<br />ruleCreateRena...
Transformationaladaptationofmodels: example<br />moduleH_R;<br />createOUT : ATL from Delta : KM3Diff;<br />ruleCreateRena...
Transformationaladaptationofmodels: example<br />t1<br />pt1<br />tp1<br />CTR<br />p1<br />p2<br />p1<br />p2<br />pt2<br...
Transformationaladaptationofmodels: example<br />module H_NR;<br />createOUT : ATL from Delta : KM3Diff;<br />rule CreateR...
Transformationaladaptationofmodels: example<br />module H_NR;<br />createOUT : ATL from Delta : KM3Diff;<br />rule CreateR...
Parallel dependent modifications<br />The automatic co-adaptation of models relies on the parallel independence of breakin...
Parallel dependent modifications<br />The automatic co-adaptation of models relies on the parallel independence of breakin...
Parallel dependent modifications<br />
Parallel dependent modifications<br />The differences between MM2 and MM0 are not parallel independent (although the sub s...
Resolving dependences<br />We analyzed the kind of interdependencies among breaking resolvable and breaking unresolvable c...
Resolving dependences<br />Sufficient criteria have been given to establish the correct scheduling of the conflicting chan...
Resolving dependences<br />An alternative approach ([1]) is based on a lazy evaluation mechanism which queues up adaptatio...
Approach<br />This is a general approach which can be applied to any metamodel (so far it works for KM3 metamodels, Ecore ...
Summary<br />Introduction<br />Evolution in the Large: Metamodel Evolution (XLE)<br />Problem-based adaptation<br />Soluti...
Solution-based adaptation<br />The chosen generic modeling platform – intended as a set of languages, systems, and transfo...
beContent<br />beContent is an model-driven platform for designing and maintaining web applications<br />A beContent model...
beContent<br />ECLIPSE GMF<br />AMMA TCS<br />beContentMetamodel<br />ECLIPSE Ecore<br />ACCELEO<br />AMMA ATL<br />ACCELE...
beContent architecture<br />BML<br />BTL<br />round-tripping<br />ECLIPSE GMF<br />AMMA TCS<br />ECLIPSE GMF<br />AMMA TCS...
BML – beContent Modeling Language<br />[demo at ICWE 2009]<br />
BMM – beContentMetamodel<br />
BMM – beContentMetamodel<br />
BMM – beContentMetamodel<br />. . .<br />Metamodel fragment<br />Model fragment<br />
Problem: a simple text generation<br />Generate a text file containing source code based on information which is retrieved...
Problem: a simple text generation<br />. . .<br />...<br />
Problem: a simple text generation<br />Generate a text file containing source code based on information which is retrieved...
Refactoring the metamodel<br />MM v1.0<br />MM v2.0<br />
Problem: a simple text generation<br />In this scenario, a simple change of the metamodel from v1.0 to v2.0 is already pre...
Hiding the metamodel refactoring<br />Δ<br />Metamodel  v1.0<br />Metamodel  v2.0<br />conformsTo<br />conformsTo<br />ada...
Evolution in the large – open questions<br />Automating the co-adaptation of models is only one aspect of the evolution of...
Summary<br />Introduction<br />Evolution in the Large: Metamodel Evolution (XLE)<br />Problem-based adaptation<br />Soluti...
Evolution in the small<br />Manual modifications<br />Model (v1.0)<br />Model (v2.0)<br />T<br />T<br />System”<br />Syste...
Evolution in the small<br />Regenerating the whole system may require lots of time which reduce the usability for the desi...
Upcoming SlideShare
Loading in …5
×

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

1,757 views

Published on

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

This talk analyzes the different kinds of co-adaptations which are required, distinguishing among co-evolution in the large and in the small. In particular, the coupling between models and metamodels implies that when a metamodel undergoes a modification, the conforming models require to be accordingly co-adapted. Analogously, whenever a new version of a model is produced, the generated application may require an explicit adaptation of the generated artifacts, especially when specific
assets are not directly reflected by the models and transformations, as for instance when dealing with serialized objects or with page content which is persistently stored in a database.

Published in: Technology
  • Be the first to comment

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

  1. 1. Evolution in the Large and in the Small in Model-Driven Development <br />
  2. 2. 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 resilientto 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 />
  3. 3. 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 />
  4. 4. 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 />
  5. 5. 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 sparseNote: problems with profiles in different versions of UML<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 />
  6. 6. 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 />
  7. 7. 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 />
  8. 8. Evolution<br />I would like to discuss the problem of the evolution in model-driven development<br />
  9. 9. Evolution<br />I would like to discuss the problem of the evolution in model-drivendevelopment<br />
  10. 10. Evolution<br />I would like to discuss the problem of the evolution in model-drivendevelopment engineering<br />
  11. 11.
  12. 12. MDD<br />
  13. 13. MDD<br />MDE<br />MDE<br /> MDD<br />
  14. 14. MDD<br />MDE<br />MDE<br /> MDD<br />We have not yet seen the full application deployment of MDE!<br />[J. Bezivin keynote at SLE 2009]<br />
  15. 15. Evolution<br />I would like to discuss the problem of the evolution in model-drivendevelopment 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 />
  16. 16. 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 />
  17. 17. 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 />
  18. 18. M3<br />The “language” oflanguages,<br />eg. Ecore<br />Meta Metamodel<br />The modelinglanguage, typicallyusedtoengineerthe application domain,<br />eg. UWE, WebML, beContent<br />M2<br />Meta modeling architecture<br />Metamodels<br />M1<br />Instancemodelswhichrepresentproblems and solutions in the application domain<br />Models<br />Tools<br />(VisualEditors)<br />Tools<br />(VisualEditors)<br />Tools<br />(VisualEditors)<br />Systems and applicationsrealizing the solutionin the application domain,<br />eg. portals, data-intensive web apps, etc<br />M0<br />Tools<br />(VisualEditors)<br />Tools<br />(VisualEditors)<br />Tool<br />
  19. 19. 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 />
  20. 20. This is a domain<br /><ul><li>P1
  21. 21. P2
  22. 22. P3</li></li></ul><li>Domains usually do not have crispy boundaries.<br />This is a domain<br /><ul><li>P1
  23. 23. P2
  24. 24. P3</li></li></ul><li>This is a specific problem in the domain<br />domain<br /><ul><li>P1
  25. 25. P2
  26. 26. P3</li></li></ul><li>Goal: to formalize a modeling language for capturing the domain problems<br />domain<br /><ul><li>P1
  27. 27. P2
  28. 28. P3</li></li></ul><li>Metamodel<br />Goal: to formalize a modeling language for capturing the domain problems<br />domain<br /><ul><li>P1
  29. 29. P2
  30. 30. P3</li></li></ul><li>Metamodel<br />Problem: the domain and the metamodel do not have the same semantics<br />domain<br /><ul><li>P1
  31. 31. P2
  32. 32. P3</li></li></ul><li>conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />Model Transformations<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 />
  33. 33. Metamodel<br />Model transformations map problems to solutions<br />domain<br /><ul><li>P1
  34. 34. P2
  35. 35. P3</li></li></ul><li>Model transformations map problems to solutions<br /><ul><li>S1</li></ul>domain<br /><ul><li>P1
  36. 36. S2
  37. 37. P2
  38. 38. P3</li></ul>Metamodel<br />
  39. 39. Metamodel evolution<br />Sometimes metamodels must be adapted, extended or amended to better capture the problems<br />
  40. 40. Metamodel evolution<br />Sometimes metamodels must be adapted, extended or amended to better capture the problems<br />
  41. 41. 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 refinementor enlargement<br />a more complete understanding of the domain is at hand<br />
  42. 42. Metamodel<br />domain<br /><ul><li>P1
  43. 43. P2
  44. 44. P3</li></li></ul><li>Metamodel<br />domain<br /><ul><li>P1
  45. 45. P2
  46. 46. P3</li></li></ul><li>conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />Model Transformations<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 />
  47. 47. conformsTo<br />conformsTo<br />M3<br />Meta Metamodel<br />conformsTo<br />M2<br />Model Transformations<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 />
  48. 48. 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 />
  49. 49. 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 />
  50. 50. 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 />
  51. 51. Metamodel changes<br /><ul><li>A metamodel can undergo a number of different kinds of modifications which are classified in </li></ul>Non-breaking<br />Breaking <br /><ul><li>The breaking modifications can be divided into</li></ul>Breakingandresolvable: existing instances need to be co-adapted to conform to the new metamodel version. The co-evolution can be automatically operated<br />Breakingandunresolvable: 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 />
  52. 52. Metamodel changes classification<br />
  53. 53. Sample Petri Net metamodel changes<br />
  54. 54. Sample Petri Net metamodel changes<br />Breaking and resolvable changes<br />(extract meta-class)<br />
  55. 55. 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 />
  56. 56. Sample Petri Net metamodel changes<br />Breaking and unresolvablechange<br />(Addobligatorymetaproperty)<br />
  57. 57. 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 />
  58. 58. Model difference representation<br />[TOOLS EUROPE 2007]<br />([Vallecillo et al 2008])<br />
  59. 59. Metamodel difference representation<br />Since a meta-model is a model itself, metamodel differences can be represented by exploiting the previously mentioned approach<br />
  60. 60. Sample metamodel difference representation<br />
  61. 61. 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 />[EDOC 2008]<br />
  62. 62. Transformationaladaptationofmodels: example<br />Δ(0,1)<br />
  63. 63. Transformationaladaptationofmodels: example<br />Restrictmetapropertychange<br />Extractmetaclasschanges<br />Δ(0,1)<br />
  64. 64. 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 />
  65. 65. 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 />
  66. 66. Transformationaladaptationofmodels: example<br />t1<br />pt1<br />tp1<br />CTR<br />p1<br />p2<br />p1<br />p2<br />pt2<br />tp2<br />t2<br />
  67. 67. 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 />
  68. 68. 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 &lt; 1) then<br />thisModule.createPlace(self) -&gt;asSequence() -&gt;union(self.createPlaceInstances())<br />else<br />Sequence{}<br />endif;<br />…<br />CT¬R<br />
  69. 69. 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 />
  70. 70. 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 />
  71. 71. Parallel dependent modifications<br />
  72. 72. 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 Arcmetaclass of MM2)<br />
  73. 73. 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 />
  74. 74. Resolving dependences<br />Sufficient criteria have been given to establish the correct scheduling of the conflicting changes<br />
  75. 75. 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 />
  76. 76. 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 />
  77. 77. 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 />
  78. 78. 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 />
  79. 79. 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 />
  80. 80. beContent<br />ECLIPSE GMF<br />AMMA TCS<br />beContentMetamodel<br />ECLIPSE Ecore<br />ACCELEO<br />AMMA ATL<br />ACCELEO<br />
  81. 81. 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 />
  82. 82. BML – beContent Modeling Language<br />[demo at ICWE 2009]<br />
  83. 83. BMM – beContentMetamodel<br />
  84. 84. BMM – beContentMetamodel<br />
  85. 85. BMM – beContentMetamodel<br />. . .<br />Metamodel fragment<br />Model fragment<br />
  86. 86. 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 />
  87. 87. Problem: a simple text generation<br />. . .<br />...<br />
  88. 88. 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 />
  89. 89. Refactoring the metamodel<br />MM v1.0<br />MM v2.0<br />
  90. 90. 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 />
  91. 91. 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 />
  92. 92. 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 />
  93. 93. 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 />
  94. 94. Evolution in the small<br />Manual modifications<br />Model (v1.0)<br />Model (v2.0)<br />T<br />T<br />System”<br />System’<br />
  95. 95. 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 />
  96. 96. Evolution in the small<br />Δ<br />M1<br />M2<br />T<br />T<br />System2<br />System1<br />
  97. 97. 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 />
  98. 98. 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 />
  99. 99. 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 />
  100. 100. Evolution in the small: beContent example<br />Manual modifications<br />Simple data refactoring<br />birthday is deleted<br />a new reference is added<br />
  101. 101. Evolution in the small: beContent example<br />Δ<br />
  102. 102. 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 />
  103. 103. Evolution in the small: beContent example<br />ALTER TABLE Person ADD (zodiac INT UNSIGNED NOT NULL);<br />ALTER TABLE PersonDROP COLUMN birthday;<br />
  104. 104. 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 />
  105. 105. 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 />
  106. 106. Thank you!<br />
  107. 107. Some References<br />A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, AutomatingCo-evolution in Model-DrivenEngineering. Procs. EDOC 2008, Munich, Germany<br />A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, Meta-modelDifferencesforSupportingModelCo-evolution. Procs. MoDSE 2008, Atene, Greece<br />A. Cicchetti, D. Di Ruscio, A. Pierantonio, A MetamodelIndependentApproachtoDifferenceRepresentation, Procs. TOOLS EUROPE 2007, Zurich, Switzerland<br />A. Cicchetti, D. Di Ruscio, and A. Pierantonio. Managingdependentchanges in coupledevolution, toappear in Procs. ICMT 2009, Zurich, Switzerland<br />D.S.Kolovos, D. Di Ruscio, R.F. Paige, A. Pierantonio. DifferentModelsforModelMatching: An analysisofapproachestosupportmodeldifferencing, Procs. CVSM&apos;09, Vancouver, Canada <br />

×