|
|
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-47 to see what it's telling us.
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 comprised of one or more Schools, and that a School is comprised 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 may or may 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 may 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 attributes.) Thus, a given Student may optionally work for one Department, perhaps as a teaching assistant, and a given Professor may 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 at the University, but that Persons in general (i.e., Students) are not.
What if we instead wanted to reflect the fact that both Students and Professors may hold the role of mentor? We could substitute a reflexive association on the Person class, as shown in Figure 10-48, 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 wanted to reflect that only the first three of these are possible, we'd have to resort to the rather more complex version shown in Figure 10-49, where 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.
|
|
