Architecting 
Domain-Specific Languages 
Markus Völter 
voelter@acm.org 
www.voelter.de 
@markusvoelter
Introduction
more in GPLs more in DSL 
Domain Size large and complex smaller and well-defined 
Designed by guru or committee a few engi...
C 
LEGO Robot 
Control 
Components 
State Machines 
Sensor Access 
General Purpose 
Domain 
Specific
Case Study: 
mbeddr
An extensible set of integrated languages 
for embedded software engineering. 
„ Specific Languages“
Open Source @ eclipse.org 
Eclipse Public License 1.0 
http://mbeddr.com
itemis France: Smart Meter 
First significant mbeddr project 
ca. 100,000 LoC 
about to be finished 
great modularity due ...
ACCEnT 
Control.Lab
20+ Projects in various stages 
by various “Big Name” companies. 
Branching into other domains 
insurance, financial, tax
Open Source 
Apache 2.0 
http://jetbrains.com/mps
[Language Workbench] 
+ Refactorings, Find Usages, Syntax Coloring, Debugging, ...
[Projectional Editing] 
Parsing Projectional Editing
[Projectional Editing] 
Syntactic Flexibility 
Regular Code/Text Mathematical 
Tables Graphical
[Projectional Editing] 
Language Composition 
L2 L1 
Separate Files In One File 
Type System 
Transformation 
Constraints ...
Expressivity
Shorter Programs 
More Accessible 
Semantics
For a limited 
Domain! 
Domain Knowledge 
encapsulated in language
Smaller Domain 
More Specialized Language 
Shorter Programs
The 
do-what-I-want language 
Ѱ
Single Program vs. 
Class/Domain 
No Variability! 
Ѱ
Domain Hierarchy 
more specialized domains 
more specialized languages
Reification 
Dn+1 
Dn 
==
Reification 
== 
Language 
Definition 
Transformation/ 
Generation
C Extensions
Requirements
Linguistic Abstraction 
In-Language 
Abstraction 
Libraries 
Classes 
Frameworks
Linguistic Abstraction 
In-Language 
Abstraction 
User-Definable 
Simpler Language 
Analyzable 
Better IDE Support
Functions 
Components
Linguistic Abstraction 
In-Language 
Abstraction 
User-Definable 
Simpler Language 
Analyzable 
Better IDE Support 
Specia...
Linguistic Abstraction 
Std Lib 
In-Language 
Abstraction
Block Library
Unique State Names 
Unreachable States 
Dead End States 
Guard Decidability 
Exhaustive Search, Proof! 
Reachability
Component Verification 
SM Model Checking
Notation
UI for the language! 
Important for acceptance by users! 
Textual 
Prose 
Symbolic/Math 
Tabular 
Graphical
Reuse existing syntax of 
domain, if any! 
Tools let you freely combine 
all kinds.
Reuse existing syntax of 
domain, if any!
State Machine Tables 
Math 
Component Wiring 
Prose 
Traces
Type System
Static Semantics 
Execution Semantics
Static Semantics 
Execution Semantics
Static Semantics 
Constraints 
Type Systems
Unique State Names 
Unreachable States 
Dead End States 
… 
Example 
Exten 
ded C
Unique State Names 
Unreachable States 
Dead End States 
… 
Easier to do on a declarative Level! 
Example 
Exten 
ded C
Unique State Names 
Unreachable States 
Dead End States 
… 
Easier to do on a declarative Level! 
Thinking of all constrai...
Assign fixed types 
Derive Types 
Calculate Common Types 
Check Type Consistency 
What does a type system do?
Intent + 
Check 
Derive 
More code 
Better error 
messages 
Better Performance 
More convenient 
More complex checkers 
Ha...
Classical C Types 
Closures
Execution
Def: Semantics 
… via mapping to lower level 
OB: Observable Behaviour (Test Cases)
Def: Semantics 
… via mapping to lower level 
LD 
LD-1 
Transformation 
Interpretation
Transformation 
Dn+1 
Dn
LD 
LD-1 
Transformation 
Known Semantics! 
Transformation
LD 
Transformation 
Correct!? Transformation 
LD-1
Transformation 
LD 
LD-1 
Transformation 
Tests (D) 
Tests (D-1) 
Run tests on both levels; all pass. 
Coverage Problem!
mbeddr Tests
Multi-Stage 
L3 
L2 
L1 
L0 
Modularization
Multi-Stage: Reuse 
L3 
L2 
L1 
L0 
Reusing 
Later Stages 
Optimizations! 
L5
Multi-Stage: Reuse 
L3 
L2 
L1 
L0 
L5 
Example 
Exten 
ded C 
Robot Control 
State Machine 
Components 
C (MPS tree) 
C T...
Multi-Stage: Reuse 
L3 
L2 
L1 
L0 
L5 
Example 
Exten 
ded C 
Robot Control 
State Machine 
Consistency 
Model Checking 
...
Multi-Stage: Reuse 
L3 
L2 
L1 
L0 
L1b 
L0b 
Reusing 
Early Stages 
Portability
Multi-Stage: Reuse 
L3 
L2 
L1 
L0 
L1b 
Example 
L0b Exten 
ded C 
Java 
C#
Mock Components
Multi-Stage: Preprocess 
Adding an 
optional, modular emergency 
stop feature
Composite Blocks 
Transformation
Platform
No Platform
Interpretation 
A program at D0 that 
acts on the structure 
of an input program at D>0
Transformation Interpretation 
+ Code Inspection 
+ Debugging 
+ Performance & 
Optimization 
+ Platform Con-formance
Essentially 
Everything :-)
Transformation Interpretation 
+ Code Inspection 
+ Debugging 
+ Performance & 
Optimization 
+ Platform Con-formance 
+ T...
Business Rules 
in Requirements
Def: Semantics 
… via mapping to lower level 
LD 
LD-1 
Transformation 
Interpretation
Multiple Mappings 
… at the same time 
LD 
Lx Ly Lz 
Similar Semantics? 
T 
T T T 
all green!
Multiple Mappings 
… at the same time 
LD 
Lx Ly Lz 
Similar Semantics? 
T 
T T T 
all green!
Multiple Mappings 
… alternatively, selectably 
LD 
Extend LD to include explicit data that 
determines transformation 
Lx...
Multiple Mappings 
… alternatively, selectably 
LD 
External Data: 
- Switches 
- Annotation Model 
Lx Ly Lz
Build Config 
Comp Static Wiring
Separation 
of Concerns
Several Concerns 
… in one domain
Several Concerns 
… in one domain 
integrated into 
one fragment 
separated into 
several fragments
Components + 
Instances
Viewpoints 
independent 
dependent
Viewpoints: Why? 
Sufficiency 
Different Stakeholders 
Different Steps in Process – VCS unit!
Separate 
Requirements
Viewpoints 
independent 
sufficient? 
contains all 
the data for running a meaningful 
transformation
Viewpoints: Why? 
1:n Relationships
Viewpoints 
Well-defined Dependencies 
No Cycles! 
Avoid Synchronization! 
(unless you use a projectional editor)
Sync in 
Comp + Interfaces
Completeness
Can you generate 100% of the code from 
the DSL program? 
More generally: all of D-1
Incomplete: What to do? 
FD 
OB(FD) != FD-1
Incomplete: What to do? 
Manually written code! 
FD 
OB(FD) == FD-1 + FD-1, man
Manually written code? 
Call “black box” code 
(foreign functions)
State Machine 
Event Functions
Manually written code? 
Call “black box” code 
(foreign functions) 
Embed LD-1 code in LD program
All of mbeddr
Manually written code? 
Call “black box” code 
(foreign functions) 
Embed LD-1 code in LD program 
Use composition mechani...
Manually written code? 
Call “black box” code 
(foreign functions) 
Embed LD-1 code in LD program 
Use composition mechani...
Manually written code? 
Call “black box” code 
(foreign functions) 
Embed LD-1 code in LD program 
Use composition mechani...
Roundtripping 
LD 
L’D 
LD-1 ……… 
L’D-1
Roundtripping – Don’t! 
LD 
L’D 
LD-1 ……… 
L’D-1 
Semantic 
Recovery!
Fundamental 
Paradigms
Structure 
Modularization, Visibility 
Namespaces, 
public/private 
importing
Structure 
Modularization, Visibility 
Namespaces, 
public/private 
importing 
divide & conquer 
reuse 
stakeholder integr...
mbeddr Chunks
Structure 
Partitioning (Files) 
VCS Unit 
Unit of sharing 
Unit of IP 
!= logical modules 
may influence language design
MPS models
Structure 
Spec vs. Implementation 
plug in different Impls 
different stakeholders
Interfaces + 
Components
Structure 
Specialization 
Liskov substitution P 
leaving holes (“abstract”)
Structure 
Specialization 
Liskov substitution P 
leaving holes (“abstract”) 
variants (in space) 
evolution (over time)
Components 
Polymorphism
Behavior 
Not all DSLs specify behavior 
Some just declare behavior 
This section is 
not for those!
Behavior 
Imperative 
sequence of statements 
changes program state 
write understand debug analyze performance 
simple si...
C
Behavior 
Functional 
functions call other functions. 
no state. No aliasing. 
write understand debug analyze performance ...
ACCENT Blocks
Behavior 
Functional 
pure expressions are 
a subset of functional 
(operators hard-wired) 
guards 
preconditions 
derived...
Business Rules – 
Debugging
Behavior 
Declarative 
only facts and goals. 
no control flow. 
eval engine, solver (several) 
write understand debug anal...
Behavior 
Declarative 
concurrency 
constraint programming 
solving 
logic programming
Typing Rules
Behavior 
Data Flow 
chained blocks consume continuous data that flows 
from block to block 
write understand debug analyz...
Behavior 
Data Flow 
continuous, calc on change 
quantized, calc on new data 
time triggered, calc every x
Behavior 
Data Flow 
Embedded Programming 
Enterprise ETL & CEP
ACCENT Blocks
Behavior 
State Based 
states, transitions, 
guards, reactions 
event driven, timed 
write understand debug analyze perfor...
State Machines
Behavior 
Combinations 
data flow uses functional, imperative or declarative 
lang inside block
Behavior 
Combinations 
state machines use expressions in guards and often an 
imperative lang in actions
Modularity
Language Modularity, 
Composition and Reuse (LMR&C) 
Behavior 
increase efficiency 
of DSL development 
4 ways of composit...
Language Modularity, 
Composition and Reuse (LMR&C) 
Behavior 
increase efficiency 
of DSL development 
4 ways of composit...
Behavior Dependencies: 
do we have to know about the reuse when designing 
the languages? 
Fragment Structure: 
homogeneou...
Behavior Dependencies & 
Fragment Structure:
Behavior Dependencies & 
Fragment Structure:
RReeffeerreenncciinngg
Referencing 
Dependent 
No containment
Referencing 
Used in Viewpoints
Extension
Dependent 
Containment 
Extension
EExxtteennssiioonn 
more specialized domains 
more specialized languages
Dn+1 
Dn 
== 
Extension
Dn+1 
Dn 
== 
Extension
Good for bottom-up (inductive) domains, and for use by 
technical DSLs (people) 
Dn 
== 
Extension
Extension 
BDerhawavbiaocrks 
tightly bound to base 
potentially hard to analyze 
the combined program
Embedding
EmEbmedbdeidndging
Independent 
Containment 
Embedding
Units in State Machines
Thank you! 
voelter@acm.org 
www.voelter.de 
@markusvoelter
Architecting Domain-Specific Languages
Upcoming SlideShare
Loading in …5
×

Architecting Domain-Specific Languages

914 views

Published on

Architecture DSLs are a useful tool to capture the cornerstones of platform or product line architectures. In addition, interesting analyses can be performed on the models, and much of the infrastructure and configuration code can be generated. On the flip side, these DSLs themselves must be architected consciously: while many architectural abstractions are specific to any given platform or product line, many other aspects are generic and hence can be reused for several architecture DSLs. In this talk I trace how my thinking on architecture modeling has changed over time, and how this is reflected in the architecture DSLs I have built (or helped to build), and how evolving tools have made these changes possible.

Published in: Software
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
914
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Architecting Domain-Specific Languages

  1. 1. Architecting Domain-Specific Languages Markus Völter voelter@acm.org www.voelter.de @markusvoelter
  2. 2. Introduction
  3. 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. 4. C LEGO Robot Control Components State Machines Sensor Access General Purpose Domain Specific
  5. 5. Case Study: mbeddr
  6. 6. An extensible set of integrated languages for embedded software engineering. „ Specific Languages“
  7. 7. Open Source @ eclipse.org Eclipse Public License 1.0 http://mbeddr.com
  8. 8. 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
  9. 9. ACCEnT Control.Lab
  10. 10. 20+ Projects in various stages by various “Big Name” companies. Branching into other domains insurance, financial, tax
  11. 11. Open Source Apache 2.0 http://jetbrains.com/mps
  12. 12. [Language Workbench] + Refactorings, Find Usages, Syntax Coloring, Debugging, ...
  13. 13. [Projectional Editing] Parsing Projectional Editing
  14. 14. [Projectional Editing] Syntactic Flexibility Regular Code/Text Mathematical Tables Graphical
  15. 15. [Projectional Editing] Language Composition L2 L1 Separate Files In One File Type System Transformation Constraints Type System Transformation Constraints Syntax IDE
  16. 16. Expressivity
  17. 17. Shorter Programs More Accessible Semantics
  18. 18. For a limited Domain! Domain Knowledge encapsulated in language
  19. 19. Smaller Domain More Specialized Language Shorter Programs
  20. 20. The do-what-I-want language Ѱ
  21. 21. Single Program vs. Class/Domain No Variability! Ѱ
  22. 22. Domain Hierarchy more specialized domains more specialized languages
  23. 23. Reification Dn+1 Dn ==
  24. 24. Reification == Language Definition Transformation/ Generation
  25. 25. C Extensions
  26. 26. Requirements
  27. 27. Linguistic Abstraction In-Language Abstraction Libraries Classes Frameworks
  28. 28. Linguistic Abstraction In-Language Abstraction User-Definable Simpler Language Analyzable Better IDE Support
  29. 29. Functions Components
  30. 30. Linguistic Abstraction In-Language Abstraction User-Definable Simpler Language Analyzable Better IDE Support Special Treatment!
  31. 31. Linguistic Abstraction Std Lib In-Language Abstraction
  32. 32. Block Library
  33. 33. Unique State Names Unreachable States Dead End States Guard Decidability Exhaustive Search, Proof! Reachability
  34. 34. Component Verification SM Model Checking
  35. 35. Notation
  36. 36. UI for the language! Important for acceptance by users! Textual Prose Symbolic/Math Tabular Graphical
  37. 37. Reuse existing syntax of domain, if any! Tools let you freely combine all kinds.
  38. 38. Reuse existing syntax of domain, if any!
  39. 39. State Machine Tables Math Component Wiring Prose Traces
  40. 40. Type System
  41. 41. Static Semantics Execution Semantics
  42. 42. Static Semantics Execution Semantics
  43. 43. Static Semantics Constraints Type Systems
  44. 44. Unique State Names Unreachable States Dead End States … Example Exten ded C
  45. 45. Unique State Names Unreachable States Dead End States … Easier to do on a declarative Level! Example Exten ded C
  46. 46. 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
  47. 47. Assign fixed types Derive Types Calculate Common Types Check Type Consistency What does a type system do?
  48. 48. Intent + Check Derive More code Better error messages Better Performance More convenient More complex checkers Harder to understand for users
  49. 49. Classical C Types Closures
  50. 50. Execution
  51. 51. Def: Semantics … via mapping to lower level OB: Observable Behaviour (Test Cases)
  52. 52. Def: Semantics … via mapping to lower level LD LD-1 Transformation Interpretation
  53. 53. Transformation Dn+1 Dn
  54. 54. LD LD-1 Transformation Known Semantics! Transformation
  55. 55. LD Transformation Correct!? Transformation LD-1
  56. 56. Transformation LD LD-1 Transformation Tests (D) Tests (D-1) Run tests on both levels; all pass. Coverage Problem!
  57. 57. mbeddr Tests
  58. 58. Multi-Stage L3 L2 L1 L0 Modularization
  59. 59. Multi-Stage: Reuse L3 L2 L1 L0 Reusing Later Stages Optimizations! L5
  60. 60. Multi-Stage: Reuse L3 L2 L1 L0 L5 Example Exten ded C Robot Control State Machine Components C (MPS tree) C Text
  61. 61. 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
  62. 62. Multi-Stage: Reuse L3 L2 L1 L0 L1b L0b Reusing Early Stages Portability
  63. 63. Multi-Stage: Reuse L3 L2 L1 L0 L1b Example L0b Exten ded C Java C#
  64. 64. Mock Components
  65. 65. Multi-Stage: Preprocess Adding an optional, modular emergency stop feature
  66. 66. Composite Blocks Transformation
  67. 67. Platform
  68. 68. No Platform
  69. 69. Interpretation A program at D0 that acts on the structure of an input program at D>0
  70. 70. Transformation Interpretation + Code Inspection + Debugging + Performance & Optimization + Platform Con-formance
  71. 71. Essentially Everything :-)
  72. 72. Transformation Interpretation + Code Inspection + Debugging + Performance & Optimization + Platform Con-formance + Turnaround Time + Runtime Change
  73. 73. Business Rules in Requirements
  74. 74. Def: Semantics … via mapping to lower level LD LD-1 Transformation Interpretation
  75. 75. Multiple Mappings … at the same time LD Lx Ly Lz Similar Semantics? T T T T all green!
  76. 76. Multiple Mappings … at the same time LD Lx Ly Lz Similar Semantics? T T T T all green!
  77. 77. Multiple Mappings … alternatively, selectably LD Extend LD to include explicit data that determines transformation Lx Ly Lz
  78. 78. Multiple Mappings … alternatively, selectably LD External Data: - Switches - Annotation Model Lx Ly Lz
  79. 79. Build Config Comp Static Wiring
  80. 80. Separation of Concerns
  81. 81. Several Concerns … in one domain
  82. 82. Several Concerns … in one domain integrated into one fragment separated into several fragments
  83. 83. Components + Instances
  84. 84. Viewpoints independent dependent
  85. 85. Viewpoints: Why? Sufficiency Different Stakeholders Different Steps in Process – VCS unit!
  86. 86. Separate Requirements
  87. 87. Viewpoints independent sufficient? contains all the data for running a meaningful transformation
  88. 88. Viewpoints: Why? 1:n Relationships
  89. 89. Viewpoints Well-defined Dependencies No Cycles! Avoid Synchronization! (unless you use a projectional editor)
  90. 90. Sync in Comp + Interfaces
  91. 91. Completeness
  92. 92. Can you generate 100% of the code from the DSL program? More generally: all of D-1
  93. 93. Incomplete: What to do? FD OB(FD) != FD-1
  94. 94. Incomplete: What to do? Manually written code! FD OB(FD) == FD-1 + FD-1, man
  95. 95. Manually written code? Call “black box” code (foreign functions)
  96. 96. State Machine Event Functions
  97. 97. Manually written code? Call “black box” code (foreign functions) Embed LD-1 code in LD program
  98. 98. All of mbeddr
  99. 99. 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, …)
  100. 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, …) Use protected regions (if you really have to…)
  101. 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…) DON’T!
  102. 102. Roundtripping LD L’D LD-1 ……… L’D-1
  103. 103. Roundtripping – Don’t! LD L’D LD-1 ……… L’D-1 Semantic Recovery!
  104. 104. Fundamental Paradigms
  105. 105. Structure Modularization, Visibility Namespaces, public/private importing
  106. 106. Structure Modularization, Visibility Namespaces, public/private importing divide & conquer reuse stakeholder integration
  107. 107. mbeddr Chunks
  108. 108. Structure Partitioning (Files) VCS Unit Unit of sharing Unit of IP != logical modules may influence language design
  109. 109. MPS models
  110. 110. Structure Spec vs. Implementation plug in different Impls different stakeholders
  111. 111. Interfaces + Components
  112. 112. Structure Specialization Liskov substitution P leaving holes (“abstract”)
  113. 113. Structure Specialization Liskov substitution P leaving holes (“abstract”) variants (in space) evolution (over time)
  114. 114. Components Polymorphism
  115. 115. Behavior Not all DSLs specify behavior Some just declare behavior This section is not for those!
  116. 116. Behavior Imperative sequence of statements changes program state write understand debug analyze performance simple simple - simple (step) hard good
  117. 117. C
  118. 118. Behavior Functional functions call other functions. no state. No aliasing. write understand debug analyze performance simple - simple simple (tree) good good -
  119. 119. ACCENT Blocks
  120. 120. Behavior Functional pure expressions are a subset of functional (operators hard-wired) guards preconditions derived attributes
  121. 121. Business Rules – Debugging
  122. 122. Behavior Declarative only facts and goals. no control flow. eval engine, solver (several) write understand debug analyze performance simple simple - hard depends often bad
  123. 123. Behavior Declarative concurrency constraint programming solving logic programming
  124. 124. Typing Rules
  125. 125. 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
  126. 126. Behavior Data Flow continuous, calc on change quantized, calc on new data time triggered, calc every x
  127. 127. Behavior Data Flow Embedded Programming Enterprise ETL & CEP
  128. 128. ACCENT Blocks
  129. 129. Behavior State Based states, transitions, guards, reactions event driven, timed write understand debug analyze performance simple - simple/hard s/h simple + can be good
  130. 130. State Machines
  131. 131. Behavior Combinations data flow uses functional, imperative or declarative lang inside block
  132. 132. Behavior Combinations state machines use expressions in guards and often an imperative lang in actions
  133. 133. Modularity
  134. 134. Language Modularity, Composition and Reuse (LMR&C) Behavior increase efficiency of DSL development 4 ways of composition: Referencing Reuse Extension Reuse
  135. 135. Language Modularity, Composition and Reuse (LMR&C) Behavior increase efficiency of DSL development 4 ways of composition: distinguished regarding dependencies and fragment structure
  136. 136. Behavior Dependencies: do we have to know about the reuse when designing the languages? Fragment Structure: homogeneous vs. heterogeneous („mixing languages“)
  137. 137. Behavior Dependencies & Fragment Structure:
  138. 138. Behavior Dependencies & Fragment Structure:
  139. 139. RReeffeerreenncciinngg
  140. 140. Referencing Dependent No containment
  141. 141. Referencing Used in Viewpoints
  142. 142. Extension
  143. 143. Dependent Containment Extension
  144. 144. EExxtteennssiioonn more specialized domains more specialized languages
  145. 145. Dn+1 Dn == Extension
  146. 146. Dn+1 Dn == Extension
  147. 147. Good for bottom-up (inductive) domains, and for use by technical DSLs (people) Dn == Extension
  148. 148. Extension BDerhawavbiaocrks tightly bound to base potentially hard to analyze the combined program
  149. 149. Embedding
  150. 150. EmEbmedbdeidndging
  151. 151. Independent Containment Embedding
  152. 152. Units in State Machines
  153. 153. Thank you! voelter@acm.org www.voelter.de @markusvoelter

×