Transcript Kein Folientitel

Model-Driven Development of Distributed, Component-Based Systems
Model-Driven Development
of component-based,
Distributed systems
Markus Völter
[email protected]
www.voelter.de
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-1-
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
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
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Overview
•
These slides are composed of three parts. All parts are
rather pragmatic and based on actual experience from
many projects, in various (enterprise and embedded)
domains.
•
Part 1, Introduction to MDSD
Introduces Model-Driven Software Development and
teaches a couple of essential best practices.
•
Part 2, Software Architectural Approach
Explains how (I think) software architecture should be
addressed in non-trivial projects. Illustrated with a
component-based application from the enterprise world.
•
Part 3, A Components Reference Metamodel
This section introduces a way to describe component
based systems in a way that allows for all-aspect code
generation. The description is introduced in the form of a
metamodel.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-3-
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
CONTENTS
PART 1:
Introduction to MDSD
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 Development of Distributed, Component-Based Systems
C O N T E N T S: Part 1, Introduction to MDSD
•
•
•
•
•
What is MDSD
Benefits
Mechanics and Tooling
Process Issues
Some Essential Best Practices
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-5-
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 1, Introduction to MDSD
•
•
•
•
•
What is MDSD
Benefits
Mechanics and Tooling
Process Issues
Some Essential Best Practices
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-6-
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Domain Driven Development
•
Domain Driven Development is about making software
development more domain-related as opposed to
computing related. It is also about making software
development in a certain domain more efficient.
Domain Concepts
Domain Concepts
mental work
of developers
Software Technology
Concepts
ingenieurbüro für sof twaretechnologie
Software Technology
Concepts
.
w w w.vo el ter.d e
-7-
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
MDSD on a Slide
several
Metametamodel
target
software
architecture
design
expertise
subdomains
bounded area of
knowlege/interest
partial
composable
multi-step
multiple
knowledge
transform
viewpoint
Domain
single-step
compile
Model
semantics
Ontology
interpret
no
roundtrip
precise/
executable
Domain
Specific
Language
graphical
Metamodel
textual
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-8-
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
MDSD Core Values
•
We prefer to validate software-under-construction over
validating software requirements
•
We work with domain-specific assets, which can be
anything from models, components, frameworks,
generators, to languages and techniques.
•
We strive to automate software construction from
domain models; therefore we consciously distinguish
between building software factories and building software
applications
•
We support the emergence of supply chains for
software development, which implies domain-specific
specialization and enables mass customization
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
-9-
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
MDSD Core Building Blocks
•
domain analysis
•
meta modelling
•
model-driven generation
(and: model transformation)
•
template languages
•
domain-driven framework design
•
the principles for agile software development
•
the development and use of Open Source infrastructure
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 10 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
DSLs in Industry
•
Model-Driven Development (MDSD)
pragmatic technology, process building blocks
•
OMG’s Model-Driven Architecture (MDA)
standardization effort, technology-focus, platform
independence, m2m transformations
•
Microsoft’s Software Factories (SF)
framework for domain-specific IDE tooling, DSLs are part
of this approach
•
Generative Programming (GP)
traditional small scale, technology focused
•
Language-Oriented Programming (LOP)
integrate DSLs into IDE with editors, debuggers, symbolic
integration
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 11 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Reasons for using DSLs
• You want to provide a way for your domain-experts to
formally specify their knowledge, and to provide a way
for your technology people to define how this is implemented
(using model transformations).
• You might want to provide different implementations (i.e.
more concrete models) for the same model, perhaps
because you want to run it on different platforms (.NET, Java,
CORBA).
• You may want to capture knowledge about the domain, the
technology, and their mapping in a clear, uncluttered format.
• In general, you don’t want to bother with
implementation details when specifying your functionality.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 12 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 1, Introduction to MDSD
•
•
•
•
•
What is MDSD
Benefits
Mechanics and Tooling
Process Issues
Some Essential Best Practices
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 13 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
MDSD Benefits I
•
Models are free of implementation artifacts – they directly
represent domain knowledge and are thus reusable.
•
Implementations for various platforms can be generated in
principle – the technology change problem is adressed to
some extend.
•
Technology freaks and domain experts can take care of
„their business“ (transformations and models, respectively)
and need to care of each other‘s problems only in a limited
way.
•
Domain experts can play a direct role in development
since they can more easily understand models expressed with
a DSL as opposed to implementation code.
 Domain Experts play the central role they deserve!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 14 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
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
- 15 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Benefits for Software Quality
•
DSLs, if they describe software structure/architecture requires
an explicit, well-defined architecture. Defining an
architecture this way improves the quality of the system
(indpendent of whether it is generated or not).
•
Transformations capture expert knowledge. The
generated code reflects this expert knowledge uniformly.
•
An DSL-based Archtitecture defines a strict programming
model for the manually developed parts – again, uniformity
and constrained-ness improves quality.
•
Generator does not produce accidental errors – either
things are always right or always wrong. This makes finding
errors easier!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 16 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Benefits for Software Quality II
•
In general, defining a DSL forces you to take care of many
good things, which you‘d like to have in any application
development project:
• Domain/Application Scoping
• Variability Management
• Well-Defined Software Architecture, Architecture
Metamodelling
• Trying to build a DSL/generator for a domain/target
architecture enables your understanding of the domain/target
architecture. This in itself is a huge benefit.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 17 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
DSL/Code Generation “Financial Benefits”
„Normal“ Implementation Effort
Information Gain
•
ion
entat
m
e
l
Imp
si
De
Goal
gn
Effort
is
ys
l
a
An
Level of Detail
Start
Result of
Analysis
ingenieurbüro für sof twaretechnologie
virtual or real
Implementation model
.
w w w.vo el ter.d e
Implementation
- 18 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
DSL/Code Generation “Financial Benefits” II
Realistic DSL based Implementation Effort
Information Gain
•
A'
B
Automation
enImplem
tation
Goal
M
od
el
lin
g
A
Savings
because
of Generation
An
al
ys
is
Effort
Savings based on
the use of a semantically
rich platform
Level of Detail
Start
Results of
Analysis
ingenieurbüro für sof twaretechnologie
virtual or real
implementation model
.
w w w.vo el ter.d e
Implementation
- 19 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
DSL/Code Generation “Financial Benefits” III
Ideal DSL based Implementation Effort
Information Gain
•
A'
B
Automation
Goal
de
llin
g
A
Mo
Savings
because
of generation
An
aly
sis
Effort
Savings based on
the use of a semantically
rich platform
Level of Detail
Start
Results of
Analysis
ingenieurbüro für sof twaretechnologie
virtual or real
implementation model
.
w w w.vo el ter.d e
Implementation
- 20 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 1, Introduction to MDSD
•
•
•
•
•
What is MDSD
Benefits
Mechanics and Tooling
Process Issues
Some Essential Best Practices
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 21 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
How DSLs are usually used
Developer develops model(s)
based on certain
metamodel(s), expressed
using a DSL.
•
Using code generation
templates, the model is
transformed to executable
code.
•
•
• Alternative: Interpretation
Optionally, the generated
code is merged with
manually written code.
Model
Model
Model
Metamodel
Transformer
Tranformation
Rules
Model
Metamodel
Transformer
Code
Generation
Templates
Generated Code
Manually
Written
Code
One or more model-tomodel transformation steps
may precede code generation.
optional, can be repeated
•
optional
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 22 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Example Tool: openArchitectureWare Generator
•
How it works:
specification
(model)
metamodel
instance of
model parser
metamodel
instance
written in
terms of
ingenieurbüro für sof twaretechnologie
template
engine
output code
templates
.
w w w.vo el ter.d e
- 23 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
How Transformations Work
•
Transformations (Model-2-Model as well as Model-2-Code) are
at the heart of MDSD. However, due to limitations in space
and time, I cannot provide details on how these work,
except:
•
For M2M Transformations, various textual or graphical
languages exist (or are being worked on), some of them rulebased, others imperative.
• The simplest thing that could possibly work are 3GL
procedures (e.g. in Java) that work on model elements
directly. This works well in practice if metamodel API is good.
•
For Code Generation, almost all generators use templatebased approaches, where template control code is intertwined
with to-be-generated code; the to-be-generated code is
parametrized by „properties“ that get their values from the
underlying model.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 24 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
How Transformations Work II - Example Template (oAW)
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 25 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 1, Introduction to MDSD
•
•
•
•
•
What is MDSD
Benefits
Mechanics and Tooling
Process Issues
Some Essential Best Practices
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 26 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
DSLs/Generation and Agility
•
Agile Manifesto:
We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value
the items on the left more.
•
DSL-based Models are no „paperwork“, they are the code
which is translated to executable code automatically
•
Agility does not oppose tools in general – compilers are ok,
model transformers are a kind of compiler
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 27 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
MDSD and Agility II
•
Project automation (ant, cruisecontrol) is ok in „agile
minds“, so is automation of the writing of repetitive code
•
Automation of the development process makes responding
to change easier and faster (single source principle).
• Changes in the model respond to changes in the functional
requirements
• Changes in the templates/transformations can be used to
evolve the architecture
•
The customer on-site can be integrated better, if we have
languages that are better related to domain concepts as
opposed to 3GL code or the like.
• Pair programming between developer and domain expert is
more realistic.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 28 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
MDSD and Agility III
•
Tests can still be written manually (even before generation),
generators can help is building mocks or scenarios
• We have done Test-Driven, Model-Driven Development
•
We do not recommend a waterfall that first builds
metamodel/DSL/generators and then builds apps, rather, both
are iteratively evolved in parallel.
• Domains Architectures are based on experience, not
based on „big design upfront“
•
Developers can do what they can do best:
• Some deal with applications and customer requirements,
• Others deal with technical architecture, platforms and
generators
•
So: There is no conflict between Agility and
DSLs/Generation!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 29 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Teaming issues
•
Using DSLs is not very different from “normal”
programming – every developer can basically do it.
•
Defining DSLs is, however, something completely
different:
• Finding the „right“ abstractions, defining metamodels,
keeping the various metalevels sorted, etc. is not
everybody‘s business.
• Some of the tools to define metamodels, DSLs, generators
and model-2-model transformations are not (yet)
intuitively usable.
•
Therefore I recommend to keep DSL/generator
development to a limited group of people in your
project.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 30 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Teaming issues II - Roles
•
Not all of these roles are necessary in every project,
of course
•
However, as an example, there is a fundamental difference
between those who understand the domain and its
abstractions (left branch)
compared to those who
know how to best use
Customer
some platform
technology
(right branch)
Domain Analyst
Domain Architect
Domain Expert
Language Designer
Prototype
Developer
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
Reference
Implementor
- 31 -
Platform
Developer
Transformation
Developer
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Iterative Dual Track Development
•
Develop DSL/Generator 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
DSL/Generator
releases only at the
beginning of
iterations.
Application
Development
(n)
Integration
and
Feedback
feedback
Infrastructure
Development
(n+1)
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 32 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Iterative Dual Track Development II - Roles
•
Note that the „men“ in
the diagram on the
right are roles, you
can easily have some
of them be handled
by the same person!
Application Engineering
Domain Engineering
Application
Developer
Project
Manager
Product
Manager
Test Engineer
Customer
Application
Architect
Domain
Analyst
Domain
Expert
Tester
Domain
Architect
Requirements
Analyst
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 33 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
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 DSL/Generator
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
- 34 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 1, Introduction to MDSD
•
•
•
•
•
What is MDSD
Benefits
Mechanics and Tooling
Process Issues
Some Essential Best Practices
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 35 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
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 DSLs
 see below, Cascading
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 36 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
How do I come up with a good metamodel? II
•
In order to continuously improve and validate the
metamodel 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.
•
(Based on Eric Evans’ Ubiquitous Language)
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 37 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
How do I come up with a good metamodel? III
•
Example:
owns
*
implements
1
Port
Interface
Component
provides
operations
defined by
Required Port
Provided Port
provides access to operations defined by
• A component owns any number of ports.
• Each port implements exactly one interface.
• There are two kinds of ports: required ports and provided
•
•
ports.
A provided port provides the operations defined by its
interface.
A required port provides access to operations defined by
its interface.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 38 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
One DSL is not enough
Most systems can be structured into various
• partitions: functional subsystems
• subdomains: technical aspects
•
It is hardly possible to describe each
of these with the same DSL.
• You will need to come up with
separate DSLs
• … that have to be „connectable“
in order to build the complete
system
Subdomains
•
ingenieurbüro für sof twaretechnologie
CRM
Human
Resourcs
Accounting
Partitions
GUI
M
E
ST
Processes
SY
Persistence
.
w w w.vo el ter.d e
- 39 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
One DSL is not enough II
•
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 metaclasses, 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
- 40 -
DSL 3
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
One DSL is not enough III - Example
Persistence
Business Objects
Type
Column
*
Table
type
*
maps
*
Entity
Attribute
Mapping
represents
represents
Key
Attribute
Pages, Forms and Workflow
Form Layout
target
Page
*
Form
Form
Layout
*
Button
FormField
Tabular
Layout
Simple
Layout
[...]
[...]
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 41 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Rich Domain-Specific Platform
•
•
•
•
Define a rich domain-specific application platform
consisting of
• Libraries
Generated Applications
• Frameworks
- Core Domain
Classes (Entities,
• base classes
Domain
Value Types, ...)
- Business Rules
Platform
• interpreters, etc.
- Business Services
The transformations will
“generate code” for this
domain-specific application
platform.
As a consequence, the transformations become simpler.
- ...
Technical
Platform/
Middleware
- Persistence
- Transactions
- Distribution
- Scheduling
- Hardware Access
- ...
Programming Language
Operating System
DSLs and Frameworks are two sides of the same coin
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 42 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Rich Domain-Specific Platform II - Integration
•
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
- 43 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
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
- 44 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Testing through 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.
• However, it is easily possible to verify design constraints in
the model before model transformation or code generation
steps are done.
• So, a DSL definition includes checks („constraints“) that
determine if a model is correct.
• Note that those constraints report errors in a language that is
on the same abstraction level as the DSL – i.e. no low level
compiler errors!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 45 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Testing through Model Verification II - Example
• Example Metamodel
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 46 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Testing through Model Verification III – Example cont‘d
• Verifications 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 …
}
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 47 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
CONTENTS
PART 2:
Software Architectural
Approach
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 48 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 49 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 50 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
The Problem
•
I think the craft of software architecture in current
industrial practice is not what it should be.
•
As a consequence, software development
• is too complicated
• too expensive
• hard to test
• has to change too much if technology changes
•
Specifically,
• Software architecture is too much technology driven.
• It is to be a slave to hypes and buzzwords
• Standards are used in too eagerly
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 51 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Problem: Technology-Driven
•
You hear statements such as “we have a web-service
architecture”, “EJB Architectures”, “Thin Client
Architecture”.
•
Such a this statement is stupid because
• it describes only one aspect of the overall system,
• And focuses on the implementation technology for that
aspect.
•
An early commitment to a specific technology usually
results in
• blindness for the concepts
• a too tight binding to the particular technology.
• a complicated programming model,
• bad testability and
• no flexibility to change the technology, as QoS
requirements evolve.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 52 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Problem: Hype and Buzzwords
•
It is good practice to characterize an architecture as
implementing a certain architectural style or pattern.
•
But some of the buzzwords used today are not even
clearly defined.
•
A “service oriented architecture” is a classic.
• Nobody knows what this really is,
• and how it is different from well-designed componentbased systems.
•
And there are many misunderstandings.
• People say “SOA”, and others understand “web service”…
•
A hype-based architecture often leads to too early (and
wrong) technology decisions – see previous slide!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 53 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Problem: Industry Standards
•
•
Standard definition, good old times.
•
•
•
•
try a couple of alternatives;
see which one is best;
set up a committee that defines the standard
the standard is usually close to the solution that worked best.
Standard definition, today:
•
•
•
Standards are often defined by a group of (future) vendors.
Either they already have tools, which the standard must consider
or there is no practical previous experience and the standard is
defined “from scratch”.
•
Standards are often not usable because there was no previous
experience, or they are overly complicated because it must
satisfy all the vendors….
•
Thus, if you use standards for too many aspects of your system,
your system will be complicated!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 54 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Problem: Architecture Degradation
•
It is one thing to define a „good“ architecture (assuming
we know what „good“ means for a project)
•
It is, however, much more complicated to make sure the
architecture is lived in the project.
• Communication
• Competence
• Ignorance
•
The goal:
• We (the team, architects, dictator…) want to make
architectural decisions when we see the need to
decide
• Then we want to ensure that everybody respects and
follows the decision…
• …until we find the decision has to be revised… which is
when we change it … but then, again, everybody has to
follow the new decision…
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 55 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Problem: Politics
I would be the first
I‘d
rather
one in the
company
the blue
to useprefer
web service
Database over
standards…
the red one.
© Die Gerd Show / Elmar Brandt
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 56 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Phase 1: Elaborate!
•
This section outlines best practices and approaches which
I think are important and applicable for all kinds of
projects – you don't want to go without these.
•
This first elaboration phase should be handled by a small
team, before the architecture is rolled out to the team as
a whole.
•
We want to build an enterprise system that contains
various subsystems such as customer management, billing
and catalogs.
In addition to managing the data using a database, forms
and the like, we also have to manage the
associated long-running business processes.
We will look at how we can attack this problem below.
•
•
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 57 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 58 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology-Independent Architecture
•
Context: You have to define a software architecture for a
non-trivial system
•
Problem: How do you define a software architecture that
is well-defined, long-lived and feasible for use in practice?
The architecture has to be reasonable simply and
explainable on a beer mat.
•
Forces
• Architectural concepts must be communicated to
stakeholders and developers
• Implementation of functional requirements should be as
efficient as possible.
• The architecture must “survive” a long time, longer than
the typical hype or technology cycles
• The architecture might have to evolve with respect to
QoS levels such as performance, resource consumption or
scalability.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 59 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology-Independent Architecture II
•
Solution: Define the archtitectural concepts independent
of specific technologies and implementation strategies.
•
Clearly define concepts, constraints and relationships of
the architectural building blocks – a glossary or an
ARCHITECTURAL METAMODEL can help here.
•
Define a TECHNOLOGY MAPPING in a later phase to map
the the artefacts defined here to a particular
implementation platform.
Use the well-known architectural styles and
patterns here. Typically these are best practices for
architecting certain kinds of systems independent of a
particular technology. They provide a reasonable
starting point for defining (aspects of) your systems's
architecture.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 60 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology-Independent Architecture III
•
We decide that our system will be built from components.
• Each component can provide a number of interfaces.
• It can also use a number of interfaces (provided by other
components).
• Communication is synchronous, Communication is also
restricted to be local
• We design components to be stateless.
•
In addition to components, we also explicitly support
business processes.
• These are modelled as a state machine.
• Components can trigger the state machine by supplying
events to them.
• Other components can be triggered by the state machine,
resulting in the invocation of certain operations.
• Communication to/from processes is asynchronous,
remote communication is supported.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 61 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology-Independent Architecture IV
•
Rationale and Consequences: You can focus more on
the structure, responsibilities and collaborations among
the parts of your systems.
• Implementation of functionality becomes more efficient.
• And you don't have to educate all developers with all
the details of the various technologies that you'll
eventually use.
•
So, how much technology is in a technologyindependent architecture?
• All technologies or approaches that provide additional
expressive concepts are useful in a TECHNOLOGYINDEPENDENT ARCHITECTURE.
• AOP is such a candidate.
• The notion of components is also such a concept.
• Message queues, pipes and filters and in general,
architectural patterns are also useful.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 62 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology-Independent Architecture V
•
Rationale and Consequences cont‘d: When
documenting and communicating your TECHNOLOGYINDEPENDENT ARCHITECTURE models are useful.
• Simple box and line diagrams, layer diagrams, sequence,
state or activity charts can help to describe what the
architecture is about.
• They are used for illustrative purposes, to help reason
about the system, or to communicate the architecture.
• For this very reason, they are often drawn on beer mats,
flip charts or with the help of Visio or Powerpoint.
• While these are not formal, you should still make sure
that you define what a particular visual element means
intuitively – boxes and lines with no defined meaning are
not very useful, even for non-formal diagrams.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 63 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 64 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Programming Model
•
Context: You have defined a TECHNOLOGY INDEPENDENT
ARCHITECTURE.
•
Problem:
• The architecture is a consequence of non-functional
•
•
requirements and the basic functional application structure,
which might make the architecture non-trivial and hard to
comprehend for developers.
How can you make the architecture accessible to (large
numbers of) developers?
Forces
•
•
•
•
You want to make sure the architecture is used “correctly” to
make sure it’s benefits can actually materialize.
You have developers of different qualifications in the project
team. All of them have to work with the architecture.
You want to be able to review application code easily and
effectively.
Your applications must remain testable.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 65 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Programming Model II
•
Solution: Define a simple and consistent programming
model.
• A programming model describes how an architecture is
used from a developer’s perspective. It is the
“architecture API”.
• The programming model must be optimized for typical
tasks, but allow for more advanced things if necessary.
• Note that a main constituents of a programming model is
a How-To Guide that walks developers through the
process of building an application.
•
The programming model uses a simple IOC approach à
la Spring to define component dependencies on an
interface level.
An external XML file takes care of the configuration of
the instances.
•
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 66 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Programming Model III
•
The following piece of code shows the implementation of
a simple example component. Note how we use Java 5
annotations
public @component class ExampleComponent
implements HelloWorld {
// provides HelloWorld
private IConsole console;
public @resource void setConsole( IConsole c ) {
this.console = c;
// setter for console
}
// component
public void sayHello( String s ) {
console.write( s );
}
}
•
•
•
Processes engines are components like any other.
For triggers, they provide an interface w/ void operations
They also define interfaces with the actions that those
components can implement that want to be notified of
state changes.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 67 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Programming Model IV
•
Process Component Implementation Example
public @process class SomeProcess
implements ISomeProcessTrigger {
private IHelloWorld resource;
public @resource void setResource( IHelloWorld w ) {
this.resource = w;
}
public @trigger void T1( int procID ) {
SomeProcessInstance i = loadProcess( procID );
if ( guardG1() ) {
// advance to another state…
}
}
public @trigger void T2( int procID ) {
SomeProcessInstance i = loadProcess( procID );
// …
resource.sayHello( "hello" );
}
}
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 68 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Programming Model V
•
Rationale and Consequences: The most important guideline
when defining a programming model is usability and
understandability for the developer.
•
Frameworks, libraries, and domain-specific languages are useful
•
Platform might have consequences for the programming model.
•
•
For example, if you want to be able to deploy something as an
enterprise bean, you should not create objects yourself.
Therefore:
•
•
•
•
•
Always develop against interfaces, not implementations
Never create objects yourself, always use factories
Use factories to access resources (such as database
connections)
Stateless design is a good idea in enterprise systems
Separate concerns: make sure a particular artifact does one
thing, not five.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 69 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 70 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology Mapping
•
Context: You have defined a TECHNOLOGY INDEPENDENT
ARCHITECTURE and a PROGRAMMING MODEL.
•
•
Problem: Your software has to deliver certain QoS levels.
Implementing QoS as part of the project is costly. You
might not even have the appropriate skills on the team.
Also, your system might have to run with different levels
of QoS, depending on the deployment scenario.
•
•
Forces
• You don't want to implement QoS stuff yourself.
• You want to keep the conceptual discussions, as well as
the PROGRAMMING MODEL free from technical issues.
• You might want to run the system with various levels of
QoS, with minimal cost for each.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 71 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology Mapping II
•
•
•
Solution: Map the TECHNOLOGY-INDEPENDENT
ARCHITECTURE to a specific platform that provides the
requires QoS.
Make the mapping to the technology explicit. Define
rules how the conceptual structure of your system (the
metamodel) can be mapped to the technology at hand.
Define those rules clearly to make them amenable for
GLUE CODE GENERATION.
Decide about standards usage here, not earlier.
But keep in mind: First solve the problem. Then look
for a standard. Not vice versa.
Use technology-specific Design Patterns here.
Use them as the basis for the TECHNOLOGY MAPPING.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 72 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology Mapping III
•
•
For the remote communication between business
processes we will use web services.
• From the interfaces such as IHelloWorld, we generate a
WSDL file, and the necessary endpoint implementation.
We use on of the many available web service frameworks.
Spring will be used as long a no advanced load
balancing and transaction policies are required.
<beans>
<bean id="proc" class="somePackage.SomeProcess">
<property name="resource"><ref bean="hello"/></property>
</bean>
<bean id="hello" class="somePackage.ExampleComponent">
<property name="console"><ref bean="cons"/></property>
</bean>
<bean id="cons" class="someframework.StdOutConsole">
</beans>
•
Once this becomes necessary, we will use Stateless
Session EJBs. The necessary code to wrap our
components inside beans is easy to write.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 73 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology Mapping IV
•
Persistence for the process instances – like any other
persistent data – is managed using Hibernate.
• To make this possible, we create a data class for each
process.
• Since this is a normal value object, using Hibernate to
make it persistent is straight forward
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 74 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Technology Mapping V
•
•
•
•
•
Rationale and Consequences: The question is, which
technology do you chose?
In general, this is determines by the QoS requirements
you have to fulfill.
Platforms are good at handling technical concerns such as
transactions, distribution, threading, load-balancing,
failover or persistence.
You don't want to implement these yourself.
So, always use the platform that provides the
services you need, in the QoS level you are required to
deliver. Often this is deployment specific!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 75 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 76 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Mock Platform
•
Context: You have a nice PROGRAMMING MODEL in
place.
•
Problem: Developers have to be able to run (parts of) the
system locally, at least to run unit tests.
How can you make sure developers can run "their stuff"
locally without caring about the TECHNOLOGY MAPPING
and its potentially non-trivial consequences for debugging
and test setup?
•
•
Forces
• Developers have to run their code as early as possible
• You want to minimize dependencies on other project
members, specifically those caring about the
TECHNOLOGY MAPPING.
• You have to make sure developers can efficiently run unit
tests.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 77 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Mock Platform II
•
•
•
•
•
•
Solution: Define the simplest TECHNOLOGY MAPPING
that could possibly work.
Provide a framework that mocks or stubs the
architecture as far as possible.
Make sure developers can test their application code
without caring about QoS and technical infrastructure.
Since we are already using a PROGRAMMING MODEL that
resembles Spring, we use the Spring container to run the
application components locally.
Stubbing out parts is easy based on Springs XML
configuration file.
Since persistence is something that Hibernate takes care
of for us, the MOCK PLATFORM simply ignores the
persistence aspect.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 78 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Mock Platform III
•
•
•
•
•
Rationale and Consequences: This is essential for unit
testing!
Testing one's business logic is simply if you have your
system well modularized.
If you stick to the guidelines given in the PROGRAMMING
MODEL pattern (interfaces, factories, separation of
concerns) it is easy to mock technical infrastructure
and other artifacts developed by other people.
Note that it's essential that you have a clearly defined
programming model, otherwise you TECHNOLOGY
MAPPING will not work reliably.
Note that the tests you run on the MOCK PLATFORM will
not find QoS problems – QoS is provided by the
execution platform.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 79 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 80 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Vertical Prototype
•
•
Context: You have a TECHNOLOGY INDEPENDENT
ARCHITECTURE, a PROGRAMMING MODEL as well as a
TECHNOLOGY MAPPING.
The first implementations of functionality are available and
tested using the MOCK PLATFORM.
•
Problem: QoS depends on the technology platform, you
selected only recently in the TECHNOLOGY MAPPING.
How do you make sure you don’t run into dead-ends?
•
Forces
• You want to keep your architecture as free of technology
specific stuff as possible.
• However, you want to be sure that you can address all the
non-functional requirements.
• You want to make sure you don’t invest into unworkable
technology mappings
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 81 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Vertical Prototype II
•
•
•
Solution: Make sure you test the non-functional
requirements!
Build a prototype application that uses all of the above
and implements it only for a very small subset of the
functional requirements.
This specifically includes performance and load tests.
Work on performance improvements here, not
earlier.
It is bad practice to optimize design for performance
from the beginning, since this often destroys good
architectural practice.
In certain domains, there are patterns to realize
certain QoS properties (such as stateless design for
large-scale business systems). You shouldn't ignore
these intentionally at the beginning.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 82 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Vertical Prototype III
•
The vertical prototype includes parts of the customer
and billing systems.
• For creating an invoice, the billing system uses normal
interfaces to query the customer subsystem for customer
details.
• The invoicing process is based on a long-running
process.
•
A scalability test was executed and resulted in two
problems:
• For short running processes, the repeated loading and
saving of persistent process state had become a problem.
A caching layer was added.
• Second, web-service based communication with process
components was a problem. Communication was
changed to CORBA for remote cases that were inside the
company
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 83 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 84 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Phase 2: Iterate!
•
•
•
•
•
Now that you have the basic mechanisms in place you
should make sure that they actually work for your
project.
Therefore, iterate over the previous steps until they are
reasonable stable and useful.
Spring was intended for the production environment.
New requirements (versioning!) have made this
infeasible.
• Spring does not support two important features:
Dynamic installation/de-installation of components,
• and isolations of components from each
other(classloaders).
Eclipse has been chosen as the new execution framework.
The PROGRAMMING MODEL did not change; the
TECHNOLOGY MAPPING, however, had to be adapted.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 85 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
CONTENTS
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 86 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Phase 3: Automate!
•
The steps outlined above are useful in any kind of
project.
•
•
In case your project is really large (i.e. you have a large
number of developers),
or in case your TECHNOLOGY MAPPING or the
PROGRAMMING MODEL is too tedious to use, you
should consider automating the development.
•
The next set of patterns describes how.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 87 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 88 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Architecture Metamodel
•
•
•
•
•
Context: You have a TECHNOLOGY-INDEPENDENT
ARCHITECTURE.
You want to automate various tasks of the software
development processes.
Problem: To automate, you have to codify the rules of
the TECHNOLOGY MAPPING
Thus, you have to be very clear and precise about the
artifacts defined in your TECHNOLOGY-INDEPENENT
ARCHITECTURE.
Forces
• Automation cannot work if you can't formalize
translation rules.
• An architecture based on prose text is not formal enough.
• You want to be able to check models for architectural
consistency.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 89 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Architecture Metamodel II
•
•
•
Solution: Define a formal architecture metamodel.
An architecture metamodel formally defines the concepts
of the TECHNOLOGY-INDEPENDENT ARCHITECTURE.
Ideally this metamodel is also useful in the
transformers/generators that are used to automate
development.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 90 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Architecture Metamodel III
if a component B is a new version
of a component A, then B has to
have the same interfaces,
additional provided interfaces,
fewer required interfaces or new
version of interfaces of A
a new version of an interface has to
have the same return type and the
same parameters - or parameters
with subtypes.
newVersionOf
0..n
1
providedInterface
0..n
0..n
Component
Operation
Interface
1..n
requiredInterface
0..n
0..n
0..n
returnType
1
newVersionOf
Parameter
Container
Characteristic
type
0..n
Type
Process
Component
Container
Service
0..n
PrimitiveType
ComplexType
State
Machine
State
1..n
to
0..n
from
0..n
Transition
0..1
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
Trigger
Operation
- 91 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Architecture Metamodel IV
•
•
Rationale and Consequences: Formalization is a
double-edged sword. While it has some obvious benefits,
it also requires a lot more work than informal models.
The only way to justify the extra effort is if the
metamodel is really used by tools in the development
process, such as
• as part of the code generation in DSL-BASED
PROGRAMMING MODELS
• and ARCHITECTURE-BASED MODEL VERIFICATION
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 92 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach S
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 93 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Glue Code Generation
•
Context: You have a TECHNOLOGY INDEPENDENT
ARCHITECTURE, as well as a working TECHNOLOGY
MAPPING.
•
Problem: The TECHNOLOGY MAPPING – if sufficiently
stable – is typically repetitive and thus tedious and error
prone to implement.
Often information that is already defined in the artifacts of
the PROGRAMMING MODEL have to be repeated in the
TECHNOLOGY MAPPING code (method signatures are
typical examples).
•
•
Forces
• A repetitive, standardized technology mapping is good
since it is a sign of a well though-out architecture
• Repetitive implementations always tend to lead to errors
and frustration.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 94 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Glue Code Generation II
•
•
•
Context: Based on the specifications of the TECHNOLOGY
MAPPING, use code generation to generate
• a glue code layer,
• and other adaptation artifacts such as descriptors,
configuration files, etc.
To make that feasible you might have to formalize your
TECHNOLOGY INDEPENDENT ARCHITECTURE into an
ARCHITECTURAL METAMODEL.
In order to be able to get access to the necessary
information for code generation, you might have to use a
DSL-BASED PROGRAMMING MODEL.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 95 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Glue Code Generation III
•
Our scenario has several useful locations for glue code
generation.
• We generate the Hibernate mapping files
• We generate the web service and CORBA adapters
based on the interfaces and data types that are used for
communication. The generator uses reflection to obtain
the necessary type information.
• Finally, we generate the process interfaces from the
state machine implementations.
•
In the programming model, we use Java 5 annotations
to mark up those aspects that cannot be derived by using
reflection alone.
Annotations can help a code generator to "know what to
generate" without making the programming model
overly ugly.
•
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 96 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Glue Code Generation IV
•
•
•
Rationale and Consequences: Build and test
automation is an established best practice in current
software development.
The natural next step is to automate programming – at
least those issues that are repetitive and governed by
clearly defined rules.
Generating these artifacts has several advantages.
• It's simply more efficient.
• The requirement to "implement" the TECHNOLOGY
MAPPING in the form of a generator helps refine the
TECHNOLOGY MAPPING rules.
• Code quality will typically improve, since a code
generator doesn't make any accidental errors
• Developers are relieved from having to implement
tedious glue code over and over again
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 97 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach S
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 98 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model
•
Context: You have a PROGRAMMING MODEL defined.
•
Problem: Your PROGRAMMING MODEL is still too
complicated, with a lot of domain-specific algorithms
implemented over and over again.
It is hard for your domain experts to use the
PROGRAMMING MODEL in their everyday work.
And the GLUE CODE GENERATION needs information
about the program structure that is hard or derive
from the code
•
•
•
Forces
• The code-based PROGRAMMING MODEL can’t use
domain-specific notations
• Parsing code in order to gain information on what kind of
glue code to generate is tedious, and the code also does
not have the necessary semantic richness.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 99 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model II
•
•
•
•
Solution: Define Domain-Specific Languages that
developers use to describe application structure and
behavior in a brief and concise manner.
Generate the lower-level implementation code from
these models.
Generate a skeleton against which developers can code
those aspects that cannot be completely generated from
the models.
We use DSLs for components, interfaces and
dependencies. Describing this aspect in a model has two
benefits:
• First, the GLUE CODE GENERATION can use a more
semantically rich model as its input,
• and the model allows for very powerful MODEL-BASED
ARCHITECTURE VALIDATION (see below).
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 100 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model III
IConole
IHelloWorld
<<component>>
HelloWorld
{persistent}
<<component>>
StdOutConsole
•
•
From these diagrams,
• we can generate a skeleton component class
• all the necessary interfaces.
Developers simply inherit from the generated skeleton
and implement the operations defined by the provided
interfaces.
<<interface>>
<<generate>>
SomeInterface.java
SomeInterface
<<component>>
<<generate>>
<<gen-code>>
<<man-code>>
Some
Component
Base.java
SomeComponent
ingenieurbüro für sof twaretechnologie
<<gen-code>>
.
w w w.vo el ter.d e
SomeComponent.java
- 101 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model IV
•
A second place is the
processes.
• State machines can be
“drawn” using UML
state machines.
• To integrate processes
with other components,
these can easily be
rendered by “blackboxing” the state
machine with a
component and using
it in component diagrams.
• The component is
derived from the
state chart automatically.
ingenieurbüro für sof twaretechnologie
sd SomeProcess
s1
[valid] T1
[invalid] T1
s3
s2
T2/someAction
cd SomeProcessComponent
.
w w w.vo el ter.d e
<<interface>>
ISomeProcessTrigger
<<component>>
SomeProcessComponent
isValid()
isInvalid()
triggerT1()
triggerT2()
<<interface>>
ISomeProcessResource
someAction()
- 102 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model V
Type Model
<<entity>>
<<component>>
AddressManager
Person
person
name: String
firstName: String
0..n
addressStore
<<valuetype>>
<<interface>>
AddressStore
Address
<<component>>
CustomerManager
addOrUpdateContact( p: Person) : void
addAddress( p: Person, a: Address) : void
getAddresses( p: Person ) : Address[]
street: String
zip: String
City: String
Composition Model
System Model
<configurations>
<configuration name="addressStuff">
<deployment name="am" type="AddressManager">
<wire name="personDAO" target="personDAO"/>
</deployment>
<deployment name="personDAO" type="PersonDAO"/>
</configuration>
<configuration name="customerStuff">
<deployment name="cm" type="CustomerManager">
<wire name="addressStore" target=":addressStuff:am"/>
</deployment>
</configuration>
<configuration name="test" includes="addressStuff, customerStuff"/>
</configurations>
<systems>
<system name="production">
<node name="server" type="spring" configuration="addressStuff"/>
<node name="client" type="eclipse" configuration="customerStuff"/>
<system>
<system name="test">
<node name="test" type="spring" configuration="test"/>
<system>
</systems>
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 103 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model VI
<<entity>>
<<interface>>
<<transform>>
SomeEntity
<<generate>>
<<gen-code>>
SomeEntityDAO.java
SomeEntityDAO
<<transform>>
<<component>>
<<generate>>
<<gen-code>>
SomeEntityDAOBase
.java
SomeEntityDAO
<<generate>>
<<generate>>
SomeEntityDAO.java
<<gen-code>>
SomeEntity.java
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
<<gen-code>>
- 104 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model VII
<<proc-component>>
AProcess
1
<<transform>>
sm AProcess
s1
*
<<trigger-interface>>
AProcessInterface
<<transform>>
s2
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
operations...
<<generate>>
<<generate>>
AProcessData.java
1
<<gen-code>>
AProcessBase
.java
<<gen-code>>
AProcessProcBase.java
data
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 105 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model VIII
•
Rationale and Consequences: Defining useful DSLs,
providing a suitable editor, and implementing an generator
creates efficient code is a non-trivial task.
•
So this step only makes sense
• if the generator is reused often,
• the "normal" PROGRAMMING MODEL is so intricate,
that a DSL boosts productivity,
• or if you want to do complex MODEL-BASED
ARCHITECTURE VALIDATION.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 106 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: DSL-based Programming Model IX
•
Rationale and Consequences cont’d: The deeper your
understanding of the domain becomes, the more
expressive your DSL can become (and the more powerful
your generators have to be).
Input Models
•
•
In order to manage the
complexity, you should
build cascades of
DSL/Generator pairs.
The lowest layer is basically
the GLUE CODE GENERATOR;
higher layers provide more
and more powerful
DSL-BASED PROGRAMMING
MODELS.
ingenieurbüro für sof twaretechnologie
...
...
...
...
...
...
MDSDInfrastructure
Output Model
Model for Domain 1
Model for Domain 2
DSL-based prog.
model 1
DSL-based prog.
model 2
.
w w w.vo el ter.d e
Programming Model Artifacts
Glue Code Generation
Code for Target Platform
- 107 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 108 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Model-Based Architecture Validation
•
Context: You have all the things from above in place and
you roll out your architecture to a larger number of
developers.
•
Problem: You have to make sure that the PROGRAMMING
MODEL is used in the intended way.
Different people might have different qualifications.
Using the programming model correctly is also crucial
for the architecture to deliver it QoS promises.
•
•
•
Forces:
• Checking a system for “architectural compliance” is
critical!
• Using only manual reviews does not scale
• Since a lot technical complexity is taken away from
developers (it is in the generated) these issues need not
be checked.
• Checking the use of the PROGRAMMING MODEL on source
level is complicated
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 109 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Model-Based Architecture Validation II
•
Solution: Make sure critical architectural things are either
•
•
specified as part of the DSL-BASED PROGRAMMING MODEL,
or the developers are restricted in what they can do be the
generated skeleton, into which they add their 3GL code.
•
Architectural verifications can then be done on model level,
which is quite simple: it can be specified against the constraints
defined in the ARCHITECTURE METAMODEL.
•
It is checked that
•
•
•
•
for triggers in processes there is a component that calls the
trigger.
Dependency management: It is easy to detect circular
dependencies among components.
Components are assigned to layers (app, service, base) and
dependencies are only allowed in certain directions.
The component signature generated from the model prevents
developers from creating dependencies to components that are
not described in the model
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 110 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Model-Based Architecture Validation III
•
Another really important aspect in our example system is
evolution of interfaces:
<<component>>
SomeCompV1
<<interface>>
SomeInterface
soSomething(int, ValueObject)
<<newVersionOf>>
<<vo>>
ValueObject
<<interface>>
AnotherInterface
<<component>>
SomeCompV2
<<newVersionOf>>
<<newVersionOf>>
<<newVersionOf>>
<<interface>>
SomeInterfaceV3
<<component>>
SomeCompV3
<<vo>>
ValueObjectV3
soSomething(int, ValueObjectV2)
anAdditionalOperation()
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 111 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Model-Based Architecture Validation IV
•
Rationale and Consequences: In larger projects, you
have to be able to verify the properties of your system
(from an architectural point of view) via automated
checks.
•
Some of them can be done on code level (using metrics,
etc.).
•
However, if you have the system's critical aspects
described in models, you have much more powerful
verification and validation tools at hand.
•
It is essential that you can use the ARCHITECTURE
METAMODEL to verify models/specifications.
•
Good tools for model-driven software development
(such as the openArchitectureWare generator) can read
(architecture) metamodels and use them to validate input
models.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 112 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
PATTERN: Model-Based Architecture Validation V
•
•
Rationale and Consequences cont’d: This way, a
metamodel is not “just documentation”, it is an artifact
used by development tools.
The following illustration shows how this tool works.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 113 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Part 2, Software Architectural Approach
•
•
•
•
•
The Problem
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Iterate!
PHASE 3: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
Summary
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 114 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Summary
•
•
•
•
The approach to software architecture described in this
papers is a tried and trusted one. However, it is often not
used …
Why? People think it is too complicated to use. And it's not
"standard".
To some extend this is true. Defining your own
PROGRAMMING MODEL certainly means, that not all
developers will learn each and every J2EE detail.
While this might be considered a problem by some
developers (for their CVs), it is certainly a good thing wrt.
productivity.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 115 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
CONTENTS
PART 3:
Components
Reference Metamodel
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 116 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Components Reference Metamodel
•
•
•
•
•
•
Why?
Three basic Viewpoints and their Metamodels
Component Implementation
Aspect Models
Variants
Code Generation revisited
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 117 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Components Reference Metamodel
•
•
•
•
•
•
Why?
Three basic Viewpoints and their Metamodels
Component Implementation
Aspect Models
Variants
Code Generation revisited
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 118 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Why?
•
Based on my experience, the core “asset” in model-driven
component based development is not a generator that
generated some J2EE code, rather, the “right” selection
of models and viewpoints is essential.
•
So these slides contain exactly this: a reference
metamodel that has been used in many, many different
projects.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 119 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Components Reference Metamodel
•
•
•
•
•
•
Why?
Three basic Viewpoints and their Metamodels
Component Implementation
Aspect Models
Variants
Code Generation revisited
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 120 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Three Basic Viewpoints
•
•
•
Type Model: Components, Interfaces, Data Types
Composition Model: Instances, “Wirings”
System Model: Nodes, Channels, Deployments
Type Model
<<entity>>
<<component>>
AddressManager
person
Person
name: String
firstName: String
0..n
addressStore
<<valuetype>>
<<interface>>
AddressStore
Address
<<component>>
CustomerManager
addOrUpdateContact( p: Person) : void
addAddress( p: Person, a: Address) : void
getAddresses( p: Person ) : Address[]
street: String
zip: String
City: String
Composition Model
System Model
<configurations>
<configuration name="addressStuff">
<deployment name="am" type="AddressManager">
<wire name="personDAO" target="personDAO"/>
</deployment>
<deployment name="personDAO" type="PersonDAO"/>
</configuration>
<configuration name="customerStuff">
<deployment name="cm" type="CustomerManager">
<wire name="addressStore" target=":addressStuff:am"/>
</deployment>
</configuration>
<configuration name="test" includes="addressStuff, customerStuff"/>
</configurations>
<systems>
<system name="production">
<node name="server" type="spring" configuration="addressStuff"/>
<node name="client" type="eclipse" configuration="customerStuff"/>
<system>
<system name="test">
<node name="test" type="spring" configuration="test"/>
<system>
</systems>
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 121 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Three Basic Viewpoints – Generated Stuff
•
•
•
•
•
•
Base classes for component implementation
Build-Scripts
Descriptors
Remoting Infrastructure
Persistence
…
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 122 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Type Metamodel
*
Component
providedInterface
name
Interface
name
*
required
Interface
Component
Interface
Requirement
Operation
name
target
*
Parameter
name
returnType
Type
name
name
exception
type
*
Exception
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 123 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Type Metamodel II (Data)
Type
name
Complex
Type
Entity
Reference
attribute
Attribute
type
name
Primitive
Type
*
ref
name
isBidirectional
targetMultiplicity
sourceMultiplicity
*
src
Entity
target
ingenieurbüro für sof twaretechnologie
Data
Transfer
Object
.
w w w.vo el ter.d e
- 124 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Composition Metamodel
*
Component
providedInterface
name
name
*
type
Interface
required
Interface
Component
Interface
Requirement
target
name
Component Stuff
Composition Stuff
cireq
Configuration
name
*
instance
Component
Instance
Wire
*
name
name
target
context ComponentInstance inv:
foreach of type’s ComponentInterfaceRequirements
there must be a Wire of the same
name
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
context Wire inv:
the type of the target
instance must provide
the Interface pointed
to by the Wire’s cireq’s
target
- 125 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
System Metamodel
Configuration
Component
Instance
*
instance
name
*
Wire
name
name
Composition Stuff
*
System Stuff
System
name
*
Node
name
ingenieurbüro für sof twaretechnologie
Container
* name
.
w w w.vo el ter.d e
- 126 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Viewpoint Dependencies
•
Dependencies between Viewpoint Models are only
allowed in the way shown below in order to
• Be able to have several compositions per type model
• And several system models per composition
•
This is important to be able to have several “systems”,
• Several deployed locally for testing, using only a subset of
the defined components,
• And “the real system”
Composition Model
Composition Model
System Model(s)
Composition Model
Composition Model(s)
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
Type/Data Model
- 127 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Components Reference Metamodel
•
•
•
•
•
•
Why?
Three basic Viewpoints and their Metamodels
Component Implementation
Aspect Models
Variants
Code Generation revisited
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 128 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Component Implementation
•
We have not yet talked about the implementation code
that needs to go along with components.
• As a default, you will provide the implementation by a
manually written subclass
<<interface>>
<<generate>>
SomeInterface.java
SomeInterface
<<component>>
<<generate>>
SomeComponent
•
<<gen-code>>
<<gen-code>>
Some
Component
Base.java
<<man-code>>
SomeComponent.java
However, for special kinds of components (“component
kind” will be defined later) can use different
implementation strategies -> Cascading!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 129 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Component Implementation II
<<proc-component>>
1
AProcess
<<transform>>
Remember
the example
of the process
components
from before:
s1
s2
<<transform>>
•
sm AProcess
*
<<trigger-interface>>
AProcessInterface
<<entity>>
AProcessData
attributes...
s3
<<generate>>
<<gen-code>>
•
•
operations...
Various other
implementation
stragies can be used,
such as:
• Rule-Engines
• “Procedural” DSLs or action
semantics
<<generate>>
<<generate>>
<<gen-code>>
<<gen-code>>
AProcessBase
.java
AProcessProcBase.jav
a
AProcessData.java
1
data
guard operations... (abstract)
action methods... (abstract)
<<man-code>>
AProcess.java
Note that, here, interpreters can often be used sensibly
instead of generating code!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 130 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Components Reference Metamodel
•
•
•
•
•
•
Why?
Three basic Viewpoints and their Metamodels
Component Implementation
Aspect Models
Variants
Code Generation revisited
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 131 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Aspect Models
•
These go into separate aspect models, each describing
a well-defined aspect of the system.
• Each of them uses a suitable DSL/syntax
• The generator acts as a weaver
•
Typical Examples are
• Persistence
• Security
• Forms, Layout, Pageflow
• Timing, QoS in General
• Packaging and Deployment
• Diagnostics and Monitoring
ct4
on
ositi
p
m
Co
el(s)
Mod
Ty
p
M e/D
o
a
d
el ta
2
.
w w w.vo el ter.d e
sp
e
ct
ingenieurbüro für sof twaretechnologie
Aspe
Sy s t
e
Mod m
el(s)
ect3
Asp
Often, the described three viewpoints are not enough,
additional aspects need to be described.
A
•
Aspe
- 132 -
ct1
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Components Reference Metamodel
•
•
•
•
•
•
Why?
Three basic Viewpoints and their Metamodels
Component Implementation
Aspect Models
Variants
Code Generation revisited
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 133 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Separate Interfaces
•
You might not need separate Interfaces
• Operations could be annotated directly to components
• Dependencies would be to components, not to interfaces
•
Relationships between interfaces are often needed,
• “if you require this interface, you also have to provide that
one”
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 134 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Component Types
•
Often different “kinds” of Components are needed.
• To manage dependencies,
• And to define implementation strategies
context ApplicationComponent inv:
No provided interfaces
are allowed
Component
name
Service
Component
DAO
Component
Domain
Component
<<validDep>>
Application
Component
<<validDep>>
Legcy
Adapter
Component
<<validDep>>
GUI
Component
Facade
Component
<<validDep>>
<<validDep>>
<<validDep>>
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 135 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Component Layering
•
Alternatively you can simply annotate each component
with a layer
*
Component
name
layer: LayerType
providedInterface
*
required
Interface
Component
Interface
Requirement
Interface
name
layer: LayerType
target
<<enumeration>>
LayerType
domain
gui
facade
...
name
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 136 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Component Signatures
•
You might need to provide several implementations
(i.e. components) for the same signature (i.e.
provided/required interfaces).
• So you need to separate implementation from signature
*
Component
Signature
name
implemented
Signature
providedInterface
Interface
name
Component
Interface
Requirement
*
required
Interface
target
name
required
Interface
Component
Implementation
name
ingenieurbüro für sof twaretechnologie
ConfigParam
*
default
.
w w w.vo el ter.d e
- 137 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Hierarchical Components
Component
type
name
*
may have additional
properties that define
how interface is used
Port
Interface
p2
name
name
port
HierarchicalComponent
RequiredPort
ProvidedPort
*
ComponentInstance
name
* PortInstance
name
p1
context ConnectingWire inv:
One of the port instances’s ports
must be a provided port, the
other a required port. Interfaces
of the two ports must be the
same
p1
p2
Connecting
Wire
*
Delegating
Wire
Wire
name
ingenieurbüro für sof twaretechnologie
context
DelegatingWire
inv:
p2's owning
component must be
the same as p1's
instance’s owning
hierarchical
component
.
w w w.vo el ter.d e
- 138 -
context
DelegatingWire inv:
If p1's port is a
ProvidedPort, then p2
must also be a
ProvidedPort. Similar
for RequiredPorts.
Interface of p1's Port
must be same as p2's
interface
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Hierarchical Components II
•
This allows an infinite nesting of component structures
•
It requires the concept of ports
•
Note that the clear boundaries between type and
composition models are blurted (which makes this
approach a bit more advanced!)
•
Example:
HierarchicalComponentA
Component
InstanceB
ComponentD
I1
Component
InstanceC
bPort
aPort
I1
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 139 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Configuration Parameters
•
Parameters allow for dynamic configuration of
components.
•
There is a wide variety of potential value definition
scopes
* ConfigParam
Component
name
Attribute
name
default
Component Stuff
Composition Stuff
type
Configuration
name
*
instance
*
Component
Instance
ConfigParam
Value
name
context ComponentInstance inv:
foreach of type’s ConfigParams
there must be a ConfigParamValue
ingenieurbüro für sof twaretechnologie
StaticConfig
ParamValue
value
.
w w w.vo el ter.d e
Dynamic
ConfigParam
Value
- 140 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Behaviour
•
Different (types of) Components typically have different
lifecycles
•
The threading model is typically different, too.
•
Also, some components might be stateless, while others
are stateful (with persistent state, or not)
Service
Component
<<enumeration>>
ThreadingType
<<enumeration>>
LifecycleType
SingleThread
ThreadSafe
lifecycle: LifecycleType
threading: ThreadingType
Simple
WithInit
Active
0..1
Complex
Type
Component
State
isPersistent
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 141 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Asynchronous Communication
•
Some components might need asynchronous
communication with others
• Note that this has to be specified in the type model –
since it affects the API!
*
Component
providedInterface
name
Interface
<<enumeration>>
CommType
name
*
required
Interface
Component
Interface
Requirement
sync
async-oneway
async-syncWS
async-poll
async-callback
target
name
comm: CommType
context ComponentInterfaceRequirement inv:
if oneway or syncWithServer is used, all operations in
the target interface must be void, and not throw any
exceptions!
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 142 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Events
•
Events are a way to signal information from a
component to another, asynchronously.
• Sometimes it is useful to allow for violations of the
(otherwise rigidly enforced) dependency rules
Complex
Type
Component
name
*
*
attribute
Attribute
name
Event
producer
*
consumer
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 143 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Subsystems and Business Components
•
If the number of components grows, additional means
to organize them are required.
•
The internal structure of subsystems or business
components can be defined by enforcing certain policies
wrt. Component types
• For example, each business component must have exactly
one facade
context BusinessComponent inv:
Must contain exactly
one FacadeComponent
*
Entity
*
Interface
*
Service
Component
Subsystem
Business
Component
Facade
Component
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
GUI
Component
- 144 -
...
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Data
•
More elaborate data structures are often required
• Typical example is based on entities and dependent types
•
DAOComponents are used to manage the entities and
their associated dependent types
•
Ownership and Scope of data types is essential
• Indirect dependency management
• packaging
Complex
Type
Component
*
Entity
usedEntity
name
Dependent
Type
Value
Type
*
baseType
DAO
Component
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 145 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Wiring
•
Optional wires might be useful
•
Dynamic Wires don’t specify the target instance, but
rather a set of properties based on which at runtime, the
target can be found
• Important for dynamic systems, e.g. P2P
b)
Component
Instance
Wire
*
name
name
Component
Instance
*
Wire
name
query
name
target
backupTarget
ingenieurbüro für sof twaretechnologie
Interface
.
w w w.vo el ter.d e
- 146 -
requiredInterface
a)
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Container Types and Networks
•
This allows for more specific description of hardware,
• Networks and network types describe means to
communicate
• Whereas container types are important to distinguish
various execution environments (server, local, …)
Configuration
Component
Instance
*
instance
name
Wire
*
*
<<enumeration>>
NodeType
name
...
name
Composition Stuff
*
hosts
System Stuff
name
Node
Container
* name
name
type: NodeType
type: ContainerType
node1
node2
*
*
transports
System
*
...
<<enumeration>>
NetworkType
Network
...
name
type: NetworkType
ingenieurbüro für sof twaretechnologie
<<enumeration>>
ContainerType
.
w w w.vo el ter.d e
- 147 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Versioning
Capturing versioning and type evolution information
explicitly in the model allows for definitive statements
about component compatibility and system
evolution.
newVersionOf
•
newVersionOf
0..1
*
0..1
*
Component
providedInterface
name
Interface
name
*
0..1
*
required
Interface
Component
Interface
Requirement
*
target
name
newImplementationOf
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 148 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
C O N T E N T S: Components Reference Metamodel
•
•
•
•
•
•
Why?
Three basic Viewpoints and their Metamodels
Component Implementation
Aspect Models
Variants
Code Generation revisited
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 149 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Code Generation Revisited
•
The discussions previously have only discussed how we
want to describe our system – we did not talk about how
these things are implemented.
• This mights sound odd.
•
However, coping with complexity starts with finding
solid means to describe what we want to developer – a
good description is thus essential!
•
Only then we want to use good platforms, that provide
many of the (runtime) services we require, this can
include
• J2EE
• CORBA
• Spring
• Osek
•…
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 150 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Code Generation Revisited II
•
In case we have to build the infrastructure ourselves,
e.g. since, for the respective target environment, no
infrastructure is available (embedded, e.g.), we have a
wide range of patterns to select from:
• POSA 1, 2 and 3
• Server Component Patterns
• Remoting Patterns
•
Good Luck 
THE END.
Questions?
Criticism?
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 151 -
© 2004 M a rk us Vö l te r
Model-Driven Development of Distributed, Component-Based Systems
Some advertisement 
•
For those, who happen to speak
(or rather, read) german:
Völter, Stahl:
Modellgetriebene
Softwareentwicklung
Technik, Engineering, Management
dPunkt Verlag, 2005
www.mdsd-buch.de
•
For all others:
A translation (with Wiley) is
under way.
ingenieurbüro für sof twaretechnologie
.
w w w.vo el ter.d e
- 152 -
© 2004 M a rk us Vö l te r