Sheet 1MDAFA2004 Linköping, June 2004
A Language for
Model Transformations in
the MOF Architecture
Ivan Kurtev, Klaas van den Berg
University of Twente, the Netherlands
Sheet 2MDAFA2004 Linköping, June 2004
Outline
Transformation scenarios; Limitations in current transformation
languages; Uniform representation of model elements
in MOF; Operations in model transformations; Instantiation and Generalization
mechanisms; Conclusions;
Sheet 3MDAFA2004 Linköping, June 2004
Transformation Scenarios
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
TransformationExecution
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 4MDAFA2004 Linköping, June 2004
Transformation Scenarios
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 5MDAFA2004 Linköping, June 2004
Transformation Techniques 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 6MDAFA2004 Linköping, June 2004
Transformation Techniques
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;
Sheet 7MDAFA2004 Linköping, June 2004
Transformation Techniques
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 8MDAFA2004 Linköping, June 2004
Transformation Techniques
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?
Sheet 9MDAFA2004 Linköping, June 2004
Approach
Two basic ideas: Represent model elements at
any level of MOF in a uniform way;
Study the impact of instantiation and generalization over a transformation language;
Transformation Language: Operates on the generic
representation; Specifies different
instantiation mechanisms as transformations;
MOF
a Meta-model
a Model
Instances
MOFR
a Meta-modelR
a ModelR
InstancesR
GenericModel
MOFArchitecture
GenericRepresentation
instanceOf
instanceOf
instanceOf
Sheet 10MDAFA2004 Linköping, June 2004
Structure of Model Elements
MOF architecture is a space of model elements; Elements have identity and named slots; This structure is applicable to model elements at any level of
the MOF architecture;
ModelElement
+name
Slot
+value
Literal
1
+slots
1..*
*+value0..*
+slot
Sheet 11MDAFA2004 Linköping, June 2004
Example: MOF Model Representation
Simplified MOF Model
Primitive data types and multiplicity are skipped
Sheet 12MDAFA2004 Linköping, June 2004
MOF Model represented as a set of model elements
Example: MOF Model Representation
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 13MDAFA2004 Linköping, June 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 14MDAFA2004 Linköping, June 2004
Example: Relational Model
Metamodel of relational schemas and its instances
Sheet 15MDAFA2004 Linköping, June 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
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
instanceOf
RelationalSchemaFieldType
instanceOfMOF
instanceOfMOF instanceOfMOF
Tuple Field
instanceOfMOFinstanceOfMOF
instanceOfMOF
instanceOf
instanceOf
Sheet 16MDAFA2004 Linköping, June 2004
Transformation Language
Models are sets of model elements; Transformations operate on the generic representation
of models; Two types of transformation 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 17MDAFA2004 Linköping, June 2004
Modeling Instantiation and Generalization The four operations are affected by instantiation and
generalization mechanisms; Operations rely on a set of primitive functions that implement
various aspects of instantiation and generalization;
Selection Instantiation Slot Access Slot Assignment
meta
getSpecializedConstructs
instantiategetSlotValue
setValue
isCompatible
Instantiation Generalization
transformationoperations
functions
languageconcepts
Sheet 18MDAFA2004 Linköping, June 2004
Modeling Instantiation
Selection: meta(me: ModelElement): ModelElementReturns the meta-construct of a model element
Instantiation: instantiate(meta-construct: ModelElement) : ModelElementCreates an instance of a meta-construct
Slot Access: getSlotValue(me: ModelElement, slotName: String) : Set of ModelElement
Slot Assignment: setValue(me: ModelElement,
slotName: String, slotValue: Set of ModelElement)
Sheet 19MDAFA2004 Linköping, June 2004
Modeling Generalization
Selection: getSpecializedConstructs(me: ModelElement) : Set of
ModelElementUsed for selection on the base of sub-types;
Instantiation: instantiate(meta-construct: ModelElement) : ModelElement Contains knowledge about inheritance
Slot assignment: isCompatible(expectedType: ModelElement, actualtype: ModelElement): Boolean Used to perform type checking
Sheet 20MDAFA2004 Linköping, June 2004
Specifying Transformations
The 6 functions have different implementations for different modeling languages;
Before executing a transformation, the transformation engine is configured with function implementations:
Meta model andConfiguration
Meta model andConfiguration
SourceModel
TargetModel
TransformationEngine
TransformationSpecification
instanceOf instanceOf
based onbased on
input output
executed byinput input
Sheet 21MDAFA2004 Linköping, June 2004
Example: Instantiating Model Elements
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 InstantiationMOFClassInstantiation 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 22MDAFA2004 Linköping, June 2004
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 MOF instantiation
Example: Instantiating Model Elements
Sheet 23MDAFA2004 Linköping, June 2004
Conclusions
The approach enhances the scope of transformations beyond the QVT scenario;
Requires explicit definition of part of a modeling language semantics concerning instantiation and generalization;
Future work: automatically derive transformations over more than one level (the Data Binding Scenario);