Domain-specific modelling languages: challenges and opportunities

1. DOMAIN-SPECIFIC
MODELLING LANGUAGES
CHALLENGES AND OPPORTUNITIES
MODELSWARD’2017, Porto
Juan de Lara
Modelling&Software Engineering Research Group
http://miso.es @miso_uam

2. MODEL DRIVEN
ENGINEERING
Increase the level of abstraction in software
development
Models are actively used to
• Describe the problem…
• Simulate/verify/test…
• Generate code for the final application
Move from the solution space (code-centric) to the
problem space
• Higher levels of productivity and quality
• Less accidental details
2

3. MODEL DRIVEN
ENGINEERING
For specific domains
• Avoid coding the same
solutions over and over
• Families of applications
Domain-Specific Modelling
Languages (DSLs) Code
Generator
• Modelling, validation and automatic
generation of telephony services
3

4. MODEL DRIVEN
ENGINEERING
• Code generation from State-Machines
for Railway Signaling Systems
4
Code
generator
For specific domains
• Avoid coding the same
solutions over and over
• Families of applications
Domain-Specific Modelling
Languages (DSLs)

5. MetaEdit+
DOMAIN SPECIFIC
MODELLING LANGUAGES
Describe the structure of the domain
• Relevant primitives and abstractions
• Relations, features
• Explicit expert knowledge
5

6. 6
HOW ARE DSLs BUILT?
Meta-model
design
Modelling
environment
Automatic generation
House Concrete syntax
design
DSL design
DSL
designers
DSL
users
(and creation
of model
transformations)
Typical construction process

7. MODELS AND
META-MODELS
The abstract syntax of DSLs is
defined through a meta-model
• Classes
• Attributes
• Relations
7
Factory meta-model
Machine
Part
Conveyor
Generator Assembler
inps
outs
*
*
* parts
Terminator
1..*
1..*

8. MODELS AND
META-MODELS
The abstract syntax of DSLs is
defined through a meta-model
• Classes
• Attributes
• Relations
8
«conforms to»
c1:Conveyor
g:Generator
a:Assembler
c2:Conveyor
c3:Conveyor t:Terminator
p2: Partp2: Partouts
outs
inps
inps
outs inps
Factory meta-model
Machine
Part
Conveyor
Generator Assembler
inps
outs
*
*
* parts
Terminator
1..*
1..*

9. (GRAPHICAL)
CONCRETE SYNTAX
Mapping of abstract syntax to graphical elements
Usually through models including
• Graphical icons attached to domain primitives
• Palette of the graphical environment
• Actions triggered by these buttons
Compiled vs Interpreted
• Sirius (odesign). Interpreted.
• GMF (graphical, tooling, mapping, generator). Compiled.
• AToM3 (graphics, palette, Python). Compiled.
• …
9

10. (GRAPHICAL)
CONCRETE SYNTAX
Mapping of abstract syntax to graphical elements
Usually through models including
• Graphical icons attached to domain primitives
• Palette of the graphical environment
• Actions triggered by these buttons
Compiled vs Interpreted
• Sirius (odesign, interpreted)
• GMF (graphical, tooling, mapping, generator)
• AToM3 (pre-eclipse era)
10
J. de Lara, H. Vangheluwe. “Defining visual notations and their manipulation through
meta-modelling and graph transformation”. J. Vis. Lang. Comp. 15(3-4): 309-330 (2004)

11. CHALLENGES
Domain expert vs meta-modelling expert
Current DSL construction techniques imply building a meta-model
first
Building meta-models first may not be natural to domain experts
• Classes do not exist in the real world
• Domain experts may be more familiar with examples (objects)
11
How can we engage the domain experts in the
DSL construction?

12. CHALLENGES
Building a usable DSL environment is difficult
• Requires deep expertise in the DSL platform
12
Can we lower the technological complexity of
DSL construction?

13. OPPORTUNITIES
DSLs normally used
• at design time
• in “static” scenarios: desktop computers, laptops
Mobile phones
• Geo services
• Context awareness
• Interaction with other devices
13
Can we extend the use of DSLs beyond design-
time, static scenarios?

14. INDEX
14
Example-based construction of DSLs
Active DSLs
Some reflections
Conclusions and future work

15. 15
Automatic induction
• Abstract syntax (meta-
model)
• Concrete syntax (including
spatial relations)
Modelling tool
• Eclipse
• EMF
• Sirius
Informal
drawing tool
• yED
• Powerpoint
EXAMPLE-BASED PROCESS
domain
experts
domain
experts
metaBUP

16. FEATURES OF THE
PROCESS
Bottom-up
• Examples first
WYDIWYG
• What you draw is what you get
Iterative and Interactive
• Provision of several small fragments
• Each directed to describe a concern of the DSL
16

17. DETAILED PROCESS
17

18. PARSING
18
Sketch
Importer
Sketch
Meta-model
Sketch to
Fragment
Fragment
Meta-model
Dia
yED
Sketch
as model
fragment
Power
point
(textual syntax)

19. MODEL FRAGMENTS
19
Examples of concrete situations, gathering DSL
requirements.
• Can focus on a particular aspect (no need to be complete)
Not just documentation
• Actively used to induce a meta-
model
Graphical (sketches) or
textual syntax (fragment)

20. TEXTUAL SYNTAX
fragment WifiAndDevices {
h : Home {
attr name = “Peter Parker”
@containment
@composition
ref wifiNetwork = w
@containment
@composition
ref mobiles = m
@containment
@composition
ref laptops = l
}
…
20
…
w : WifiNetwork {}
m : MobilePhone {
ref wifi = w
}
l : Laptop {
ref wifi = w
}
}

21. PARSING FRAGMENTS
Drawings are converted to a common meta-model representation
• Open architecture: importers can be added
Legend: annotate graphical elements with their name
21

22. CONCRETE SYNTAX
IN FRAGMENTS
Parsed textual fragments are automatically annotated with
spatial relations
• Containment
• Adjacency
• Overlapping
Reified as references in fragments
Edge styles (lines, decorators) are also extracted as annotations
Fragments can be modified once parsed
• Renaming of references
• Annotations
22
h : Home {
@containment
ref wifiNetwork = w
}
w : WifiNetwork {}

23. INTEGRITY CONSTRAINTS
23
As annotations on different elements
• nodes
• edges
• fields
Domain vs design annotations

24. SOME DOMAIN
ANNOTATIONS
24
MeaningElementAnnotation
@unique
Makes the class a singleton
Sets the attribute as the class id
class
attribute
@acyclic
The reference should have no
cycles
reference
@irreflexive Forbids self-loopsreference
@cycleWith
A given reference must commute
with a set of other references
reference
… ……

25. SOME DESIGN
ANNOTATIONS
25
MeaningElementAnnotation
@general
Pulls common attributes of the class
set to a common super class
class
@general Pulls up the annotated reference
attribute
reference
@composition
Marks the given reference as
composition
reference
@bidirectional
Marks the given reference as
bidirectional
reference
h : Home {
@composition
@containment
ref wifiNetwork = w
}
w : WifiNetwork {}

26. META-MODEL INDUCTION
26
Meta-model update upon
entering a new fragment
• induction algorithm
Annotations in fragments are
transfered to the meta-model
• may trigger refactorings
Conflicts reported and fixed if
possible
sketch
fragment
Meta-
model

27. META-MODEL INDUCTION
27
Meta-model update upon
entering a new fragment
• induction algorithm
Annotations in fragments are
transfered to the meta-model
• may trigger refactorings
Conflicts reported and fixed if
possible
new
sketch
new
fragment Meta-
Model
update

28. INDUCTION ALGORITHM
Create new meta-class for each different object type
in fragment (if class does not exist).
Add new attributes/relation to meta-class for each
new slot/reference in object (if it does not exist).
:A :C
r
A B
r
[a,b] A B
r
[min(a,1),b]
C
BC
existing
meta-model
resulting
meta-model
new fragment
is processed
fragment
:A :C
r
A B
r
[a,b] A B
r
[min(a,1),b]
C
BC
existing
meta-model
resulting
meta-model
new fragment
is processed
fragment
Relations with
same name
pointing to objects
of different type.

29. EXAMPLE
29
fragment WifiAndDevices {
h : Home {
attr name = “Peter P…”
@containment
@composition
ref wifiNetwork = w
@containment
@composition
ref mobiles = m
@containment
@composition
ref laptops = l
}
w : WifiNetwork {}
m : MobilePhone {
@general ref wifi= w
}
l : Laptop { ref wifi = w }
}
Home
name: String
Wifi
Network
Mobile
Phone
Laptop
*wifiNetwork
* *
mobiles
laptops
wifi wifi* *
@containment
@containment
@general
@containment

30. REFACTORINGS
30
The transferred annotations may trigger meta-model
refactorings
Home
name: String
Wifi
Network
Mobile
Phone
Laptop
*wifiNetwork
* *
mobiles
laptops
wifi wifi* *
@containment
@containment
@general
Home
name: String
Wifi
Network
Mobile
Phone
Laptop
*wifiNetwork
* *
mobiles laptops
wifi*@containment
@containment
@general
Device
Extract
superclass
@containment @containment

31. VIRTUAL ASSISTANT
31
Detect places where the meta-model can be
improved and recommend solutions
Structural recommendations
• Inline class
• Pullup features (FCA)
• Generalize references
• Replace class by integer
Style recommendations
• Number conflict, camel case, etc

32. VIRTUAL ASSISTANT
32
Home
name: String
Wifi
Network
Mobile
Phone
Laptop
wifiNetwork
* *
mobiles laptops
wifi
0..1
@containment
@containment
@general
Device
wifi is
singular,
change
* by 1 or
pluralize
*
Home
name: String
Wifi
Network
Mobile
Phone
Laptop
*wifiNetwork
* *
mobiles laptops
wifi*
@containment
@containment
@general
Device

33. VIRTUAL ASSISTANT
33
Home
name: String
Wifi
Network
Mobile
Phone
Laptop
wifiNetworks
* *
mobiles laptops
wifi
0..1
@containment
@containment
@general
Device
wifiNetwork is
singular,
change
* by 1,
or pluralize
*
Home
name: String
Wifi
Network
Mobile
Phone
Laptop
*wifiNetwork
* *
mobiles laptops
wifi*
@containment
@containment
@general
Device

34. GENERATION OF THE
GRAPHICAL ENVIRONMENT
34
Intermediate meta-model for concrete
syntax representation
Transformation into Sirius

35. INTERMEDIATE META-MODEL
35

36. EXAMPLE:
FINAL ENVIRONMENT
36

37. COMPARISON
37
Modelling tool
• Syntax, incl constraints.
• Attributes
• MDE services
Diagramming tool
• No syntax check
• Attributes as labels
• No MDE services

38. METABUP
38
http://miso.es/tools/metaBUP.html

39. 39
Active
DSLs

40. MOTIVATION
DSLs normally used in “static” environments
• Computers
• Laptops
DSL usage can benefit from mobility and context
• DSL for Smart city planning
• DSL for designing touristic routes
Modelling closer to the system being modelled
• On-site modelling
• Geo-location of modelling elements, potos
Make models more active
• Collaboration facilities
• Interaction with external devices
40

41. SCENARIO 1:
MULTI-DEVICE MODELLING
41
Keep models compatible with other devices
Applications
• On-site modelling
• Agile meetings
• Educational domain
• …

42. SCENARIO 2:
MOBILE COLLABORATION
42
Collaboration in mobility
Cannot assume availability of WiFi or Data connectivity
Collaboration protocol
Applications
• Joint model creation
• Model revision
• Model discussion
• …
wind farm

43. SCENARIO 3:
CONTEXT-BASED MODELLING
Use of contextual information
Rules in the DSL to:
• Adapt the modelling environment
• Enable/disable modelling actions
Geo-positioned model elements
Applications
• DSLs for educational ghymkanas
• DSLs for physical exercises
• Domotics
• …
43

44. SCENARIO 4:
ACTIVE DSLs
Contextual DSLs with capabilities to interact with external
devices/services
• Triggered by the user
• Triggered by contextual rules
Applications
• Domotics
• IoT applications
• Active gaming
• …
44

45. REALIZATION:
DSL-COMET
45
http://miso.es/tools/DSL-comet.html
iOS tool
• iPhone
• iPad
Mobile modelling with DSLs
Generation of DSLs environments for
• Eclipse (on top of Sirius)
• iOS
Geopositioned models
Collaboration

46. ARCHITECTURE
46

47. DESCRIBING THE DSL
47

48. DESKTOP
ENVIRONMENT
48

49. MOBILE
ENVIRONMENT
49

50. MODEL SEARCH
50

51. MODEL SHARING
51
Through Drive, Dropbox, etc Tweet your models

52. EXTENDED MODELLING
52
Notes: text, photos, geopositioned Informal drawings, signals

53. COLLABORATION
53
One device is the “server”
• Sets up a local wifi
• Other devices connect
Token-based collaboration protocol

54. GEOPOSITIONED DSLs
54
DSL for creating touristic routes

55. Video
55
https://www.youtube.com/watch?v=rzhl9yMFSxI

56. SOME REFLECTIONS
56
In the future everyone
will be famous for 15
minutes
Andy Warhol

57. SOME REFLECTIONS
57
Felienne Hermans
Leaders of Tomorrow on the Future of Software
Engineering A Roundtable. IEEE Software
March/April 2016
In the future everyone
will be a programmer
for 15 minutes

58. END USER
PROGRAMMING
Programming by non experts
• Spreadsheets
• IFTTT
• code.org
DSLs!
• Example-based definition
• Active DSLs
DSLs in mobiles
• >60% population worldwide own a mobile
• More mobile phones than people in the world
58

59. CONCLUSIONS
DSLs are central to the success of MDE
Make DSL definition easier
• Use of examples
• Derivation of the meta-model
• Synthesis of the graphical DSL environment
Make DSL use more flexible
• In mobility
• Active DSLs
59

60. SOME REFERENCES
Example-based DSL definition
• J. Sánchez Cuadrado, J. de Lara, E. Guerra. “Bottom-Up Meta-Modelling: An
Interactive Approach”. Proc. MoDELS 2012.
• J. J. López-Fernández, J. Sánchez Cuadrado, E. Guerra, J. de Lara.
“Example-driven meta-model development”. Software and System Modeling
14(4): 1323-1347 (2015)
• J.J. López Fernández, A. Garmendia, E. Guerra, J. de Lara. “Example-Based
Generation of Graphical Modelling Environments”. Proc. ECMFA 2016.
Mobile DSLs
• D. Vaquero-Melchor, A. Garmendia, E. Guerra, J. de Lara. “Towards Enabling
Mobile Domain-specific Modelling”. ICSOFT-PT 2016.
• D. Vaquero-Melchor, A. Garmendia, E. Guerra, J. de Lara. “Domain-Specic
Modelling using Mobile Devices”. CCIS Springer 2017.
60

61. THANKS!
Juan.deLara@uam.es
61
http://www.miso.es
@miso_uam
Joint work with E. Guerra, J. J. López, D. Vaquero,
A. Garmendia, J. S. Cuadrado