An individual use case describes how a particular actor interacts with the system to achieve a result of value for that specific actor. The set of all use cases together describes the complete behavior of the system. However, we don't determine the behavior of the system by first writing individual use cases and then adding them all up. Instead, we first build a context model of the system and then successively refine this model until the detailed behaviors are understood , but each of these behaviors (use cases) is refined only within the overall context of the system. The complete set of use cases, actors, and their interactions constitutes the use-case model for the system.
Building the use-case model for the system is an important analysis step, one that will become the basis for understanding, communicating, and refining the behavior of the system over the course of the entire project. Building and refining the use-case model is not a one-time project event. A fundamental premise of iterative development is that "you don't know what you don't know," and this drives a process of continuous refinement wherein each phase of development advances the model to the next level of detail. In addition, as this happens, the model is refactored, new use cases are discovered , they in turn are refined, and the process continues until your model is fully refined.
By then, much of it will already be implemented in code! While there is no one perfect process for developing the model, we have found a simple five-step approach to be effective. However, as we've said earlier, these steps do not all happen at the same point in the project lifecycle, and the iterative nature of development dictates that some steps will be revisited over time.
Step 1: Identify and Describe the Actors
The first step in building the use-case model is to identify all the actors that interact with our system. After all, since a use case provides a result of value to an actor, there can be no use case that doesn't interact with something. As we described in Chapter 7, this is a matter of dividing the world into two classes of interesting things: our system and those things (actors) that interact with our system. Returning to our HOLIS case study, in Chapter 7 we identified six different actors that interacted with the HOLIS Central Control Unit.
To find the actors that interact with your system, think about the following questions.
Step 2: Identify the Use Cases and Write a Brief Description
Once the actors are identified, the next step is to identify the various use cases that the actors need to accomplish their jobs. We can do this by determining the specific goals for each actor in turn.
In our case study, we might discover use cases such as "program vacations settings" and "set clock" since these are important things that a resident (actor) might want to do with the system. If we place these in a simple diagram, it might look like Figure 14-2.
Figure 14-2. Use cases for the Homeowner /Programmer actor
You should consider the use-case name carefully . Typically, the name is a few words or a short phrase that starts with an action verb and communicates what the actor achieves with the use case. The use case names by themselves help communicate what the system does and quickly become a part of the project "lingo."
Along with the name, you should provide a brief description that elaborates the intent of the use case. For example, at this point, you might have the following mini-template for an identified use case.
Step 3: Identify the Actor and Use-Case Relationships
While we've noted that only one actor can initiate a use case, you'll also discover that many use cases involve the participation of multiple actors. When the actors and use cases interact in concert, that's when the system becomes a system. In this step in the process, each use case is analyzed to see what actors interact with it, and each actor's anticipated behavior is reviewed to verify that the actor participates in all the necessary use cases and thereby achieves all the results the actor needs to be successful with the system. In a system of any scope, this can become complex fairly quickly with a large number of use cases and actors, so you'll almost certainly want to represent this part of the model pictorially. That way, a user , analyst, or other reviewer can "see" the overall system behavior at one time and thereby better understand what is being proposed.
Step 4: Outline the Individual Use Cases
The next step is to outline each use case so you can start to gain an understanding of required system behavior at the next level of detail. As you do so, you also start to understand various alternatives and events that can occur as part of the systems operation. Of particular interest at this time is the flow of events, including the basic and alternate flows.
Typically, you will outline the basic flow first. There is only one basic flow (the straight line path on the diagram to the left), the flow that represents the most common path from start to finish through the system. (Some call this the "happy day" flow since there are no problems and no exceptions on this path .)
Step 5: Refine the Use Cases
At some point later in the project lifecycle, the time will be right to refine the use cases to the next and last level of detail. At that time, there are a number of additional factors to be considered , and each will play a role in the refinement process.