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

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;

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

Sheet 13MDAFA2004 Linköping, June 2004 Multiple InstanceOf Relations  InstanceOf MOF – linguistic (physical) instantiation;  InstanceOf Java – 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 InstanceOf MOF ;  The second is ontological, based on InstanceOf REL ; Example: Relational Model

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; SelectionInstantiationSlot AccessSlot Assignment meta getSpecializedConstructs instantiate getSlotValue setValue isCompatible InstantiationGeneralization transformation operations functions language concepts

Sheet 18MDAFA2004 Linköping, June 2004 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)

Sheet 19MDAFA2004 Linköping, June 2004 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

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:

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 Instantiation 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 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);