Evolutionary Togetherness: How to Manage Coupled Evolution in Metamodeling Ecosystems

  • 332 views
Uploaded on

Keynote at Intl. Conf Graph Transformation - 24-29 Sept 2012 - Bremen (Germany)

Keynote at Intl. Conf Graph Transformation - 24-29 Sept 2012 - Bremen (Germany)

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
332
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Alfonso PierantonioDISIM – Università degli Studi dellAquila, Italyalfonso.pierantonio@univaq.it
  • 2. 2Model-Driven EngineeringMetamodeling EcosystemsHow/why a metamodel changes?Coupled EvolutionEcosystem Specification→ Relation and DependenciesMigrating Artifacts→ Terms and Concepts→ Current Approaches→ A Babel of Tools and TechniquesEMF MigrateConclusions ICGT 2012 – Bremen, 27 Sept 2012
  • 3. 3 MDE → Model-Driven Engineering (MDE) holds promise for greater abstraction in software development → Programs are designed with the help of models bound to the application domain rather than to the underlying technical assets → Problems, solutions, and the mappings among them are described by means of modeling languages in the corresponding domainsAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 4. 4 MDE Models are not considered as merely documentation but precise artifacts to be automatically processed abstraction Domain-specific modeling languages •P problem domain <- Model Transformations are models as well •S General-purpose solution domain modeling languages, eg. UMLAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 5. 5 Metamodels → DSMLs are analogous to software frameworks and as such are intrinsically bound to the domainAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 6. 6 This is a domain • P1 • P2 • P3Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 7. 7 Domains do not have crispy Domains do not usually have crispy boundaries. boundaries This is a domain • P1 • P2 • P3Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 8. 8 This is a specific problem in the domaindomain • P1 • P2 • P3Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 9. 9 Metamodels are used for capturing problems in the domaindomain • P1 • P2 • P3Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 10. 10 Misalignmentdomain • P1 • P2 • P3Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 11. 11 Metamodels → In Model-Driven Engineering metamodels are cornerstones for defining a wide range of related artifactsAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 12. 12 Metamodels → In Model-Driven Engineering metamodels are cornerstones for defining a wide range of related artifacts MetamodelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 13. 13 Metamodels → In Model-Driven Engineering metamodels are cornerstones for defining a wide range of related artifacts → Models, transformations, editors, and many more can be regarded as a whole pursuing a common scope and therefore we like to call it Metamodeling EcosystemAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 14. 14 WOODLAND ECOSYSTEM Great Horned Hawk Owl Skunk Sparrow Rabbit Shrew Field Mouse Grasshopper Grass Blueberry BushAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 15. 15 Metamodeling Ecosystem → All the components in a metamodeling ecosystem are coupled together by means of (implicit or explicit) correspondences → Sometimes this correspondences are tight and formal, other times they are looser or to be better investigated ─ eg, the conformance between metamodels and models is a very precise typing relationAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 16. 16 Petri Net MetamodelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 17. 17 Conformance Petri Net Metamodel A Petri Net ModelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 18. 18 GMF Editors Petri Net Metamodel GMF Editor A Petri Net ModelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 19. Transformation 19 Petri Net Metamodel GMF Editor Transformations A Petri Net ModelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 20. Transformation 20 Petri Net Metamodel GMF Editor Code Generators A Petri Net ModelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 21. Transformation 21 Petri Net Metamodel GMF Editor A Petri Net ModelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 22. 22 WOODLAND ECOSYSTEM Great Horned Hawk Owl Skunk Sparrow Rabbit Shrew Field Mouse Grasshopper Grass Blueberry BushAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 23. 23 ENDANGERED Evolving WOODLAND ECOSYSTEM Great Horned Hawk Owl Skunk Sparrow Rabbit Shrew Field Mouse Grasshopper Grass Blueberry BushAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 24. 24 Problem: what happens when the metamodel in the ecosystem changes?Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 25. 25 How a metamodel changes? General-purpose modeling languages tend to change is a sparse way UML 0.8 UML 1.1 UML 1.4 UML 2.0 UML 2.2 UML 0.9 UML 1.3 UML 1.5 UML 2.1.2 1995 1997 2000 2003 2005 2007 Domain-specific modeling languages are as prone to evolution as software frameworks DSMLAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 26. 26 How a metamodel changes? While both GPMLs and DSMLs are subject to evolution, the way they are used can vary → GPMLs are managed by third parties which are in charge of their evolution → DSMLs are typically in-house instruments managed by the organizations which are using them, ie. metamodeling and DSML design must be part of the company expertiseAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 27. 27 Why a metamodel changes? The reason a DSML undergoes modification can be the most disparate → A DSML definition is subject to different iterations before it converges to a stable version → A DSML is a living entity, it may be amended or extended in order to accommodate new requirements and / or insights emerging from the domain ─ eg. technological shifts over the reference platformAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 28. 28domain • P1 • P2 • P3Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 29. 29domain • P1 • P2 • P3Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 30. Transformation 30 The Model P1 needs to be adapted to conform the new metamodel versiondomain •• P11 P • P2 • P3Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 31. 31A SIMPLE METAMODEL EVOLUTION ICGT 2012 – Bremen, 27 Sept 2012
  • 32. 32 A simple metamodel evolution Petri Nets revised Let us consider a simple refactoring of the previous Petri Net metamodel ─ A metaclass renaming ─ Reference merge ─ New Metaclasses addedAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 33. 33 Petri Nets revisedInitial Version Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 34. 34 Petri Nets revisedInitial Version Final Version Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 35. 35 Petri Nets revised Reference mergeInitial Version Metaclass renaming New Metaclasses Final Version Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 36. 36 Petri Nets revised Reference mergeInitial Version Metaclass renaming New Metaclasses Final Version Despite the simplicity, such changes are enough for invalidating most of artifacts in the ecosystem Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 37. Transformation 37 Petri Net Metamodel GMF Editor A Petri Net ModelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 38. 38 Metamodel/Model co-evolutionAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 39. 39 Metamodel/Model co-evolution → This model is not conforming to the newer version of the Petri Net Metamodel → An adaptation is necessaryAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 40. 40 Metamodel/Model co-evolutionAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 41. 41 Metamodel changes The changes can be classified according to their effect on the models → non-breaking changes do not break the conformance → breaking and resolvable changes break the conformance of models, although they can be automatically co-adapted → breaking and unresolvable changes break the conformance which can not be automatically restoredAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 42. 42 Manual adaptations Modelers can adapt the models by inspecting them, detecting the necessary changes and finally applying them by manual operations Manually restoring the conformance is tedious and error-prone: it can easily lead to information erosion in the adapted artifacts. G. Wachsmuth. Metamodel Adaptation and Model Co- adaptation. In E. Ernst, editor, Procs. 21st ECOOP, LNCS 4069, Springer-Verlag, July 2007.Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 43. 43 Manual adaptations Metamodel → Any artifact in the ecosystem requires to be consistently adaptedAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 44. 44 Pragmatics This represents a severe pragmatic issue for the adoption of the Model-Driven Engineering The intrinsic difficulties in adapting the artifacts makes the metamodel resilient to changes and the ecosystem locked in the current metamodel version Therefore the adoption of MDE comes with the urgent need of finding solutions for supporting the evolutionary nature of the ecosystemAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 45. 45 Problem: how we can equip the ecosystem with the right infrastructure to deal with the co-evolution of any artifact ?Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 46. 46 Problem: how we can equip the ecosystem with the right infrastructure to deal with the co-evolution of any artifact ? consistentAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 47. 47 Coupled evolution tasks Relations definition: a set of relations between the metamodel and the other modeling artifacts are identified Change impact detection: the relationships defined in the previous step are considered in order to assess the impact of the changes made in the metamodel on the related artifacts Adaptation: the developer apply some adaptation actions on the (possibly corrupted) artifacts. This step can imply the use of very different adaptation policies, depending on the types of artifacts to be adaptedAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 48. 48 Coupled evolution tasks Relations definition: a set of relations between the metamodel and the other modeling artifacts are identified Change impact detection: the relationships defined in the previous step are considered in order to assess the impact of the changes made in the metamodel on the related artifacts Adaptation: the developer apply some adaptation actions on the (possibly corrupted) artifacts. This step can imply the use of very different adaptation policies, depending on the types of artifacts to be adaptedAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 49. 49 Ecosystem Specification MetamodelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 50. 50 Ecosystem Specification A metamodeling ecosystem can be formalized by means of a megamodel Jean Bézivin, Frédéric Jouault, and Patrick Valduriez. On the Need for Megamodels. In Procs. OOPSLA/GPCE: Best Practices for Model-Driven Software Development Workshop, 2004.Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 51. 51 Ecosystem Specification A metamodeling ecosystem can be formalized by means of a megamodel EHY THIS IS NOT A TYPO, OK? Jean Bézivin, Frédéric Jouault, and Patrick Valduriez. On the Need for Megamodels. In Procs. OOPSLA/GPCE: Best Practices for Model-Driven Software Development Workshop, 2004.Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 52. 52 Ecosystem Specification A metamodeling ecosystem can be formalized by means of a megamodel A megamodel is a model of which at least some elements represent and/or refer to models or metamodels Jean Bézivin, Frédéric Jouault, and Patrick Valduriez. On the Need for Megamodels. In Procs. OOPSLA/GPCE: Best Practices for Model-Driven Software Development Workshop, 2004.Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 53. 53 Ecosystems formalized by MegamodelsAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 54. 54 Ecosystems formalized by Megamodels Coupled Evolution TasksAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 55. 55 Relations and DependenciesAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 56. 56 ConformsTo relation Conformance is present in most of technical spacesAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 57. 57 ConformsTo Relation – as a weavingAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 58. 58 Transformations They map models conforming to a source metamodel to models conforming to a target metamodel The transformation is said to be domain conformant to the source metamodel Usually the source metamodel corresponds to the main metamodel of the ecosystem, but the same holds for the target metamodelAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 59. 59 Domain ConformanceAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 60. 60 Simple ATL transformation create OUT : PNML from IN : PetriNetMM0; … rule Net { from s: PetriNetMM0!Net to t : PNML!NetElement ( name <- name, …), … } rule Place { from s : PetriNetMM0!Place to t : PNML!Place ( name <- name, …), … } rule Transitions { from s : PetriNetMM0!Transition to t : PNML!Transition ( name <- name, …), … }Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 61. 61Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 62. 62 Metamodel changes Similarly to the conformance, change effects over the transformation can be classified as follows → fully automated: transformations can be automatically adapted without user intervention → partially automated: transformations can be semi- automatically adapted and some manual fine-tuning is required to complete the adaptation → fully semantic: transformations cannot be automatically migrated and the user has to completely define the adaptationAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 63. 63MIGRATING ARTIFACTS ICGT 2012 – Bremen, 27 Sept 2012
  • 64. 64 Coupled evolution tasks Relations definition: a set of relations between the metamodel and the other modeling artifacts are identified Change impact detection: the relationships defined in the previous step are considered in order to assess the impact of the changes made in the metamodel on the related artifacts Adaptation: the developer apply some adaptation actions on the (possibly corrupted) artifacts. This step can imply the use of very different adaptation policies, depending on the types of artifacts to be adaptedAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 65. 65Concept Description How metamodel changes are detected: state-based and operation-Differencing based approachesAdaptation The adaptation can be done in parallel with the metamodel changesScheduling (interleaved) or as a whole (batch) The migration programs can be generated from the metamodelOrder changes (higher-order) or programmatically (single-order)Focus The artifacts to be adapted (e.g., models, or transformations) Metamodel changes are corrupting or not-corrupting on the existingLack of artifacts. In the former case, the induced lack of information isinformation managed by asking users or by using heuristicsModularity/ Modularity mechanisms are required in order to organize recurrentReuse migrations in reusable modulesRefinement Refinement mechanisms are required to customized migrationsModel Mechanisms for querying and navigating the artifacts to be adaptednavigation (e.g., OCL)Uncertainty The way the artifacts can be adapted is not univocal ICGT 2012 – Bremen, 27 Sept 2012
  • 66. 66Concept Description How metamodel changes are detected: state-based and operation-Differencing based approachesAdaptation The adaptation can be done in parallel with the metamodel changesScheduling (interleaved) or as a whole (batch) The migration programs can be generated from the metamodelOrder changes (higher-order) or programmatically (single-order)FocusFocus The artifacts to be adapted (e.g., models, or transformations) artifacts to be adapted (e.g., models, or transformations) Metamodel changes are corrupting or not-corrupting on the existingLack of artifacts. In the former case, the induced lack of information isinformation managed by asking users or by using heuristicsModularity/ Modularity mechanisms are required in order to organize recurrentReuse migrations in reusable modulesRefinement Refinement mechanisms are required to customized migrationsModel Mechanisms for querying and navigating the artifacts to be adaptednavigation (e.g., OCL)Uncertainty The way the artifacts can be adapted is not univocal ICGT 2012 – Bremen, 27 Sept 2012
  • 67. Levendovszky GMFEvolution EMFMigrate 67 CURRENTCOPE [2] Flock [4] APPROACHES [3] [1] [5] operation- operation- operation-Differencing state-based state-based based based basedAdaptation interleaved batch batch batch batchSchedulingOrder single-order single-order higher-order single-order single-orderFocus Model Model Transformation Editor anyParadigm imperative imperative declarative declarative declarative heuristicsLack of heuristics user specified user specified user specified based/ userinformation based specifiedModularity/R No No No No YeseuseRefinement No No No No YesModel Groovy based OCL based MCL based OCL based OCL basednavigationDedicated Yes Yes Yes No YesenvironmentReference EMF EMF GME/GReAT EMF EMFplatformUncertainty No No No No 2012 – Bremen, 27 Sept 2012 ICGT No
  • 68. 68 A Babel of Tools and Techniques Too many different techniques, difficulties in having a consistent and coherent adaptation of the ecosystem Metamodel Täntzer et al O. Diaz GMF COPE Flock (ICGT’12) Levendovszky (SLE’12) EvolutionFocus Model Model Model Transformation Transformation Editor Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 69. 69 EMF Migrate It is a declarative DSL devoted to the co-evolution management of any artifact in the ecosystem, it permits → to specify reusable default libraries, each devoted to the adaptation of a specific kind of artifact ─ the adaptations must be kept consistent → to customize migrations already available in libraries → to manage those migrations which are not fully automated and that require user intervention to address ad-hoc needs It is agnostic of the differencing techniqueAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 70. 70 EMF Migrate ArchitectureAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 71. 71 EMF Migrate → An EMF Migrate specification is given as follows:Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 72. 72 EMF Migrate → An EMFMigrate specification is given as follows: Migrate artifact A conforming to metamodel MMAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 73. 73 EMF Migrate → An EMFMigrate specification is given as follows: According to the metamodel differences in the model DeltaAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 74. 74 EMF Migrate → An EMFMigrate specification is given as follows:The migration is specified in terms of migration rules mriAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 75. 75 EMF Migrate → An EMFMigrate specification is given as follows:Each rule is applied on the artefact A if the correspondingguardi evaluated on the difference model Delta holdsAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 76. 76 EMF Migrate → An EMFMigrate specification is given as follows:The body of a migration rule consists of a sequence of rewriting rules Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 77. 77 EMF Migrate A rewriting rule can be specified as followswhere s, t1, …, tn refer to metaclasses in MM guard is a filter over the artifact which triggers the rewrite of s with t1, t2, and tnAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 78. 78 EMFMigrate > sample migration programAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 79. 79 EMFMigrate > sample migration program Metamodel change pattern written in Edelta - textual DSL for metamodel difference specifications - embedded in EMFMigrateAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 80. 80 EMFMigrate > sample migration programAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 81. 81 EMFMigrate > sample migration program ATL Metamodel change pattern written in EMFMigrate - Metamodel-independent Query Language - ATL is imported as a parameterAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 82. 82 EMFMigrate > sample migration programAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 83. 83 EMFMigrate > sample migration programAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 84. 84 Sample ATL transformationAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 85. 85 EMFMigrate > sample migration libraryAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 86. 86 EMFMigrate > sample migration libraryAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 87. 87 The migrated transformation Rule MergeReferencesAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 88. → The dynamic semantics of EMF Migrate is given by the 88 semantic anchoring to the EMFTVM bytecode metamodel ─ Mapping of EMF Migrate constructs to EMFTVM constructs adapted artifact artifact ICGT 2012 – Bremen, 27 Sept 2012
  • 89. 89 Conclusions The evolution of metamodeling ecosystems comes with some pragmatic issues whose solution is key to MDE success ?Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 90. 90 Conclusions In software engineering design for reuse is a commonplace, analogously in MDE we need something like metamodeling for co-evolution In other words, we need to think ahead before unforeseen insights or requirements emerge from the domain Neglecting this will not only freeze specific metamodels and consequently the related ecosystemsAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 91. 91 Conclusions Metamodels are related to all the components in the ecosystem and their evolution must be consistently managed Evolutionary togethernessAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 92. 92 Only a portion of the MDE potential has been deployedAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 93. 93 Only a portion of the MDE potential has been deployedAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 94. 94 Only a portion of the MDE potential has been deployed – few pragmatic issues are reducing its effectivenessAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 95. 95 References [1] D. Di Ruscio, R. Laemmel, and A. Pierantonio.. Procs. 3rd International Conference on Software Language Engineering Automated coevolution of GMF editor models (SLE 2010), number 6563 in LNCS, pp. 143–162. Springer, Heidelberg, October 2010 [2] M. Herrmannsdoerfer, S. Benz, and E. Juergens. Cope – automating coupled evolution of metamodels and models. Procs. ECOOP 2009 Object-Oriented Programming, number 5653 of LNCS, pp. 52–76, Springer Berlin / Heidelberg, 2009 [3] T. Levendovszky, D. Balasubramanian, A. Narayanan, and G. Karsai. A novel approach to semi- automated evolution of DSML model transformation. Procs. Second International Conference on Software Language Engineering, SLE 2009, LNCS, volume 5969, Springer, 2010 [4] Louis M. Rose, Dimitrios S. Kolovos, Richard F. Paige, and Fiona A. C. Polack. Model migration with Epsilon Flock. Procs. 3rd international conference on Theory and practice of model transformations (ICMT10), pages 184–198, Springer-Verlag Berlin, Heidelberg, 2010 [5] D. Wagelaar, L. Iovino, D. Di Ruscio, and A. Pierantonio. Translational semantics of a co-evolution specific language with the EMF transformation virtual machine. Procs. 5th International Conference on Model Transformation (ICMT’12), Springer-Verlag Berlin, Heidelberg, 2012 [6] D. Di Ruscio, L. Iovino and A. Pierantonio, Evolutionary togetherness: how to manage coupled evolution in metamodeling ecosystems, in: Intl. Conf. on Graph Transformations (ICGT 2012), Springer, 2012 [7] D. Di Ruscio, L. Iovino and A. Pierantonio, Coupled Evolution in Model-Driven Engineering, in: IEEE Software, Nov/Dec 2012, IEEE Computer Society, to appearAlfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012
  • 96. 96Questions? Università degli Studi dell’Aquila ICGT 2012 – Bremen, 27 Sept 2012