5. Adding Directionality to a Non-Directed Association

When we make an information model in the form of a UML class diagram, we typically end up with a model containing one or more associations that do not have any ownership defined for their ends, as, for instance, in Figure 8.4 below. When there is no ownership dot at either end of an association, such as in this example, this means that the model does not specify how the association is to be represented (or realized) with the help of reference properties. Such an association does not have any direction. According to the UML 2.5 specification, the ends of such an association are "owned" by itself, and not by any of the classes participating in it.

Figure 8.4. A model of the Committee-has-ClubMember-as-chair association without ownership dots

A model of the Committee-has-ClubMember-as-chair association without ownership dots

A model without association end ownership dots is acceptable as a relational database design model, but it is incomplete as an information design model for classical object-oriented (OO) programming languages. For instance, the model of Figure 8.4 provides a relational database design with two entity tables, committees and clubmembers, and a separate one-to-one relationship table committee_has_clubmember_as_chair. But it does not provide a design for Java classes, since it does not specify how the association is to be implemented with the help of reference properties.

There are three options how to turn a model without association end ownership dots into a complete OO design model where all associations are either uni-directional or bi-directional: we can place an ownership dot at either end or at both ends of the association. Each of these three options defines a different way how to represent, or implement, the association with the help of reference properties. So, for the association shown in Figure 8.4 above, we have the following options:

  1. Place an ownership dot at the chair association end, leading to the model shown in Figure 8.2 above, which can be turned into the association-free model shown in Figure 8.1 above.

  2. Place an ownership dot at the chairedCommittee association end, leadig to the completed models shown in Figure 8.3 above.

  3. Make the association bi-directional by placing ownership dots at both association ends with the meaning that the association is implemented in a redundant manner by a pair of mutually inverse reference properties Committee::chair and ClubMember::chairedCommittee, as discussed in the next part of our 5-part tutorial.

    Figure 8.5. Modeling a bidirectional association between Committee and ClubMember

    Modeling a bidirectional association between Committee and ClubMember

So, whenever we have modeled an association, we have to make a choice, which of its ends represents a reference property and will therefore be marked with an ownership dot. It can be either one, or both. This decision also implies a decision about the navigability of the association. When an association end represents a reference property, this implies that it is navigable (via this property).

In the case of a functional association that is not one-to-one, the simplest design is obtained by defining the direction of the association according to its functionality, placing the association end ownership dot at the association end with the multiplicity 0..1 or 1 . For a non-directed one-to-one or many-to-many association, we can choose the direction, that is, at which association end to place the ownership dot.