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.
An information design model that contains an association without association end ownership dots is acceptable as a relational database design model, but it is incomplete as a design model for OOP languages.
For instance, the model of Figure 8.4 provides a relational database design with two
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 an information design model of a non-directed association (without any association end ownership dots) into an information design model where all associations are either unidirectional or bidirectional: 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:
Place an ownership dot at the
association end, leading to the completed models shown in Figure 8.8 below.
Make the association bidirectional by placing ownership dots at
both association ends, as shown in Figure 8.5 with the meaning that the association is
implemented in a redundant manner by a pair of mutually inverse
chairedCommittee, as discussed
in Chapter 12.
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
1. For a non-directed one-to-one or many-to-many association,
we can choose the direction as we like, that is, we can place the
ownership dot at either association end.