ITU - MDD – Model-to-Model Transformations

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.

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)
M2M M2T

Why use Model-to-Model Transformations
Translation
Refactoring
Refinement
Code Generation
Specialization
Migration
Normalization

Model-to-Model Transformations Principles

Example of Model Transformation 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) M2 M1

Example of Model Transformation

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 conformsTo conformsTo based on based on input output

Some Terms Endogeneous Exogeneous Horizontal vertical M2 M1

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)
- -

Same case using an M2M+M2T solution
- -

Same case using an M2M+M2T solution + new refactoring
- -

Application on a concrete use case: UML2 to Java and C#
Same case using an M2M+M2T solution + new mapping
- -

Same case using an M2M+M2T solution + new extraction
- -

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)
- -

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

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

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

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

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

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

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

Extensible Stylesheet Language Transformation (XSLT) <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_atr2" name="title" type="dt2"/> <attribute id="c2_atr3" name="author" type="dt1"/> <association aggregationType="none" id="c2_ass1" name="book" targetClass="c1"/> </class> </package> </model>

Extensible Stylesheet Language Transformation (XSLT) <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_atr1" name="title" type="dt1"/> <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>

Extensible Stylesheet Language Transformation (XSLT) <?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>

Graph Transformations

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

Inheritance RHS LHS The pattern matches all nodes of type ElementWithTitle, considering the inheritance hierarchy Type graph Production rule Book Chapter nbPages : Integer author : String chapters * ElementWithTitle title : String t : ElementWithTitle

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

QVT
QVT stands for Q uery/ V iews/ T ransformations
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

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

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

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

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

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

Operational QVT Example: Input Model

Operational QVT Example: Expected Output Model

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 }

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
Metamodel A Metamodel B Model A Model B MOF ATL defines M1 M0 M2 ATL Transformation Model Transformation conforms to conforms to

ATL Example
Assume we want to translate data from a hierarchical model (Family) to a flat model (Person)

ATL Example

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

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;

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

by Tonny Madsen on Nov 22, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

ITU - MDD – Model-to-Model Transformations — Presentation Transcript