Transcript Document

Unifying Approach
for
Model Transformations
in
the MOF Architecture
Ivan Kurtev, Klaas van den Berg
University of Twente, the Netherlands
MDA Workshop
Enschede, March 2004
Sheet 1
Outline
 Transformation scenarios;
 Limitations in current transformation languages;
 Uniform representation of model elements in
MOF;
 Transformation language;
 Instantiation mechanisms;
 Conclusions;
MDA Workshop
Enschede, March 2004
Sheet 2
Transformation Scenarios (1)
MOF
M3
M2
UML
Metamodel
M1
a UML
model
M0
User data
Transformation
Definiton
Transformatio
n
Execution
Java
Metamodel
M2
DTD Meta
Model
Java
classes
M1
a DTD
Transformation
Definiton
a Relational
Schema
Java
objects
M0
an XML
Document
Transformation
Execution
a Relational
Database
QVT Scenario
 Transformation specified
between meta models;
 The context of
Query/Views/Transformation
RFP by OMG;
MDA Workshop
MOF
M3
Enschede, March 2004
Relational
Meta Model
Data Transformation Scenario
 Transformation is executed over
concrete data instances at level
M0;
 E.g. Common Warehousing
Metamodel (CWM);
Sheet 3
Transformation Scenarios (2)
MOF
M3
XMI
M3
MOF
JMI
M2
DTD Meta
Model
Transformation
Definiton
Java Meta
Model
M2
DTD Meta
Model
UML Meta
Model
Java Meta
Model
M1
a DTD
Schema
Compilation
Java
Classes
M1
UML DTD
an UML
Model
Java
Classes
M0
an XML
Document
Java
Objects
M0
an XML
Document
a Model
Instance
Java
Objects
Unmarshalin
g
Data Binding in context of MOF
 Transformation specified at level
M2 is executed twice in lower
levels M1 and M0;
MDA Workshop
Enschede, March 2004
Inter-level Transformations
 XML Metadata Interchange (XMI);
 Java Metadata Interchange (JMI);
Sheet 4
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.
MDA Workshop
Enschede, March 2004
Sheet 5
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;
MDA Workshop
Enschede, March 2004
Sheet 6
Transformation Techniques (3)
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;
MDA Workshop
Enschede, March 2004
Sheet 7
Transformation Techniques (4)
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?
MDA Workshop
Enschede, March 2004
Sheet 8
Approach
Two basic ideas:
Level M3

The MOF
MMM

Level M2
a Meta Model
Single Generic
Representation
Level M1
Transformation Language:

a Model

Level M0
MDA Workshop
data
Enschede, March 2004
Represent model elements at
any level of MOF in a uniform
way;
Decouple the transformation
language from instantiation
mechanism;
Operates on the generic
representation;
Specifies different
instantiation mechanisms as
transformations;
Sheet 9
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;
MDA Workshop
Enschede, March 2004
Sheet 10
Example: MOF Model Representation (1)
Simplified MOF Model
Primitive data types and multiplicity are skipped
MDA Workshop
Enschede, March 2004
Sheet 11
Example: MOF Model Representation (2)
ModElNameAttr
"true"
name
"name"
isAbstract
attributes
"isAbstract"
"Model
Element"
name
attributes
from
type
name
"Generalizes"
instanceOfMOF
ModelElement
"Generalizable
Element"
isAbstractAttr
A1
name
name
"Attribute"
supertype
supertype
name
Generalizable
Element
GeneralizesAssoc
Attribute
instanceOfMOF
type
to
name
"supertype"
type
instanceOfMOF
supertype
A2
instanceOfMOF
name
"Classifier"
Classifier
name
"attributes"
A4
instanceOfMOF
"Class"
to
supertype
supertype
name
from
name
"Association"
instanceOfMOF
supertype
from
to
"from"
name
"type"
A12
to
attrClassAssoc
from
name
"type"
AssocEnd
ClassAssoc
to
A8
name
A6
AssocFrom
instanceOfMOF
name
"to"
type
type
instanceOfMOF
to
A11
instanceOfMOF
A9
from
AssocTo
A3
Class
type
A7
type
instanceOfMOF
Association
type
classAttr
Assoc
from
A10
type
type
instanceOfMOF
Association
End
type
A5
instanceOfMOF
name
"Association
End"
MOF Model represented as a set of model elements
MDA Workshop
Enschede, March 2004
Sheet 12
Example: MOF Model Representation (2)
ModElNameAttr
"true"
name
"name"
isAbstract
attributes
"Model
Element"
name
instanceOfMOF
ModelElement
"Generalizable
Element"
name
"Attribute"
supertype
supertype
name
Generalizable
Element
Attribute
instanceOfMOF
instanceOfMOF
supertype
instanceOfMOF
"Classifier"
name
Classifier
instanceOfMOF
"Class"
supertype
name
Class
instanceOfMOF
MOF Model represented as a set of model elements
MDA Workshop
Enschede, March 2004
Sheet 13
Multiple InstanceOf Relations
M3
MOF Class
MOF Class
instanceOfMOF
instanceOfMOF
M2
JavaClass
instanceOfMOF
M1
JavaClass
instanceOfMOF
instanceOfJava
instanceOfMOF
a Class
a Class
JavaObject
instanceOfMOF
type
an Object
instanceOfJava
M0


an Object
InstanceOfMOF – linguistic (physical) instantiation;
InstanceOfJava – ontological (logical) instantiation;
MDA Workshop
Enschede, March 2004
Sheet 14
Example: Relational Model (1)
Metamodel of relational schemas and its instances
MDA Workshop
Enschede, March 2004
Sheet 15
Example: Relational Model (2)
FieldType
RelationalSchema
instanceOfMOF
instanceOfMOF
"A"
instanceOfMOF
Tuple
Field
instanceOfMOF
instanceOfMOF
Int
"A"
type
name
'123'
instanceOfMOF
f1
ft1
fieldTypes
instanceOfREL
aSchema
"B"
name
value
name
instanceOfREL
field
aTuple
name
ft2
name
f2
type
Boolean
instanceOfREL
"mySchema"
"B"
value
"true"
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;
MDA Workshop
Enschede, March 2004
Sheet 16
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;
MDA Workshop
Enschede, March 2004
Sheet 17
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;
MDA Workshop
Enschede, March 2004
Sheet 18
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]
MOFAttributeToSlot ModelElementRule
source [a:Attribute]
target [Slot {name=a.name}]
MOFAssociationToSlot ModelElementRule
source [assoc:Association]
target [Slot {name=assoc.to.name}]
associationSlots
source [assoc:Association,
condition {assoc.from.type=c}]
target [slots]
}
MDA Workshop
Enschede, March 2004
Sheet 19
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
MDA Workshop
Enschede, March 2004
Sheet 20
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]
MDA Workshop
Enschede, March 2004
Sheet 21
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 inplace transformation:
SettingSlotValue ModelElementRule
inputParameters [slotName:String, newValue:ModelElement]
source [s:Tuple, f:Field=s.field, condition {f.name=slotName}]
target [update f {value=newValue}]
MDA Workshop
Enschede, March 2004
Sheet 22
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;
MDA Workshop
Enschede, March 2004
Sheet 23