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.
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
6. An extensible set of integrated languages
for embedded software engineering.
„ Specific Languages“
7.
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
16. [Projectional Editing]
Language Composition
L2 L1
Separate Files In One File
Type System
Transformation
Constraints
Type System
Transformation
Constraints
Syntax
IDE
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
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
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!
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
119. Behavior
Functional
functions call other functions.
no state. No aliasing.
write understand debug analyze performance
simple - simple simple
(tree)
good good -
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
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
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
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“)