7. Eliminating Unidirectional Associations

How to eliminate explicit unidirectional associations from an information design model by replacing them with reference properties

Since classical OO programming languages do not support assocations as first class citizens, but only classes and reference properties, which represent unidirectional associations (but without any explicit visual rendering), we have to eliminate all explicit associations for obtaining an OO design model.

7.1. The basic elimination procedure restricted to unidirectional associations

The starting point of our restricted association elimination procedure is an information design model with various kinds of uni-directional associations, such as the model shown in Figure 8.6 above. If the model still contains any non-directional associations, we first have to turn them into directional ones by making a decision on the ownership of their ends, as discussed in Section 5.

A uni-directional association connecting a source with a target class is replaced with a corresponding reference property in its source class having

  1. the same name as the association end, if there is any, otherwise it is set to the name of the target class (possibly pluralized, if the reference property is multi-valued);

  2. the target class as its range;

  3. the same multiplicity as the target association end,

  4. a uniqueness constraint if the uni-directional association is inverse functional.

This replacement procedure is illustrated for the case of a uni-directional one-to-one association in Figure 8.3 above.

For the case of a uni-directional one-to-many association, Figure 8.8 below provides an illustration of the association elimination procedure. Here, the non-functional association end at the target class Point is turned into a corresponding reference property with name points obtained as the pluralized form of the target class name

Figure 8.8. Turn a non-functional target association end into a corresponding reference property


7.2. Eliminating associations from the Publisher-Book-Author design model

In the case of our running example, the Publisher-Book-Author information design model, we have to replace both uni-directional associations with suitable reference properties. In the first step, we replace the many-to-one association Book-has-Publisher in the model of Figure 8.6 with a functional reference property publisher in the class Book, resulting in the following association-free model:

Figure 8.9. The association-free Publisher-Book design model

The association-free Publisher-Book design model

Notice that since the target association end of the Book-has-Publisher association has the multiplicity 0..1, we have to declare the new property publisher as optional by appending the multiplicity 0..1 to its name.

In the second step, we replace the many-to-many association Book-has-Author in the model of Figure 8.7 with a multi-valued reference property authors in the class Book, resulting in the following association-free model:

Figure 8.10. The association-free Publisher-Book-Author design model

The association-free Publisher-Book-Author design model

After the platform-independent association-free information design model has been completed, one or more platform-specific data models, for a choice of specific implementation platforms, can be derived from it. Such a platform-specific data model can still be expressed in the form of a UML class diagram, but it contains only modeling elements that can be directly encoded in the chosen platform. Thus, for any platform considered, the tutorial contains two sections: 1) how to make the platform-specific data model, and 2) how to encode this model.