model management in model-driven engineering

Dipartimento di Ingegneria e Scienze

Università degli Studi dell’Aquiladell’Informazione e Matematica

Model Management in Model-Driven Engineering

Alfonso Pierantonio

2

University of Alberta - May 30, 2016

IntroductionIn this presentation, I’ll overview different model management we have been investigating over the last years– Coupled Evolution– Semantic Issues in Bidirectional Model

Transformations– MDE Forge Collaborative Modeling Platform

A brief introduction to Model-Driven Engineering

4


Model-Driven EngineeringA software discipline that shifts the focus of software development from coding to modeling

Models – are abstractions representing knowledge and activities

that govern a particular application domain– use domain concepts rather than computing concepts,

ie they can be defined/used by non computer scientists– have first-class status

Model-Driven Engineering=

Abstraction + Automation

6


AbstractionModels are abstractions that enable to deal with complex reality in a simplified way– early analysis to detect faults or unwanted behavior– communication between stakeholders, designers, etc– to persist and retain knowledge within an

organization

Models have a purpose: they can be used in a cost-effective way (simpler, safer, cheaper) in place of reality for some cognitive purpose.

wrong models lead to wrong conclusions


10Wrong models: four humoursHippocrates believed the body contained four fluids, called humours: blood, yellow bile, black bile, and phlegm.Bloodletting was used to remove excess humour to restore balance and cure sickness.

Physician Benjamin Rush (one of the signers of the Declaration of Independence)

recommended bloodletting to George Washington, the first U.S. president, who

died after having 3.75 liters of blood removed from his body within a 10 hour

period as treatment for a throat infection.

Model-Driven Engineering=

Abstraction + Automation

13


AutomationA model transformation is a program that mutates one model into another– production of concrete

models from abstract ones(and viceversa)

– keeping two or more models synchronized orin a consistent state

– models must be formal and processable

m1

m2

m3

m4

viewpoint v1 viewpoint v2

14


TransformationsModel transformations are required to perform complex tasks, eg– non destructive incremental changes– round-tripping engineering, – traceability managementUsing standard programming languages is challenging, suboptimal, and prone to errors

15


Summary– Introduction– Coupled Evolution– Uncertainty in Bidirectional Model Transformations– MDE Forge Collaborative Modeling Platform

16


Metamodeling ArchitectureThe four-layer meta architecture is present in many technical spaces.


17Modeling EcosystemsMetamodels formalize domains and are cornerstones of modeling ecosystems– A wide range of artifacts are defined upon

metamodels– Changing a metamodel might invalidate many

components of the ecosystem

Petri Net Metamodel

A Petri Net Model

Petri Net Metamodel

Conformance

A Petri Net Model

GMF Editor

Petri Net Metamodel

GMF Editors

A Petri Net Model

GMF Editor

Petri Net Metamodel

Transformation

Transformations

A Petri Net Model

GMF Editor

Petri Net Metamodel

Transformation

Code Generators

A Petri Net Model

GMF Editor

Petri Net Metamodel

Transformation

A simple metamodel evolution

25


A simple metamodel evolution Let us consider a simple refactoring of a (simple) Petri Net metamodel– A metaclass renaming– Reference merge– New Metaclasses added

26


Petri Net revised

Initial Version

27


Petri Net revised

Initial Version

conformsTo

28


Petri Net revised

Initial Version

Final Version

conformsTo

29


Petri Nets revised

Initial Version

Final Version

Metaclass renaming

Reference merge

New Metaclasses

30Petri Nets revised

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

Initial Version

Final Version

Metaclass renaming

Reference merge

New Metaclasses

31


Metamodel/Model co-evolution– The model is not conforming to

the Petri Net metamodel anymore

– Adaptations are needed to restore conformance

32


Metamodel/Model co-evolution

33


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

The classification is artifact specific, eg. what holds for models does not hold for transformations

0..*

Artifact Impact

Models An optional metaclass does not compromise the conformance of existing models

Transformations A new rule is needed to “consume” the new instances

Editors A new widget in the palette must be added

Code generators Templates must be extended

…

(new metaclass)

36


A Babel of Tools and TechniquesToo many different techniques, difficulties in having a consistent and coherent adaptation of the ecosystem

Metamodel

COPE Flock Täntzer et al (ICGT’12) Levendovszky O. Diaz

(SLE’12)GMF

Evolution

Focus Model Model Model Transformation Transformation Editor

37


ApproachesThere are different kinds of approaches– Inductive: migration strategies are directly derived

from metamodel differences– Programatic: migration procedure are specified by

means of dedicated languages or librariesThe main difficulty is due to the ambiguity of the migration process– Several alternatives are typically available– Difficulty in “capturing” the rationale behind

migration to be reused across the different artifacts

38


EMF MigrateIt is a declarative DSL devoted to the co-evolution management of any artifact in the ecosystem, it permits It is agnostic of the differencing technique

Davide Di Ruscio, Jürgen Etzlstorfer, Ludovico Iovino, Alfonso Pierantonio and Wieland Schwinger. Supporting variability exploration and resolution during model migration. ECMFA 2016, STAF Wien (to appear)

Di Ruscio, Davide, Ludovico Iovino, and Alfonso Pierantonio. "Coupled evolution in model-driven engineering." Software, IEEE 29.6 (2012): 78-84.

Iovino, Ludovico, Alfonso Pierantonio, and Ivano Malavolta. "On the Impact Significance of Metamodel Evolution in MDE." Journal of Object Technology 11.3 (2012): 3-1.

Di Ruscio, Davide, Ludovico Iovino, and Alfonso Pierantonio. "Evolutionary Togetherness: How to Manage Coupled Evolution in Metamodeling Ecosystems." ICGT. Vol. 7562. 2012.

Di Ruscio, Davide, Ralf Lämmel, and Alfonso Pierantonio. "Automated co-evolution of GMF editor models." Software Language Engineering. Springer Berlin Heidelberg, 2010. 143-162.

A. Cicchetti, D. D. Ruscio, R. Eramo, and A. Pierantonio, “Automating Co-evolution in Model-Driven Engineering,” Enterprise Distributed Object Computing Conference, 2008. EDOC '08. 12th International IEEE, pp. 222–231, 2008.

39


Summary– Introduction– Coupled Evolution– Uncertainty in Bidirectional Model Transformations– MDE Forge Collaborative Modeling Platform

40


Bidirectionality in Model TransformationsBidirectionality is about keeping a set or related models synchronized or in a consistent state: updates to a source entail updates to the others.


41Bidirectionality in Model TransformationsBidirectionality is about keeping a set or related models synchronized or in a consistent state: updates to a source entail updates to the others.

2

42


Uncertainty in modelingUncertainty in modeling has been investigated in different areas– requirement engineering– partial modeling– change propagation – variability modeling– sets of models Uncertainty in model transformations makes their behavior non-deterministic and difficult to be kept under control P. Stevens, “Bidirectional model transformations in

QVT: semantic issues and open questions,” Softw Syst Model, vol. 9, no. 1, pp. 7–20, Dec. 2008.

43


Uncertainty in modelingUncertainty in modeling has been investigated in different areas– requirement engineering– partial modeling– change propagation – variability modeling– sets of models Uncertainty in model transformations makes their behavior non-deterministic and difficult to be kept under control P. Stevens, “Bidirectional model transformations in

QVT: semantic issues and open questions,” Softw Syst Model, vol. 9, no. 1, pp. 7–20, Dec. 2008.

No emerging language so far, QVT-R implementations are present severe

semantic issues

in(card)

startup

Out of Service

Off Idle

Self Test

Maintenance

Active

Authentication Selecting transaction Transactionfailed

doneshutdown

in(card)cancel

error

fixed

Out of Service

Off Idle

Active

shutdown

cancel

error

fixed

startup

done

2 2

in(card)

startup

Out of Service

Off Idle

Self Test

Maintenance

Active


doneshutdown

in(card)cancel

error

fixed

Out of Service

Off Idle

Active

shutdown

cancel

error

fixed

startup

done

in(card)

startup

Out of Service

Off Idle

Self Test

Maintenance

Active


doneshutdown

in(card)cancel

error

fixed

Out of Service

Off Idle

Active

shutdown

cancel

error

fixed

startup

done

How this manual change can be

back propagated?

in(card)

startup

Out of Service

Off Idle

Self Test

Maintenance

Active


doneshutdown

in(card)cancel

error

fixed

Out of Service

Off Idle

Active

shutdown

cancel

error

fixed

startup

done

The update entails multiple

choices

49


Why non-determinism/uncertainty?Consistency management can be seen as an update view problem.The transformation is not-deterministic because1) Metamodels are not isomorphic2) Multiple update strategies are possible, a

general consistency-restoration strategy cannot always at design-time

Unknown uncertainty: the designer does not hold enough information for deciding a priori what is the “wanted” solution

Zan, Tao, Hugo Pacheco, and Zhenjiang Hu. "Writing bidirectional model transformations as intentional updates." Procs. 36th International Conference on Software Engineering, 2014.

Bancilhon, François, and Nicolas Spyratos. "Update semantics of relational views." ACM Transactions on Database Systems (TODS) 6.4 (1981): 557-575.

50


Why non-determinism/uncertainty?Consistency management can be seen as an update view problem.The transformation is not-deterministic because1) Metamodels are not isomorphic2) Multiple update strategies are possible, a

general consistency-restoration strategy cannot always at design-time

Unknown uncertainty: the designer does not hold enough information for deciding a priori what is the “wanted” solution

Zan, Tao, Hugo Pacheco, and Zhenjiang Hu. "Writing bidirectional model transformations as intentional updates." Procs. 36th International Conference on Software Engineering, 2014.

Bancilhon, François, and Nicolas Spyratos. "Update semantics of relational views." ACM Transactions on Database Systems (TODS) 6.4 (1981): 557-575.

Warning!

Non-determinism is evident only at runtime

51


Janus Transformation LanguageThe JTL language provide an explicit support to non-determinism: – programmers need only specify a consistency relation,

allowing the bx engine to resolve the under-specification non-deterministically”

– From unknown to known uncertainty!

– A categorical characterization of JTL

Alessio Bucaioni, Antonio Cicchetti, Federico Ciccozzi, Saad Mubeen, Alfonso Pierantonio, Mikael Sjödin. “Handling Uncertainty in Automatically Generated Implementation Models in the Automotive Domain”, Proceedings SEEA, 2016 (to appear)

Eramo, Romina, Alfonso Pierantonio, and Gianni Rosa. "Managing uncertainty in bidirectional model transformations." Proceedings of the 2015 ACM SIGPLAN International Conference on Software Language Engineering. ACM, 2015. Best paper award.

Eramo, Romina, Alfonso Pierantonio, and Gianni Rosa. "Uncertainty in bidirectional transformations." Proceedings of the 6th International Workshop on Modeling in Software Engineering. ACM, 2014.

Cicchetti, Antonio, et al. "JTL: a bidirectional and change propagating transformation language." Software Language Engineering. Springer Berlin Heidelberg, 2010. 183-202.

Zinovy Diskin, Romina Eramo, Alfonso Pierantonio, Krzysztof Czarnecki: “Incorporating Uncertainty into Bidirectional Model Transformations and their Delta-Lens Formalization.” Procs. 5th Intl Workshop on Bidirectional Transformations, ETAPS 2016: 15-31

52


Current Research DirectionsMain research interests in Model Driven Engineering– Coupled Evolution– Uncertainty in Bidirectional Model Transformations– MDE Forge Collaborative Modeling Platform

53


MDE ForgeComplex model management as-a-service– most functionalities are restfulCollaborative modeling platform– workspace/project/team management– artifact sharing mechanismOpen architecture to accommodate third-party functionalities– core components– extensions

Feature soon(already implemented)

later(Q2 2017)

maybe

formalized as a megamodel ✓document persistency ✓free user registration ✓development team support ✓workspace templating ✓search by-example ✓advanced query language ✓advanced browsing/clustering ✓full EMF support ✓ATL transformation engine ✓ATL static validation & testing ✓ETL transformation engine ✓automated transformation chaining ✓metrics extraction ✓user-defined quality models ✓collaborative diagrammatic editor ✓

…

55


Core Service

56


ATL Extension

57


Metamodel clustering tecniques

58


Digging the repository

59


Digging the repositoryRepository wide query language for mining the complete set of available artifacts

mdeforge> mdeforge> foreach (mm in mdeforge.getMetamodels()) { List<String> results; EClass.allInstances(mm).foreach(x -> results.add(x.getName())); EAttribute.allInstances(mm).foreach(x -> results.add(x.getName())); EReference.allInstances(mm).foreach(x -> results.add(x.getName()))} > 257,347 elements found in 2422 metamodels

mdeforge>

60


MDE Forgehttp://www.mdeforge.orgExample– Dashboard http://

www.mdeforge.org/mdeforge/public/dashboard – Clustering

http://www.mdeforge.org/public/browse/cluster_graph

http://www.mdeforge.org/mdeforge/public/dashboard

http://www.mdeforge.org/mdeforge/public/dashboard



Di Rocco, J., Di Ruscio, D., Iovino, L., & Pierantonio, A. (2015). Collaborative Repositories in Model-Driven Engineering. IEEE Software, (3), 28-34.

62


ConclusionsModel-Driven Engineering is about related models cross-linked by automated operations and existing at – different level of abstractions, and – different stages Uncertainty is inherent to most of the operations that include– Model transformations– Multi-layer model transformations (coupled evolution)– Model comparison/differencing– Traceability management– Solution space exploration– etc

Thanks!