When you model the real world you find attributes that do not seem to fit in any one class. For instance, in our rental example you have two classes,
Client
and
CrashDummy
. Further, you know that
Now you want to model the attribute
dayOfRental.
The value of that attribute is the day a particular client rents a particular
Well, for openers, the dayOfRental attribute does not belong in Client; the client may rent dummies on different days. You could create attributes for client called dayOfRental1 , dayOfRental2 , and dayOfRental3 . But if you create multiple attributes, how do you know which crash dummy was rented on dayOfRental1 ? On the other hand, dayOfRental doesn’t belong in CrashDummy either; any given dummy can be rented on many different days, to different clients. The solution to this dilemma: Recognize that dayOfRental is an attribute of the rents association and not an attribute of a class .
If you find an attribute whose value depends on more than one class instance, you need a third class that holds that attribute. For example, the dayOfRental attribute depends on the specific instance of Client and the specific instance of CrashDummy that were linked in the rents association on that day. You would
Figure 4-13 shows the UML notation for showing such special attributes. The figure shows your two classes— Client and CrashDummy —in the rents relationship. It then shows another class ( Rents ) that contains the special attribute dayOfRental .
Figure 4-13:
The Rents association class.
In UML, a dashed line means dependency; Figure 4-13 shows dependency between the Rents class and the association named rents .
Remember
The name of the association class must be the same
People often partition the objects of a class into groups based on the value of an attribute in that class when they describe the real world. This grouping of objects may be an important aspect of an association between two classes. In our rental example, we
Modeling this situation requires the use of something the UML gurus call a
qualifier
, a notation that qualifies—that is, partitions into groups—navigation from an instance of one class to the instances of another. Figure 4-14 shows a qualified association where the qualifier occupies a small box between a class and an association. The qualifier goes at the
Say what? In Figure 4-13, size is an attribute of CrashDummy . When a Client instance orders zero or more instances of CrashDummy , they must specify the size they want. (The qualifier size goes at the opposite end of the orders association, away from the CrashDummy class.) So Figure 4-14 means that if we take an instance of Client and a value for the size qualifier, then we have zero or more orders links to instances of the class CrashDummy . So, given a specific client, the particular crash dummies rented are of a certain size.
Remember A qualifier is an attribute in the instances at the far end of the qualified association. Any attribute can have a datatype. In Figure 4-14, for example, the size qualifier has the inches datatype.
Figure 4-14:
Qualifying an association.
Often you find qualifiers reduce the multiplicity of an association. The rents association between the Client class and the CrashDummy class (for example) is a many-to-many association. If we recast the association as a qualified association (as in Figure 4-15), the multiplicity is reduced. Figure 4-15 has the following meaning: “Given an instance of Client and the value for a CrashDummy serialNum, the Client rents zero or one instance of CrashDummy.” (This is true because each crash dummy has a unique serial number.) Using qualifiers to reduce multiplicity is like
Figure 4-15:
Qualifiers can reduce multiplicity.
During design, you may want to tell the programmer to use an index when invoking the
As a designer, you’re often