Transcript Kein Folientitel

MDSD‘s role as an architectural catalyst
The role of MDSD as an
Architectural Catalyst
Markus Völter
[email protected]
www.voelter.de
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-1-
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-3-
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
-4-
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Model-Driven Software Development
•
MDSD 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
-5-
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
-6-
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
MDSD 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
-7-
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
How MDSD works
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
-8-
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
-9-
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 10 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Software Architecture Process „on a slide“
•
•
•
…and actually, this is
a talk of its own…
Today‘s Problems:
• Too much technology
• Too many hypes and buzzwords
• Too many standards too early
• So: People don‘t focus on architectural concepts
PHASE 1: Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
PHASE 2: Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 11 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Architecture-Centric MDSD
•
It is essential that, in a first step, you build an MDSD
Infrastructure that consolidates your software architecture
– architecture-centric MDSD.
• Metamodels are on the abstraction level of the
architectural concepts of the target architecture
• Models express software structures (such as
components, processes, etc).
• On top of this infrastructure, additional, more specific
layers can be cascaded (next slide)
•
This approach makes sure the software architecture
receives the level of attention it deserves:
building this basic MDSD infrastructure makes you think
hard about the your system‘s architectural concepts
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 12 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Cascaded MDSD
Input Models
...
...
...
...
...
...
MDSDInfrastructure
Output Model
Model for Subdomain 1
Model for Subdomain 2
M2M/Code
Generator for SD 1
M2M/Code
Generator for SD 2
Programming Model (based on Arch-MM)
Code Generator for
Architectural MDSD Infrastructure
Code for Target Platform
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 13 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 14 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
What is Metamodelling I
•
•
•
In order to define a modelling
language by specifying its
metamodel, you‘ll need
another language: This is
typically called the
beschreibt
instanceof
metametamodelling
M3: Meta-Metamodel
language.
A metamodel is a model
of a modelling language.
It is not „a model of a
model!“
The OMG defines four
metalevels, the metametamodel is called the
MOF, or Meta Object
Facility.
ingenieurbüro für sof twaretechnologie
beschreibt
instanceof
Typ: Classifier
ID: 764535
Name: Klasse
Features: Attributes,
Operations, Assoc's, ...
M2: Metamodel
beschreibt
instanceof
M1: Model
beschreibt
instanceof
Typ: Klasse
ID: 21436456
Name: Person
Attribute: Name, Vorn.
Operationen: ...
Assoziationen: ...
Typ: Person
ID: 05034503
Name: Völter
Vorname: Markus
M0: Instanzen
w w w.vo el ter.d e
Typ: Classifier
ID: 5346456
Name: Classifier
- 15 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
How does the MOF look like?
M3: Meta-Metamodel
MOF
M2: Metamodel
UML
M1: Model
Class model
M0: Instances
Run-time objects
depends on
Model
Element
Import
Namespace
Constraint
Tag
Feature
imports
generalizes
Generalizable
Element
Package
Behavioral
Feature
Classifier
Operation
Exception
can throw
Association
Class
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 16 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Example: Simple Model/Metamodel
•
We want to define a textual language to define
interfaces/classes. Example:
class SomeClass {
operation doSomething( i:int, j:int ):String;
operation anotherOne(): boolean;
attribute anAttr: String;
};
•
The metamodel/AST for this kind of definition looks like
the following:
Class
*
Operation
name
type
name
*
*
Parameter
name
type
Attribute
name
type
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 17 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Example: The metamodel(s) of a typical enterprise app
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
- 18 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 19 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 20 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 21 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 22 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Architectural Styles and Patterns
•
Architectural Patterns capture architectural blueprints or
styles and describe their characteristics in the well-known
pattern form.
•
Architectural patterns, if described right, imply a kind of
„metamodel“ – a collection of (types of) artefacts that
can be used to build an architecture with certain
properties.
•
As such, architectural patterns can be the basis for you
domain‘s architectural metamodel.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 23 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Architectural Patterns / The Pipes and Filters Pattern
•
Thumbnail:
•
•
•
•
The Pipes and Filters pattern provides a structure for systems that
process a stream of data.
Each processing step is encapsulated in a filter component.
Data is passed through pipes between adjacent filters.
Recombining filters allows you to build families of related systems.
data
data''''
data'
filter n
pipe
data''
filter n-1
data'''
...
pipe
pipe
filter 1
pipe
filter 0
data flow
•
Known Uses:
•
•
•
•
Compilers (different stages)
UNIX shells
CMS Pipelines
Image Processing (ALMA)
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 24 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
A selection of architectural styles
Independent parts
Communicating
Processes
Event/Message-bases
Systems
Data
Centered
Data Flow
Batch
Sequential
Pipes and
Filters
Repository
Workflow
Plug-Ins
Call and
Return
Components
Virtual Machine
Procedural
Interpreter
Rule-Based
ingenieurbüro für sof twaretechnologie
Microkernel
w w w.vo el ter.d e
Blackboard
Frameworks
- 25 -
Object
oriented
Layers
Reflection
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 26 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Code Generation vs. Platform
•
•
There is no point in generating 100% of an
application’s code. You might want to
generate 100% for a certain part/aspect,
but other code will always be reused
from a platform.
Stalagtite
The ratio of generated code and
platform code varies
•
•
From system to system
And also in one system over time
•
If the platform gets too complicated
or too slow, generate more code.
If the generator gets too complicated
or generates lots of identical code,
move it to the platform
•
•
Generated
Code
Platform
Stalagmite
Generated code is often framework completion code – DSLs
make frameworks easier to use!
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 27 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Rich Domain-Specific Platform
•
•
•
•
Define a rich domain-specific application platform
consisting of
Generated Applications
• Libraries
- Core Domain
• Frameworks
Classes (Entities,
Domain
Value Types, ...)
• base classes
- Business Rules
Platform
- Business Services
• interpreters, etc.
- ...
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
- 28 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 29 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
The Role of Architecture II
• MDSD helps you come up with a good architecture, since
it requires a few, well defined concepts; otherwise, the
approach does not work.
• The act of building a generator „point your nose“ to the
architecturally important questions.
• MDSD can also help you to enforce the architecture
especially in large projects because
• architectural issues can be controlled on the model level,
• and the generator removes „degrees of freedom“ for developers.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 30 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Architecture „Enforcement“ using MDSD
• Example:
MenuUtilities
<<application>>
TextEditor
SMSApp
SMSIF
SMSIF CallIF EMSIF
UIManager
GSMStack
lookAndFeel: String
• Problem: How do you ensure that developers can actually
only reference (use) those components, which are declared as
being used in the model?
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 31 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Typical Solution, without MDSD
public class SMSAppImpl {
public void tueWas() {
TextEditor editor =
Factory.getComponent(“TextEditor”);
editor.setText( someText );
editor.show();
}
}
• Problems:
• Developers can lookup, use, and thus, depend on whatever they
like
• Developers are not guided (by IDE, compiler, etc.) what they are
allowed to access and what is prohibited
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 32 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Improved Solution, with MDSD
public interface SMSAppContext extends ComponentContext {
public TextEditorIF getTextEditorIF();
public SMSIF getSMSIF();
public MenuIF getMenuIF();
}
public class SMSAppImpl implements Component {
private SMSAppContext context = null;
public void init( ComponentContext ctx) {
this.context = (SMSAppContext)ctx;
}
public void tueWas() {
TextEditor editor = context.getTextEditorIF();
editor.setText( someText ); editor.show();
} }
• Better, because:
• Developers can only access what they are allowed to…
• … and this is always in sync with the model
• IDE can help developer (ctrl+space in eclipse)
• Architecture (here: Dependencies) are enforced and controlled
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 33 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Relationship Programming Model/Model
•
The programming model must be true to the model and the
constraints checked therein:
•
•
If certain constraints on the model hold
Then the programming model must ensure that these
constraints can’t be violated in the “real” code
•
Example:
• constraints, saythere are no illegal dependencies in the model...
• The programming model must then be sure that no illegal
dependencies can be created in the manually written code
•
If this is not the case, constraint checks in the model
don’t help you much!
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 34 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Relationship Programming Model/Model II
•
Conformance of the manually written code to guidelines
implied by the generator (and thus, by the constraints) can
be checked by using
•
compiler tricks such as static if-false blocks that cast types
around or “call” methods
public class SCMComponentBase ... {
static {
if ( false ) {
SCMComponentBase i = (SCMComponentBase)
(new SCMBusinessComponent());
}
}
}
•
subsequent checks check the manually written code for
consistency with the guidelines/programming model
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 35 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Relationship Programming Model/Model III
•
•
The openArchitectureWare RecipeFramework can be used to
subsequently check manually written code
•
During the generator run, we generate the generated code;
•
in addition, based on the model, we instantiate checks that
need to be verified later on the manually-written code
•
In the IDE, the failed checks are shown to the user hinting at
“problems” with the manualy code that need to be fixed.
•
Once a problem is fixed, the complaint goes away.
•
For many failed checks, a “fix this” button can be activated to fix
the problem automatically.
A fairly small number of such Checks can get you a long way...
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 36 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
oAW Recipe Framework Screenshot
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 37 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 38 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 39 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 40 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Type Metamodel
*
Component
providedInterface
name
Interface
name
*
required
Interface
Component
Interface
Requirement
Operation
name
*
Parameter
name
target
returnType
Type
name
name
exception
type
*
Exception
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 41 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 42 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 43 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 44 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Variants
•
Many many variants of this metamodel are necessary
in practice. These concern
• Separate Interfaces
• Component Types and Layering
• Component Signatures
• Hierarchical Components
• Configuration Parameters
• Asynchronous Communication
• Events
• Subsystems and Business Components
• (Dynamic) Wiring
• Container Types and Networks
• Versioning
•
I have skipped them for reasons of brevity.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 45 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 46 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Generated Stuff II
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
- 47 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Cascading: Persistence
<<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>>
- 48 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Cascading: Processes
<<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
- 49 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 50 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 51 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
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
- 52 -
ct1
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Example Aspect: Persistence
•
The following example shows a possible metamodel for a
persistence aspect:
Type
name
Complex
Type
Entity
Reference
1
Primitive
Type
type
name
attribute
base
src
Component
Entity
target
ref
0..1
RefTable
attribute
Attribute
*
ref
name
isBidirectional
targetMultiplicity
sourceMultiplicity
*
Data
Transfer
Object
name
entity
*
from
name
EntityTable
column
Column
* name
name
to
pk
index
*
Index
{ordered}
name
ingenieurbüro für sof twaretechnologie
*
DBPrimitive
Type
*
Query
name
expression
w w w.vo el ter.d e
- 53 -
*
Query
Component
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 54 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
SOA – Trivial
•
Some people consider a well-done component-based
system already a service-oriented architecture. Adopting
this view, results in the following metamodel:
*
Component
providedInterface
name
Service
name
*
required
Interface
Component
Service
Requirement
Operation
name
*
Parameter
name
target
returnType
Type
name
name
exception
type
*
Exception
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 55 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
SOA – The Essence
•
Contract First!
•
However, I consider a SOA to be a component architecture
with the following important differences:
• The core focus is on the messages and interactions
• A registry that knows the services and their metadata is
available
• Multi-Language/Multi-Platform
•
For those reasons, MDSD and SOA go together
extremely well – you almost have to use MDSD if you
want to do “real” SOA.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 56 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
SOA – Refined
Component
name
Provider
Consumer
consumes
Provider
Consumer
p
provides
1..*
1..*
c
1..* 1..*
Service
Message
Flow
Control
0..1
*
Elementary
Service
*
Message
*
name
Attribute
name
type
Compound
Service
1..*
accepted
Message
Inbound
Message
Oneway
Message
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
Request
Message
Type
name
1..*
resp
- 57 -
Outbound
Message
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
SOA – Refined II: QoS
•
•
Another important
aspect is quality of
service and other
provision/consumption
data.
The metamodel on the
right shows how these
aspects can be taken
into account.
Provider
1..*
Consumer
1..*
Provider
Consumer
1..*
1..*
Service
Provision
Service
Consumption
location
… more
location
… more
Service
provided
QoSSpec
required
agreed
Contract
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 58 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
CONTENTS
•
Brief intro to MDSD
•
Architecture – Dehyped
•
Architectural Metamodels
•
The role of patterns
•
Platform vs. code generation
•
Architecture vs. the Programming Model
•
More specific: MDSD and CBD
•
More specific: MDSD and SOA
THE END.
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 59 -
© 2004 M a rk us Vö l te r
MDSD‘s role as an architectural catalyst
Some advertisement 
•
Völter, Stahl:
Modellgetriebene
Softwareentwicklung
Technik, Engineering, Management
dPunkt Verlag, 2005
www.mdsd-buch.de
ingenieurbüro für sof twaretechnologie
w w w.vo el ter.d e
- 60 -
© 2004 M a rk us Vö l te r