|
|
Events originating externally to a system occur randomly: we can't predict, for example, when a user is going to click a button on a GUI. In order 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. Rather, they must be orchestrated in such as way as to lead, in 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 of 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
A sequence of events esp. when imagined; esp : an account or synopsis of a possible course of action or events.
which is precisely how the term is used in the object modeling sense.
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 may 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 is able to 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, however, that even though we're now concerned with internal system processes, we're still only interested in functional requirements as defined in Chapter 9, not in the "bits and bytes" of how the computer works.)
The following is a sample scenario representing the "Register for a Course" use case, one of several use cases that we identified for the SRS in Chapter 9.
In this first scenario, a student by the name of Fred successfully registers for a course. The specific sequence of events is as follows:
He views the schedule of classes for the current semester to determine which section(s) he wishes to register for.
Fred requests a seat in a particular section of a course titled "Beginning Objects," course number OBJ101, 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 of 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 wishes to register for OBJ101, section 1 by choosing it from the available course list, and then clicks the Add button (see Figure 11-5).
A few moments later, Fred receives a confirmation message, as shown in Figure 11-6.
Fred's unaware (for the most part) of all of the "behind the scenes" processing steps that are taking place on his behalf!
The preceding scenario represents a "best case" scenario, where 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 that are shown in bold.
In this scenario, Fred once again attempts to register for a course; while he meets all of 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 wishes to register for.
Fred requests a seat in a particular section of a course titled "Beginning Objects," course number OBJ101, 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 of 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 wishes 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?/td> |
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 observe the future users of the system that we're modeling as they go about performing the same business functions today. In the case of student registration, for example, what manual or automated steps does a student have to go through presently 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're going to 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.
|
|
