Indicating Alternative Courses of Behavior

As the main course is just one possible course through the use case, if there are other ways of reaching the actor’s goals, you need to construct other courses for each way. Each possible path through a use case is called a scenario. Consider a scenario as an instance of a use case, which you may diagram as shown in Figure 9-2. The use-case instances use the same oval notation as the use cases, but have their instance name, in the standard underlined format, as follows:

 scenario name: use-case name

Figure 9-2: Scenarios of a use case.

The modeling notation shown in Figure 9-2 is similar to that of classes and their instances, objects, which is covered in Chapter 3. Name each scenario so that they are easily distinguished using the format for object instances.

There are often infinite potential instances of use cases, each of which is a slightly different path through the use case, with different values for user input, or different number of errors occurring in different orders. However, don’t bother to even try to identify all of these. You should just identify the ones that yield quantitatively different results. For example, identify different ways of meeting the goals or different error messages. Construct scenarios that span all errors, exceptions, or variations of flow. Ultimately, the set of scenarios that you identify should exhaust all the logic of the use case.

Each scenario you identify has to be a possible path through the use cases. Thus you’ll probably have to construct a separate flow of events for every scenario you’ve found. Each of these additional flows is usually called an alternate course. Document the alternate courses in the same way as the main course.

Tip This might seem a bit redundant. The scenario in which the credit card is accepted is very similar to the scenario in which the credit card is rejected, at least, up to the point of rejection. Luckily, it’s not necessary to duplicate steps mentioned in previous courses. When you start an alternate course, indicate the step from which it branches off and the conditions that cause the branch off.

When you end an alternate course, it has several possibilities:

The use case ends because the goal is reached in an alternative way. Write a postcondition to indicate the results of this course.
The use case ends because it’s not possible to reach a successful conclusion. Write a postcondition to indicate the results of abandoning the use case.
The use case resumes at a previous step to re-attempt a failed behavior. Indicate the next step in the original course that follows.
The use case accomplishes a subgoal in a different way so that it skips a group of steps and rejoins at a latter step. Indicate the next step in the original course that follows.

Here’s an example of an alternate course

Alternate course #1: Invalid reservation day span.

Precondition: At Step 2, the actor enters an invalid reservation day span (more than 1 month, or less than 1 day).

The System validates inputs but the reservation day span fails validation.
- The System displays an error message indicating the problem to be fixed.
- The System prompts for correct reservation span.
Processing continues with Step 2.1 of the main course.

Tip You may become tempted to use control syntax, such as IF, ENDIF, DO, FOR, or CONTINUE AT, to minimize the number of alternate flows in a use case, but it’s best to avoid such things altogether. If you yield to temptation, you’ll find in hard to stop and the flow would quickly become unreadable.

Remember When you describe use cases to specify requirements for your system, you want to use the language of the user. That way, your users will be able to clearly understand what the system does for them—and they can better review and critique your use cases.

Another common approach to capturing the courses or flow that you might use is table-oriented steps. The following example shows how a main course and a few of the possible alternate courses could be captured using the table-oriented steps:

Use-case name: Make Room Reservation

Description: The actor Potential Guest uses a Web browser to specify desired room features and dates, and to obtain from the system a confirmed room reservation.

Main course of events: Successful credit card transaction.

Precondition: Actor reaches the hotel’s home Web page wanting to make a reservation.

Successful postcondition: Actor has a confirmed room reservation.

Potential Guest	System	Credit Card Authorization System
1. This use case starts when the actor visits the opening Web page.	2. Prompts for span of reservation (in days) and room type.
3. Identifies type of room (bed size and is smoking allowed) and span (in days) of reservation.	4. Validates inputs using Data-Validation Rules1 and 2.
	5. Determines available matching room classes.
	6. For each available room class, determines reservation cost. (See Business Rule 1.)
	7. Displays possible reservations.
	8. Prompts for a choice.
9. Selects desired room.	10. Prompts for billing information.
11. Supplies name, billing address, credit card number, and expiration date.	12. Validates the inputs, using Data-Validation Rules 3 through 6.
	13. Sends transaction to Credit Card Authorization system.	14. Reports transaction is accepted.
	15. Marks room as reserved by Potential Guest over the specified time period (to prevent subsequent reservations).
	16. Calculates unique reservation number. (See Business Rule 2.)
	17. Informs Potential Guest of success.
18. This use case ends when the actor, satisfied with the reservation, leaves the system.

Alternate course #1: Invalid reservation day span.

Precondition: At Step 3 of the main course, the actor enters an invalid reservation day span (more than 1 month, or less than 1 day).

Potential Guest	System	Credit Card Authorization System
	1. Fails Reservation Day Span validation.
	2. Displays error message, indicating problem to be fixed.
	3. Prompts for corrected reservation span (days).
4. Use case continues with Step 3 of the main course.

Alternate course #2: Credit card authorization fails.

Precondition: At Step 14 of the main course, the Credit Card Authorization System rejects the transaction.

Potential Guest	System	Credit Card Authorization System
		1. Rejects transaction.
	2. Informs Actor of transaction rejection.
	3. Prompts for corrected or different credit card.
4. Use case continues with Step 11 of the main course

Alternate course #3: Reservation canceled.

Precondition: At any of Steps 3, 9, or 11 in the main course, the actor desires to cancel the reservation.

Postcondition: This use case ends with no reservation made.

Potential Guest	System	Credit Card Authorization System
1. Indicates Cancel or	2. Cancels ongoing leaves Web page.transaction.

In this example, we occasionally refer to Business Rules (for example, Step 6) and Data-Validation Rules (Steps 4 and 12). Some use-case authors place the details of the field validations and algorithmic calculations in line with the steps. This is acceptable, but we prefer to refer to the rules, and place them somewhere else, usually at the end of the document. If you place the rules right inside of the steps, the steps can get very long and difficult to read. Readability should be one of your most important goals when you write use cases, because you are attempting to get agreement and buy-in from your stakeholders and other developers. In addition, business rules and data validations tend to change often—so it’s best to take the ones shown here out of your final steps so the steps don’t have to change.

Here are some examples of the business and data-validation rules that we referred to in our example. The business rule helps calculate the room prices; the data-validation rules prevents reservations of less than one day or more than one month. Here’s what they look like:

 Business Rules: 1.  DoubleOccupancyPrice = 1.75*BaseRoomPrice Data-Validation Rules: 2.  Day Span: Date1 -- Date2  Format:   MM/DD/YY -- MM/DD/YY aDate2 > Date1 bDate2 - Date1 =  1 cDate2 - Date1 = 31

As we write out use cases, we need to be aware of situations that may cause problems with the design—or the implementation—of the use case. Here’s an example of a typical design note that would apply to our use case:

Design note:
If more than one Potential Guest could be running this use case at the same time, there is the possibility that they may be attempting to reserve the same room(s). This can cause inconsistent results. The design must consider locking (preventing another actor from selecting) the offered rooms until one is selected, and then locking the selected room until the reservation is confirmed or canceled.