The starting point of our restricted association elimination procedure is an information design model with various kinds of unidirectional associations, such as the model shown in Figure 1.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 unidirectional association connecting a source with a target class is replaced with a corresponding reference property in its source class having

This replacement procedure is illustrated for the case of a unidirectional one-to-one association in Figure 1.3 below, where the uniqueness constraint of the reference property chairedCommittee is expressed by the {key} property modifier.

Figure 1.8. Turning a functional association end into a reference property

For the case of a unidirectional one-to-many association, Figure 1.9 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 1.9. Turning a non-functional association end into a multi-valued reference property

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

Figure 1.10. An OO class model for Publisher and Book

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 defining its multiplicity to be 0..1.

The meaning of this OO class model and its reference property publisher can be illustrated by a sample data population for the two model classes Book and Publisher as presented in the following tables:

Notice that the values of the "Publisher" column of the Book table are unique names that reference a row of the Publisher table. The "Publisher" column may not have a value for certain rows due to the fact that the corresponding reference property publisher is optional.

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

Figure 1.11. An OO class model for the classes Book, Publisher and Author

The meaning of this OO class model and its reference properties Book::publisher and Book::authors can be illustrated by sample data populations for the three model classes:

After the platform-independent OO class model has been completed, one or more platform-specific implementation models, for a choice of specific implementation platforms, can be derived from it. Examples of types of platform-specific implementation models are JS class models, Java Entity class models and SQL table models.

A platform-specific implementation model can still be expressed in the form of a UML class diagram, but it contains only modeling elements that can be directly coded in the chosen platform. Thus, for any platform considered, two guidelines are needed: 1) how to make the platform-specific implementation model, and 2) how to code this model.