1. Sheet 1© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 IPA Lentedagen on Software Architecture Model Transformations in MDA Ivan Kurtev University of Twente

2. Sheet 2© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 3© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 MDA Transformation Pattern

4. Sheet 4© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 Refined MDA Transformation Pattern

5. Sheet 5© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 6© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 7© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 8© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 9© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 10© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 11© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 12© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 Source Meta-model Simplified UML meta-model

13. Sheet 13© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 Target Meta-model Simplified Java meta-model

14. Sheet 14© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 15© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 16© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 17© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 18© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 19© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 20© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 21© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 22© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 23© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 24© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 25© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 26© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 27© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 28© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 29© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 30© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 31© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 32© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 Transformation Alternatives (1)

33. Sheet 33© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 Transformation Alternatives (2) Example: UML to XML Schema transformation

34. Sheet 34© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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. Sheet 35© 2005 kurtev@cs.utwente.nlIPA Lentedagen, 30 March-1 April 2005 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;