6.2 Metadata Architectures

   The central theme of the MOF approach to metadata management is extensibility. The aim is to provide a framework that supports any kind of metadata, and that allows new kinds to be added as required. In order to achieve this, the MOF has a layered metadata architecture that is based on the classical four layer metamodeling architecture popular within standards communities such as ISO and CDIF. The key feature of both the classical and MOF metadata architectures is the meta-metamodeling layer that ties together the metamodels and models.

   The traditional four layer metadata architecture is briefly described below. This is followed by a more detailed description of how this maps onto the MOF metadata architecture.

   The classical framework for metamodeling is based on an architecture with four meta- layers. These layers are conventionally described as follows:

• The information layer is comprised of the data that we wish to describe.

• The model layer is comprised of the metadata that describes data in the information layer. Metadata is informally aggregated as models.

• The metamodel layer is comprised of the descriptions (i.e., meta-metadata) that define the structure and semantics of metadata. Meta-metadata is informally aggregated as metamodels. A metamodel is an “abstract language? for describing different kinds of data; that is, a language without a concrete syntax or notation.

• The meta-metamodel layer is comprised of the description of the structure and semantics of meta-metadata. In other words, it is the “abstract language? for defining different kinds of metadata.

    The classical four layer meta-modeling framework is illustrated in Figure 6.1 on page 10. This example shows metadata for some simple records (i.e., “StockQuote? instances) along with the “RecordTypes? metamodel for describing and the hard-wired meta-metamodel that defines the metamodeling constructs (e.g., meta-Classes and meta-Attributes).

   While the example shows only one model and one metamodel, the main aim of having four meta-layers is to support multiple models and metamodels. Just as the “StockQuote? type describes many StockQuote instances at the information level, the “RecordTypes? metamodel can describe many record types at the model level. Similarly, the meta-metamodel level can describe many other metamodels at the metamodel that in turn represent other kinds of metadata describing other kinds of information.

   Hard-wired Meta-metamodel

   MetaModel ( “RecordTypes?, MetaClass ( “Record?,[ MetaAttr ( “name?, String),metamodel MetaAttr ( “fields?, List < “Field?> ) ] MetaClass ( “Field?, ... )

   Record ( “StockQuote?, [ Field ( “company?, String ) model Field ( “price?, FixedPoint ) ] )

   StockQuote (“Sunbeam Harvesters?, 98.77)StockQuote (“Ace Taxi Cab Ltd?, 12.32)

   information

   ...

   Figure 6.1 - Four Layer Metadata Architecture

   The classical four layer metadata architecture has a number of advantages over simple modeling approaches. If the framework is designed appropriately, it can:

• support any kind of model and modeling paradigm that is imaginable,

• allow different kinds of metadata to be related,

• allow metamodels and new kinds of metadata to be added incrementally, and

• support interchange of arbitrary metadata (models) and meta-metadata (metamodels) between parties that use the same meta-metamodel.

   The MOF metadata architecture1 , illustrated by the example in Figure 6.2, is based on the traditional four layer metadata architecture described above. This example shows a typical instantiation of the MOF metadata architecture with metamodels for representing UML diagrams and OMG IDL.

   1. One could argue that the term “architecture? is an inappropriate in this context. After all, the MOF metadata “architecture? is little more than a way of conceptualizing relationships between data and descriptions of data. Certainly, there is no intention the “architecture? be used as a benchmark for MOF conformance. However, the term has been used in MOF discussion for a long time, so the reader must forgive any perceived inaccuracy.

   Figure 6.2 - MOF Metadata Architecture

   The MOF metadata architecture has a few important features that distinguish it from earlier metamodeling architectures:

• The MOF Model (the MOF’s core meta-metamodel) is object-oriented, with metamodeling constructs that are aligned with UML’s object modeling constructs. Hence, the example uses UML package icons to denote MOF-based metamodels as well as UML models.

• The meta- levels in the MOF metadata architecture are not fixed. While there are typically 4 meta-levels, there could be more or less than this, depending on how MOF is deployed. Indeed, the MOF specification does not require there to be discrete meta- levels at all at the implementation level. MOF meta- levels are purely a convention for understanding relationships between different kinds of data and metadata.

• A model (in the broad sense of a collection of metadata) is not necessarily limited to one meta-level. For example, in a data warehousing context, it may be useful to think of the meta-schema “Relational Table? and specific schemas that are instances of relational tables as being one conceptual model.

• The MOF Model is self-describing. In other words, the MOF Model is formally defined using its own metamodeling constructs. Hence, the MOF Model is also denoted by a UML style Package icon.

   The self-describing nature of the MOF Model has some important consequences:

• It shows that the MOF Model is sufficiently expressive for practical metamodeling.

• It allows the MOF’s interfaces and behavior to be defined by applying the MOF IDL mapping to the MOF Model. This provides uniformity of semantics between computational objects that represent models and metamodels. It also means that when a new technology mapping is defined, the APIs for managing metamodels in that context are implicitly defined as well.

• It provides an architectural basis for extensions and modifications to the MOF Model. Successive MOF RTFs have thus been able to make incremental changes in the MOF Model to address problems that become apparent. In the future, new meta-metamodels may be added to support tasks like specification of modeling notations and model-tomodel transformations.

• Given an appropriate set of implementation generators, it allows new MOF metamodel repository implementations and associated tools to be created by bootstrapping.

   There is enormous scope for confusion if standard metamodeling terminology is used in the MOF specification. To avoid this and to make it easier to read, we have opted to simplify the terminology. Some particular points of confusion are as follows:

• Since the number of MOF meta-levels is not fixed and meta-levels are conventionally named upwards from the “information? layer, the “top? meta-level of the stack varies. Some people find this idea hard to grasp.

• There are a number of object modeling concepts that appear at two, three, or even four levels in a well populated MOF metadata framework. For example, a class in a UML is described by an instance of the class “Class? in the UML metamodel. This is in turn described by an instance of the class “Class? in the MOF Model. Finally, the class “Class? in the MOF Model is described by itself. This overloading of names of concepts often confuses people.

• While the “meta-? prefix has a clear meaning in the context of the MOF, evidence suggests that people who encounter it for the first time find it very confusing. This is particularly the case for forms like “meta-meta-? and “meta-metameta-?. Even for seasoned experts, “meta-meta-meta-? is cumbersome in conversation.

   To avoid some of this confusion, we generally try to avoid using the “meta-? prefix. In particular, while the core of the MOF is a meta-metamodel (assuming that there are 4 meta- layers), it is referred to as “the MOF Model.? Similarly, rather than using terms like Class, MetaClass, and MetaMetaClass, we use phraseology like “an M1-level instance of an M2level Class.?

   The meta-level numbering used in the remainder of this specification (for example, M2-level or M1-level) should be read as top down labels relative to the MOF Model at M3-level. We assume that the reader can mentally relabel the meta-levels to fit the context; for example, in contexts where the MOF Model is not at M3-level, or when applying the IDL mapping to the MOF Model itself.

   NOTE: Even the M1- / M2- terminology above has proved to be confusing to some readers. However, since changing the terminology again will take significant effort and cause considerable disruption, further work on this has been deferred until a clearly superior terminology is proposed.

   There are three cases where it is convenient to use the “meta-? prefix as part of MOF terminology:

1. The term “metadata? is used to refer to data whose purpose is to describe other data.

2. The term “metamodel? is used to refer to a model of some kind of metadata.

3. The term “metaobject? is used to refer to an abstract or technology specific object that represents metadata.

   In each case, the term is used across all meta-levels and has a deliberately imprecise meaning.

   The core modeling concepts in the MOF use terms that are also used in UML with similar meanings. For example, a MOF Class corresponds to a UML Class, a MOF Attribute corresponds to a UML Attribute, and a MOF Association corresponds to a UML Association. However the correspondence is not always a direct match. For example, UML Associations may have many AssociationEnds, but MOF Associations must have precisely two.