Association Class

Association classes allow you to add attributes, operations, and other features to associations, as shown in Figure 6-14.

Figure 6-14. Association Class

We can see from the diagram that a Person may work for a single Company. We need to keep information about the period of time that each employee works for each Company.

We can do this by adding a dateRange attribute to the association. We could add this attribute to the Person class, but it is really a fact about a Person's relationship to a Company, which will change should the person's employer change.

Figure 6-15 shows another way to represent this information: make Employment a full class in its own right. (Note how the multiplicities have been moved accordingly .) In this case, each of the classes in the original association has a single-valued association end with regard to the Employment class. The "employer" end now is derived, although you don't have to show this.

Figure 6-15. Promoting an Association Class to a Full Class

What benefit do you gain with the association class to offset the extra notation you have to remember? The association class adds an extra constraint, in that there can be only one instance of the association class between any two participating objects. I feel the need for an example.

Take a look at the two diagrams in Figure 6-16. These diagrams have much the same form. However, we could imagine a Person working for the same Company at different periods of time ”that is, he or she leaves and later returns. This means that a Person could have more than one Employment association with the same Company over time. With regard to the Person and Skill classes, it would be hard to see why a Person would have more than one Competency in the same Skill; indeed, you would probably consider that an error.

Figure 6-16. Association Class Subtleties

In the UML, only the latter case is legal. You can have only one Competency for each combination of Person and Skill.

The top diagram in Figure 6-16 would not allow a Person to have more than one Employment with the same Company. If you need to allow this, you need to make Employment a full class, in the style of Figure 6-15.

In the past, modelers made various assumptions about the meaning of an association class in these circumstances. Some assumed that you can have only unique combinations, such as competency, whereas others did not assume such a constraint.

Many people did not think about it at all and may have assumed the constraint in some places and not in others. So when using the UML, remember that the constraint is always there.

You often find this kind of construct with historical information, such as in the preceding Employment case. A useful pattern here is the Historic Mapping pattern described in Fowler (1997). We can use this by defining a «history » stereotype (see Figure 6-17).

Figure 6-17. History Stereotype for Associations

The model indicates that a Person may work for only a single Company at one time. Over time, however, a Person may work for several Companies. This suggests an interface along the lines of

 class Person {               //get current employer       Company getEmployer();              //employer at a given date       Company getEmployer(Date);            void changeEmployer(Company newEmployer,          Date changeDate);             void leaveEmployer (Date changeDate);

The «history » stereotype is not part of the UML, but I mention it here for two reasons. First, it is a notion I have found useful on several occasions in my modeling career. Second, it shows how you can use stereotypes to extend the UML.