1 / 35

IPA Lentedagen on Software Architecture

IPA Lentedagen on Software Architecture. Model Transformations in MDA Ivan Kurtev University of Twente. Outline. Transformation Languages and MOF 2.0 QVT RFP; QVT Requirements; Example: DSTC transformation language; Classification of Transformation Languages; Transformation Scenarios;

rasha
Download Presentation

IPA Lentedagen on Software Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation 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 Data Transformation Scenario • Transformation is executed over concrete data instances at level M0; • E.g. Common Warehousing Metamodel (CWM); QVT Scenario • Transformation specified between meta models; • The context of Query/Views/Transformation RFP by OMG;

  27. Transformation Scenarios Inter-level Transformations • XML Metadata Interchange (XMI); • Java Metadata Interchange (JMI); Data Binding in context of MOF • Transformation specified at level M2 is executed twice in lower levels M1 and M0;

  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;

More Related