8.9 Semantics of Associations

   Associations are the MOF Model’s second mechanism for relating MOF values at the M1-level. A MOF M2-level Association defines a binary relation between pairs of M1-level Instances, where the relationships in the relation are called Links. The Links for a given M2-level Association conceptually belong to a Link set.

   NOTE: While the MOF Model appears to support N-ary Associations, this is not so. There is a Constraint that states that an Association must have precisely 2 Association Ends; see “AssociationsMustNotUnary,? on page 117.

   An M2-level Association definition specifies the following properties:

• an Association “name,?

• an “isDerived? flag that determines whether the Association Links are stored explicitly or derived from other state.

• a pair of AssociationEnds that each have:

• a “name,?

    A MOF Association is represented in UML notation as shown in Figure 8.6.

   <Association Name>

   <Class1 Name> <end1 name> <end2 name>

   <Class2 Name>

   <end1 multiplicity> <end2 multiplicity>

   aggregation - none

   aggregation - composite

   navigable in direction indicated

   aggregation - shared

   Figure 8.6 - An M2-level Association in UML notation

   The connecting line denotes an Association between two Classes. The text of <Association Name>, <end1 name> and <end2 name> denote the “name? values for the respective Association and AssociationEnds. If the Association name is preceded by a forward slash, the Association has “isDerived? set to true.

   The Class boxes denote the respective types of the two ends. If the two ends of an Association have the same type, the Association line loops around so that it connects a Class box to itself.

   The <end1 multiplicity> and <end2 multiplicity> text give the multiplicity settings for the respective ends of the Association. The text that can appear here consists of an optional bounds specification with syntax:

   <bounds>::= [<number> ‘..’] (<number> | ‘*’)

   and the optional keyword “ordered.?

   Finally, the navigability and aggregation of the ends of the Association are (partially) specified by the symbols at the respective ends of the line:

• An empty diamond indicates that the Instances at the labeled end “share? the Instances at other end.

• A filled diamond indicates that the Instances at the labeled end are “composed? of Instances at the other end.

• An arrow head indicates that the Association is navigable from the Instance at the other end to the Instance at the labeled end.

   NOTE: There are a couple of anomalies in the mapping of UML Association notation to MOF Associations. First, while navigability and aggregation are orthogonal in the MOF, it is not possible to put both a diamond and an arrow head on the same end of a UML Association line. This means, for example, that it is not possible to express (the lack of) navigability from a component end to a composite end. Second, UML is imprecise about what an Association line with no arrowheads means. It can mean that the Association is not navigable, or alternatively that its navigability is not shown.

   This sub clause defines the core semantic model for M1-level Association instances in a rigorous, mapping independent fashion, and enumerates some important characteristics that follow from the definition.

    Given an M2 Association labeled as in Figure 8.6, the mapping to M1-level Link sets and Links can be modeled as follows:

1. The M1-level Instances of the M2-level Classes <Class1> and <Class2> belong to sets Class1_Instances and Class2_Instances that represent the sets of all possible instances of <Class1> and <Class2>, except for the respective null instances. (Note these sets are not restricted to current extant instances.)

2. The set All_Links is the Cartesian product of the sets Class1_Instances and Class2_Instances. Thus a Link, which is a member of All_Links, can be any tuple of the form “<c1, c2>? where “c1? and “c2? are members of Class1_Instances and Class2_Instances respectively.

3. The Link_Set is a subset of the set All_Links which consists of those Links that currently exist in the given M1-level Association.

5. A State of an M1-level instance of an Association consists of the Link_Set and (if the Association is ordered) the Before ordering.

4. If one or other of the AssociationEnds has “isOrdered? set to true, there is a partial ordering Before over the elements of Link_Set defined as follows. Assuming that <End1> of the Association is the one that is flagged as ordered:

a. For each Instance “i? in Class2_Instances, we can define a subset End2_Linksi of Link_Set consisting of those Links in Link_Set for which the second tuple member is “i.? b. Given the End2_Linksi sets as defined in item a. above, the Before ordering is defined between any pair of different Links in an End2_Linksi set with 2 or more members. In other words, for any distinct Linkjand Linkk in End2_Linksi, we can say either Linkj Before Linkk, or Linkk Before Linkj. c. The Before ordering is NOT defined between any pair of Links that belong to different End2_Links sets. d. Where it is defined, the Before ordering is required to be:

6. A Well-formed State is a State in which:

a. The Links set is a subset of Valid_Links, where Valid_Links is the subset of All_Links where the connected Instances currently exist. b. The End_Linksi sets as defined in item a. above conform to their respective Association End upper and lower bounds; that is,

   i. the number of Links in each End1_Linksi set must be greater than or equal to <End2.lower>, and less than or equal to <End2.upper>, and

   ii. the number of Links in each End2_Linksi set must be greater than or equal to <End1.lower>, and less than or equal to <End1.upper>.

   Ideally, the computational semantics of M1-level Associations for a particular mapping should be describable as transformations from one Well-formed State to another. However, some mappings must be defined such that the State of an Association instances is not always a well-formed. For example, in the IDL mapping, deletion of an Instance may cause an End_Links set to contain too few Links.

   The general model of an M1-level Association’s State may be further constrained by M2-level Constraints on the Association or other elements of the meta-model. Other systematic restrictions may apply in some mappings; for example, 8.11.1, “The Reference Closure Rule,? on page 153 and 8.11.2, “The Composition Closure Rule,? on page 155.

   The definitions of Links and Link_Sets above mean that M1-level Association instances have the following characteristics:

• Links only exist between existing Instances in a Well-formed State. When an Instance ceases to exist, any Links involving the Instance in any Link_Set cease to be universally meaningful.

• A Link “<a, b>? is distinct from a Link “<b, a>?. In other words, Links are directed. (Whether or not the “direction? of a Link has a meaning depends on the underlying semantics of the reality that the M2-level Association describes.)

• Links do not have object identity, but are uniquely identified by the Instances at both ends.

• A Link cannot connect a null Class instance to any other instance (including itself).

• Since a Link_Set is defined to be a set, it cannot contain more than one copy of a given Link. In other words, M1-level Associations cannot contain duplicate links.

• The Before ordering on the Links in an End_Links set (where defined) can be represented by arranging the Links in a strictly linear sequence.

• There can be multiple States for a given M2-level Association, each corresponding to a different M1-level Association instance in separate Package instances. In this scenario:

• a given Link can be a member of multiple Link_Sets, and • the Before orderings of different States will be independent.

   The “isChangeable? flag for an AssociationEnd determines whether or not the APIs for the Association should allow clients to change Links in an M1-level Association instance. The precise interpretation of this flag is mapping specific.

   The “isNavigable? flag for an AssociationEnd determines whether or not clients should be able to “navigate? the Links in an M1-level Association instance. The flag also determines whether or not the AssociationEnd can be used as a “key.? This flag’s interpretation (i.e., its impact on APIs) will depend on the mapping used.

   The “aggregation? attributes of an Association’s two ends determines the aggregation semantics for the corresponding M1-level Association instances; see 8.10, “Aggregation Semantics,? on page 152 . The impact of aggregation semantics are largely mapping specific. However, “composite? aggregation does place constraints on the Link_Set of a Well-formed State.

   When an M2-level Association has “isDerived? set to true, the resulting M1-level Association’s Link_Set is calculated from other information in the M1-level model. The M1-level semantics of derived Association instances is beyond the scope of the MOF specification.