• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

ITU - MDD – Model-to-Model Transformations

  • 942 views
Uploaded on

This presentation describes the use Model-to-Model transformations (M2M). It focus on the why, what and how. …

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.

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
942
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
29
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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.
  • 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)
    M2M M2T
  • 3. Why use Model-to-Model Transformations
    • Translation
    • Refactoring
    • Refinement
    • Code Generation
    • Specialization
    • Migration
    • Normalization
  • 4. Model-to-Model Transformations Principles
  • 5. 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
  • 6. Example of Model Transformation
  • 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 conformsTo conformsTo based on based on input output
  • 8. Some Terms Endogeneous Exogeneous Horizontal vertical M2 M1
  • 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)
    - -
  • 10. Combining both approaches in an MDE process
    • Application on a concrete use case: UML2 to Java
      • Same case using an M2M+M2T solution
    - -
  • 11. Combining both approaches in an MDE process
    • Application on a concrete use case: UML2 to Java
      • Same case using an M2M+M2T solution + new refactoring
    - -
  • 12. Combining both approaches in an MDE process
    • Application on a concrete use case: UML2 to Java and C#
      • Same case using an M2M+M2T solution + new mapping
    - -
  • 13. Combining both approaches in an MDE process
    • Application on a concrete use case: UML2 to Java
      • Same case using an M2M+M2T solution + new extraction
    - -
  • 14. Combining both approaches in an MDE process
    • 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)
    - -
  • 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
  • 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
  • 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
  • 18. Text Manipulation Tools
    • Unix “pipe-line” tools
      • sed, awk, perl, ….
    • Special purpose programming languages
      • Snobol
    • Rules are typically based on regular expressions
  • 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
  • 20. Extensible Stylesheet Language Transformation (XSLT)
    • 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
  • 21. Extensible Stylesheet Language Transformation (XSLT)
    • 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
  • 22. Extensible Stylesheet Language Transformation (XSLT) <model xmlns:uml=&quot;http://www.eclipse.org/uml2/1.0.0/UML&quot; xmlns:xmi=&quot;http://www.omg.org/XMI&quot;> <package id=&quot;pck1&quot; name=“library&quot;> <class id=&quot;c1&quot; name=&quot;Book&quot;> <association aggregationType=&quot;composite&quot; id=&quot;c1_ass1&quot; name=&quot;chapters&quot; targetClass=&quot;c2&quot;/> <attribute id=&quot;c1_atr1&quot; name=&quot;title&quot; type=&quot;dt1&quot;/> </class> <class id=&quot;c2&quot; name=&quot;Chapter&quot;> <attribute id=&quot;c2_atr1&quot; name=&quot;nbPages&quot; type=&quot;dt2&quot;/> <attribute id=&quot;c2_atr2&quot; name=&quot;title&quot; type=&quot;dt2&quot;/> <attribute id=&quot;c2_atr3&quot; name=&quot;author&quot; type=&quot;dt1&quot;/> <association aggregationType=&quot;none&quot; id=&quot;c2_ass1&quot; name=&quot;book&quot; targetClass=&quot;c1&quot;/> </class> </package> </model>
  • 23. Extensible Stylesheet Language Transformation (XSLT) <model xmlns:uml=&quot;http://www.eclipse.org/uml2/1.0.0/UML&quot; xmlns:xmi=&quot;http://www.omg.org/XMI&quot;> <package id=&quot;pck1&quot; name=“library&quot;> <class id=&quot;c1&quot; name=&quot;Publication&quot;> <attribute id=&quot;c1_atr1&quot; name=&quot;title&quot; type=&quot;dt1&quot;/> <attribute id=&quot;c1_atr2&quot; name=&quot;nbPages&quot; type=&quot;dt2&quot;/> <attribute id=&quot;c1_atr3&quot; name=&quot;authors&quot; type=&quot;dt1&quot;/> </class> <datatype id=&quot;dt1&quot; name=&quot;String&quot;/> <datatype id=&quot;dt2&quot; name=&quot;Integer&quot;/> </package> </model>
  • 24. Extensible Stylesheet Language Transformation (XSLT) <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <xsl:transform version=&quot;1.0&quot; xmlns:xsl=&quot;http://www.w3.org/1999/XSL/Transform&quot; > <xsl:output method=&quot;xml&quot; /> <xsl:template match=&quot;library.Book&quot; > <xsl:variable name=&quot;title&quot; select=&quot;@title&quot; /> <xsl:variable name=&quot;authors&quot; select=&quot;concat(@chapters.author, ',')&quot;/> <xsl:variable name=&quot;nbPages&quot; select=&quot;sum(@chapters.nbPages)&quot;/> <xsl:call-template name=&quot;createPublication&quot;> <xsl:with-param name=&quot;title&quot; select=&quot;$title&quot;/> <xsl:with-param name=&quot;authors&quot; select=&quot;$authors&quot;/> < xsl:with-param name=&quot;nbPages&quot; select=&quot;$nbPages&quot;/> </xsl:call-template> </xsl:template> </xsl:transform>
  • 25. Graph Transformations
  • 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
  • 27. 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
  • 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
  • 29. 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
  • 30. 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
  • 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
  • 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);
    • }
    • }
  • 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
  • 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
  • 35. Operational QVT Example: Input Model
  • 36. Operational QVT Example: Expected Output Model
  • 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 }
  • 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
    Metamodel A Metamodel B Model A Model B MOF ATL defines M1 M0 M2 ATL Transformation Model Transformation conforms to conforms to
  • 39. ATL Example
    • Assume we want to translate data from a hierarchical model (Family) to a flat model (Person)
  • 40. ATL Example
  • 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 ) }
  • 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;
  • 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