• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
What is needed for managing co-evolution in MDE?
 

What is needed for managing co-evolution in MDE?

on

  • 1,192 views

Metamodels can be considered one of the cardinal concepts of...

Metamodels can be considered one of the cardinal concepts of
Model-Driven Engineering and a number of coordinated entities,
suchasmodels, transformationsandtools, isdependingonit. Anal-
ogously to any software artifact, metamodels are equally prone to
evolution during their lifetime. As a consequence, whenever a
metamodelchanges, any related entity must be consistently adapted
for preserving its wellformedness, consistency, or intrinsic correct-
ness.

This work discusses the problem of co-adapting models, trans-
formations, and tools. Different aspects are taken into account and
a prospective and unifying characterization is given with the intend
ofclarifyingthemaindifficultiesandoutlinethebasicrequirements
for possible solutions. In this respect, EMFMigrate a comprehen-
sive approach to the metamodel co-evolution problem is proposed.

Statistics

Views

Total Views
1,192
Views on SlideShare
1,190
Embed Views
2

Actions

Likes
1
Downloads
0
Comments
0

2 Embeds 2

http://www.slideshare.net 1
http://twitter.com 1

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

    What is needed for managing co-evolution in MDE? What is needed for managing co-evolution in MDE? Presentation Transcript

    • What is needed for managing co-evolution in MDE?
      Dipartimento di InformaticaUniversità degli Studi dell’Aquila – Italy
      alfonso.pierantonio@univaq.it
      Davide Di Ruscio, Ludovico Iovino, Alfonso Pierantonio
    • Outline
      Introduction
      Scenario
      Changing a metamodel does not come alone:
      Metamodel/model co-evolution
      Metamodel/transformation co-evolution
      Metamodel/generic artifacts co-evolution
      Co-evolution dimensions
      EMFMigrate
      Migration programs and rules
      Example
      Conclusions
      Slideshare: http://slidesha.re/jvOm9m
      IWMCP2011 - June 30, 2011 - Zurich
    • Introduction
      In MDE a domain-specific modeling language (DSML) consists of a collection of coordinated models
      abstractand concrete syntaxes of the language
      further aspects including semantic mapping(s)
      The abstract syntax of DSMLs is typically expressed in terms of metamodels
      EclipseModelingFramework (EMF)
      3
      IWMCP2011 - June 30, 2011 - Zurich
    • Introduction
      Metamodels are the building blocks of any model development environment
      The entities defined upon metamodels include
      Models
      Model and Text Transformations
      Syntax-directed and diagrammatic editors
      Model differencing and analysis tools
      Given a metamodel a number of metamodel-dependent artifacts are usually designed and implemented, eg.
      GMF Editors
      Code generators
      IWMCP2011 - June 30, 2011 - Zurich
    • Scenario
      IWMCP2011 - June 30, 2011 - Zurich
    • Scenario
      IWMCP2011 - June 30, 2011 - Zurich
      Metamodels are living entities which are constantly changing
    • Scenario
      IWMCP2011 - June 30, 2011 - Zurich
      Whenever a metamodel undergoes modifications, all the corresponding entities must be accordingly adapted in order to remain valid.
    • Changing a metamodel does not come alone
      A number of relations which characterize the kind of rippleeffecthavebeenidentified
      conformsTothe conformance relation betweenmetamodels and models
      domainConformsTothe relation between a transformation and the metamodels it operates on
      dependsOnanyarbitrary relation between a metamodel and modeling artifacts (eg. GMF models or Java code)
      IWMCP2011 - June 30, 2011 - Zurich
    • Changing a metamodel does not come alone
      A number of relations which characterize the kind of rippleeffecthavebeenidentified
      conformsTothe conformance relation betweenmetamodels and models
      domainConformsTothe relation betweena transformation and the metamodels it operates on
      dependsOnany arbitrary relation between a metamodel and modeling artifacts (eg. GMF models or Java code)
      IWMCP2011 - June 30, 2011 - Zurich
      When a metamodel changes these relations might be affected and the corresponding artifacts might be no longer valid
    • conformsTo: Metamodel/model co-evolution
      Issue
      Changes in the metamodel might compromise the validity of the existing models which need to be consistently adapted to restore the conformance relation
      Classification of changes
      non-breaking changes
      breaking and resolvable changes
      breaking and unresolvable changes
      IWMCP2011 - June 30, 2011 - Zurich
      [EDOC 2008]
    • domainConformsTo: Metamodel/Transformation co-evolution
      Issue
      inconsistencies arise when elements in the considered transformation no longer satisfy the domain conformance relation
      Classification of adaptations
      fully automated
      partially automated
      fully semantic
      [Levendovszkyet al]
      IWMCP2011 - June 30, 2011 - Zurich
    • dependsOn: Metamodel/genericartifactco-evolution
      Issue
      Each different tool relies on a different dependsOn relation which is assumed by the tool implementation, eg
      GMF editors are developed starting from a set of models coupled with the considered metamodel
      Classification adaptation result
      Unsound, the adapted artifact is broken
      Uncomplete, the adapted artifact lacks capabilities
      Sound, the adapted artifact is complete
      IWMCP2011 - June 30, 2011 - Zurich
      [SLE 2010]
    • Co-evolution dimensions
      IWMCP2011 - June 30, 2011 - Zurich
    • Existing approaches
      Existing approaches are based on different techniques for migrating the affected artifacts
      operation-based
      pros:
      Locality: artifact and metamodel may be migrated together
      cons:
      Change recorders are required, thus change traces can be unavailable
      Redundancy in multiple migrations
      state-based
      pros:
      Interoperability among different platforms
      cons:
      Differencing accuracy, heuristics instead of semantics
      Usually based on HOTs, lack of flexibility
      IWMCP2011 - June 30, 2011 - Zurich
    • It is a programmatic approach consisting of a DSLfor specifying migration strategies for any kind of artifacts
      The migration strategies can be specified and collected in libraries, each formalizing a specific relation
      conformsTo
      domainConformsTo
      dependsOn
      Extension and customization are possible by means of linguistic features (refine, override) for deviating from default migration strategies
      IWMCP2011 - June 30, 2011 - Zurich
    • IWMCP2011 - June 30, 2011 - Zurich
    • Migration
      After a metamodeldifference (Delta) iseithercalculated or defined, the migrationstrategydefinedby a library (and itssubsequentextensions) ofrules can beusedtoadapt the correspondingartifacts
      IWMCP2011 - June 30, 2011 - Zurich
    • A migration program
      While adapting an artifact A conforming to MM, a rule mri is applied whenever the guardiis detected on the metamodel Delta
      IWMCP2011 - June 30, 2011 - Zurich
      rewriting rules, in-place transformations
    • Migration rules
      The body of a migration rule consists of a sequence of rewriting rules like the following
      s[guard] -> t1[assign1]; t2[assign2]; …tn[assignn]
      where s, t1, …,tnrefer to metaclasses of the considered artifact metamodel(e.g. ATL, TCS), and guardis a booleanexpression which has to be true in order to rewrite swith t1, t2, and tn.
      IWMCP2011 - June 30, 2011 - Zurich
    • A simple ATL migrationrule
      IWMCP2011 - June 30, 2011 - Zurich
    • IWMCP2011 - June 30, 2011 - Zurich
    • Rule guard, it detects change patterns on the metamodel delta
      IWMCP2011 - June 30, 2011 - Zurich
    • rewriting guard, it detects patterns on the artifact to be adapted
      IWMCP2011 - June 30, 2011 - Zurich
    • IWMCP2011 - June 30, 2011 - Zurich
    • Conclusions
      Co-evolution between metamodel/model has been intensively investigated over the last years
      Co-evolutionbetweenmetamodel/modelis just onepossible case, plentyofothercases are demandingsupport
      Using different techniques for different cases is still possible but requires too much effort, reduces regularity, and demands familiarity with too many notations and systems
      We proposed EMFMigrate
      a comprehensive and generic approach for any kind of co/evolution problem in MDE
      IWMCP2011 - June 30, 2011 - Zurich
    • Whatisneeded?
      A uniform and consistentapproachfordealingwithanykindofdependency in model-drivendevelopmentenvironment
      A programmaticyetdeclarativeapproachtodefine default migrationstrategies
      Extensionmechanismforcustomizing default behavioraccordingtomigrationrequirement
      Toolsupport and integration, usability, etc.
      IWMCP2011 - June 30, 2011 - Zurich
    • What is needed for managing co-evolution in MDE?
      Dipartimento di InformaticaUniversità degli Studi dell’Aquila – Italy
      alfonso.pierantonio@univaq.it
      Davide Di Ruscio, Ludovico Iovino, Alfonso Pierantonio
      Questions ?