Previous Table of Contents Next


11.3.1 Association


   An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link.

   Description

   An association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of an association may have the same type.

   An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.

   UML Infrastructure Specification, v2.0

   Generalizations

   Attributes

   • isDerived : Boolean Specifies whether the association is derived from other model elements such as other associations or constraints. The default value is false.

   Associations

   Constraints

   [1] An association specializing another association has the same number of ends as the other association.

   self.parents()->forAll(p | p.memberEnd.size() = self.memberEnd.size())

   [2] When an association specializes another association, every end of the specific association corresponds to an end of the general association, and the specific end reaches the same type or a subtype of the more general end.

   [3] endType is derived from the types of the member ends.

   self.endType = self.memberEnd->collect(e | e.type)

   [4] Only binary associations can be aggregations

   self.memberEnd->exists(isComposite) implies self.memberEnd->size() = 2

   [5] Association ends of associations with more than two ends must be owned by the association.

   if memberEnd->size() > 2then ownedEnd->includesAll(memberEnd)

   Semantics

   An association declares that there can be links between instances of the associated types. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end.

   When one or more ends of the association have isUnique=false, it is possible to have several links associating the same set of instances. In such a case, links carry an additional identifier apart from their end values.

   When one or more ends of the association are ordered, links carry ordering information in addition to their end values.

   A navigable end of an association means that it is intended to be traversed at runtime from objects participating in links at the other end(s) of the association to objects participating in links at the navigable end. This is independent of ownership of the end. Associations can have navigable ends regardless of how many ends they have. Implementations can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object.

   Traversal of an n-ary association towards a navigable end requires that objects first be identified for the remaining n-1 ends. The result of traversal is a collection of objects for the navigable end derived from links in which the other n-1 objects participate. For binary associations n=2, in which case traversal proceeds from one object at the other end to a collection of objects at the navigable end. The multiplicity of the association end constrains the size of this collection. If the end is marked as ordered, this collection will be ordered. If the end is marked as unique, this collection is a set; otherwise it allows duplicate elements.

   An end of one association may be marked as a subset of an end of another in circumstances where (a) both have the same number of ends, and (b) each of the set of types connected by the subsetting association conforms to a corresponding type connected by the subsetted association. In this case, given a set of specific instances for the other ends of both associations, the collection denoted by the subsetting end is fully included in the collection denoted by the subsetted end.

   An end of one association may be marked to show it redefines an end of another in circumstances where (a) both have the same number of ends, and (b) each of the set of types connected by the redefing association conforms to a corresponding type connected by the redefined association. In this case, given a set of specific instances for the other ends of both associations, the collections denoted by the redefining and redefined ends are the same.

   Associations may be specialized. The existence of a link of a specializing association implies the existence of a link relating the same set of instances in a specialized association.

   Subsetting represents the familiar set-theoretic concept. It is applicable to the collections represented by association ends, not the association itself. It may additionally apply to the extents of classifiers generally. The collection represented by one association end may be a subset of the collection represented by another association end without being a proper subset. That is to say, for A to be a subset of B, it is not required that collection B has a member NOT in A. Proper subsetting implies that the superset is not empty and that the subset has fewer members; subsetting does not have this implication. Subsetting is a relationship in the domain of extensional semantics.

   Specialization is in contrast to Subsetting a relationship in the domain of intensional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naïve but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation.

   Redefinition is a relationship between features of classifiers within a specialization hierarchy. Redefinition may be used to change the definition of a feature, and thereby introduce a specialized classifier in place of the original featuring classifier, but this usage is incidental. The difference in domain (that redefinition applies to features) differentiates redefinition from specialization.

   For n-ary associations, the lower multiplicity of an end is typically 0. A lower multiplicity for an end of an n-ary association of 1 (or more) implies that one link (or more) must exist for every possible combination of values for the other ends.

   An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions define transitive asymmetric relationships—their links form a directed, acyclic graph. Composition is represented by the isComposite attribute on the part end of the association being set to true.

   Semantic Variation Points

   The order and way in which part instances in a composite are created is not defined.

   The logical relationship between the derivation of an association and the derivation of its ends is not defined.

   The interaction of association specialization with association end redefinition and subsetting is not defined.

   Notation

   Any association may be drawn as a diamond (larger than a terminator on a line) with a solid line for each association end connecting the diamond to the classifier that is the end’s type. An association with more than two ends can only be drawn this way.

   A binary assocation is normally drawn as a solid line connecting two classifiers, or a solid line connecting a single classifier to itself (the two ends are distinct). A line may consist of one or more connected segments. The individual segments of the line itself have no semantic significance, but they may be graphically meaningful to a tool in dragging or resizing an association symbol.

   An association symbol may be adorned as follows:

   An association end is the connection between the line depicting an association and the icon (often a box) depicting the connected classifier. A name string may be placed near the end of the line to show the name of the association end. The name is optional and suppressible.

   Various other notations can be placed near the end of the line as follows:

   <property-string> ::= '{' <end-property> [ ',' <end-property> ]* '}' <end-property> ::=

   (

   'subsets' <property-name> | 'redefines' <end-name>

   )

   where <property-name> and <end-name> are names of user-provided properties and association ends found in the model context.

   If an association end is navigable, attribute-properties defined for attributes are legal as end-properties in the property string for that association end.

   Note that by default an association end represents a set.

   A stick arrowhead on the end of an association indicates the end is navigable. A small x on the end of an association indicates the end is not navigable. A visibility symbol can be added as an adornment on a navigable end to show the end’s visibility as an attribute of the featuring classifier.

   If the association end is derived, this may be shown by putting a slash in front of the name, or in place of the name if no name is shown.

    The notation for an attribute can be applied to a navigable end name as specified in the Notation subsection of “Property? on page 122.

   A composite aggregation is shown using the same notation as a binary association, but with a solid, filled diamond at the aggregate end.

   Presentation Options

   When two lines cross, the crossing may optionally be shown with a small semicircular jog to indicate that the lines do not intersect (as in electrical circuit diagrams).

   Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress some of the arrows and crosses and just show exceptional situations:

   If there are two or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends into a single segment. Any adornments on that single segment apply to all of the aggregation ends.

   Style Guidelines

   Lines may be drawn using various styles, including orthogonal segments, oblique segments, and curved segments. The choice of a particular set of line styles is a user choice.

   Generalizations between associations are best drawn using a different color or line width than what is used for the associations.

   Examples

    Figure 11.6 shows a binary association from Player to Year named PlayedInYear. The solid triangle indicates the order of reading: Player PlayedInYear Year. The figure further shows a ternary association between Team, Year, and Player with ends named team, season, and goalie respectively.


   Figure 11.6 - Binary and ternary associations

   The following example shows association ends with various adornments.


   {subsets b}

   Figure 11.7 - Association ends with various adornments

    The following adornments are shown on the four association ends in Figure 11.7.

   context C inv: b->includesAll(d) The following examples show notation for navigable ends.

Figure 11.8 - Examples of navigable ends

   In Figure 11.8 :

    Figure 11.9 shows that the attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end..


   Figure 11.9 - Example of attribute notation for navigable end owned by an end class

    Figure 11.10 shows the notation for a derived union. The attribute A::b is derived by being the strict union of all of the attributes that subset it. In this case there is just one of these, A1::b1. So for an instance of the class A1, b1 is a subset of b, and b is derived from b1.

   /b {union}

Figure 11.10 - Example of a derived union

    Figure 11.11 shows the black diamond notation for composite aggregation.


   Figure 11.11 - Composite aggregation is depicted as a black diamond