Your SlideShare is downloading. ×
Presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Presentation

285
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
285
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
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. IPA Lentedagen on Software Architecture Model Transformations in MDA Ivan Kurtev University of Twente
  • 2. Outline
    • Transformation Languages and MOF 2.0 QVT RFP;
    • QVT Requirements;
    • Example:
      • DSTC transformation language;
    • Classification of Transformation Languages;
    • Transformation Scenarios;
    • Identification and Selection of Alternative Transformations;
  • 3. MDA Transformation Pattern
  • 4. Refined MDA Transformation Pattern
  • 5. Transformation Languages
    • Two approaches for writing transformation definitions:
    • In general-purpose programming language;
    • In domain-specific transformation language;
    • OMG Approach:
    • Domain-specific transformation Language
    • MOF 2.0 Query/Views/Transformation (QVT) Request for Proposals;
  • 6. MOF 2.0 QVT RFP
    • QVT RFP addresses the need for standard language for transformation definitions in MDA;
    • QVT formulates two sets of requirements:
      • Mandatory requirements;
      • Optional requirements;
    • 6 submissions to the RFP (QVTP, TRL, DSTC/IBM, Compuware/Sun, Adaptive Ltd., InteractiveObjects (IO));
    • No proposed standard yet;
  • 7. QVT Requirements (1)
    • Mandatory requirements:
      • Query language : proposals shall define a language for querying models;
      • Transformation language : proposals shall define a language for expressing transformation definitions. Transformation definitions are executed over MOF models, i.e. models that are instances of MOF meta-models;
      • Abstract syntax definition : QVT languages shall define their abstract syntax as a MOF meta-model;
      • View language : QVT languages shall enable creation of views on models;
      • Declarative language : proposals shall define declarative transformation language;
  • 8. QVT Requirements (2)
    • Optional requirements:
      • Bidirectional transformation definitions : proposals may support transformation definitions executable in two directions;
      • Traceability : proposals may support generation of traceability information;
      • Reuse mechanisms : QVT languages may support mechanisms for reuse and extension of generic transformation definitions;
      • Transactional transformations : proposals may support execution of parts of transformations as a transaction;
      • Update of existing models : proposals may support execution of transformation where the source and the target model are the same;
  • 9. QVT Terminology
    • Query : A query is an expression that is evaluated over a model. The result of a query is one or more instances of types defined in the source model, or defined by the query language;
    • View : A view is a model which is completely derived from another model (the base model). There is a ‘live’ connection between the view and the base model;
    • Transformation : A model transformation is a process of automatic generation of a target model from a source model, according to a transformation definition (Kleppe et al., MDA Explained ) ;
      • Definitions of Query and View are based on Gardner et al.
  • 10. Transformation Languages
    • Declarative : transformation definitions specify relationships between the elements in the source and target models Transformation engine applies an algorithm over the relationships to produce a result;
    • Imperative : definition specifies an explicit sequence of steps to be executed in order to produce the result;
    • Hybrid : exposes mix of declarative and imperative constructs;
  • 11. Example: DSTC/IBM Proposal
    • Declarative language;
    • Structure of transformation definitions:
      • Pattern definitions;
      • Transformation rules;
      • Tracking relationships;
    • Example: UML-to-Java transformation;
    • Example is taken from DSTC/IBM/CBOP QVT Submission
  • 12. Source Meta-model
    • Simplified UML meta-model
  • 13. Target Meta-model
    • Simplified Java meta-model
  • 14. Transformation Rules
    • Transformation declaration and a transformation rule:
    TRANSFORMATION uml2java(SOURCE UML, TARGET Java) TRACKING TModel; RULE umlClassifierToJavaClass(X, Y) FORALL UMLClassifier X WHERE X.name = N MAKE JavaClass Y, Y.name = N LINKING X, Y BY JavaClassFromUMLClassifier; ...
  • 15. Tracking Relationships
    • Tracking class and a transformation rule:
    CLASS JavaClassFromUMLClassifier { UMLClassifier a; JavaClass c; KEY (a); } RULE umlAttributeToJavaField FORALL UMLAttribute X WHERE JavaClassFromUMLClassifier LINKS X.owner, JC MAKE JavaField Y, Y.owner = JC LINKING X, Y BY FieldFromAttr;
  • 16. Rule Inheritance
    • Rule inheritance and Superseding:
    CLASS JavaIntfFromUMLIntf EXTENDS JavaClassFromUMLClassifier; RULE umlInterfaceToJavaInterface(X, Y) SUPERSEDES umlClassifierToJavaClass(X, Y) FORALL UMLInterface X MAKE JavaInterface Y, Y.name = X.name LINKING X, Y BY JavaIntfFromUMLIntf; RULE umlClassToJavaClass(X, Y) EXTENDS umlClassifierToJavaClass(X, Y) MAKE JavaMethod M, M.name = X.name, Y.constructor = M LINKING X, M BY JavaConsFromUMLClass;
  • 17. Outline
    • Transformation Languages and MOF 2.0 QVT RFP;
    • QVT Requirements;
    • Example:
      • DSTC transformation language;
    • Classification of Transformation Languages ;
    • Transformation Scenarios;
    • Identification and Selection of Alternative Transformations;
  • 18. Classification of Transformation Languages
    • Czarnecki and Helsen define classification of transformation languages.
    • Categories of classification:
      • Transformation Rules;
      • Source-Target Relationships;
      • Rule Application Strategy;
      • Rule Scheduling;
      • Rule Organization;
      • Traceability Links;
    • Variation points for every category: represent the design alternatives for languages;
  • 19. Transformation Rules
    • Transformation rule: basic construct in transformation languages
      • Left-hand side and right-hand side: syntactically separated or mixed;
    • Variation points:
      • Directionality: unidirectional and bidirectional ;
      • Rule parameterization: additional parameters passed to rules;
  • 20. Rule Application Strategy
    • Applied when a rule matches more than one source element/tuple in the source model
    • Strategies:
      • Deterministic : follows a particular algorithm (e.g. depth-first, breadth-first);
      • Non-deterministic ;
      • Interactive : the user specifies the strategy;
  • 21. Rule Scheduling (1)
    • Rule scheduling is responsible for the order of rule application;
    • Variation points:
      • Form: How the order is expressed
        • Implicit vs. Explicit;
        • Explicit internal scheduling;
        • Explicit external scheduling
      • Rule selection:
        • Explicit condition;
        • Rule conflict resolution;
  • 22. Rule Scheduling (2)
    • Variation points:
      • Rule iteration:
        • Recursion;
        • Looping;
        • Fix-point (until a condition is met);
        • Combination these forms;
      • Phasing: transformation definition is separated into phases executed sequentially. Each phase uses certain set of rules;
  • 23. Rule Organization
    • Rule organization is concerned with relationships among transformation rules;
    • Variation points:
      • Modularity mechanisms: packaging constructs (e.g. modules, units, etc.)
      • Reuse mechanisms (e.g. rule inheritance);
      • Organizational structure:
        • Source-driven;
        • Target-driven;
        • Arbitrary;
  • 24. Traceability Links
    • Traceability links keep record of correspondences between source and target elements established by transformation rules;
    • Maintaining traceability links:
      • User-based : the user maintains links as ordinary model elements;
      • Dedicated support : support provided by the language and transformation engine. May be automatic and manual ;
  • 25. Outline
    • Transformation Languages and MOF 2.0 QVT RFP;
    • QVT Requirements;
    • Example:
      • DSTC transformation language;
    • Classification of Transformation Languages;
    • Transformation Scenarios ;
    • Identification and Selection of Alternative Transformations;
  • 26. Transformation Scenarios
    • QVT Scenario
    • Transformation specified between meta models;
    • The context of Query/Views/Transformation RFP by OMG;
    • Data Transformation Scenario
    • Transformation is executed over concrete data instances at level M0;
    • E.g. Common Warehousing Metamodel (CWM);
  • 27. Transformation Scenarios
    • Data Binding in context of MOF
    • Transformation specified at level M2 is executed twice in lower levels M1 and M0;
    • Inter-level Transformations
    • XML Metadata Interchange (XMI);
    • Java Metadata Interchange (JMI);
  • 28. Transformation Techniques
    • QVT Scenario :
      • 6 submissions to OMG, standardization is expected;
    • Data transformation Scenario :
      • CWM OMG document;
      • Supports object-oriented, relational, XML, record-based data sources;
    • Data Binding :
      • proprietary tools, outside the context of MOF architecture ;
    • XMI, JMI :
      • transformations specified with grammars and templates ;
    • There is no single language that addresses all the scenarios.
  • 29. Transformation Techniques
    • QVT Languages :
    • Execute transformations among models at level M1;
    • Rely on the MOF instantiation mechanism:
      • Non-abstract Classifiers at level M2 can be instantiated;
      • Attributes become slots;
      • Associations become links;
    • Disadvantages:
    • QVT languages are not applicable at level M0;
    • Coupled with the MOF instantiation;
  • 30. Transformation Techniques
    • Summary
    • Current transformation languages are coupled with particular instantiation and generalization mechanisms
    • This coupling prevents the existence of a single transformation language for all scenarios
    • Problem
    • How to decouple the transformation language from instantiation and generalization mechanisms for a given model?
  • 31. Outline
    • Transformation Languages and MOF 2.0 QVT RFP;
    • QVT Requirements;
    • Example:
      • DSTC transformation language;
    • Classification of Transformation Languages;
    • Transformation Scenarios;
    • Identification and Selection of Alternative Transformations ;
  • 32. Transformation Alternatives (1)
  • 33. Transformation Alternatives (2) Example: UML to XML Schema transformation
  • 34. Transformation Alternatives (3)
    • Problem 1: Lack of support for identification of alternative transformations
      • Transformation to the desired model may not always be obvious and trivial;
    • Problem 2: Selection among Alternatives
      • Alternatives differ in their Quality properties such as Extensibility, Adaptability, Performance;
    • Alternative Transformations Analysis must be addressed explicitly in the MDA software development process!
  • 35. Conclusions
    • OMG approach for model transformations:
      • Domain-specific transformation languages;
      • QVT MOF 2.0 RFP, no standard yet;
    • Two example languages:
      • DTSC (declarative language);
      • TRL (hybrid language);
    • Classification of transformation languages: categories and variation points;
    • QVT covers only one transformation scenario within MOF architecture;
    • Identification of alternative transformations requires additional support;