An overview on some relevant model managements activities in MDE

1. Dipartimento di Ingegneria e Scienze
Università degli Studi dell’Aquila
dell’Informazione e Matematica
Model Management in Model-
Driven Engineering
Alfonso Pierantonio

2. 2
University of Alberta - May 30, 2016
Introduction
In 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

3. A brief introduction to
Model-Driven Engineering

4. 4
University of Alberta - May 30, 2016
Model-Driven Engineering
A 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

5. Model-Driven Engineering
=
Abstraction + Automation

6. 6
University of Alberta - May 30, 2016
Abstraction
Models 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.

9. wrong models lead to
wrong conclusions

10. University of Alberta - May 30, 2016
10
Wrong models: four humours
Hippocrates 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.

12. Model-Driven Engineering
=
Abstraction + Automation

13. 13
University of Alberta - May 30, 2016
Automation
A 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 or
in a consistent state
– models must be formal
and processable
m1
m2
m3
m4
viewpoint v1 viewpoint v2

14. 14
University of Alberta - May 30, 2016
Transformations
Model transformations are required to perform complex tasks,
eg
– non destructive incremental changes
– round-tripping engineering,
– traceability management
Using standard programming languages is challenging,
suboptimal, and prone to errors

15. 15
University of Alberta - May 30, 2016
Summary
– Introduction
– Coupled Evolution
– Uncertainty in Bidirectional Model Transformations
– MDE Forge Collaborative Modeling Platform

16. 16
University of Alberta - May 30, 2016
Metamodeling Architecture
The four-layer meta architecture is present in many
technical spaces.

17. University of Alberta - May 30, 2016
17
Modeling Ecosystems
Metamodels 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

18. Petri Net Metamodel

19. A Petri Net Model
Petri Net Metamodel
Conformance

20. A Petri Net Model
GMF Editor
Petri Net Metamodel
GMF Editors

21. A Petri Net Model
GMF Editor
Petri Net Metamodel
Transformation
Transformations

22. A Petri Net Model
GMF Editor
Petri Net Metamodel
Transformation
Code Generators

23. A Petri Net Model
GMF Editor
Petri Net Metamodel
Transformation

24. A simple metamodel evolution

25. 25
University of Alberta - May 30, 2016
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. 26
University of Alberta - May 30, 2016
Petri Net revised
Initial Version

27. 27
University of Alberta - May 30, 2016
Petri Net revised
Initial Version
conformsTo

28. 28
University of Alberta - May 30, 2016
Petri Net revised
Initial Version
Final Version
conformsTo

29. 29
University of Alberta - May 30, 2016
Petri Nets revised
Initial Version
Final Version
Metaclass
renaming
Reference
merge
New Metaclasses

30. 30
Petri 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. 31
University of Alberta - May 30, 2016
Metamodel/Model co-evolution
– The model is not conforming to the
Petri Net metamodel anymore
– Adaptations are needed to restore
conformance

32. 32
University of Alberta - May 30, 2016
Metamodel/Model co-evolution

33. 33
University of Alberta - May 30, 2016
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

35. 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. 36
University of Alberta - May 30, 2016
A Babel of Tools and Techniques
Too 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. 37
University of Alberta - May 30, 2016
Approaches
There 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 libraries
The 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. 38
University of Alberta - May 30, 2016
EMF Migrate
It 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. 39
University of Alberta - May 30, 2016
Summary
– Introduction
– Coupled Evolution
– Uncertainty in Bidirectional Model Transformations
– MDE Forge Collaborative Modeling Platform

40. 40
University of Alberta - May 30, 2016
Bidirectionality in Model Transformations
Bidirectionality is about keeping a set or related
models synchronized or in a consistent state:
updates to a source entail updates to the others.

41. University of Alberta - May 30, 2016
41
Bidirectionality in Model Transformations
Bidirectionality 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. 42
University of Alberta - May 30, 2016
Uncertainty in modeling
Uncertainty 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. 43
University of Alberta - May 30, 2016
Uncertainty in modeling
Uncertainty 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

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

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

46. in(card)
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
Authentication
Selecting
transaction
Transactfailed
doneshutdown
in(card)cancel
error
fixed
Out of Service
Off Idle
Active
shutdown
cancel
error
fixed
startup
done

47. in(card)
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
Authentication
Selecting
transaction
Transactfailed
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?

48. in(card)
startup
Out of Service
Off Idle
Self Test
Maintenance
Active
Authentication
Selecting
transaction
Transactfailed
doneshutdown
in(card)cancel
error
fixed
Out of Service
Off Idle
Active
shutdown
cancel
error
fixed
startup
done
The update entails
multiple choices

49. 49
University of Alberta - May 30, 2016
Why non-determinism/uncertainty?
Consistency management can be seen as an update
view problem.
The transformation is not-deterministic because
1) Metamodels are not isomorphic
2) 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. 50
University of Alberta - May 30, 2016
Why non-determinism/uncertainty?
Consistency management can be seen as an update
view problem.
The transformation is not-deterministic because
1) Metamodels are not isomorphic
2) 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. 51
University of Alberta - May 30, 2016
Janus Transformation Language
The 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. 52
University of Alberta - May 30, 2016
Current Research Directions
Main research interests in Model Driven Engineering
– Coupled Evolution
– Uncertainty in Bidirectional Model Transformations
– MDE Forge Collaborative Modeling Platform

53. 53
University of Alberta - May 30, 2016
MDE Forge
Complex model management as-a-service
– most functionalities are restful
Collaborative modeling platform
– workspace/project/team management
– artifact sharing mechanism
Open architecture to accommodate third-party
functionalities
– core components
– extensions

54. 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. 55
University of Alberta - May 30, 2016
Core Service

56. 56
University of Alberta - May 30, 2016
ATL Extension

57. 57
University of Alberta - May 30, 2016
Metamodel clustering tecniques

58. 58
University of Alberta - May 30, 2016
Digging the repository

59. 59
University of Alberta - May 30, 2016
Digging the repository
Repository 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. 60
University of Alberta - May 30, 2016
MDE Forge
http://www.mdeforge.org
Example
– Dashboard
http://www.mdeforge.org/mdeforge/public/dashboard
– Clustering
http://www.mdeforge.org/public/browse/cluster_graph

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

62. 62
University of Alberta - May 30, 2016
Conclusions
Model-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

63. Thanks!