Sioux Hot-or-Not: Model Driven Software Development (Markus Voelter)
-
Upload
siouxhotornot -
Category
Technology
-
view
3.159 -
download
3
Transcript of Sioux Hot-or-Not: Model Driven Software Development (Markus Voelter)
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 1 -
Markus Vö[email protected]
Model-DrivenSoftware Development
Hot or Not?
www.mdsd-buch.de
www.mdsd-book.org
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 2 -
Markus Vö[email protected]
www.voelter.de
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 3 -
Markus Vö[email protected]
www.voelter.de
I work as an independent consultant/coach/trainer…
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 4 -
Markus Vö[email protected]
www.voelter.de
… for software technology and engineering …
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 5 -
Markus Vö[email protected]
www.voelter.de
… I focus on software architecture, …
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 6 -
Markus Vö[email protected]
www.voelter.de
… middleware, …
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 7 -
Markus Vö[email protected]
www.voelter.de
… and model-driven software development.
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 8 -
Markus Vö[email protected]
www.voelter.de
I have written a number of books…
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 9 -
Markus Vö[email protected]
www.voelter.de
… regularly speak on conferences …
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 10 -
Markus Vö[email protected]
www.voelter.de
… and I am an eclipse.org comitter for openArchitectureWare
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 11 -
Markus Vö[email protected]
www.voelter.de
I am also founder and editor ofsoftware engineering radio
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 12 -
Markus Vö[email protected]
www.voelter.de
More information is available at www.voelter.de…
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 13 -
Markus Vö[email protected]
www.voelter.de
and on my blog at voelter.de/blog
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 14 -
Markus Vö[email protected]
www.voelter.de
I am based in Heidenheim, Germany
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 15 -
Markus Vö[email protected]
www.voelter.de
And in my spare time I fly my glider…
About me
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 16 -
C O N T E N T S
Part 1: Theory
Part 2: Practice
Part 3: Q&A
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 17 -
Model-Driven Development
• Model Driven Development is about making software development more domain-related as opposed to computing related. It is also about making software development in a certain domain more efficient.
Software TechnologyConcepts
Domain Concepts
Software TechnologyConcepts
Domain Concepts
mental workof developers
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 18 -
How MDSD works
• Developer develops model(s)based on certain metamodel(s), expressed using a DSL.
• Using code generation templates, the model is transformed to executable code.• Alternative: Interpretation
• Optionally, the generated code is merged with manually written code.
• One or more model-to-model transformation steps may precede code generation.
ModelModelModel
Transformer TranformationRules
Model
TransformerCode
GenerationTemplates
Generated CodeManuallyWrittenCode
optional
Metamodel
Metamodel
optio
nal,
can
be
repe
ated
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 19 -
Reasons for DDD
• Software Development is too complex and too expensive (now, this is a really new finding ) …
… because:• There is too little reuse• Technology changes faster than developers can learn • Knowledge and practices are hardly captured explicitly
and made available for reuse• Domain experts cannot understand all the technology
stuff involved in software development
• DDD aims at attacking some of these problems.We shall see how on the following slides.
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 20 -
What is a „Domain“
• A definition could be:
A domain is a bounded area of knowledge or interest.
• Examples (from the world of Software) include:• eBanking• Embedded Software• Web-Based eBusiness Applications• Control Software for 4-Cylinder Diesel Engines• Astronomical Image Processing Software
• Domains can have varios „scopes“ as well as various „flavours“ – see next slides.
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 21 -
MDSD Core Concepts
Model
DomainSpecific
Language
Metamodeltextual
graphical
Domain
Ontology
bounded area ofknowlege/interest
semantics
precise/executable
multiple
partial
viewpoint
subdomains
composable
Metametamodeltarget
softwarearchitecture
softwarearchitecture
transform
compile
interpret
multi-step
single-step
noroundtrip
knowledge
several
designexpertise
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 22 -
Example 1: Model and Metamodel
interface Sensor { operation start():void; operation stop():void; operation measure():float;}interface Controller { operation reportProblem(Sensor s, String errorDesc ):void;}
*
{ordered}Interface
name : Stringtype : String
Operation
name : Stringtype : String
Parameter
type : String
Exception**
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 23 -
Example 2: Model (J2ME apps)
NumberEntryForm
a: Number ["a"] {a>0}b: Number ["b"] {b>0}
CalcResultDisplay
["The Result is "+c]{align=center}
["Abort"]
["Result"]
>> a,b c: Number;c = a + b
>> c
["Again"] ["Exit"]
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 24 -
Example 2: Metamodel (J2ME apps)
name : String
UIElement
Form
label : Stringconstraints: String
Display
varName : Stringlabel : Stringconstraints: String
Field
Flow
transportedVars: String
AutoFlow
label : StringtransportedVars: String
Button
Element
Start End
declaredVars: Stringexpression : String
Calculation
1 to
1 from
outbound*
inbound*
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 25 -
Example 5: Power Grid
SomePlace: Generator
G11: GenerationElement
20KV: Bus
link11
T11: Transformer
link12
220KV: Buslink13end11
link14
SomeOtherPlace: SwitchingStation
end21
transmissionLine1
B21-220KV: Bus
link21
B22-10KV: Bus
T21: Transformer
link22
link23
link24
end22
SomePlace:Generator
SomeOtherPlace:SwitchingStation
end11 end21 end22
transmissionLine1
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 26 -
Example 5: Power Grid Metamodel
GenerationElement
MicroNode Link1 targetNode sources 0..*
1 sourceNode targets 0..*
Transformer Bus Endpoint
MacroNodeTransmission
Line
1 targetNode sources 0..*
1 sourceNode targets 0..*
0..*parts
Generator BranchPoint SwitchingStation
sourceEndPoint 1 1 targetEndPoint
targetTransmissionLine 0..1 0..1 sourceTransmissionLine
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 27 -
MDSD Core Values
• We prefer to validate software-under-construction over validating software requirements
• We work with domain-specific assets, which can be anything from models, components, frameworks, generators, to languages and techniques.
• We strive to automate software construction from domain models; therefore we consciously distinguish between building software factories and building software applications
• We support the emergence of supply chains for software development, which implies domain-specific specialization and enables mass customization
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 28 -
MDA and Model Driven Software Development Overview
Model
DomainSpecific
Language
Metamodeltextual
graphical
Domain
Ontology
bounded area ofknowlege/interest
semantics
precise/executable
multiple
partial
viewpoint
subdomains
composable
Metametamodel
transform
compile
interpret
multi-step
single-step
noroundtrip
UML+Profiles
MOF
OCL, Action Semantics
PIM, PSM, .... QVT
several targetsoftware
architecturesoftware
architecture
Applicationdesignexpertise
• Focus: Platform Independence, (Tool) Interop
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 29 -
Other related approaches
• Microsoft’s Software Factories:Focus on Reuse, Efficient Development, DSLs
• Domain-Specific (Visual) Modelling:Focus on (Visual) DSLs
• Generative Programming:Focus on Efficiency, “Automatic Manufactoring”, Software System Families
• Language-Oriented Programming:Focus on DSLs instead of Frameworks, incl. Editor/Debugger Support
all basically the same
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 30 -
MDSD and Agility
• Agile Manifesto:We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
• MDSD-Models are no „paperwork“, they are the code which is translated to code automatically
• Agility does not oppose tools in general – compilers are ok, model transformers are a kind of compiler
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 31 -
MDSD and Agility II
• Project automation (ant, cruisecontrol) is ok in „agile minds“, so is automation of the writing of repetitive code
• Automation of the development process makes responding to change easier and faster (single source principle). • Changes in the model respond to changes in the functional
requirements• Changes in the templates/transformations can be used to
evolve the architecture
• The customer on-site can be integrated better, if we have languages that are better related to domain concepts as opposed to 3GL code or the like.• Pair programming between developer and domain expert is
more realistic.
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 32 -
MDSD and Agility III
• Tests can still be written manually (even before generation), generators can help is building mocks or scenarios
• We do not recommend a waterfall that first builds generators and then builds apps, rather, both are iteratively evolved in parallel. • Domains Architectures are based on experience, not
based on „big design upfront“
• Developers can do what they can do best:• Some deal with applications and customer requirements,• Others deal with technical architecture, platforms and
generators
• So: There is no problem with Agility and MDSD!
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 33 -
Reasons for using MDSD
• You want to provide a way for your domain-experts to formally specify their knowledge, and to provide a way for your technology people to define how this is implemented (using model transformations).
• You might want to provide different implementations (i.e. more concrete models) for the same model, perhaps because you want to run it on different platforms (.NET, Java, CORBA).
• You may want to capture knowledge about the domain, the technology, and their mapping in a clear, uncluttered format.
• In general, you don’t want to bother with implementation details when specifying your functionality.
• MDSD results in a fan-out, i.e. one set of models can be the source for transformations to several targets.
• Another reason for using MDSD: You are working in the context of product lines and software system families and need to develop domain-specific assets.
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 34 -
MDSD Benefits I
• Models are free of implementation artifacts – they directly represent domain knowledge and are thus reusable.
• Implementations for various platforms can be generated in principle – the technology change problem is adressed to some extend.
• Technology freaks and domain experts can take care of „their business“ (transformations and models, respectively) and need to care of each other‘s problems only in a limited way.
• Domain experts can play a direct role in development since they can more easily understand models expressed with a DSL as opposed to implementation code.
Domain Experts play the central role they deserve!
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 35 -
MDSD Benefits II
• Development becomes more efficient since repetitive implementation code can be generated automatically.
• Architectural contraints/rules/patterns can more easily be enforced, since the they are embedded in the templates rather than just being documented (and ignored).
This is especially important in really large teams, often in the context of Product-Line Engineering and Software System Families.
• Transformer/Generator can address cross-cutting concerns (just like an aspect weaver)
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 36 -
MDSD Predjudices
• MDSD does not require UML – any kind of modelling language is ok, graphical or textual
• Precise and complete models…• … are not the the same as „visualized code“ – the
abstraction level is higher• … are not the same as analysis models – analysis models
are not computational
• MDSD does not require – not even recommend – a waterfall. Development of the generative infrastructure is iterative and incremental.
• You do not need big and expensive tools – a lot of small and useful open source tools are available.
• You don‘t need to generate 100% of the code – it is ok, to also code some aspects in a 3GL.
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 37 -
Benefits for Software Quality
• MDSD requires an explicit, well-defined architecture. Defining an architecture this way improves the quality of the system (indpendent of whether it is generated or not).
• Transformations capture expert knowledge. The generated code reflects this expert knowledge uniformly.
• An Domain Archtitecture defines a strict programming model for the manually developed parts – again, uniformity and constrained-ness improves quality.
• Generator does not produce accidental errors – either things are always right or always wrong. This makes finding errors easier!
• Models can serve as an up-to-date and always current documentation.
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 38 -
Benefits for Software Quality II
• In general, MDSD forces you to take care of many good things, which you‘d like to have in any application development project:
• Domain/Application Scoping
• Variability Management
• Well-Defined Software Architecture, Architecture Metamodelling
• Trying to build a generator for a domain/target architecture enables your understanding of the domain/target architecture. This in itself is a huge benefit.
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 39 -
No Free Lunch - Challenges
• You need additional skills in your team (domain analysis , metamodelling, generator development, architecture)
You need a couple of good people who usually aren‘t easy to get, and who aren‘t cheap.
• Your development process needs to reflect the two-track nature of MDSD (domain architecture development, application development)
• Sometimes tools require some „creative use“ and improvisation ( use open source!)
• Remember: a fool with a tool is still a fool
generator
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 40 -
MDSD (compared to “normal” Software Development)
Level of Detail
Result ofAnalysis
virtual or realImplementation model Implementation
Info
rmat
ion
Gai
n
Start
GoalImplementation
Analysis
Design
Effort
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 41 -
MDSD Effort (stage 1)
Level of Detail
Results ofAnalysis
virtual or realimplementation model Implementation
Info
rmat
ion
Gai
n
Start
GoalImplemen-
tation
Analys
is
Effort
Modell
ing
Automation
Savings based onthe use of a semantically
rich platform
Savingsbecause
of Generation
A
A' B
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 42 -
MDSD Effort (stage 2)
Level of Detail
Results ofAnalysis
virtual or realimplementation model Implementation
Info
rmat
ion
Gai
n
Start
Goal
Analy
sis
Effort
Mod
ellin
g
Automation
Savings based onthe use of a semantically
rich platform
Savingsbecause
of generation
A
BA'
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 43 -
UML Tools as DSL editors
• If you want to use a UML tool as the editor for you DSL, the DSL must be mapped onto a UML profile, i.e. a set of• Stereotypes,• Tagged values, and • Constraints
• Pros:• Easy to implement• (Looks like a) standard• More or less acceptable export format (XMI)• Model Management features (searching, paritioning…)• Integration into the tool suite (versioning, etc.), if provided
by the UML tool and indeed necessary
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 44 -
UML Tools as DSL editors II
• Cons:• Graphical Features are very limited (especially, data-
dependent graphics!)• Constraints cannot be checked in real time (this may
change over time – tool vendors improve!)• You cannot „remove“ UML semantics completely (try to
draw a line between two attributes…).• You always have to use the complete UML tool – complex
UI
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 45 -
Editor Alternatives: Developing a Custom Tool
• Pros:• Typically, quite powerful graphics features• No inherited features forced upon you by the tool• Only valid concrete syntax is possible• Constraints can be checked in realtime• Tool can be as simple as possible – no UML mess
• Cons:• Implementation Effort usually high• Often limited partitioning and model management support
(depends ultimately on the effort you want to put in)
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 46 -
Editor Alternatives: Developing a Custom Tool II
• Models are instances of their metamodel.• The Editor edits models…• … and uses concepts from the metamodel
Domain Metamodel
Model
<<instanceof>>
Editoredits
uses concepts defined in
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 47 -
Editor Alternatives: Custom Tool / Generating Editors
• GEF (Eclipse Graphical Editing Framework) is powerful, but hard to use.
• Especially, if the domain metamodel changes regularly in a project, adapting the editors correspondingly is annoying.
• As a consequence, we generate the editors from the domain meta-model and additional editor descriptions.
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 48 -
GMF Process
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 49 -
Custom Tool – the generated Network Editor
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
Characteristics of Textual DSLs
• Different characteristics for different domains• Concrete Syntax: textual vs. graphical• Domain Selection: structural vs. behavioural • Expressive Power: declarative vs. imperative• Execution: interpretation vs. compilation/transformation• Integration: internal vs. external• Tool Support: editor, debugger, …
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
Why concrete syntax is important
• Abstract Syntax defines grammar for the language – most important for tools
• Concrete Syntax is the “UI” for the language – critical for DSL users• concise vs. redundant• intuitive• simple to write and read
• Tool support matters• IDE integration• syntax highlighting• metamodel awareness
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
Different syntax for different abstractions / domains
• Different concrete syntax is well established for different domains• class diagrams to describe types and structure• state charts• textual expression notation for behaviour• XML for structured data
• The abstraction should drive syntax decision, not vice versa• Available tool support often decides the syntax• UML has its uses, but it is no panacea• building specific textual languages – and IDEs to work with
them – has become feasible
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
Tradeoffs for textual DSLs
• With both textual and graphical syntax you can• Model for any meta model• verify constraints in real time• (Eclipse) write ordinary EMF models
• Graphical Editors are good to show structural relationships
• Textual Editors are better for „algorithmic“ aspects, or hierarchical models
• Textual Editors integrate better with CVS etc. (diff, merge)
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
Strengths of Textual DSLs
• Textual languages have specific strengths compared to graphical languages• ideally there should be the option to have both
• compact and expressive syntax• productivity for experienced users• IDE support softens learning curve
• configuration management/versioning and integration into the “regular” development process• splitting a model into several files• concurrent work on a model, especially with a version
control system: diff, merge• search, replace
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
Separate Generated and Non-Generated Code
• Keep generated and non-generated code in separate files.
• Never modify generated code. • Design an architecture that clearly defines which
artifacts are generated, and which are not. • Use suitable design approaches to “join” generated
and non-generated code. Interfaces as well as design patterns such as factory, strategy, bridge, or template method are good starting points.
Connected by Patterns, etc.
GeneratorApplicationModel
GeneratedSource
ManuallyWrittenSource
Compiler/Build Tool
CompleteSystem
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
Separate Generated and Non-Generated Code II
• A) Generated code can call non-generated code contained in libraries
• B) A non-generated framework can call generated parts.
• C) Factories can be used to „plug-in“ the generated building blocks
• D) Generated classes can also subclass non-generated classes.
• E) The base class can also contain abstract methods that it calls, they are implemented by the generated subclasses(template method pattern)
a)
b)
c) d) e)
generated code non-generated code
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
We didn’t talk about...
• Model-to-Model Transformations• Interpreters• Best Practices• AO & MDSD• CBD & MDSD• PLE & MDSD• Many many other tools... (ME+, DSL Tools, Intentional, ...)• ... And many more
Please ask in Q&A
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 58 -
C O N T E N T S
Part 1: Theory
Part 2: Practice
Part 3: Q&A
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 59 -
openArchitectureWare
• Open Source• Version 4.2 is almost released• Proven track record in various domains &
project contexts• e.g., telcos, internet, enterprise, embedded
realtime, finance, …• www.openarchitectureware.org• IDE-portions based on Eclipse• (Optional) Integration with Eclipse Modelling
facilities (such as EMF)
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
openArchitectureWare / Eclipse EMF, GMF, EMP
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 61 -
C O N T E N T S
Part 1: Theory
Part 2: Practice
Part 3: Q&A
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 62 -
Some advertisement
• For those, who speak(or rather, read) german: Völter, Stahl, Haase, Efftinge: Modellgetriebene SoftwareentwicklungTechnik, Engineering, Management2. AuflagedPunkt, 2007www.mdsd-buch.de
• A translation is availableModel-Driven Software Development, Wiley, May 2006www.mdsd-book.org
2nd Edition – significantly
updated
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 63 -
More Advertisement
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 64 -
More Advertisement
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 65 -
More Advertisement
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 66 -
More Advertisement
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2003 - 2006 M a rk u s V ö l t e r
MDSD Intro & Overview
- 67 -
C O N T E N T S
Part 1: Theory
Part 2: Practice
Part 3: Q&A
THE END.Thanks.