Transcript Kein Folientitel

MDSD Best Practices
www.mdsd-buch.de
Model-Driven
Software Development
Best Practices
Markus Völter
[email protected]
www.voelter.de
Note:
This is an extract of a tutorial, which is an ongoing project.
Updates of the slides can be found regularly at
Thomas Stahl
[email protected]
www.bmiag.de
www.mdsd-buch.de
Please check the site for updates, if you‘re interested.
w w w.vo elter.d e
-1-
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domains, Metamodeling, Structuring
• Code Generation
• Architectural Issues
•
Tools
• Features and Structure
• Example
•
Process
•
Testing
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
w w w.vo elter.d e
-2-
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
MDSD Main Terms
ApplikationsApplikationsApplicationModell
Modell
Model
Application-Code
DSL
DSL
(e.g. Profile)
TransTransfor-formationen
mations
analyse
Individual
Code
separate
Handcrafted
Handcrafted
Individual
Code
Code
Code
Generic
Code
Plattform
Platform
• model driven
• generative
• domain specific
• re-usable
• implements a
family of
software
Repetitive
Code
Repetitive Code
uses
w w w.vo elter.d e
Domain
Architecture
-3-
creates
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Structure of Application Projects
Anwendungsprojekt
AnwendungsRepository
Manuell entwickelter Code
DomänenArchitekturRepository
Modelle
Generatorkonfiguration
Generator
Generierter Code
Plattform
Build Tool
Fertige Anwendung
w w w.vo elter.d e
-4-
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
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
Technical Subdomain 2
(e.g. Persistence)
DSL 1
w w w.vo elter.d e
Metamodel
2
-5-
DSL 2
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
Technical Subdomain 3
(e.g. GUI)
Metamodel
3
w w w.bmiag.d e
DSL 3
MDSD Best Practices
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.
w w w.vo elter.d e
-6-
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Partitions vs. Subdomains
Subdomänen
CRM
Personalwesen
Finanzbuchhaltung
Partitionen
GUI
Prozesse
Persistenz
w w w.vo elter.d e
-7-
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Model-Based Merging
Composite Model
Model I
<<interface>>
AnInterface
Model A
Model B
Component A
w w w.vo elter.d e
Component B
-8-
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Generator-Based Referencing
Model A
Model B
<<interfaceref>>
AnInterface
<<interface>>
AnInterface
operationA(): int
operationB(int):void
Component A
Component B
Generator
<<interfaceref>>
<<map>>
A::AnInterface
w w w.vo elter.d e
-9-
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
<<interface>>
B::AnInterface
w w w.bmiag.d e
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:
• The output of a higher Domain Architecture (DA) applied
to a higher model can be an input model for the next
lower DA.
• The platform of a higher DA can be build with the aid of
the next lower DA.
w w w.vo elter.d e
- 10 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Levels of MDSD II - Cascading
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
w w w.vo elter.d e
- 11 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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>>
<<generate>>
SomeComponent
w w w.vo elter.d e
- 12 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
<<gen-code>>
<<gen-code>>
Some
Component
Base.java
w w w.bmiag.d e
<<man-code>>
SomeComponent.java
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
w w w.vo elter.d e
- 13 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
<<gen-code>>
SomeEntityDAO.java
w w w.bmiag.d e
MDSD Best Practices
Levels of MDSD III – M2M Transformations III
Model
(UML)
openArchitectureWare
export
(may be repeated)
Parser
Model
(XMI)
Model
(Object Graph)
Model
Transformer
Generated
Code
Modified Model
(Object Graph)
Code
Generator
w w w.vo elter.d e
- 14 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Levels of MDSD III – M2M Transformations IV
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<generate>>
<<gen-code>>
AProcessBase
.java
1
<<gen-code>>
AProcessProcBase.java
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
w w w.vo elter.d e
- 15 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
AProcessData.java
w w w.bmiag.d e
data
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domains, Metamodeling, Structuring
• Code Generation
• Architectural Issues
•
Tools
• Features and Structure
• Example
•
Process
•
Testing
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
w w w.vo elter.d e
- 16 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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
w w w.vo elter.d e
- 17 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
Manually
Written
Source
Generated
Source
Compiler/
Build Tool
w w w.bmiag.d e
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.
a)
•
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)
w w w.vo elter.d e
- 18 -
b)
d)
c)
generated code
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
non-generated code
w w w.bmiag.d e
e)
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domains, Metamodeling, Structuring
• Code Generation
• Architectural Issues
•
Tools
• Features and Structure
• Example
•
Process
•
Testing
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
w w w.vo elter.d e
- 19 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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.
- ...
Technical
Platform/
Middleware
As a consequence, the transformations become simpler.
w w w.vo elter.d e
- 20 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
- Persistence
- Transactions
- Distribution
- Scheduling
- Hardware Access
- ...
Programming Language
Operating System
w w w.bmiag.d e
MDSD Best Practices
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.
w w w.vo elter.d e
- 21 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Descriptive Metaobjects
•
The generated application often needs information
about some model elements at run time to control
different aspects of the applicaton platform.
•
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.
w w w.vo elter.d e
- 22 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domains, Metamodeling, Structuring
• Code Generation
• Architectural Issues
•
Tools
• Features and Structure
• Example
•
Process
•
Testing
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
w w w.vo elter.d e
- 23 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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 to simple code generators or technology
specific generators (e.g. for J2EE).
w w w.vo elter.d e
- 24 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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
w w w.vo elter.d e
- 25 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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.
w w w.vo elter.d e
- 26 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Modular Transformations
•
In order to more easily reuse parts of a transformation, it
is a good idea to modularize a transformation.
•
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
Process
Metamodel
Bank /
Prozess
Process/
J2EE
J2EE/
IBM
J2EE/
BEA
BEA/
Java
WLS
Metamodel
Java
Metamodel
IBM/
Java
w w w.vo elter.d e
- 27 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
WebSphere
Metamodel
MDSD Best Practices
Modular Transformations II
•
Example cont’d:
Now consider a Call-Center application; only the first step
needs to be adapted.
CC /
OO
OO Metamodel
...
CallCenter
Metamodel
...
Process
Metamodel
CC /
Prozess
•
...
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
w w w.vo elter.d e
- 28 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domains, Metamodeling, Structuring
• Code Generation
• Architectural Issues
•
Tools
• Features and Structure
• Example
•
Process
•
Testing
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
w w w.vo elter.d e
- 29 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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 …) –
i.e. concrete syntax is irrelevant
• 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)
w w w.vo elter.d e
- 30 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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
w w w.vo elter.d e
- 31 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Example Tool: openArchitectureWare Generator
•
How it works:
specification
(model)
metamodel
instance of
model parser
metamodel
instance
written in
terms of
w w w.vo elter.d e
- 32 -
template
engine
output code
templates
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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
w w w.vo elter.d e
- 33 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domains, Metamodeling, Structuring
• Code Generation
• Architectural Issues
•
Tools
• Features and Structure
• Example
•
Process
•
Testing
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
w w w.vo elter.d e
- 34 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
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.
•
Domain Architecture develops iteration n+1 whereas
application developers use iteration n.
•
Introduce new
Domain Architecture
releases only at the
beginning of
iterations.
Application
Development
(n)
feedback
Integration
and
Feedback
Infrastructure
Development
(n+1)
w w w.vo elter.d e
- 35 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
MDSD Process
•
Domain Architecture Development
Domäne
Transformationen
Domänenanalyse/
Design
Plattform
Plattform
Platffrom
(initial)
Prototyping
DSL/
Metamodell
Referenzimplementierung erstellen
DSL-Editor
erstellen
Plattformentwicklung
Referenzimplementierung
Referenzmodell
erstellen
MDSDPlattform
Referenzmodell
w w w.vo elter.d e
- 36 -
Transformationen
ableiten
Programmiermodell
dokumentieren
Transformationen
ProgrammierModell
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Adopting MDSD
Traditionelle
Softwareentwicklung
Ausgereifte, Iterative
Softwareentwicklung
Etablieren eines
disziplinierten, iterativen
Anforderungsmanagements
Entwickeln
einer Referenzimplementierung
Klassifizieren
des SoftwareInventars
Implementieren eines gemanagten
Prozesses
Extrahieren der
Infrastruktur
Definieren der
Software Supply
Chain
MDSD-basierte
Anwendungsentwicklung
Weiterentwikkeln der
Infrastruktur
Standardisierung
der Infrastruktur
Entwicklung einer
domänenspezifischen
Anwendungsplattform
Architekturzentrierte MDSD
Nicht gemanagter Prozess
Legende:
MDSD
Nicht-MDSD
w w w.vo elter.d e
Applikations-Engineering
- 37 -
Domänen-Engineering
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domains, Metamodeling, Structuring
• Code Generation
• Architectural Issues
•
Tools
• Features and Structure
• Example
•
Process
•
Testing
Model-Driven
Software
Development
www.mdsd-buch.de
Best Practices
w w w.vo elter.d e
- 38 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
The Role of Testing in SW Development
• Typically software cannot be verified formally, so it must be
•
tested.
There are different kinds of tests:
• Component tests (as JUnit)
• Integration tests
• Acceptance tests
• GUI driven tests (as integration or acceptance tests)
• Non functional tests
• Performance and load tests
• Regression tests
• All these tests are relevant in an MDSD-Project.
• Some of these tests can be optimized by MDSD or should
•
have a special form in that context.
In MDSD we can separate tests of applications and
Domain Architectures.
w w w.vo elter.d e
- 39 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Unit Testing and MDSD
• Separate test cases from test data
• Generate the test infrastructure
• Test cases based on (OCL-)constraints can be generated
from the domain models
• Generate Code for setup, execution and checking the
postcondition, or
• Generate Assertions within the application that are executed
through integration tests
• Eventually use a framework or interpreter to delegate the
constraint evaluation/execution
• Define testable architectures
• Use or generate Mocks
• Testware can be modelled (as decoration of the domain
model) and generated.
w w w.vo elter.d e
- 40 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
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.
w w w.vo elter.d e
- 41 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
A new potential: Model Validation
• In many cases it is possible to detect design errors already
in the models. This step is called model validation.
• 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.
w w w.vo elter.d e
- 42 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Model Validation Example
• Validation in the metamodel (Implemented)
public class ECInterface
extends generatorframework.meta.uml.Class {
public String CheckConstraints() {
Checks.assertEmpty( this, Attribute(),
"must not have attributes." );
}
// more …
public class Component extends
}
generatorframework.meta.Class {
public String CheckConstraints() {
Checks.assertEmpty( this, Operation(),
"must not have attributes." );
Checks.assertEmpty( this, Generalization(),
"must not have superclasses or subclasses." );
Checks.assertEmpty( this, Realization(),
"must not implement any interface." );
Checks.assertUniqueNames( this, Port(),
"a component's ports must have unique names." );
}
// more …
}
w w w.vo elter.d e
- 43 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Testing the Domain Architecture
• Use a (generic) generator and assume it‘s correct (like
you assume the Java compiler to be correct, when you write
test code for your application).
• Metamodel implementations, transformations and meta
constraints (i.e. part of the Domain Architecture) are
software and have to be tested though.
• Don‘t write explicit unit tests for the transformations,
because it would be an over-specification.
• Test them implicitly by testing at application level
• Modularity can be achieved by setting up small test
„applications“ just covering one or few constructs from the
DSL.
w w w.vo elter.d e
- 44 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
CONTENTS
•
Domain Architecture
• Domains, Metamodeling, Structuring
• Code Generation
• Architectural Issues
•
Tools
• Features and Structure
• Example
•
Process
•
Testing
Model-Driven
Software
Development
www.mdsd-buch.de
THE END.
Best Practices
w w w.vo elter.d e
- 45 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e
MDSD Best Practices
Some advertisement 
•
Thomas Stahl, Markus Völter
•
Modellgetriebene
Softwareentwicklung
Techniken, Engineering, Management
•
dPunkt.verlag
•
www.mdsd-buch.de
•
Out now !
w w w.vo elter.d e
- 46 -
© 200 5 Ma rk u s Vö l ter, Thomas Stahl
5
w w w.bmiag.d e