Transcript Kein Folientitel

MDSD Intro & Overview
Model-Driven
Software Development
Introduction and Overview
Markus Völter
www.mdsd-buch.de
[email protected]
www.voelter.de
www.mdsd-book.org
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-1-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Domain Driven Development
•
Domain 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.
Domain Concepts
Domain Concepts
mental work
of developers
Software Technology
Concepts
ingenieurbüro für sof twaretechnologie
Software Technology
Concepts
w w w.vo el ter.d e
-2-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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.
Model
Model
Model
Metamodel
Transformer
Tranformation
Rules
Model
Metamodel
Transformer
Code
Generation
Templates
Generated Code
Manually
Written
Code
One or more model-tomodel transformation steps
may precede code generation.
optional, can be repeated
•
optional
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-3-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-4-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-5-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Hierarchical Structuring of Domains
•
Since Domains can be of any size or granularity, it is
useful to structure domains hierarchically.
•
Automotive Example:
Automotive
Systems
Embedded
Systems
•
eBanking Example:
Engine Controllers
Diesel
Gasoline
4-Cyl
web-based
e-Banking
money
transfer
inv.
bank.
eBusiness
Apps
Rich
Clients
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-6-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
„Kinds“ of Domains
•
In the context of software development it is also useful to
distinguish (at least) two kinds of domains:
• Technical Domains adress key technical issues related
to software development such as
• Distribution, Failover and Load-Balancin
• Persistence and Transactions
• GUI Design
• Concurreny and Realtime
• Functional Domains represent the business/professional
issues; examples include
• Banking
• Human resource management
• Insurance
• Engine Controllers
• Astronomical Telescope Control
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-7-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
MDSD Core Concepts
several
Metametamodel
target
software
architecture
design
expertise
subdomains
bounded area of
knowlege/interest
partial
composable
multi-step
multiple
knowledge
transform
viewpoint
Domain
single-step
compile
Model
semantics
Ontology
interpret
no
roundtrip
precise/
executable
Domain
Specific
Language
graphical
Metamodel
textual
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-8-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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;
}
Operation
Parameter
{ordered}
Interface
name : String
type : String
*
name : String
type : String
Exception
**
type : String
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-9-
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Example 2: Model (J2ME apps)
["Abort"]
["Exit"]
["Again"]
Display
Form
CalcResult
NumberEntry
a: Number ["a"] {a>0}
b: Number ["b"] {b>0}
>> a,b
["Result"]
ingenieurbüro für sof twaretechnologie
c: Number;
c=a+b
w w w.vo el ter.d e
>> c
["The Result is "+c]
{align=center}
- 10 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Example 2: Metamodel (J2ME apps)
1
to
1
from
Element
UIElement
Calculation
name : String
Start
declaredVars: String
expression : String
End
outbound
*
inbound
*
Flow
Form
Display
label : String
constraints: String
Field
AutoFlow
Button
transportedVars: String
label : String
transportedVars: String
varName : String
label : String
constraints: String
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 11 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Example 3: Model (Components, Ports, Connectors)
<system name=”weatherStation”>
<node name=”main”>
<container name=”main”>
<instance name=”controller”
type=”Control”/>
</container>
</node>
<!-- temperature sensor outside -->
<node name=”inside”>
<connector name="toSensorTempOutside">
<container name=”sensorInside”>
<providedPort instance="tempOutside"
<instance name=”tempInside” port="measurementPort">
type=”TemperatureSensor”>´
<requiredPort instance="controller"
<param name=”unit” value=”centigrade”/>
port="sensorsPort">
</instance> </connector>
</container>
<connector name="fromSensorTempOutside">
</node>
<providedPort instance="controller"
<node name=”outside”>…</node>
port="controllerPort">
<requiredPort instance="tempOutside"
port="controllerPort>
</connector>
<!-- humidity sensor outside -->
<connector name="toSensorHumOutside">…</connector>
<connector name="fromSensorHumOutside">…</connector>
<!-- temperature sensor inside -->
<connector name="toSensorTempInside">…</connector>
<connector name="fromSensorTempInside">…</connector>
</system>
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 12 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Example 3: Metamodel (Components, Ports, Connectors)
Provided
PortRef
Required
PortRef
1 source
ComponentRef
1 target
1
*
Component
Instance
name : String
Connector
*
id : String
*
1
context Connector
inv: source.interface == target.interface
type
Connector
Type
*
*
System
Node
Container
{open}
DirectCall
Connector
SharedMemory
Connector
ingenieurbüro für sof twaretechnologie
CAN
Connector
w w w.vo el ter.d e
- 13 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Example 4: Workflow Model (UML + Stereotypes)
<<ProcessObject>>
ReservierungDurchfuehrenPO
+ verfuegbarkeitPruefen( reservierungsBeginn : Date, reservierungsEnde: Date,
gewaehlteStationID : String, gewaehlteKfzKlasseID : String ) : Collection
+ getReservierungsParameter() : ReservierungsParameterVO
+ kfzReservieren( reservierungsBeginn : Date, reservierungsEnde: Date,
gewaehlteKfzNr : String, mitgliedsNr : String ) : ReservierungBestaetigenVO
<<ValueObject>>
<<ValueObject>>
<<ValueObject>>
ReservierungBestaetigenVO
ReservierungsParameterVO
VerfuegbarkeitPruefenVO
- Mitglied : String
- Station : String
- Kfz : String
- ReservierungsBeginn : Date
- ReservierungsEnde : Date
- stationen : Collection
- kfzKlassen : Collection
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- ReservierungsBeginn : Date
- ReservierungsEnde : Date
- Station : String
- KfzKlasse : String
- KfzBezeichnung : String
- KfzNr : String
- 14 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Example 4: Workflow Model II (UML + Stereotypes)
<<ActivityController>>
<<Presentation>>
BenutzerAnmeldenCtrl
BenutzerAnmelden
- kennung : String
- passwort : String
+ AnmeldungErfolgreich() : Boolean
+ Weiter()
+ Ende()
<<ProcessObject>>
<<ValueObject>>
BenutzerAnmeldenPO
BenutzerAnmeldenVO
benutzerAnmelden( kennung : String,
passwort : String ) : BenutzerAnmeldenVO
- Name : String
- Passwort : String
- Kennung : String
<<EntityObject>>
Benutzer
- <<Key>> Name : String
- Passwort : String
- Kennung : String
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 15 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Example 5: Power Grid
SomePlace: Generator
end11
T11: Transformer
link13
220KV: Bus
link14
transmissionLine1
link12
end21
20KV: Bus
SomeOtherPlace: SwitchingStation
link21
link11
B21-220KV: Bus
G11: GenerationElement
link22
T21: Transformer
link23
B22-10KV: Bus
link24
end22
SomePlace:
Generator
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
end11
end21
transmissionLine1
- 16 -
SomeOtherPlace:
SwitchingStation
end22
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Example 5: Power Grid Metamodel
1 targetNode
sources 0..*
MicroNode
parts
Generation
Element
0..*
Link
1 sourceNode
Transformer
targets 0..*
Bus
Endpoint
sourceEndPoint
targetTransmissionLine
1 targetNode
sources 0..*
MacroNode
1 sourceNode
Generator
BranchPoint
ingenieurbüro für sof twaretechnologie
1
0..1
1
0..1
targetEndPoint
sourceTransmissionLine
Transmission
Line
targets 0..*
Switching
Station
w w w.vo el ter.d e
- 17 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 18 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
MDSD Core Building Blocks
•
domain analysis
•
meta modelling
•
model-driven generation
(and: model transformation)
•
template languages
•
domain-driven framework design
•
the principles for agile software development
•
the development and use of Open Source infrastructure
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 19 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
•
An often-asked question is: are MDSD
models the same as requirements
/analysis models?
• They can be, but in general, they
are not.
• Analyis/requirements models
are non-computational, MDSD
models are compuatational.
Model
Business Model
(Domain Model)
System
Model
Logical
Model
Requirements
Model
Physical Model
(Deployment)
Computational
Model
PIM
Adapted from Frankel‘s book on MDA
MDSD and Requirements/Analysis
PSM
 somewhere the „intellectual work of development and
problem solving“ has to be put into the system. Usually, this is
on the stage from requirements/analysis to (computational)
MDSD models.
•
How can MDSD help with requirements?
• Formalizing Requirements using a DSL is benefitial because
requirements become unambigious.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 20 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
MDA and Model Driven Software Development Overview
several
target
software
architecture
MOF
Metametamodel
subdomains
design
expertise
Application
PIM, PSM, ....
QVT
multi-step
transform
bounded area of
knowlege/interest
partial
composable
multiple
viewpoint
Domain
single-step
compile
Model
semantics
Ontology
interpret
no
roundtrip
precise/
executable
Domain
Specific
Language
OCL, Action
Semantics
UML+
Profiles
graphical
Metamodel
textual
•
Focus: Platform Independence, (Tool) Interop
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 21 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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 
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 22 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 23 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 24 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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!
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 25 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 26 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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!
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 27 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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)
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 28 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 29 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 30 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 31 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
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
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 32 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Information Gain
MDSD (compared to “normal” Software Development)
n
tatio
n
e
m
Imple
Goal
n
sig
De
Effort
is
ys
l
a
An
Level of Detail
Start
Result of
Analysis
ingenieurbüro für sof twaretechnologie
virtual or real
Implementation model
w w w.vo el ter.d e
Implementation
- 33 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Information Gain
MDSD Effort (stage 1)
A'
B
Automation
enImplem
tation
Goal
M
od
el
lin
g
A
Savings
because
of Generation
An
al
ys
is
Effort
Savings based on
the use of a semantically
rich platform
Level of Detail
Start
Results of
Analysis
ingenieurbüro für sof twaretechnologie
virtual or real
implementation model
w w w.vo el ter.d e
Implementation
- 34 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Information Gain
MDSD Effort (stage 2)
A'
B
Automation
Goal
de
llin
g
A
Mo
Savings
because
of generation
An
aly
sis
Effort
Savings based on
the use of a semantically
rich platform
Level of Detail
Start
Results of
Analysis
ingenieurbüro für sof twaretechnologie
virtual or real
implementation model
w w w.vo el ter.d e
Implementation
- 35 -
© 2003 - 2006 Ma rk u s Vö l te r
MDSD Intro & Overview
Some advertisement 
•
For those, who speak
(or rather, read) german:
Völter, Stahl:
Update currently
in progress,
with Arno Haase and
Sven Efftinge as
additional
coauthors
Modellgetriebene
Softwareentwicklung
Technik, Engineering, Management
dPunkt, 2005
www.mdsd-buch.de
•
A very much updated translation is
under way:
Model-Driven
Software Development,
Wiley, Q2 2006
www.mdsd-book.org
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 36 -
© 2003 - 2006 Ma rk u s Vö l te r