ITU - MDD – Model-to-Model Transformations

L0082 - 2010-11-18
Redistribution and other use of this material requires written permission from The RCP Company.
ITU - MDD – Model-to-Model Transformations
This presentation describes the use Model-to-Model transformations (M2M). It
focus on the why, what and how.
This presentation is developed for MDD 2010 course at ITU, Denmark.
Some materials by Artur Boronat, University of Leicester (UK) and Emilio Insfrán,
TU Valencia (Spain) with permissions.

L0082 - 2010-11-18
2
What is Model-to-Model Transformations
 Two kinds of model transformation:
 Model-to-Text transformation (M2T)
 Model-to-Model transformation (M2M)
 A Model-to-Model transformation is the automated creation of m target models from n
source models
 Each model conforms to a given reference model (which can be the same for
several models)
M2MM2M
M2T
M2T

L0082 - 2010-11-18
3
Why use Model-to-Model Transformations
 Translation
 Refactoring
 Refinement
 Code Generation
 Specialization
 Migration
 Normalization

L0082 - 2010-11-18
4
Model-to-Model Transformations Principles

L0082 - 2010-11-18
5
M2
M1
relational schema (model)
class diagram metamodel specification (CD) relational metamodel specification (RDBS)
conforms to
conforms to
context ForeignKey
inv: self.owningTable.columns -> includesAll( self.columns)
context AssociationEnd
inv: not(self.opposite.oclIsUndefined) implies
(self.type=self.opposite.owningClass and
self.owningClass=self.opposite.type)
inv: (lower = 0 or lower = 1) and (upper = 1 or upper = -1)
class diagram model (cd)
Example of Model Transformation
M2
M1

L0082 - 2010-11-18
6
Example of Model Transformation

L0082 - 2010-11-18
7
Approaches for Model Transformations
 Model-to-model
 Model transformations are based on rules. These rules map constructs in the source model to
constructs in the target model
Meta-model A Meta-model B
Model A Model B
Transformation
Apply Transformation
conformsToconformsTo based onbased on
input output

L0082 - 2010-11-18
8
Some Terms
Endogeneous
Exogeneous
Horizontal
vertical
M2
M1

L0082 - 2010-11-18
9
- 9 -
Combining both approaches in an MDE process
Application on a concrete use case:
UML2 to Java
 An M2T solution
 A single transformation
performing at the same time:

Refactoring (e.g. delete of
multiple inheritance)

Mapping (UML2 concepts to
Java concepts)

Extraction to a concrete syntax
(conforming to the Java
grammar)

L0082 - 2010-11-18
10
- 10 -
Application on a concrete use case: UML2 to Java
 Same case using an M2M+M2T solution

L0082 - 2010-11-18
11
- 11 -
 Same case using an M2M+M2T solution + new refactoring

L0082 - 2010-11-18
12
- 12 -
Application on a concrete use case: UML2 to Java and C#
 Same case using an M2M+M2T solution + new mapping

L0082 - 2010-11-18
13
- 13 -
 Same case using an M2M+M2T solution + new extraction

L0082 - 2010-11-18
14
- 14 -
Advantages of such a generic M2M+M2T solution
 Modularity

Clearly separate the concerns (refactoring, mapping, extraction to a given
syntax, etc)
 Extensibility

Easily add new features (additional refactoring, different mapping, other
extraction to a textual or graphical syntax, etc)
 Reusability

Apply the same feature in different contexts (i.e., the same refactoring for
targeting different languages)
 Homogeneity

Handle mostly models (extraction is just the final step)
 Abstraction

Focus is set only on the concepts (abstract syntax) and not on their
various possible representations (concrete syntaxes)

L0082 - 2010-11-18
15
Important Success Factors for Model-to-Model Technologies
 Ease of use
 It is likely not going to be the primary tool of any developer
 Requirements on source and target models
 Form and format (text, XML, graph, …)
 Traceability
 Can you trace changes in the input to changes in the final results
 Very important for certain industries
 Reasoning about the transformation themselves
 Termination, Completeness, etc

L0082 - 2010-11-18
16
Several Types of Transformation Technologies
 Text based model
 Using sed, awk, perl, Snobol…
 Data often represented as a text files
 Tree based model
 Using XSLT
 Difficulties with models that’s are not pure trees
 Data often represented as simple XML files
 Graph based model
 Using QVT, ATL, XTend, …
 Data often represented as XMI files

L0082 - 2010-11-18
17
General Purpose Languages
 Java, VB, C# (take your favourite poison)
 Rules are implemented from scratch
 Depending on the form of the model you can have APIs to access the data
 Example: JMI or EMF (MOF-compliant Java Interfaces)
 No overhead to learn a new language
 The programming complexity problem continues

L0082 - 2010-11-18
18
Text Manipulation Tools
 Unix “pipe-line” tools
 sed, awk, perl, ….
 Special purpose programming languages
 Snobol
 Rules are typically based on regular expressions

L0082 - 2010-11-18
19
Extensible Stylesheet Language Transformation (XSLT)
 XML-based language used for the transformation of XML documents
 Part of a W3C family of languages (XSL)
 Describes how to format and transform XML files
 XSLT, XSL-FO, XPath
 Used to model transformation
 Where models are in XMI encoding format

L0082 - 2010-11-18
20
 Metamodels are provided as XML schemas (XSD or DTD)
 Models are represented as XML documents
 XSLT Characteristics
 Declarative rather than imperative
 Consist of a template rules collection
 Each rule specifies what to add to a target fragment

Based on a source fragment and a fixed algorithm
 XSLT processor scan the source tree, apply rules and generate the target tree
 Syntactical & inefficient for model transformations

XML (XMI) is verbose

Operates on tree structures

More batch than interactive

Parameters passed by value

L0082 - 2010-11-18
21
XML
Document 1
XMLS
Document 1
Valid
XSLT
Document
XSLT
Engine
Source
Schema
Fragment
Matching
Patterns
XML
Document 2
XMLS
Document 2
Valid
Target
Schema
Fragment
Insertion Actions
Matched
Source Fragments
 Transformation process:
 Source document matching patterns
 XSLT document specifying actions that copy matched elements and attributes
from source document and assemble them
 Target document matching transformations

L0082 - 2010-11-18
22
<model xmlns:uml="http://www.eclipse.org/uml2/1.0.0/UML" xmlns:xmi="http://www.omg.org/XMI">
<package id="pck1" name=“library">
<class id="c1" name="Book">
<association aggregationType="composite" id="c1_ass1" name="chapters" targetClass="c2"/>
<attribute id="c1_atr1" name="title" type="dt1"/>
</class>
<class id="c2" name="Chapter">
<attribute id="c2_atr1" name="nbPages" type="dt2"/>
<attribute id="c2_atr3" name="author" type="dt1"/>
<association aggregationType="none" id="c2_ass1" name="book"
targetClass="c1"/>
</class>
</package>
</model>

L0082 - 2010-11-18
23
<model xmlns:uml="http://www.eclipse.org/uml2/1.0.0/UML" xmlns:xmi="http://www.omg.org/XMI">
<package id="pck1" name=“library">
<class id="c1" name="Publication">
<attribute id="c1_atr2" name="nbPages" type="dt2"/>
<attribute id="c1_atr3" name="authors" type="dt1"/>
</class>
<datatype id="dt1" name="String"/>
<datatype id="dt2" name="Integer"/>
</package>
</model>

L0082 - 2010-11-18
24
<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<xsl:output method="xml" />
<xsl:template match="library.Book" >
<xsl:variable name="title" select="@title" />
<xsl:variable name="authors" select="concat(@chapters.author, ',')"/>
<xsl:variable name="nbPages" select="sum(@chapters.nbPages)"/>
<xsl:call-template name="createPublication">
<xsl:with-param name="title" select="$title"/>
<xsl:with-param name="authors" select="$authors"/>
< xsl:with-param name="nbPages" select="$nbPages"/>
</xsl:call-template>
</xsl:template>
</xsl:transform>

L0082 - 2010-11-18
25
Graph Transformations

L0082 - 2010-11-18
26
Graph Transformations
 Basic Operation:
 Match a set of nodes in the source graph
 Transform matched data
 Output nodes to the target graph
 Some basic problems
 Graphs are not directed acyclic graphs (DAGs) so there can be multiple
references to the same nodes
 How to you prevent the rules from matching the same data multiple times
 How to handle inheritance for nodes – especially the nodes in the target
model

L0082 - 2010-11-18
27
Book Chapter
nbPages : Integer
author : String
chapters
*
ElementWithTitle
title : String
RHSt : ElementWithTitle
LHS
The pattern matches all nodes of type ElementWithTitle,
considering the inheritance hierarchy
Type graph
Production rule
Inheritance

L0082 - 2010-11-18
28
Tree versus Graphs Transformations
 XSLT
 Operates on tree structures
 Data conversion
 XPath to traverse documents
 XML based commands: transformation
definitions tend to be quite verbose,
low level of detail
 Available in many platforms (libraries)
 Graph transformations
 Operates on graphs
 Models without containments
 Graph patterns
 Graphical approach: large patterns can
be difficult to draw
 Higher conceptual level: inheritance,
dangling edges, pattern matching
 Formal approach: reasoning about
termination and confluence, model
checking

L0082 - 2010-11-18
29
QVT
 QVT stands for Query/Views/Transformations
 OMG standard language for expressing queries, views, and transformations on
MOF models
 Three language: Core, Relational and Operational
 QVT is standards based language
 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
 Automatic handling of traceability links

L0082 - 2010-11-18
30
Requirements for QVT Language
Some requirements formulated in the QVT RFP
Mandatory requirements
Query language Proposals shall define a language for querying models
Transformation language Proposals shall define a language for transformation definitions
Abstract syntax The abstract syntax of the QVT languages shall be described as MOF 2.0 metamodel
Paradigm The transformation definition language shall be declarative
Input and output All the mechanisms defined by proposals shall operate on models instances of MOF 2.0 metamodels
Optional requirements
Directionality Proposals may support transformation definitions that can be executed in two directions
Traceability Proposals may support traceability between source and target model elements
Reusability Proposals may support mechanisms for reuse of transformation definitions
Model update Proposals may support execution of transformations that update an existing model

L0082 - 2010-11-18
31
QVT – Relations and Core Languages
 Relations Language
 A declarative specification of the relationships between MOF models
 Supports complex object pattern matching, and implicitly creates trace
classes and their instances to record what occurred during a transformation
execution.
 Core Language
 A small model/language which only supports pattern matching over a flat set
of variables by evaluating conditions over those variables against a set of
models
 It is equally powerful to the Relations language, and because of its relative
simplicity, its semantics can be defined more simply, although transformation
descriptions are more verbose

L0082 - 2010-11-18
32
QVT Relations – When and Where Clauses
 when clause: conditions under which the
relationship needs to hold. The relation
ClassToTable needs to hold only when the
PackageToSchema relation holds between
the package containing the class and the
schema containing the table.
 where clause: condition that must be
satisfied by all model elements
participating in the relation, and it may
constrain any of the variables in the
relation and its domains.
 when and where clauses may contain also
any arbitrary OCL expressions
relation ClassToTable
/* map each persistent class to a table */
{
domain uml c:Class {
namespace = p:Package {},
kind='Persistent',
name=cn
}
domain rdbms t:Table {
schema = s:Schema {},
name=cn,
column = cl:Column {
name=cn+'_tid',
type='NUMBER'},
primaryKey = k:PrimaryKey {
name=cn+'_pk',
column=cl}
}
when {
PackageToSchema(p, s);
}
where {
AttributeToColumn(c, t);
}
}

L0082 - 2010-11-18
33
Operational QVT
 Operational == Procedural
 Uses OCL as procedural language
 Needed when there are big differences between the input and output models
 Very difficult to map multiple source nodes to multiple target nodes in
Declarative languages
 Likewise difficult to handle shared nodes

L0082 - 2010-11-18
34
Operational QVT Example
 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

L0082 - 2010-11-18
35
Operational QVT Example: Input Model

L0082 - 2010-11-18
36
Operational QVT Example: Expected Output Model

L0082 - 2010-11-18
37
Operational QVT Example: Expected Output Model
transformation SimpleUML2FlattenSimpleUML(in source : SimpleUML, out target : SimpleUML);
main() { source.objectsOfType(Class)->map leafClass2Class(source); }
mapping Class::leafClass2Class(in model : Model) : Class
when {not model.allInstances(Generalization)->exists(g | g.general = self)} {
name:= self.name;
abstract:= self.abstract;
attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet();
}
mapping Property::property2property(in ownerClass : Class) : Property {
name:= self.name;
type:= self.type;
owner:= ownerClass;
}
query Class::derivedAttributes() : OrderedSet(Property){
if self.generalizations->isEmpty() then self.attributes
else
self.attributes->union(
self.generalizations->collect(g |
g.general.derivedAttributes()->select(attr |
not self.attributes->exists(att | att.name = attr.name)
)
)->flatten()
)->asOrderedSet()
endif
}

L0082 - 2010-11-18
38
ATL – Atlas Transformation Language
 ATL is the ATLAS INRIA & LINA research group answer to the OMG MOF/QVT
 mix of declarative and imperative constructs
 expression language based on OCL 2.0
 supports queries, views and transformations
 described by a MOF metamodel and a textual concrete syntax
 ATL transformations:
 are defined via the
corresponding
MOF based metamodels
 are not bidirectional
 ATL has become a reference
language for model
transformations and it is now
part of the Eclipse Modeling Project
MetamodelA MetamodelB
ModelA ModelB
MOF
ATL
defines
M1
M0
M2 ATL Transformation
Model Transformation
conforms to
conforms to

L0082 - 2010-11-18
39
ATL Example
 Assume we want to translate data from a hierarchical model (Family) to a flat
model (Person)

L0082 - 2010-11-18
40
ATL Example

L0082 - 2010-11-18
41
ATL Example
module Families2Persons;
-- @path Families=/Families2Persons/Families.ecore
-- @path Persons=/Families2Persons/Persons.ecore
create OUT: Persons from IN: Families;
rule Member2Male {
from
s: Families!Member (not s.isFemale())
to
t: Persons!Male (
fullName <- s.firstName + ' ' + s.familyName
)
}
rule Member2Female {
from
s: Families!Member (s.isFemale())
to
t: Persons!Female (
fullName <- s.firstName + ' ' + s.familyName
)
}

L0082 - 2010-11-18
42
ATL Example
helper context Families!Member def: isFemale(): Boolean =
if not self.familyMother.oclIsUndefined() then
true
else
if not self.familyDaughter.oclIsUndefined() then
true
else
false
endif
endif;
helper context Families!Member def: familyName: String =
if not self.familyFather.oclIsUndefined() then
self.familyFather.lastName
else
if not self.familyMother.oclIsUndefined() then
self.familyMother.lastName
else
if not self.familySon.oclIsUndefined() then
self.familySon.lastName
else
self.familyDaughter.lastName
endif
endif
endif;

L0082 - 2010-11-18
43
More Information
 “QVT Repository”
 http://www.toodoc.com/qvt-pdf.html

Repository with many QVT documents
 “MOF QVT Final Adopted Specification”
 http://www.omg.org/docs/ptc/05-11-01.pdf

You usual very hard to read OMG model

ITU - MDD – Model-to-Model Transformations

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Similaire à ITU - MDD – Model-to-Model Transformations

Similaire à ITU - MDD – Model-to-Model Transformations (20)

Plus de Tonny Madsen

Plus de Tonny Madsen (20)

Dernier

Dernier (20)

ITU - MDD – Model-to-Model Transformations