• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Evolution in the Large and in the Small in Model-Driven Development
 

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

on

  • 2,189 views

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

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.

Statistics

Views

Total Views
2,189
Views on SlideShare
2,022
Embed Views
167

Actions

Likes
1
Downloads
55
Comments
0

4 Embeds 167

http://l.lj-toys.com 116
http://lj-toys.com 41
http://www.di.univaq.it 5
http://www.slideshare.net 5

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Evolution in the Large and in the Small in Model-Driven Development
    • Introduction
      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
      Coordinated collections of models and modeling languages are used to describe web applications on different abstraction levels and from different perspectives
      Models and metamodels are not preserved from the evolutionary pressure which inevitably affects almost any artifacts, possibly causing a cascade of adaptations
    • Modeling languages
      Modeling languages can be used to specify problems, solutions and the mapping among them in the corresponding domains
      abstraction
      Domain-specific modeling languages
      • P
      problem domain
      • S
      General-purpose modeling languages,
      eg. UML
      solution domain
    • Evolution
      Any modeling language can be subject to different evolutionary pressures
      The evolution of general-purpose modeling languages (GPMLs) is comparable to that of general-purpose languages and tend to be monotone and sparse
    • Evolution
      Any modeling language can be subject to different evolutionary pressures
      The evolution of general-purpose modeling languages (GPMLs) is comparable to that of general-purpose languages and tend to be monotone and sparseNote: problems with profiles in different versions of UML
      UM 0.8
      UML 1.1
      UML 1.4
      UML 2.0
      UML 2.2
      UML 0.9
      UML 1.3
      UML 1.5
      UML 2.1.2
      1995
      1997
      2005
      2000
      2003
      2007
    • Evolution
      The evolution of domain-specific modeling languages (DSMLs) is more rapid and elaborated as they tend to have a living corpus comparable to that of software
      Moreover, they require specific support tools which have to be adapted according to the metamodel evolution
    • Evolution
      The evolution of domain-specific modeling languages (DSMLs) is more rapid and elaborated as they tend to have a living corpus comparable to that of software
      Moreover, they require specific support tools which have to be adapted according to the metamodel evolution
    • Evolution
      I would like to discuss the problem of the evolution in model-driven development
    • Evolution
      I would like to discuss the problem of the evolution in model-drivendevelopment
    • Evolution
      I would like to discuss the problem of the evolution in model-drivendevelopment engineering
    • MDD
    • MDD
      MDE
      MDE
      MDD
    • MDD
      MDE
      MDE
      MDD
      We have not yet seen the full application deployment of MDE!
      [J. Bezivin keynote at SLE 2009]
    • Evolution
      I would like to discuss the problem of the evolution in model-drivendevelopment engineering
      This talk analyzes the different kinds of co-adaptations distinguishing among co-evolution in the large and in the small
      when a metamodel undergoes a modification, the conforming models require to be accordingly co-adapted
      when a new version of a model is produced, the application may require an explicit adaptation of those assets which are not directly reflected by the models and transformations
    • Summary
      Introduction
      Evolution in the Large: Metamodel Evolution (XLE)
      Problem-based adaptation
      Solution-based adaptation
      Metamodel change classification
      Transformationaladaptationofmodels
      Evolution in the Small: Application Model Evolution (XSE)
      Data migration
      Adaptation of specific assets
      Conclusions and future work
    • Summary
      Introduction
      Evolution in the Large: Metamodel Evolution (XLE)
      Problem-based adaptation
      Solution-based adaptation
      Metamodel change classification
      Transformationaladaptationofmodels
      Evolution in the Small: Application Model Evolution (XSE)
      Data migration
      Adaptation of specific assets
      Conclusions and future work
    • M3
      The “language” oflanguages,
      eg. Ecore
      Meta Metamodel
      The modelinglanguage, typicallyusedtoengineerthe application domain,
      eg. UWE, WebML, beContent
      M2
      Meta modeling architecture
      Metamodels
      M1
      Instancemodelswhichrepresentproblems and solutions in the application domain
      Models
      Tools
      (VisualEditors)
      Tools
      (VisualEditors)
      Tools
      (VisualEditors)
      Systems and applicationsrealizing the solutionin the application domain,
      eg. portals, data-intensive web apps, etc
      M0
      Tools
      (VisualEditors)
      Tools
      (VisualEditors)
      Tool
    • M3
      M2
      M1
      M0
      Metamodel based tools
      conformsTo
      Meta Metamodel
      Metamodel
      conformsTo
      Model
      basedOn
      edits
      implementedFor
      Tool
    • This is a domain
      • P1
      • P2
      • P3
    • Domains usually do not have crispy boundaries.
      This is a domain
      • P1
      • P2
      • P3
    • This is a specific problem in the domain
      domain
      • P1
      • P2
      • P3
    • Goal: to formalize a modeling language for capturing the domain problems
      domain
      • P1
      • P2
      • P3
    • Metamodel
      Goal: to formalize a modeling language for capturing the domain problems
      domain
      • P1
      • P2
      • P3
    • Metamodel
      Problem: the domain and the metamodel do not have the same semantics
      domain
      • P1
      • P2
      • P3
    • conformsTo
      conformsTo
      M3
      Meta Metamodel
      conformsTo
      M2
      Model Transformations
      to
      from
      Target Metamodel
      Source Metamodel
      TransformationLanguage
      conformsTo
      conformsTo
      conformsTo
      M1
      Target Model
      Source Model
      TransformationRules
      source
      target
      exec
      TransformationEngine
      M0
    • Metamodel
      Model transformations map problems to solutions
      domain
      • P1
      • P2
      • P3
    • Model transformations map problems to solutions
      • S1
      domain
      • P1
      • S2
      • P2
      • P3
      Metamodel
    • Metamodel evolution
      Sometimes metamodels must be adapted, extended or amended to better capture the problems
    • Metamodel evolution
      Sometimes metamodels must be adapted, extended or amended to better capture the problems
    • Metamodel evolution
      Sometimes metamodels must be adapted, extended or amended to better capture the problems
      This may happen because
      the domains are often only partially analyzed and several instances may be left out
      new requirements must be considered which will result in a domain refinementor enlargement
      a more complete understanding of the domain is at hand
    • Metamodel
      domain
      • P1
      • P2
      • P3
    • Metamodel
      domain
      • P1
      • P2
      • P3
    • conformsTo
      conformsTo
      M3
      Meta Metamodel
      conformsTo
      M2
      Model Transformations
      to
      from
      Target Metamodel
      Source Metamodel
      TransformationLanguage
      conformsTo
      conformsTo
      conformsTo
      M1
      Target Model
      Source Model
      TransformationRules
      source
      target
      exec
      TransformationEngine
      M0
    • conformsTo
      conformsTo
      M3
      Meta Metamodel
      conformsTo
      M2
      Model Transformations
      to
      from
      Target Metamodel
      Source Metamodel
      TransformationLanguage
      Source Metamodel
      conformsTo
      conformsTo
      conformsTo
      M1
      Target Model
      Source Model
      TransformationRules
      source
      target
      exec
      TransformationEngine
      M0
    • Model Transformations
      conformsTo
      conformsTo
      M3
      Meta Metamodel
      conformsTo
      M2
      to
      from
      Target Metamodel
      Source Metamodel
      TransformationLanguage
      Source Metamodel
      conformsTo
      conformsTo
      conformsTo
      M1
      Target Model
      Source Model
      TransformationRules
      source
      target
      exec
      TransformationEngine
      M0
    • Model Transformations
      conformsTo
      conformsTo
      M3
      Meta Metamodel
      conformsTo
      M2
      to
      from
      Target Metamodel
      Source Metamodel
      TransformationLanguage
      Source Metamodel
      conformsTo
      conformsTo
      conformsTo
      M1
      Target Model
      Source Model
      TransformationRules
      source
      target
      exec
      TransformationEngine
      M0
    • Model Transformations
      conformsTo
      conformsTo
      M3
      Meta Metamodel
      conformsTo
      M2
      to
      from
      Target Metamodel
      Source Metamodel
      TransformationLanguage
      Source Metamodel
      conformsTo
      conformsTo
      conformsTo
      M1
      Target Model
      Source Model
      TransformationRules
      source
      target
      exec
      TransformationEngine
      M0
    • Metamodel changes
      • A metamodel can undergo a number of different kinds of modifications which are classified in
      Non-breaking
      Breaking
      • The breaking modifications can be divided into
      Breakingandresolvable: existing instances need to be co-adapted to conform to the new metamodel version. The co-evolution can be automatically operated
      Breakingandunresolvable: the necessary co-adaptation of existing models can not be automatically computed due to the need of further information
      [Paige at al 2007]
    • Metamodel changes classification
    • Sample Petri Net metamodel changes
    • Sample Petri Net metamodel changes
      Breaking and resolvable changes
      (extract meta-class)
    • Sample Petri Net metamodel changes
      Breaking and resolvable changes
      (extract meta-class)
      t1
      pt1
      tp1
      p1
      p2
      p1
      p2
      pt2
      tp2
      t2
    • Sample Petri Net metamodel changes
      Breaking and unresolvablechange
      (Addobligatorymetaproperty)
    • Sample Petri Net metamodel changes
      weight=?
      weight=?
      pt1
      tp1
      pt1
      tp1
      p1
      p2
      p1
      p2
      pt2
      tp2
      pt2
      tp2
      weight=?
      weight=?
      Breaking and unresolvablechange
      (Addobligatorymetaproperty)
    • Model difference representation
      [TOOLS EUROPE 2007]
      ([Vallecillo et al 2008])
    • Metamodel difference representation
      Since a meta-model is a model itself, metamodel differences can be represented by exploiting the previously mentioned approach
    • Sample metamodel difference representation
    • Transformational adaptation of models
      Δ consist of an arbitrary combination of the atomic changes
      In order to distinguish them the following steps are performed:
      automatic decomposition of Δ in two disjoint (sub) models, ΔR and Δ¬R, which denote breaking resolvable and unresolvable changes;
      if ΔR and Δ¬R are parallel independent then we separately generate the corresponding co-evolutions;
      if ΔR and Δ¬R are parallel dependent, they are further refined to identify and isolate the interdependencies causing the interferences
      [EDOC 2008]
    • Transformationaladaptationofmodels: example
      Δ(0,1)
    • Transformationaladaptationofmodels: example
      Restrictmetapropertychange
      Extractmetaclasschanges
      Δ(0,1)
    • Transformationaladaptationofmodels: example
      moduleH_R;
      createOUT : ATL from Delta : KM3Diff;
      ruleCreateRenaming {

      }
      ruleCreateExtractMetaClass{

      }

      HR
      ΔR(0,1)
    • Transformationaladaptationofmodels: example
      moduleH_R;
      createOUT : ATL from Delta : KM3Diff;
      ruleCreateRenaming {

      }
      ruleCreateExtractMetaClass{

      }

      HR
      module CTR;
      create OUT : MM1 from IN : MM0;

      rulecreatePTArc(s : OclAny, n : OclAny) {

      }
      rulecreateTPArc(s : OclAny, n : OclAny) {

      }
      ΔR(0,1)
      CTR
    • Transformationaladaptationofmodels: example
      t1
      pt1
      tp1
      CTR
      p1
      p2
      p1
      p2
      pt2
      tp2
      t2
    • Transformationaladaptationofmodels: example
      module H_NR;
      createOUT : ATL from Delta : KM3Diff;
      rule CreateRestrictMetaproperty{ …
      }
      ruleAddObligatoryMetaclass{

      }

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

      }

      Δ¬R(0,1)
      H¬R
      module CTR;
      create OUT : MM1 from IN : MM0;
      …helper context MM2!Net def:createPlaceInstances() : Sequence (MM2!Place) =
      if (thisModule.placeInstances < 1) then
      thisModule.createPlace(self) ->asSequence() ->union(self.createPlaceInstances())
      else
      Sequence{}
      endif;

      CT¬R
    • Parallel dependent modifications
      The automatic co-adaptation of models relies on the parallel independence of breaking resolvable and unresolvable modifications, or more formally
      ΔR|Δ¬R = ΔR;Δ¬R +Δ¬R;ΔR
      where + denotes the non-deterministic choice
    • Parallel dependent modifications
      The automatic co-adaptation of models relies on the parallel independence of breaking resolvable and unresolvable modifications, or more formally
      ΔR|Δ¬R = ΔR;Δ¬R +Δ¬R;ΔR
      where + denotes the non-deterministic choice
      Bad news: the parallel independence of changes is not assured, ie. multiple changes can be interdependent one another
    • Parallel dependent modifications
    • Parallel dependent modifications
      The differences between MM2 and MM0 are not parallel independent (although the sub steps MM0−MM1 and MM1 − MM2 are directly manageable)
      The interdependenciesbetween the atomic changes in MM2 − MM0 have to be isolated (i.e. the attribute weight of the Arcmetaclass of MM2)
    • Resolving dependences
      We analyzed the kind of interdependencies among breaking resolvable and breaking unresolvable changes
      We found out that these interdependencies do not depend on the specific metamodel, rather only on the meta metamodel (eg. Ecore, MOF, KM3)
      [ICMT 2009]
    • Resolving dependences
      Sufficient criteria have been given to establish the correct scheduling of the conflicting changes
    • Resolving dependences
      An alternative approach ([1]) is based on a lazy evaluation mechanism which queues up adaptations which require unavailable information
      We have found that for KM3, Ecore, and MOF interdependencies are not circular and that they only depend on the meta metamodel
      This implies that it is possible to find the exact scheduling of the adaptation steps w/o queuing them
      [1] Narayanan, Levendovszky, Balasubramanian, Karsai: Domain ModelMigrationtoManageMetamodelEvolution, MoDELS 2009
    • Approach
      This is a general approach which can be applied to any metamodel (so far it works for KM3 metamodels, Ecore and MOF are under study), it permits
      the management of complex metamodel modifications (in contrast with current approaches)
      the complete automatic adaptation of models (breaking non resolvable via transformation refinements)
      We are currently working on the migration of UWE models
    • Summary
      Introduction
      Evolution in the Large: Metamodel Evolution (XLE)
      Problem-based adaptation
      Solution-based adaptation
      Metamodel change classification
      Transformationaladaptationofmodels
      Evolution in the Small: Application Model Evolution (XSE)
      Data migration
      Adaptation of specific assets
      Conclusions and future work
    • Solution-based adaptation
      The chosen generic modeling platform – intended as a set of languages, systems, and transformation paradigms – may affect the metamodel life-cycle
      In fact, sometimes metamodels must be changed in order to permit solutions which are otherwise not admissible
    • beContent
      beContent is an model-driven platform for designing and maintaining web applications
      A beContent model consists mainly of the declarative and coordinated specification of three different concerns:
      the data view is the description of the relational model of the data, in essence it describes the metadata of the application;
      the content view describes the data sources and how the content is retrieved and aggregated in pages; and finally
      the interaction view specifies how to manipulate the information entered in the forms, the validation constraints, and additional information which may affect the interaction between the user and the application.
    • beContent
      ECLIPSE GMF
      AMMA TCS
      beContentMetamodel
      ECLIPSE Ecore
      ACCELEO
      AMMA ATL
      ACCELEO
    • beContent architecture
      BML
      BTL
      round-tripping
      ECLIPSE GMF
      AMMA TCS
      ECLIPSE GMF
      AMMA TCS
      beContentMetamodel
      beContentMetamodel
      ECLIPSE Ecore
      ECLIPSE Ecore
      M2C
      M2M
      ACCELEO
      AMMA ATL
      ACCELEO
      AMMA ATL
      M2C
      M2C
      PHPMySQL
      ACCELEO
      ACCELEO
      ACCELEO
      J2EE/Liferay
      .NET
    • BML – beContent Modeling Language
      [demo at ICWE 2009]
    • BMM – beContentMetamodel
    • BMM – beContentMetamodel
    • BMM – beContentMetamodel
      . . .
      Metamodel fragment
      Model fragment
    • Problem: a simple text generation
      Generate a text file containing source code based on information which is retrieved from different instances of the same metaclass
    • Problem: a simple text generation
      . . .
      ...
    • Problem: a simple text generation
      Generate a text file containing source code based on information which is retrieved from different instances of the same metaclass
      This is not easy as it may appear as templating languages (in contrast with M2M languages) do not always have the querying power of OCL
      In particular, this can be achieved either using external Java helpers or changing the metamodel in such a way these instances must be within a container
    • Refactoring the metamodel
      MM v1.0
      MM v2.0
    • Problem: a simple text generation
      In this scenario, a simple change of the metamodel from v1.0 to v2.0 is already pretty troublesome as it would require
      the adaptation of the models, which can be performed automatically as shown before
      the manual adaptation of the tools
      A possible workaround …
    • Hiding the metamodel refactoring
      Δ
      Metamodel v1.0
      Metamodel v2.0
      conformsTo
      conformsTo
      adapt(Δ)
      Model (v2.0)
      Model (v1.0)
      M2T
      Source code
    • Evolution in the large – open questions
      Automating the co-adaptation of models is only one aspect of the evolution of metamodels, nevertheless it is already very complex and presents open questions
      Metamodel difference calculation: it is very difficult, none of the available approaches are really satisfactory because of domain semantics, similarity metrics, etc
      Update: we are having interesting result by combining EMF Compare and ECL for Ecoremetamodels differencing
      Overriding default adaptation with ad-hoc refactorings
      Semantics preserving ?
      Validation, everybody is very keen on keeping her/his models secret :-)
    • Summary
      Introduction
      Evolution in the Large: Metamodel Evolution (XLE)
      Problem-based adaptation
      Solution-based adaptation
      Metamodel change classification
      Transformationaladaptationofmodels
      Evolution in the Small: Application Model Evolution (XSE)
      Data migration
      Adaptation of specific assets
      Conclusions and future work
    • Evolution in the small
      Manual modifications
      Model (v1.0)
      Model (v2.0)
      T
      T
      System”
      System’
    • Evolution in the small
      Regenerating the whole system may require lots of time which reduce the usability for the designers, possibile solutions are incremental/live transformations
      Not all the aspects can be generated or derived by the models, eg. a model modification may require
      a data migration procedure
      a consistency check of the graphic templates
      Typically transformations encode knowledge about the underlying platform and architecture, eg.
      persistent classes and serialized objects in Java must be in sync
    • Evolution in the small
      Δ
      M1
      M2
      T
      T
      System2
      System1
    • Evolution in the small
      Δ
      M1
      M2
      T
      T
      System2
      System1
      uses
      uses
      data1
      data2
    • Evolution in the small
      Δ
      M1
      M2
      T
      T
      System2
      System1
      uses
      uses
      data1
      data2
      migration
      (evolutionrollbackauxfunctions)
    • Evolution in the small
      Δ
      M1
      M2
      T
      T
      System2
      System1
      T’
      uses
      uses
      data1
      data2
      migration (Δ)
    • Evolution in the small: beContent example
      Manual modifications
      Simple data refactoring
      birthday is deleted
      a new reference is added
    • Evolution in the small: beContent example
      Δ
    • Evolution in the small: beContent example
      This is a special case in beContent as the underlying framework is able to detect new tables to be created
    • Evolution in the small: beContent example
      ALTER TABLE Person ADD (zodiac INT UNSIGNED NOT NULL);
      ALTER TABLE PersonDROP COLUMN birthday;
    • Evolution in the small: beContent example
      As the difference model is a model, it is possible to generate anything based on its content
      eg. a configuration for a migration wizard to assist the designer
    • Conclusions
      Using DSML (in contrast with a GPML) has the advantage to increase the degree of automation by exploiting the metamodeling hierarchy
      The evolution of models and metamodels is almost unavoidable if they are inherently part of the process (as both main actors and instruments)
      In order to automate the coupled-evolution which takes place at different levels in the metamodeling hierarchy is necessary to have a formal representation of model differences
    • Thank you!
    • Some References
      A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, AutomatingCo-evolution in Model-DrivenEngineering. Procs. EDOC 2008, Munich, Germany
      A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, Meta-modelDifferencesforSupportingModelCo-evolution. Procs. MoDSE 2008, Atene, Greece
      A. Cicchetti, D. Di Ruscio, A. Pierantonio, A MetamodelIndependentApproachtoDifferenceRepresentation, Procs. TOOLS EUROPE 2007, Zurich, Switzerland
      A. Cicchetti, D. Di Ruscio, and A. Pierantonio. Managingdependentchanges in coupledevolution, toappear in Procs. ICMT 2009, Zurich, Switzerland
      D.S.Kolovos, D. Di Ruscio, R.F. Paige, A. Pierantonio. DifferentModelsforModelMatching: An analysisofapproachestosupportmodeldifferencing, Procs. CVSM'09, Vancouver, Canada