Ipa lentedagen on software architecture
This presentation is the property of its rightful owner.
Sponsored Links
1 / 35

IPA Lentedagen on Software Architecture PowerPoint PPT Presentation


  • 46 Views
  • Uploaded on
  • Presentation posted in: General

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;

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ipa lentedagen on software architecture

IPA Lentedagen on Software Architecture

Model Transformations in MDA

Ivan Kurtev

University of Twente


Outline

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

MDA Transformation Pattern


Refined mda transformation pattern

Refined MDA Transformation Pattern


Transformation languages

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

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

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

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

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 languages1

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;


Example dstc ibm proposal

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

Source Meta-model

Simplified UML meta-model


Target meta model

Target Meta-model

Simplified Java meta-model


Transformation rules

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

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;


Outline1

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;


Classification of transformation languages

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 rules1

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

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 (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

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

  • 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

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


Outline2

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;


Transformation scenarios

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;


Transformation scenarios1

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;


Ipa lentedagen on software architecture

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.


Ipa lentedagen on software architecture

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;


Ipa lentedagen on software architecture

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?


Outline3

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;


Transformation alternatives 1

Transformation Alternatives (1)


Transformation alternatives 2

Transformation Alternatives (2)

Example: UML to XML Schema transformation


Transformation alternatives 3

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!


Conclusions

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;


  • Login