oorpt object-oriented reengineering patterns and techniques

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


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


10.4

Roadmap


> Query/Views/Transformations


10.5

The Vision of MDA

softwaredeveloper

PlatformIndependentModel

automatictranslation


10.7

Roadmap




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


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


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


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


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)


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)


10.18

Roadmap




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}


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


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


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


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


10.24

Roadmap




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)


10.26

Each model conforms to its reference model


10.27

There are several kinds of models


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.


10.30

Roadmap

> Introduction to Model Engineering> Query/Views/Transformations

— QVT languages: Relations, Core, Operational Mappings— Case study: flattening UML hierarchies


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


10.32

Roadmap




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


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


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


10.36

Roadmap




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


10.38

Source and Target Metamodel: SimpleUML


10.39

Example Input Model


10.40

Example Output Model


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


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


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


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


10.44


g.general = self)}


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.


Operation Signature and Guard


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.



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


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


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

oorpt object-oriented reengineering patterns and techniques

Documents

model engineeringmodels

incorrect model

model technology models

modeldriven developmentprof

abstraction of reality

irreversibility of reality

aspects of reality

given purpose