MDA Praktisch Modellbasierte Java Entwicklung Markus Völter voelter@acm voelter.de

MDA praktisch

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 3 M a r k u s V ö l t e r. - 1 -

MDA Praktisch MDA Praktisch Modellbasierte Java EntwicklungModellbasierte Java Entwicklung

Markus Vö[email protected]

MDA praktisch


Table of Contents

• MDA/D Introduction and Overview

• Metamodelling

• Example •Metamodel• Implementing the metamodel•Generating Code

• The future: Model Transformations• Summary

MDA praktisch


Table of Contents


• Metamodelling



MDA praktisch


Characterizing 3D• The following mindmap originates from a BoF Meeting at

OOPSLA 2003 which tried to characterize the essential properties of Domain Driven Development, and also relate things such as• GP• MDA• ...

MDA praktisch


Characterizing 3D

Model

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

MDA praktisch


semantics

Characterizing 3D

Model

DomainSpecific

Language

MDA praktisch


semantics

Characterizing 3D

Model

DomainSpecific

Language

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodel

semantics

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

semantics

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domainsemantics

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology

bounded area ofknowlege/interest

semantics

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodel

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget

softwarearchitecture

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transformknowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

knowledge

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

knowledge

several

designexpertise

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

knowledge

several

designexpertise

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

knowledge

several

designexpertise

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

knowledge

several

designexpertise

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

knowledge

several

designexpertise

MDA praktisch


Characterizing 3D

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

portability

knowledge

several

designexpertise

MDA praktisch


MDA?

And MDA?

MDA praktisch


MDA

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

portability

MDA praktisch


MDA

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

portability

UML+Profiles

MDA praktisch


MDA

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

portability

UML+Profiles

MOF

MDA praktisch


MDA

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

portability

UML+Profiles

MOF

OCL, Action Semantics

MDA praktisch


MDA

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

portability

UML+Profiles

MOF


MDA praktisch


MDA

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

portability

UML+Profiles

MOF


PIM, PSM, ....

MDA praktisch


MDA

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology


semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget



transform

compile

interpret

multi-step

single-step

noroundtrip

rapidevolution

customizability

softwarefamilies

productlines

portability

UML+Profiles

MOF


PIM, PSM, ....

MDA praktisch


MDD defined

• Model Driven Development (MDD) means developing executable software from higher-level models.

• A Model in this context is defined to be some specification that cannot be directly executed on current mainstream platforms (such as Java, .NET, Intel x86, ...).•Models can be graphical (e.g. UML, Aris) or they can be textual

(typically called DSLs, or Domain-Specific Languages).

• Code, on the other side, is a directly executable artifact on current platforms.

• Thus, the definition of what is a model and what is code is always relative to current mainstream platforms.•See comparison to lower level / higher level languages and

compilers

MDA praktisch


How to execute models

• Executing models can happen in different ways:•Models can be interpreted by a „model-VM“. Dirk Riehle‘s UML

virtual machine is an example.•Typically, however, models are compiled into lower-level models

or code, which is then executed (compiled or interpreted).

MDA praktisch


Abstraction and Concretization

• To make model-driven development worthwhile, models must provide some higher level of abstraction over the platform on which they are executed.•This higher-level of abstraction is typically achieved by using

domain-specific abstractions in the models.•„Domain specific“ can denote a business domain or a technical

domain•UML models which show a box for each and every

implementation class might be useful, but this is not an example of model-driven development.

• These higher-level models are then typically transformed to more concrete models (and/or finally, code). •This can happen in a single step or in multiple steps.•The rules for such transformations must be specified

somewhere.

MDA praktisch


Abstraction and Concretization: Example

Personnam e: StringfirstNam e : StringbirthDate: Date

age(): int

PersonBeannam e: StringfirstNam e : StringbirthDate: Date

ejbActivate()/ejbPassivate()ejbLoad()/ejbStore()ejbCreate()/ejbDestroy()age()getNam e()/setNam e()getFirstNam e()/setFirstNam e()getBirthDate()/setBirthDate()

<<interface>>

EntityBean<<interface>>

PersonIFage()getNam e()/setNam e()getFirstNam e()/setFirstNam e()getBirthDate()/setBirthDate()

<<logically im plem ents>>rem ote

interface

beanim pl.

bean baseinterface

<<interface>>

PersonHom eIFcreate()

EJBEntity Bean

hom einterface

abst

ract

concrete

MDA praktisch


Software System Families

• Typically, MDD makes most sense in the context of software system families because developing modeling environments, generators, translators, etc. can be a lot of work and it pays only if reused.

• What is a software system familiy?We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members.

Definition by Parnas

MDA praktisch


Examples for Software System Families

• A set of projects in the same domain (banking, telecom switching, automotive diagnosis). • You might be able to generate recurring business logic from models.

• A set of artifacts based on the same infrastucture (such as EJB) in one project. • Here, you might be able to to generate all the infrastructure-specific code

around manually implemented business logic.

• you have some specific business logic that you want to run on different platforms. • You might be able to generate platform-specific implementation code

from the models (this is the focus of MDA)

• a set of artifacts based on the same modelling paradigm, such as state chart. • You might be able to generate the complete implementation based on the

model and its predefined mapping to lower-level implementations.

MDA praktisch


Models in MDA

• This is a taxonomy of models in MDA (adapted from David Frankel‘s MDA book)

M odel

SystemM odel

Business M odel(Domain M odel)

LogicalM odel

Physical M odel(Deployment)

RequirementsM odel

ComputationalM odel

PIM PSM

MDA praktisch


Models in MDA II

• PIMs are independent of any particular implementation platform. They only capture the business logic – the problem space in terms of GP.

• A series of model transformations is then applied to concretize the model for specific platforms. •Mapping rules (as covered

later) are part of the core model definition – they operate on the metamodel defined by the core model.

PIM

PSM

Core M odel

PSM -M etamodel

concrete leve lm eta level

<<instanceof>>

<<instanceof>>

MDA praktisch


Software System Families revisited

• Developing an MDD infrastructure – however simple or sophisticated it may be – is always additional effort.

• Such an infrastructure can include•A clearly defined system architecture•Modelling abstractions, metamodels and profiles•Model verifiers and design checkers•Reusable components and composition rules,

frameworks and libraries•Generators and/or model interpreters

• You only want to do this if this additional effort pays off!

• Like with mass production, the amount of effort you put into the infrastructure must be less than the amount of effort you save when developing the products.

MDA praktisch


Product Line Engineering

• Domain Scoping• Variability Analysis• Domain Structuring

• Define common architecture

• Define Production Plan• Define Building Blocks

• Components• DSLs & Generators• Production Process

Dom ain Analysis

Dom ain Design

Dom ainI m plem entation

MDA praktisch


Variability Analysis

• Variability analysis discovers the variable and fixed parts of a product in a domain. Parts can be•Structural or behavioral•Functional or non-functional (technical)•Modularized or aspectual

• To define variable parts, we need to have a commonality base: a base platform, a common architecture

• There are two kinds of variability:•positive variability: add something (optional)•negative variability: removes something (essential)

• Positive variability leaves the concept intact, while netative variability does not.

MDA praktisch


Example Feature Diagram

• Example products:•An aircraft with a low wing, piston engine

and made of metal, wood and cloth: Robin DR-400

•An aircraft with shoulder wing, no engine and made of plastic: ASW-27

•An aircraft with low wing, jet engine(s) and made of metal: Airbus A320

Engine

Aircraft

W ing

high shoulder low J et Piston

m andatory optional

alternative(1 of m )or (n of m )

Materials

w oodm etal cloth plastic

m andatory

or ( n of m )

MDA praktisch


Feature Diagrams cont‘d

• They can contain constraints on the combinations of features

• They can define „names“ for specific combinations of features; feature groups

• Features can be open: additional subfeatures can be added

• Features can be incomplete: the subfeatures are not yet defined

• Multiplicity of subfeatures can be added

• And more...

MDA praktisch


Binding Time Analysis

• A feature diagram defines the common and variable parts of a system. It has to be determined when it needs to be decided if a specific (sub-) feature will be present in a specific product in the family. This is called binding time.

• Binding time has consequences on•flexibility•performance•code size• type safety•and: on the technique used to implement the variable aspect

MDA praktisch


Typical Binding Times

• source time: manual programming, template parameters, generators

• Compile time: function overloading, precompiler, template evaluation

• deployment/configuration time: component deployment (impl. for an interface), environment variables

• link time: DLLs, class loading

• run time: virtual functions, inheritance & polymorphism, factory-based instance creation, delegation

MDA praktisch


Table of Contents


• Metamodelling



MDA praktisch


Metamodelling defined• Metamodelling denotes the definition of models for models.

• Analogies: • If models are a language, the metamodels are the language‘s syntax and

semantics• If models are considered objects, then the metamodel can be seen as the

metaobjects/MOP

• Why metamodelling?• Models become unambiguous if they are formally defined• Models can become more succinct and more expressive if suitable

metamodels are defined and used• Model exchange and interpretation is only possible if they are based on

a formal metamodel

• As in most cases, modelling uses the UML we will now focus on metamodelling using the UML.

• UML itself is defined in terms of a metamodel, called the MOF (Meta Object Facility). The MOF uses UML as its representation

MDA praktisch


MOF

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 : 05034503Nam e : PersonAttribute : Nam e, Vornam eO perationen : ...Assoziationen : ...

Typ : C lassifierID : 05034503Nam e : K lasseFeatures : A ttributes, O perations,Associations, ...

Typ : C lassifierID : 05034503Nam e : C lassifier

instanceofbeschreibt

MDA praktisch


Models and the MOF

im ports

depends on

Package Classifier

Association

can throw

generalizes

Nam espaceIm port Constraint Tag Feature

BehavioralFeature

GeneralizableElem ent

Class

O peration Exception

M odelElem ent

MDA praktisch


Extending the Metamodel

• Extending the UML metamodel is conceptually simple:

• This can be rendered in one of the following ways:

UM L::Class

CM ::Com ponent

Kundenverw::Person<<CM::Com ponent>>

CM ::Com ponent

instanceof

Kundenverw::Person Kundenverw::Person<<com ponent>>

Kundenverw::Person(a) (b)

(c)

(d)

{m etaclass= CM::Com ponent}

Kundenverw::Person

(e)

MDA praktisch


Extending the Metamodel

• Metamodel attributes are rendered as tagged values in an instance model

UM L::Class

CM ::Com ponenttransaction : boolean


{transactional = true }

MDA praktisch


Stereotypes to define new Metaclasses• UML 1.x

• UML 2.x

<<m etaclass>>UM L::Class

<<stereotype>>CM ::Component

{ <<taggedValue>> transactional }<<stereotype>>


<<stereotype>>CM ::Component


<<stereotype>>CM ::Com ponent

transactional: boolean


{transactional = true }

MDA praktisch


UML 2.x Profile Metamodel

Package

PackageIm port

PackageApplication{subsets

packageIm port}

appliedProfile

<<m etaclass>>Class Extension ExtensionEnd

Stereotype

1 n

/m etaclass

/extension1

n

Association

{subsetsownedEnd}

1 1

Property

type

1

n

Profileim ported Profile

1

n

{subsets im portedPackage}

1

n

ownedStereotype

{subsets ownedMem ber}

MDA praktisch


More Complex Example for a Profile

Com ponent <<stereotype>>Bean

<<stereotype>>EntityBean

<<stereotype>>SessionBean

state: S tateK ind

<<enum eration>>StateKind

statefulstateless

Artifact <<stereotype>>JAR

Interface

<<stereotype>>Remote

<<stereotype>>Home

<<profile>>EJB

context Bean:inv: realization->realizer-> collect(i|i.hasStereotype("Rem ote")->size() == 1 && realization->realizer-> collect(i|i.hasStereotype("Hom e")->size() == 1

MDA praktisch


UML Metamodelling: OCL Constraints II

CarowningCompany = driver.employer

Cardriver.age >= 18

CompanypotentialDrivers = employees->select( age >= 18 )

Companyvehicles->forAll( driver.age >= 18 )

Company::recruit( p : Person )pre : -- nonepost: (employees.size = employees @pre.size+1 ) && (employees.includes( p ) )

Car::drive( p : Person )pre : ( driver == null ) && ( p.age >= 18 )post: driver = p

<<m etaclass>>CM ::ConfigParam

<<m etaclass>>UM L::Attribute

nam e : Stringtype : Type[...]

context Attribute:inv: Type.Nam e == "String"

MDA praktisch


Table of Contents


• Metamodelling


• The future: Model Transformations • Summary

MDA praktisch


Example

• Simple Component Model

• Can be used in embedded systems. A component

• A component has two kinds of interfaces:•A service interface •A resource interface

• A component can have any number of String-type configutation parameters.

<<Com ponent>>Calculator

<<ServiceInterface>>CalculatorSI

add( int, int ) : intsubtract( int, int ) : int

<<RessourceInterface>>CalculatorRI

setLogger( LoggerSI ) <<configParam >>logLevel : S tring

MDA praktisch


Example Metamodel

<<m etaclass>>Component

<<m etaclass>>ServiceInterface

11

<<m etaclass>>Ressourcenterface

1

1

*

*<<m etaclass>>

ConfigParam*

MDA praktisch


Example Metamodel connected to UML-MM

<<m etaclass>>CM ::Com ponent

<<m etaclass>>CM ::ServiceInterface

11

<<m etaclass>>CM ::Ressourcenterface

1

1

*

*<<m etaclass>>

CM ::ConfigParam*


nam e : Stringtype : Type[...]

context Attribute:inv: Type.Nam e == "S tring"


<<m etaclass>>UM L::Interface

MDA praktisch


Tool Support

• Tool Chain•Model is designed in UML Tool.•Model is exported to XMI•Code Generator reads XMI and verifies model against

metamodel, and generates code

• How the code generator worksM etam odel

Classes

Generator Fram ew ork

InputM odel

Parser M etam odelInstantiator

M etam odelInstance

CodeGenerator

Tem plates GeneratedCode

MDA praktisch


Table of Contents


• Metamodelling



MDA praktisch


Implementing the metamodel

• Generator uses an Java implementation of the metamodel used, as well as (typically) the UML Metamodel as a basis.

• Example: Config Parameters

<<m etaclass>>CM ::ConfigParam


nam e : S tring[...] <<m etaclass>>

UM L::Class

<<m etaclass>>UM L::Type

*

1

1

1

Nam e : StringType

MDA praktisch


Implementing the metamodel II

• Basic metaclass definition:

• Impementing the type constraint:

package cm;

public class ConfigParam extends Attribute {}

public String CheckConstraints() throws DesignException {

if ( !Type.Name.toString().equals("String") ) { throw new DesignException( "ConfigParam Type “+ “not String” ); }

return super.CheckConstraints();

}

MDA praktisch


Implementing the metamodel III

• Constraints checking for for component:public String CheckConstraints() throws DesignException {

if ( numberOfAssociations(ServiceInterface.class) != 1 ) {

throw ( new DesignException("No ServiceInterface!”)); }

if ( numberOfAssociations(RessourceInterface.class) != 1 ) { throw ( new DesignException("No RessourceInterface!")); }

return "ok";

}

MDA praktisch


private int numberOfAssociations(java.lang.Class c) throws DesignException {

int count = 0; Iterator it = AssociationEnd.iterator(); while (it.hasNext()) AssociationEnd ae = (AssociationEnd) it.next(); if ( c.isInstance( ae.Opposite().Class ) ) count++; } return count;}

Implementing the metamodel IV

• Constraints checking for for component:


<<m etaclass>>UM L::AssociationEnd

<<m etaclass>>UM L::Association

1

2

*1AssociationEndClass

Opposite

MDA praktisch


public class Component extends Class { public String CheckConstraints() throws DesignException { // check numberOfAssociations as before. if ( !ServiceInterface().Name().toString().equals( this.Name().toString()+"SI") ) {

throw ( new DesignException("SI has wrongName!")); } // dito for ResourceInterface }

public ServiceInterface ServiceInterface() { ServiceInterface si = null; // iterate over associations and return the one that is an

// instance of ServiceInterface. // iteration see numberOfAssocations return si; }

public RessourceInterface RessourceInterface() { … } }

Implementing the metamodel V• Naming conventions checking for Components:

MDA praktisch


Table of Contents


• Metamodelling



MDA praktisch


Implementing the metamodel

• Code generation is based on templates:public class <NameDerKomponente> implements <NameDerKomponente>SI, <NameDerKomponente>RI { // Operationen des ServiceInterfaces // Operationen des ResourceInterfaces // Operationen für den Komponentenlifecycle, // wie start, stop, ...

}

<<m etaclass>>CM ::Com ponent


Nam e(): String

ServiceInterface(): ServiceInterfaceResourceInterface(): ResourceInterface

public class <<Nam e>> im plem ents <<Nam e>>SI, <<Nam e>>RI { // m ore}

Met

amod

ell

Tem

plat

e

MDA praktisch


Templates for Code Generation

• Generating the root – a Java class for each component with a member declaration for each attribute«DEFINE Root FOR Component»

«FILE Name".java"»

public class «Name» {

«EXPAND ParamDefinition FOREACH Attribute»

}

«ENDFILE»

«ENDDEFINE»

«DEFINE ParamDefinition FOR Attribute»

«Type» «Name»;

«ENDDEFINE»

MDA praktisch


Templates for Code Generation II

• Templates support polymorphism[…]

«EXPAND ParamDefinition FOREACH Attribute»

[…]

«DEFINE ParamDefinition FOR Attribute»

«Type» «Name»;

«ENDDEFINE»

«DEFINE ParamDefinition FOR ConfigParam»

«Type» «Name»; // CconfigParam public void configure«CapitalizedName»( «Type» val ) { «Name» = val; }

«ENDDEFINE»

MDA praktisch


Templates for Code Generation III

• Metamodel implementation needs to have the features accessed in the templates.«DEFINE ParamDefinition FOR ConfigParam»

«Type» «Name»; // CconfigParam public void configure«CapitalizedName»( «Type» val ) { «Name» = val; }

«ENDDEFINE»

package metamodel;

public class ConfigParam extends Attribute {[…] public String CapitalizedName() throws DesignException { return Name().toString().substring(0,1).toUpperCase()+ Name().toString().substring(1); }

}

MDA praktisch


Table of Contents


• Metamodelling



MDA praktisch


Model Transformations

• Model transformation in an integral part of MDA (PIM->PSM).

• However, currently, no standard model transformation languages are available; practical large-scale experience with such tools is not available.

• There are several proposals as a request for the OMG‘s QVT RFP.

• I will present some ideas and concepts...

MDA praktisch


Model Transformations - Goal

Personnam e: StringfirstNam e : S tringbirthDate: Date

age(): int

PersonBeannam e: StringfirstNam e : S tringbirthDate: Date

ejbActivate()/ejbPassivate()ejbLoad()/ejbStore()ejbCreate()/ejbDestroy()age()getNam e()/setNam e()getFirstNam e()/setFirstNam e()getBirthDate()/setBirthDate()

<<interface>>

EntityBean<<interface>>

PersonIFage()getNam e()/setNam e()getFirstNam e()/setFirstNam e()getBirthDate()/setBirthDate()

<<logically im plem ents>>

<<interface>>

PersonHom eIFcreate()

Sour

ce

Targ

et

Personnam e: StringfirstNam e : S tringbirthDate: Date

age(): int

Sour

ceTa

rget Person

nam e: StringfirstNam e : S tringbirthDate: Date

age(): int

<<EJB ::EntityBean>>

{transactions=tx.cm t, persistence=persistence.bm p.hibernate, interface=interfaces.rem oteOnly}

MDA praktisch


Model Transformations: Metamodels

• To make the transformation possible, we need the metamodels of the source and the target.

• Transformation rules are based on these metamodels.

• Here, the source metamodel is the normal UML metamodel; the target metamodel could be this simple EJB metamodel.

UM L::Class

EJB::ImplementationClass

UM L::Interface

EJB::Rem oteInterface

EJB::HomeInterface

Rem oteInterfaceinv: extends("EJBObject")

Hom eInterfaceinv: extends("EJBHom e")

EntityBeaninv: im plem ents("SessionBean")

EJB::SessionBean EJB::EntityBean

EntityBeaninv: im plem ents("EntityBean")

MDA praktisch


ModelTx: Procedural and Textual

function createEJBModel( Model source ): Model { Model target = new Model(); foreach c:Class in source.classes { ImplementationClass implClass = new ImplementationClass(); implClass.setName( c.getName()+"Bean" ); target.addClass( implClass ); Dependencies.define( implClass, c ); RemoteInterface ri = new RemoteInterface (); // set name and add it to target model HomeInterface hi = new HomeInterface (); // set name and add it to target model foreach o:Operation in c.operations { ri.addOperation( new Operation( o.clone() ) ); implClass.addOperation( new Operation( o.clone() ) ); } } return target;}

MDA praktisch


ModelTx: Graphical / Declarative I• Precondition:

Representing a class diagram of metalevel n as an object diagram of metalevel n+1

Vehicleplate : S tringtype: S tring

Personnam e : S tring

drive() : void

driver

vehicleC lass:UM L::Class

nam e = "Vehicle"

plateAttr:UM L::Attribute

nam e = "plate"type = "S tring"

plateAttr:UM L::Attribute

nam e = "plate"type = "S tring"

:UM L::AssociationEnd

:UM L::AssociationEndro leNam e = "driver"

personClass:UM L::Class

nam e = "Person"

nam eAttr:UM L::Attribute

nam e = "nam e"type = "S tring"

driveOp:UM L::Operationnam e = "drive"type = "void"...

KlassendiagrammObjektdiagram m

MDA praktisch


ModelTx: Graphical / Declarative II

class:UM L::Class

*

1

AssociationEnd

Class

in com ponent:CM ::Com ponent

out

otherSideEnd:UM L::AssociationEnd

roleNam e = $nnavigable = true

assocA ttributeUM L::Attribute

nam e = $n

thisS ideEnd:UM L::AssociationEnd

assoc:UM L::Association

<<UML::C lass>>Vehicle

plate : S tringtype: S tring


drive() : void

driver

<<CM::Com ponent>>Person

nam e : S tring

<<CM::Com ponent>>Vehicle

plate : S tringtype: S tringdriver : Person

drive() : void

MDA praktisch


ModelTx: Textul / Declarative II

Petage : Integer


P(Package) [ nam e = ’P ’, contents = { (C lass, Person) [ nam e = ’Person’, attributes = { (A ttribute) [ nam e = ’nam e’, type = String], (A ttribute) [ nam e = ’pet’, type = (SetType) [ e lem entType = Pet]]}], (C lass, Pet) [ nam e = ’Pet’, attributes = { (A ttribute) [ nam e = ’age’, type = Integer]}]}]

*

relation Method_And_XML { domain { (UML.Method)[name = n, body = b] } domain { (XML.Element)[ name = "Method", attributes = {(XML.Attribute)[name = "name", value = n]}, contents = {b} ] }}

• Precondition:Representing an objectdiagram textually

MDA praktisch


Table of Contents


• Metamodelling



MDA praktisch


Summary

• MDA in the way we interpret it here is technically possible today.

• Tools are mature (for what they support...) and can be used.

• A suitable development process is required (e.g. b+m GDP)

• If you want to try....

•http://www.gentleware.de for Poseidon/UML

•http://www.architectureware.de orhttp://sourceforge.net/architectureware for the Generator

•http://www.voelter.defor more information and slides

MDA praktisch


Summary II

• The hands-on session will show how to implemet the examples shown here, including•Metamodelling•Modelling•Metamodel implementation•Model verification•Code generation

• Using mainly•Poseidon/UML•And the b+m generator f/w

MDA praktisch


The End.

ThanksQuestions?Comments?Criticism?

Markus Vö[email protected]

www.voelter.de

Documents

MDA Praktisch Modellbasierte Java Entwicklung Markus Völter voelter@acm voelter.de