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

.

Alfonso PierantonioDipartimento di Informatica

Università degli Studi dell’Aquila

[email protected]

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








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



31



»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


Source Model

Source Metamodel

Meta Metamodel

Target Model

Target Metamodel




conformsTo

conformsTo

conformsTo

conformsTo

conformsTo

conformsTo

exec targetsource

tofrom

35

35

M3

M2

M1

M0


Source Model

Source Metamodel

Meta Metamodel

Target Model

Target Metamodel




conformsTo

conformsTo

conformsTo

conformsTo

conformsTo

conformsTo

exec targetsource

tofrom

Source Metamodel

36

36

M3

M2

M1

M0


Source Model

Source Metamodel

Meta Metamodel

Target Model

Target Metamodel




conformsTo

conformsTo

conformsTo

conformsTo

conformsTo

conformsTo

exec targetsource

tofrom

Source Metamodel

37

37

M3

M2

M1

M0


Source Model

Source Metamodel

Meta Metamodel

Target Model

Target Metamodel




conformsTo

conformsTo

conformsTo

conformsTo

conformsTo

conformsTo

exec targetsource

tofrom

Source Metamodel

38

38

M3

M2

M1

M0


Source Model

Source Metamodel

Meta Metamodel

Target Model

Target Metamodel




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


Breaking and resolvable changes(extract meta-class)

43


Breaking and resolvable changes(extract meta-class)

p1 p2

t1

t2

p1 p2

pt1 tp1

pt2tp2

44


Breaking and unresolvable change

(Add obligatory metaproperty)

45


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


Δ(0,1)

Restrict metaproperty change

Extract metaclass changes

52


ΔR(0,1)

module H_R;

create OUT : ATL from Delta : KM3Diff;

rule CreateRenaming {

…

}

rule CreateExtractMetaClass {

…

}

…

HR

53


module H_R;


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


p1 p2

t1

t2

p1 p2

pt1 tp1

pt2tp2

CTR

55


module H_NR;


rule CreateRestrictMetaproperty{

…

}

rule AddObligatoryMetaclass {

…

}

…

H¬R

Δ¬R(0,1)

56


module H_NR;


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


»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


60


» 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


»Sufficient criteria have been given to establish the correct scheduling of the conflicting changes

63


»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








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 Ecore

ACCELEO AMMA ATL

ACCELEO ACCELEO

beContent Metamodel


ECLIPSE Ecore

ACCELEO AMMA ATL

ACCELEO

70

70BML – beContent Modeling Language

[demo at ICWE 2009]

71

71BMM – beContent Metamodel

72


73


. . .

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


. . .

...

76


»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


» 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








82

82Evolution in the small

Model (v1.0)

System”

Model (v2.0)

System’

Manual modifications

T T

83


»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


M1

System2

M2

System1

Δ

T T

85


M1

System2

M2

System1

Δ

T T

data1 data2

uses uses

86


M1

System2

M2

System1

Δ

T T

uses uses

migration(evolution rollback aux functions)

data1 data2

87


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


Δ

90


»This is a special case in beContent as the underlying framework is able to detect new tables to be created

91


ALTER TABLE Person ADD (zodiac INT UNSIGNED NOT NULL);

ALTER TABLE PersonDROP COLUMN birthday;

92


»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

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

Technology

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