Slides of my talk at the Models In Software Engineering Workshop (MISE) co-located with the International Conference on Software Engineering (ICSE), Austin Texas, May 16, 2016

1. Featured Model Types
Gilles Perrouin, Moussa Amrani, Mathieu Acher, Benoît Combemale,
Axel Legay, Pierre-Yves Schobbens
Towards Systematic Reuse in Modelling
Language Engineering
MISE@ICSE, Austin
May 16, 2016

2. www.unamur.be
Reuse Dimensions [1]
2
Granularity
Scope
Specificity
[1] Kusel et al. Reuse in Model-To-Model Transformation
Languages: Are We There Yet? SoSyM, 14(2):537–572, May
2015.

3. www.unamur.be
Reuse Dimensions [1]
2
Granularity
Scope
Specificity
[1] Kusel et al. Reuse in Model-To-Model Transformation
Languages: Are We There Yet? SoSyM, 14(2):537–572, May
2015.

4. www.unamur.be
Reuse Dimensions [1]
2
Granularity
Scope
Specificity
[1] Kusel et al. Reuse in Model-To-Model Transformation
Languages: Are We There Yet? SoSyM, 14(2):537–572, May
2015.

5. www.unamur.be
Reuse Dimensions [1]
2
Granularity
Scope
Specificity
LARGE:
(trans parts, or in full)
SMALL:
(functions, rules, etc.)
[1] Kusel et al. Reuse in Model-To-Model Transformation
Languages: Are We There Yet? SoSyM, 14(2):537–572, May
2015.

6. www.unamur.be
CONCRETE:
Bound to a specific metamodel / trans language
GENERIC:
Independent of metamodel / trans language
Reuse Dimensions [1]
2
Granularity
Scope
Specificity
LARGE:
(trans parts, or in full)
SMALL:
(functions, rules, etc.)
[1] Kusel et al. Reuse in Model-To-Model Transformation
Languages: Are We There Yet? SoSyM, 14(2):537–572, May
2015.

7. www.unamur.be
CONCRETE:
Bound to a specific metamodel / trans language
GENERIC:
Independent of metamodel / trans language
Reuse Dimensions [1]
2
Granularity
Scope
Specificity
LARGE:
(trans parts, or in full)
SMALL:
(functions, rules, etc.)
Inter:
Reused across many transformations
INTRA:
Reuse inside the same
transformation
[1] Kusel et al. Reuse in Model-To-Model Transformation
Languages: Are We There Yet? SoSyM, 14(2):537–572, May
2015.

8. www.unamur.be
Model Reuse Strategies
• By adapting the
transformation to be
reused
• By adapting the source
metamodel
3
[1] Salay, Rick and Famelis, Michalis and Rubin, Julia and Di Sandro, Alessio and Chechik, Marsha. Lifting Model Transformations To Product Lines. ICSE, 2014.
[2] de Lara, Juan and Guerra, Esther and Cuadrado, Jesus Sanchez.A-posteriori typing for Model-Driven Engineering. MoDELS 2015.
[3] Tisi, Massimo and Jouault, Frédéric and Fraternali, Piero and Ceri, Stefano and Bézivin, Jean. On The Use of Higher-Order Transformations. MDA-FA, 2009.
[4] Guy, Clément and Combemale, Benoît and Derrien, Steven and Steel, James and Jézéquel, Jean-Marc. On Model Subtyping. ECMFA, 2012.
[5] Moha, Naouel and Mahé, Vincent and Barais, Olivier and Jézéquel, Jean-Marc. Generic Model Refactorings. MoDELS 2009.
[6] Sen, Sagar and Moha, Naouel and Mahé, Vincent and Barais, Olivier and Baudry, Benoît and Jézéquel, Jean-Marc. Reusable model transformations. SoSyM, 11(1), 2010.

9. www.unamur.be
Issues [1]
4
[1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):
537–572, May 2015.

10. www.unamur.be
Issues [1]
I1 – Insufficient abstraction from metamodel(s) to support
metamodel-independent reuse
4
[1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):
537–572, May 2015.

11. www.unamur.be
Issues [1]
I1 – Insufficient abstraction from metamodel(s) to support
metamodel-independent reuse
By generalization: decouple transformation logic from type info
By simplification: expose interface; hide realisation
4
[1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):
537–572, May 2015.

12. www.unamur.be
Issues [1]
I1 – Insufficient abstraction from metamodel(s) to support
metamodel-independent reuse
By generalization: decouple transformation logic from type info
By simplification: expose interface; hide realisation
I2 – Lack of repositories for simplifying artifacts selection, at coarse-
(e.g., full transfos) and fine-grained (e.g., functions) levels
4
[1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):
537–572, May 2015.

13. www.unamur.be
Issues [1]
I1 – Insufficient abstraction from metamodel(s) to support
metamodel-independent reuse
By generalization: decouple transformation logic from type info
By simplification: expose interface; hide realisation
I2 – Lack of repositories for simplifying artifacts selection, at coarse-
(e.g., full transfos) and fine-grained (e.g., functions) levels
I3 – Lack of meta-information for selecting appropriate reusable
elements without knowing the transformation’s internal
4
[1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):
537–572, May 2015.

14. www.unamur.be
Issues [1]
I1 – Insufficient abstraction from metamodel(s) to support
metamodel-independent reuse
By generalization: decouple transformation logic from type info
By simplification: expose interface; hide realisation
I2 – Lack of repositories for simplifying artifacts selection, at coarse-
(e.g., full transfos) and fine-grained (e.g., functions) levels
I3 – Lack of meta-information for selecting appropriate reusable
elements without knowing the transformation’s internal
Provide documentation, pre-conditions,
test models, formal requirements, etc
4
[1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):
537–572, May 2015.

15. www.unamur.be
Issues [1]
I1 – Insufficient abstraction from metamodel(s) to support
metamodel-independent reuse
By generalization: decouple transformation logic from type info
By simplification: expose interface; hide realisation
I2 – Lack of repositories for simplifying artifacts selection, at coarse-
(e.g., full transfos) and fine-grained (e.g., functions) levels
I3 – Lack of meta-information for selecting appropriate reusable
elements without knowing the transformation’s internal
Provide documentation, pre-conditions,
test models, formal requirements, etc
4
[1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):
537–572, May 2015.
Systematic reuse is not
there yet

16. 5

17. 5
Systematising model reuse by
adopting a product line
approach

18. www.unamur.be
Variations over an FSM
6
FSM
State Transition
Graph
Vertex Edge
FSM
State Transition
Init Final
Normal
current
FSM
State Transition
time : real
FSM
State Transition

19. www.unamur.be
Variations over an FSM
6
FSM
State Transition
Graph
Vertex Edge
FSM
State Transition
Init Final
Normal
current
FSM
State Transition
time : real
Applicable transformations:
minimize() : FSM
Applicable transformations:
accept() : boolean
Applicable transformations:
wcet() : real
FSM
State Transition

20. www.unamur.be
Variations over an FSM
6
FSM
State Transition
Graph
Vertex Edge
FSM
State Transition
Init Final
Normal
current
FSM
State Transition
time : real
Applicable transformations:
minimize() : FSM
Applicable transformations:
accept() : boolean
Applicable transformations:
wcet() : real
FSM
State Transition
Model Types capture the
FSM
variants, but what
captures the Model Type
Variants ?

21. www.unamur.be
FMT: What’s in a name?
Intent: Do not reinvent the wheel !
Reuse existing techniques as much as possible!
Manage explicitly your language assets
Operate with multi-granularity (both coarse-/fine-grained);
Create repositories of specialised domain assets
Configure your language !
7

22. www.unamur.be 8
FSM
Transition
Init Final
Normal
current
State
time : real
nested
r
h x t
requires
r / minimise() : FSM
r ˄ h / flatten() : HFSM
r ˄ t ˄ x / wcet() : real
r ˄ x / accept() : Boolean
FSM_FMT

23. www.unamur.be
Domain Engineering Activities

24. www.unamur.be
Building FMTs
10

25. www.unamur.be
Building FMTs
Purpose
Define FMT construction approaches:
“Big Bang”: Design FMTs explicitly w.r.t SPL paradigm
“Incremental”: Start from a MT and incrementally add
features and MM elements
10

26. www.unamur.be
Building FMTs
Purpose
Define FMT construction approaches:
“Big Bang”: Design FMTs explicitly w.r.t SPL paradigm
“Incremental”: Start from a MT and incrementally add
features and MM elements
10

27. www.unamur.be
Building FMTs
Purpose
Define FMT construction approaches:
“Big Bang”: Design FMTs explicitly w.r.t SPL paradigm
“Incremental”: Start from a MT and incrementally add
features and MM elements
Challenges: providing construction primitives that support
merging similar elements and features, correct by
construction FMTs, evolution…
10

28. www.unamur.be
Validate FMTs
11

29. www.unamur.be
Validate FMTs
Purpose
11

30. www.unamur.be
Validate FMTs
Purpose
Dealing with FMTs inconsistencies
Structural: conflicting Names, references/ multiplicities
mismatches => Can be addressed with variability-aware type
checking
Semantic: unintended interactions amongst transformations,
transformations not meant to work on hierarchies, …
Can be addressed via SPL testing or verification
11

31. www.unamur.be
Validate FMTs
Purpose
Dealing with FMTs inconsistencies
Structural: conflicting Names, references/ multiplicities
mismatches => Can be addressed with variability-aware type
checking
Semantic: unintended interactions amongst transformations,
transformations not meant to work on hierarchies, …
Can be addressed via SPL testing or verification
Challenges: Scalability of analyses, “verifiability” of
transformations
11

32. www.unamur.be
Application Engineering

33. www.unamur.be
Configure and Derive an MT Product
13

34. www.unamur.be
Configure and Derive an MT Product
Purpose
Configure your DSML the same way you configure your car…
Configurator partially generated from the feature model
Product derivation techniques (e.g. pruning) to build desired
MT automatically
13

35. www.unamur.be
Configure and Derive an MT Product
Purpose
Configure your DSML the same way you configure your car…
Configurator partially generated from the feature model
Product derivation techniques (e.g. pruning) to build desired
MT automatically
Challenges
Partial configuration, user guidance on the relevance of
elements (documentation issues)
13

36. www.unamur.be
Validate MTs
14

37. www.unamur.be
Validate MTs
Purpose
14

38. www.unamur.be
Validate MTs
Purpose
Perform QA activities that are too expensive at the domain
engineering level (e.g. “integration” tests)
14

39. www.unamur.be
Validate MTs
Purpose
Perform QA activities that are too expensive at the domain
engineering level (e.g. “integration” tests)
14

40. www.unamur.be
Validate MTs
Purpose
Perform QA activities that are too expensive at the domain
engineering level (e.g. “integration” tests)
Challenges
Reusing validation artifacts from domain engineering,
validating them (e.g. Mutation Analysis)
14

41. www.unamur.be
Matching and Customising MTS
15

42. www.unamur.be
Matching and Customising MTS
Purpose
15

43. www.unamur.be
Matching and Customising MTS
Purpose
Relating your MT with existing metamodels
15

44. www.unamur.be
Matching and Customising MTS
Purpose
Relating your MT with existing metamodels
Needed if your MT is not a DSML in itself but part of it
15

45. www.unamur.be
Matching and Customising MTS
Purpose
Relating your MT with existing metamodels
Needed if your MT is not a DSML in itself but part of it
For fully derived MTs, existing techniques apply
15

46. www.unamur.be
Matching and Customising MTS
Purpose
Relating your MT with existing metamodels
Needed if your MT is not a DSML in itself but part of it
For fully derived MTs, existing techniques apply
15

47. www.unamur.be
Matching and Customising MTS
Purpose
Relating your MT with existing metamodels
Needed if your MT is not a DSML in itself but part of it
For fully derived MTs, existing techniques apply
Challenges
Dealing with partial MTs => “variability-aware” matching
15

48. www.unamur.be
Conclusion
We proposed a vision leveraging Model Types and Feature
Modelling to support product-line engineering of modelling
languages
FMTs = support to manage reusable MM assets
Wishlist of high-level operations to work with FMTs
16

49. www.unamur.be
Future Work
17