Unifying Approach

1
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
• Represent model elements at any level of MOF in a
  uniform way
• Decouple the transformation language from
  instantiation mechanism

Single GenericRepresentation

• 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.fieldnameA.
  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 aAttribute
• target Slot namea.name
• MOFAssociationToSlot ModelElementRule
• source assocAssociation
• target Slot nameassoc.to.name

• MOFClassInstantiation ModelElementRule
• source cClass, condition c.isAbstractfalse
  
• target ModelElement slots
• SlotRules
• attributeSlots
• source aAttributec.attributes
• target slots
• associationSlots
• source assocAssociation,
  condition assoc.from.typec
• target slots

20
Instantiating Model Elements (2)

• Relational schema instantiation
• RelSchemaInstantiation ModelElementRule
• source sRelationalSchema
• target Tuplefield, instanceOfRel s
• SlotRules
• Fields
• source fFieldTypes.fieldTypes
• target field
• FieldTypeToField ModelElementRule
• source ftFieldType
• target Fieldnameft.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,
  
  contextNodeTuple
• source fFieldcontextNode.field,
  conditionf.nameslotName
• target SlotnameslotNamef.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 slotNameString,
  newValueModelElement
• source sTuple, fFields.field, condition
  f.nameslotName
• target update f valuenewValue

23
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