Markus Völter voelter@acm voelter.de
description
Transcript of Markus Völter voelter@acm voelter.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 1 -
MDSD Best Practices
Markus Vö[email protected]
Model-DrivenSoftware Development
Some Essential Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 2 -
MDSD Best Practices
Markus Völter
www.voelter.de
• Independent Consultant
• Based out of Heidenheim, Germany
• Focus on
• Software Architecture
• Model-Driven SoftwareDevelopment
• 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 © 2 0 0 4 M a rk u s V ö l t e r. - 3 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 4 -
MDSD Best Practices
Before we start … II: MDSD on a Slide
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 © 2 0 0 4 M a rk u s V ö l t e r. - 5 -
MDSD Best Practices
Before we start … III: MDSD and MDA
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
architecturedesign
expertise
• 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 © 2 0 0 4 M a rk u s V ö l t e r. - 6 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling• Code Generation
• Tools
• Features And Structure• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 7 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 8 -
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
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 © 2 0 0 4 M a rk u s V ö l t e r. - 9 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 10 -
MDSD Best Practices
Talk Metamodel II
• 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.
Component
Portowns *
Interfaceimplements 1
Required Port Provided Port
providesoperationsdefined by
provides access to operations defined by
• Example:
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 © 2 0 0 4 M a rk u s V ö l t e r. - 11 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 12 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 13 -
MDSD Best Practices
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.
GeneratorApplication
ModelGenerated
Source
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 © 2 0 0 4 M a rk u s V ö l t e r. - 14 -
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)
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 © 2 0 0 4 M a rk u s V ö l t e r. - 15 -
MDSD Best Practices
Produce Nice-Looking Code … whenever possible!
• PRODUCE NICE-LOOKING CODE … WHEREVER POSSIBLE!
• 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
• 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“)
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 © 2 0 0 4 M a rk u s V ö l t e r. - 16 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 17 -
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).
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 © 2 0 0 4 M a rk u s V ö l t e r. - 18 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 19 -
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
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 © 2 0 0 4 M a rk u s V ö l t e r. - 20 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 21 -
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 ConcreteSyntaxParser
ApplicationModel
(Concrete Syntax)
Source Model AST(Instance of the
source metamodel)Transformer
Target Model AST(Instance of the
target metamodel)
Unparser/PrettyPrinter
Target Model(Concrete Syntax)
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 © 2 0 0 4 M a rk u s V ö l t e r. - 22 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 23 -
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
Banking-Metamodell
Bank /OO
OO Metamodel
J2EE Metamodel
ProcessMetamodel
Bank /Prozess
OO/J2EE
Process/J2EE
WLSMetamodel
WebSphereMetamodel
J2EE
/B
EA
J2EE
/IB
M
JavaMetamodel
BEA/Java
IBM/Java
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 © 2 0 0 4 M a rk u s V ö l t e r. - 24 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 25 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 26 -
MDSD Best Practices
Example Tool: openArchitectureWare Generator
• Open Source, quite active projecthttp://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)
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 © 2 0 0 4 M a rk u s V ö l t e r. - 27 -
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
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 © 2 0 0 4 M a rk u s V ö l t e r. - 28 -
MDSD Best Practices
Example Tool: openArchitectureWare Generator
• How it works:
specification(model)
instance of
model parsermetamodel
instancetemplateengine
metamodel
templateswritten interms of
output 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 © 2 0 0 4 M a rk u s V ö l t e r. - 29 -
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
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 © 2 0 0 4 M a rk u s V ö l t e r. - 30 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 31 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 32 -
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.
Integrationand
Feedback
ApplicationDevelopment
(n)
InfrastructureDevelopment
(n+1)
feedback
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 © 2 0 0 4 M a rk u s V ö l t e r. - 33 -
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!)
ManuallyDevelopedPrototype
Transformations
DSL(s)
Metamodel
Application Model
Platform(s)Application
Development
InfrastructureDevelopment
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 © 2 0 0 4 M a rk u s V ö l t e r. - 34 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 35 -
MDSD Best Practices
One DSL is not enough
GUI
Persistence
Processes
Acc
ou
nti
ng
Hu
man
R
eso
urc
s
CR
M
Partitions
Su
bd
om
ain
s
SYSTEM
• 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 withseparate DSLs
• … that have to be „connectable“in order to build the complete system
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 © 2 0 0 4 M a rk u s V ö l t e r. - 36 -
MDSD Best Practices
One DSL is not enough II - Example
Form Layout
Entity Attribute*
KeyAttribute
TableColumnType
type
*
Mapping
*
Business Objects
Page Form
FormField
*
*
maps
Button
target
Pages, Forms and Workflow
representsrepresents
FormLayout
TabularLayout
SimpleLayout
[...]
[...]
Persistence
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 © 2 0 0 4 M a rk u s V ö l t e r. - 37 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 38 -
MDSD Best Practices
Rich Domain-Specific Platform
• Define a rich domain-specific application platform consisting of
• Libraries
• Frameworks
• base classes
• interpreters, etc.
• The transformations will “generate code” for this domain-specific application platform.
• As a consequence, the trans-formations become simpler.
• DSLs and Frameworks are two sides of the same coin
DomainPlatform
TechnicalPlatform/Middleware
Operating System
Programming Language
- Persistence- Transactions- Distribution- Scheduling- Hardware Access- ...
- Core Domain Classes (Entities, Value Types, ...)- Business Rules- Business Services- ...
Generated Applications
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 © 2 0 0 4 M a rk u s V ö l t e r. - 39 -
MDSD Best Practices
Software Architecture Process „on a slide“
• 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
…and actually, this is
a talk of its own…
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 © 2 0 0 4 M a rk u s V ö l t e r. - 40 -
MDSD Best Practices
MDSD and CBD – the three viewpoints
<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>
<<component>>
AddressManager
<<interface>>AddressStore
addOrUpdateContact( p: Person) : voidaddAddress( p: Person, a: Address) : voidgetAddresses( p: Person ) : Address[]
<<entity>>
Person
name: StringfirstName: String
<<valuetype>>
Address
street: Stringzip: StringCity: String
0..n
<<component>>
CustomerManager
address-Store
<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>
Type Model
Composition Model System Model
person
• Type Model: Components, Interfaces, Data Types
• Composition Model: Instances, “Wirings”
• System Model: Nodes, Channels, Deployments
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 © 2 0 0 4 M a rk u s V ö l t e r. - 41 -
MDSD Best Practices
Component Implementation
• Componentimplementation should be based on notationsspecific to the “kind of component”
• Various other implementationstragies can be used, such as:
• Rule-Engines
• “Procedural” DSLs or action semantics
• Note that, here, interpreters can often be used sensibly instead of generating code!
<<generate>>
<<gen-code>>
AProcess-Data.java
<<proc-component>>
AProcess
<<gen-code>>
AProcessBase.java
<<gen-code>>
AProcessProcBase.java
<<trigger-interface>>
AProcessInterface
*
1
sm AProcess
<<entity>>
AProcessData
<<
tran
sfor
m>
>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<
tran
sfor
m>
>
guard operations... (abstract)action methods... (abstract)
<<man-code>>
AProcess.java
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 © 2 0 0 4 M a rk u s V ö l t e r. - 42 -
MDSD Best Practices
Aspect Models
• Often, the described three viewpoints are not enough, additional aspects need to be described.
• These go into separate aspect models, each describinga 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
System Model(s)
Co
mp
osi
tio
n
Mo
del
(s)
Type/Data
Model
Aspect1
Aspect2
Asp
ect3
Aspect4
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 © 2 0 0 4 M a rk u s V ö l t e r. - 43 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD
Model-DrivenSoftware Development
Best Practiceswww.mdsd-buch.de
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 © 2 0 0 4 M a rk u s V ö l t e r. - 44 -
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.)
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 © 2 0 0 4 M a rk u s V ö l t e r. - 45 -
MDSD Best Practices
Adopting MDSD – process
TraditionelleSoftwareentwicklung
Etablieren einesdisziplinierten, iterativen
Anforderungsmanagements
Entwickelneiner Referenz-
implementierung
Extrahie-ren derInfra-
struktur
Definieren derSoftware Supply
Chain
Ausgereifte, IterativeSoftwareentwicklung
Klassifizierendes Software-
Inventars
Weiterentwik-keln der
Infrastruktur
MDSD-basierteAnwendungsentwicklung
Implementieren eines gemanagtenProzesses
Standardisierungder Infrastruktur
Architekturzentrierte MDSD
Nicht gemanagter Prozess MDSD
Nicht-MDSD Domänen-EngineeringApplikations-EngineeringLegende:
Entwicklung einerdomänenspezifischenAnwendungsplattform
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 © 2 0 0 4 M a rk u s V ö l t e r. - 46 -
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.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 47 -
MDSD Best Practices
Levels of MDSD
MDSDInfrastructure
Input Models
Output Models
Basic TechnicalMDSD Infrastructure
Code for Target Platform
Input Models
Functional Domain 1MDSD Infrastructure
Domain 1 Model
Functional Domain 2MDSD Infrastructure
Domain 2 Model
...
...
...
...
...
...
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 © 2 0 0 4 M a rk u s V ö l t e r. - 48 -
MDSD Best Practices
Levels of MDSD III – M2M Transformations
<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>
<<component>>
AddressManager
<<interface>>AddressStore
addOrUpdateContact( p: Person) : voidaddAddress( p: Person, a: Address) : voidgetAddresses( p: Person ) : Address[]
<<entity>>
Person
name: StringfirstName: String
<<valuetype>>
Address
street: Stringzip: StringCity: String
0..n
<<component>>
CustomerManager
address-Store
<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>
Type Model
Composition Model System Model
person
<<component>>
SomeComponent
<<generate>><<man-code>>
SomeCompo-nent.java
<<interface>>
SomeInterface
<<gen-code>>
Some-Interface.java
<<generate>>
<<gen-code>>
SomeComponentBase.java
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 © 2 0 0 4 M a rk u s V ö l t e r. - 49 -
MDSD Best Practices
Levels of MDSD III – M2M Transformations II
<<gen-code>>
SomeEntity.java
<<entity>>
SomeEntity
<<generate>>
<<interface>>
SomeEntityDAO<<transform>>
<<generate>> <<gen-code>>
SomeEntity-DAO.java
<<component>>
SomeEntityDAO
<<transform>><<generate>> <<gen-code>>
SomeEntity-DAOBase
.java
<<gen-code>>
SomeEntity-DAO.java
<<generate>>
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 © 2 0 0 4 M a rk u s V ö l t e r. - 50 -
MDSD Best Practices
Levels of MDSD III – M2M Transformations III
openArchitectureWareModel(UML)
Model(XMI)
Parser
Model(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
GeneratedCode
CodeGenerator
(may be repeated)
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 © 2 0 0 4 M a rk u s V ö l t e r. - 51 -
MDSD Best Practices
PATTERN: DSL-based Programming Model
<<generate>>
<<gen-code>>
AProcess-Data.java
<<proc-component>>
AProcess
<<gen-code>>
AProcessBase.java
<<gen-code>>
AProcessProcBase.java
<<trigger-interface>>
AProcessInterface
*
1
sm AProcess
<<entity>>
AProcessData
<<
tran
sfor
m>
>
s1
s2
s3
<<generate>> <<generate>>operations...
attributes...
data
1
<<
tran
sfor
m>
>
guard operations... (abstract)action methods... (abstract)
<<man-code>>
AProcess.java
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 © 2 0 0 4 M a rk u s V ö l t e r. - 52 -
MDSD Best Practices
C O N T E N T S
• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Testing
• Multi Model
• Adopting MDSD The End.
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 © 2 0 0 4 M a rk u s V ö l t e r. - 53 -
MDSD Best Practices
Some advertisement
• For those, who happen to speak(or rather, read) german:
Völter, Stahl:
Modellgetriebene SoftwareentwicklungTechnik, Engineering, Management
dPunkt, 2005
www.mdsd-buch.de
• For all others:A updated translation isunder way:Model-Driven Software Development, Wiley, Q2 2006
www.mdsd-book.org