Browse Prior Art Database

Extending the MOF meta-model to support definition of mappings between models

IP.com Disclosure Number: IPCOM000035210D
Original Publication Date: 2005-Jan-20
Included in the Prior Art Database: 2005-Jan-20
Document File: 4 page(s) / 64K

Publishing Venue

IBM

Abstract

Disclosed is a method of extending the Object Management Group (OMG) Meta-Object Facility (MOF) 2.0 standard [*] meta-model in order to support the definition of mappings between MOF 2.0 compliant models. Mappings defined in this way can be used by tools to automatically generate or check mappings between model elements.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 55% of the total text.

Page 1 of 4

Extending the MOF meta-model to support definition of mappings between models

Disclosed is a method of extending the Object Management Group (OMG) Meta-Object Facility (MOF) 2.0 standard [*] meta-model in order to support the definition of mappings between MOF 2.0 compliant models. Mappings defined in this way can be used by tools to automatically generate or check mappings between model elements.

    A relationship between model elements can be represented as one object (representing the relationship) with references to the objects that are related. The relationship object is itself a model element, so the kinds of relationships that are possible can be defined as a set of meta-classes for the relationships. e.g.:

<<relation>>

UMLClass2Ecore

(f rom u ml2e core)

<<equals>> name

Clas s

(f rom u ml )

+uml

1

1

+ec ore

EClass

(from eco re)

Figure 1

    An instance of a relation class can represent a mapping between model elements.

    However, on its own a relation class does not specify sufficiently how a mapping should be constructed. It is not possible to automatically create a set of mappings between model elements without further information (i.e.: in Figure 1, there is no indication of which Class should be mapped to which EClass).

    Model transformation languages based on this approach may use various different ways to add the additional information required - usually in the form of expressions, constraints, and properties of the relation class.

    Because relation classes are MOF classes, properties of the relation class may be defined, and this allows one relation object to contain or reference other relation objects, e.g.:

[This page contains 4 pictures or other non-text objects]

Page 2 of 4

<<relation>>

0..*

UMLClass 2Ec ore

<<equals>> name

(from uml2ecore)

Class

(from uml)

+uml

1 <<parameter>> 1

+ecore

1

EClass

(from ecore)

<<parameter>>

1

+features

0..*

0..*

Feature

(from uml)

+attrs

0..*

         0..* +attributes

0..*

Attribute

(from uml)

<<relation>>

Attr2EAttr

(from uml2ecore)

<<parameter>>

<<parameter>>

EAttribute

(from ecore)

1 +uml 1

     1 +ecore 1

Figure 2

    Figure 2 is a UML diagram, expressing the concept that an instance of the relation UMLClass2Ecore could contain many instances of the relation Attr2EAttr.

    Given that this relationship has been defined between the classes UMLClss2Ecore and Attr2EAttr, it might naturally be assumed that the Attr2EAttr relation instances contained by the UMLClass2Ecore instance are not mapping any arbitrary Attribute and EAttribute instances, but are in fact relating attributes that are contained by the classes that are mapped by the containing UMLClass2Ecore instance. However this piece of information is not in the diagram (Figure 2) and could not be automatically deduced by a tool.

    To add this additional information it is necessary to extend the MOF 2.0 meta-model in some way. The method disclosed in this article is to define a new kind of Property (here called a Correspondence) that may be used to represent m...