Evolution in the Large and in the Small in Model-Driven Development
-
Upload
alfonso-pierantonio -
Category
Technology
-
view
1.463 -
download
2
description
Transcript of Evolution in the Large and in the Small in Model-Driven Development
.
Alfonso PierantonioDipartimento di Informatica
Università degli Studi dell’Aquila
Evolution in the Large and in the Small in
Model-Driven Development
22Introduction
»Model Driven Engineering (MDE) is increasingly gaining acceptance in the development of software 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 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
33Modeling languages
»Modeling languages can be used to specify problems, solutions and the mapping among them in the corresponding domains
abst
racti
on
problem domain
solution domain
• P
• S
Domain-specific modeling languages
General-purpose modeling languages,eg. UML
44Evolution
»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
55Evolution
»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
Note: problems with profiles in different versions of UML
UML1995 1997 20052000 2003 2007
UM 0.8
UML 0.9
UML 1.1
UML 1.3
UML 1.4
UML 1.5
UML 2.0
UML 2.1.2
UML 2.2
66Evolution
»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
77Evolution
»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
DSL
88Evolution
» I would like to discuss the problem of the evolution in model-driven development
99Evolution
» I would like to discuss the problem of the evolution in model-driven development
10
10Evolution
» I would like to discuss the problem of the evolution in model-driven development engineering
11
11
12
12
MDD
13
13
MDD
MDE
MDD
MDE
14
14
MDD
MDE
MDD
MDE
We have not yet seen the full application deployment of MDE![J. Bezivin keynote at SLE 2009]
15
15Evolution
» I would like to discuss the problem of the evolution in model-driven development 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
16
16Summary
» Introduction
»Evolution in the Large: Metamodel Evolution (XLE)– Problem-based adaptation
– Solution-based adaptation
– Metamodel change classification
– Transformational adaptation of models
»Evolution in the Small: Application Model Evolution (XSE)– Data migration
– Adaptation of specific assets
»Conclusions and future work
17
17Summary
» Introduction
»Evolution in the Large: Metamodel Evolution (XLE)– Problem-based adaptation
– Solution-based adaptation
– Metamodel change classification
– Transformational adaptation of models
»Evolution in the Small: Application Model Evolution (XSE)– Data migration
– Adaptation of specific assets
»Conclusions and future work
18
18
M3
M2
M1
M0
Meta modeling architecture
Models
Metamodels
Meta Metamodel
Tools(Visual Editors)
The “language” of languages,eg. Ecore
The modeling language, typically used to engineer the application domain,eg. UWE, WebML, beContent
Instance models which represent problems and solutions in the application domain
Systems and applications realizing the solution in the application domain,eg. portals, data-intensive web apps, etc
Tools(Visual Editors)Tools
(Visual Editors)Tools(Visual Editors)Tools
(Visual Editors)Tool
19
19
M3
M2
M1
M0
Metamodel based tools
Model
Metamodel
Meta MetamodelconformsTo
conformsTo
Tool
edits basedOn implementedFor
20
20
• P1
• P2
• P3
This is a domain
21
21
• P1
• P2
• P3
Domains usually do not have crispy boundaries.This is a domain
22
22
• P1
• P2
• P3
This is a specific problem in the domain
domain
23
23
• P1
• P2
• P3
Goal: to formalize a modeling language for capturing the domain problems
domain
24
24
Metamodel
• P1
• P2
• P3
domain
Goal: to formalize a modeling language for capturing the domain problems
25
25
Metamodel
• P1
• P2
• P3
domain
Problem: the domain and the metamodel do not have the same semantics
26
26
M3
M2
M1
M0
Model Transformations
Source Model
Source Metamodel
Meta Metamodel
Target Model
Target Metamodel
Transformation Rules
Transformation Language
Transformation Engine
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
exec targetsource
tofrom
27
27
Metamodel
• P1
• P2
• P3
Model transformations map problems to solutions
domain
28
28
Metamodel
• P1
• P2
• P3
Model transformations map problems to solutions
• S1
• S2
domain
29
29Metamodel evolution
»Sometimes metamodels must be adapted, extended or amended to better capture the problems
30
30Metamodel evolution
»Sometimes metamodels must be adapted, extended or amended to better capture the problems
31
31Metamodel 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 refinement or enlargement
– a more complete understanding of the domain is at hand
32
32
Metamodel
• P1
• P2
• P3
domain
33
33
Metamodel
• P1
• P2
• P3
domain
34
34
M3
M2
M1
M0
Model Transformations
Source Model
Source Metamodel
Meta Metamodel
Target Model
Target Metamodel
Transformation Rules
Transformation Language
Transformation Engine
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
exec targetsource
tofrom
35
35
M3
M2
M1
M0
Model Transformations
Source Model
Source Metamodel
Meta Metamodel
Target Model
Target Metamodel
Transformation Rules
Transformation Language
Transformation Engine
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
exec targetsource
tofrom
Source Metamodel
36
36
M3
M2
M1
M0
Model Transformations
Source Model
Source Metamodel
Meta Metamodel
Target Model
Target Metamodel
Transformation Rules
Transformation Language
Transformation Engine
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
exec targetsource
tofrom
Source Metamodel
37
37
M3
M2
M1
M0
Model Transformations
Source Model
Source Metamodel
Meta Metamodel
Target Model
Target Metamodel
Transformation Rules
Transformation Language
Transformation Engine
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
exec targetsource
tofrom
Source Metamodel
38
38
M3
M2
M1
M0
Model Transformations
Source Model
Source Metamodel
Meta Metamodel
Target Model
Target Metamodel
Transformation Rules
Transformation Language
Transformation Engine
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
conformsTo
exec targetsource
tofrom
Source Metamodel
39
39Metamodel 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– Breaking and resolvable: existing instances need to be co-
adapted to conform to the new metamodel version. The co-evolution can be automatically operated
– Breaking and unresolvable: the necessary co-adaptation of existing models can not be automatically computed due to the need of further information
[Paige at al 2007]
40
40Metamodel changes classificationChange type Change
Non-breaking Generalize metapropertyAdd (non-obligatory) metaclassAdd (non-obligatory) metaproperty
Breaking and resolvable Extract (abstract) superclassEliminate metaclassEliminate metapropertyPush metapropertyFlatten hierarchyRename metaelementMove metapropertyExtract/inline metaclass
Breaking and unresolvable Add obligatory metaclassAdd obligatory metapropertyPull metapropertyRestrict metapropertyExtract (non-abstract) superclass
41
41Sample Petri Net metamodel changes
42
42Sample Petri Net metamodel changes
Breaking and resolvable changes(extract meta-class)
43
43Sample Petri Net metamodel changes
Breaking and resolvable changes(extract meta-class)
p1 p2
t1
t2
p1 p2
pt1 tp1
pt2tp2
44
44Sample Petri Net metamodel changes
Breaking and unresolvable change
(Add obligatory metaproperty)
45
45Sample Petri Net metamodel changes
Breaking and unresolvable change
(Add obligatory metaproperty)
p1 p2
pt1 tp1
pt2tp2
p1 p2
pt1 tp1
pt2tp2
weight=? weight=?
weight=?weight=?
46
46Model difference representation
[TOOLS EUROPE 2007]([Vallecillo et al 2008])
47
47Metamodel difference representation
»Since a meta-model is a model itself, metamodel differences can be represented by exploiting the previously mentioned approach
48
48Sample metamodel difference representation
49
49Transformational adaptation of models
» Δ consist of an arbitrary combination of the atomic changes
» In order to distinguish them the following steps are performed:
1. automatic decomposition of Δ in two disjoint (sub) models, ΔR and Δ¬R, which denote breaking resolvable and unresolvable changes;
2. if ΔR and Δ¬R are parallel independent then we separately generate the corresponding co-evolutions;
3. if ΔR and Δ¬R are parallel dependent, they are further refined to identify and isolate the interdependencies causing the interferences
[EDOC 2008]
50
50Transformational adaptation of models: example
Δ(0,1)
51
51Transformational adaptation of models: example
Δ(0,1)
Restrict metaproperty change
Extract metaclass changes
52
52Transformational adaptation of models: example
ΔR(0,1)
module H_R;
create OUT : ATL from Delta : KM3Diff;
rule CreateRenaming {
…
}
rule CreateExtractMetaClass {
…
}
…
HR
53
53Transformational adaptation of models: example
module H_R;
create OUT : ATL from Delta : KM3Diff;
rule CreateRenaming {
…
}
rule CreateExtractMetaClass {
…
}
…module CTR;
create OUT : MM1 from IN : MM0;
…
rule createPTArc(s : OclAny, n : OclAny) {
…
}
rule createTPArc(s : OclAny, n : OclAny) {
…
}
HR
CTR
ΔR(0,1)
54
54Transformational adaptation of models: example
p1 p2
t1
t2
p1 p2
pt1 tp1
pt2tp2
CTR
55
55Transformational adaptation of models: example
module H_NR;
create OUT : ATL from Delta : KM3Diff;
rule CreateRestrictMetaproperty{
…
}
rule AddObligatoryMetaclass {
…
}
…
H¬R
Δ¬R(0,1)
56
56Transformational adaptation of models: example
module H_NR;
create OUT : ATL from Delta : KM3Diff;
rule CreateRestrictMetaproperty{
…
}
rule AddObligatoryMetaclass {
…
}
…
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
Δ¬R(0,1)
57
57Parallel 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
58
58Parallel 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
59
59Parallel dependent modifications
60
60Parallel 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 interdependencies between the atomic changes in MM2 − MM0 have to be isolated (i.e. the attribute weight of the Arc metaclass of MM2)
61
61Resolving 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]
62
62Resolving dependences
»Sufficient criteria have been given to establish the correct scheduling of the conflicting changes
63
63Resolving 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 Model Migration to Manage Metamodel Evolution, MoDELS 2009
64
64Approach
»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
65
65Summary
» Introduction
»Evolution in the Large: Metamodel Evolution (XLE)– Problem-based adaptation
– Solution-based adaptation
– Metamodel change classification
– Transformational adaptation of models
»Evolution in the Small: Application Model Evolution (XSE)– Data migration
– Adaptation of specific assets
»Conclusions and future work
66
66Solution-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
67
67beContent
»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.
68
68beContent
beContent Metamodel
ECLIPSE GMF AMMA TCS
ECLIPSE Ecore
ACCELEO AMMA ATL
ACCELEO
69
69beContent architecture
BML BTLround-tripping
beContent Metamodel
M2C M2M
M2C M2CPHP
MySQL J2EE/Liferay .NET
ECLIPSE GMF AMMA TCS
ECLIPSE Ecore
ACCELEO AMMA ATL
ACCELEO ACCELEO
beContent Metamodel
ECLIPSE GMF AMMA TCS
ECLIPSE Ecore
ACCELEO AMMA ATL
ACCELEO
70
70BML – beContent Modeling Language
[demo at ICWE 2009]
71
71BMM – beContent Metamodel
72
72BMM – beContent Metamodel
73
73BMM – beContent Metamodel
. . .
Model fragmentMetamodel fragment
74
74Problem: a simple text generation
»Generate a text file containing source code based on information which is retrieved from different instances of the same metaclass
75
75Problem: a simple text generation
. . .
...
76
76Problem: 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
77
77Refactoring the metamodel
MM v1.0 MM v2.0
78
78Problem: 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 …
79
79Hiding the metamodel refactoring
Model (v1.0)
Metamodel v1.0
conformsTo
Source code
Metamodel v2.0
Model (v2.0)
conformsTo
Δ
adapt(Δ)
M2T
80
80Evolution 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 Ecore metamodels differencing
– Overriding default adaptation with ad-hoc refactorings
– Semantics preserving ?
– Validation, everybody is very keen on keeping her/his models secret :-)
81
81Summary
» Introduction
»Evolution in the Large: Metamodel Evolution (XLE)– Problem-based adaptation
– Solution-based adaptation
– Metamodel change classification
– Transformational adaptation of models
»Evolution in the Small: Application Model Evolution (XSE)– Data migration
– Adaptation of specific assets
»Conclusions and future work
82
82Evolution in the small
Model (v1.0)
System”
Model (v2.0)
System’
Manual modifications
T T
83
83Evolution 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
84
84Evolution in the small
M1
System2
M2
System1
Δ
T T
85
85Evolution in the small
M1
System2
M2
System1
Δ
T T
data1 data2
uses uses
86
86Evolution in the small
M1
System2
M2
System1
Δ
T T
uses uses
migration(evolution rollback aux functions)
data1 data2
87
87Evolution in the small
M1
System2
M2
System1
Δ
T T
uses usesT’
migration (Δ)data1 data2
88
88Evolution in the small: beContent example
»Simple data refactoring– birthday is deleted
– a new reference is added
Manual modifications
89
89Evolution in the small: beContent example
Δ
90
90Evolution 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
91
91Evolution in the small: beContent example
ALTER TABLE Person ADD (zodiac INT UNSIGNED NOT NULL);
ALTER TABLE PersonDROP COLUMN birthday;
92
92Evolution 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
93
93Conclusions
»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!
95
95Some References» A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, Automating Co-
evolution in Model-Driven Engineering. Procs. EDOC 2008, Munich, Germany
» A. Cicchetti, D. Di Ruscio, R. Eramo and A. Pierantonio, Meta-model Differences for Supporting Model Co-evolution. Procs. MoDSE 2008, Atene, Greece
» A. Cicchetti, D. Di Ruscio, A. Pierantonio, A Metamodel Independent Approach to Difference Representation, Procs. TOOLS EUROPE 2007, Zurich, Switzerland
» A. Cicchetti, D. Di Ruscio, and A. Pierantonio. Managing dependent changes in coupled evolution, to appear in Procs. ICMT 2009, Zurich, Switzerland
» D.S. Kolovos, D. Di Ruscio, R.F. Paige, A. Pierantonio. Different Models for Model Matching: An analysis of approaches to support model differencing, Procs. CVSM'09, Vancouver, Canada