model-driven software development - semantic scholar · vision of model-driven software development...
Post on 11-Jul-2020
4 Views
Preview:
TRANSCRIPT
© 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
juergen.dunkel@fh-hannover.de
© Jürgen Dunkel 2007 | Model-Driven Software Development 2
Model-Driven Software Development
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 3
Model-Driven Software Development
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.
© Jürgen Dunkel 2007 | Model-Driven Software Development 4
Model-Driven Software Development
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
3. Domain-Specific-Languages (DSL)
4. Model Transformation and Code Generation
6. Standards: OMG/Model Driven Architecture (MDA)
7. Case-Study
8. Best Practices
9. Conclusion
Lab: MDSD using openArchitectureWare
© Jürgen Dunkel 2007 | Model-Driven Software Development 5
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 6
1.1 State-of-the Art in Software Development
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 7
1.1 State-of-the Art in Software Development
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()
unsetEntityContext()
Interface
EntityBean
ejbActivate()
ejbLoad()
ejbPassivate()
ejbRemove()
ejbStore()
setEntityContext()
unsetEntityContext()
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()
© Jürgen Dunkel 2007 | Model-Driven Software Development 8
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 9
1.2 Vision of Model-Driven Software Development
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, …)
© Jürgen Dunkel 2007 | Model-Driven Software Development 10
1.2 Vision of Model-Driven Software Development
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 11
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 12
1.3 MDSD Prerequisites and Basic Steps
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 13
1.3 MDSD Prerequisites and Basic Steps
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 14
1.3 MDSD Prerequisites and Basic Steps
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 15
1.3 MDSD Prerequisites and Basic Steps
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}
© Jürgen Dunkel 2007 | Model-Driven Software Development 16
1.3 MDSD Prerequisites and Basic Steps
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}
© Jürgen Dunkel 2007 | Model-Driven Software Development 17
Model-Driven Software Development
1. Introduction
2. Meta Modeling
2.1 DSLs as Formal Languages
2.2 Meta Modeling Layers
2.3 Meta Modeling Languages
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 18
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 19
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 20
2.2 Meta Modeling Layers
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 21
2.2 Meta Modeling Layers
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 22
2.2 Meta Modeling Layers
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 23
2.3 Meta Modeling Languages
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 24
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' ;
© Jürgen Dunkel 2007 | Model-Driven Software Development 25
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.
© Jürgen Dunkel 2007 | Model-Driven Software Development 26
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 27
2.3 Meta Modeling Languages – MOF
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 28
aus: http://de.wikipedia.org/wiki/Meta-Object_Facility
2.3 Meta Modeling Languages – MOF
OMG / Meta Object Facility (MOF) Model
� simplified overview
© Jürgen Dunkel 2007 | Model-Driven Software Development 29
2.3 Meta Modeling Languages – MOF
Essential MOF – Classes
aus: OMG: Meta Object Facility (MOF) Specification , Version 2.0
© Jürgen Dunkel 2007 | Model-Driven Software Development 30
2.3 Meta Modeling Languages
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 31
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 32
2.3 Meta Modeling Languages – Ecore
Eclipse Ecore – Meta model (2)
© Jürgen Dunkel 2007 | Model-Driven Software Development 33
2.3 Meta Modeling Languages – Ecore
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 34
Model-Driven Software Development
1. Introduction
2. Meta Modeling
3. Domain-Specific-Languages (DSL)
3.1 Defining new DSLs
3.2 Extending General Purpose Modeling Languages
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 35
3.1 Defining new DSLs
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 36
3.1 Defining new DSLs
Example (1): Meta Model (DSL) for Petri Nets
� here: described in UML/MOF
� defining the abstract syntax
© Jürgen Dunkel 2007 | Model-Driven Software Development 37
3.1 Defining new DSLs
Domain Specific Models (DSM)
� is an instance of the meta model defined by the DSL
� uses a concrete syntax (here a graphical notation)
© Jürgen Dunkel 2007 | Model-Driven Software Development 38
3.1 Defining new DSLs
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 39
3.1 Defining new DSLs
UML Meta Model (1)
� for class diagrams
© Jürgen Dunkel 2007 | Model-Driven Software Development 40
3.1 Defining new DSLs
UML Meta Model (2)
� for use case diagrams
© Jürgen Dunkel 2007 | Model-Driven Software Development 41
3.2 Extending General Purpose Modeling Languages
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 42
3.2 Extending General Purpose Modeling Languages
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 43
3.2 Extending General Purpose Modeling Languages
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 44
3.2 Extending General Purpose Modeling Languages
Example – UML Profiles
� architecture-centric stereotypes: window, controller, entity class, process class
� here: MVC architectural style
© Jürgen Dunkel 2007 | Model-Driven Software Development 45
3.2 Extending General Purpose Modeling Languages
Heavy-weight extensions of UML
M1
M2
M3
© Jürgen Dunkel 2007 | Model-Driven Software Development 46
3.2 Extending General Purpose Modeling Languages
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}
© Jürgen Dunkel 2007 | Model-Driven Software Development 47
3.2 Extending General Purpose Modeling Languages
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 48
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 49
3.3 DSL Modeling Tools
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 50
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 51
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 52
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 53
3.3 DSL Modeling Tools
Ecore model (DSL) as XML file
� not used
© Jürgen Dunkel 2007 | Model-Driven Software Development 54
3.3 DSL Modeling Tools
Instance of Ecore Meta Model
(DSM)
� uses the meta model elements
� instantiates the meta model
� entities Driver and Car
� simple modeling editor
� XML representation
© Jürgen Dunkel 2007 | Model-Driven Software Development 55
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 56
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 57
3.3 DSL Modeling Tools
Create Xtext project
• newProject-> other-> xtext-Project
• generates 3 additional projects
• in xtend.example the DSL
has to be specified
© Jürgen Dunkel 2007 | Model-Driven Software Development 58
3.3 DSL Modeling Tools
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;
© Jürgen Dunkel 2007 | Model-Driven Software Development 59
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 60
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 61
3.3 DSL Modeling Tools
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"};
© Jürgen Dunkel 2007 | Model-Driven Software Development 62
3.3 DSL Modeling Tools
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 63
3.3 DSL Modeling Tools
Overview of DSL modeling approaches (2)
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 64
3.3 DSL Modeling Tools
Overview of DSL modeling approaches (3)
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?
© Jürgen Dunkel 2007 | Model-Driven Software Development 65
Model-Driven Software Development
1. Introduction
2. Meta Modeling
3. Domain Specific Languages (DSL)
4. Model Transformation and Code Generation
4.1 General Characteristics of Model Transformations
4.2 Transformation Languages
4.3 Code Generation and Target Platforms
5. Standards: OMG/Model Driven Architecture (MDA)
6. Case-Study
7. Best Practices
8. Conclusion
Lab: MDSD using openArchitectureWare
© Jürgen Dunkel 2007 | Model-Driven Software Development 66
4.1 General Characteristics of Model Transformations
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 67
4.1 General Characteristics of Model Transformations
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 68
4.1 General Characteristics of Model Transformations
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 69
4.1 General Characteristics of Model Transformations
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, …
© Jürgen Dunkel 2007 | Model-Driven Software Development 70
4.1 General Characteristics of Model Transformations
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 71
4.1 General Characteristics of Model Transformations
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 72
4.1 General Characteristics of Model Transformations
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 73
4.1 General Characteristics of Model Transformations
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 74
4.1 General Characteristics of Model Transformations
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
3. Model Transformation and Code Generation
� 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
© Jürgen Dunkel 2007 | Model-Driven Software Development 75
4.2 Transformation Languages
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“);
© Jürgen Dunkel 2007 | Model-Driven Software Development 76
4.2 Transformation Languages
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 77
4.2 Transformation Languages
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 78
4.2 Transformation Languages
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 79
4.2 Transformation Languages
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»
© Jürgen Dunkel 2007 | Model-Driven Software Development 80
4.2 Transformation Languages
openArchitectureWare/ Xpand (2)
«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
© Jürgen Dunkel 2007 | Model-Driven Software Development 81
4.2 Transformation Languages
openArchitectureWare/ Xpand (3)
«FILE expression »
a sequence of statements
«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»
© Jürgen Dunkel 2007 | Model-Driven Software Development 82
4.2 Transformation Languages
openArchitectureWare/ Xpand (4)
«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»
© Jürgen Dunkel 2007 | Model-Driven Software Development 83
4.2 Transformation Languages
openArchitectureWare/ Xpand (5)
«FOREACH expression AS variableName [ITERATOR iterName][SEPARATOR expression]»
a sequence of statements
«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»
© Jürgen Dunkel 2007 | Model-Driven Software Development 84
4.2 Transformation Languages
openArchitectureWare/ Xpand (6)
«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*/
}
© Jürgen Dunkel 2007 | Model-Driven Software Development 85
4.2 Transformation Languages
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;
}
© Jürgen Dunkel 2007 | Model-Driven Software Development 86
4.2 Transformation Languages
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
}
© Jürgen Dunkel 2007 | Model-Driven Software Development 87
4.2 Transformation Languages
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>
© Jürgen Dunkel 2007 | Model-Driven Software Development 88
4.2 Transformation Languages
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>
© Jürgen Dunkel 2007 | Model-Driven Software Development 89
4.3 Code Generation and Target Platforms
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 90
4.3 Code Generation and Target Platforms
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 91
Model-Driven Software Development
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 92
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 93
5 Standards – Model Driven Architecture (MDA)
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 94
5 Standards – Model Driven Architecture (MDA)
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}
© Jürgen Dunkel 2007 | Model-Driven Software Development 95
5 Standards – Model Driven Architecture (MDA)
Different PSMs base on a certain PIM
PIM
CORBAModel
EJBModel
XMLModel
CORBACode
EJBCode
XMLCode
© Jürgen Dunkel 2007 | Model-Driven Software Development 96
5 Standards – Model Driven Architecture (MDA)
Models and transformations
Model
Transformation
PlatformInformation
MDA-Pattern
Code
Model
Platform Independent Model (PIM)
Platform Specific Model (PSM)
Model to Text
© Jürgen Dunkel 2007 | Model-Driven Software Development 97
Model-Driven Software Development
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 98
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 99
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 100
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 101
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 102
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 103
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 104
6 Case-Study
Service Descriptions (2)
� 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
© Jürgen Dunkel 2007 | Model-Driven Software Development 105
6 Case-Study
Service Descriptions (3)
� BAMOS-specific workflow language
© Jürgen Dunkel 2007 | Model-Driven Software Development 106
6 Case-Study
Problem
� BAMOS simplifies service development� only XForms and XML-workflow
� but error-prone and time consuming
Solution: Model Driven Development
© Jürgen Dunkel 2007 | Model-Driven Software Development 107
6 Case-Study
Domain Specific Language (DSL)
� defining new domain specific modeling elements
� specified by meta-modeling language (MOF, Ecore ,..)
© Jürgen Dunkel 2007 | Model-Driven Software Development 108
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 ;
© Jürgen Dunkel 2007 | Model-Driven Software Development 109
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
}
}
© Jürgen Dunkel 2007 | Model-Driven Software Development 110
6 Case-Study
Domain Specific Language (DSL)� UML activity diagrams for specifying the control flow
© Jürgen Dunkel 2007 | Model-Driven Software Development 111
6 Case-Study
Domain Specific Modeling (DSM)
� using the DSL for modeling mobile services
� class diagram with DSL stereotypes for XForms screens
© Jürgen Dunkel 2007 | Model-Driven Software Development 112
6 Case-Study
Domain Specific Modeling (DSM)� UML activity diagrams model control flow
© Jürgen Dunkel 2007 | Model-Driven Software Development 113
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 114
Model-Driven Software Development
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 115
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 116
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 117
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 118
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 119
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)
© Jürgen Dunkel 2007 | Model-Driven Software Development 120
Model-Driven Software Development
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
© Jürgen Dunkel 2007 | Model-Driven Software Development 121
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 ...
top related