8.6 Semantics of Attributes

   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.