Markus Völter voelter@acm voelter.de

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2 0 0 4 M a rk u s V ö l t e r- 1 -

MDSD‘s role as an architectural catalyst

Markus Vö[email protected]

The role of MDSD as anArchitectural Catalyst



Markus Vö[email protected]

www.voelter.de

• Independent Consultant

• Based out of Heidenheim, Germany

• Focus on• Software Architecture• Middleware• Model-Driven Software

Development

About me



C O N T E N T S

• 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



C O N T E N T S











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.

Software TechnologyConcepts

Domain Concepts

Software TechnologyConcepts

Domain Concepts

mental workof developers



MDSD on a Slide

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology

bounded area ofknowlege/interest

semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget

softwarearchitecture

softwarearchitecture

transform

compile

interpret

multi-step

single-step

noroundtrip

knowledge

several

designexpertise



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



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.

• One or more model-to-model transformation steps may precede code generation.

ModelModelModel

Transformer TranformationRules

Model

TransformerCode

GenerationTemplates

Generated CodeManuallyWrittenCode

optional

Metamodel

Metamodel

optio

nal,

can

be

repe

ated



Example Tool: openArchitectureWare Generator

• How it works:

specification(model)

instance of

model parser metamodelinstance

templateengine

metamodel

templateswritten interms of

output code



C O N T E N T S











Software Architecture Process „on a slide“

• Today‘s Problems:• Too much technology• Too many hypes and buzzwords• Too many standards too early• So: People don‘t focus on architectural concepts

• PHASE 1: Elaborate!• Technology-Independent Architecture• Programming Model• Technology Mapping• Mock Platform• Vertical Prototype

• PHASE 2: Automate!• Architecture Metamodel• Glue Code Generation• DSL-based Programming Model• Model-based Architecture Validation

…and actually, this isa talk of its own…



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



Cascaded MDSD

MDSD-Infrastructure

Input Models

Output Model

Code Generator forArchitectural MDSD Infrastructure

Code for Target Platform

Programming Model (based on Arch-MM)

M2M/CodeGenerator for SD 1

Model for Subdomain 1

M2M/CodeGenerator for SD 2

Model for Subdomain 2

...

...

...

...

...

...



C O N T E N T S











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 metametamodelling language.

• A metamodel is a modelof a modelling language.It is not „a model of a model!“

• The OMG defines fourmetalevels, the meta-metamodel is called theMOF, or Meta ObjectFacility. M 0: Instanzen

M 1: M odel

M 2: M etamodel

M 3: M eta-M etamodel

instanceof

instanceof

instanceof

beschreibt

beschreibt

Typ : PersonID : 05034503Nam e : VölterVornam e : Markus

Typ : K lasseID : 21436456Nam e : PersonAttribute : Nam e, Vorn.Operationen : ...Assoziationen : ...

Typ : C lassifierID : 764535Nam e : K lasseFeatures : A ttributes,Operations, Assoc's, ...

Typ : C lassifierID : 5346456Nam e : C lassifier

instanceofbeschreibt

beschreibt



How does the MOF look like?

M 0: Instances

M 1: M odel

M 2: M etam odel

M 3: M eta-M etam odel

R un-tim e ob jects

C lass m odel

U M L

M O F

im ports

depends on

Package Classifier

Association

can throw

generalizes

Nam espaceIm port Constraint Tag Feature

BehavioralFeature

GeneralizableElem ent

Class

Operation Exception

M odelElem ent



Example: Simple Model/Metamodel

• We want to define a textual language to define interfaces/classes. Example:

• The metamodel/AST for this kind of definition looks like the following:

class SomeClass { operation doSomething( i:int, j:int ):String; operation anotherOne(): boolean; attribute anAttr: String;};

Class Operation*

nam e nam etype

Attributenam etype

*

Param eternam etype

*



Example: The metamodel(s) of a typical enterprise app

Form Layout

Entity Attribute*

KeyAttribute

TableColumnType

type

*

Mapping

*

Business Objects

Page Form

FormField

*

*

maps

Button

target

Pages, Forms and Workflow

representsrepresents

FormLayout

TabularLayout

SimpleLayout

[...]

[...]

Persistence



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



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)



How do I come up with a good metamodel? III

• A component owns any number of ports.• Each port implements exactly one interface.• There are two kinds of ports: required ports and provided

ports. • A provided port provides the operations defined by its

interface.• A required port provides access to operations defined by

its interface.

Component

Portowns *

Interfaceimplements 1

Required Port Provided Port

providesoperationsdefined by

provides access to operations defined by

• Example:



C O N T E N T S











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.



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.

• Known Uses: • Compilers (different stages)• UNIX shells• CMS Pipelines• Image Processing (ALMA)

pipe

data flow

filter n filter n-1pipe ... pipe filter 1 pipe filter 0

data data''''

data' data'' data'''



A selection of architectural styles

Independent parts

Com municatingProcesses

Event/M essage-basesSystem s

Data Flow

BatchSequential

Pipes andFilters

DataCentered

Repository Blackboard

Virtual M achine

Interpreter Rule-Based M icrokernel

Call andReturn

Procedural Objectoriented Layers

Reflection

ComponentsPlug-Ins

Fram eworks

W orkflow



C O N T E N T S











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.

• 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 is often framework completion code – DSLs make frameworks easier to use!

GeneratedCode

PlatformStalagmite

Stalagtite



Rich Domain-Specific Platform

• Define a rich domain-specific application platform consisting of • Libraries• Frameworks• base classes• interpreters, etc.

• The transformations will “generate code” for this domain-specific application platform.

• As a consequence, the trans-formations become simpler.

• DSLs and Frameworks are two sides of the same coin

DomainPlatform

TechnicalPlatform/Middleware

Operating System

Programming Language

- Persistence- Transactions- Distribution- Scheduling- Hardware Access- ...

- Core Domain Classes (Entities, Value Types, ...)- Business Rules- Business Services- ...

Generated Applications



C O N T E N T S











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.



Architecture „Enforcement“ using MDSD

• Example:

• Problem: How do you ensure that developers can actually only reference (use) those components, which are declared as being used in the model?

<<application>>SMSApp TextEditor

UIManagerGSMStack

CallIFSMSIF EMSIF

SMSIF

MenuUtilities

lookAndFeel: String



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



Improved Solution, with MDSD

public interface SMSAppContext extends ComponentContext { public TextEditorIF getTextEditorIF(); public SMSIF getSMSIF(); public MenuIF getMenuIF();}

• 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

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();} }



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!



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

• subsequent checks check the manually written code for consistency with the guidelines/programming model

public class SCMComponentBase ... {

static { if ( false ) { SCMComponentBase i = (SCMComponentBase) (new SCMBusinessComponent()); } }

}



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...



oAW Recipe Framework Screenshot



C O N T E N T S











Three Basic Viewpoints

<configurations> <configuration name="addressStuff"> <deployment name="am" type="AddressManager"> <wire name="personDAO" target="personDAO"/> </deployment> <deployment name="personDAO" type="PersonDAO"/> </configuration> <configuration name="customerStuff"> <deployment name="cm" type="CustomerManager"> <wire name="addressStore" target=":addressStuff:am"/> </deployment> </configuration> <configuration name="test" includes="addressStuff, customerStuff"/></configurations>

<<component>>AddressManager

<<interface>>AddressStore

addOrUpdateContact( p: Person) : voidaddAddress( p: Person, a: Address) : voidgetAddresses( p: Person ) : Address[]

<<entity>>Person

name: StringfirstName: String

<<valuetype>>Address

street: Stringzip: StringCity: String

0..n

<<component>>CustomerManager

address-Store

<systems> <system name="production"> <node name="server" type="spring" configuration="addressStuff"/> <node name="client" type="eclipse" configuration="customerStuff"/> <system> <system name="test"> <node name="test" type="spring" configuration="test"/> <system></systems>

Type Model

Composition Model System Model

person

• Type Model: Components, Interfaces, Data Types• Composition Model: Instances, “Wirings”• System Model: Nodes, Channels, Deployments



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 ModelComposition Model Composition ModelComposition Model(s)System Model(s) Type/Data Model



Type Metamodel

Interface Operation *

target

providedInterfaceComponent

ComponentInterface

Requirement

*requiredInterface

name name

name

name

Type

returnType

name

Parameter

name *

type

Exception

*exception



Type Metamodel II (Data)

Type

name

PrimitiveType

ComplexType

DataTransferObject

Entity

Attribute *

name

attribute type

EntityReference

nameisBidirectionaltargetMultiplicitysourceMultiplicity

*ref

target

src



Composition Metamodel

Interface *

target


ComponentInterface

Requirement

*requiredInterface

name name

nameComponent Stuff

Composition Stuff

ComponentInstance

name

Configuration

name *

instance

type

Wire

name *

cireq

target

context ComponentInstance inv:foreach of type’s Component-InterfaceRequirementsthere must be a Wire of the same name

context Wire inv:the type of the target instance must provide the Interface pointed to by the Wire’s cireq’s target



System Metamodel

ComponentInstance

name

Configuration

name *

instanceWire

name *

Composition Stuff

System Stuff

System

name

Node

name

Container

name

*

*

*



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.



Three Basic Viewpoints – Generated Stuff

• Base classes for component implementation• Build-Scripts• Descriptors• Remoting Infrastructure• Persistence• …



Generated Stuff II

• 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.

<<component>>StdOutConsole

<<component>>HelloWorld

IHelloWorldIConole

{persistent}

<<component>>SomeComponent

<<generate>><<man-code>>

SomeCompo-nent.java

<<interface>>SomeInterface

<<gen-code>>Some-

Interface.java

<<generate>>

<<gen-code>>Some

ComponentBase.java



Cascading: Persistence

<<gen-code>>SomeEntity.java

<<entity>>SomeEntity

<<generate>>

<<interface>>SomeEntityDAO

<<transform>><<generate>> <<gen-code>>

SomeEntity-DAO.java

<<component>>SomeEntityDAO

<<transform>><<generate>> <<gen-code>>

SomeEntity-DAOBase

.java

<<gen-code>>SomeEntity-

DAO.java

<<generate>>



Cascading: Processes

<<generate>>

<<gen-code>>AProcess-Data.java

<<proc-component>>AProcess

<<gen-code>>AProcessBase

.java<<gen-code>>

AProcessProcBase.java

<<trigger-interface>>AProcessInterface

*

1

sm AProcess

<<entity>>AProcessData

<<tra

nsfo

rm>>

s1

s2

s3

<<generate>> <<generate>>operations...

attributes...

data

1

<<tra

nsfo

rm>>

guard operations... (abstract)action methods... (abstract)

<<man-code>>AProcess.java



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

• However, for special kinds of components (“component kind” will be defined later) can use different implementation strategies -> Cascading!

<<component>>SomeComponent

<<generate>><<man-code>>

SomeCompo-nent.java

<<interface>>SomeInterface

<<gen-code>>Some-

Interface.java

<<generate>>

<<gen-code>>Some

ComponentBase.java



Component Implementation II

• Remember the example of the process components from before:

• Various other implementationstragies can be used, such as:• Rule-Engines• “Procedural” DSLs or action

semantics

• Note that, here, interpreters can often be used sensibly instead of generating code!

<<generate>>

<<gen-code>>AProcess-Data.java

<<proc-component>>AProcess

<<gen-code>>AProcessBase

.java

<<gen-code>>AProcessProcBase.jav

a

<<trigger-interface>>AProcessInterface

*

1

sm AProcess

<<entity>>AProcessData

<<tra

nsfo

rm>>

s1

s2

s3

<<generate>> <<generate>>operations...

attributes...

data

1

<<tra

nsfo

rm>>

guard operations... (abstract)action methods... (abstract)

<<man-code>>AProcess.java



Aspect Models

• Often, the described three viewpoints are not enough, additional aspects need to be described.

• These go into separate aspect models, each describinga well-defined aspect of the system.• Each of them uses a suitable DSL/syntax• The generator acts as a weaver

• Typical Examples are• Persistence• Security• Forms, Layout, Pageflow• Timing, QoS in General• Packaging and Deployment• Diagnostics and Monitoring

System Model(s)

Com

posi

tion

Mod

el(s

)

Type/Data

Model

Aspect1

Aspect2

Aspe

ct3

Aspect4



Example Aspect: Persistence

• The following example shows a possible metamodel for a persistence aspect:

Type

name

PrimitiveType

ComplexType

DataTransferObject

Entity

Attribute *

nameattribute type

EntityReference

nameisBidirectionaltargetMultiplicitysourceMultiplicity

*ref

target

src

DBPrimitiveType

base

EntityTable

entity

Column *

namecolumn

attribute

name

Index

name

index**

{ordered}

pk

*RefTable

name

ref10..1

from

to

Query

nameexpression

*

QueryComponent

Component

name

*



C O N T E N T S











SOA – Trivial

• Some people consider a well-done component-based system already a service-oriented architecture. Adopting this view, results in the following metamodel:

Service Operation *

target


ComponentService

Requirement

*requiredInterface

name name

name

name

Type

returnType

name

Parameter

name *

type

Exception

*exception



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.



SOA – Refined

Service

Message

name

Type

name

Attribute

name *

type

RequestMessage

OnewayMessage

OutboundMessage

1..*

MessageFlowControl

*

*ElementaryService

resp

InboundMessageaccepted

Message

1..*Compound

Service

Component

name

Provider Consumer

0..1

1..*1..*

1..*

providesconsumes p

c

1..*

ProviderConsumer



SOA – Refined II: QoS

• Another importantaspect is quality ofservice and other provision/consumptiondata.

• The metamodel on the right shows how theseaspects can be takeninto account.

ServiceProvision

Service

Provider

1..*

ServiceConsumption

Consumer ProviderConsumer

1..* 1..*1..*

QoSSpec

location… more

location… more

requiredprovided

Contract

agreed



C O N T E N T S








• More specific: MDSD and SOA THE END.



Some advertisement

• Völter, Stahl: Modellgetriebene SoftwareentwicklungTechnik, Engineering, ManagementdPunkt Verlag, 2005www.mdsd-buch.de

Markus Völter voelter@acm voelter.de

Documents

Transcript of Markus Völter voelter@acm voelter.de