Chapter 4: Use Cases and Actors

Use cases and actors define the scope of the system you are building. Use cases include anything that is within the system; actors include anything that is external to the system. We'll start this chapter by discussing some of the fundamental concepts of use case, or system, modeling: use case, actor, association relationship, includes relationship, extends relationship, generalization relationship, flow of events, activity diagram, and Use Case diagram. Then, we'll look at how to model each of these in Rose.

At the end of the chapter, we provide an exercise that builds on the business case of Chapter 3, "Business Modeling," by adding use cases, actors, and Use Case diagrams to a Rose model.

∙

Using the Use Case view and Use Case diagrams

∙

Working with use cases, actors, and relationships

∙

Using notes

∙

Adding and deleting Use Case packages

Use Case Modeling Concepts

In this section, we'll discuss some of the fundamental concepts of use case modeling: use cases, actors, relationships, activity diagrams, and Use Case diagrams. If you have gone through the business modeling process, you will notice the similarities between what we will discuss here and business modeling. Business modeling also works with actors, use cases, relationships, activity diagrams, and Use Case diagrams. The difference is that business modeling focuses on the organization, while system modeling focuses on the system being built. The terms system use case or system actor are sometimes used to differentiate them from business use cases or business actors.

Item	Business Modeling	System Modeling
Use case	Describes what the business does	Describes what a system within the
		business does
Actor	External to the organization	External to the system (may be
		internal to the organization)
Business worker	Internal to the organization	Not used

In the last chapter, we went through the business modeling process for an airline. During that example, we focused on the business of being an airline, not on what systems we would build. Now, we focus in on a particular system. Assume that we are building a ticket reservation system for the airline. It will eventually let people call in or go online to order plane tickets and to change or cancel a reservation.

Actors

An actor is anyone or anything that interacts with the system being built. As we will see shortly, use cases describe anything that is inside the system's scope. Actors are anything that is outside the system's scope. In

104

Chapter 4: Use Cases and Actors

UML, actors are represented with stick figures:

There are three primary types of actors: users of the system, other systems that will interact with the system being built, and time.

The first type of actor is a physical person, or a user. These are the most common actors, and are present in just about every system. For our flight reservation system, actors are the people who will be directly using the system. Because we know some of the functionality will be available over the Internet, customers can directly use the system. We also know that customers can call in to a customer service representative to make a reservation. The customer service representative will directly use the system, so this role is an actor as well.

When naming actors, remember to use role names rather than position names. A given individual will play many roles. John Doe may be a customer service representative, but if he goes online to buy a ticket for himself, he is playing the role of a customer. Using role names rather than position names will give you a more stable picture of your actors. Position names change over time, as roles and responsibilities are moved from one position to another. By using roles, you won't need to update your model every time a new position is added or a position changes.

The second type of actor is another system. For example, the airline's reservation system may need to interface with an external application to validate credit cards for purchases. In this example, the external credit application is an actor. It is another system that we won't be changing at all, so it is outside the scope of the current project, but it does need to interface with our new system. Any systems like this, which lie just beyond the boundaries of our application, are actors.

The third type of actor that is commonly used is time. Time becomes an actor when the passing of a certain amount of time triggers some event in the system. For example, part of our airline's promotions may be the chance to win a free ticket. Every day at 3:00 p.m. the system may automatically select a random customer to give a free ticket to. Because time is outside of our control, it is an actor.

Use Cases

A use case is a high−level piece of functionality that the system will provide. In other words, a use case illustrates how someone might use the system. Let's begin by looking at an example.

Along with our actors, we need to define the use cases for the airline reservation system. It really doesn't matter if you identify the use cases or the actors first. In fact, these two steps are usually done together. To identify the use cases, we answer the question: What will the system do that provides value to the outside world? We can see from our brief vision statement above that it will let users purchase tickets, change a reservation, or cancel a reservation. These are all good candidates for use cases; each is some piece of functionality the system will provide that is of value to the end user. Notice that we didn't include a use case, such as "Get Flight Information" from the legacy system. This is a behind−the−scenes piece of logic that the end user really doesn't care about, so it doesn't qualify as a use case. "Purchase Ticket," "Change Reservation," or "Cancel Reservation," on the other hand, are things that the end user would care about and high−level pieces of functionality the system will provide, so they are good use cases. In UML, a use case is

105

Chapter 4: Use Cases and Actors

represented by the following symbol:

The advantage of looking at a system with use cases is the ability to dissociate the implementation of the system from the reason the system is there in the first place. It helps you focus on what is truly important—meeting the customer's needs and expectations without being instantly overwhelmed by implementation details. By looking at the use cases, the customer can see what functionality will be provided, and can agree to the system scope before the project goes any further.

Use cases take a different approach than traditional methods. Splitting the project into use cases is a process−oriented, not an implementation−oriented, way of looking at the system. It is therefore different from the functional decomposition approach that is so often taken. While functional decomposition focuses on how to break the problem down further and further into pieces that the system will handle, the use case approach focuses first on what the user expects from the system.

When you are beginning a project, a natural question is: How do I go about finding the use cases? A good way to begin is to examine any documentation the customers have provided. For example, a high−level scope or vision document can frequently help you identify the use cases. Consider also each of the stakeholders of the project. Ask yourself what functionality each stakeholder expects from the system. For each stakeholder, ask questions such as:

∙

What will the stakeholder need to do with the system?

∙

Will the stakeholder need to maintain any information (create, read, update, delete)?

∙

Does the stakeholder need to inform the system about any external events?

∙

Does the system need to notify the stakeholder about certain changes or events?

As we mentioned before, use cases are an implementation−independent, high−level view of what the user expects from the system. Let's examine each piece of this definition separately.

First, the use cases are implementation−independent. As you are defining the use cases, assume you are building a manual system. Your use cases should be able to be built in Java, C++, Visual Basic, or on paper. Use cases focus on what the system should do, not how the system will do it. We'll get into the how later on in the process.

Secondly, the use cases are a high−level view of the system. Your collection of use cases should let the customers easily see, at a very high level, your entire system. There should not be so many use cases that the customer is forced to wade through pages and pages of documentation just to see what the system will do. At the same time, there should be enough use cases to completely describe what the system will do. A typical system will have somewhere between 20 and 70 use cases. (If your system has 3000 use cases, you've lost the benefit of simplicity.) You can use different types of relationships, called includes and extends relationships,

106

Chapter 4: Use Cases and Actors

to break down the use cases a little if you need to. You can also package the use cases together to form groups of use cases to help you organize them better. We'll explore these topics later in this chapter.

Finally, the use cases should be focused on what the user will get out of the system. Each use case should represent a complete transaction between the user and the system that results in something of value to the user. The use cases should be named in user terms, not technical terms, and should be meaningful to the customer. We wouldn't have a use case, for example, called "Interface with the Bank's Credit System to Validate the Credit Card Number." The customer is trying to purchase a ticket, so that's what we call the use case: "Purchase Ticket." Use cases are typically named with verbs or short verb phrases in the format "<verb> <noun>," and describe what the customer sees as the end result. The customer doesn't care how many other systems you have to interface with, what specific steps need to be taken, or how many lines of code you need to confirm a Visa card. That customer cares only that a ticket was purchased. Again, you focus on the result the user expects from the system, not the steps that were taken to achieve the result.

So, when you have the final list of use cases, how do you know if you've found them all? Some questions to ask are:

∙

Is each functional requirement in at least one use case? If a requirement is not in a use case, it will not be implemented.

∙

Have you considered how each stakeholder will be using the system?

∙

What information will each stakeholder be providing for the system?

∙

What information will each stakeholder be receiving from the system?

∙

Have you considered maintenance issues? Someone will need to start the system and shut it down.

∙

Have you identified all of the external systems with which the system will need to interact?

∙

What information will each external system be providing to the system and receiving from the system?

Traceability

As with business modeling, a very important concept to consider at this point is traceability. Each of the system use cases should be able to be traced back to a business use case. The system use case is what implements part of the functionality in the business use case.

This is not a one−to−one mapping. Business use cases tend to be very high level, so many system use cases may be needed to support a single business use case. For example, an airline has a business use case called "Repair Plane." If we build a system to support this use case, it will have a lot of system use cases in it, such as "Enter Problem," "Check Inventory for Available Parts," "Receive Part from Inventory," "Order Part," "Schedule Maintenance," and so on. Each of these system use cases would be traced to the business use case

107