The document discusses the architecture and design of domain-specific languages (DSLs), contrasting them with general-purpose languages in terms of complexity, community, lifespan, and evolution. It provides a case study on 'mbeddr', highlighting its extensible set of integrated languages for embedded software engineering and its applications across various industries. Key aspects include modularity, language composition, behavior specification, and challenges like state machine management and semantic recovery.

1. Architecting
Domain-Specific Languages
Markus Völter
voelter@acm.org
www.voelter.de
@markusvoelter

2. Introduction

3. more in GPLs more in DSL
Domain Size large and complex smaller and well-defined
Designed by guru or committee a few engineers and domain experts
Language Size large small
Turing-completeness almost always often not
User Community large, anonymous and widespread small, accessible and local
In-language abstraction sophisticated limited
Lifespan years to decades months to years (driven by context)
Evolution slow, often standardized fast-paced
Incompatible Changes almost impossible feasible

4. C
LEGO Robot
Control
Components
State Machines
Sensor Access
General Purpose
Domain
Specific

5. Case Study:
mbeddr

6. An extensible set of integrated languages
for embedded software engineering.
„ Specific Languages“

8. Open Source @ eclipse.org
Eclipse Public License 1.0
http://mbeddr.com

9. itemis France: Smart Meter
First significant mbeddr project
ca. 100,000 LoC
about to be finished
great modularity due to components
uses physical units extensively
great test coverage due to special extensions

10. ACCEnT
Control.Lab

11. 20+ Projects in various stages
by various “Big Name” companies.
Branching into other domains
insurance, financial, tax

12. Open Source
Apache 2.0
http://jetbrains.com/mps

13. [Language Workbench]
+ Refactorings, Find Usages, Syntax Coloring, Debugging, ...

14. [Projectional Editing]
Parsing Projectional Editing

15. [Projectional Editing]
Syntactic Flexibility
Regular Code/Text Mathematical
Tables Graphical

16. [Projectional Editing]
Language Composition
L2 L1
Separate Files In One File
Type System
Transformation
Constraints
Type System
Transformation
Constraints
Syntax
IDE

17. Expressivity

18. Shorter Programs
More Accessible
Semantics

19. For a limited
Domain!
Domain Knowledge
encapsulated in language

20. Smaller Domain
More Specialized Language
Shorter Programs

21. The
do-what-I-want language
Ѱ

22. Single Program vs.
Class/Domain
No Variability!
Ѱ

23. Domain Hierarchy
more specialized domains
more specialized languages

24. Reification
Dn+1
Dn
==

25. Reification
==
Language
Definition
Transformation/
Generation

26. C Extensions

27. Requirements

28. Linguistic Abstraction
In-Language
Abstraction
Libraries
Classes
Frameworks

29. Linguistic Abstraction
In-Language
Abstraction
User-Definable
Simpler Language
Analyzable
Better IDE Support

30. Functions
Components

31. Linguistic Abstraction
In-Language
Abstraction
User-Definable
Simpler Language
Analyzable
Better IDE Support
Special
Treatment!

32. Linguistic Abstraction
Std Lib
In-Language
Abstraction

33. Block Library

34. Unique State Names
Unreachable States
Dead End States
Guard Decidability
Exhaustive Search, Proof!
Reachability

35. Component Verification
SM Model Checking

36. Notation

37. UI for the language!
Important for acceptance by users!
Textual
Prose
Symbolic/Math
Tabular
Graphical

38. Reuse existing syntax of
domain, if any!
Tools let you freely combine
all kinds.

39. Reuse existing syntax of
domain, if any!

40. State Machine Tables
Math
Component Wiring
Prose
Traces

41. Type System

42. Static Semantics
Execution Semantics

43. Static Semantics
Execution Semantics

44. Static Semantics
Constraints
Type Systems

45. Unique State Names
Unreachable States
Dead End States
…
Example
Exten
ded C

46. Unique State Names
Unreachable States
Dead End States
…
Easier to do on a declarative Level!
Example
Exten
ded C

47. Unique State Names
Unreachable States
Dead End States
…
Easier to do on a declarative Level!
Thinking of all constraints is a coverage
problem! Exten
Example
ded C

48. Assign fixed types
Derive Types
Calculate Common Types
Check Type Consistency
What does a type system do?

49. Intent +
Check
Derive
More code
Better error
messages
Better Performance
More convenient
More complex checkers
Harder to understand for users

50. Classical C Types
Closures

51. Execution

52. Def: Semantics
… via mapping to lower level
OB: Observable Behaviour (Test Cases)

53. Def: Semantics
… via mapping to lower level
LD
LD-1
Transformation
Interpretation

54. Transformation
Dn+1
Dn

55. LD
LD-1
Transformation
Known Semantics!
Transformation

56. LD
Transformation
Correct!? Transformation
LD-1

57. Transformation
LD
LD-1
Transformation
Tests (D)
Tests (D-1)
Run tests on both levels; all pass.
Coverage Problem!

58. mbeddr Tests

59. Multi-Stage
L3
L2
L1
L0
Modularization

60. Multi-Stage: Reuse
L3
L2
L1
L0
Reusing
Later Stages
Optimizations!
L5

61. Multi-Stage: Reuse
L3
L2
L1
L0
L5
Example
Exten
ded C
Robot Control
State Machine
Components
C (MPS tree)
C Text

62. Multi-Stage: Reuse
L3
L2
L1
L0
L5
Example
Exten
ded C
Robot Control
State Machine
Consistency
Model Checking
Components
Efficient Mappings
C Type System
C (MPS tree)
Syntactic
Correctness,
Headers
C Text

63. Multi-Stage: Reuse
L3
L2
L1
L0
L1b
L0b
Reusing
Early Stages
Portability

64. Multi-Stage: Reuse
L3
L2
L1
L0
L1b
Example
L0b Exten
ded C
Java
C#

65. Mock Components

66. Multi-Stage: Preprocess
Adding an
optional, modular emergency
stop feature

67. Composite Blocks
Transformation

68. Platform

69. No Platform

70. Interpretation
A program at D0 that
acts on the structure
of an input program at D>0

71. Transformation Interpretation
+ Code Inspection
+ Debugging
+ Performance &
Optimization
+ Platform Con-formance

72. Essentially
Everything :-)

73. Transformation Interpretation
+ Code Inspection
+ Debugging
+ Performance &
Optimization
+ Platform Con-formance
+ Turnaround Time
+ Runtime Change

74. Business Rules
in Requirements

75. Def: Semantics
… via mapping to lower level
LD
LD-1
Transformation
Interpretation

76. Multiple Mappings
… at the same time
LD
Lx Ly Lz
Similar Semantics?
T
T T T
all green!

77. Multiple Mappings
… at the same time
LD
Lx Ly Lz
Similar Semantics?
T
T T T
all green!

78. Multiple Mappings
… alternatively, selectably
LD
Extend LD to include explicit data that
determines transformation
Lx Ly Lz

79. Multiple Mappings
… alternatively, selectably
LD
External Data:
- Switches
- Annotation Model
Lx Ly Lz

80. Build Config
Comp Static Wiring

81. Separation
of Concerns

82. Several Concerns
… in one domain

83. Several Concerns
… in one domain
integrated into
one fragment
separated into
several fragments

84. Components +
Instances

85. Viewpoints
independent
dependent

86. Viewpoints: Why?
Sufficiency
Different Stakeholders
Different Steps in Process – VCS unit!

87. Separate
Requirements

88. Viewpoints
independent
sufficient?
contains all
the data for running a meaningful
transformation

89. Viewpoints: Why?
1:n Relationships

90. Viewpoints
Well-defined Dependencies
No Cycles!
Avoid Synchronization!
(unless you use a projectional editor)

91. Sync in
Comp + Interfaces

92. Completeness

93. Can you generate 100% of the code from
the DSL program?
More generally: all of D-1

94. Incomplete: What to do?
FD
OB(FD) != FD-1

95. Incomplete: What to do?
Manually written code!
FD
OB(FD) == FD-1 + FD-1, man

96. Manually written code?
Call “black box” code
(foreign functions)

97. State Machine
Event Functions

98. Manually written code?
Call “black box” code
(foreign functions)
Embed LD-1 code in LD program

99. All of mbeddr

100. Manually written code?
Call “black box” code
(foreign functions)
Embed LD-1 code in LD program
Use composition mechanisms of LD-1 (inheritance, patterns,
aspects, …)

101. Manually written code?
Call “black box” code
(foreign functions)
Embed LD-1 code in LD program
Use composition mechanisms of LD-1 (inheritance, patterns,
aspects, …)
Use protected regions (if you really have to…)

102. Manually written code?
Call “black box” code
(foreign functions)
Embed LD-1 code in LD program
Use composition mechanisms of LD-1 (inheritance, patterns,
aspects, …)
Use protected regions (if you really have to…) DON’T!

103. Roundtripping
LD
L’D
LD-1 ………
L’D-1

104. Roundtripping – Don’t!
LD
L’D
LD-1 ………
L’D-1
Semantic
Recovery!

105. Fundamental
Paradigms

106. Structure
Modularization, Visibility
Namespaces,
public/private
importing

107. Structure
Modularization, Visibility
Namespaces,
public/private
importing
divide & conquer
reuse
stakeholder integration

108. mbeddr Chunks

109. Structure
Partitioning (Files)
VCS Unit
Unit of sharing
Unit of IP
!= logical modules
may influence language design

110. MPS models

111. Structure
Spec vs. Implementation
plug in different Impls
different stakeholders

112. Interfaces +
Components

113. Structure
Specialization
Liskov substitution P
leaving holes (“abstract”)

114. Structure
Specialization
Liskov substitution P
leaving holes (“abstract”)
variants (in space)
evolution (over time)

115. Components
Polymorphism

116. Behavior
Not all DSLs specify behavior
Some just declare behavior
This section is
not for those!

117. Behavior
Imperative
sequence of statements
changes program state
write understand debug analyze performance
simple simple - simple
(step)
hard good

118. C

119. Behavior
Functional
functions call other functions.
no state. No aliasing.
write understand debug analyze performance
simple - simple simple
(tree)
good good -

120. ACCENT Blocks

121. Behavior
Functional
pure expressions are
a subset of functional
(operators hard-wired)
guards
preconditions
derived attributes

122. Business Rules –
Debugging

123. Behavior
Declarative
only facts and goals.
no control flow.
eval engine, solver (several)
write understand debug analyze performance
simple simple - hard depends often bad

124. Behavior
Declarative
concurrency
constraint programming
solving
logic programming

125. Typing Rules

126. Behavior
Data Flow
chained blocks consume continuous data that flows
from block to block
write understand debug analyze performance
simple - simple/hard hard simple can be good

127. Behavior
Data Flow
continuous, calc on change
quantized, calc on new data
time triggered, calc every x

128. Behavior
Data Flow
Embedded Programming
Enterprise ETL & CEP

129. ACCENT Blocks

130. Behavior
State Based
states, transitions,
guards, reactions
event driven, timed
write understand debug analyze performance
simple - simple/hard s/h simple + can be good

131. State Machines

132. Behavior
Combinations
data flow uses functional, imperative or declarative
lang inside block

133. Behavior
Combinations
state machines use expressions in guards and often an
imperative lang in actions

134. Modularity

135. Language Modularity,
Composition and Reuse (LMR&C)
Behavior
increase efficiency
of DSL development
4 ways of composition:
Referencing
Reuse
Extension
Reuse

136. Language Modularity,
Composition and Reuse (LMR&C)
Behavior
increase efficiency
of DSL development
4 ways of composition:
distinguished regarding
dependencies and fragment
structure

137. Behavior Dependencies:
do we have to know about the reuse when designing
the languages?
Fragment Structure:
homogeneous vs. heterogeneous
(„mixing languages“)

138. Behavior Dependencies &
Fragment Structure:

139. Behavior Dependencies &
Fragment Structure:

140. RReeffeerreenncciinngg

141. Referencing
Dependent
No containment

142. Referencing
Used in Viewpoints

143. Extension

144. Dependent
Containment
Extension

145. EExxtteennssiioonn
more specialized domains
more specialized languages

146. Dn+1
Dn
==
Extension

147. Dn+1
Dn
==
Extension

148. Good for bottom-up (inductive) domains, and for use by
technical DSLs (people)
Dn
==
Extension

149. Extension
BDerhawavbiaocrks
tightly bound to base
potentially hard to analyze
the combined program

150. Embedding

151. EmEbmedbdeidndging

152. Independent
Containment
Embedding

153. Units in State Machines

154. Thank you!
voelter@acm.org
www.voelter.de
@markusvoelter