Post on 09-Mar-2018
11.08.2011
1
Model-DrivenDevelopment and DSLs
in the context of embedded sytems
Markus VoelterIndependent/itemis
voelter@acm.org
A little HistoryDomain Specific LanguagesExamplesToolsBenefitsArchitecture DSLsA more theoretical ViewProgramming and ModelingThe LWES ProjectBonus: Best Practices
11.08.2011
2
A little History
programming
close to the hardwarestarted
abstractionscomputing
chips
11.08.2011
3
abstractionscomputing
bits
C
abstractionscomputing
11.08.2011
4
Java
abstractionscomputing?
SQL
abstractionscomputing?
11.08.2011
5
11.08.2011
6
general purpose
domain specific
11.08.2011
7
effective++
specialized, limited
used by experts
together with otherspecialized tools
tailor made
Domain Specific Languages
11.08.2011
8
DSLA DSL is a focussed, processable
language for describing a specific
concern when building a system in a
specific domain. The abstractions and
notations used are natural/suitable for
the stakeholders who specify that
particular concern.
map
11.08.2011
9
DSL Program
GPL Program
(aka Model)
map
automated!
map
GenerationTransformationCompilation
Interpretation
11.08.2011
10
Analysing DomainsDefining Languages
Activities
Building EditorsTransforming ModelsBuilding Generators
Building Frameworks
Adapting/Selecting
… and using all of that to build apps
11.08.2011
11
internal
external
vs.
compiled
interpreted
vs.
11.08.2011
12
customization
configuration
vs.
graphical
textual
vs.
11.08.2011
13
Examples
Example 1:
Embedded Protocol Handler
11.08.2011
14
SOLU
TIO
NComponent Specification
SOLU
TIO
N
Message Format Definition
11.08.2011
15
tests
refines
SOLU
TIO
NTesting
TOO
LS
Eclipse ModelingEclipse Xtext
11.08.2011
16
Example 2:
Pension Fund SpecificationSO
LUTI
ON
Textual Documentation
11.08.2011
17
SOLU
TIO
NInsurance Mathematics
SOLU
TIO
N
Calculation Rules and Tests
11.08.2011
18
TOO
LS
Intentional Software‘s Domain Workbench
Example 3:
Radar Systems Engineering
11.08.2011
19
SOLU
TIO
NComponent Definition
SOLU
TIO
N
Component Behavior Specification
11.08.2011
20
SOLU
TIO
NResulting System Behaviour
SOLU
TIO
N
Analysis
11.08.2011
21
TOO
LS
Eclipse ModelingEclipse XtextWolfram MathematicaMathematica Workbench
Example 4:
Alarm System Menus
11.08.2011
22
SOLU
TIO
NMenu Structure
SOLU
TIO
N
Software Components
11.08.2011
23
TOO
LS
Eclipse ModelingEclipse Xtext
Example 5:
Requirements Tracability
11.08.2011
24
SOLU
TIO
NImported Requirements
SOLU
TIO
N
Program Code with Annotations (green)
11.08.2011
25
SOLU
TIO
NSelecting from the Requirements
Find Usages of Requirements
TOO
LS
JetBrains MPS
11.08.2011
26
Example 5:
OSGi-based SystemSO
LUTI
ON
Component Specification
11.08.2011
27
SOLU
TIO
NComponent Specification
SOLU
TIO
N
Component Specification
11.08.2011
28
TOO
LS
Eclipse ModelingEclipse Xtext
Example 6:
Math, Science and Java
11.08.2011
29
SOLU
TIO
NSO
LUTI
ON
11.08.2011
30
SOLU
TIO
NTO
OLS
JetBrains MPS
11.08.2011
31
Example 7:
FountainsC
ON
TEX
T
11.08.2011
32
SOLU
TIO
NHardware Structure
SOLU
TIO
N
Behaviour
11.08.2011
33
SOLU
TIO
NPlus:
In-IDE SimulatorUnit Test Support
TOO
LS
Eclipse ModelingEclipse Xtext
11.08.2011
34
More Examples8:
MiscellaneousD
OM
AIN
Hearing Aids
11.08.2011
35
DO
MA
INRefrigerators
SOLU
TIO
N
BPEL Designer
11.08.2011
36
SOLU
TIO
NBlock Diagrams
SOLU
TIO
N
PLC Programming
11.08.2011
37
SOLU
TIO
NState Charts
TOO
LS
11.08.2011
38
Tools
Tooling!Editor, Debugger, Testing, Groupware, Scalable, „All in Eclipse“
11.08.2011
39
Tools Tooling
Language Definition Tools
Editor FrameworksTransformation Languages
Code Generation Tools
abstract syntax, concrete syntax, constraints
11.08.2011
40
Current Version 2.0:improved performance
Xbase: expressions for reuse
Xtend2: „Better Java“, with support
for Xpand-like templates
Eclipse-based, Eclipse ProjectVery flexible, very popular!
Open Source (EPL)
11.08.2011
41
Open Source (Apache 2.0)Projectional EditorVery good at lang. CompositionCurrent Version 2.0:
Improved performance
Unified generate/compile/build
Debug MPS in MPS
Tables in the editor
(Diagrams planned for 2.1)
Commercial Tool.Projectional EditorVery flexible notationsVersion 1.8 is current
11.08.2011
42
Way More:SpoofaxRascaloomegaThe Whole Platform
see alsohttp://languageworkbenches.net
Benefits
11.08.2011
43
Automationfaster, deterministic
Increased Qualitywell defined structures allthrough the system
11.08.2011
44
Meaningful Validationmore semantics in the model
CaptureDomain Knowledge
formalized into languages and models
11.08.2011
45
Suitable Notationstextual, graphical, tabular
Technology Independencegenerate „technology glue code“
11.08.2011
46
Abstraction w/oRuntime Overhead
generator „optimizes away“
Implementation StrategyCapture
in the generators
11.08.2011
47
Everything is a modelincluding for example hardware (some) hardware
Architecture DSLs
11.08.2011
48
AirportManagement
System
MonitorsWebsite
Aircraft-Module
Data Center
11.08.2011
49
component DelayCalculator {}
component InfoScreen {}
component AircraftModule {}
component DelayCalculator {
provides IDelayCalculator
requires IInfoScreen
}
component InfoScreen {
provides IInfoScreen
}
component AircraftModule {
provides IAircraftModule
requires IDelayCalculator
}
interface IDelayCalculator {}
interface IInfoScreen {}
interface IAircraftModule {}
11.08.2011
50
component InfoScreen {
provides IInfoScreen
}
instance screen1: InfoScreen
instance screen2: InfoScreen
…
component DelayCalculator {
provides default: IDelayCalculator
requires screens[0..n]: IInfoScreen
}
component InfoScreen {
provides default: IInfoScreen
}
component AircraftModule {
provides default: IAircraftModule
requires calculator[1]: IDelayCalculator
}
11.08.2011
51
component DelayCalculator {
provides aircraft: IAircraftStatus
provides managementConsole:
IManagementConsole
requires screens[0..n]: IInfoScreen
}
component Manager {
requires backend[1]: IManagementConsole
}
component InfoScreen {
provides default: IInfoScreen
}
component AircraftModule {
requires calculator[1]: IAircraftStatus
}
component DelayCalculator {
requires screens[0..n]: IInfoScreen
…
}
component InfoScreen {
provides default: IInfoScreen
}
instance dc: DelayCalculator
instance screen1: InfoScreen
instance screen2: InfoScreen
connect dc.screens
to (screen1.default, screen2.default)
11.08.2011
52
namespace com.mycompany.production {
instance dc: DelayCalculator
// InfoScreen instances are created and
// started in other configurations
dynamic connect dc.screens every 60 query {
type = IInfoScreen
status = active
}
}
interface IAircraftStatus {
oneway message reportPosition
(aircraft: ID, pos: Position )
request-reply message reportProblem {
request (aircraft: ID, problem: Problem,
comment: String)
reply (repairProcedure: ID)
}
}
11.08.2011
53
struct FlightInfo {
from: Airport
to: Airport
scheduled: Time
expected: Time
…
}
replicated singleton flights {
flights: FlightInfo[]
}
component DelayCalculator {
publishes flights
}
component InfoScreen {
consumes flights
}
interface IAircraftStatus {
oneway message registerAircraft(aircraft: ID! )
oneway message unregisterAircraft(aircraft: ID! )
oneway message reportPosition(aircraft: ID!,
pos: Position! )
request-reply message reportProblem {
request (aircraft: ID!, problem: Problem!,
comment: String!)
reply (repairProcedure: !ID)
}
protocol initial = new {
state new {
registerAircraft => registered
}
state registered {
unregisterAircraft => new
reportPosition
reportProblem
}
}
}
11.08.2011
54
As youunderstandand develop
yourArchitecture…
Develop a language toexpress it!
11.08.2011
55
Language resemblesarchitectural concepts
We express theapplication(s) with
the language.
11.08.2011
56
Architecture
DSL
Clear Understandingfrom building the
language
11.08.2011
57
UnambigiousVocabulary
Concepts independentfrom Technology
11.08.2011
58
Programming Model canbe defined based on
Conceptual Arcitecture
Architecture „executable“(i.e. more than rules and docs)
11.08.2011
59
Since we alreadyhave a formal model….
Generate APIMaps Architectural Concepts to
Implementation language (non-trivial!)
Implementation Code
ProgrammingModel API
Runtime Infrastructure(Platform/Middleware)
Glue Code
11.08.2011
60
ImplementationImplementation only depends on
the generated programming model API
Implementation Code
ProgrammingModel API
Runtime Infrastructure(Platform/Middleware)
Glue Code
Programming ModelGenerated API + Usage Idioms
Completely Technology-Independent
Implementation Code
ProgrammingModel API
Runtime Infrastructure(Platform/Middleware)
Glue Code
11.08.2011
61
Runtime InfrastructureSelect based on fit wrt. to architectural
concepts and non-functional requirements
Implementation Code
ProgrammingModel API
Runtime Infrastructure(Platform/Middleware)
Glue Code
Glue CodeAka Technology Mapping CodeMaps API to selected platform
Implementation Code
ProgrammingModel API
Runtime Infrastructure(Platform/Middleware)
Glue Code
11.08.2011
62
Glue CodeContains Configuration Files for Platform
Might require „mix in models“
Implementation Code
ProgrammingModel API
Runtime Infrastructure(Platform/Middleware)
Glue Code
Several PlatformsDifferent Platforms, not Languages
Support for Scaling (non-functional req)
Implementation Code
ProgrammingModel API
Runtime Infrastructure(Platform/Middleware)
Glue Code
Platform 2
Glue Code 2
Testing!
11.08.2011
63
Formal ArchitectureDescription is not new:
ADLs, UML
But all of those useexisting, generic
languages!
11.08.2011
64
Thismisses
thepoint!
Trying to express your specificarchitecture with predefined
abstractions is not useful!
11.08.2011
65
You want to build a languageto capture your own
architectural abstractions asyour learn things.
Where arestandards
useful?
11.08.2011
66
People haveto learn
architecturalconcepts anyway.
Is UML with a profilestill a
standardlanguage?
11.08.2011
67
On whichmeta level do
I want tostandardize?M2 (UML), M3 (MOF)?
Isn‘t a DSLbased on MOFas „standard“
as a profilebased on
UML?
11.08.2011
68
UML Profiles instead?You‘ll think more aboutUML-ities than your ownconcepts
UML Profiles instead?Tool integration issues(repository, diff/merge, versioning)
11.08.2011
69
UML Profiles instead?Tools are often complex, heavyweight, bloated. Acceptance limited.
UML Generally Useless?No. UML can be used fordocumentation(sequence diagrams, eg)
11.08.2011
70
A more theoretical View
Do
mai
n S
pe
cifi
cLa
ngu
age
s A DSL is a focussed, processable
language for describing a specific
concern when building a system in a
specific domain. The abstractions and
notations used are natural/suitable for
the stakeholders who specify that
particular concern.
11.08.2011
71
What‘s the Problem here?Li
ngu
isti
cA
bst
ract
ion
What‘s the Problem here?
Lin
guis
tic
Ab
stra
ctio
n
Much better with new linguistic abstraction
No sophisticated analysis required to understand the semantics of a contructand treat it “correctly”.
11.08.2011
72
What‘s this? And what‘s the Problem?Li
ngu
isti
cA
bst
ract
ion
Much better!
Lin
guis
tic
Ab
stra
ctio
n
11.08.2011
73
Much better!Li
ngu
isti
cA
bst
ract
ion
Do
mai
ns
are
Hie
rarc
hic
al
11.08.2011
74
Cre
atin
gLi
ngu
isti
cA
bst
ract
ion
sD
om
ain
Sp
eci
fic
Lan
guag
es
A DSL is a language at D that provides
linguistic abstractions for common
patterns and idioms of a language at
D-1 when used within the domain D.
A good DSL does not require the use of
patterns and idioms to express
semantically interesting concepts in D.
Processing tools do not have to do
“semantic recovery” on D programs.
11.08.2011
75
Exte
nsi
on
vs.
Cas
cad
ing
Programming and
Modeling
11.08.2011
76
Modeling
… (Mostly) GraphicalNotations
… Abstract Syntax Storage
… Projecting Editors
… Different editableviews for model
Programming
… (Mostly) Textual Notations
… Concrete Syntax Storage
… (Fancy) ASCII Editors
… Read-Only Visualizations
Whythe difference?
11.08.2011
77
Programmingthe way we do
Modeling?
Modelingthe way we do
Programming?
Modeling Programming
Programming Modeling
====
11.08.2011
78
We don‘t want to
we want tomodel,
program!… at different levels of abstaction
… from different viewpoints
… integrated!
We don‘t want to
we want tomodel,
program!… with different degrees of
… with suitable notations
… with suitable expressiveness
domain-specificity
11.08.2011
79
We don‘t want to
we want tomodel,
program!
precise and tool processableAnd always:
Programming Languages
are not
enough.MODULAR
11.08.2011
80
Programming Languages
are not
enough.COMPOSABLE
Programming Languages
are not
enough.CONFIGURABLE
11.08.2011
81
Programming Languages
are not
enough.ADAPTABLE
Programming Language Syntax
is not
enough.FLEXIBLE
11.08.2011
82
L
ab
c
d
e
f
gh
i
j
k
m
n
o
with many first class concepts!
Big Language?
L
Small Language?
and poweful conceptswith a few, orthogonal
11.08.2011
83
my L
a b c
d e f
g h i
j k l
Modular Language
composable conceptswith many optional,
Like frameworksand libraries,
but with syntaxand IDE support
Modular Language
11.08.2011
84
Seve
ralC
on
cern
sin
a D
om
ain
Vie
wp
oin
ts
11.08.2011
85
Vie
wp
oin
ts
A: mixedB: separate Viewpoints
Lan
guga
eC
om
bin
atio
n
When DSL (for several concerns) are developed from scratch, as a group, then dependencies between the concerns can be materialized as dependencies between the languages and the language concepts
11.08.2011
86
Lan
guga
eEx
ten
sio
n
A language B extends another language A if B contains additional language concepts. This means that for programs written in B, all concepts from A are available, plus those defined in B.
Lan
guga
eR
eu
se
A language has been developed to be used in contexts not known at the time of development. No dependencies allowed! The reusable language has to be extended so it can reference concepts from languages in that context.
11.08.2011
87
Lan
guga
eEm
be
dd
ing
Composition is a special case ofreuse, where the reused language is syntactically embedded into languages from the context.
The LWES Project
11.08.2011
88
LWESLanguage Workbenches
for
http://mbeddr.com
Embedded Systems
LWESLanguage Workbenches
for
http://mbeddr.com
Embedded Systems
Incremental Extension of Cwith DSLs for Embedded Systems,integrated with Formal Methodsand support for PLE andRequirements Tracing
11.08.2011
89
LWESLanguage Workbenches
for
http://mbeddr.com
Embedded Systems
LWESLanguage Workbenches
for
http://mbeddr.com
Embedded Systems
11.08.2011
90
EXA
MP
LE C
ASE
SOLU
TIO
N
11.08.2011
91
SOLU
TIO
NSO
LUTI
ON
11.08.2011
92
TOO
LS
JetBrains MPS
mbeddr.com
11.08.2011
93
Bonus:
Best Practices
Limit Expressiveness
11.08.2011
94
Notation, Notation, Notation
Graphical vs. Textual
11.08.2011
95
Viewpoints
Teamwork Support
11.08.2011
96
Interpretation Generation
vs.
Rich Domain Specific Platform
11.08.2011
97
Checks Firstand Separate
Cascading
11.08.2011
98
Annotation Models
Don‘t forgetTesting
11.08.2011
99
Iterate!
Co-Evolve Language and Concepts
11.08.2011
100
Domain UsersProgramming?
CompatibleOrganization
11.08.2011
101
web email twitter
xinglinkedin
www.voelter.devoelter@acm.orgmarkusvoelter
http://www.xing.com/profile/Markus_Voelterhttp://www.linkedin.com/pub/0/377/a31
.coordinates
THE END.