Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


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