Sheet 1 MDA Workshop Enschede, March 2004 Unifying Approach for Model Transformations in the MOF...

Sheet 1MDA Workshop Enschede, March 2004

Unifying Approach for

Model Transformations in

the MOF Architecture

Ivan Kurtev, Klaas van den Berg

University of Twente, the Netherlands


Outline

Transformation scenarios; Limitations in current transformation

languages; Uniform representation of model elements

in MOF; Transformation language; Instantiation mechanisms; Conclusions;


Transformation Scenarios (1)

QVT Scenario Transformation specified

between meta models; The context of

Query/Views/Transformation RFP by OMG;

MOF

UMLMetamodel

JavaMetamodel

a UMLmodel

Javaclasses

User dataJava

objects

TransformationDefiniton

Transformation

Execution

MOF

DTD MetaModel

RelationalMeta Model

a DTDa Relational

Schema

an XMLDocument

a RelationalDatabaseM0

M1

M2

M3


TransformationExecutionM0

M1

M2

M3

Data Transformation Scenario

Transformation is executed over concrete data instances at level M0;

E.g. Common Warehousing Metamodel (CWM);


Transformation Scenarios (2)

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

QVT and CWM languages have similarities but cannot be applied in a different context.


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;

Instantiation for models at M1 is not defined by MOF;

Disadvantages: QVT languages are not applicable at level M0; Coupled with the MOF instantiation;



Common Warehouse Metamodel (CWM): Reuses the concepts of classes and instances from

UML; Concrete data models (XML, Relational,…) specialize

these concepts; To apply CWM transformations we extend CWM meta

model;

Disadvantages: Can not handle models at level M2 if they do not

specialize CWM;



Summary

Current transformation languages are coupled with particular instantiation mechanisms

This coupling prevents the existence of a single transformation language for all scenarios

Problem

How to unify the different transformation techniques?


Approach

Two basic ideas: Represent model

elements at any level of MOF in a uniform way;

Decouple the transformation language from instantiation mechanism;

The MOFMMM

a Meta Model

a Model

data

Level M3

Level M2

Level M1

Level M0

Single GenericRepresentation

Transformation Language:

Operates on the generic representation;

Specifies different instantiation mechanisms as transformations;


Structure of Model Elements

MOF architecture is a space of model elements; Elements have identity and named slots; Special instanceOf slots; This structure is applicable to model elements at any level of the MOF

architecture; Slot multiplicity is not modeled;


Example: MOF Model Representation (1)

Simplified MOF Model

Primitive data types and multiplicity are skipped


MOF Model represented as a set of model elements

Class

ModelElement

Attribute

Association

ModElNameAttr

"Class"

"Attribute"

"Association"

"name"name

classAttrAssoc

typefrom

to

supertype

attributes

GeneralizableElement

Classifier

AssociationEnd

"ModelElement"

name

"GeneralizableElement"

name

"Classifier"name

name

name

name

"AssociationEnd"

name

isAbstractAttr

"isAbstract"

name

attributes

GeneralizesAssoc"Generalizes"name

A1

A2"supertype"name

type

AssocEndClassAssoc

from

to

A5

A6 "type"name

type

AssocTo

from

to

A7

A8"to"name

type

type

from

to

A3

A4"attributes"

name

type

type

supertype

supertype

supertypesupertype

type

AssocFrom

from

to

A9

A10"from"name

type

attrClassAssoc

A11

A12fromto

type

type

"type"

name

"true"

isAbstract

supertype

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF



MOF Model represented as a set of model elements


Class

ModelElement

Attribute

ModElNameAttr

"Class"

"Attribute"

"name"name

supertype

attributes

GeneralizableElement

Classifier

"ModelElement"

name

"GeneralizableElement"

name

"Classifier"name

name

name

supertype

supertype

supertype

"true"

isAbstract

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF

instanceOfMOF


Multiple InstanceOf Relations

JavaClass

MOF ClassM3

instanceOfMOF

type

JavaObject

a Class an Object

instanceOfMOF

instanceOfMOF instanceOfMOF

instanceOfJavaJavaClass

MOF Class

instanceOfMOF

a Class

an Object

instanceOfMOF

instanceOfJava

M2

M1

M0

InstanceOfMOF – linguistic (physical) instantiation;

InstanceOfJava – ontological (logical) instantiation;


Example: Relational Model (1)

Metamodel of relational schemas and its instances


Two ways to refer to the field A: Navigating over the graph: aTuple.field[name=“A”].value By using the type aSchema: aTuple.A

The first is linguistic, based on InstanceOfMOF;

The second is ontological, based on InstanceOfREL;

Example: Relational Model (2)

aSchema

ft1

"A"

name

fieldTypes

"mySchema"

nameft2"B"

name

Int

type

Boolean

type

aTuple

f1

"A"

name

field

"true"

value

f2 "B"name

'123'

value

instanceOfREL

RelationalSchemaFieldType

instanceOfMOF

instanceOfMOF instanceOfMOF

Tuple Field

instanceOfMOFinstanceOfMOF

instanceOfMOF

instanceOfREL

instanceOfREL


Transformation Language

Models are sets of model elements; Transformations are set of rules; Two types of rules:

Model element rule: creates model elements in the target model;

Slot rules: assign values to slots;

Four basic operations: Selection of source model elements on the base of their type; Instantiating model elements on the base of a type; Accessing slot values; Assigning values to slots;


Modeling Instantiation

InstanceOfMOF is assumed to be default instantiation mechanism;

Possibility to work with any other ontological instantiation mechanism;

Transformation engine is configured with: Rules for instantiation; Rules for slot access; Rules for assigning values to slots;


Instantiating Model Elements (1)

Instantiation is treated as a transformation from a model element (the type) to another model element (instance) with empty slots;

Instantiation is defined in the transformation language;

Example: MOF Instantiation (the default mechanism):MOFClassInstantiation ModelElementRule source [c:Class, condition {c.isAbstract=false}] target [ModelElement {slots}] SlotRules { attributeSlots source [a:Attribute=c.attributes] target [slots] associationSlots source [assoc:Association,

condition {assoc.from.type=c}] target [slots] }

MOFAttributeToSlot ModelElementRule source [a:Attribute] target [Slot {name=a.name}]

MOFAssociationToSlot ModelElementRule source [assoc:Association] target [Slot {name=assoc.to.name}]


Instantiating Model Elements (2)

Relational schema instantiation:

RelSchemaInstantiation ModelElementRule source [s:RelationalSchema] target [Tuple{field, instanceOfRel =s}]

SlotRules{ Fields source [f:FieldType=s.fieldTypes] target [field]}

FieldTypeToField ModelElementRule source [ft:FieldType] target [Field{name=ft.name}]

Instantiation of Tuple and Field is according to the default MOF instantiation


Accessing Slot Values

Two options: Slot exists in the underlying representation:

Example: slot named field of aTuple model element; Slot does not exist.

Example: slots A and B of aTuple model element;

In the second case we model slot access as a slot rule:

TupleFieldToSchemaField SlotRule inputParameters [slotName: String, contextNode:Tuple]

source [f:Field=contextNode.field, condition{f.name=slotName}] target [Slot{name=slotName}=f.value]


Assigning Slot Values

The same two options: Slot exists in the underlying representation

Example: slot named field of aTuple model element; Slot does not exist (It is a logical one); Example: slots A and B of aTuple model element;

In the second case we model the setting of the value as in-place transformation:

SettingSlotValue ModelElementRule inputParameters [slotName:String, newValue:ModelElement] source [s:Tuple, f:Field=s.field, condition {f.name=slotName}] target [update f {value=newValue}]


Conclusions

Transformation language: Transformations between models at any level in MOF; Decoupled from the instantiation mechanism; Different instantiations are modeled as generic transformations;

Future Work: Modeling Generalization relation;

Sheet 1 MDA Workshop Enschede, March 2004 Unifying Approach for Model Transformations in the MOF...

Documents

Transcript of Sheet 1 MDA Workshop Enschede, March 2004 Unifying Approach for Model Transformations in the MOF...