Transcript Kein Folientitel

MDSD Best Practices
www.mdsd-buch.de
Model-Driven
Software Development
Some Essential Best Practices
Markus Völter
[email protected]
www.voelter.de
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-1-
© 2004 M a rk us Vö l te r
MDSD Best Practices
About me
•
•
Independent Consultant
•
Focus on
• Software Architecture
• Model-Driven Software
Development
• Middleware
Markus Völter
[email protected]
www.voelter.de
Based out of Heidenheim,
Germany
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-2-
© 2004 M a rk us Vö l te r
MDSD Best Practices
Before we start… I
•
Model-Driven Software 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
-3-
© 2004 M a rk us Vö l te r
MDSD Best Practices
Before we start … II: MDSD on a Slide
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
-4-
© 2004 M a rk us Vö l te r
MDSD Best Practices
Before we start … III: MDSD and MDA
MOF
several
target
software
architecture
design
expertise
Metametamodel
subdomains
bounded area of
knowlege/interest
partial
composable
PIM, PSM, ....
QVT
multi-step
transform
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
-5-
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
•
•
•
Process
Multi Model
Model-Driven
Software
Development
Architecture and CBD
Adopting MDSD
ingenieurbüro für sof twaretechnologie
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
-6-
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Multi Model
•
Architecture and CBD
•
Adopting MDSD
ingenieurbüro für sof twaretechnologie
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
-7-
© 2004 M a rk us Vö l te r
MDSD Best Practices
How do I come up with a good metamodel?
•
Incrementally!
•
Based on experience from previous projects, and by
„mining“ domain experts.
•
A very good idea is to start with a (typically) very well
known domain: the target software architecture
(platform)
 Architecture-Centric MDSD
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-8-
© 2004 M a rk us Vö l te r
MDSD Best Practices
Talk Metamodel
•
In order to continuously improve and validate the
FORMAL META MODEL for a domain, it has to be
exercised with domain experts as well as by the
development team.
•
In order to achieve this, it is a good idea to use it during
discussions with stakeholders by formulating sentences
using the concepts in the meta model.
•
As soon as you find that you cannot express something
using sentences based on the meta model,
• you have to reformulate the sentence
• the sentence’s statement is just wrong
• you have to update the meta model.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-9-
© 2004 M a rk us Vö l te r
MDSD Best Practices
Talk Metamodel II
•
Example:
owns
*
implements
1
Port
Interface
Component
provides
operations
defined by
Required Port
Provided Port
provides access to operations defined by
• A component owns any number of ports.
• Each port implements exactly one interface.
• There are two kinds of ports: required ports and provided
•
•
ports.
A provided port provides the operations defined by its
interface.
A required port provides access to operations defined by
its interface.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 10 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Multi Model
•
Architecture and CBD
•
Adopting MDSD
ingenieurbüro für sof twaretechnologie
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
- 11 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Leverage the Model
•
•
The information captured in a model should be leveraged
to avoid duplication and to minimize manual tasks.
Hence you may generate much more than code:
• user guides
• help text
• test data
• build script
• content, etc.
•
Find the right balance between the effort required for
automating manual tasks and the effort of repetitively
performing manual tasks
•
Make use of SELECT FROM BUY, BUILD, OR OPEN SOURCE
in your assessment.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 12 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Separate Generated and Non-Generated Code
•
Keep generated and non-generated code in separate
files.
•
•
Never modify generated code.
•
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.
Design an architecture that clearly defines which
artifacts are generated, and which are not.
Connected by Patterns, etc.
Application
Model
Generator
Complete
System
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
Manually
Written
Source
Generated
Source
Compiler/
Build Tool
- 13 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
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)
ingenieurbüro für sof twaretechnologie
a)
b)
d)
c)
generated code
.
w w w.vo el ter.d e
e)
non-generated code
- 14 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Produce Nice-Looking Code … whenever possible!
•
•
PRODUCE NICE-LOOKING CODE … WHEREVER POSSIBLE!
•
Using this pattern helps to gain acceptance for code
generation in general.
•
Examples:
• Comments
• Use pretty printers/code formatters
• Location string („generated from model::xyz“)
When designing your code generation templates, also
keep the developer in mind who has to – at least to
some extent – work with the generated code, for example
• When verifying the generator
• Or debugging the generated code
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 15 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Multi Model
•
Architecture and CBD
•
Adopting MDSD
ingenieurbüro für sof twaretechnologie
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
- 16 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Tools: Overview
• Many kinds of tools can be used in the context of model
driven development:
• UML modelling tools
• Metamodelling environments
• (XMI) Repositories
• Code Generators
• Model verifiers
• There is also a large amount of tools that are „MDA
certified“. These range from completely integrated
environments such as ArcStyler to simple code generators or
technology specific generators (e.g. for J2EE).
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 17 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Tools: Vendor Lock-in
• Because a lot of issues are not yet standardized, it is hard to
integrate tools. Open issues include:
• Some XMI aspects
• Specification of model transformation rules
• Code generation
• ...
• As a consequence, integrated MDD/MDA tooling is
currently impossible to achieve without vendor lock-in.
• Alternatively, building/integrating your own tooling based on
open source can be done, but requires compromises.
• Many tools are exemplified in the context of code
generation (see other presentation). Build Tools are also
important. UML tools (such as Rational XDE) also develop in
the direction of supporting MDA.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 18 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Tools: The Ideal One
• MOF Based Metamodelling, including OCL
• Usage of thses metamodels for subsequent modeling of M1
• Metamodel specific repositoriy
• GUI adapted to metamodel
• Model Validation based on metamodel
• Also including OCL
• Transformation rules based on user-defined metamodels
• Flexible Code Generation
• Test support
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 19 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Implement the Metamodel
•
Implement the meta model in some tool that can read a
model and check it against the meta model.
•
This check needs to include everything including
declared constraints.
•
Make sure the model is only transformed if the model
has been validated against the meta model.
•
The meta model implementation is typically part of the
transformation engine or code generator since a valid
model is a precondition for successful transformation.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 20 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Ignore Concrete Syntax
•
Define transformations based on the source and target
meta models.
•
The transformer uses a three phase approach:
• first parse the input model into some in-memory
representation of the meta model (typically an object
structure),
• then transforms the input model to the output model
(still as an object structure)
• and finally unparse the target model to a concrete syntax
Application
Model
(Concrete Syntax)
Concrete
Syntax
Parser
Source Model AST
(Instance of the
source metamodel)
Target Model
(Concrete Syntax)
Unparser/
PrettyPrinter
Target Model AST
(Instance of the
target metamodel)
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 21 -
Transformer
© 2004 M a rk us Vö l te r
MDSD Best Practices
Transformations as first class citizens
•
Transformations (and Templates) are central assets in
MDSD. You should treat them accordingly.
•
Transformations should be versioned.
•
Refactor transformations to keep them current and well
organized.
•
Modularize transformations, e.g. using object-oriented
concepts such as encapsulation, polymorphism,
inheritance, etc.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 22 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Modular, Automated Transforms
•
In order to more easily reuse parts of a transformation, it
is a good idea to modularize a transform.
•
Note that in contrast to the OMG, we do not recommend
looking at, changing or marking the intermediate
models.
•
They are merely a standardized format for exchanging
data among the transformations.
•
Example: Multi-Step
transformation from
a banking-specific
DSL to Java via J2EE
Bank /
OO
OO Metamodel
OO/
J2EE
BankingMetamodell
J2EE Metamodel
Bank /
Prozess
Process
Metamodel
Process/
J2EE
J2EE/
IBM
J2EE/
BEA
BEA/
Java
WLS
Metamodel
Java
Metamodel
IBM/
Java
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 23 -
WebSphere
Metamodel
© 2004 M a rk us Vö l te r
MDSD Best Practices
External Model Markings (AO-Modelling)
•
In order to allow the transformation of a source model into
a target model (or to generate code) it is sometimes
necessary to provide “support” information that is
specific to the target meta model.
• Example: Entity Bean vs. Type Manager
•
Adding these to the source model “pollutes” the source
model with concepts specific to the target model.
•
MDA proposes to add “model markings”, but this
currently supported well by only very few tools.
•
Instead, we recommend keeping this information outside
of the model (e.g. in an XML file); the transformation
engine would use this auxiliary information when
executing the transformations.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 24 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Multi Model
•
Architecture and CBD
•
Adopting MDSD
ingenieurbüro für sof twaretechnologie
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
- 25 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Example Tool: openArchitectureWare Generator
•
Open Source, quite active project
http://www.openarchitectureware.org
•
Core Features:
• Can Read any model (XMI from various UML tools, UML,
textual, JDBC, Java classes …)
• Can generate any kind of output
• Explicit Domain-Metamodel (implemented in Java)
• Semi-Declarative Metamodel Constraints, „Functional
Programming“
• Simple, efficient template language
• Template Polymorphism and Template overwriting
• Multi-Model (Merging-Support)
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 26 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Example Tool: openArchitectureWare Generator
•
Core Features cont‘d:
• Inter-Model References among various model syntaxes
(i.e. UML to XML)
• Support for Aspects in the metamodel and in the
templates
• Arbitrary Namespace Models can be supported
• Plugin-Based Generator configuration (ant-based)
•
Additional Features:
• Syntax-Highlighting Template Editor for Eclipse
• Metamodel can be generated from UML model, incl. DTD,
HTML Docs, etc.
• Graphical GEF-Based Editors can be generated
• Dialog-Based Editors can be generated
• Framework for building IDEs based on this Generator
•
Future Features
• EMF Integration, Visio Integration
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 27 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Example Tool: openArchitectureWare Generator
•
How it works:
specification
(model)
metamodel
instance of
model parser
metamodel
instance
written in
terms of
ingenieurbüro für sof twaretechnologie
template
engine
output code
templates
.
w w w.vo el ter.d e
- 28 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Example Tool: openArchitectureWare Generator
•
Usage Examples
• Web Development (J2EE, Servlets, Struts)
• Banking, Insurances
• Mobile Phone Software (C++ + QT, J2ME + Java)
• Embedded Software (C, CANbus, Osek)
• Automotive Component Middleware
• (Interactive) Web sites
• Architectural Management, „Entertainment)
• Multi-Platform Middleware (XML, C++, Java, …)
• Radioastronomy
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 29 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Multi Model
•
Architecture and CBD
•
Adopting MDSD
ingenieurbüro für sof twaretechnologie
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
- 30 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Teaming issues
•
Using DSLs is not very different from “normal”
programming – every developer can basically do it.
•
Defining DSLs is, however, something completely
different:
• Finding the „right“ abstractions, defining metamodels,
keeping the various metalevels sorted, etc. is not
everybody‘s business.
• Some of the tools to define metamodels, DSLs, generators
and model-2-model transformations are not (yet)
intuitively usable.
•
Therefore I recommend to keep DSL/generator
development to a limited group of people in your
project.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 31 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Iterative Dual Track Development
•
Develop Domain Architecture and at least one application
at the same time.
•
Establish rapid feedback from application developers to
domain architecture developers.
•
Develop both aspects iteratively and incrementally.
Use strict timeboxing.
•
Infrastructure develops iteration n+1 whereas
application developers use iteration n.
•
Introduce new
Domain Architecture
releases only at the
beginning of
iterations.
Application
Development
(n)
Integration
and
Feedback
feedback
Infrastructure
Development
(n+1)
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 32 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Extract the Infrastructure
•
Before starting ITERATIVE DUAL-TRACK DEVELOPMENT,
Extract the transformations from manually developed
application.
• Either, start by developing this prototype
conventionally, then build up the MDSD infrastructure
based on this running application,
• Or extract the code from applications developed in the
respective domain before doing MDSD (but only if the
quality is sufficiently good!)
Metamodel
DSL(s)
Manually
Developed
Prototype
Infrastructure
Development
Transformations
Platform(s)
Application
Development
Application Model
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 33 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Multi Model
•
Architecture and CBD
•
Adopting MDSD
ingenieurbüro für sof twaretechnologie
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
- 34 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
One DSL is not enough
Most systems can be structured into various
• partitions: functional subsystems
• subdomains: technical aspects
•
It is hardly possible to describe each
of these with the same DSL.
• You will need to come up with
separate DSLs
• … that have to be „connectable“
in order to build the complete
system
Subdomains
•
ingenieurbüro für sof twaretechnologie
CRM
Human
Resourcs
Accounting
Partitions
GUI
M
E
ST
Processes
SY
Persistence
.
w w w.vo el ter.d e
- 35 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
One DSL is not enough II - Example
Persistence
Business Objects
Type
Column
*
Table
type
*
maps
*
Entity
Attribute
Mapping
represents
represents
Key
Attribute
Pages, Forms and Workflow
Form Layout
target
Page
*
Form
Form
Layout
*
Button
FormField
Tabular
Layout
Simple
Layout
[...]
[...]
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 36 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Multi Model
•
Architecture and CBD
•
Adopting MDSD
ingenieurbüro für sof twaretechnologie
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
- 37 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Rich Domain-Specific Platform
•
•
•
•
Define a rich domain-specific application platform
consisting of
• Libraries
Generated Applications
• Frameworks
- Core Domain
Classes (Entities,
• base classes
Domain
Value Types, ...)
- Business Rules
Platform
• interpreters, etc.
- Business Services
The transformations will
“generate code” for this
domain-specific application
platform.
As a consequence, the transformations become simpler.
- ...
Technical
Platform/
Middleware
- Persistence
- Transactions
- Distribution
- Scheduling
- Hardware Access
- ...
Programming Language
Operating System
DSLs and Frameworks are
two sides of the same coin
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 38 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Software Architecture Process „on a slide“
•
•
•
…and actually, this is
a talk of its own…
Today‘s Problems:
• Too much technology
• Too many hypes and buzzwords
• Too many standards too early
• So: People don‘t focus on architectural concepts
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 39 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
MDSD and CBD – the three viewpoints
•
•
•
Type Model: Components, Interfaces, Data Types
Composition Model: Instances, “Wirings”
System Model: Nodes, Channels, Deployments
Type Model
<<entity>>
<<component>>
AddressManager
person
Person
name: String
firstName: String
0..n
addressStore
<<valuetype>>
<<interface>>
AddressStore
Address
<<component>>
CustomerManager
addOrUpdateContact( p: Person) : void
addAddress( p: Person, a: Address) : void
getAddresses( p: Person ) : Address[]
street: String
zip: String
City: String
Composition Model
System Model
<configurations>
<configuration name="addressStuff">
<deployment name="am" type="AddressManager">
<wire name="personDAO" target="personDAO"/>
</deployment>
<deployment name="personDAO" type="PersonDAO"/>
</configuration>
<configuration name="customerStuff">
<deployment name="cm" type="CustomerManager">
<wire name="addressStore" target=":addressStuff:am"/>
</deployment>
</configuration>
<configuration name="test" includes="addressStuff, customerStuff"/>
</configurations>
<systems>
<system name="production">
<node name="server" type="spring" configuration="addressStuff"/>
<node name="client" type="eclipse" configuration="customerStuff"/>
<system>
<system name="test">
<node name="test" type="spring" configuration="test"/>
<system>
</systems>
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 40 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Component Implementation
•
•
sm AProcess
<<proc-component>>
AProcess
1
<<transform>>
Component
implementation
should be based
on notations
specific to the
“kind of
component”
s1
s2
*
<<trigger-interface>>
AProcessInterface
<<transform>>
•
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
Various other
implementation
stragies can be used,
such as:
• Rule-Engines
• “Procedural” DSLs or action
semantics
<<generate>>
<<gen-code>>
<<gen-code>>
AProcessBase
.java
AProcessProcBase.jav
a
AProcessData.java
1
data
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
Note that, here, interpreters can often be used sensibly
instead of generating code!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 41 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Aspect Models
•
These go into separate aspect models, each describing
a well-defined aspect of the system.
• Each of them uses a suitable DSL/syntax
• The generator acts as a weaver
•
Typical Examples are
• Persistence
• Security
• Forms, Layout, Pageflow
• Timing, QoS in General
• Packaging and Deployment
• Diagnostics and Monitoring
ct4
on
ositi
p
m
Co
el(s)
Mod
Ty
p
M e/D
o
a
d
el ta
2
.
w w w.vo el ter.d e
sp
e
ct
ingenieurbüro für sof twaretechnologie
Aspe
Sy s t
e
Mod m
el(s)
ect3
Asp
Often, the described three viewpoints are not enough,
additional aspects need to be described.
A
•
Aspe
- 42 -
ct1
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Multi Model
•
Architecture and CBD
•
Adopting MDSD
ingenieurbüro für sof twaretechnologie
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
.
w w w.vo el ter.d e
- 43 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Adopting MDSD – prerequisites
•
Well-practices MDSD builds on several mature other
practices, among them
• Well-defined software architecture
• Iterative software development and requirements
management
• Mature project automation (regression testing,
automatic builds, etc.)
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 44 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Adopting MDSD – process
Traditionelle
Softwareentwicklung
Etablieren eines
disziplinierten, iterativen
Anforderungsmanagements
Klassifizieren
des SoftwareInventars
Ausgereifte, Iterative
Softwareentwicklung
Entwickeln
einer Referenzimplementierung
Extrahieren der
Infrastruktur
Definieren der
Software Supply
Chain
Implementieren eines gemanagten
Prozesses
Standardisierung
der Infrastruktur
MDSD-basierte
Anwendungsentwicklung
Weiterentwikkeln der
Infrastruktur
Entwicklung einer
domänenspezifischen
Anwendungsplattform
Architekturzentrierte MDSD
Nicht gemanagter Prozess
Legende:
Nicht-MDSD
MDSD
Applikations-Engineering
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
Domänen-Engineering
- 45 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Levels of MDSD
•
You would typically start with architecture-centric
MDSD where the abstractions of the DSL correspond to
the core concepts of the technical platform.
•
This automates many aspects of the technical aspects;
• Results in a wide platform/infrastructure
• Many projects can be handled with the infrastructure
•
In later phases, functional MDSD infrastructures will be
built on this technical one, resulting in cascaded MDSD.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 46 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Levels of MDSD
Input Models
...
...
...
...
...
...
MDSD
Infrastructure
Output Models
Domain 1 Model
Domain 2 Model
Functional Domain 1
MDSD Infrastructure
Functional Domain 2
MDSD Infrastructure
Input Models
Basic Technical
MDSD Infrastructure
Code for Target Platform
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 47 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Levels of MDSD III – M2M Transformations
Type Model
<<entity>>
<<component>>
person
AddressManager
Person
name: String
firstName: String
0..n
addressStore
<<valuetype>>
<<interface>>
AddressStore
Address
<<component>>
CustomerManager
addOrUpdateContact( p: Person) : void
addAddress( p: Person, a: Address) : void
getAddresses( p: Person ) : Address[]
street: String
zip: String
City: String
Composition Model
System Model
<configurations>
<configuration name="addressStuff">
<deployment name="am" type="AddressManager">
<wire name="personDAO" target="personDAO"/>
</deployment>
<deployment name="personDAO" type="PersonDAO"/>
</configuration>
<configuration name="customerStuff">
<deployment name="cm" type="CustomerManager">
<wire name="addressStore" target=":addressStuff:am"/>
</deployment>
</configuration>
<configuration name="test" includes="addressStuff, customerStuff"/>
</configurations>
<systems>
<system name="production">
<node name="server" type="spring" configuration="addressStuff"/>
<node name="client" type="eclipse" configuration="customerStuff"/>
<system>
<system name="test">
<node name="test" type="spring" configuration="test"/>
<system>
</systems>
<<interface>>
<<generate>>
SomeInterface.java
SomeInterface
<<component>>
SomeComponent
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
<<gen-code>>
<<generate>>
<<gen-code>>
Some
Component
Base.java
- 48 -
<<man-code>>
SomeComponent.java
© 2004 M a rk us Vö l te r
MDSD Best Practices
Levels of MDSD III – M2M Transformations II
<<entity>>
<<interface>>
<<transform>>
SomeEntity
<<generate>>
<<gen-code>>
SomeEntityDAO.java
SomeEntityDAO
<<transform>>
<<component>>
<<generate>>
<<gen-code>>
SomeEntityDAOBase
.java
SomeEntityDAO
<<generate>>
<<generate>>
<<gen-code>>
SomeEntity.java
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
<<gen-code>>
SomeEntityDAO.java
- 49 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Levels of MDSD III – M2M Transformations III
Model
(UML)
export
openArchitectureWare
(may be repeated)
Parser
Model
(XMI)
Model
(Object Graph)
Model
Transformer
Generated
Code
Modified Model
(Object Graph)
Code
Generator
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 50 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
PATTERN: DSL-based Programming Model
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<generate>>
AProcessData.java
1
<<gen-code>>
AProcessBase
.java
<<gen-code>>
AProcessProcBase.java
data
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 51 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domain Metamodelling
• Code Generation
•
Tools
• Features And Structure
• An Example
•
Process
•
Testing
•
Multi Model
•
Adopting MDSD
The End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 52 -
© 2004 M a rk us Vö l te r
MDSD Best Practices
Some advertisement 
•
For those, who happen to speak
(or rather, read) german:
Völter, Stahl:
Modellgetriebene
Softwareentwicklung
Technik, Engineering, Management
dPunkt, 2005
www.mdsd-buch.de
•
For all others:
A 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
- 53 -
© 2004 M a rk us Vö l te r