1.2.1 An Overview of the MOF

   The Meta Object Facility (MOF) is the OMG’s adopted technology for defining metadata and representing it as CORBA objects. Metadata is a general term for data that in some sense describes information. The information so described may be information represented in a computer system; for example, in the form of files, databases, running program instances, and so on. Alternatively, the information may be embodied in some system, with the metadata being a description of some aspect of the system such as a part of its design.

   The MOF supports any kind of metadata that can be described using Object Modeling techniques. This metadata may describe any aspect of a system and the information it contains, and may describe it to any level of detail and rigor depending on the metadata requirements.

   The term model is generally used to denote a description of something from the real world. The concept of a model is highly fluid, and depends on one’s point of view. To someone who is concerned with building or understanding an entire system, a model would include all of the metadata for the system. On the other hand, most people are only concerned with certain components (for example, programs A and B) or certain kinds of detail (for example, record definitions) of the system.

   In the MOF context, the term model has a broader meaning. Here, a model is any collection of metadata that is related in the following ways:

• The metadata conforms to rules governing its structure and consistency; that is, it has a common abstract syntax.

• The metadata has meaning in a common (often implied) semantic framework.

   Metadata is itself a kind of information, and can accordingly be described by other metadata. In MOF terminology, metadata that describes metadata is called metametadata, and a model that consists of meta-metadata is called a metamodel.

   One kind of metamodel plays a central role in the MOF. An MOF metamodel defines the abstract syntax of the metadata in the MOF representation of a model. Since there are many kinds of metadata in a typical system, the MOF framework needs to support many different MOF metamodels. The MOF integrates these metamodels by defining a common abstract syntax for defining metamodels. This abstract syntax is called the MOF Model and is a model for metamodels; that is, a meta-metamodel. The MOF metadata framework is typically depicted as a four layer architecture as shown in Table 1-1.

   Table 1-1 OMG Metadata Architecture

   Some points on OMG and MOF metadata terminology:

• To make things easier to understand, we often describe things in terms of their level in the meta-stack; for example, the MOF Model is an M3-level model in a 4 level stack.

• The “meta-? prefix should be viewed in a relative rather than absolute sense. Similarly, the numbering of meta-levels is not absolute.

• While there are typically four layers in an MOF-based metadata stack, the number of layers can be more or less than this.

   The MOF specification has three core parts; that is, the specification of the MOF Model, the MOF IDL Mapping, and the MOF’s interfaces.

   The “MOF Model? is the MOF’s built-in meta-metamodel. One can think of it as the “abstract language? for defining MOF metamodels. This is analogous to the way that the UML metamodel is an abstract language for defining UML models. While the MOF and UML are designed for two different kinds of modeling; that is, metadata versus object modeling, the MOF Model and the core of the UML metamodel are closely aligned in their modeling concepts. (The alignment of the two models is close enough to allow UML notation to be used to express MOF-based metamodels!)

   The three main metadata modeling constructs provided by the MOF are the Class, Association, and Package. These are similar to their counterparts in UML, with some simplifications:

• Classes can have Attributes and Operations at both “object? and “class? level. Attributes have the obvious usage; that is, representation of metadata. Operations are provided to support metamodel specific functions on the metadata. Both Attributes and Operation Parameters may be defined as “ordered,? or as having structural constraints on their cardinality and uniqueness. Classes may multiply inherit from other Classes.

• Associations support binary links between Class “instances.? Each Association has two AssociationEnds that may specify “ordering? or “aggregation? semantics, and structural constraints on cardinality or uniqueness. When a Class is the type of an AssociationEnd, the Class may contain a Reference that allows navigability of the Association’s links from a Class “instance.?

• Packages are collections of related Classes and Associations. Packages can be composed by importing other Packages or by inheriting from them. Packages can also be nested, though this provides a form of information hiding rather than reuse.

   The other significant MOF Model constructs are DataTypes and Constraints. DataTypes allow the use of non-object types for Parameters or Attributes. In the OMG MOF specification, these must be data types or interface types expressible in CORBA IDL.

   Constraints are used to associate semantic restrictions with other elements in an MOF metamodel. This defines the well-formedness rules for the metadata described by a metamodel. Any language may be used to express Constraints, though there are obvious advantages in using a formal language like OCL.

   The MOF’s “IDL Mapping? is a standard set of templates that map an MOF metamodel onto a corresponding set of CORBA IDL interfaces. If the input to the mapping is the metamodel for a given kind of metadata, then the resulting IDL interfaces are for CORBA objects that can represent that metadata. The mapped IDL are typically used in a repository for storing the metadata.

   The IDL mapping is too large to describe here, and indeed it is largely irrelevant to the problem of model interchange. Instead, we will simply note the main correspondences between elements in a MOF metamodel (M2-level entities) and the CORBA objects that represent metadata (M1-level entities):

• A Class in the metamodel maps onto an IDL interface for metadata objects and a metadata class proxy. These interfaces support the Operations, Attributes, and References defined in the metamodel, and in the case of class proxy, provide a factory operation for metadata objects.

• An Association maps onto an interface for a metadata association proxy that supports association queries and updates.

• A Package maps onto an interface for a metadata package proxy. A package proxy acts as a holder for the proxies for the Classes and Associations contained by the Package, and therefore serves to define a logical extent for metadata associations, classifier level attributes and the like.

   The IDL that is produced by the mapping is defined in precise detail so that different vendor implementations of the MOF can generate compatible repository interfaces from a given MOF metamodel. Similarly, the semantic specification of the mapped interfaces allows metadata objects to be interoperable.

   In addition to the metamodel specific interfaces for the metadata (defined by the IDL mapping), MOF metadata objects share a common set of Reflective base interfaces. These interfaces allow a ‘generic’ client program to access and update metadata without either being compiled against the metamodel’s generated IDL or having to use the CORBA DII.

   The final component of the MOF specification is the set of IDL interfaces for the CORBA objects that represent an MOF metamodel. These are not of interest to the meta-modeler who will typically use vendor supplied graphical editors, compilers and generator tools to access an MOF Model repository. However, they are of interest to MOF-based tool vendors, and to programmers who need to access metadata using the Reflective interfaces.

   In fact, there is not a lot to say about these interfaces, except to explain how they were derived. In the MOF specification, the MOF Model is defined using the MOF Model as its own modeling language; that is, it is the “fixed point? of the metadata stack. Conceptually, the MOF Model is M3 level metadata conforming to an M4 level metamodel that is isomorphic to the MOF Model. The IDL mapping is then applied to this metamodel (or strictly speaking meta-metamodel) to produce the MOF Model’s IDL interfaces. Likewise, the MOF Model IDL’s operational semantics are largely defined by the mapping and the OCL constraints in the MOF Model specification.