OORPTObject-Oriented Reengineering Patterns and Techniques
13. Model-Driven Development
Prof. O. Nierstrasz
OORPT — Architecture Recovery
10.2
Roadmap
> Introduction to Model Engineering— Models and metamodels— MDA— Models as graphs
> Query/Views/Transformations— QVT languages: Relations, Core, Operational Mappings— Case study: flattening UML hierarchies
OORPT — Architecture Recovery
10.3
Sources
> Introduction to Model Engineering — Jean Bézivin
> Query/Views/Transformations— ATLAS group, INRIA & University of Nantes
> Model Driven Development— Colin Atkinson, Universität Mannheim
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ecesis-home/downloads/index.htmlhttp://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ecesis-home/downloads/index.html
OORPT — Architecture Recovery
10.4
Roadmap
> Introduction to Model Engineering— Models and metamodels— MDA— Models as graphs
> Query/Views/Transformations
OORPT — Architecture Recovery
10.5
The Vision of MDA
softwaredeveloper
PlatformIndependentModel
automatictranslation
OORPT — Architecture Recovery
10.7
Roadmap
> Introduction to Model Engineering— Models and metamodels— MDA— Models as graphs
> Query/Views/Transformations
OORPT — Architecture Recovery
10.9
http://poweredge.stanford.edu/BioinformaticsArchive/PrimarySite/NIHpanelModeling/RothenbergNatureModeling.pdfhttp://poweredge.stanford.edu/BioinformaticsArchive/PrimarySite/NIHpanelModeling/RothenbergNatureModeling.pdf
What is a model?
> Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality.
– “The Nature of Modeling.” Jeff Rothenberg. In Artificial Intelligence, Simulation, and Modeling, John Wiley and Sons, Inc., 1989, pp. 75-92
OORPT — Architecture Recovery
10.10
A model is a partial view of a system
Respiratory model OtherModels
muscular,nervous,
circulatory,digestive,
endocrinous,etc.Skeleton model
A system Several modelsof this system (partial views)
repOf
OORPT — Architecture Recovery
10.11
Carpenter'sview
Mason'sview
Plumber'sview
Architect'sview
Landlord'sview
Renter'sview
InteriorDesigner's
view
TaxCollector's
view
Electrician'sview
Each view is expressed in a given domain language (DSL).Vocabularies of different corporations are different;
However they allow talking about a common building.
ModelrepOfSystem
Multiples views and coordinated DSLs
OORPT — Architecture Recovery
10.14
Percentage of places infestedby termites in France.
First round of politicalelection in France in 2002.
A model has no meaning when separated from its metamodel
OORPT — Architecture Recovery
10.16
This is DSLX
DDMM
Modela
Modelb
Modelc
Modeld
This is DSLY
This is DSLZ
Definition: A DSL is a coordinated set of models
DDMM = Domain Definition MetaModel
Metamodels define Domain Specific Languages (DSLs)
OORPT — Architecture Recovery
10.17
What is a model?
A model is a representation of a system
— A model is written in the language of its unique metamodel— A metamodel is written in the language of its unique
metametamodel– The unique MMM of the MDA is the MOF
— A model is a constrained directed labeled graph — A model may have a visual graphical representation
(sometimes)
OORPT — Architecture Recovery
10.18
Roadmap
> Introduction to Model Engineering— Models and metamodels— MDA— Models as graphs
> Query/Views/Transformations
OORPT — Architecture Recovery
10.19
Production of a system from a model
S M
Production of a systemfrom a model. For example construction a buildingfrom its floor plans.
MrepOf
S {postcondition}
OORPT — Architecture Recovery
10.20
Université de NANTES
M1, M2 & M3 spaces
M3
M2
M1
M2
M1
M2
M1 M1M1
M1
M2
M3
MDA in a nutshell
- One unique Metametamodel (the MOF) - An important library of compatible Metamodels,
each defining a DSL - Each of the models is defined in the language of
its unique metamodel
OORPT — Architecture Recovery
10.21
The OMG/MDA Stack
the UML MetaModel
Class Attribute*
1
a UML Model
Client
Name : String
M2
M1
the MOF
Class Association
source
destination
M3
c2
c2
c2
metamodel
model
"the real world"
meta-metamodel
The MOF
The UML metamodel ++
Some UML Models ++
Various usagesof these models
M0
M1
M2
M3
OORPT — Architecture Recovery
10.22
CORBA
Java/EJB
C#/DotNet
Web/XML/SOAP
PIM
etc.
Platform-IndependentModel
Multi-targetcode generation
+ SVG, GML, Delphi, ASP, MySQL, PHP, etc.
data grid computingpervasive computingcluster computing
SMIL/Flash
Write Once, Run AnywhereModel Once, Generate Anywhere
OORPT — Architecture Recovery
10.23
Forward and reverse engineering
PSM PSM
Platformsof yesterday
Platformsof tomorrow
Platformsof today
Legacy,Cobol, ADA, etc.
Java, EJB, J2EE, etc.
????Grid, Cluster,
P2P architectures
PIM
OORPT — Architecture Recovery
10.24
Roadmap
> Introduction to Model Engineering— Models and metamodels— MDA— Models as graphs
> Query/Views/Transformations
OORPT — Architecture Recovery
10.25
Structural definition of a model
> Definition 1. A directed multigraph G = (NG, EG, G) consists of a finite set of distinct nodes NG, a finite set of edges EG and a mapping function G: : EG NG x NG
> Definition 2. A model M = (G, , ) is a triple where:— G = (NG, EG, G) is a directed multigraph
— is itself a model, called the reference model of M,associated to a graph G = (N, E, )
— : NG EG N is a function associating elements (nodes and edges) of G to nodes of G (metaElements)
OORPT — Architecture Recovery
10.28
Definitions
> Definition 3. A metametamodel is a model that is its own reference model (i.e. it conforms to itself).
> Definition 4. A metamodel is a model such that its reference model is a metametamodel.
> Definition 5. A terminal model is a model such that its reference model is a metamodel.
OORPT — Architecture Recovery
10.30
Roadmap
> Introduction to Model Engineering> Query/Views/Transformations
— QVT languages: Relations, Core, Operational Mappings— Case study: flattening UML hierarchies
OORPT — Architecture Recovery
10.31
Overview
> QVT stands for Query/Views/Transformations> OMG standard language for expressing queries, views,
and transformations on MOF models— OMG QVT Request for Proposals (QVT RFP, ad/02-04-10)
issued in 2002— Seven initial submissions that converged to a common proposal— Current status (June, 2006): final adopted specification, OMG
document ptc/05-11-01
OORPT — Architecture Recovery
10.32
Roadmap
> Introduction to Model Engineering> Query/Views/Transformations
— QVT languages: Relations, Core, Operational Mappings— Case study: flattening UML hierarchies
OORPT — Architecture Recovery
10.33
QVT Operational Context
> Abstract syntax of the language is defined as MOF 2.0 metamodel> Transformations (Tab) are defined on the base of MOF 2.0 metamodels
(MMa, MMb)> Transformations are executed on instances of MOF 2.0 metamodels (Ma)
QVT MMb
Mb
conf ormsTo
conf ormsTo
based on
conf ormsTo
conf ormsTo
MOF
MMa
Ma
conf ormsTo
conf ormsTo
conf ormsTo
M1
M2
M3
Engine
Tab
based on
input outputexecuted
OORPT — Architecture Recovery
10.34
Relations
OperationalMappings
Core
extends
RelationsToCoreTransf ormation
BlackBox
extends
extends
extends
QVT Architecture
> Layered architecture with three transformation languages:— Relations— Core— Operational Mappings
> Black Box is a mechanism for calling external programs during transformation execution
OORPT — Architecture Recovery
10.35
QVT Languages
> Relations— Declarative transformation language— Specification of relations over model elements
> Core— Declarative transformation language— Simplification of Relations language
> Operational Mappings— Imperative transformation language— Extends Relations language with imperative constructs
QVT is a set of three languages that collectively provide a hybrid “language”.
OORPT — Architecture Recovery
10.36
Roadmap
> Introduction to Model Engineering> Query/Views/Transformations
— QVT languages: Relations, Core, Operational Mappings— Case study: flattening UML hierarchies
OORPT — Architecture Recovery
10.37
Case Study
> Flattening UML class hierarchies:— given a source UML model transform it to another UML model
in which only the leaf classes (classes not extended by other classes) in inheritance hierarchies are kept.
> Rules:— Transform only the leaf classes in the source model— Include the inherited attributes and associations— Attributes with the same name override the inherited attributes— Copy the primitive types
OORPT — Architecture Recovery
10.41
transformation SimpleUML2FlattenSimpleUML(in source : SimpleUML out target : SimpleUML);
…………………………………………………………………
main() {}
……………………………………………………………………helpers………………………………………………mapping operations………………
transformation SimpleUML2FlattenSimpleUML(in source : SimpleUML out target : SimpleUML);
…………………………………………………………………
main() {}
……………………………………………………………………helpers………………………………………………mapping operations………………
Overall structure of a transformation program:
Signature:Declares the transformation name and the source and target metamodels. in and out keywords indicate source and target model variables.
Signature:Declares the transformation name and the source and target metamodels. in and out keywords indicate source and target model variables.
Entry point:The execution of the transformation starts here by executing the operations in the body of main
Entry point:The execution of the transformation starts here by executing the operations in the body of main
Transformation elements:Transformation consists of mapping operations and helpers. They form the transformation logic.
Transformation elements:Transformation consists of mapping operations and helpers. They form the transformation logic.
Model Transformation expressed inOperational Mappings Language
OORPT — Architecture Recovery
10.42
Mapping Operations
> A mapping operation maps one or more source elements into one or more target elements— Always unidirectional— Selects source elements on the base of a type and a Boolean
condition (guard)— Executes operations in its body to create target elements— May invoke other mapping operations and may be invoked— Mapping operations may be related by inheritance
OORPT — Architecture Recovery
10.43
mapping Class::leafClass2Class(in model : Model) : Classwhen {not model.allInstances(Generalization)->exists(g |
g.general = self)}{ name:= self.name; abstract:= self.abstract; attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet();}
mapping Class::leafClass2Class(in model : Model) : Classwhen {not model.allInstances(Generalization)->exists(g |
g.general = self)}{ name:= self.name; abstract:= self.abstract; attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet();}
Operation bodyOperation body
Signature and guardSignature and guard
Mapping Operations: Example (1)
> Consider the rule that transforms only leaf classes— Selects only classes without subclasses— Collects all the inherited properties— Creates new class in the target model
OORPT — Architecture Recovery
10.44
mapping Class::leafClass2Class(in model : Model) : Classwhen {not model.allInstances(Generalization)->exists(g |
g.general = self)}
mapping Class::leafClass2Class(in model : Model) : Classwhen {not model.allInstances(Generalization)->exists(g |
g.general = self)}
Operation nameOperation nameSource elementtypeSource elementtype
An optional sequence of input/output parametersAn optional sequence of input/output parameters
Target element typeTarget element type
GuardGuard
The Guard is an OCL expression used to filter source elements of a given type. The mapping operation is executed only on elements for which the guard expression is evaluated to true.
Mapping Operations: Example (2)
Operation Signature and Guard
OORPT — Architecture Recovery
10.45
name:= self.name;abstract:= self.abstract;attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet();
name:= self.name;abstract:= self.abstract;attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet();
Operation BodyThe predefined variable self refers to the source element on which the operation is executed
The predefined variable self refers to the source element on which the operation is executed
The left-hand side of the assignments denotes properties of the target element
The left-hand side of the assignments denotes properties of the target element
Invocation of helper derivedAttributesInvocation of helper derivedAttributes
The keyword map is used to invoke another mapping operation named property2property over the elements returned by the helper derivedAttributes
The keyword map is used to invoke another mapping operation named property2property over the elements returned by the helper derivedAttributes
The mapping operation body contains initialization expressions for the properties of the target element. When an operation is executed over a source element the self variable is bound to it and an instance of the target type is created. Then the operation body is executed.
Mapping Operations: Example (3)
OORPT — Architecture Recovery
10.46
Conclusions (1)
> QVT: Query/Views/Transformations – the OMG standard language for model transformations in MDA/MDE
> The issue of Views over models is not addressed> Query language based on OCL> A family of three transformation languages:
— Relations: declarative language— Core: declarative language, simplification of Relations— Operational Mappings: imperative transformation language that
extends relations
> Collectively QVT languages form a hybrid language
OORPT — Architecture Recovery
10.47
Conclusions (2)
> Tool support is still insufficient (at the time of preparing of this lecture – June 2006)
> QVT is not proved yet in non-trivial industrial like scenarios
> Many issues need further exploration:— Performance— Testing— Scalability of transformations— Ease of use— Handling change propagation— Incremental transformations— Adequacy of the reuse mechanisms
OORPT — Architecture Recovery
10.48
License
> The present courseware has been elaborated in the context of the MODELWARE European IST FP6 project (http://www.modelware-ist.org/).
> Co-funded by the European Commission, the MODELWARE project involves 19 partners from 8 European countries. MODELWARE aims to improve software productivity by capitalizing on techniques known as Model-Driven Development (MDD).
> To achieve the goal of large-scale adoption of these MDD techniques, MODELWARE promotes the idea of a collaborative development of courseware dedicated to this domain.
> The MDD courseware provided here with the status of open source software is produced under the EPL 1.0 license.
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ecesis-home/downloads/index.htmlhttp://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ecesis-home/downloads/index.html