|
|
We sometimes find ourselves in a situation where we identify an attribute that is critical to our model, but which doesn't seem to fit nicely into any one class. As an example, let's revisit the association "a Student attends a Section," as shown in Figure 10-50. (Note that we're using the "generic" many multiplicity symbol this time, a single asterisk (*), at each end of the association line.)
At the end of every semester, a student receives a letter grade for every section that he or she attended during that semester. We decide that the grade should be represented as a string attribute (e.g., "A-", "C+"). However, where does the "grade" attribute belong?
It's not an attribute of the Student class, because a student doesn't get a single overall grade for all of his or her coursework, but rather a different grade for each course attended.
It's not an attribute of the Section class, either, because not all students attending a section typically receive the same letter grade.
If we think about this situation for a moment, we realize that the grade is actually an attribute of the pairing of a given Student object with a given Section; that is, it's an attribute of the link that exists between these two objects.
With UML, we create a separate class, known as an association class, to house attribute(s) belonging to the link between objects, and attach it with a dashed line to the association line, as shown in Figure 10-51.
Any time you see an association class in a class diagram, realize that there is an alternative equivalent way to represent the same situation without using an association class.
In the case of a many-to-many association involving an association class, you may split the many-to-many association into two one-to-many associations, inserting what was formerly the association class as a "normal" class between the other two classes. Doing this for the preceding attends association, we wind up with the alternative equivalent representation in Figure 10-52.
Figure 10-52: An alternative representation for Figure 10-51
One important point to note is that the "many" ends of these two new associations reside with the newly inserted class, because a Student receives many grades and a Section issues many grades.
If we happen to have an association class for a one-to-many association, as in the works for association between Professor and Department in Figure 10-53, then the association class's attribute(s) can, in theory, be "folded into" the class at the "many" end of the association instead, and we can do away with the association class completely as shown in Figure 10-54.
Figure 10-53: Placing an association class on a one-to-many association
Figure 10-54: An alternative representation for Figure 10-53
With a one-to-one association, we can fold the association class's attributes into either class.
That being said, this practice of folding in association class attributes into one end of a one-to-many or one-to-one association is discouraged, however, because it reduces the amount of information communicated by the model. In the preceding example, the only reason that a Professor has a salary attribute is because he or she works for a Department; knowledge of this "cause and effect" connection between employment and salary is lost if the association class is eliminated as such from the model.
Note that association classes are "normal" classes that may themselves participate in relationships with other classes. In the diagram in Figure 10-55, for example, we show the association class Role participating in a one-to-many association with the class USPresident; an example illustrating this model would be "Film Star Anthony Hopkins starred in the movie Nixon in the role of Richard M. Nixon, thus portraying the real former U.S. President Richard M. Nixon."
|
|
