The goal of this presentation is to help novice metadevelopers with development of domain specific languages (DSLs). To this end, a number of paradigms, techniques and guidelines are introduced. This presentation was given during DSML Design Workshop at the PPL2010 conference that took place on November 17 & 18 at Océ R&D, Venlo, NL.

1. Interactive DSML Design
Andriy Levytskyy | MDD Consultant
Luminis Software Development B.V.
Practical Product Lines 2010
November 17 & 18
Venlo

2. Introduction
• Goal:
DSL
Design:
approach,
pracBcal
techniques
and
guidelines
• Disclaimer:
•
No
100%
subject
coverage,
just
what
works
well
•
Limited
to
Visual
DSMLs
•
TransformaBon
is
briefly
touched
on
2

3. Tutorial Overview
Hands-on
case
1
Basics of Domain Analysis
2
3
Exercise: domain selection, analysis
Language Design
4
5
Exercise: abstract metamodel
Language Implementation
6
5
Exercise: executable metamodel, code generator
Round-up
3

4. Introducing each other
Name:
Company:
Function:
Domain:
Specialization:
Experience with MDD:
Expectations:
4

5. • Paradigm
• Basic Techniques
• Guidelines
• Added value
BASICS OF DOMAIN
ANALYSIS
5

6. Analysis Paradigm
R
Generalization
Entity (E) – concepts
Relationship (R) –
connection among Es
Entity
Generalization –
for sake of the DRY
principle
Business rules – text
notes in KISS style
name
n description
n
R
n
n
name
6

7. Analysis Techniques:
Dictionary
Driver
Motor
Rule of Thumb:
• Nouns are Es
• Verbs are Rs
Steering
wheel
Automobile
Wheel
Sedan
Door
7

8. Analysis Techniques:
Generalization
Full notation
Short-hand
Motor
Motor
has
has
Automobile
Automobile
Automobile
is a
Sedan
Sedan
• Focus on what matters.
• Move repeatable information
away w/o loosing track of it.
8

9. Analysis Techniques:
Multiple Classification (1/2)
Consider a car that
is either personal or
cargo, travels over
water or on land..
Vehicle
Cargo
travel
People
content
General
i za
or discrim tion set
inator
Craft
Land
Generalizations
within a set can’t
be combined.
Automobile
9

10. Analysis Techniques:
Multiple Classification (2/2)
has
People
Cargo
omain rule:
D
Only personal
vehicle have
passenger seats
No need to create concepts
for all possible combinations.
content
n
Passenger
seat
Vehicle
Better expressiveness.
Better display of information.
Rules can be expressed via
structure instead of text.
Automobile
10

11. Analysis Techniques:
Roles (1/4)
Role is a particular aspect or
usage of a concept that is
utilized in a specific context.
Context is the (changing) circumstances
(i.e. other "surrounding" concepts) under
which the concept is being used.
Therefore such a concept can
have several roles.
• Reduction in the number of concepts.
• Enhances expressive power for modeling.
11

12. Dynamic: 1 Object, * Things, * Times
W/O Roles
With Roles
times
Person
Employee
Student
Retiree
Student
Person
Retiree
surroundings
Employee
Man
Husband
Son
Father
Husband
Son
Man
Father
12

13. Reduction Example (3/4)
W/O Roles
has
2
Rear
wheel
Car
With Roles
has
2
Front
wheel
has
has
Car
2
rear
Wheel
2
front
13

14. Expressiveness Example (4/4)
W/O Roles
Car
With Roles
has
has
Car
has 4
Wheel
2
rear
Wheel
2
front
14

15. Analysis Guidelines & Tips
• When stuck ask domain expert for more information
• Apply Law of preservation to extracted information
• Define depth and scope of domain around needs of end users
• Avoid working on domain model from the time/process perspective
• Expose all information visually as entities <= facilitates discussion
• Use multiple classification over role if:
• Classifications are exclusive
• Roles need to be more prominent.
• Entities have no properties nor attributes (except for Name)
• Resist tendency of putting info in business rules/comments
• Use Wikipedia for generic vocabularies/classifications
• Avoid large diagrams
• Iterate analysis-modeling-review until the model:
• Consistent, adequate, has no gaps, “feels” right
15

16. Added value
Great intro
Finally an overview!
Trainee
Developer
Domain
Expert
Domain Model
Great DSL
concepts!!!
Meta-developer
The more uses, "
le DSL..
the more sustainab
el.
The most stable mod
odel,
The less abstract m
and
the less uses it has,
the less stable it is.
I clearly see
variability
Software
Architect
16

17. • Choose a domain
• Extract concepts
• Organize concepts
• Review
EXERCISE: DOMAIN ANALYSIS
17

18. • What is language?
• Paradigm
• Guidelines
LANGUAGE DESIGN
18

19. What is a Metamodel?
1
Car
A language definition comprised of:
§ concepts and their interrelations
(abstract syntax)
§ form (concrete syntax):
2
rear
2
Wheel
front
*
Ø Textual
Ø Graphical
Ø Combination
§ meaning (semantics):
*
Ø Often realized via transformation
19

20. Design Paradigm
Analysis
Design
n
Entity
Syntax
name
description
Good languages:
• ER
• Class Diagrams
Entity
name
attributes
description
Constraint
n
20

21. Design Guidelines & Tips
• Stay consistent with domain model
• Focus on variability/configuration and “mass” production
• Do not focus on aspects (leave it to transformations)
• Use generalization
• No multiple classifications => entities or properties
• No roles => entities or properties
• Add administrative attributes, such as id, version, title, etc..
• No constructors, no interface definitions, no XML, no Java, etc..
• Consider breaking the domain model into multiple DSLs based on:
• high cohesion and low coupling of concepts
• different change frequency of concepts instances
21

22. • Translate domain model to DSL design(s)
• Choose additional semantic domain, e.g. HTML
• How your concepts are related to the semantic domain?
EXERCISE: DSL DESIGN
22

23. • Tool Selection
• AToM3 Introduction
LANGUAGE
IMPLEMENTATION
23

24. Tool Selection
Selection guidelines:
• No meaningful guidelines exist
• My advice: Choose tools that are as close to design paradigm as
possible (raise level of abstraction)
Skipped Candidates:
✘Eclipse based tools
✘Tools from industry heavyweights (IBM, Microsoft, Borland)
✘Popular DSL tools
(Would not fit into the allocated time or will spend time clicking/typing
in many dialogue windows)
24

25. AToM3
25

26. DSL Specification In
AToM3
AToM3Object
cardinality
attributes
constraints
appearance
Abstract syntax – ER
paradigm
Rules/constraints –
python language
AToM3Object
Entity
name
n description
Concrete Syntax –
simple vector editor
Semantics – GG based
transformation system
n
AToM3Object
n
n
Relationship
26

27. • Translate DSL design to AToM3 metamodel
• Making a simple generator (e.g. for HTML)
• Test-drive of the DSL
EXERCISE:
DSL IMPLEMENTATION
27

28. • DSLs: Familiar and Different
• A few bad practices
• References
• Any questions?
ROUND-UP
28

29. DSLs are Familiar..
• DSL development is a software development process
• DSL is a very special, but still a software system
• Status quo: DSL development still done at PSM (i.e. coding/3GLs)
• With all consequences
• All best practices from SE apply here as well:
• Good analysis
• Modeling to raise abstraction
• Modeling architectures (e.g. MDA’s CIM/PIM/PSM), etc..
29

30. .. And Yet Different
• Clients do not know domain concepts <= agile
• Metamodels are more domain-driven <= good domain analysis
• No one wants a vendor lock <= CIM/PIM/PSM/
• DSLs are very specific systems <= automate DSL development
Best SE pract
ices
are even mor
e
important wit
h
DSLs!
30

31. A Few Bad Practices
• Lack of domain understanding
• Too generic/too specific
• Letting the tool dictate language analysis design
• Failing to consider the language’s real-life usage
• Top/down and bottom/up confusion => inflexible MDD
• and more (see [3])…
31

32. References
[1] Eric Evans. Domain-Driven Design: Tacking Complexity In the
Heart of Software. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 2003.
[2] Martin Fowler and Kendall Scott. UML Distilled: A Brief Guide to
the Standard Object Modeling Language. Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, 3rd edition, 2003.
[3] Steven Kelly and Risto Pohjonen. Worst Practices for DomainSpecific Modeling. IEEE Software, vol. 26, no. 4, pp. 22-29, July/
Aug. 2009. doi:10.1109/MS.2009.109
[4] Steven Kelly and Juha-Pekka Tolvanen, Domain-Specific
Modeling, enabling full code generation, Wiley-Blackwell, 2008.
32

33. http://lsd.luminis.eu
andriy.levytskyy@luminis.eu
http://nl.linkedin.com/in/andriylevytskyy
http://lsd.luminis.eu/tag/mdd/
http://twitter.com/levytsky
33