David S. Frankel is Director of Advanced Architectures for Genesis Development Corporation of
West Chester, PA. He is a member of the OMG Architecture Board. He can be contacted at
[email protected].
UML IS KNOWN to most people who use it as a standard notation for describing object models.
It is not commonly known that UML has a rigorously defined meta-model.
A high-level view of the UML meta-model (Table 1) reveals three levels we discussed last time:
| Table 1. Levels of Classification. |
| LEVEL |
DESCRIPTION |
ELEMENTS |
| Meta-model Model
User Objects |
The UML meta-model. A model of a specific information domain. Consists of instances of the UML elements. These instances are called meta-objects. Instances of the elements of a model. |
Class, Attribute, Operation, etc. UML Classes: Customer, Policy, etc.
UML Associations: The Association between Customer and Policy, etc. Customer #123, Customer #456, Policy #ABC, Policy #DEF, Association between Customer #123 & Policy #ABC |
The level at which the meta-model is defined. The UML meta-model defines a number of
elements such as Class, Operation, Attribute, Association, etc. We call
each of these elements a meta-class.
The level at which meta-objects are instantiated. Instances of
UML Class represent business entities and processes. For example,
in the insurance industry we would identify Classes such as Customer, Policy,
PolicyReview, etc. Instances of the UML meta-class Association
can be defined among Classes, such as an Association that might be
defined between Customer and Policy.
We call instances of the UML meta-classes meta-objects.
The level at which business objects are instantiated. Instances of UML Classes, such
as instances of the Class Customer, are objects rather than meta-objects.
We call UML object models of particular domains, such as of the insurance industry,
domain object models or simply domain models.
META-MODELS FOR DATABASE SYSTEMS
As we also discussed last time, other meta-models exist, most notably meta-models for database systems.
A database meta-model defines basic elements such as database, table, column,
key, etc. that are used to define specific data models. A data model based on a
typical database meta-model would define specific databases, tables, columns, keys, etc.
BRIDGING DIFFERENT META-MODELS: THE META-OBJECT FACILITY (MOF)
Domain object models and data models are stored in specialized databases called meta-data
repositories, sometimes referred to simply as repositories. Repository administrators
typically would like to manage domain models and data models in a unified fashion, but the
disparate nature of the meta-models on which they are based present a formidable obstacle.
The OMG Meta-Object Facility (MOF) bridges the gap between dissimilar meta-models by providing a
common basis for meta-models. If two different meta-models are both MOF-conformant, then models
based on them can reside in the same repository.
The UML meta-model is based on the MOF standard. UML's MOF conformance is a crucial piece of the OMG's
strategy for supporting integrated repositories.
The MOF was officially approved as an Object Management Group (OMG) standard in late 1997. It defines
a set of constructs that can be used to describe meta-models. It was submitted by Unisys, IBM, Oracle,
and several other companies. OMG rules require the submitters of a successful proposal to produce a
conformant shipping product within 18 months.
HOW THE MOF WORKS
The MOF is independent of CORBA IDL. It has a set of core constructs that are independent of any
standard representation format and has a mapping from the core to IDL.
Basing a meta-model on the MOF entails defining the meta-model in terms of the MOF core constructs.
The UML meta-model is based on the MOF, meaning that its constructs are defined in terms of the MOF
core elements. Applying the MOF-IDL mapping yields, effectively, a representation of the UML meta-model
in IDL.
The existence of this IDL representation of UML means that each element in the UML meta-model has an
IDL description. For example, two elements of the UML meta-model are Class
and Association. The UML specification maps each of these to the MOF core.
In turn, the application of the MOF-IDL mapping yields CORBA IDL for UML Class
and UML Association, as depicted by Figure 1.
Figure 1. The IDL for elements of the UML meta-model are determined by the MOF-IDL mapping.
Whenever we specify an object model, we expect to be identifying classes and associations among the classes.
The MOF core is object-oriented, so it should come as no surprise that MetaClasses
and MetaAssociations are the primary building blocks offered by the MOF core
for describing meta-models. The mapping shown by Figure 1 can be confusing unless it is seen in this light.
From the point of view of the MOF core, UML Class and
UML Association are both instances of the MOF's
MetaClass construct. It is a little tricky to keep track of the fact that what
is an Association from UML's point of view is a
MetaClass from the MOF's point of view. Moreover, there is
a MetaAssociation between UML Class and
UML Association, which we call Class-Association! The
IDL mapping rules produce IDL of a somewhat different character for instances of
MetaAssociation than they do for instances of
Meta-Class.
Assume that an analyst uses a MOF-compliant UML tool to define a Class
called Policy and a Class
called Customer. The tool would store the Policy
and Customer Classes in its repository as meta-objects that expose the CORBA
IDL for Class, as shown by Figure 2. Assume further that an
Association named "Protects" between
Policy and Customer is defined. The tool
would store the Association in its repository as a meta-object that
exposes the CORBA IDL for Association, as also illustrated by Figure 2.
Figure 2. Storing a UML-based domain model in a MOF-compliant repository.
Now, remember the MetaAssociation Class-Association from Figure 1?
Class-Association is an element of the UML meta-model. There are two
instances of it in the repository shown in Figure 2. The first one represents the
Class-Association Policy-Protects—in other words the relationship between
the UML Class Policy and the UML Association Protects!
The second one, Customer-Protects, represents the relationship between
Customer and Protects. You may have to go
over this a few times before it really sinks in.
Thus, the UML-MOF and MOF-IDL mappings allow UML-based domain models to be stored as sets of meta-objects
that expose industry-standardized CORBA IDL interfaces.
A JAVA CONNECTION
Because CORBA IDL has Java bindings, the IDL interfaces for the UML elements can be implemented in Java.
Thus, the meta-objects can be Java-based CORBA objects, as depicted by Figure 2. Because CORBA IDL also
has bindings to other programming languages, the meta-objects can also be CORBA objects programmed in
other languages. Regardless of the language in which CORBA objects (and thus our meta-objects) are
programmed they can be accessed by CORBA clients written in Java.
THE FOUR META-LEVELS
The MOF essentially adds a fourth meta-level to the classification system described earlier. The MOF calls
these levels M0, M1, M2, and M3, as indicated in
Table 2.
| Table 2. The four meta-levels. |
| LEVEL |
DESCRIPTION |
ELEMENTS |
| "M3" MOF Core "M2" Meta-Model
"M1" Model
"M0" User Objects
or User Data |
Defines the elements used to specify meta-models.
A meta-model defined in terms of the MOF core elements. Consists of MetaClasses, MetaAttributes, etc.
A model expressed in terms of a meta-model. Models a specific information domain. Consists of instances of the elements of a meta-model (i.e., meta-objects). Instances of the elements of a model. |
MetaClass, MetaAttribute, MetaAssociation Mof::Class, Mof::Attribute, Mof::Association
UML: Class, Attribute, Operation Data Warehousing: Database, table, row
UML Classes: Customer, Policy UML Associations: Protects Data Warehousing Table: Policy Data Warehousing Row: Address
Customer #123, Customer #456, Policy #ABC, Policy #DEF, Association between Customer #123 & Policy #ABC
|
OTHER MOF-COMPLIANT META-MODELS
The OMG has issued an RFP for a common meta-model for data warehousing. This meta-model will be
MOF-compliant. It will surely define elements such as database, table, row, etc.,
as well as the associations among these elements.
Figure 3 shows how the data warehousing meta-model will be defined in terms of the MOF core elements and
how the MOF-IDL mapping will be applied to derive the CORBA IDL interfaces for the elements of the meta-model.
Figure 4 shows how a particular data model expressed in terms of the MOF-compliant data warehousing meta-model
will be stored in a MOF-compliant repository and accessed by clients.
Figure 3. The IDL for elements of the data warehousing meta-model will be determined by the MOF-IDL
mapping.
Figure 4. A data model stored in a MOF-compliant repository.
THE COMMON GROUND
The fact that the IDL representation of the data warehousing meta-model will be derived via the same MOF-IDL
mapping that was used to derive the IDL for UML means that there will be commonalities among meta-objects
comprising domain object models on the one hand and meta-objects comprising data models on the other.
These commonalities will allow MOF-based repositories to manage domain object models and data models
in an integrated fashion.
For example, the MOF-IDL mapping dictates that all meta-object interfaces derive from a common set of
interfaces called the Reflective interfaces. The Reflective interfaces allow a tool that does
not know the meta-model on which a model is based to probe and iteratively discover the structure of
the model.
Furthermore, the common design pattern of the meta-model-specific interfaces derived via the mapping makes
it easy for tools that know about one meta-model to be upgraded to know about another meta-model. If a
tool knows the UML meta-model, for example, it can read and manipulate UML-based domain models more
intelligently than can a generic MOF tool. It will be much easier to upgrade a UML-aware tool to
understand a MOF-based data warehousing meta-model than it would be for it to support a non-compliant
meta-model.
The MOF also specifies interfaces to a repository. These interfaces are called the Facility
interfaces. The Facility interfaces allow a repository client to interact at the repository level—that
is, they provide a standard means for a client to get a first reference to a repository at the highest
level and to get a high-level picture of its contents. The client, in turn, can use the Reflective
and/or meta-model-specific interfaces to browse the repository. (This scenario contrasts with another
common one in which a client asks an object for a meta-object that describes its structure and behavior.
In that case the client gets a reference to a meta-object deep within the repository structure without
having to start at the top level.)
The Reflective interfaces inherited by all meta-objects, the common design pattern of specific interfaces
for particular meta-models and the Facility interfaces together form the foundation on which we can build
or use repositories that integrate domain object models and data models as illustrated by Figure 5.
Figure 5. An integrated meta-data repository.
The MOF supports standard object principles of substitutability and encapsulation. Therefore, the MOF
enables separate but compliant meta-models to be integrated. One meta-model can subclass elements of
other meta-models and associations can be established between elements of different meta-models, all
without changing the existing meta-models.
Integrated repositories based on a common architecture for meta-models already exist, but none are as
yet MOF-compliant. Repository vendors that submitted the MOF specification to the OMG are currently
upgrading their products to conform to the MOF.
XML META-DATA INTERCHANGE
The OMG has issued an RFP for a Stream-Based Model Interchange Format (SMIF). Unisys, IBM, Oracle, and
others responded with the XMI proposal. XMI takes advantage of the independence of the MOF core from
any particular representation format such as IDL. It defines a mapping from the MOF core to XML Data
Type Dictionary (DTD) format.
Just as the MOF-IDL mapping provides a formula for deriving the IDL for all of the constructs of a
MOF-compliant meta-model, XMI provides a formula for deriving an XML DTD representing the constructs
of a MOF-compliant meta-model.
With an industry-standardized MOF-XML mapping coming into place, all MOF-based domain meta-models can
apply this mapping to produce an XML DTD representing their elements. Figure 6 demonstrates the application
of the mapping to the UML meta-model.
Figure 6. The MOF-XML mapping maps elements of the UML meta-model to XML DTD elements.
A MOF-compliant tool can thus represent and stream a UML-based domain model in the form of XML whose
structure is dictated by an industry-standardized XML DTD (Figure 7). The intention of the XMI
submitters is that XML be used to import and export models to and from a persistent repository.
Some developers are using XML text files as repositories, but employing unparsed XML text files
as online repositories might not scale as the number and size of models in large enterprises grows.
Figure 7. The MOF-XML mapping specifies how to represent UML-based domain models in XML.
Deriving the XML DTD for the meta-objects via the MOF enhances interoperability between IDL-based meta-objects
on the one hand, and XML representations of meta-objects on the other. The XMI submission to the SMIF RFP
not only defines the MOF-XML mapping, but also applies that mapping to the UML meta-model. Thus, one of
the submission's appendixes contains a complete XML DTD for the UML meta-model.
The XMI's MOF-XML DTD mapping will also be applied to the emerging OMG-standard data warehousing meta-model
to define the DTD for XML streams that could be used to import and export compliant data models into and
out of repositories in a MOF-compliant fashion.
A REPOSITORY FULL OF ENTERPRISE JAVABEANS?
Because it is possible to map the independent MOF-core to many different representation formats, a
mapping from MOF to Enterprise JavaBean (EJB) interfaces is a logical next step. Such a mapping
would make it possible to implement MOF-compliant meta-objects as EJBs in a standard, interoperable
manner. Thus, UML-based domain models as well as data models could be stored as sets of meta-objects
implemented as EJBs.
With an industry-standardized MOF-EJB mapping in place, all MOF-based meta-models could apply this
mapping to produce EJB interfaces representing their elements. The OMG specification for UML (Figure 8)
could be updated to contain the EJB interfaces and the data warehousing meta-model specification could
likewise define EJB interfaces derived via the mapping.
Figure 8. An MOF-EJB mapping would determine the EJB interfaces representing the UML meta-model.
A MOF-compliant tool could thus store a UML-based object model by populating a repository with meta-objects
exposing industry-standardized EJB interfaces, as illustrated by Figure 9. Of course the repository
could also hold data models exposing the EJB interfaces derived by applying the mapping to the data
warehousing meta-model.
Figure 9. An UML-based domain model stored in a MOF-compliant repository as a set of EJBs.
Deriving the EJB interfaces for the meta-objects via the MOF will enhance interoperability between IDL-based
meta-objects on the one hand, and EJB-based meta-objects on the other. The mapping between the two will be
very straightforward. Repositories could project meta-objects as either exposing IDL or EJB interfaces,
depending on the needs of the developer. Importing and exporting via MOF-compliant XML streams rounds out
a very exciting picture.