This document discusses approaches for constructing domain-specific modeling languages (DSMLs). It presents both a top-down approach, which begins with defining a meta-model, and a bottom-up approach, which starts by drafting example models and then inducing a meta-model. The bottom-up approach aims to facilitate DSML construction by non-experts by allowing them to provide model fragments from which a meta-model is constructed. Annotations on the fragments can trigger refactorings to the meta-model. Open issues that arise are also recorded to aid resolution.

1. CONSTRUCTING DOMAIN
SPECIFIC MODELLING
LANGUAGES FOR MODEL
DRIVEN ENGINEERING
Esther Guerra, Juan de Lara
modelling&software engineering
research grouphttp://www.miso.es

2. Model-Driven Engineering (MDE)
• Introduction
• Current Challenges in Defining DSMLs
Top-down approach
Bottom-up approach
Conclusions and open lines
AGENDA
2

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

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

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

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

7. DOMAIN SPECIFIC
MODELLING LANGUAGES
DSMLs need not be graphical…
xText
7

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

9. MODELS AND
META-MODELS
The abstract syntax of DSMLs is
defined through a meta-model
• Classes
• Attributes
• Relations
9
«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..*

10. OCL CONSTRAINTS
10
Object Constraint Language
Well-formedness rules, which
every model should satisfy
Based on First-Order Logic
g:Generator
«conforms to»
c:Conveyor
Factory meta-model
Machine
Part
Conveyor
Generator Assembler
inps
outs
*
*
* parts
Terminator
1..*
1..*
Factory meta-model
Machine
Part
Conveyor
Generator Assembler
inps
outs
*
*
* parts
Terminator
1..*
1..*
context Generator inv:
self.inps->isEmpty() and self.outs->size()>0
context Generator inv:
self.inps->isEmpty() and self.outs->size()>0
context Terminator inv:
self.outs->isEmpty() and self.inps->size()>0
context Assembler inv:
self.inps->size()>0 and self.outs.size()>0
…
inps

11. MODELS AND
META-MODELS
Models are represented using
concrete syntax
• Visual
• Textual
No need for a 1-1 correspondence
between abstract and concrete
syntax elements
11
asse

12. MODEL
TRANSFORMATIONS
Models need to be manipulated for
• Simulation
• Optimization/refactoring
• Generating another model
• Generating code
in-place
transformations
12
…

13. MODEL
TRANSFORMATIONS
Models need to be manipulated for
• Simulation
• Optimization/refactoring
• Generating another model
• Generating code
Source
Target
13
model-to-model
transformations

14. MODEL
TRANSFORMATIONS
Models need to be manipulated for
• Simulation
• Optimization/refactoring
• Generating another model
• Generating code
14
MMsrc MMtar
Msrc Mtar
Transformation
definition
from to
«conforms to» «conforms to»
Transformation
execution
Transformation
developer
Final user
model-to-model
transformations

15. MODEL
TRANSFORMATIONS
Models need to be manipulated for
• Simulation
• Optimization/refactoring
• Generating another model
• Generating code
15
Template languages
query and
model navigation

16. Some DSML
creation
challenges
16

17. DSML CONSTRUCTION
PROCESS
17
Meta-model
design
Modelling
environment
Automatic generation
House Concrete syntax
design
DSML design
DSML
designers
DSML
users
( and creation
of model
transformations )

18. MOTIVATION
18
Many DSML construction environments exist nowadays
But:
• Do not focus on scalable DSMLs
• The definition of every DSML has to start from scratch
• Difficult, technical tasks (hampers involvement of domain experts)
• No systematic process for DSML construction
• Do not cover the whole lifecycle of DSML development
 Xtext
 EMFText
 Spoofax
 MPS
 MetaEdit+
 Sirius
 GMF
 Eugenia
Graphical Textual

19. OUR APPROACHES
Top-down
• Meta-model first
• Reusability by means of patterns
• Pattern to specify model
fragmentation strategies
19
1
2 Patterns

20. OUR APPROACHES
Top-down
• Meta-model first
• Reusability by means of patterns
• Pattern to specify model
fragmentation strategies
Bottom-up
• Start from examples
• Improve the involvement of domain
experts
20
1
2
2
1
3
Patterns

21. Model-Driven Engineering (MDE).
Top-down approach
Bottom-up approach
Conclusions and open lines
AGENDA
21

22. WHAT’S IN A META-MODEL?
22
Do different meta-models share features?
• If so, generalize those and make them reusable
• For example, common abstractions for behavioural languages:
• State-machine
• Workflow
• ..
Analysis of ATL meta-model repository
• 305 meta-models

23. WHAT’S IN A META-MODEL?
23

24. TYPES OF PATTERNS
Domain
• Characterize families of DSMLs (e.g., workflow, state machines)
Design
• Concrete meta-model design
Infrastructure
• Services of the modelling environment (filtering, model fragmentation)
Dynamic semantic patterns
• Participant roles in different styles of semantics (Petri nets, event-
based, etc)
24

25. PATTERNS
Structure
• Like a meta-model
• Fine-grained variability through
roles
Variability
• Pattern variants
• Feature model
25
StateMachine
StateVertex
*states
name: String
Transition
name: String
*
source
target
outgoing
incoming
*
*
Simple
State
Final
State Event
trigger 0..1
Initial
State
transitions
0..1 0..1
0..1
Services
• Code generation
• Components that contribute functionality to the modelling
environment

26. APPLYING A PATTERN
26

27. MODULARITY PATTERN
27
Customize a fragmentation strategy for a DSL
Generate a modelling
environment that organizes:
• A model as a project (root
class as “Project”)
• Folders associated to classes
tagged as “Package”
• Units (files) for elements in a
container object tagged as
“Unit”

28. APPLYING AN
INFRASTRUCTURE PATTERN
28
Container
extension@1: String
*
Project
contents
modularity pattern
Containee
Package Unit 0..*0..*
meta-model
Component
@Component
@Unit
StateMachine
@StateMachine
@Unit
WTComponents
@Project
Subsystem
@Package
Control
Subsystem
@Package
*
*
*
*
extension=“state”
extension=“figcom”
*
1..*
Hierarchical
Organization 0..5
Model
Injector
Model
Descriptor
EditorTab

29. 29
Project root
:WTComponents
sysId=“EmbSys”
version=2
model=“Dynamic”
Package
:SubSystem
name=“comp-sys”
description =“verified”
Unit
: Component
:Port :Port
cross-reference
cross-reference
Package
:SubSystem
name=“plant-sys”
description =“beta”
cross-reference
EmbSys
plant-sys
comp-sysname=“comp1”
comp1
[Eclipse project]
[folder]
[folder]
[file]
Modular model
Physical deployment
APPLYING AN
INFRASTRUCTURE PATTERN

30. REALIZATION
DSL-TAO
30
An Eclipse plugin
• http://miso.es/tools/DSLtao.html
• EU project MONDO http://mondo-
project.org
• Open source
Catalogue of patterns
• Domain
• Concrete syntax
• Infrastructure
• Can contribute their own wizard
DSL tao
Modularity Filter
Hierarchical
Organization
EditorTab
Filtering
ModelConsumer
generated DSML environment
DSML meta-model
…
pattern
occurrence
patterns catalogue
pattern
occurrence
code generation

31. 31

32. 32

33. 33

34. CUSTOM WIZARD
(GRAPHICAL PATTERN)
34
Selection of heuristics

35. 35
Selection of representation for elements
CUSTOM WIZARD
(GRAPHICAL PATTERN)

36. 36
Customization of graphical elements
CUSTOM WIZARD
(GRAPHICAL PATTERN)

37. RESULTING TOOL
37
Sirius-based
editor
Fragmented
model as a
project

38. Model-Driven Engineering (MDE).
Top-down approach
Bottom-up approach
Conclusions and open lines
AGENDA
38

39. Facilitate the construction of DSLs by non-experts
There is currently a gap
• domain experts have the knowledge of the domain...
• but lack the expertise to build meta-models.
Drafting example models first might be more
intuituive…
…but current MDE environments require the existence
of a meta-model.
MOTIVATION
39

40. Facilitate the construction of DSLs by non-experts
There is currently a gap
• Domain experts have the knowledge of the domain...
• but lack the expertise to build meta-models.
Drafting example models first might be more
intuituive…
…but current MDE environments require the existence
of a meta-model.
MOTIVATION
40
domain
experts
fragments
meta-model
induction

41. Fragment-n
Neutral
Meta-
Model
Fragment-2
Fragment-1
Fragment-n
+
induction
refactorings
Conformance
Checking &
Reporting
2
3
4
import
5
7
Model-to-model
Transformation
Visual
Language
Compilation into
implementation
meta-models
1
…
Technical Spaces
Domain
experts
Engineer
EMF
Textual
Language
Meta
Depth
Purpose
of use
Model-to-model
Transformation
Visual
Language
Textual
Language
Construction phase Validation
phase
Test suite
6Fragment-n
Neutral
Meta-
Model
Fragment-2
Fragment-1
Fragment-n
+
induction
refactorings
Conformance
Checking &
Reporting
2
3
4
import
5
7
Model-to-model
Transformation
Visual
Language
Compilation into
implementation
meta-models
1
…
Technical Spaces
Domain
experts
Engineer
EMF
Textual
Language
Meta
Depth
Purpose
of use
Model-to-model
Transformation
Visual
Language
Textual
Language
Construction phase Validation
phase
Test suite
6
BOTTOM-UP META-MODELLING

42. MODEL FRAGMENTS
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

43. fragment edu1 {
c : Course {
attr name = "Design Project"
attr course = 2
attr semester = 2
ref coordinator = p1
}
g1 : Group {
attr code = "PADS221"
attr shift = "morning"
ref course = c
}
…
…
g2 : Group {
attr code = "PADS226"
attr shift = "afternoon"
ref course = c
}
p1 : Professor {
attr name = "Juan"
ref teaches = g1
}
p2 : Professor {
attr name = "Eduardo"
ref teaches = g2
}
}
MODEL FRAGMENTS
textual syntax

44. LEGEND
44
Also a sketch
Assigns meaning to
icons
• Redundancy (on
purpose). Different
icons with same
meaning.

45. ANNOTATIONS
Provide an insight on some aspect of the fragment
• domain annotations: normally by the domain expert (in sketch)
• design annotations: normally by the engineer (in textual notation)
Impact on the meta-model
• Trigger refactorings
• Produce integrity constraints

46. fragment edu1 {
c : Course {
attr name = "Design Project"
attr course = 2
attr semester = 2
@cycleWith(teaches,course)
ref coordinator = p1
}
g1 : Group {
attr code = "PADS221"
attr shift = "morning"
ref course = c
}
…
…
g2 : Group {
attr code = "PADS226"
attr shift = "afternoon"
ref course = c
}
p1 : Professor {
attr name = "Juan"
ref teaches = g1
}
p2 : Professor {
attr name = "Eduardo"
ref teaches = g2
}
}
ANNOTATIONS
textual syntax

47. …
MeaningElement
ANNOTATIONS
some annotations
Domain Annotation
@unique
Makes the class a singleton
Sets the attribute as the class id
class
attribute
@irreflexive Forbids self-loopsreference
@cycleWith
A given reference must commute
with a set of other references
reference
MeaningElementDesign Annotation
@general
Pulls common attributes of the class
set to a common super class
class
@general Pulls up the annotated reference
attribute
reference
@composition Marks a reference as compositionreference

48. BOTTOM-UP META-MODEL
CONSTRUCTION
Meta-model update upon entering a new fragment
using induction algorithm.
Annotations in a fragment are transfered to the meta-
model, which may trigger refactorings.
Conflicts (e.g., assignment of non-compatible types
for same field) are reported and fixed if possible.

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

50. INDUCTION ALGORITHM
example
50
fragment edu3 {
c: Course{ ref calendar = ca }
@container(w)
ca : Calendar{ ref week = w }
@container(tc1, tc2, lc)
w: Week{
attr weekNumber = 1
ref elements = tc1, tc2, lc
}
tc1 : TheoryClass{
@general ref topics = t
}
tc2 : TheoryClass{ ref topics = t }
lc : LabClass{ ref topics = t }
t: Topic { attr topic= "Design patterns"}
}

51. INDUCTION ALGORITHM
example
51
fragment edu3 {
c: Course{ ref calendar = ca }
@container(w)
ca : Calendar{ ref week = w }
@container(tc1, tc2, lc)
w: Week{
attr weekNumber = 1
ref elements = tc1, tc2, lc
}
tc1 : TheoryClass{
@general ref topics = t
}
tc2 : TheoryClass{ ref topics = t }
lc : LabClass{ ref topics = t }
t: Topic { attr topic= "Design patterns"}
}

52. REFACTORINGS
The transferred annotations may trigger meta-model
refactorings
52

53. REFACTORINGS
The transferred annotations may trigger meta-model
refactorings
53

54. VIRTUAL ASSISTANT
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
54

55. OPEN ISSUES
Alternatives recorded as “open issues”
• Conflict. Fragment specifying contradictory
information (e.g. different types for an attribute).
• Automatic. Naming of added classes.
Resolution of an open issue may break the
conformance of previous fragments
• Non-breaking and breaking and resolvable
• Preferred by the algorithm
• Breaking and unresolvable
• Provide additional information to keep the conformance
• Discard fragments
55

56. COMPILATION
56

57. TOOL SUPPORT
57
http://www.miso.es/tools/metaBUP.html

58. TOOL SUPPORT
58
http://www.miso.es/tools/metaBUP.html

59. ANOTHER EXAMPLE
59

60. ANOTHER EXAMPLE:
SPATIAL RELATIONSHIPS
60
containment
overlapping
adjacency

61. ANOTHER EXAMPLE:
METABUP
61

62. ANOTHER EXAMPLE:
GENERATED DSL ENVIRONMENT
62

63. Model-Driven Engineering (MDE)
Top-down approach
Bottom-up approach
Conclusions and open lines
AGENDA
63

64. CONCLUSIONS
MDE accelerates software development process
(for specific domains)
DSMLs oriented to particular domains
Constructing environments for DSMLs is time
consuming
• Top-down (pattern-based)
• Bottom-up (example-based)
64

65. OPEN LINES
Flexible modelling
• Informal modelling (early stages)
• Formality (late stages)
Mobility and Context
• DSL-comet
• Available in app Store
65

66. THANKS!
Questions?
66
http://www.miso.es
modelling&software engineering
research group
Esther Guerra, Juan de Lara
{Esther.Guerra, Juan.deLara}@uam.es
Joint work with: Jesús Juan López, Ana Pescador,
Antonio Garmendia, Jesús Sánchez Cuadrado