Visual Introduction to UML for Object-Oriented Design
The other lines in Figure 7 show other types of relationships between the classes and interface. UML calls these other types of relationships associations. A number of things can appear with associations that provide information about the nature of an association. The following items are optional, but they should be used wherever they make the nature of the relationship clearer.
- Association name: Somewhere around the middle of an association line there may be an association name. The name of an association should be capitalized. There may be a triangle that looks like an arrow head at one end of the association name. The triangle indicates the direction in which you should read the association. Looking at Figure 7, you see that the association between the Factory and ConcreteProduct classes has the name Creates.
- Navigation arrows: Arrowheads that may appear at the ends of an association line are called navigation arrows. Navigation arrows indicate the direction in which you may navigate an association. Looking at the association named Creates in Figure 7, you see a navigation arrow pointing from the Factory class to the ConcreteProduct class. Because of the nature of creation, it seems clear that the Factory class is responsible for creating instances of the ConcreteProduct class. The nature of some associations is less obvious. To make the nature of such associations clear, it may be necessary to supply additionalinformation about the association. A common way to clarify the nature of an association is to name the role that each class plays in the association.
- Role Name: To clarify the nature of an association, the name of the role each class plays in the association can appear at each end of an association, next to the corresponding class. Role names should be lower-case. This makes them easier to distinguish from association names, which should becapitalized. In Figure 7, the CreationRequestor class and the IFactory interface participate in an association named Requests-Creation. The CreationRequestor class participates in that association in a role named requestor. The IFactory interface participates in that association in a role named creator.
- Multiplicity Indicator: Another helpful detail of an association is how many instances of each class participate in an occurrence of the association. A multiplicity indicator may appear at each end of an association to provide this information. A multiplicity indicator can be a simple number like 0 or 1. It can be a range of numbers indicated like this:
0..2An asterisk as the high value of a range means an unlimited number of occurrences. The multiplicity indicator 1..* means at least one instance; 0..* means any number of instances. A simple * is equivalent to
Looking at the multiplicity indicators in Figure 7, you will see that each one of the associations in the drawing is a one-to-many relationship. Figure 10 is a class diagram that shows a class with multiple subclasses.
Figure 10: Individual Inheritance Arrows
Although the drawing in Figure 10 is perfectly valid, the UML allows a more aesthetically pleasing way to draw a class with multiple subclasses. You can combine the arrowheads, as shown in Figure 11. The diagram in Figure 11 is identical in meaning to the diagram in Figure 10.
Figure 11: Combined Inheritance Arrow
Sometimes, there is a need to convey more structure than is implied by a simple one-to-many relationship. You may want to convey the idea that one object contains a collection of other objects. This kind of relationship is called an aggregation. A hollow diamond at the end of the association indicates aggregation. The hollow diamond appears at the end of the association attached to the class that contains instances of the other class. The class diagram in Figure 12 shows an aggregation.
Figure 12: Aggregation
The class diagram in Figure 12 shows a class named MessageManager. Each of its instances contains zero or more instances of a class named MIMEMsg.
Page 4 of 6