11.2. Scenarios
Events originating externally to a system occur randomly; we can't predict, for example, when a user will click a button on a GUI. For a system to perform useful functions, however, the internal events that arise in response to these external events—in other words, the messages that objects exchange in carrying out some system function—can't be left to occur randomly. Instead, they must be orchestrated in such as way as to lead, in a cause-and-effect fashion, to some desired result. In the same way that a musical score indicates which notes must be played by various instruments to produce a melody, a scenario prescribes the sequence of internal messages (events) that must occur in carrying out some system function from beginning to end.
We introduced use cases in Chapter 9 as a way to specify all the goals for a system from the standpoint of external actors—users or other computer systems. Merriam-Webster's Collegiate Dictionary, Eleventh Edition defines the term scenario as follows (which is precisely how the term is used in the object modeling sense):
A sequence of events especially when imagined; especially an account or synopsis of a possible course of action or events.
A scenario is one hypothetical instance of how a particular use case might play out. Just as an object is an instance of a class, and a link is an instance of an association, a scenario might be thought of as an instance of a use case. Or, stated another way, just as a class is a template for creating objects, and an association is a template for creating links, a use case is a template for creating scenarios. A single use case thus inspires many different scenarios, in the same way that planning a driving trip from one city to another can involve many different routes.
We describe scenarios in narrative fashion, as a series of steps observed from the standpoint of a hypothetical observer who can see not only what is happening outwardly as the system carries out a particular request but also what is going on behind the scenes, internally to the system.
NOTE
Even though we're now concerned with internal system processes, we're still interested only in functional requirements (as defined in Chapter 9), not in the technical requirements of how the computer works.
The following is a sample scenario representing the "Register for a Section" use case, one of several use cases identified for the SRS in Chapter 9.
11.2.1. Scenario #1 for the "Register for a Section" Use Case
In this first scenario, a student named Fred successfully registers for a section of a course. The specific sequence of events is as follows:
Fred, a student, logs on to the SRS.
He views the schedule of classes for the current semester to determine which section(s) he wants to register for.
Fred requests a seat in a particular section of a course titled "Beginning Computer Technology," course number CMP101, section 1.
Fred's plan of study is checked to ensure that the requested course is appropriate for his overall degree goals. (We assume that students are not permitted to take courses outside of their plans of study.)
His transcript is checked to ensure that he has satisfied all the prerequisites for the requested course, if there are any.
Seating availability in the section is confirmed.
The section is added to Fred's current course load.
From Fred's vantage point (sitting in front of a computer screen!), here's what he perceives to be occurring: after logging on to the SRS, he indicates that he wants to register for CMP101, section 1 by choosing it from the available course list, and then clicks the Add button (see Figure 11-5).
Figure 11.5. Fred's view of things, part 1
A few moments later, Fred receives a confirmation message, as shown in Figure 11-6.
Figure 11.6. Fred's view of things, part 2
Fred is unaware (for the most part) of all the behind-the-scenes processing steps that are taking place on his behalf!
The preceding scenario represents a best-case scenario, in which everything goes smoothly, and Fred ends up being successfully registered for the requested course. But as we know all too well, things don't always work out this smoothly, as evidenced by the following alternative scenario for the same use case. Everything is the same between Scenarios #1 and #2 except for the steps shown in italic.
11.2.2. Scenario #2 for the "Register for a Section" Use Case
In this scenario, Fred once again attempts to register for a section of a course; although he meets all the requirements, the requested section is unfortunately full. The SRS offers Fred the option of putting his name on a wait list. The specific sequence of events is as follows:
Fred, a student, logs on to the SRS.
Fred views the schedule of classes for the current semester to determine which section(s) he wants to register for.
Fred requests a seat in a particular section of a course titled "Beginning Computer Technology," course number CMP101, section 1.
Fred's plan of study is checked to ensure that the requested course is appropriate for his overall degree goals.
His transcript is checked to ensure that he has satisfied all the prerequisites for the requested course, if any.
Seating availability in the section is checked, but the section is found to be full.
Fred is asked if he wants to be put on a first come, first served wait list.
Fred elects to be placed on the wait list.
With a little imagination, you can undoubtedly think of numerous other scenarios for this use case, involving such circumstances as Fred having requested a course that isn't called for by his plan of study, or a course for which he hasn't met the prerequisites. And, there are many other use cases to be considered, as well, as were discussed in Chapter 9.
NOTE
Are there practical limits to the number of alternative scenarios that one should consider for a given use case? As with all requirements analysis, the criteria for when to stop are somewhat subjective; we stop when it appears that we can no longer generate significantly different scenarios; trivial variations are to be avoided.
When devising scenarios, it's often helpful to imagine the future users of the system that we're modeling as they go about performing the same business functions today. In the case of current student registration, for example, what manual or automated steps does a student have to go through to register for a course? What steps does the university take before deeming a student eligible to register? Whether the registration process is 100 percent manual at present or is based on an automated system that you'll be replacing or augmenting, observing the steps that are involved today in carrying out a particular business goal can serve as the basis for one or more useful scenarios.
Scenarios, once written, should be added to our project's use case documentation; generally, we pair all scenarios with their associated use cases in that document.
Why are scenarios so important? Because they are the means by which we start to gain insight into the behaviors that will be required of our objects. We'll need a way to formalize these scenarios so that the actual methods needed for each of our classes become apparent; UML sequence diagrams are the means by which we do so, so let's now discuss how to prepare these.