Chapter 4: Use Cases and Actors

Tip The point of these diagrams is communication. If including an actor generalization would give the team some useful information, then include it. Otherwise, don't clutter up the diagrams with them.

The same concept is true for use cases. If you have a base set of functionality that one or more use cases expand upon, you can create a generic use case and then inherit the other use cases from it with a generalization relationship.

Use Case Diagrams

A Use Case diagram shows you some of the use cases in your system, some of the actors in your system, and the relationships between them. As you know, a use case is a high−level piece of functionality that the system will provide. An actor is anyone or anything that interacts with the system being built. An example of a Use Case diagram is shown in Figure 4.6.

Figure 4.6: Sample Use Case diagram

In this diagram, we see the system actors, the system use cases, and the relationships between them. Because the system will be available both online and over the phone, the customer and customer service representative can initiate the same use cases. We have one extends relationship and one includes relationship. There are eight major pieces of functionality the system will provide: purchasing tickets, changing a reservation, checking credit, canceling a reservation, viewing a customer itinerary, reserving a hotel room, reserving a rental car, and setting up the flight schedule.

One of the major benefits of Use Case diagrams is communication. Your customers can look at this diagram and receive a great deal of information. By looking at the use cases, they will know what functionality will be included in the system. By looking at the actors, they will know exactly who will be interfacing with the system. By looking at the set of use cases and actors, they will know exactly what the scope of the project will be. This can help them identify up front any missing functionality. For example, someone could look at the diagram above and say, "That's great, but I also need the ability to check my frequent−flyer membership to see how many miles I have." If so, all we need to do is add another use case called "View Frequent−Flyer Information."

Frequently, you will want to create several Use Case diagrams for a single system. A high−level diagram, usually called Main in Rational Rose, will show you just the packages, or groupings, of use cases. Other

118