To support development and testing activities, the use cases defined earlier in the project must be
more fully elaborated.
The use-case model is reviewed and will often be refactored as well.
A well-elaborated use case also defines all alternative flows, pre- and post- conditions, and
special requirements.
The additional use-case relationships extend and include help the team structure and maintain the
use-case model.
The Scope of a Use Case
However, a use case usually requires a fair amount of additional elaboration, and more work lies
ahead. One of these tasks is the decision about whether a set of user interactions is one or several
use cases. Consider the use of a recycling machine. The customer inserts cans and bottles into the
recycling machine, presses a button, and receives a printed receipt that can be exchanged for
money.
Is it one use case to insert a deposit item, another use case to press the button, and yet another to
acquire the receipt? Or is this all one use case? Three actions occur, but one without the others is
of little value to the customer. The complete process is required to make sense to the customer.
Thus, the complete dialogue—from inserting the first deposit item to pressing the button to
getting the receipt—is a complete instance of use, a use case.
Additionally, you want to keep the three actions together, to be able to review them at the same
time, modify them together, test them together, change them together when necessary, write user
documentation that describes them, and in general manage them as a unit. This becomes
particularly important in larger systems.
The Case Study: Anatomy of a Simple Use Case
As an example of the refinement process, let's look at a step-by-step procedure for refining a use
case. Recall that in Chapter 14, we developed the preliminary use-case model for HOLIS. At that
time, it was necessary only to decide on what the basic use cases would be. We took care in
doing our systems analysis work to try to identify all the significant use cases, but we didn't
elaborate them. We just named them and provided a brief description. That was appropriate, and
it reflected the level of abstraction at which we needed to understand the system at thattime.
In later iterations, however, we need to revisit the use cases and refine them so they can be
implemented and tested. Even then, we have to pick the right level of abstraction or else we may
overspecify or underspecify system behavior. We'll use a simple HOLIS example: a resident
activating a light in a house, using the HOLIS home automation lighting system. While the use
case is a simple one, it has a few interesting facets that illustrate some of the complexities of the
system and demonstrate how we can handle them with our techniques.
Reviewing the Actors
When we first identified the actors, we saw only one user that interacted with the light switch, so
we named only one actor, the user (Resident) pressing the switch. However, from the perspective
of HOLIS as a system, we also recognized that the system automatically controls the lighting and
thus involves another actor, which we named Light Bank.
Reviewing the Name
As we described, each use case should have a name indicating what is achieved by its interaction
with the actor(s). The name is important since, ideally, it describes in shorthand form what the
actor accomplishes with the use case. We also noted that no two use cases can have the same
name, and each should be unique and easily distinguishable among the use cases defined for the
project. Further, use-case names often begin with an action verb to indicate the intent of the use
case.
In our case study, we now discover that the HOLIS systems
engineers have made some key design decisions that affect the
software for the system. Suppose the team is now presented with
a finalized control panel design that looks as shown on the left.
We note from this design that a single switch controls the on and off function as well as "dim."
Perhaps we assumed there would be a separate slide switch or something for the dimming
function, but in any case, the design is what it is. Now we have to look at our use case in light of
this new information and decide what we want our use case to do. Let's make the decision to
provide only one use case to control the lighting function since this would seem to simplify
things. However, based on what we know now, it looks like we haven't named the use case very
well. After all, the user can do more than turn the light on or off; with the same button on the
control panel the resident can also brighten or dim the light. So, let's rename our use case to
become Control Light since that seems more descriptive. Now the representation of our "simple
and obvious" use case Turn Light On/Off has been refined .
You may want to use a formal method to structure the names of use cases so as to group similar
use cases with similar names. Or you may want to incorporate a "serial number" or other unique
identifier into the use-case name to facilitate managing a list of the use cases. For example, a
designer might specify the name of this use case as "031 Control Light." Although the spirit of
this approach is laudable, our experience has shown that proper use-case naming, and perhaps
the application of tools that allow us to search, sort, and analyze use cases, are usually adequate
to the task, so we'll just stick with "Control Light."
Alternative Flow of Events: Dimming
When the Resident holds down the On/Off/Dim button for more than 1 second, the system
initiates a brightening/dimming activity for the room's Light Bank.
While the Resident continues to press the On/Off/Dim button:
1. The brightness of the controlled light is smoothly increased to a system-wide maximum value
at a rate of 10 percent per second.
2. When the brightness reaches its maximum value, the brightness of the controlled light is then
smoothly decreased to a system-wide minimum value at a rate of 10 percent per second.
3. When the brightness reaches its minimum value, the use case continues at subflow step 1.
When the Resident releases the On/Off/Dim button:
4. The use case terminates and the brightness stays at the current leveL
Identifying the Pre- and Post-conditions
For most cases, you will need to identify pre-conditions that affect the behavior of the system
described in the use case and to describe post-conditions, such as system state or persistent data
that is left when the use case is complete. There can be significant work involved in fully
defining pre- and post-conditions; however, you need to use pre- and post-conditions only when
necessary to clarify the behavior expressed in the use case. Figure 21-3 may help you discover
the pre- and post-conditions for your use case.
Pre-conditions for the Control Light Use Case
The selected On/Off/Dim button must be Dim Enabled.
The selected On/Off/Dim button must be preprogrammed to control a Light Bank.
Similarly, we need to identify post-conditions. In our use case, in order for the brightness to
begin at the proper level when the Resident uses the switch the next time, the system must
remember the previous brightness level that was set for a selected Control Switch button after a
dimming action has occurred. So, this is a post-condition that we'll record in the use case.
Post-condition for the Control Light Use Case
On leaving this use case, the system remembers the current brightness level for the
selected On/Off/Dim button.
Extending Use Cases
As the system evolves over time, additional features and functionality will
be added to meet new or existing user needs. Indeed, if the scope of your
project was originally two times what your team could accomplish, then
you will have necessarily eliminated half of the functionality in the first
release or you will not have released the project on time. In some cases,
this means that you simply deferred use cases from that release to the next,
and you can add them to the use-case model at the next iteration.
However, it's even more likely that many of the use cases you've
implemented didn't do everything you could envision doing for the user.
In other words, you "scope managed" the use cases themselves by not
implementing all that was envisioned.
The extend relationship can simplify maintenance of the use case and allow the team to
focus and elaborate on the extended ("what's new or different") functionality, as an entity,
without worrying about rereading or managing the base use case itself.
2. When an extension is envisioned as a use case is developed, extension points can be
provided in the base use case as a map to "future features." This provides an indication of
future intent to the design team and may aid development of a more robust architecture. It
also provides a pointer to the area of the use case that needs further development in the
next release.
3. The extended use case may represent optional behavior, as opposed to a new, basic, or
alternative flow.
Including Use Cases in Other Use Cases
As the use cases are refined and elaborated, it is likely that the team will
discover that certain patterns of user and system behavior reoccur in a
variety of places. Indeed, it's possible that some significant percentage of
the functionality of the system occurs in multiple use cases. Examples
include entering a password for user validation, performing a system
status check before proceeding with a transaction that commits a change to
data, selecting separate items from a table in a user interface, and so on.
As this develops, the team members will find that they are creating
redundant documentation in multiple use cases. Besides the volume
problem, a worse problem happens when the common behavior changes
since the change must be reflected in every use case that uses the common
behavior. Those locations may not be obvious, and the process of making
all necessary changes may be tedious and error prone