10.8. "Mixing and Matching" Relationship Notations

It's possible to intertwine the various relationship types in some rather sophisticated ways. To appreciate this fact, let's study the model in Figure 10-36 to see what it's telling us. Note that the UML model shown in Figure 10-36 is a bit more complicated than the SRS model in that it includes University, School, and Department classes that won't be part of the SRS.

First of all, we see some familiar uses of aggregation and inheritance.

The use of aggregation in the upper-left corner of the diagram—a two-tier aggregation—communicates the facts that a University is composed of one or more Schools, and that a School is composed of one or more Departments, but that any one Department is only associated with a single School, and any one School is only associated with a single University.

The use of inheritance in the lower-right corner of the diagram indicates that Person is the common base class for both Student and Professor. Alternatively, stated another way: a Student is a Person, and a Professor is a Person.

The first interesting use of the notation that we observe is that an association can be used to relate classes at differing levels in an aggregation, as in the use of the funds R&D (Research & Development) association used to relate the University and Department classes. This indicates that the University funds one or more Departments for research and development purposes, but that a given Department might or might not be funded for R&D.

Next, we note the use of the employs association to relate the Department and Person classes, indicating that a Department employs one or more Persons, but that a given Person can work for only one Department, if indeed they work for any Department at all.

Because Person is a base class of both the Student and Professor derived classes, then by virtue of the "is a" relationship, anything we can say about a Person must also be true of its derived classes. Therefore:

• Associations/aggregations that a base class participates in are inherited by its derived classes. (This makes sense because we now know that associations are really rendered as fields.) Thus, a given Student can optionally work for one Department, perhaps as a teaching assistant, and a given Professor can optionally work for one Department.

• Also, because we can deduce (via the aggregation relationship) which School and University a given Department belongs to, the fact that a Person works for a given Department also implies which School and University the Person works for.

Finally, we note that an association can be used to relate classes at differing levels in an inheritance hierarchy, as in the use of the mentors association to relate the Person and Professor classes. Here, we're stating that a Professor optionally mentors many Persons—Students and/or Professors—and conversely that a Person—either a Student or a Professor—is mentored by optionally many Professors. We label the end of the association line closest to the Professor class with the role designation "mentor" to emphasize that Professors are mentors, but that Persons in general (that is, Students) are not.

What if we instead wanted to reflect the fact that both Students and Professors can hold the role of mentor? We could substitute a reflexive association on the Person class, as shown in Figure 10-37, which, by virtue of inheritance, actually implies four relationship possibilities:

• A Professor mentoring a Student

• A Professor mentoring another Professor

• A Student mentoring another Student

• A Student mentoring a Professor (which is not very likely!)

If we want to reflect that only the first three of these are possible, we have to resort to the rather more complex version shown in Figure 10-38, in which the three relationships of interest are all reflected as separate association lines (two reflexive, one binary).

As cumbersome as it is to change the diagram to reflect these refinements in our understanding, it would be orders of magnitude more painful to change the software once the application has been coded. An alternative approach to avoid some of the issues we just discussed would be to define a "policy" class that encapsulated the rules for mentoring.