Evolutionary Togetherness: How to Manage Coupled Evolution in Metamodeling Ecosystems

Alfonso Pierantonio
DISIM – Università degli Studi dell'Aquila, Italy
alfonso.pierantonio@univaq.it

2
Model-Driven Engineering
Metamodeling Ecosystems
How/why a metamodel changes?
Coupled Evolution
Ecosystem Specification
→ Relation and Dependencies
Migrating Artifacts
→ Terms and Concepts
→ Current Approaches
→ A Babel of Tools and Techniques
EMF Migrate
Conclusions
ICGT 2012 – Bremen, 27 Sept 2012

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 domains

Alfonso Pierantonio ICGT 2012 – Bremen, 27 Sept 2012

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


5
Metamodels
→ DSMLs are analogous to software frameworks and as
such are intrinsically bound to the domain


6

This is a domain

• P1

• P2

• P3


7
Domains do not have crispy
Domains do not usually have crispy boundaries.
boundaries
This is a domain

• P1

• P2

• P3


8

This is a specific problem in the domain

domain

• P1

• P2

• P3


9
Metamodels are used for capturing
problems in the domain

domain

• P1

• P2

• P3


10
Misalignment

domain

• P1

• P2

• P3


11
Metamodels
→ In Model-Driven Engineering metamodels are
cornerstones for defining a wide range of related
artifacts


12
Metamodels
artifacts

Metamodel


13
Metamodels
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 Ecosystem


14

WOODLAND ECOSYSTEM

Great Horned
Hawk Owl

Skunk
Sparrow

Rabbit Shrew
Field Mouse

Grasshopper

Grass
Blueberry
Bush


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 relation


16

Petri Net Metamodel


17
Conformance

Petri Net Metamodel

A Petri Net Model


18
GMF Editors

Petri Net Metamodel

GMF Editor

A Petri Net Model


Transformation
19

Petri Net Metamodel

GMF Editor

Transformations

A Petri Net Model


Transformation
20

Petri Net Metamodel

GMF Editor

Code Generators

A Petri Net Model


Transformation
21

Petri Net Metamodel

GMF Editor

A Petri Net Model


22

WOODLAND ECOSYSTEM

Great Horned
Hawk Owl

Skunk
Sparrow

Rabbit Shrew
Field Mouse

Grasshopper

Grass
Blueberry
Bush


23

ENDANGERED Evolving
WOODLAND ECOSYSTEM

Great Horned
Hawk Owl

Skunk
Sparrow

Rabbit Shrew
Field Mouse

Grasshopper

Grass
Blueberry
Bush


24

Problem: what happens when the
metamodel in the ecosystem changes?


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

DSML


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 expertise


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 platform


28

domain

• P1

• P2

• P3


29

domain

• P1

• P2

• P3


Transformation
30
The Model P1 needs to be adapted
to conform the new metamodel version

domain

•• P11
P

• P2

• P3


31

A SIMPLE METAMODEL EVOLUTION


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 added


33
Petri Nets revised

Initial Version


34
Petri Nets revised

Initial Version

Final Version


35
Petri Nets revised Reference
merge

Initial Version

Metaclass
renaming

New Metaclasses Final Version


36
Petri Nets revised Reference
merge

Initial Version

Metaclass
renaming

New Metaclasses Final Version

Despite the simplicity, such changes are enough for
invalidating most of artifacts in the ecosystem

Transformation
37

Petri Net Metamodel

GMF Editor

A Petri Net Model


38
Metamodel/Model co-evolution


39
→ This model is not conforming to the
newer version of the Petri Net
Metamodel

→ An adaptation is necessary


40


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
restored


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.


43
Manual adaptations

Metamodel

→ Any artifact in the ecosystem requires to be
consistently adapted


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 ecosystem


45

Problem: how we can equip the ecosystem
with the right infrastructure to deal with
the co-evolution of any artifact ?


46

Problem: how we can equip the ecosystem
with the right infrastructure to deal with
the co-evolution of any artifact ?
consistent


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 adapted


48

Relations definition: a set of relations between the metamodel
and the other modeling artifacts are identified
of very different adaptation policies, depending on the types of
artifacts to be adapted


49

Metamodel


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


51
EHY THIS IS NOT
A TYPO, OK?



52

A megamodel is a model of which at least some
elements represent and/or refer to models or
metamodels



53
Ecosystems formalized by Megamodels


54
Ecosystems formalized by Megamodels
Coupled Evolution Tasks


55
Relations and Dependencies


56
ConformsTo relation
Conformance is present in most of technical spaces


57
ConformsTo Relation – as a weaving


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 metamodel


59
Domain Conformance


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,
…),
…
}

61


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
adaptation


63

MIGRATING ARTIFACTS


64

Relations definition: a set of relations between the
metamodel and the other modeling artifacts are identified
of very different adaptation policies, depending on the types
of artifacts to be adapted


65
Concept Description
How metamodel changes are detected: state-based and operation-
Differencing
based approaches
Adaptation The adaptation can be done in parallel with the metamodel changes
Scheduling (interleaved) or as a whole (batch)
The migration programs can be generated from the metamodel
Order
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 existing
Lack of
artifacts. In the former case, the induced lack of information is
information
managed by asking users or by using heuristics
Modularity/ Modularity mechanisms are required in order to organize recurrent
Reuse migrations in reusable modules
Refinement Refinement mechanisms are required to customized migrations
Model Mechanisms for querying and navigating the artifacts to be adapted
navigation (e.g., OCL)
Uncertainty The way the artifacts can be adapted is not univocal

66
Concept Description
How metamodel changes are detected: state-based and operation-
Differencing
based approaches
Adaptation The adaptation can be done in parallel with the metamodel changes
Scheduling (interleaved) or as a whole (batch)
The migration programs can be generated from the metamodel
Order
changes (higher-order) or programmatically (single-order)
Focus
Focus 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 existing
Lack of
artifacts. In the former case, the induced lack of information is
information
managed by asking users or by using heuristics
Modularity/ Modularity mechanisms are required in order to organize recurrent
Reuse migrations in reusable modules
Refinement Refinement mechanisms are required to customized migrations
Model Mechanisms for querying and navigating the artifacts to be adapted
navigation (e.g., OCL)
Uncertainty The way the artifacts can be adapted is not univocal

Levendovszky GMFEvolution EMFMigrate 67
CURRENTCOPE [2] Flock [4]
APPROACHES [3] [1] [5]
operation- operation- operation-
Differencing state-based state-based
based based based
Adaptation
interleaved batch batch batch batch
Scheduling
Order single-order single-order higher-order single-order single-order
Focus Model Model Transformation Editor any
Paradigm imperative imperative declarative declarative declarative
heuristics
Lack of heuristics
user specified user specified user specified based/ user
information based
specified
Modularity/R
No No No No Yes
euse
Refinement No No No No Yes
Model
Groovy based OCL based MCL based OCL based OCL based
navigation
Dedicated
Yes Yes Yes No Yes
environment
Reference
EMF EMF GME/GReAT EMF EMF
platform
Uncertainty No No No No 2012 – Bremen, 27 Sept 2012
ICGT No

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) Evolution
Focus Model Model Model Transformation Transformation Editor

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 technique


70
EMF Migrate Architecture


71
EMF Migrate
→ An EMF Migrate specification is given as follows:


72
EMF Migrate
→ An EMFMigrate specification is given as follows:

Migrate artifact A conforming to metamodel MM


73
EMF Migrate
According to the metamodel differences in the model
Delta


74
EMF Migrate

The migration is specified in terms of migration rules mri


75
EMF Migrate
Each rule is applied on the artefact A if the corresponding
guardi evaluated on the difference model Delta holds


76
EMF Migrate

The body of a migration rule consists of a sequence of rewriting rules


77
EMF Migrate
A rewriting rule can be specified as follows

where 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 tn


78
EMFMigrate > sample migration program


79
Metamodel change pattern written in
Edelta
- textual DSL for metamodel
difference specifications
- embedded in EMFMigrate


80


81
ATL Metamodel change pattern written
in EMFMigrate

- Metamodel-independent Query
Language
- ATL is imported as a parameter


82


83


84
Sample ATL transformation


85
EMFMigrate > sample migration library


86
EMFMigrate > sample migration library


87
The migrated transformation

Rule MergeReferences


→ 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

89
Conclusions
The evolution of metamodeling ecosystems comes with
some pragmatic issues whose solution is key to MDE
success

?


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
ecosystems


91
Conclusions
Metamodels are related to all the components in
the ecosystem and their evolution must be
consistently managed
Evolutionary togetherness


92
Only a portion of the MDE potential has been
deployed


93
deployed


94
deployed – few pragmatic issues are reducing its
effectiveness


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
(ICMT'10), 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 appear


96

Questions?

Università degli Studi dell’Aquila


Evolutionary Togetherness: How to Manage Coupled Evolution in Metamodeling Ecosystems

Recomendados

Recomendados

Más contenido relacionado

Similar a Evolutionary Togetherness: How to Manage Coupled Evolution in Metamodeling Ecosystems

Similar a Evolutionary Togetherness: How to Manage Coupled Evolution in Metamodeling Ecosystems (20)

Más de Alfonso Pierantonio

Más de Alfonso Pierantonio (18)

Último

Último (20)

Evolutionary Togetherness: How to Manage Coupled Evolution in Metamodeling Ecosystems