Model-Driven Software Development - Semantic Scholar · Vision of Model-Driven Software Development (MDSD) (2) MDSD is a paradigm shift models substitute code models play the central

© Jürgen Dunkel 2007 | Model-Driven Software Development 1

Model-Driven Software Development

Hannover University of Applied Sciences and Arts

Department of Computer Science

Jürgen Dunkel

[email protected]



1. Introduction

2. Meta modeling

3. Domain-Specific-Languages (DSL)

4. Model Transformation and Code Generation

5. Standards: OMG/Model Driven Architecture (MDA)

6. Case-Study

7. Best Practices

8. Conclusion

Lab: MDSD using openArchitectureWare



References

T. Stahl, M. Völter: Model-Driven Software Development, Wiley, 2006

MDA Guide Version 1.0.1, http://www.omg.org/docs/omg/03-06-01.pdf

A. Brown: An introduction to Model DrivenArchitecture,

http://www-106.ibm.com/developerworks/rational/library/3100.html

A. Kleppe, et. al.: MDA explained, Addison Wesley, 2003

J. Dunkel, R. Bruns: Model-Driven Architecture for Mobile Applications,

in: W. Abramowicz (ed.), Proceedings of 10th International Conference on Business

Information Systems, Poznan (Poland), Springer, Lecture Notes LNCS 4439, pp. 464-477,

2007.



1. Introduction

1.1State-of-the Art in Software Development

1.2Vision of Model-Driven Software Development

1.3MDSD Prerequisites and Basic Steps

2. Meta Modeling




7. Case-Study

8. Best Practices

9. Conclusion



1.1 State-of-the Art in Software Development

Problems in Software Development

� abstraction level of programming languages is too low

� lots of details have to be specified: persistence, access rights, user

interfaces,…

� coding is not very creative

� cut & paste from existing example

� time-consuming, very detailed and error-prone

� standard modeling languages (UML) are too general

� UML is nearly on the same abstraction level as source code

� low level concepts as classes, methods, attributes

� not adapted to a special domain



Code Generation

� to accelerate software development

last decade: UML- tools offering round-trip-engineering

� generating code skeletons from models

� reverse engineering just yields source code visualization

� model and code have the same level of abstraction

� no significant productivity gain

now: integrated tools

� differences between UML tools und IDE‘s are diminishing

� editors, compilers, UML-Tools,..-.

� generate code skeletons, GUI, refactoring, …

� but: not adaptable to (specific application/technical architecture)



Example: Code Generation in Integrated Tool

Problems:

� code is generated for a specific platform (here: J2EE)

� bound to a technology

� can’t be changed to another platform (Spring, Hibernate, Struts, domain architecture)

� model have a low abstraction level

� no general and flexible concept for generating code

Interface

PersonLocal

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

Interface

Person

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

Interface

PersonHome

create()

findByPrimaryKey()

findOlderThan()

Interface

PersonLocalHome

create()

findByPrimaryKey()

findOlderThan()

Interface

EntityBean

ejbActivate()

ejbLoad()

ejbPassivate()

ejbRemove()

ejbStore()

setEntityContext()

unsetEntityContext()

PersonBean

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

setEntityContext()

getEntityContext()

ejbCreate()

makeOlderThan()

Interface

PersonLocal

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

Interface

PersonLocal

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

Interface

Person

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

Interface

Person

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

Interface

PersonHome

create()

findByPrimaryKey()

findOlderThan()

Interface

PersonHome

create()

findByPrimaryKey()

findOlderThan()

Interface

PersonLocalHome

create()

findByPrimaryKey()

findOlderThan()

Interface

PersonLocalHome

create()

findByPrimaryKey()

findOlderThan()

Interface

EntityBean

ejbActivate()

ejbLoad()

ejbPassivate()

ejbRemove()

ejbStore()

setEntityContext()


Interface

EntityBean

ejbActivate()

ejbLoad()

ejbPassivate()

ejbRemove()

ejbStore()

setEntityContext()


PersonBean

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

setEntityContext()

getEntityContext()

ejbCreate()

makeOlderThan()

PersonBean

getOid()

getName()

setName()

getAlter()

setAlter()

makeOlder()

setEntityContext()

getEntityContext()

ejbCreate()

makeOlderThan()

Person

oidnamealter

makeOlder()


1.2 Vision of Model-Driven Software Development

Vision of Model-Driven Software Development (MDSD) (1)

� modeling instead of programming

� generating code from models

� and: model has a higher abstraction level than code!

� general und flexible concept for code generation

� adaptable to arbitrary target platforms

� swing GUIs, J2ME applications, persistence frameworks, …

� generating arbitrary artifacts

� source code, XML descriptors, SQL scripts, test cases, documentation,…

� advantages

� faster development because of higher abstraction level

� higher quality



Vision of Model-Driven Software Development (MDSD) (2)

� MDSD is a paradigm shift

� models substitute code

� models play the central role in software development

� models are assets not additional effort

� MDA (Model-Driven Architecture)

� is the MDSD initiative of the OMG

� defines some standards (MOF, XMI, QVT, …)



Which code can be generated?

� schematic code can be generated from model

� transformation by code generator

code of a reference application

individualcode

codeanalysis

genericcodeschematic

code

generic code

� application independent: (e.g.

technical services)

� not changed

schematic code

� different for distinct

applications

� but structurally the same

individual code

� different for distinct

applications

� cannot be generated

model

transformation

platt-form

individualcode

schematiccode

uses generates


1.3 MDSD Prerequisites and Basic Steps

MDSD Prerequisites (1)

� formal models

� only precise models allow automatic code generation

� leave no room for interpretation

� domain specific models

� general (UML-) models lack the necessary information for code generation

� semantically rich models required

� use a DSL (Domain Specific Language)



MDSD Prerequisites (2)

� Domain Specific Language (DSL)

� modeling language

� adapted to a specific domain: e.g. user interfaces, web shops, workflow systems

� can be graphically or textualy notated

� Powerful Target Platform

� target platform defines the type of code to be generated

� for a powerful platform requires less code generation

� e.g. J2EE requires deployment descriptor instead of SQL code



Basic Steps of Model-Driven Software Development

1. Analysis of target platform

� which application parts can be generated?

� analyzes a reference implementation

2. Defining a Domain Specific-Language (DSL)

� formal definition of a new modeling language

� using a meta-modeling language

3. Modeling the application: Domain Specific Modeling (DSM)

� using the DSL defined in step 2

4. Code generation

� transforming the DSM model from step 3 into code artifacts

� using code generators which know how the model elements

of the DSL can be transformed into code of the target platform

Defining a DSL (domain specific language )

DSM domain specific modeling

Code Generation

Analysis of

Target Platform



Comparing MDSD and RUP

Classical Approach (RUP)

� informal requirements

� semi-formal design

� interpretable

� not automatically transformable

� high implementation efforts

Model-driven Development

� semi-formal requirements

� formal design

� allowing code generation

from Petrasch: MDA, dpunkt, 2006



MDSD – A Simple Example (1)

� just to give a first impression

1. Analysis of Target platform

� generating J2EE applications

2. Defining a Domain-Specific-Language (DSL)

� specifying new elements for a modeling language

� e.g just introducing new UML stereotypes

� that‘ s not a real formal definition !

<<BusinessEntity>>, <<unique id>> <<query>>

<<EJB EntityBean>>, <<primary key>>, <<EJBFinderMethod>>{EJBPersistenceType=Container}



MDSD – A Simple Example (2)

3. Modeling the application: Domain Specific Modeling (DSM)

� modeling the application using the stereotypes defined in the DSL

4. Code generation

� generator loads model and generates source code (and deployment descriptor)

<<BusinessEntity>>Account

<<unique id>> numberbalance

<<query>>findByNumber()withdraw(amount): double

Stereotypes

public interface Konto extends EJBObject{..}

public interface KontoHome extends EJBHome{..}

public abstract class KontoBean implements EntityBean{..}

public KontoPK implements Serializable {..}

<<EJBEntityBean>>Account

<<primary key>> numberbalance

<<EJBFinder>>findByNumber()withdraw(amount: double}

{EJBPersistenceRype=CBP}



1. Introduction

2. Meta Modeling

2.1 DSLs as Formal Languages

2.2 Meta Modeling Layers

2.3 Meta Modeling Languages




6. Case-Study

7. Best Practices

8. Conclusion



2.1 DSLs as formal languages

Domain Specific Language (DSL)

� key concept of MDSD

� a DSL is a modeling language

� contains domain specific modeling constructs

� often extension of a standard modeling language (=UML)

� a DSL is a formal language

� with a defined syntax

� it can be proved models are well-formed

� only precise models can serve for code generation

� no room for interpretations

� generator can only cope with model elements it knows

� a DSL has a well-defined semantic

� mapping model elements to the domain

� generator transforms model elements into artifacts (e.g. code)

� e.g. a stereotype <<key>> is mapped to a data base primary key


2.1 DSLs as formal languages

Examples of Domain Specific Languages (DSL)

� are domain specific modeling languages – not general purpose

� Examples:

� UML

� ERM

� BPMN, BPEL, XPLD

� Petri Nets

� OCL

� Latex

� YACC

� How can DSLs be formally defined??

� �� meta models



Meta model

� goal: formal definition of a DSL

� often modeling languages are not defined precisely

(that’s good enough for usage but not for code generation)

� meta model is a model which defines a new modeling language

� defines modeling elements

� and their relations dependencies and constraints

� meta model determines only the abstract syntax

� e.g. the UML-meta model doesn’t specify a graphical notation

� the concrete (graphical) notations is defined by the concrete syntax

Meta model examples:

� XML schema can be considered as a meta model of XML data

� Backus Naur Form (BNF) to define programming languages



OMG Meta Model Layers

M0: Instance, Data

� objects are instances of a class models

� e.g. Java runtime objects

M1: Model

� defines the classes of a domain (with its

attributes, methods, stereotypes,..)

� e.g. UML class model, FSM

M2: Meta model

� defines a modeling language (e.g. UML)

� determines elements used in M1 (e.g.

classes, methods, attributes),

� e.g. UML meta model

M3: Meta meta model

� meta-modeling language

� defines the elements of a meta model (i.e. a

modeling language of layer M2)

� e.g. OMG/ MOF (Meta Object Facility)

M0: Instances

M1: Model

M2: Meta model

M3: Meta meta model

Typ: Personid: 47112342341name: Daisyage: 33

Typ: Classid: 213424Name: PersonAttributes: name, age

Operations..

Typ: Classifierid: 4564737347Name: KlasseFeatures: Attributes,

Operations, Associations

Typ: Classifierid: 4564737347Name: Classifier

instance describes

describes

describesinstance

instance



MOF Meta Model Architecture

from: OMG: Meta Object Facility (MOF) Specification , Version 1.4

MOF Model

UMLMetamodel

ERMMetamodel

UMLModelsIDL

InterfacesPaket1UML

Models

Paket2ERM

Interfaces

M2 layermeta models

M1 layermodels

M3 layermeta meta model

M0 layer



Meta-modeling languages (Layer M3)

� define the elements of a meta model:

� e.g. what are the base constructs of UML?

� meta models can be described using different meta-modeling languages

� (E)BNF – (Extended) Backus Naur Form

� well-known (text based) language to specify a programming language

� MOF (Meta-Object-Facility)

� OMG standard

� actual version MOF 2.0

� EMF/ECore – Eclipse Meta Framework

� developed by IBM

� simplified version of MOF 1.x ( ≈ EMOF)


2.3 Meta Modeling Languages – EBNF

(E)BNF – Extended Backus Naur Form

� well-known (text based) language to specify a programming language

� BNF introduced by Nikolaus Wirth to define Pascal

� specifies a set of derivation rules: <symbol> ::= <expression with symbols>

Notation

terminals: are used in the language written in “ “

symbols: are nonterminals (not used in language)

| choice

digitExcludingZero = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;

digit = "0" | digitExcludingZero ;

{ … } repetition

naturalNumber = digitExcludingZero , { digit } ;

[ …] option

integer = [ '-' ] digitExcludingZero { digit } | '0' ;


2.3 Meta Modeling Languages – EBNF

Backus Naur Form - simple example

program = 'PROGRAM' , white space , identifier , white space , 'BEGIN' , white space ,

{ assignment , ";" , white space } ,

'END.' ;

identifier = alphabetic character , [ { alphabetic character | digit } ] ;

number = [ "-" ] , digit , [ { digit } ] ; string = '"' , { all characters − '"' } , '"' ;

assignment = identifier , ":=" , ( number | identifier | string ) ; alphabetic character = "A" | "B" | …. "Z" ; digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;

white space = ? white space characters ? ; all characters = ? all visible characters ? ;

PROGRAM DEMO1

BEGIN

A0:=3; B:=45; BABOON:=GIRAFFE;

TEXT:="Hello world!";

END.


2.3 Meta Modeling Languages – MOF

OMG / Meta Object Facility (MOF) Version 2.0

� MOF was defined to formally specify UML formal

� MOF uses a UML kernel (UML2 Infrastructure Library)

� self-descriptive: MOF defines MOF

� used for defining UML

� historically UML was defined before MOF

� MOF elements have similar or same names as in UML,

e.g. UML::Class and MOF::Class

� actual version MOF 2.0 consists of

� Essential MOF (EMOF)

� Complete MOF (CMOF)



MOF elements

� define basic concept for defining modelling languages

� similar to class diagrams in UML (structural models)

� model element

� class (MOF::class,…)

� association

� operation

� attribute

� reference

� data types

� package

� constraints


aus: http://de.wikipedia.org/wiki/Meta-Object_Facility


OMG / Meta Object Facility (MOF) Model

� simplified overview



Essential MOF – Classes

aus: OMG: Meta Object Facility (MOF) Specification , Version 2.0



Relation between model and meta model

� a model is an instance of the meta model

-

-

-

-

-

-

-

-

-

Classifier

Generalization

0..1 0..*

specific

0..1 *

general

Person

Student

instanciates

instanciates

instanciates

M1: UML modelM2: UML meta model


2.3 Meta Modeling Languages – Ecore

Eclipse Ecore – Meta model (1)

� corresponds to EMOF

� often used: simpler than MOF, well-integrated in Eclipse, tool support

Example: (simplified, in parts)



Eclipse Ecore – Meta model (2)



Usages of Meta Models

� used in code generation

� code transformation is a mapping (function) between

� modeling elements defined by a meta model and

� (code) artifacts

� model validation

� check if a model is correct, i.e. consistent with a DSL



1. Introduction

2. Meta Modeling


3.1 Defining new DSLs

3.2 Extending General Purpose Modeling Languages

3.3 DSL Modeling Tools



6. Case-Study

7. Best Practices

8. Conclusion




Defining a Completely New Modeling Language

� introducing new domain specific concepts

� and the corresponding relations and constraints

advantage:

� specific language is well-adapted to the domain

� special graphical notation (e.g. Petri nets, BPMN,…)

� e.g. general modeling languages as UML not well-suited for GUI specification

disadvantage:

� high developing efforts

� specifying the DSL

� developing modeling tools (especially: graphical modeling editors)

� but: almost tools exist to generate graphical editors from Ecore model

(� Eclipse GMF (Graphical Modeling Framework)



Example (1): Meta Model (DSL) for Petri Nets

� here: described in UML/MOF

� defining the abstract syntax



Domain Specific Models (DSM)

� is an instance of the meta model defined by the DSL

� uses a concrete syntax (here a graphical notation)



Example (2): Meta model (DSL) of UML

� originally UML wasn‘t formally defined

� UML meta model describes the abstract syntax

� ca. 90 meta classes, 100 meta associations

� use case, activity, class diagrams,..

� data types

� using UML diagram (circular definition)

� concrete syntax is informally described

� semantic: using OCL and informally

OMG: UML Modeling Language Superstructure, Version 2.1.1, 732 pages, Feb. 2007



UML Meta Model (1)

� for class diagrams



UML Meta Model (2)

� for use case diagrams



Extending Existing Modeling Languages

� extending an existing modeling language with additional modeling elements

� i.e. usually UML is used

� well-known and good tool support

advantage:

� small effort: DSM editors already exist

disadvantage:

� UML not specifically adjusted to domains

� UML notation (concrete syntax) not well-suited for all domains (e.g. GUI design)



Extending the UML

Light-weight extensions

� using the UML extension mechanism

� UML profiles

� stereotypes, tagged values, constraints

� annotating standard UML elements

� hint: the OMG has already defined some profiles (e.g. J2EE profile)

Heavy-weight extensions

� extending the UML meta model

� prerequisite: UML tool provides UML meta modell

� yields a non-standard version of the UML



Profiles – Light-weight Extensions of UML

� meta modeling layer (M2 )

� definition of class stereotypes and attribute stereotypes

Problem:

� relations between stereotypes and constraints are not defined

� e.g. <<key>> attribute is only allowed in EntityObject



Example – UML Profiles

� architecture-centric stereotypes: window, controller, entity class, process class

� here: MVC architectural style



Heavy-weight extensions of UML

M1

M2

M3



Extending the UML-Meta model

� use the elements of the UML meta model (MOF resp.)

� own domain specific classes inherit from UML meta model classes

meta model (M2) – DSL

model (M1) – DSM

inheritance stereotypes tagged values

MySystem::Person

{metaclass=FBI::Component}



Problems of meta modeling

� defining constraints correctly is sometimes difficult

Example 1: all entities (instances of the meta class Entity) have to implement an interface

Example 2: all entities must posses an id

wrong: correct: context Entity:realization�exists (r | r oclIsTypeOf MyInterface)

wrong: correct: context Entity:attribute�select (Name=‘id‘)->size =1)

- OCL-Constraint for meta classe Entity- meta class Entity implements MyInterface

- meta class Entity has an attribute id



Tool Support for Meta Modeling

� specialized meta modeling tools

� often proprietry meta modeling language

� not widely-used: MetaEdit+, Cubetto,

� UML tools

� provide only limited support for meta modeling

� standard: definition of new stereotypes

� no model validation, OCL support, …

� important: model export in XMI format for sub-sequent processing (code- generation)

� Examples:

� UML tool: MagicDraw

� Eclipse Ecore

� EBNF: openarchitectureWare/Xtext



Model Serialization and Model Access

XMI (XML Metadata Interchange)

� XMI provides a loss-free mapping: UML model ↔ XML

� allows subsequent processing of models

� requires a well-defined DSL (here: UML meta model)

� UML meta model elements (<Classifier> <Property>,,..) are XMI tags

Java Metadata Interface (JMI)

� maps MOF models to Java

� refAllOfType() yields all classes of a model (as umlClass-objects)



Example 1: Meta Modeling in MagicDraw

� defining DSL elements

a. specifying new stereotype <<myStereotype>>

Toolbar-> Profiling Mechanism ->Stereotype

b. assigning to a UML meta model class

(here UML::Class and UML::Property)

� using stereotype in UML model (DSM)

� saving the UML model in XMI format: mymodel.xml



Example 2: Using Ecore in openArchitectureWare/Eclipse � Eclipse version (3.2 , not 3.3) JDK >= 1.5

� EMF-pugin http://www.eclipse.org/modeling/emf/downloads/

� OAW 4.1.2 SKD plug-in (http://www.eclipse.org/gmt/oaw/download/)

� define openArchitectureWareProject

- newProject-> other->

openArchitecturwareProject

- choose: „generate a simple example“

� definition of meta model

� in ECore

� saved in metamodel.ecore

� domain specific modelling (DSM)

� in XMI format

� in file: model.xmi



Ecore model (DSL) for JavaBeans

� Model:

� has name an set of entities

� Entity:

� has name, attributes and references

� Attributes and references

� have name and type

� simple meta model editor

� tree representation

� pop-up-menus

� has also an XML representation



Ecore model (DSL) as XML file

� not used



Instance of Ecore Meta Model

(DSM)

� uses the meta model elements

� instantiates the meta model

� entities Driver and Car

� simple modeling editor

� XML representation



Problems of Using Ecore Meta Models in Eclipse

� ECore model editor is cumbersome

� DSL constraints cannot be specified

� modeling editor is tedious

� constraints are not checked



Example 3: Meta Modeling using openArchitectureWare/Xtext

� textual description of the DSL using Xtext

� Xtext similar to Extended BackusNaur-Form (EBNF)

� generates Ecore model

� own constraint language called Check

� similar to OCL

� generates DSM editor from ECore model

� supports syntax highlighting and

� constraint checking



Create Xtext project

• newProject-> other-> xtext-Project

• generates 3 additional projects

• in xtend.example the DSL

has to be specified



Definition of DSL Grammar using OAW/ Xtext

� similar to EBNF (extended Backus Naur Form)

• * repetition • | alternative • terminal literals in “ “

� definition of rules:

� (Model ist Root-Element)

� abstract model element not usable in DSM

Model :

(entities+=Entity)*;

Entity :

"entity" name=ID ("extends"extends=ID)? "{"

(features+=Feature)*

"}";

Abstract Feature :

Attribute | Reference;

Attribute :

"attr" type=ID name=ID;

Reference :

"ref" type=ID (multiple?"[]")?name=ID;



Generating ECore model and DSM editor

� generates from Xtext specification

� ECore-Model (in exampledsl.ecore)

� and an model editor in the project

extext.example,editor



Usage of the DSM editor

� start (run as) Eclipse applikation

in project xtext.example

� create a simple Java project

� create a file with extension dsl

� the generated editor works automatically

with dsl-files



Defining Constraints

� constraints analogue to OCL

� attribute name are unique

� defining allowed datatypes

� references only to defined types

� OAW chck language-Sprache

� uses Java functions

import exampledsl;

entity(Feature this) :(Entity) eContainer;

model(Entity this) :

(Model) eContainer;

datatypes() :

{"string","int","boolean"};



Overview of DSL modeling approaches (1)

1. UML based modeling

- light weight extensions: stereotypes - heavy-weight extension: use UML meta model

- easy to use, good tool support - tool provides meta model classes

Problems:

- difficult to use constraints (yet no OCL support)

- XMI model export is very complex




2. ECore modeling

- in-place editor in Eclipse for developing

- ECore based DSLs

- and DSL-based models (but: very simple)

- only few concepts : EClass, EOperation,

EAttribute, EReference, EAnnotation

- corresponding XML format very simple

Problems:

- no constraints

- editor to simple for complex models

- � use GMF for creating graphical model editor




3. EBNF modelling

- Xtext as proprietary EBNF language

- in-place editor in Eclipse Xtext (but: very simple)

- specifies Ecore model

- model constraints can be formulated by OCL-like

language

- model editor can be generated (considering

constraints)

Problems:

- proprietary languages for EBNF and for constraints

- EBNF not appropriate for complex models?



1. Introduction

2. Meta Modeling

3. Domain Specific Languages (DSL)


4.1 General Characteristics of Model Transformations

4.2 Transformation Languages

4.3 Code Generation and Target Platforms


6. Case-Study

7. Best Practices

8. Conclusion




Transformation and Code Generation

� each transformation is a chain of mappings:

model1 �� (model2 �� …. �� modeln ��) code

� model1 describes a domain model not related to any technology

� model1 , … modeln describe intermediate stages related to a specific technology

� the final transformation generates code for the target platform



One-stage and Multiple-stage Model Transformation

Model Driven Software Development

� there is one direct transformation from model to code: model �� code

� problems:

� there is only one level of abstraction

� code generator must fill a great semantic gap

� meta model must specify all the details required for code generation

(e.g. persistence, GUI, business logic,…)

OMG/ Model Driven Architecture (MDA)

� defines transformations between models: model1 �� model2 �� …. �� modeln �� code

� there are multiple abstraction levels / meta models

� transformators / generators can focus on a coherent task



Defining Transformations

� a model transformation is a set of transformation rules

� each transformation rule maps elements of source DSL to concepts of the target DSL

{element| element Є DSLsource} � {element| element Є DSLtarget}

� transformations tool

� imports a domain specific model (DSM) based on source DSL

� applies the transformation rules



Transformation Rules

� mapping model elements

� described in transformation language

� usually based on markings in the model

� e.g. UML stereotypes

� for each marking exists a certain transformation rule

� add aspects of the target platform

� abstract from (filter) irrelevant aspects of the source model

� different types of rules: refinement, abstraction, merge, translation, …



Informal Example of a Transformation Rule

� Generation of a data base scheme

� search for all UML classes with stereotype <<entity>> in the DSM:

� create for each UML class of stereotype <<entity>> a table

(table name = class name)

� create for each attribute a column (column name = attribute name)

� for each attribute with <<unique key>> create primary key constraint



Problems of Re-Generating

� manually implemented code may not be overwritten

1. Solution approach: protected regions

class MyClass{

public void myMethod(){…

//PROTECTED REGION ID(7787FbD567methodbody) START

// adding implementation

//PROTECTED REGION END

}

� hand-made code and generated artifacts are merged

� readability and maintenance is difficult

� renaming can cause deletion of manual code

� hint: usage of versioning system is important



2. Solution approach: Separation of manual and generated code

� generated and manual code is stored in different files

� solution depends on target platform, e.g.

� include files (e.g. for JSP)

� strategy / template pattern for source code

� Aspect Oriented Programming (AOP)

class Persistent{

abstract public String getInsert(); // defines Hot Spot

}

class Person extends Persistent{

public String getInsert() { return “insert ..“;}

}

� manual and generated artifacts aren’t merged

� but: there are a many files

� readability and maintenance is also quite difficult



3. Solution approach: UML Action Semantics

� algorithms (method bodys) are specified in the UML model

� Action Semantics allows a platform-independent description of algorithms

� can be attached as marks to class operations

� goal: executable UML models



Transformation Tool Architecture

1. Model Import (in XMI)

� parsing the (XML-) Modell

2. Model Validation

� based on abstract syntax defined in DSL

� takes OCL constraints into account


� generates an instance of the meta model

� templates generate code from meta model instance

XMI Model

ParserMeta Model

FactoryMetamodell-

InstanceCode

Generator

Meta ModelClasses

GeneratedCode

Templates



Tranformation Languages

� language for describing model transformatione

� are capable of importing DSM (normally in XMI)

� declarative approach for describing transformation rules

� imperative languages (e.g. Java)

� not optimal (e.g. no special constructs for processing of collections)

� JMI (Java Metadata Interface) provides access for XMI models

in Java:

List erg = new ArryList();

for (i= 0; i< myList.size(); i++) {

MyObject e = (Myobject)e.get(i);

if (e.getName()!=null && e.getName().startsWith(“get“))

erg.add(e);

}

in Xpand:

myList.select(e|e.name.startsWith(“get“);



Specialized Transformation Languages

� mostly template languages

� code-centric (not for model-to-model transformationen)

� contain code blocks with parameters

Beispiele:

� XSLT

� JavaServer Pages, aber auch Apache/Velocity, Apache/Turbine,

� Eclipse/JET – Java Emitter Templates),…

� OMG/ QVT

� ATL

� openArchtectureWare/ Xpand

Reference:

� J. Herrington: Code Generation in Action, Manning, 2003



QVT (Query / View / Transformation) (1)

� standard of the OMG:

� for platform-independent transformations

� abstract syntax of QVT is defined in MOF

� actually focused on model-to-model transformations

� model-to-code transformation not considered



QVT (2)

� hybrid approach: QVT defines 3 different languages

� declarative component: QVT Relations and QVT Core

� object pattern matching

� defines relations between MOF models

� relation language hat graphische konkrete Syntax

� imperative component QVT Operational Mapping

� while…., if ….

� core meta model

� extending of EMOF and OCL (with imperative elements)

� QVT Black Box

� integration of other transformation languages (e.g. XSLT)

� Implementations:

� actually no complete implementation of QVT exists

� M2M (Eclipse), Borland Together (QVT Operational), ModelMorf (QVT Relation), IBM/MTF

(QVT-Core), INRIA /ATL



openArchitectureWare/ Xpand (1)

� template language for code generation

� stored in files with extension xpt, special oaw-Eclipse-editor

� independent from meta model (same for Xtext, Ecore, UML meta model)

� General Structure

«IMPORT meta::model» imports name space similar to java import

«EXTENSION my::ExtensionFile» for target specifc extensions(e.g. java data types, packages, queries,..)

«DEFINE javaClass FOR Entity» template definition for code generation

«FILE fileName()»

package «javaPackage()»;

public class «name» {

// implementation

}

«ENDFILE»

«ENDDEFINE»




«DEFINE templateName(formalParameterList) FOR MetaClass»

a sequence of statements

«ENDDEFINE»

� DEFINE smallest identifiable unit in template file

� name

� optional parameter list

� name of the meta model class for which the template is defined




«FILE expression »


«ENDFILE»

� redirects the output to a file

� file name is defined by an expression

� name is the name of the instance of metaclass Entity

«IMPORT metamodel»

«DEFINE javaClass FOR Entity»

«FILE name+".java"»public class «name» {

….}

«ENDFILE»«ENDDEFINE»




«EXPAND definitionName

[FOR expression | FOREACH expression] [SEPARATOR expression] ]»

� expands another DEFINE block and inserts its output in the current location

� similar to subroutine call

� definitionName is a DEFINE in the same template or in another template file

«DEFINE main FOR Model»«EXPAND javaClasses FOREACH entities»

«ENDDEFINE»

«DEFINE javaClasses FOR Entity»

…«ENDDEFINE»




«FOREACH expression AS variableName [ITERATOR iterName][SEPARATOR expression]»


«ENDFOREACH»

� expands the body for each element in the collection defined by the expression

� defines a variableName which can be used in the statements

«FOREACH attributes AS attr»public «attr.type» «attr.name»;

«ENDFOREACH»«FOREACH references AS ref»

public «ref.type.name» «ref.name»;

«ENDFOREACH»




«PROTECT CSTART „/*“ CEND „*/“ ID ElementsUniqueID»

here goes some content

«ENDPROTECT»

� generates a protected region

� defining how comments are used in the target language (here: Java)

� code inserted in a protected region is not overwritten by a sub-sequent code

generation

� generates something like this:

public class Person {/*PROTECTED REGION ID(Person) */

.../*PROTECTED REGION END*/

}



Xpand Example (1)«IMPORT metamodel»

«DEFINE javaClass FOR Entity»

«FILE name+".java"»

public class «name» {

«FOREACH attributes AS attr»

public «attr.type» «attr.name»;

«ENDFOREACH»

«FOREACH references AS ref»

public «ref.type.name» «ref.name»;

«ENDFOREACH»

}

«ENDFILE»

«ENDDEFINE»

� template code: copied in the generated code

� references to the (Ecore) meta model

� language elements of Xpandpublic class Car {

public String manufacterer;

public Driver driver;

}



Xpand Example (2)«IMPORT exampledsl»«EXTENSION org::example::dsl::JavaSpecificExtensions»

«DEFINE main FOR Model»«EXPAND javaClasses FOREACH entities»

«ENDDEFINE»

«DEFINE javaClasses FOR Entity»«FILE "my/pack/"+name+".java"»package my.pack;

public class «name» {«FOREACH features AS f»

private «f.javaType()» «f.name»;

public «f.javaType()» get«f.name.toFirstUpper()»() {return this.«f.name»;

}

public void set«f.name.toFirstUpper()»(«f.javaType()» «f.name») {this.«f.name» = «f.name»;

}«ENDFOREACH»}«ENDFILE»«ENDDEFINE»

� template code: copied in the generated code

� references to the (Ecore) meta model

� language elements of Xpand

package my.pack; Generated Codeimport java.util.Set;

public class Address {private Set<Person> peopleWhoLiveHere;private String street;

private String city;

public Set<Person> getPeopleWhoLiveHere() {return this.peopleWhoLiveHere;

}…

entity Address { DSMref Person[] peopleWhoLiveHereattr string streetattr string city

}



Generator-Workflow

� defined in generator.oaw

� looks like ant

� describes workflow of code

generation

� import of the meta model

� similar for all the different

inputs

� imports DSM model

� usage of Xpand generator

(defines entry point:

template::Simple::javaClass )

<workflow><property name="model" value="model.xmi" /><property name="src-gen" value="src-gen" />

<component class="org.openarchitectureware.emf.XmiReader"><metaModelFile value="metamodel/metamodel.ecore" /><modelFile value="${model}" /><outputSlot value="model" /><firstElementOnly value="true" /></component>

<component class="org.openarchitectureware.xpand2.Generator"><metaModelclass="org.openarchitectureware.type.emf.EmfMetaModel"><metaModelFile value="metamodel/metamodel.ecore" /></metaModel><expandvalue="template::Simple::javaClass FOREACH model.entities" /><genPath value="${src-gen}" /><beautifierclass="org.openarchitectureware.xpand2.output.JavaBeautifier" /></component></workflow>



Code Generation based on UML-Model

� a bit more complicated � use example project

� Eclipse project requires a lot of jdom-libraries

� XMI files hast to be copied into the model sub-directory

� create meta classes for each new modeling element

import org.openarchitectureware.meta.uml.classifier.Class;

public class myStereo extends Class { }

� map the DSL modeling element to meta class in metamappings.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE MetaMap SYSTEM

"http://www.openarchitectureware.org/dtds/metamap.dtd">

<MetaMap>

<Mapping>

<Map>myStereo</Map>

<To>meta.myStereo</To>

</Mapping>

</MetaMap>



Target Platforms

� transformation is based on a well-defined target platform

� reference implementation

� vertical prototype and

� architectural concept

� simple target platform requires complex transformation

Frameworks

� framework hotspots are defined with DSL

� code adaptation via hook methods composition

� balance: if too much code has to be generated � extend the framework

Component-based platforms

� technological platforms (EJB, .NET)

� configured by MDSD (generation of the descriptors)



Examples of Target Platforms

� architecture-centric

� workflow engines (e.g. BPEL engine)

� persistence framework (Spring, Hibernate,..)

� GUI framework (QT, Swing, Struts, JSF,…)

� domain-specific

� VAA (Versicherungs-Anwendungs-Architektur) domain model fro insurance companies

� IBM/San Francisco



1. Introduction

2. Meta Modeling




6. Case-Study

7. Best Practices

8. Conclusion



5 Standards – Model Driven Architecture (MDA)

Model Driven Architecture (MDA)

� MDSD initiative of OMG (since 2002)

� based on multiple-stage transformation

MDA standards

� XMI (XML Metadata Interchange)

� model serialization and model exchange

� MOF (Meta Object Facility)

� definition of DSLs

� in UML 2.0: Action Semantics

� QVT (Query/ Views /Transformations)

� model transformation language



MDA Model Types

� CIM: hardware and software-independent description

� defines essential domain concepts

� common vocabulary

� PIM: platform-independent description

� more formaly and more details than CIM (attributes, data types)

� PSM: platform-specific description

� adapted to implementation technology

� Code Model: platform description

� specifies target of the transformation

ComputationIndependent Model

(CIM)

ComputationIndependent Model

(CIM)

PlatformIndependent Model

(PIM)

PlatformIndependent Model

(PIM)

PlatformSpecific Model

(PSM)

PlatformSpecific Model

(PSM)Code ModelCode Model



PIM

PSM (EJB)

Code Model

public interface Konto extends EJBObject{..}

public interface KontoHome extends EJBHome{..}

public abstract class KontoBean implements EntityBean{..}

public KontoPK implements Serializable {..}

Example

<<BusinessEntity>>Account

<<unique id>> numberbalance

<<query>>findByNumber()withdraw(amount): double

<<EJBEntityBean>>Account

<<primary key>> numberbalance

<<EJBFinder>>findByNumber()withdraw(amount: double}

{EJBPersistenceRype=CBP}



Different PSMs base on a certain PIM

PIM

CORBAModel

EJBModel

XMLModel

CORBACode

EJBCode

XMLCode



Models and transformations

Model

Transformation

PlatformInformation

MDA-Pattern

Code

Model

Platform Independent Model (PIM)

Platform Specific Model (PSM)

Model to Text



1. Introduction

2. Meta Modeling




6. Case-Study

7. Best Practices

8. Conclusion



6 Case-Study

Different Case Studies / Experiences

� generating mobile applications � next slides

� generating graphical user interfaces for the JCoffee framework

� generating control instructions for simulation car entertainment equipment

(Bosch/Blaupunkt)

� generating multi-channel applications for financial services


6 Case-Study

BAMOS-Project (Base Architecture for MObile applications in Spontaneous networks)

� project was supported by AGIP (Arbeitsgruppe Innovative Projekte beim Ministerium für

Wissenschaft und Kultur des Landes Niedersachsen) under Research Grant F.A.-Nr. 2004.612.

� J. Dunkel, R. Bruns: Model-Driven Architecture for Mobile Applications,

in: W. Abramowicz (ed.), Proceedings of 10th International Conference on Business Information

Systems, Poznan (Polen), Springer, Lecture Notes LNCS 4439, pp. 464-477, 2007.

� goals:

� simplify development of mobile applications

� code generation approaches instead of manually coding


6 Case-Study

BAMOS platform

Adhoc Client

�entering a local wireless network

� connects spontaneously to the Service Broker

�loads service descriptions from the Service Broker

� generating a user interface on mobile device

�sent service requests to the Service Broker


6 Case-Study

BAMOS platform

Service Broker

�mediator between Service Provider and Adhoc Client

� delegates client request to Service Provider and responses to Client

�service directory stores registered services


6 Case-Study

BAMOS platform

Service Provider

�offers services (e.g. Web Service)

�service descriptions for usage on mobile devices

� mobile user interface

� control flow

�service registered at Service Broker


6 Case-Study

Service Descriptions (1)

� XForms specify the user interfaceon a mobile device:

o XML-based

o close to HTML forms

o close to J2ME/ MIDP

o distinguish data (model) and presentation (view)

� rendered by Adhoc Client


6 Case-Study


� workflow: complete service is a sequence of dialogue steps

1. Service Broker instantiates XForms

2. XForms transferred to mobile device

3. Adhoc Client renders XForms

4. user submits XForm data to Service Broker

5. Service Broker process data (invoke service)and determines XForms for next interaction step

6. XForms is send to mobile device


6 Case-Study


� BAMOS-specific workflow language


6 Case-Study

Problem

� BAMOS simplifies service development� only XForms and XML-workflow

� but error-prone and time consuming

Solution: Model Driven Development


6 Case-Study

Domain Specific Language (DSL)

� defining new domain specific modeling elements

� specified by meta-modeling language (MOF, Ecore ,..)


6 Case-Study

Domain Specific Language (DSL) as EBNF using Xtext

Model : (elements+=Element)*;

Abstract Element : Service | Screen;

Service:

"service" name=ID "{"

"implClass" name=JavaIdentifier ";"

"startScreen" name = ID ";"

"}";

Screen:

"screen" name=ID "{"

"submit" name=ID ";"

"method" name=ID ";"

"dataElements" "{“ (dataElements+=DataElements)* "}"

"controlflow" "{„ (nextScreen+=NextScreen)* "}"

"}" ;

Abstract DataElements : Input | Output | Select;

Input : "input" name=ID ";";

Output : "ouput" name=ID ";";

Select : "select" name=ID "choices" (choices+=Choice)*; ";"

Choice : name = ID ;

NextScreen :"if" name = ID "nextscreen" name = ID ;


6 Case-Study

Domain Specific Model (DSM) based on EBNF

screen serviceOverview {

submit ok;

method getService;

dataElements {

select MyService

choices weatherservice publicTransportService;

}

controlflow {

if MyService/weatherservice

nextscreen weatherservice

if MyService/publicTransportService

nextscreen transport

}

};

screen weatherService {

submit Forecast ;

method getWeather;

dataElements {

input city;

select timeOfDay choices morning afternoon night;

}

controlflow {

if true nextscreen MyService/weather

}

}


6 Case-Study

Domain Specific Language (DSL)� UML activity diagrams for specifying the control flow


6 Case-Study

Domain Specific Modeling (DSM)

� using the DSL for modeling mobile services

� class diagram with DSL stereotypes for XForms screens


6 Case-Study

Domain Specific Modeling (DSM)� UML activity diagrams model control flow


6 Case-Study

Implementation Issues

Specifying DSL

� UML tool Magic Draw

� provides UML metamodel for specifying stereotypes

� precise definition of DSL not possible

Domain Specific Modeling

� using Magic Draw

� exports model in XMI format

Code Generation

� openArchitectureWare

� imports XMI model

� provides Xpand script language for code generation



1. Introduction

2. Meta Modeling




6. Case-Study

7. Best Practices

8. Conclusion



7 Best Practices

Sub domains

� often more than on DSL required

� complex systems contain many different (technical) aspekts

� e.g. business logic, GUI, SQL-DDL,…

� cannot be describes by a single DSL

� for some aspects UML extensions are not well-suited

� WYSIWYG editor for GUIs (other concrete syntax than UML)

Solution:

� defining sub domains with specific DSL

� common gateway meta classes for DSL integration

Technical Sub domain 1(workflow)

Meta model 1 DSL 1

Technical Sub domain 2

(persistence)

Meta model 2 DSL 2

Technical Sub domain 3

(GUI)

Meta model 3 DSL 3


7 Best Practices

Modular Transformations

� allows reusage

Fall 1: different domain

Fall 2: different technology

InsuranceMetamodel

OO-Metamodel

Prozess-Metamodel

J2EE-Metamodell

JBoss-Metamodel

Bea-Metamodel

Java-Metamodel

Banking-Metamodel

OO-Metamodel

Prozess-Metamodel

J2EE-Metamodel

JBoss-Metamodel

Bea-Metamodel

Java-Metamodel

Insurance

Metamodel

OO-Metamodel

Prozess-Metamodel

.NET-Metamodel

C#-Metamodel


7 Best Practices

What can be generated?

� all schematic code: source code

� that‘s not covered by the target platform

� which can be specified by the DSL

� other source code has to implemented manually

� code generation should be done automatically

� bspw. using ant, maven

� ever change/adapt generated code !

� generated as much as possible

� JUnit-Tests, test data, Mock-Objects

� data base, migrations, loading scripts

� standard GUIs for IUD dialogues

� documentation


7 Best Practices

DSL for configuring frameworks

� generation of:

� deployment descriptors (e.g. EJB)

� workflow of web systeme (using finite state machines)

(e.g. Struts configuration files)

� hibernate configuration files

� Corba-IDL (IDL compiler already generates stubs from IDL!)

� separate generated from manual code

� in different files

� otherwise the generator must cope with protected regions (use code versioning systems)

� format generated code

� sub-sequent step by pretty printer /beautifier


7 Best Practices

Separate the technical information used for generation from model

� technical information

� pathes, driver, libraries,

� layout:

� position of GUI controls, colors, logos,…

� integration in (UML-) Modelle tedious

� textual description is better

� or specialized graphical description (not UML!)

Solution:

� put this information into specific configuration files / descriptors

� they are used by the transformator/generator as additional input (to the DSM)



1. Introduction

2. Meta Modeling




6. Case-Study

7. Best Practices

8. Conclusion



8 Conclusion

MDSD advantages

� improved software quality

� no redundancy

� coding standards are guaranteed

� individual “solutions” are avoided

� accelerates development

� makes the usage of frameworks much easier

� higher level of abstraction – better integration of domain experts

� defined architectures

� standardization (MDA) allows interoperability and portability

Disadvantages

� high investments at the beginning

� development of a DSL, modeling tools, generators, education,…

� tools are not very mature

� still little experience ...

Model-Driven Software Development - Semantic Scholar · Vision of Model-Driven Software Development (MDSD) (2) MDSD is a paradigm shift models substitute code models play the central

Documents