Previous | Table of Contents | Next |
One of the major goals of the Infrastructure has been to architecturally align UML and MOF. The first approach to accomplish
this has been to define the common core, which is realized as the package Core, in such a way that the model elements are
shared between UML and MOF. The second approach has been to make sure that UML is defined as a model
that is based on MOF used as a metamodel, as is illustrated in Figure 7.4. Note that MOF is used as the metamodel for
not only UML, but also for other languages such as CWM.
How these metalevel hierarchies work is explained in more detail in Section 7.6, “Superstructure Architecture,? on
page 14. An important aspect that deserves mentioning here is that every model element of UML is an instance of exactly
one model element in MOF. Note that the InfrastructureLibrary is used at both the M2 and M3 metalevels, since it is
being reused by UML and MOF, respectively, as was shown in Figure 7.2. In the case of MOF, the metaclasses of the
InfrastructureLibrary are used as is, while in the case of UML these model elements are given additional properties. The reason
for these differences is that the requirements when metamodeling differ slightly from the requirements when modeling applications
of a very diverse nature.
MOF defines for example how UML models are interchanged between tools using XML Metadata Interchange (XMI). MOF also defines
reflective interfaces (MOF::Reflection) for introspection that work for not only MOF itself, but also for CWM, UML, and for
any other metamodel that is an instance of MOF. It further defines an extension mechanism that can be used to extend metamodels
as an alternative to or in conjunction with profiles (as described in Chapter 13, “Core::Profiles?). In fact, profiles are
defined to be a subset of the MOF extension mechanism.