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.