| Previous | Table of Contents | Next |
This Clause describes the modeling elements that comprise the MOF Model and provide the building blocks for metamodels. Because
these elements are formally described with the MOF Model itself, the characteristics used to describe the model are the same
characteristics provided by the model.
The following sub clauses briefly describe the conventions that this specification uses to define the model elements and their
characteristics, with a few exceptions noted.
Classes are the fundamental building blocks of MOF meta-models and the MOF Model. A Class can have three kinds of features;
Attributes, References, and Operations. They may inherit from other Classes, and may be related to other
Classes by Associations. Classes are presented in detail in 8.5, “Semantics of Class Instances,? on page 141.
The MOF uses the term Class with a meaning that is similar to that of Class in UML. A MOF Class is an abstract specification
or classification of meta-objects that includes their state, their interfaces, and (at least informally) behavior. A Class
specification is sufficient to allow the generation of concrete interfaces with well defined semantics for managing meta-object
state. However, a MOF Class specification does not include any methods to implement meta-object behavior.
The Classes that make up the MOF Model are introduced in 7.3, “The Structure of the MOF Model,? on page 36 and
specified in detail in
7.4, “MOF Model Classes,? on page 41. Each Class is defined in terms of its name(s), its super-
Classes, the Classes whose instances it can contain, its attributes, its references, its operations, its constraints, and
whether it is abstract or concrete.
NOTE:
Except where stated, the order in which “MOF Model Classes? on page 41 introduces Classes and their component
features is not normative. The normative order is defined in the XMI for the MOF Model that may be found in the Preface. This
order determines the order in which elements appear in the generated IDL, and is in theory significant.
This document uses a hybrid textual and tabular notation to define the important characteristics of each Class in the MOF
Model. The notation defines defaults for most characteristics, so that the Class definitions need only explicitly specify
characteristics that are different from the default. The following text explains the notation used for Classes and their characteristics.
Each Class in the MOF Model is introduced by a second level sub clause heading. The heading defines the standard ModelElement
name for the Class. The Classes name on the heading line can be followed by the word “abstract? or by a “substitute_name?
for some mapping. For example, the following:
3.4.1ModelElement (abstract)
introduces a Class called “ModelElement? and defines its Clause “isAbstract? flag to have the value “true.? On the other hand,
the following:
3.4.11Attribute (idl_substitute_name“MofAttribute?)
introduces a Class called “Attribute? and defines its substitute name (for the IDL mapping) as “MofAttribute.? The latter
information is encoded using a Tag whose “tagId? is “idl_substitute_name? and whose “values? consist of the Any-ized string
“MofAttribute.?
Unless stated otherwise each Class in the MOF Model has “isAbstract? set to false, and has no attached Tags.
NOTE: The MOF uses “abstract Class? in the same sense as UML, and also Java and many other object oriented programming languages.
There is no relationship with the IDL keyword “abstract? introduced in CORBA 2.3.
The paragraph or paragraphs following a Class heading give a description of the Class, its purpose, and its meaning.
The “Superclasses? heading lists the MOF Classes that generalize the Class being described. In the MOF context, generalization
is another term for inheritance. Saying that a Class A generalizes a Class B, means the same as saying that Class B inherits
from Class A. The sub-Class (B) inherits the contents of the super-Class (A). Multiple inheritance is permitted in the MOF.
This heading is always present, since with the sole exception of ModelElement, all Classes in the MOF Model have super-Classes.
Instances of the sub-Classes of NameSpace can act as containers of other elements. If present, the “Contained Elements? heading
lists the Classes whose instances may be contained by an instance of this container Class. It also gives the index
of the MOF Model Constraint that defines the containment rule for the Class. For more details, see 7.3.3, “The MOF
Model Structure,? on page 38
. In particular,
Table 7.5 on page 137 expresses the MOF Class containment rules in a
concise form.
If the “Contained Elements? heading is absent, instances of the Class may not contain other instances. This occurs if the
Class is an abstract Class (and therefore has no instances), or if the Class is not derived from the Namespace Class.
The “Attributes? heading lists the Attributes for a Class in the MOF Model. Attributes that are inherited from the super-Classes
are not listed. If the “Attributes? heading is missing, the Class has no Attributes.
All Attributes defined in the MOF Model have a “visibility? of “public_vis.? All have a “type? that is represented using a
DataType, and therefore all have aggregation semantics of “none.? The remaining characteristics of Attributes are defined
using the notation described in
Table 7.1.
Table 7.1 - Notation for Attribute Characteristics
| Entry | Description | ||||
| type: | This entry defines the base type for the Attribute. It gives either the name of a DataType defined in 7.6, “MOF Model Data Types,? on page 96, or the name of a standard MOF primitive data type (e.g., “Boolean? or “String?) defined in 7.10, “The PrimitiveTypes Package,? on page 134. The base type is represented by the Attribute’s “type.? | ||||
| multiplicity: | This entry defines the “multiplicity? for the Attribute, consisting of its “lower? and “upper? bounds, an “isOrdered? flag, and an “isUnique? flag. See 7.6.2, “MultiplicityType,? on page 96, and 8.6.2, “Multiplicity,? on page 142 for more details. The multiplicity for an Attribute is expressed as follows: • The “lower? and “upper? bounds are expressed as “exactly one,? “zero or one,? “zero or more,? and “one or more.? • If the word “ordered? appears, “isOrdered? should be true. If it is absent, “isOrdered? should be false. • If the word “unique? appears, “isUnique? should be true. If it is absent, “isUnique? should be false. | ||||
| changeable: | This optional entry defines the “isChangeable? flag for the Attribute. If omitted, “isChangeable? is true. |
Table 7.1 - Notation for Attribute Characteristics
| derived from: | This optional entry either describes the derivation of a derived Attribute, or if the entry is present, the Attribute’s “isDerived? flag will be true. If it is absent, the flag will be false. | ||||
| scope: | This optional entry defines the “scope? of an Attribute as either “instance_level? or “classifier_level.? If the entry is absent, the Attribute’s “scope? is “instance_level.? |
The “References? heading lists the References for a Class in the MOF Model. A Reference connects its containing Class to an
Association End belonging to an Association that involves the Class. This allows a client to navigate directly from an instance
of the Class to other instance or instances that are related by links in the Association. If the “References? heading is absent,
the Class has no References.
A Class involved in an Association may or may not have a corresponding Reference. A Reference means that a client can navigate
to instances of the other Class; however, this comes at the cost of some restrictions. In particular, if one or both Classes
in an Association have References for that Association, the Reference Closure rule restricts the creation of links
between instances in different “extents? (see 8.11.1, “The Reference Closure Rule,? on page 153).
NOTE: The modeling of navigation in MOF differs from UML. In UML, mechanisms for navigating links are available when the “isNavigable?
flag is true for a given AssociationEnd. In this case, stronger uniqueness constraints on AssociationEnd names mean that they
are unique within the namespaces of the Association and all Classes involved and their sub-Classes. This means that the AssociationEnd
names uniquely bind to a “navigator? operation in each context in which navigation might be used.
Most characteristics of References in the MOF Model are either common across all References or derived from other information:
• The “visibility? of all References in the MOF Model is “public_vis.?
• The “scope? of all References is “instance_scope.?
• The “type? of all References is the same as the “type? of the AssociationEnd it references.
• The “multiplicity? of all References is the same as the “multiplicity? of the AssociationEnd it references.
The variable characteristics of References are defined or documented using the notation described in Table 7.2.
Table 7.2 - Notation for Reference characteristics Table 7.2 - Notation for Reference characteristics
| Entry | Description | ||||
| class: | This entry documents the base type of the Reference and is represented as its “type.? Note that the “type? of a Reference must be the same as the “type? of the referenced AssociationEnd. | ||||
| defined by: | This entry defines the Association and AssociationEnd that the Reference is linked to via a RefersTo link. |
multiplicity:changeable:inverse: |
|||||
| This entry documents the “multiplicity? characteristics for the Reference. These are written the same way as Attribute “multiplicity? characteristics, except that “unique? is omitted because its value is predetermined (see 7.2.2.2, “Ends,? on page 34). Note the following: • the OCL constraints on MultiplicityType and AssociationEnd mean that the “isUnique? field must be “false? if the “upper? bound is 1 and “true? otherwise, and • the “multiplicity? settings for an AssociationEnd and its corresponding Reference(s) must be the same. | |||||
| This optional entry defines the setting of the Reference’s “isChangeable? flag. If the entry is absent, the “isChangeable? flag is true. | |||||
| This optional entry documents the “inverse? Reference for this Reference; that is, the Reference on the link related Class that allows navigation back to this Reference’s Class. If this entry is absent, the Reference does not have an inverse Reference. |
The “Operations? heading lists the Operations for a Class in the MOF Model. If the heading is absent, the Class has no Operations.
All Operations for Classes in the MOF Model have “visibility? of “public_vis.? The remaining characteristics of References
are defined using notation described in
Table 7.3.
Table 7.3 - Notation for Operation Characteristics
| Entry | Description | ||||
| return type: | This optional entry defines the “type? and “multiplicity? of the Operation’s return Parameter; that is, the one with “direction? of “return_dir.? The “type? is denoted by a name of a Class or DataType defined the MOF Model, or a name of standard MOF primitive data type. The “multiplicity? is expressed like an Attribute “multiplicity? (see Table 7.2 on page 32), except that when it is absent, the “multiplicity? defaults to “exactly one.? The return Parameter (if it exists) should be the first contained Parameter of the Operation. If this entry is absent or says “none,? the Operation does not have a return Parameter. | ||||
| isQuery: | This optional entry defines the Operation’s “isQuery? flag. If it is absent, the “isQuery? flag has the value false. | ||||
| scope: | This optional entry defines the Operation’s “scope.? If it is absent, the Operation has a “scope? of “instance_level.? | ||||
| parameters: | This entry defines the Operation’s non-return Parameter list in the order that they appear in the Operation’s signature. Each parameter is defined with the following format: name, direction type multiplicity. If the “multiplicity? is not explicitly specified, it defaults to “exactly one.? If the entry simply says “none,? the Operation has no non-return Parameters. | ||||
| exceptions: | This optional entry defines the list of Exceptions that this Operation may raise in the order that they appear in the Operation’s signature. If it is absent, the Operation raises no Exceptions. | ||||
| operation semantics: | This optional entry simply gives a cross reference to the OCL defining the Operation’s semantics. Note that the MOF Model does not provide a standard way of representing an Operation’s semantic specification, and it is not included in the normative XMI serialization of the MOF Model. |
The “Constraints? heading lists the Constraints that are attached to this Class in the MOF Model. The OCL for the Constraints
may be found in
7.9.4, “The MOF Model Constraints,? on page 105. Each listed Constraint “constrains? the
Class, and is also contained by it.
The “IDL? heading shows an excerpt of the MOF Model IDL that corresponds to this Class. The excerpts, which are part of the
“Model? module given in the “MOF to IDL Summary? clause, consist of a Class proxy interface and an Instance interface. For
information on these interfaces, refer to the “MOF to IDL Mapping? clause.
The Associations in the MOF Model are defined in 7.5, “MOF Model Associations,? on page 85.
Associations describe relationships between instances of Classes. In short, an Association relates two Classes (or relates
one Class to itself) to define a “link set? that contains two-ended “links? between instances of the Classes. The properties
of an Association rest mostly in its two AssociationEnds. Refer to 8.9, “Semantics of Associations,? on page 149 for a
more detailed explanation.
Each Association in the MOF Model is introduced by a second level sub clause heading in “MOF Model Associations?
on page 85. The heading defines the standard ModelElement name for the Association. The Classes name on the heading
line can be followed by the word “derived.? For example, the following:
3.5.4 Exposes (derived)
introduces an Association called “Exposes? and defines its Clause “isDerived? flag to be true. If the word “derived? is not
present, the Association’s “isDerived? flag is false.
The paragraph or paragraphs following an Association heading give a description of the Association, its purpose, and its meaning.
The “Ends? heading defines the two AssociationEnds for an Association in the MOF Model. The two AssociationEnds are defined
by giving their “name? values and defining the remaining characteristics in tabular form.
Every AssociationEnd in the MOF Model has both “isNavigable? and “isChangeable? set to true. The remaining characteristics
of AssociationEnds are defined using notation described in the table below.
| Entry | Description | ||||
| class: | This entry specifies the Class whose instances are linked at this end of the Association. This is represented by the AssociationEnd’s “name? attribute. | ||||
| multiplicity: | This entry defines the AssociationEnd’s “multiplicity? attribute. This is expressed in the same way as References (i.e., uniqueness is implicit - see 7.2.1.5, “References,? on page 32). Note the following: • the OCL constraints on MultiplicityType and AssociationEnd mean that the “isUnique? field must be “false? if the “upper? bound is 1 and “true? otherwise, and • the “multiplicity? settings for an AssociationEnd and its corresponding Reference(s) must be the same. | ||||
| aggregation: | This optional entry defines the AssociationEnd’s “aggregation? attribute as one of “composite,? “shared,? or “none? (see 8.9.4, “Association Aggregation,? on page 152). If the entry is absent, the AssociationEnd’s “aggregation? attribute takes the value “none.? |
The “Derivation? heading defines how a derived Association should be computed. It may include marker for an OCL rule defined
in “[C-59]? on page 122.
The “IDL? heading shows an excerpt of the MOF Model IDL that corresponds to this Association. These excerpts, which are part
of the “Model? module given in the MOF IDL Summary Clause, consist of an Association interface and related IDL data types.
For more information, refer to the MOF to IDL Mapping Clause.
The DataTypes that form part of the MOF Model are described in 7.6, “MOF Model Data Types,? on page 96. All
DataTypes in the MOF Model have “visibility? of “public_vis.? The settings of the other attributes are “isAbstract? = false,
“isRoot? = true, and “isLeaf? = true as required by various MOF Model constraints.
The DataTypes used in the MOF Model are instances of PrimitiveType, StructureType, or EnumerationType. A StructureType’s StructureFields
(and their order) are as shown in the IDL. Similarly, an EnumerationType’s “labels? and their order are as shown in the IDL.
The remaining characteristics of a DataType are its “name? (given in the sub clause heading), and its container (given by
the “Container? subheading). If the “Container? subheading is absent, the DataType is contained by the Model Package.
The Exceptions that form part of the MOF Model are described in 7.7, “MOF Model Exceptions,? on page 99.
All Exceptions in the MOF Model have “visibility? of “public_vis? and “scope? of “classifier_level.?
The remaining characteristics are the Exception’s
• “name? - given in the sub clause heading, and
• Parameters and Container, which are given in the corresponding headings.
If the Container heading is absent, the Exception is contained by the Model Package.
The Constants that form part of the MOF Model are described in
7.8, “MOF Model Constants,? on page 99
.
The characteristics of a Constant are its
• “name? - given in the sub clause heading, and
• Container - given under the “Container? heading, and
• “type? and “value? that can be determined from the IDL.
If the “Container? heading is absent, the DataType is contained by the Model Package.
The Constraints that form part of the MOF Model are described in 7.9, “MOF Model Constraints,? on page 101. The
notation used for describing the constraints is described in 7.9.2.1, “Notation for MOF Model Constraints,? on page 101.
At various points in this clause, UML class diagrams are used to describe aspects of the MOF Model. To understand these diagrams,
the reader should mentally map from UML modeling concepts to the equivalent MOF meta-modeling constructs.
There is one point in which this document’s use of UML notation requires explaining. In standard UML notation, an arrowhead
on an Association line indicates that the Association is navigable in the direction indicated. Absence of an arrowhead can
mean either that the Association is navigable or that it is navigable in both directions, depending on the context.
As was explained in 7.2.1.5, “References,? on page 32, the MOF models navigable Associations in a different way. Thus
in this document, an arrowhead on one end of an Association means that a Reference exists on the Class at the opposite end
that allows navigation in the indicated direction. If there are no arrowheads, there are References on the Classes at both
ends of the Association.