7.3 The Structure of the MOF Model

   This sub clause gives an overview of the structure of the MOF Model.

   The MOF Model, as it is currently defined, consists of a single non-nested Package called “Model.? This Package explicitly imports the “PrimitiveTypes? Package so that it can use the “Boolean,? “Integer,? and “String? PrimitiveType instances.

   The class diagram in Figure 7.2 on page 39 shows the Classes and Associations of the “Model? Package. To aid readability, Class features, Association End names, DataTypes, and other details have been omitted from the diagram. These details are all specified in later sub clauses of this clause.

   NOTE: This diagram (like other UML diagrams in this clause) is non-normative.

   Figure 7.1 - The MOF Model Package

   The “Model? Package is used to generate the CORBA IDL for the OMG MOF Model service using the MOF to IDL Mapping defined in the “MOF Abstract Mapping? clause through the “Reflective Module? clause. Relevant fragments of the resulting IDL is embedded in the Class, Association, DataType, and Exception descriptions in 7.4, “MOF Model Classes,? on page 41 through 7.7, “MOF Model Exceptions,? on page 99.

   The IDL for the MOF Model service requires a “prefix? of “org.omg.mof.? To this end, the “Model? Package is defined to have an “idl_prefix? Tag with value “org.omg.mof.?

   The IDL for the MOF Model services requires the “Attribute? and “Exception? elements to have IDL names “MofAttribute? and “MofException? respectively to avoid collision with IDL keywords. To this end, the “Attribute? Class and “Exception? Class have ‘idl_alternate_name? Tags with the values “MofAttribute? and “MofException? respectively.

    The core structure of the MOF Model is shown in the class diagram in Figure 7.2. This diagram shows the key abstract Classes in the MOF Model and the key Associations between them.

   The key abstract Classes in the MOF Model are as follows:

• ModelElement - this is the common base Class of all M3-level Classes in the MOF Model. Every ModelElement has a “name.?

• Namespace - this is the base Class for all M3-level Classes that need to act as containers in the MOF Model.

• GeneralizableElement - this is the base Class for all M3-level Classes that support “generalization? (i.e., inheritance).

• TypedElement - this is the base Class for M3-level Classes such as Attribute, Parameter, and Constant whose definition requires a type specification.

• Classifier - this is the base Class for all M3-level Classes that (notionally) define types. Examples of Classifier include Class and DataType.

   The key Associations in the MOF Model are as follows:

• Contains - this Association relates a ModelElement to the Namespace that contains it (see 7.3.4, “The MOF Model Containment Hierarchy,? on page 40).

• Generalizes - this Association relates a GeneralizableElement to its ancestors (i.e., supertypes) and children (i.e., subtypes) in a model element inheritance graph. Note that a GeneralizableElement may not know about all of its subtypes.

• IsOfType - this Association relates a TypedElement to the Classifier that defines its type.

• DependsOn - this derived Association relates a ModelElement to others that its definition depends on. (It is derived from Contains, Generalizes, IsOfType, and other Associations not shown here.)

   Figure 7.2 - The Key Abstractions of the MOF Model

   The most important relationship in the MOF Model is the Contains Association. Containment is a utility Association that is used to relate (for example) Classes to their Operations and Attributes, Operations to their Parameters, and so on. While the class diagram shows that only ModelElement objects that are subtypes of Namespace can contain any other ModelElements, the MOF Model restricts the legal containments to eliminate various nonsensical and problematical cases.

    Table 7.4 shows the legal ModelElement containments in matrix form. The rows are the non-abstract subtypes of Namespace (i.e., possible containers) and the columns are the non-abstract subtypes of ModelElements (i.e., possible contained elements). For each combination of container and contained, a “Y? says that containment is legal and an “N? says that it is not.

   NOTE: The normative specification of the containments rules is in the OCL rules

    Table 7.4 summarizes the OCL containment rules..

   Table 7.4 - The ModelElement Containment Matrix

   NOTE: While the MOF Model allows Classes to contain Classes, the MOF to IDL mapping does not support this. Any metamodel in which Classes are nested inside Classes must be considered as not technology neutral.

   © ISO/IEC 2005 - All rights reserved