MMX Framework relies heavily on the concept of 'lightweight implementation of MOF'. This article will outline the mapping of MOF elements to MMX Framework classes and the principles of implementing MOF models in MMX Repository.
MMX Framework is NOT an academic undertaking run for purely scientific purposes in a closed lab on a desert island. It is being developed and maintained for practical purposes in a very pragmatic manner. Therefore reflecting every single MOF feature and artifact has not been a goal: it is designed with minimal overhead and minimal footprint in mind, hence the term lightweight. Also, MMX Framework is intended as a platform for metadata repository, therefore all behavioral aspects of MOF as well as the Factory Class have been deliberately omitted. Further, as the power of Complete MOF (CMOF) is not required for our purposes we restrict ourselves to the power and expressivness of Essential MOF (EMOF). So, for starters, here's a complete diagram covering EMOF:
M2 layer of MMX physical model consists of just three entities: MD_OBJECT_TYPE, MD_RELATION_TYPE and MD_PROPERTY_TYPE. The centerpiece of the model, MD_OBJECT_TYPE, maps to NamedElement concept of MOF 2.0 (ModelElement in MOF 1.4). Everything derived from NamedElement is mapped to one of the classes in MMX Core Metamodel. The following table lists all EMOF elements with their respective properties and how they are implemented and mapped against MMX data model. The mappings are presented in informal way and are expressed either as MMX data model objects (physical tables, columns) or as MMX Core Metamodel elements (classes, attributes).
| EMOF | MMX implementation | Comments |
| Element | Core::MMXClass | For formal reasons, there's a root class that everything else descends from that corresponds to MOF Element. |
| Tag | Core::Annotation | Root level metaproperty (md_property_type) inherited by any MMX class. |
| +name | md_property_type.property_type_nm | |
| +value | md_property_type.default_value_ds | |
| NamedElement | Core::<any class> | MOF Named Element is mapped to any class on MMX M2 layer |
| +name | md_object_type.object_nm | |
| Class | Core::<any class> | MOF Class is mapped to any class on MMX M2 layer |
| +isAbstract | md_object_type.abstract_class_ind | |
| +ownedAttribute | | Expressed through md_object_type - md_property_type relationship (1:N). |
| +superClass | Core::SuperClass | Root level metarelation (md_relation_type) expressing containment, inherited by any pair of MMX classes |
| +ownedOperation | Not applicable | |
| Package | Core::Metamodel | Package denotes a namespace |
| +uri | md_object_type.reference_ds | Represents namespace URI |
| +nestedPackage | Core::SuperClass | nestedPackage/nestingPackage composition is expressed via a root-level metarelation applicable to any pair of MMX classes. |
| +nestingPackage | Core::SuperClass | see previous |
| +ownedType | Not applicable | Expressed via MOF Type.package property |
| Type | md_object_type.object_type_cd | Type is mapped via its subtypes (Class and DataType) |
| +package | md_object_type.parent_object_type_cd | Package and Class are related via inheritance (parent-child) relationship |
| TypedElement | Not applicable | TypedElement is mapped via its subtype, MultiplicityElement |
| +type | md_property_type.data_type_cd | This attribute is inherited and finally implemented by Property element |
| MultiplicityElement | Not applicable | MultiplicityElement is mapped via its subtype, Property. Other subtypes of MultiplicityElement (Operation and Parameter) are not implemented |
| +isOrdered | Not implemented yet | |
| +isUnique | Not implemented yet | |
| +lower | md.property_type.mandatory_ind | lower = 1 is expressed via mandatory_ind = TRUE. lower = 0 is expressed via mandatory_ind = FALSE |
| +upper | md_property_type.multiplicity_ind | upper > 1 is expressed via multiplicity_ind = TRUE. upper = 1 is expressed via multiplicity_ind = FALSE |
| Property | md_property_type | |
| +isReadOnly | Not implemented yet | |
| +default | md_property_type.default_value_ds | |
| +isDerived | Not implemented yet | |
| +class | md_property_type.object_type_cd | Expressed through md_object_type - md_property_type relationship (1:N) |
| +isID | Not applicable | Everything implemented in MMX data model always has a unique ID, this is built in |
| +isComposite | Not applicable | isComposite denotes hierarchical property. In MMX data model hierarchical properties are expressed via parent-child relations |
| +opposite | Not applicable | opposite applies to MMX relationship types. Associations between MMX properties are not possible |
| DataType | Core::DataType | MOF has 4 primitive types (Boolean, String, Integer and UnlimitedNatural) that are mirrored by corresponding MMX Core data types |
| Enumeration | Core::DataType::Enumeration | Enumeration is a MMX Core data type |
| +ownedLiteral | Not applicable | Expressed via MOF EnumerationLiteral.enumeration property |
| EnumerationLiteral | md_object domain value instances | EnumerationLiteral values are implemented as instances of their corresponding Enumeration class, on M1 level |
| +enumeration | md_object.object_type_cd | Enumerations (Value domains) and EnumerationLiteral values (domain values) are associated via md_object.object_type_cd of instance records referring to their enumeration class record in md_object_type |
| Factory | Not applicable | |
| +package | Not applicable | |
| Operation | Not applicable | |
| +ownedParameter | Not applicable | |
| +raisedException | Not applicable | |
| +class | Not applicable | |
| Parameter | Not applicable | |
| +operation | Not applicable | |
Note. MMX (as well as EMOF) does not support visibilities. All property visibilities expressed in the UML MOF model are ignored and assumed to be public.
The MOF specifies three capabilities that add-on to the modeling constructs from UML Infrastructure:
- Reflection: Allows discovery and manipulation of metaobjects and metadata
- Identifiers: Unambiguously distinguishes objects from each other
- Extension: Allows dynamic annotation of model elements with additional information
As stated in MOF Specification: "In a MOF context, an object's class (i.e it’s metaobject) reveals the nature of the object - its kind, its features. The Reflection Package allows this discovery and manipulation of metaobjects and metadata." MMX supports Reflection through separation of M2 and M1 layers (Classes - Instances, Metaobjects - Objects) and instantiation association (via object_type_cd) between the two. Thus, manipulation and navigation of M1-level instance objects based on knowledge stored on M2 level is made possible.
"An element has an identifier in the context of an extent that distinguishes it unambiguously from other elements." MMX Framework is built on database technology so naturally everything in it has a unique key. Every element (class or instance) has actually two Identifiers: one in the form of a database table key, another as a unique URI. On M2 level the table key is a primary key column (SMALLINT) with unique values, and the URI is constructed based on the location of a class in the overall class hierarchy. On M1 level the table key is a primary key column (INTEGER), construction of the unique URI is the responsibility of an application that creates class instances.
"It is sometimes necessary to dynamically annotate model elements with additional, perhaps unanticipated, information." For dynamical annotation of models (Extension) Tag element of MOF is implemented as a top-level metaproperty of MMX root class. This property gets inherited by any MMX class and can be used to associate a collection of name-value pairs with model elements.
