Transcript Kein Folientitel

MDSD
Best Practices
Note:
This tutorial is an ongoing project.
Updates of the slides can be found regularly at
Markus Völter
[email protected]
www.voelter.de
www.voelter.de/services/mdsd-tutorial.html
Please check the site for updates, if you‘re interested.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-1-
© 2004 M a rk us Vö l te r
About me
•
•
Independent Consultant
•
Focus on
• Software Architecture
• Middleware
• Model-Driven Software
Development
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
CONTENTS
•
•
Intro – What is MDSD
Best Practices
• Domain Construction & Code Generation
• Tool Construction and Selection
• Process
• Testing
• Versioning and Multi-Model/Multi-Site
•
End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-3-
© 2004 M a rk us Vö l te r
CONTENTS
•
•
Intro – What is MDSD
Best Practices
• Domain Construction & Code Generation
• Tool Construction and Selection
• Process
• Testing
• Versioning and Multi-Model/Multi-Site
•
End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-4-
© 2004 M a rk us Vö l te r
Model Driven Software Development Overview
several
target
software
architecture
Metametamodel
subdomains
design
expertise
Application
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
-5-
© 2004 M a rk us Vö l te r
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
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-6-
© 2004 M a rk us Vö l te r
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.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-7-
© 2004 M a rk us Vö l te r
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
-8-
© 2004 M a rk us Vö l te r
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
-9-
© 2004 M a rk us Vö l te r
CONTENTS
•
•
Intro – What is MDSD
Best Practices
• Domain Construction & Code Generation
• Tool Construction and Selection
• Process
• Testing
• Versioning and Multi-Model/Multi-Site
•
End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 10 -
© 2004 M a rk us Vö l te r
Believe in Re-Incarnation
•
The final, implemented application should be built by a
build process that includes re-generation of all
generated/transformed parts.
• …which includes more than just code – see LEVERAGE THE
MODEL
•
As soon as there is one manual step, or one line of
code that needs to be changed after generation, then
sooner or later (sooner is the rule) the generator will be
abandoned, and the code will become business-as-usual.
•
Note that this pattern does not receommend to
generate as much stuff as possible.
• You should use a RICH DOMAIN-SPECIFIC PLATFORM,
• And SELECT FROM BUILD, BUY OR OPEN SOURCE
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 11 -
© 2004 M a rk us Vö l te r
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
- 12 -
© 2004 M a rk us Vö l te r
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
- 13 -
© 2004 M a rk us Vö l te r
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.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- ...
Technical
Platform/
Middleware
- Persistence
- Transactions
- Distribution
- Scheduling
- Hardware Access
- ...
Programming Language
Operating System
- 14 -
© 2004 M a rk us Vö l te r
Technical Subdomains
•
Structure your system into several technical
subdomains such as persistence, GUI, deployment.
•
Each subdomain should have its own meta model and
specifically, its own suitable DSL.
•
Define a small number of GATEWAY META CLASSES, i.e.
meta model elements that occur in several meta
models to help you join the different aspects together.
Technical Subdomain 1
(e.g. Business logic)
Metamodel
1
DSL 1
Technical Subdomain 2
(e.g. Persistence)
Metamodel
2
ingenieurbüro für sof twaretechnologie
DSL 2
.
w w w.vo el ter.d e
Technical Subdomain 3
(e.g. GUI)
Metamodel
3
- 15 -
DSL 3
© 2004 M a rk us Vö l te r
Gateway Metaclasses
•
Using TECHNICAL SUBDOMAINS results in different
meta models as well as different concrete syntax for
the different subdomains.
• Example: workflow/using activity diagrams, Layout/
textual, XML-like language.
•
If you want to generate a system from these different
specifications, your generator needs a mechanism to get
from one model to the other:
• you need model elements that are present in the meta
models of both TECHNICAL SUBDOMAINS. IGNORING
CONCRETE SYNTAX in your generator makes this simpler.
• The second thing you need is a common meta meta
model. For example, Java classes to be used as the meta
meta model for all meta models.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 16 -
© 2004 M a rk us Vö l te r
Generator-based AOP
•
Implement the handling of cross-cutting concerns with
the help of the generator.
• You can either take advantage of the generator’s
integral features (e.g. consider that it generates many
instances of a meta model element with the help of one
transformation/template), or
• Weave various “aspect models” in the generator
• use the generator to implement proxies, interceptors
and other AOP-addressing design patterns in the
generated system.
•
Consider the cross-cutting concern a TECHNICAL
SUBDOMAIN and provide a suitable DSL for it.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 17 -
© 2004 M a rk us Vö l te r
Generator-based AOP II
•
Example:
String anOperation(x) {
checkSecurity(this, "anOperation", {x} ,
someClientID);
bill(this, "anOperation", someClientID );
return delegate.anOperation(x)
}
delegate
<<Service>>
SomeService
anOperation(x): String
anotherOperationx,y):void
manually
implemented
business logic
SomeService
SomeServiceOperations
anOperation(x): String
anotherOperationx,y):void
anOperation(x): String
anotherOperationx,y):void
generated
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 18 -
© 2004 M a rk us Vö l te r
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
- 19 -
© 2004 M a rk us Vö l te r
Descriptive Metaobjects
•
The generated application often needs information
about some model elements at run time to control
different aspects of the applicaton plaform.
•
Use the information available at generation time to codegenerate meta objects that describe the generated
artifacts.
•
Provide a means to associate a generated artifact with
its meta object.
• You add a getMetaObject() operation to the generated
artifact.
• You can also use a central registry that provides a lookup
function MetaRegistry.getMetaObjectFor(anArtefact). The
implementation for the operations will be generated, too.
•
Make sure the meta objects have a generic interface
that can be accessed by the RICH DOMAIN-SPECIFIC
PLATFORM.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 20 -
© 2004 M a rk us Vö l te r
Descriptive Metaobjects II
•
Example:
<<interface>>
ClassMetaObject
<<interface>>
AttributeMetaObject
getAttributeNames() : String[]
getAttribute(name:String):AttributeMetaObject
getName() : String
getValue() : Object
setValue( Object newVal ) : void
getLabel()
<<interface>>
StringAttributeMetaObject
Model
SomeClass
<<pk>> name : String
{label="Nachname"}
firstname : String
{label="Vorname"}
age : int
{label="Alter",
min=0, max=100}
zip : String
{label="PLZ",
regexp="99999"}
<<interface>>
NumAttributeMetaObject
getRegexp() : String
getMin() : int
getMax() : int
<<instanceof>>
<<instanceof>>
<<instanceof>>
meta
:SomeClassMetaObject
:StringAttributeMetaObject
attributeNames : String =
{"name", "firstname",
"age", "zip"}
name : String = "zip"
label : String = "PLZ"
:NumAttributeMetaObject
Generated
Code
SomeClass
name : String
vorname : String
age : int
zip : String
ingenieurbüro für sof twaretechnologie
...
.
w w w.vo el ter.d e
name : String = "age"
label : String = "Alter"
min : int = 0
max : int = 100
- 21 -
© 2004 M a rk us Vö l te r
Generated Reflection Layer
•
•
You can even go one
step further and generate
an “interpreter”, a
reflection layer that allows
you to
• “script” the system
• build IDEs
Since the reflection layer
is separate from the core
classes, it can be excluded
from the „real“ system for
(performance reasons)
ingenieurbüro für sof twaretechnologie
public interface RClass {
// initializer – associates with
// base-level object
public setObject( Object o );
// retrieve information about
//the object
public ROperation[] getOperations();
public RAttribute[] getAttributes();
// create new instance
public Object newInstance();
}
public interface ROperation {
// retrieve information about op
public RParameter[] getParams();
public String getReturnType();
// invoke
public Object invoke(Object params)
}
public interface RAttribute {
// retrieve information about op
public String getName();
public String getType();
// set / get
public Object get();
public void set( Object data );
}
.
w w w.vo el ter.d e
- 22 -
© 2004 M a rk us Vö l te r
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
- 23 -
© 2004 M a rk us Vö l te r
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
- 24 -
© 2004 M a rk us Vö l te r
Select from Buy, Build or Open Source
•
It is typically not a good idea to re-invent the wheel,
even in case the wheel is generated.
•
Don't be blinded and ignore the potential of well-proven
off-the-shelf products and robust Open Source
infrastructure that is used by thousands of organizations!
•
However, do LEVERAGE THE MODEL and don't
compromise hard-earned domain knowledge that has
gone into your domain-specific frameworks and generators
by replacing them with unrefined and blunt off-the shelf
tools.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 25 -
© 2004 M a rk us Vö l te r
CONTENTS
•
•
Intro – What is MDSD
Best Practices
• Domain Construction & Code Generation
• Tool Construction and Selection
• Process
• Testing
• Versioning and Multi-Model/Multi-Site
•
End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 26 -
© 2004 M a rk us Vö l te r
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
- 27 -
© 2004 M a rk us Vö l te r
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
- 28 -
© 2004 M a rk us Vö l te r
Tools: Examples
• Rational XDE
• AndroMDA
• Velocity
• XML + XSLT
• openArchitectureWare
• Xdoclet
• ArcStyler
• iUML
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 29 -
© 2004 M a rk us Vö l te r
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
- 30 -
© 2004 M a rk us Vö l te r
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
- 31 -
© 2004 M a rk us Vö l te r
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
- 32 -
Transformer
© 2004 M a rk us Vö l te r
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
- 33 -
© 2004 M a rk us Vö l te r
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
- 34 -
WebSphere
Metamodel
© 2004 M a rk us Vö l te r
Modular, Automated Transforms II
•
Example cont’d:
Now consider a Call-Center application; only the first step
needs to be adapted.
CC /
OO
OO Metamodel
...
CallCenter
Metamodel
...
CC /
Prozess
•
Process
Metamodel
...
If both should be transformed to .NET, only the backend
needs to be exchanged.
OO Metamodel
OO/
.NET
.NET Metamodel
Process
Metamodel
.NET/
C#
C# Metamodel
Prozess/
.NET
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 35 -
© 2004 M a rk us Vö l te r
Build an IDE
•
Model-Driven Software Development often includes a
wealth of input, intermediate and output artifacts.
•
Users (application developers) can easily be confused by
these many artifacts.
•
To improve acceptance of the approach, you should
consider building an IDE for application developers
which
• Hides unnecessary intermediate artifacts
• Provides editors/support for “programming” with the DSL
• Integrates all the validation, generation, build, etc.
•
Eclipse, for example, is a good toolkit for building these
kinds of IDEs.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 36 -
© 2004 M a rk us Vö l te r
Two-Stage Build
•
Separate the generation run into two stages:
• the first stage reads some kind of configuration and
prepares the actual generator for the core
transformation.
• The second stage is the execution of the transformer
and uses the preparations done in the first stage.
System
configuration
Stage 1
Tool
Generator
configuration
Application
Model
Transformer/
Generator
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
Generated
Application
- 37 -
© 2004 M a rk us Vö l te r
Two-Stage Build II
•
Example:
System Development
Architecture
Development
<<instanceof>>
Meta-Modell
Templates
Libraries
Platform(s)
<<instanceof>>
Business
Logic
Development
Manual Code
Functional
Model
System Manufacturing/Assembly
Platform
Selection/
Configuration
Target Spec
Deployment
Spec
Feature
Spec
Effective
Templates
Effective
Libraries
Generated
Build File
Generated
Code
Generated
Config Files
Target
Image
Generated
Config Files
Generator
Configuration
Code
Generation
Compilation/
Build
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
Platform(s)
- 38 -
© 2004 M a rk us Vö l te r
CONTENTS
•
•
Intro – What is MDSD
Best Practices
• Domain Construction & Code Generation
• Tool Construction and Selection
• Process
• Testing
• Versioning and Multi-Model/Multi-Site
•
End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 39 -
© 2004 M a rk us Vö l te r
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
- 40 -
© 2004 M a rk us Vö l te r
MDSD Process II
Domain Architecture Development
Erstellung der
generativen
Architektur
nicht-funktionale
Anforderungen
Anwendungsarchitektur
konzipieren
technisches
Glossar
Konzept
Domänenarchitektur / Generative Architektur
•
Laufzeitkomponenten
Laufzeitkomponenten
erstellen
Referenzimplementierung
DesignSprache
Referenzimplementierung erstellen
Muster
identifizieren
Referenzdesign
erstellen
Referenzdesign
Generatorkonfiguration
ingenieurbüro für sof twaretechnologie
Generatorkonfiguration ableiten
.
w w w.vo el ter.d e
- 41 -
© 2004 M a rk us Vö l te r
Scope Trading
•
Use a formal scope trading workshop at the beginning
of each iteration (for Domain Architecture as well as for
application development).
•
All relevant stakeholders (including end users) need to
be represented in the workshop.
•
Document results and
make sure everybody
understands and agrees.
•
Set priorities in the
upcoming iteration based
on the results of the
workshop.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 42 -
© 2004 M a rk us Vö l te r
Validate Iterations
•
Each timebox is concluded with a formal iteration
validation workshop to confirm progress
•
Let an end user that acted as the on-site customer drive
the demonstration of implemented features.
•
Explicitly communicate to the end user and stakeholder
community that new requirements can be brought up
at any point.
•
Encourage exploration of "what-if" scenarios—
stakeholders may develop a new idea while watching the
demonstration
•
Similarly the architect may want to raise issues that may
have escaped the requirements elicitation process and
that have been uncovered by the development team.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 43 -
© 2004 M a rk us Vö l te r
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
- 44 -
© 2004 M a rk us Vö l te r
CONTENTS
•
•
Intro – What is MDSD
Best Practices
• Domain Construction & Code Generation
• Tool Construction and Selection
• Process
• Testing
• Versioning and Multi-Model/Multi-Site
•
End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 45 -
© 2004 M a rk us Vö l te r
The Role of Testing in SW Development
• In all but very few cases, the correctness of software
cannot be verified theoretically or formally.
• Thus the only way of verifying a system does what it should
do is by testing it extensively.
• There are different kinds of things that can be tested:
• Ensuring that the software does what the developer wanted
it to do
• Ensuring that what the developer programmed is actually what
the system should do (i.e. what the customer wants)
• Ensuring that the system performs and scales adequately
• Ensuring that other non-functional properties work as
specified (such as transactions, security, ...)
• Ensuring that the tools and technologies used in the
implementation work together well
• We will now look at each of these in the context of MDD.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 46 -
© 2004 M a rk us Vö l te r
Unit Testing
• Ensuring that the code does what the developer wants is
called Unit Testing.
• Tools such as JUnit provide a framework to implement and
repeatedly execute unit tests
• They are written by the developer as he develops his code.
• Typically, they test functionality, not nun-functional properties
• In the context of MDD, unit tests can be generated from
models, too
• Tests for static properties can be generated directly from the
model.
• For behavioral aspects, It should be a different model –
because if tests are created from the same model as the
implementation code, tests will always pass.
• Additional Testcases can also be generated from OCL
expressions (invariants, as well as pre- and postconditions).
• When the code is generated, we can even embed OCL
constraint evaluation into the generated code and check
these at runtime.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 47 -
© 2004 M a rk us Vö l te r
Unit Testing Example
• Consider the following model:
Vehicle
Vehicle.setDriver(p):
pre: p.age >= 18
Person
age: int
setDriver( Person p )
Person:
inv: age > 0
&& age <=100
driver
• This could result in the following code:
class Vehicle {
...
public void setDriver( Person p ) {
if (driver.getAge() < 18 ) throw new ConstraintViolated();
}
}
• A similar approach could be taken for the invariant in Person.
• In case of the invariant, it is easy to automatically create a
set of unit tests that check ages like 0, 16, 78, 120, -1, 3.4
and see if the system behaves accurately.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 48 -
© 2004 M a rk us Vö l te r
Requirements Testing
• Here we want to make sure that the system does what the
customer (or the requirements) say.
• We use the same technical approach here as for unit
testing. However, here the test cases are written by domain
experts and not by the developer.
• If models are annotated with OCL constraints, they are
significantly more rich that „typical“ requirements. A lot of
test cases can be generated from these models.
• If we have a suitable, high-level modeling notation (such as a
UML profile), the domain expert can even specify test
models himself, or with some support by a technical person.
• Because of the domain-specific notation, developer/
customer communication about tests is simplified.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 49 -
© 2004 M a rk us Vö l te r
Performance and Scalability Testing
• This kind of testing basically works by simulating a certain
number of clients and then measuring response times
and resource consumption.
• Running such tests always requires a setup of an
environment similar to the production environment.
This is typically done manually, although some deployment
artifacts can be generated from models.
• The simulated clients can often be generated completely.
The input is basically
• Which operations to call
• At which sequence and intervals
• In how many parallel threads or processes
• And where to store the timing measurements and in which
format
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 50 -
© 2004 M a rk us Vö l te r
Performance and Scalability Testing Example
• A statechart can be used to specify this behaviour:
login()
checkOut()
[tm(5000)]
doSearch(...)
[tm(2000)]
[tm(5000)]
buyItem()
[tm(4000)]
buyItem(...)
• Note that we do not care about errors and functional
testing here. This is done in other test!
• This statechart can be code generated into a client.
• An additional (textual) specification defines how many
parallel threads and processes we have.
• Tools for this task are also available outside MDD.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 51 -
© 2004 M a rk us Vö l te r
Testing non-functional properties
• In contrast to functional unit tests, these kinds of tests
cannot be run in a simplified testing environment,
because non-functional problems only show up under realistic
circumstances (many parallel users, database crashes, ...)
• Many kinds of tests can only be done manually, for
example trying to „hack“ into a system to test its security.
• Some tests can be automated based on constraints,
however. There is an example on the next page.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 52 -
© 2004 M a rk us Vö l te r
Testing non-functional properties: Example
• Consider the following model:
BankingServices.transfer(to: Account,
from: Account, amout: double):
post: (from.balance =
from.balance@pre - amount)
&&
(to.balance =
to.balance@pre + amount)
BankingServices
transfer(from: Account, to:
Account, amout:
double):void
Account
balance:double
• While the constraint may look like a purely functional
constraint, it is actually a non-functional constraint with
regards to transactions in a real-world scenario.
• It can be verified in tests that run against the deployed
system while power outages, database crashes, etc. are
simulated.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 53 -
© 2004 M a rk us Vö l te r
Tools and Technology Testing
• Tools in this context are for example, Databases,
Middleware, Application Servers, etc.
• Tools and Technology testing deals with questions such as
whether the system delivers the expected performance and
reliability when deployed using the tool.
• Many of these things can be tested automatically using unit
or performance testing.
• There is an important additional aspect, though: Many
problems with tools and technology arise from developers
using the tool in a way different than anticipated.
• These kinds of errors are minimized if the code that uses the
tools is generated. The generator – once correctly implemented –
always uses the tools in the same, correct way.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 54 -
© 2004 M a rk us Vö l te r
Additional Tests: Model Verification
• In many cases it is possible to detect design errors already
in the models. This step is called model verification.
• The most „extreme“ form is to interpret and simulate the
whole model; this is however, not simple to achieve,
although there are „UML VMs“.
• However, it is easily possible to verify design constraints in
the model before model transformation or code generation
steps are done. Example:
<<TENA_class>>
Platform
<<configparam>> serverIP: string
<<configparam>> serverPort: string
position: TSPI
ingenieurbüro für sof twaretechnologie
generate(TENA_class) {
[...]
foreach ConfigParam p {
if p.type != „string“ {
error „only strings allowed“+
„for config configparams“
} else {
generate(p)
}
}
}
.
w w w.vo el ter.d e
- 55 -
© 2004 M a rk us Vö l te r
Model Verification Example
• Again the metamodel introduced before:
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 56 -
© 2004 M a rk us Vö l te r
Additional Tests: Model Verification II
• This template is used to generate IDL code from the model:
«DEFINE Root FOR TENAInterface»
«IF isInPackage»
package «Package.Name» {
«ENDIF»
interface «Name»
«IF hasSuperClass»:
«FOREACH Generalization.SuperClass AS sc EXPAND USING SEPARATOR ", "»
«sc.Name»
«ENDFOREACH»
«ENDIF»
{
«EXPAND Operation::Declaration FOREACH Operation USING SEPARATOR "\n"»
};
// generated code
«IF isInPackage»
};
«ENDIF»
«ENDDEFINE»
ingenieurbüro für sof twaretechnologie
package omtest {
interface Controllable {
TENA_string initialize(
TENA_string start( );
TENA_string stop( );
};
};
.
w w w.vo el ter.d e
- 57 -
);
© 2004 M a rk us Vö l te r
Additional Tests: Model Verification III
• Metaclass used in the generator, this has model verification
code in it:
public class TENAInterface éxtends Class {
[...}
public String CheckConstraints() throws DesignException {
Checks.ensure( this, Checks.containsOnlyNElements(
Attribute, 0, Messages.INTERFACE_NO_ATTRIBUTES ) );
Checks.ensure( this, Checks.containsOnlySpecificRealizationTypes(
this, TENAInterface.class, Messages.
INTERFACE_NOT_IMPLEMENT_INTERFACES ) );
Checks.ensure( this, Checks.containsOnlySpecificSuperClassTypes(
this, TENAInterface.class, Messages.
INTERFACE_EXTEND_OTHER_INTERFACES ) );
Checks.ensure( this, Checks.notContainsSpecificOperationTypes(
this, TENALocalOperation.class, Messages.
INTERFACE_NO_LOCAL_OPERATIONS ) );
return super.CheckConstraints();
}
}
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 58 -
© 2004 M a rk us Vö l te r
Additional Tests: Generator Testing
• Many if not all of the previous statements on testing were
based on the assumption that the generator works fine.
• Of course, this has to be tested also, at least in the early
stages of the generator or the metamodel.
• Over time, however, the generator will become a stable
asset that works reliably. Or you can buy one and trust it ....
Just as you trust C++/Java/etc. compilers.
• The effort to develop/adapt reliable generators is of course
considerable. This goes back to the issue on reuse,
software system families and economical aspects
discussed earlier.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 59 -
© 2004 M a rk us Vö l te r
Generator Testing: 2 Channel Concepts
• In safety-critical systems, the concept of independent
channels
• It is used to ensure that a failure in a system cannot go
undetected by a second channel;
• and to ensure that is is very unlikely that a failure does not affect
both channels at the same time.
Generator 1
+
Configuration 1
Implementation
Code
Generator 2
+
Configuration 2
Test Code
Model
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 60 -
© 2004 M a rk us Vö l te r
Generator Testing: 2 Channel Concepts II
• If one generator or configuration fails, it is assumed that
the other one does not fail and will thus detect the failure.
• This does not detect failures in the model, of course. To
detect those, we would need to extend the 2 channel
concept to include the model.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 61 -
© 2004 M a rk us Vö l te r
CONTENTS
•
•
Intro – What is MDSD
Best Practices
• Domain Construction & Code Generation
• Tool Construction and Selection
• Process
• Testing
• Versioning and Multi-Model/Multi-Site
•
End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 62 -
© 2004 M a rk us Vö l te r
Projects and Dependencies
Anwendung 1
Plattform
Anwendung 2
Anwendung n
DomänenArchitektur
Generatorkonfiguration
Generator
ingenieurbüro für sof twaretechnologie
Applikationen
Tools
.
w w w.vo el ter.d e
- 63 -
© 2004 M a rk us Vö l te r
Structure of Application Projects
Anwendungsprojekt
AnwendungsRepository
Manuell entwickelter Code
DomänenArchitekturRepository
Modelle
Generatorkonfiguration
Generator
Generierter Code
Plattform
Build Tool
Fertige Anwendung
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 64 -
© 2004 M a rk us Vö l te r
Partitions vs. Subdomains
Subdomänen
CRM
Finanzbuchhaltung
Personal-wesen
Partitionen
GUI
Prozesse
Persistenz
ingenieurbüro für sof twaretechnologie
M
E
ST
SY
.
w w w.vo el ter.d e
- 65 -
© 2004 M a rk us Vö l te r
Multi-Models: Example
<<interface>>
AnInterface
Component B
Component A
Model A
Model B
<<interface>>
<<interface>>
AnInterface
AnInterface
Component A
ingenieurbüro für sof twaretechnologie
Component B
.
w w w.vo el ter.d e
- 66 -
© 2004 M a rk us Vö l te r
Model-Based Merging
Composite Model
Model I
<<interface>>
AnInterface
Model A
Model B
Component A
ingenieurbüro für sof twaretechnologie
Component B
.
w w w.vo el ter.d e
- 67 -
© 2004 M a rk us Vö l te r
Generator-Based Merging
Model A
Model B
<<interface>>
<<interface>>
AnInterface
AnInterface
Component A
Component B
Mapping
Apecification
Generator
<<interface>>
<<map>>
A::AnInterface
ingenieurbüro für sof twaretechnologie
<<interface>>
B::AnInterface
.
w w w.vo el ter.d e
- 68 -
© 2004 M a rk us Vö l te r
Generator-Based Referencing
Model A
Model B
<<interface>>
<<interfaceref>>
AnInterface
AnInterface
operationA(): int
operationB(int):void
Component A
Component B
Generator
<<interfaceref>>
<<interface>>
<<map>>
A::AnInterface
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
B::AnInterface
- 69 -
© 2004 M a rk us Vö l te r
CONTENTS
•
•
Intro – What is MDSD
Best Practices
• Domain Construction & Code Generation
• Tool Construction and Selection
• Process
• Testing
• Versioning and Multi-Model/Multi-Site
•
End.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 70 -
© 2004 M a rk us Vö l te r
Some advertisement 
•
Völter, Stahl, Bettin
•
Modellgetriebene
Softwareentwicklung
•
Ein Leitfaden für die
pragmatische Arbeit mit
der Model Driven
Architecture (MDA)
•
dPunkt 2004
•
Not yet published…
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 71 -
© 2004 M a rk us Vö l te r
The End.
Thanks
Questions?
Comments?
Criticism?
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 72 -
© 2004 M a rk us Vö l te r