1. Model Transformations
Unifying Approach
for
Model Transformations in
the MOF Architecture
Ivan Kurtev, Klaas van den Berg
University of Twente, the Netherlands

2. Outline Transformation scenarios;
Limitations in current transformation languages;
Uniform representation of model elements in MOF;
Transformation language;
Instantiation mechanisms;
Conclusions;

3. Transformation Scenarios (1)
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;

4. Transformation Scenarios (2)
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);

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

6. 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;

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

8. 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?

9. Approach Two basic ideas: Transformation Language:
Represent model elements at any level of MOF in a uniform way;
Decouple the transformation language from instantiation mechanism;
Single Generic Representation
Transformation Language:
Operates on the generic representation;
Specifies different instantiation mechanisms as transformations;

10. 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;

11. Example: MOF Model Representation (1)
Simplified MOF Model
Primitive data types and multiplicity are skipped

12. Example: MOF Model Representation (2)
MOF Model represented as a set of model elements

13. Example: MOF Model Representation (2)
MOF Model represented as a set of model elements

14. Multiple InstanceOf Relations
InstanceOfMOF – linguistic (physical) instantiation;
InstanceOfJava – ontological (logical) instantiation;

15. Example: Relational Model (1)
Metamodel of relational schemas and its instances

16. Example: Relational Model (2)
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;

17. 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;

18. 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;

19. 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):
MOFAttributeToSlot ModelElementRule
source [a:Attribute]
target [Slot {name=a.name}]
MOFAssociationToSlot ModelElementRule
source [assoc:Association]
target [Slot {name=assoc.to.name}]
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}] }

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

21. 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]

22. 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}]

23. Conclusions Transformation language: Future Work:
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;