A Language
for
Model Transformations
in
the MOF Architecture
Ivan Kurtev, Klaas van den Berg
University of Twente, the Netherlands
MDAFA2004
Linköping, June 2004
Sheet 1
Outline
 Transformation scenarios;
 Limitations in current transformation languages;
 Uniform representation of model elements in
MOF;
 Operations in model transformations;
 Instantiation and Generalization mechanisms;
 Conclusions;
MDAFA2004
Linköping, June 2004
Sheet 2
Transformation Scenarios
MOF
M3
M2
UML
Metamodel
M1
a UML
model
M0
User data
Transformation
Definiton
Transformation
Execution
Java
Metamodel
M2
DTD Meta
Model
Java
classes
M1
a DTD
Java
objects
M0
an XML
Document
QVT Scenario
 Transformation specified
between meta models;
 The context of
Query/Views/Transformation
RFP by OMG;
MDAFA2004
MOF
M3
Linköping, June 2004
Relational
Meta Model
Transformation
Definiton
Transformation
Execution
a Relational
Schema
a Relational
Database
Data Transformation Scenario
 Transformation is executed over
concrete data instances at level
M0;
 E.g. Common Warehousing
Metamodel (CWM);
Sheet 3
Transformation Scenarios
MOF
M3
XMI
M3
MOF
JMI
M2
DTD Meta
Model
Transformation
Definiton
Java Meta
Model
M2
DTD Meta
Model
UML Meta
Model
Java Meta
Model
M1
a DTD
Schema
Compilation
Java
Classes
M1
UML DTD
an UML
Model
Java
Classes
M0
an XML
Document
Unmarshaling
Java
Objects
M0
an XML
Document
a Model
Instance
Java
Objects
Data Binding in context of MOF
 Transformation specified at level
M2 is executed twice in lower
levels M1 and M0;
MDAFA2004
Linköping, June 2004
Inter-level Transformations
 XML Metadata Interchange (XMI);
 Java Metadata Interchange (JMI);
Sheet 4
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.
MDAFA2004
Linköping, June 2004
Sheet 5
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;
MDAFA2004
Linköping, June 2004
Sheet 6
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;
MDAFA2004
Linköping, June 2004
Sheet 7
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?
MDAFA2004
Linköping, June 2004
Sheet 8
Approach
Two basic ideas:

MOF
Architecture
Generic
Representation
MOF
MOFR
a Metamodel
a MetamodelR
a Model
a ModelR
Instances
InstancesR
MDAFA2004

Represent model elements at any
level of MOF in a uniform way;
Study the impact of instantiation
and generalization over a
transformation language;
instanceOf
instanceOf
Generic
Model
instanceOf
Linköping, June 2004
Transformation Language:


Operates on the generic
representation;
Specifies different instantiation
mechanisms as transformations;
Sheet 9
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;
0..*
+value
*
+slot
+slots
ModelElement
Slot
1
1..*
+name
Literal
+value
MDAFA2004
Linköping, June 2004
Sheet 10
Example: MOF Model Representation
Simplified MOF Model
Primitive data types and multiplicity are skipped
MDAFA2004
Linköping, June 2004
Sheet 11
Example: MOF Model Representation
M o d E lN a m e A ttr
"tru e "
nam e
"n a m e "
is A b s tra c t
a ttrib u te s
"M o d e l
E le m e n t"
nam e
in s ta n c e O f M O F
M o d e lE le m e n t
"G e n e ra liz a b le
E le m e n t"
nam e
"A ttrib u te "
s u p e rty p e
s u p e rty p e
nam e
G e n e ra liz a b le
E le m e n t
A ttrib u te
in s ta n c e O f M O F
in s ta n c e O f M O F
s u p e rty p e
in s ta n c e O f M O F
"C la s s ifie r"
nam e
C la s s ifie r
in s ta n c e O f M O F
"C la s s "
s u p e rty p e
nam e
C la s s
in s ta n c e O f M O F
MOF Model represented as a set of model elements
MDAFA2004
Linköping, June 2004
Sheet 12
Multiple InstanceOf Relations
M3
MOF Class
MOF Class
instanceOfMOF
instanceOfMOF
M2
JavaClass
instanceOfMOF
M1
JavaClass
instanceOfMOF
instanceOfJava
instanceOfMOF
a Class
a Class
JavaObject
instanceOfMOF
type
an Object
instanceOfJava
M0


an Object
InstanceOfMOF – linguistic (physical) instantiation;
InstanceOfJava – ontological (logical) instantiation;
MDAFA2004
Linköping, June 2004
Sheet 13
Example: Relational Model
Metamodel of relational schemas and its instances
MDAFA2004
Linköping, June 2004
Sheet 14
Example: Relational Model
FieldType
RelationalSchema
instanceOfMOF
instanceOfMOF
"A"
instanceOfMOF
Tuple
Field
instanceOfMOF
instanceOfMOF
Int
"A"
type
name
'123'
instanceOfMOF
f1
ft1
fieldTypes
instanceOf
aSchema
"B"
name
value
name
instanceOf
field
aTuple
name
ft2
name
f2
type
Boolean
instanceOf
"mySchema"
"B"
value
"true"
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;
MDAFA2004
Linköping, June 2004
Sheet 15
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;
MDAFA2004
Linköping, June 2004
Sheet 16
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
meta
instantiate
getSpecializedConstructs
Slot Access
getSlotValue
Slot Assignment
setValue
isCompatible
functions
language
concepts
MDAFA2004
Instantiation
Linköping, June 2004
Generalization
Sheet 17
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)
MDAFA2004
Linköping, June 2004
Sheet 18
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
MDAFA2004
Linköping, June 2004
Sheet 19
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 and
Configuration
based on
Transformation
Specification
based on
Meta model and
Configuration
executed by
input
input
instanceOf
Source
Model
MDAFA2004
instanceOf
input
Transformation
Engine
Linköping, June 2004
output
Target
Model
Sheet 20
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]
MOFAttributeToSlot ModelElementRule
source [a:Attribute]
target [Slot {name=a.name}]
MOFAssociationToSlot ModelElementRule
source [assoc:Association]
target [Slot {name=assoc.to.name}]
associationSlots
source [assoc:Association,
condition {assoc.from.type=c}]
target [slots]
}
MDAFA2004
Linköping, June 2004
Sheet 21
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
MDAFA2004
Linköping, June 2004
Sheet 22
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);
MDAFA2004
Linköping, June 2004
Sheet 23
Descargar

Document