When classes are connected together conceptually, that connection is called an association. The initial basketball model provides some examples. Let's examine one—the association between a player and a team. You can characterize this association with the phrase “a player plays on a team.” You visualize the association as a line connecting the two classes, with the name of the association (“Plays on”) just above the line. You show how to read the relationship with a filled triangle pointing in the appropriate direction. Figure 4.1 shows how to visualize the Plays on association between the player and the team.

Figure 4.1. An association between a player and a team.

When one class associates with another, each one usually plays a role within that association. You can show each class's role by writing it near the line next to the class. In the association between a player and a team, if the team is professional, it's an employer and the player is an employee. Figure 4.2 shows how to represent these roles.

Figure 4.2. In an association, each class typically plays a role. You can represent those roles on the diagram.

You can imagine an association that you could read in the other direction: A team employs players. You can show both associations in the same diagram, with a filled triangle indicating how to read each association, as in Figure 4.3.

Figure 4.3. Two associations between classes can appear on the same diagram.

Associations may be more complex than just one class connected to another. Several classes can connect to one class. If you consider guards, forwards, and centers, and their associations with the Team class, you'll have the diagram in Figure 4.4.

Figure 4.4. Several classes can associate with a particular class.

Constraints on Associations

Sometimes an association between two classes has to follow a rule. You indicate that rule by putting a constraint near the association line. For example, a Bank Teller serves a Customer, but each Customer is served in the order in which he or she appears in line. You capture this in the model by putting the word ordered inside curly brackets (to indicate the constraint) near the Customer class, as in Figure 4.5.

Figure 4.5. You can place a constraint on an association. In this example, the Serves association is constrained to have the Bank Teller serve the Customer in order.

Another type of constraint is the Or relationship, signified by {or} on a dashed line that connects two association lines. Figure 4.6 models a high school student choosing either an academic course of study or a commercial one.

Figure 4.6. The Or relationship between two associations is a constraint.

Association Classes

An association can have attributes and operations, just like a class. In fact, when this is the case, you have an association class. You visualize an association class the same way you show a regular class, and you use a dashed line to connect it to the association line. An association class can have associations to other classes. Figure 4.7 shows an association class for the Plays on association between a player and a team. The association class, Contract, is associated with the GeneralManager class.

Figure 4.7. An association class models an association's attributes and operations. It's connected to an association via a dashed line and can associate with another class.

Links

Just as an object is an instance of a class, an association has instances as well. If you imagine a specific player who plays for a specific team, the Plays on relationship is called a link, and you represent it as a line connecting two objects. Just as you would underline the name of an object, you underline the name of a link, as in Figure 4.8.

Figure 4.8. A link is an instance of an association. It connects objects rather than classes. In a link, you underline the name of the link, just as you underline the name of an object.

The association drawn so far between Player and Team suggests that the two classes are in a one-to-one relationship. Common sense tells you that this isn't the case, however. A basketball team has five players (not counting substitutes). The Has association must take this into account. In the other direction, a player can play for just one team, and the Plays on association must account for that.

These specifications are examples of multiplicity—the number of objects from one class that relate with a single object in an associated class. To represent these numbers in the diagram, you place them near the appropriate class, as in Figure 4.9. (The numbers can go either above or below the association line.)

Figure 4.9. Multiplicity denotes the number of objects of one class that can relate to one object of an associated class.

The multiplicity in this example is not the only type. A variety of multiplicities are possible (a multiplicity of multiplicities, so to speak). One class can relate to another in a 1-to-1, 1-to-many, 1-to-1 or more, 1-to-0 or one, 1-to-a bounded interval (for example, 1-to-5 through 10), 1-to-exactly n (as in this example), or 1-to-a set of choices (for example, one-to-nine or ten).

A Helpful Hint

The first time you see some of these multiplicities, the phrasing might be a little confusing. Here's a trick to help you through the confusion: Imagine double-quotes around the right-side phrase, so that one-to-one or more becomes one-to-“one or more” and one-to-a bounded interval becomes one-to-“a bounded interval.” The double-quotes show the boundaries of that right-side phrase and might make the whole thing easier to understand.

The UML uses an asterisk (*) to represent more and to represent many. In one context Or is represented by two dots, as in 1..* (“one or more”). In another context, Or is represented by a comma, as in 5,10 (“5 or 10”). Figure 4.10 shows how to visualize possible multiplicities. (Note that the phrase at the right of each multiplicity in Figure 4.10 isn't part of the UML. It's just a label I added to help clarify things.)

Figure 4.10. Possible multiplicities and how to represent them in the UML.

One-to-Zero or One

When class A is in a one-to-zero or one multiplicity with class B, class B is said to be optional for class A.

When an association's multiplicity is one-to-many, a particular challenge often arises: lookup. When an object from one class has to choose a particular object from another in order to fulfill a role in an association, the first class has to rely on a specific attribute to select the correct object. That attribute is typically an identifier, such as an ID number. For example, a hotel's reservation list has many reservations, as Figure 4.11 shows.

Figure 4.11. A reservation list and its reservations are in a one-to-many multiplicity.

When you make a reservation at a hotel, the hotel assigns you a confirmation number. If you call with questions about the reservation, you have to supply the confirmation number, so that someone looking through the reservation list can select your reservation.

In the UML, the ID information is called a qualifier. Its symbol is a small rectangle adjoining the class that has the “one” part in the one-to-many multiplicity. Figure 4.12 shows the representation. Although the multiplicity between ReservationList and Reservation is one-to-many, the multiplicity between confirmationNumber and Reservation is one-to-one.

Figure 4.12. The UML notation for a qualifier. The idea is that when you add that little rectangle, you qualify the association.

Sometimes, a class is in an association with itself. Referred to as a reflexive association, this can happen when a class has objects that play a variety of roles. For example, a CarOccupant can be either a driver or a passenger. In the role of the driver, one CarOccupant drives zero or more additional CarOccupants who play the role of passenger. You represent this by drawing an association line from the class rectangle back to the same class rectangle, and on the association line you indicate the roles, name of the association, direction of the association, and multiplicity as before. Figure 4.13 presents this example.

Figure 4.13. In a reflexive association, you draw the line from the class to itself, and you can include the roles, association name, direction of the association, and multiplicity.

One of the hallmarks of object-orientation is that it captures one of the great commonsense aspects of day-to-day life: If you know something about a category of things, you automatically know some information you can transfer to other categories. If you know something is an appliance, you already know it has an on-off switch, a brand name, and a serial number. If you know something is an animal, you take for granted that it eats, sleeps, has a way of being born, has a way of getting from one place to another, and probably has a number of other attributes (and operations) you could list if you thought about it for a few minutes.

Object-orientation refers to this as inheritance. The UML also refers to this as generalization. One class (the child class or subclass) can inherit attributes and operations from another (the parent class or superclass). The parent class is more general than the child class.

The inheritance hierarchy doesn't have to end at two levels: A child class can be a parent class for still another child class. Mammal is a child class of Animal, and Horse is a child class of Mammal.

In the UML, you represent inheritance with a line that connects the parent class to the child class. On the part of the line that connects to the parent class, you put an open triangle that points to the parent class. This type of connection stands for the phrase is a kind of. A Mammal is a kind of Animal, and a Horse is a kind of Mammal. Figure 4.14 shows this particular inheritance hierarchy, along with some additional classes.

Figure 4.14. An inheritance hierarchy in the animal kingdom.

In the figure, note the appearance of the triangle and the lines when more than one child class inherits from a parent class. Setting the diagram up this way results in a less busy diagram than showing all the lines and triangles, but the UML doesn't prohibit putting all of them in the picture. Note also that you don't put the inherited attributes and operations in the subclass rectangles, as you've already represented them in the superclass.

Child = “Is a Kind Of”

When modeling inheritance, be sure the child class satisfies the is a kind of relationship with the parent class. If the two don't have that kind of relationship, an association of some other kind might be more appropriate.

Child classes add to the attributes and operations they inherit. For example, a Mammal has hair and gives milk, two attributes not found in the Animal class.

A class might have no parents, in which case it's a base class or root class. A class might have no children, in which case it's a leaf class. If a class has exactly one parent, it has single inheritance. If a class has more than one parent, it has multiple inheritance.

Class Names Are Singular

Have you noticed that the name of a class is always singular (for example, Mammal rather than Mammals)? The is a kind of relationship is a good reason for this. It makes sense to say “a horse is a kind of mammal” rather than “a horse is a kind of mammals” (which makes no sense at all).

Discovering Inheritance

In the course of talking to a client, an analyst discovers inheritance in several ways. It's possible that the candidate classes that emerge include both parent classes and child classes. The analyst has to realize that the attributes and operations of one class are general and perhaps apply to several other classes, which may add attributes and operations of their own.

The basketball example from Hour 3, “Working with Object-Orientation,” has Player, Guard, Forward, and Center classes. The Player has attributes such as name, height, weight, runningSpeed, and verticalLeap. This class has operations such as dribble(), pass(), rebound(), and shoot(). The Guard, Forward, and Center inherit these attributes and operations, and add some of their own. The Guard might have the operations runOffense() and bringBallUpcourt(). The Center might have the operation slamDunk(). Based on the coach's comments about relative heights of the players, the analyst might want to place constraints on the heights of the individuals who play each position.

Another possibility is that the analyst notes that two or more classes have a number of attributes and operations in common. The basketball model has a GameClock, which keeps track of how much time remains in a game period, and a ShotClock, which tracks the time remaining from the instant one team takes possession of the ball until it's supposed to shoot the ball. Realizing that both track time, the analyst could formulate a Clock class with a trackTime() operation that both the GameClock and the ShotClock inherit.

An Example of Polymorphism

Because the ShotClock tracks 24 seconds (professional) or 35 seconds (college) and the GameClock tracks 12 minutes (professional) or 20 minutes (college), trackTime() is polymorphic.

Abstract Classes

In the basketball model, the two classes I just mentioned—Player and Clock—are useful because they serve as parent classes for important child classes. The child classes are important in the model because you'll ultimately want to have instances of these classes. To develop the model you'll need instances of Guard, Forward, Center, GameClock, and ShotClock.

Player and Clock, however, will not provide any instances for the model. An object from the Player class would serve no purpose, nor would an object from the Clock class.

Classes like Player and Clock, which provide no objects, are said to be abstract. You indicate an abstract class by writing its name in italics. Figure 4.15 shows the two abstract classes and their children.

Figure 4.15. Two inheritance hierarchies with abstract classes in the basketball model.

In a different kind of relationship, one class uses another. This is called a dependency. The most common usage of a dependency is to show that the signature of one class's operation uses another class.

Suppose you're designing a system that displays corporate forms on-screen so employees can fill them out. The employee uses a menu to select the form to fill out. In your design, you have a System class and a Form class. Among its many operations, the System class has displayForm(f:Form). The form the system displays obviously depends on which form the user selects. The UML notation for this is a dashed line with an arrowhead pointing at the class depended on, as in Figure 4.16.

Figure 4.16. A dashed line with an arrowhead represents a dependency.

So far I've talked at length about class diagrams, but I haven't said nearly as much about object diagrams. As we end this hour on relationships, we've reached a good point to discuss how and why you visualize objects.

A class diagram gives general, definitional information—the properties of a class and its attributes, as well as other classes it associates with. An object diagram, on the other hand, gives information about specific instances of a class and how they link up at specific instants in time. (“Instants” and “instances”—that's a good way to conceptualize the purpose of an object diagram.)

Here's an example: Suppose you're looking at part of a chess game, like the chess pieces in Figure 4.17.

Figure 4.17. A portion of a chess game.

If you don't know anything about chess, it will be difficult for you to understand what's happening in this particular configuration of chess pieces. If you had a class diagram of chess pieces, like Figure 4.18, that diagram could help you figure out some of the general rules of chess. (The upperShape attribute is just a way of describing the physical appearance of a chess piece.)

Figure 4.18. A class diagram of some chess pieces.

Although this might aid your overall understanding (particularly if the diagram somehow explained knightMoveTo(), queenMoveTo(), pawnMoveTo(), and pawnCapture()), you'd still need some help comprehending the specific chess position in Figure 4.17. An object diagram provides the help. Figure 4.19 models the chess position in Figure 4.17, naming the links among those specific pieces.

Figure 4.19. An object diagram that models the chess position shown in Figure 4.17.

Without relationships, a class model would be little more than a laundry list of rectangles that represent a vocabulary. Relationships show how the terms in the vocabulary connect with one another to provide a picture of the slice of the world you're modeling. The association is the fundamental conceptual connection between classes. Each class in an association plays a role, and multiplicity specifies how many objects in one class relate to one object in the associated class. Many types of multiplicities are possible. An association is represented as a line between the class rectangles with the roles and multiplicities at either end. Like a class, an association can have attributes and operations.

A class can inherit attributes and operations from another class. The inheriting class is the child of the parent class it inherits from. You discover inheritance when you find classes in your initial model that have common attributes and operations. Abstract classes are intended only as bases for inheritance and provide no objects of their own. Inheritance is represented as a line between the parent and the child with an open triangle adjoining (and pointing to) the parent.

In a dependency, one class uses another. The most common usage of a dependency is to show that a signature in the operation of one class uses another class. A dependency is depicted as a dashed line joining the two classes in the dependency, with an arrowhead adjoining (and pointing to) the depended-on class.

Class diagrams show general definitional information about classes. To model specific instances of classes at specific instants in time, use an object diagram.

The quiz and the exercises are designed to firm up your knowledge of the UML in the area of relationships. Each question and exercise requires you to think about the modeling symbology you just learned and apply it to a situation. The answers to the Quiz are in Appendix A, “Quiz Answers.”

It's in the Cards

Here's a hint for doing exercises that involve classes: Get a set of 3×5 index cards and let one card represent one class. That is, write the name of the class at the top of the card and write attributes and operations on the lines below. This will help you conceive of a class as a tangible thing you can manipulate. Arrange the cards in the way you'll ultimately draw them in your model. It's the next best thing to having a modeling tool.