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.
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
clubmembers, and a separate one-to-one
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:
Place an ownership dot at the
chairedCommittee association end, leadig to
the completed models shown in Figure 8.3 above.
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
chairedCommittee, as discussed in the next part
of our 5-part tutorial.
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, that is, at which association end to place the