A Language for Model Transformations in the MOF Architecture Ivan Kurtev, Klaas van den Berg

1. A Language 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; • Operations in model transformations; • Instantiation and Generalization mechanisms; • Conclusions;

3. Transformation Scenarios 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 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 • 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 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;

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

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

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

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

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

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

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

14. Example: Relational Model Metamodel of relational schemas and its instances

15. Example: Relational Model 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;

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

17. 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; transformation operations Selection Instantiation Slot Access Slot Assignment meta instantiate setValue getSlotValue getSpecializedConstructs isCompatible functions Instantiation Generalization language concepts

18. Modeling Instantiation • Selection: • meta(me: ModelElement): ModelElement Returns the meta-construct of a model element • Instantiation: • instantiate(meta-construct: ModelElement) : ModelElement Creates 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)

19. Modeling Generalization • Selection: • getSpecializedConstructs(me: ModelElement) : Set of ModelElement Used 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

20. Specifying Transformations • The 6 functions have different implementations for different modeling languages; • Before executing a transformation, the transformation engine is configured with function implementations:

21. 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 Instantiation 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}] target [slots] }

22. Example: Instantiating Model Elements 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

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