presentation

Sheet 1© 2005 [email protected] IPA Lentedagen, 30 March-1 April 2005

IPA Lentedagen on Software Architecture

Model Transformations in MDA

Ivan KurtevUniversity of Twente


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;


MDA Transformation Pattern

Transformation

Source Model Transformationdefinition

Target Model

input

input

output


Refined MDA Transformation Pattern

TransformationSourceModel

TransformationDefinition

TargetModel

SourceMetamodel

TargetMetamodel

uses uses

instanceOf instanceOf

TransformationLanguage

written in

Requirementssatisifies satisifies


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;


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;


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;


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;


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.


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;


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


Source Meta-model

Simplified UML meta-model


Target Meta-model

Simplified Java meta-model


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;

...


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;


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;





Transformations;


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;


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;


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;


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;


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;


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;


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;





Transformations;


Transformation Scenarios

MOF

UMLMetamodel

JavaMetamodel

a UMLmodel

Javaclasses

User dataJava

objects

TransformationDefiniton

TransformationExecution

MOF

DTD MetaModel

RelationalMeta Model

a DTDa Relational

Schema

an XMLDocument

a RelationalDatabaseM0

M1

M2

M3


TransformationExecutionM0

M1

M2

M3

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);


Transformation Scenarios

MOF

DTD MetaModel

Java MetaModel

a DTDJava

Classes

an XMLDocument

JavaObjectsM0

M1

M2

M3

SchemaCompilation

Unmarshaling


MOF

DTD MetaModel

UML MetaModel

UML DTDan UMLModel

an XMLDocument

a ModelInstanceM0

M1

M2

M3XMI

Java MetaModel

JavaClasses

JavaObjects

JMI

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);


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.



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;



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?





Transformations;


Transformation Alternatives (1)

MMAMMB

MA

Instance of

MB

Instance of

MCA MC1B

MC2B

C1A

C2A

C1B

C2B

Level M2

Level M1

Source meta-model

Target meta-model

Source modelTarget alternative

models



Instance of Instance of

ClassElement

Complex Type

C1

C2

El1

CT1

Level M2

Level M1

UML meta-model XML Schema meta-model

a UML model Alternative XML schemas

Example: UML to XML Schema transformation



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!


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;

presentation

Documents

private capital access

private finance

public investment

investment of us

financing municipalities

market space

public entities

private sources