Use Case Basics

We'll start with a slightly more formal definition than we provided earlier.

A use case describes sequences of actions a system performs that yield an observable result of value to a particular actor.

Phew ”that's a pretty pithy definition. In other words, each use case describes a series of events in which a particular actor, such as Jenny the Model, interacts with a system, such as the Ad Lib Modeling Agency Client Scheduling System, to achieve a result of value to Jenny, such as downloading directions to the next modeling assignment. In the UML, a use case is represented by an oval.

Let's look a little closer at the elements of this definition of a use case.

• Sequences of actions : The sequences of actions describe a set of functions performed, an algorithmic procedure, or any other internal process that produces a result. The set is invoked when the actor initiates the use case by providing some input to the system. An action is atomic; that is, it is performed either entirely or not at all. By the way, the atomicity requirement is a strong determinant in selecting the level of granularity of the use case. You should examine the proposed use case, and if the action is not atomic, then the level of granularity should be reduced to a finer level of detail.

• System performs : The system works for the actor. It exhibits the functionality described in the use case and takes its orders from the actor as to when to do what.

• An observable result of value : A most important construct. The use case must be "of value" to a user. Therefore, "the resident pushes the light button" is not a valid use case (the system didn't do anything for the user ). But "the resident pushes the light button and the system turns the light on" is a meaningful description of a use case, and such a use case is much more likely to motivate the resident to interact with the system!

• A particular actor : The particular actor is the individual or device (Linda the resident; the signal from the emergency button) that initiates the action (toggle the light or activate the security alarm).

That is the basic definition. Simple enough, yet nontrivial at the same time. Next, let's move on to see what all these actors have to do with our system.

On Actors

Here's another definition that's important for our discussion.

An actor is someone or something that interacts with the system.

In the UML, an actor is represented by a simple stick figure. For all practical purposes, there are only three types of actors to be considered :

1. Users : Users act on the system, and this is the type of actor most people think of when they think of a use case. The homeowner is an actor on the HOLIS control. Authors are actors on the word processing system they employ to do their work.

2. Other systems or applications : Most software we write also interacts with other systems or other applications. This is another primary source of actors. The HOLIS Control Switch interfaces and communicates with the HOLIS Central Control Unit. Therefore the HOLIS Control Switch subsystem is an actor on the HOLIS Central Control Unit. The author's word processing application interacts with a Web service to access and insert a selected piece of clip art. When this happens, the author's word processing application is an actor on the Web service.

3. A device : Many software applications interface to a variety of input and output devices. The HOLIS control system turns lights on and off. The lights are actors on the HOLIS system. The author's printer is an output device to the operating system. The printer is an actor on the operating system.

Use Case Anatomy

The use case itself is a structure of logical elements that work together to define the use case. Figure 14-1 is a standard template that highlights these elements. Every use case has four mandatory elements.

1. Name : Each use case has a name describing what is achieved by the interaction with the actor. The name can be a few words in length and it must be unique for every use case. Names such as " Turn Light On/Off" (HOLIS) and "Print Document" (word processing system) are good examples because they are short and yet descriptive.

2. Brief description : The purpose of the use case should be described in one or two sentences. An example might be, "This use case controls the selected light bank when instructed by the actor Homeowner."

3. Actor(s) : Since a use case has no meaning outside the context of its use by an actor, each actor that participates in the use case must be listed with the use case. This may seem a trivial notion, but as the number of use cases expands and the system complexity grows, knowing what actors use each use case will form a crucial basis of understanding the system.

4. Flow of events : The heart of the use case is the event flow, usually a textual description of the interactions between the actor and the system. The flow of events can consist of both the basic flow , which is the main path through the use case, and alternate flows , which are executed only under certain circumstances. For example, a use case that prints a receipt for a credit card transaction may discover that the printer is out of paper. In that case, an alternate flow of events would describe the behavior of the system in that special circumstance. Or if an application groups all function selections under a single menu tree, each selection is described in an alternate flow.

Figure 14-1. Use-case template

In addition to the mandatory elements, a use case may have optional elements, as described below.

• Pre-conditions : Pre-conditions are those conditions that must be present in order for a use case to start. They usually represent some system state that must be present before the use case can be used. For example, a pre-condition of the "Print Author's Manuscript Draft" use case is that a document must be open .

• Post-conditions : Post-conditions describe the state of the system after a use case has run its course. They often represent persistent data that is saved by the system as a result of executing the use case. For example, a post-condition of the HOLIS "Turn Light On/Off" use case is that the light remains in the set state after the use case is complete.

• System or subsystem : In a system of subsystems, it may be necessary to identify whether a use case is a system-level use case (one that causes multiple subsystems to interact) or a subsystem use case. In either case, you need to identify what system or subsystem a use case is identified with.

• Other stakeholders : It may also be useful to identify other key stakeholders who may be affected by the use case. For example, a manager may use a report built by the system, and yet the manager may not personally interact with the system in any way and therefore would not appear as an actor on the system.

• Special requirements : As we'll see later, the use case may also refer to special requirements, for example, a performance or throughput requirement ("support up to 100 simultaneous users") that applies to the specific use case.

We've provided a more fully elaborated use-case specification template in Appendix C.

That's enough time spent talking about what a use case is. Let's move on to understanding how to apply them.