Previous | Table of Contents | Next |
Attributes are one of two mechanisms provided by the MOF Model for defining relationships between values at the M1level. An
Attribute of an M2-level Class defines a relation between each M1-level Instance of the Class, and values of some other type.
The Attribute specification consists of the following properties:
• the Attribute’s “name,?
• the Attribute’s “type? which may be expressed using a Class or DataType,
• a “scope? specification,
• a “visibility? specification,
• a “multiplicity? specification,
• an “isChangeable? flag,
• an “isDerived? flag, and
• an (implicit) aggregation specification.
Many aspects of the M1-level computational semantics of Attributes depend on the mapping used. The following sub clauses describe
those aspects of the semantics that are mapping independent.
The “name? and “type? of an Attribute define the basic signature of a notional binary relationship between a Class instance
and an attribute value or values. For example, an Attribute declaration of the form:
class Class1 {
attribute attr_1 AttrType;};
defines a notional relation between an M1-level type corresponding to the Class1 and an M1-level type corresponding to the
AttrType. The three main kinds of relation that can exist between a Class and an Attribute are illustrated below in
Figure 8.1. The figure shows cases where an Attribute’s “multiplicity? bounds are “[1..1]? (single-valued), “[0..1]?
(optional) and “[m..n]? (multi-valued) respectively. Each notional relation is distinguishable from others for that Class
by the Attribute’s “name.?
single-valued Attribute optional Attribute multi-valued Attribute
Figure 8.1 - Notional Class — Attribute Relations
An M2-level Attribute’s “type? can be either a Class or a DataType. In the former case, the Class — AttrType relation relates
M1-level Instances corresponding to the two Classes. In the latter case, it relates M1-level Instances corresponding to the
Class to M1-level Instances corresponding to the DataType.
In the following sub clauses, it is often necessary to talk about the type of the M1-level Instances on the AttrType end of
a Class — AttrType relation. To make the text more readable, we will use the phrase “the Attribute’s M1-level base type? for
this type rather than referring to it as “the M1-level type corresponding to the M2-level Attribute’s “type.? As we shall
see, the phrase “the Attribute’s M1-level type? is best used for another purpose.
The “multiplicity? property defines the cardinality, uniqueness, and orderedness of an Attribute as follows:
• The “lower? and “upper? fields set the bounds on the number of elements (i.e., cardinality) allowed in an Attribute
value; that is, the “(collection of) AttrType? in Figure 8.1 and Figure 8.2 on page 143. Discussion of multiplicity
usually needs to deal with three cases:
• If the “lower? and “upper? are both 1, the Attribute is single-valued; that is, the “value? is a single instance belonging to the Attribute’s M1-level base type.
• If the “lower? is 0 and “upper? is 1, the Attribute is optional; that is, the “value? is either an instance belonging to the Attribute’s M1-level base type, or nothing.
• Otherwise, the Attribute is multi-valued; that is, its “value? is a collection of instances belonging to the Attribute’s M1-level base type.
• The “isUnique? flag specifies whether or not a multi-valued Attribute is allowed to contain duplicates; that is, elements that are equal according to the definition in 8.4, “Semantics of Equality for MOF Values,? on page 140.
• The “isOrdered? flag specifies whether or not the order of the elements in a multi-valued Attribute are significant.
The “multiplicity? settings of an M2-level Attribute have considerable influence on the M1-level Attributes values. In particular,
it determines whether the M1-level type of the Attribute is the M1-level base type, or a collection of that type. In addition,
the “multiplicity? may also cause:
• runtime checks to ensure that a multi-valued Attribute’s cardinality lies within a given range,
• runtime checks to ensure that a multi-valued Attribute does not contain duplicate members, and
• mechanisms that allow the user to specify the order of the elements of a multi-valued Attribute.
The “multiplicity? may also have considerable impact on the APIs that a mapping provides for accessing and updating Attribute
values.
It should be noted that when an M2-level Attribute has “isOrdered? set to true, the corresponding Class — AttrType relation
has an associated partial ordering when viewed from the Class role.
The “scope? of an Attribute can be either “instance_level? or “classifier_level.? For an “instance_level? Attribute, independent
relationships exist between instances of MyClass and instances of AttrType. For a “classifier_level? Attribute, a single instance
of AttrType (or a collection of AttrType) is related to all instances of MyClass in the extent. This is illustrated in
Figure 8.2.
my_attr
my_attr
MyClass
c
1:AttrType
1
1
MyClass
c
1:AttrType
1
0..1
my_attr
MyClass
c
AttrType
1 m..n
single-valued
my_attr
optional
my_attr AttrType
multi-valued
MyClass
m..n
instance-level scoped attributes classifier-level scoped attributes
Figure 8.2 - Instance-level versus Classifier-level scoping
NOTE: For the classifier-level Attributes, the diagrams are intended to show that all MyClass instances are related to a single
instance or collection of instances of AttrType.
The “isDerived? flag indicates whether the notional relationship between a Class instance and the Attribute type instances
is stored or computed.
The possible aggregation semantics of an Attribute depend on its type:
• If an Attribute’s type is expressed as a DataType, it has “non-aggregate? semantics.
• If an Attribute’s type is expressed as a Class, it has “composite? semantics.
In cases where an Attribute has “composite? semantics, the Class instance that is the value of the Attribute is a component
of the Class instance that contains the Attribute, not vice-versa.
NOTE: The above description reflects the fact that the Attribute model element does not have an “aggregation? attribute. A
Class-valued Attribute with “non-aggregate? semantics is currently expressed by making the Attribute’s type a DataType, where
the DataType’s “typeCode? is an object reference type that is linked to the Class via a TypeAlias.
The “visibility? property of an Attribute determines whether or not any operations for the notional relation should be present.
Similarly, the “isChangeable? property determines whether update operations are present. The presence or absence of these
operations do not alter the semantics of the Attribute.