IPA Lentedagen on Software Architecture

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 transformation definitions specify
  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 umlClassifierToJava
Class(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 (1)

• QVT Scenario
• 5 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 (2)

• 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 (3)

• Summary
• QVT 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 Comparison 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, several submissions, no standard
  yet
• Example language
• DTSC (declarative 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