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 11.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 11.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 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 11.4 above, we have the following options:
Place an ownership dot at the chair
association end, leading to the
model shown in Figure 11.2 above, which can be turned into the association-free
model shown in Figure 11.1 above.
Place an ownership dot at the chairedCommittee
association end, leadig to
the completed models shown in Figure 11.3 above.
Make the association bidirectional 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.
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 as we like, that is, we can place the ownership dot at either association end.