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
Sheet 2MDA Workshop Enschede, March 2004
Outline
Transformation scenarios; Limitations in current transformation
languages; Uniform representation of model elements
in MOF; Transformation language; Instantiation mechanisms; Conclusions;
Sheet 3MDA Workshop Enschede, March 2004
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
TransformationDefiniton
TransformationExecutionM0
M1
M2
M3
Data Transformation Scenario
Transformation is executed over concrete data instances at level M0;
E.g. Common Warehousing Metamodel (CWM);
Sheet 4MDA Workshop Enschede, March 2004
Transformation Scenarios (2)
MOF
DTD MetaModel
Java MetaModel
a DTDJava
Classes
an XMLDocument
JavaObjectsM0
M1
M2
M3
SchemaCompilation
Unmarshaling
TransformationDefiniton
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);
Sheet 5MDA Workshop Enschede, March 2004
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.
Sheet 6MDA Workshop Enschede, March 2004
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;
Sheet 7MDA Workshop Enschede, March 2004
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;
Sheet 8MDA Workshop Enschede, March 2004
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?
Sheet 9MDA Workshop Enschede, March 2004
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;
Sheet 10MDA Workshop Enschede, March 2004
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;
Sheet 11MDA Workshop Enschede, March 2004
Example: MOF Model Representation (1)
Simplified MOF Model
Primitive data types and multiplicity are skipped
Sheet 12MDA Workshop Enschede, March 2004
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
Example: MOF Model Representation (2)
Sheet 13MDA Workshop Enschede, March 2004
MOF Model represented as a set of model elements
Example: MOF Model Representation (2)
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
Sheet 14MDA Workshop Enschede, March 2004
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;
Sheet 15MDA Workshop Enschede, March 2004
Example: Relational Model (1)
Metamodel of relational schemas and its instances
Sheet 16MDA Workshop Enschede, March 2004
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
Sheet 17MDA Workshop Enschede, March 2004
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;
Sheet 18MDA Workshop Enschede, March 2004
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;
Sheet 19MDA Workshop Enschede, March 2004
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}]
Sheet 20MDA Workshop Enschede, March 2004
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
Sheet 21MDA Workshop Enschede, March 2004
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]
Sheet 22MDA Workshop Enschede, March 2004
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}]
Sheet 23MDA Workshop Enschede, March 2004
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;