A scenario is a particular actor-system interaction corresponding to a use case. It is a specific example of a use case
execution in the system's operational environment. Scenarios have branching points at which there may be several
responses or actions available to either the actor or the system. By this definition, many scenarios are required to
fully elaborate a use case--typically one dozen to several dozen.
The object analysis model (aka PIM) executes to meet the functional requirements of the system, but is almost
inevitably inadequate in terms of performance and other design considerations. As we add design elements, we elaborate
the scenarios to ensure not only that the functionality isn't broken by our design decisions but also that the desired
design optimizations are achieved.
It is not possible to completely test all parts/interactions of a system at once. Therefore, scenarios are used to test
a system in parts. A scenario shows how collaborations of objects interact. It represents typical paths through the
state space as the system is used. Scenarios may not visit all states in all the participant objects nor activate all
transitions, but they provide an order-dependent view of how the set of objects is expected to behave under some set of
conditions with a specific ordering of external and internal stimuli. Because a scenario does not have enough
information to fully define the complete behavioral model of an object, scenarios are said to be partially
constructive. They can add operations and event handling to a state model, but they do not fully define the model.
It is best to start with the most simple and straight-forward scenario, execute and test that scenario, then add the
next most simple and straight-forward scenario, execute and test that scenario, etc. By starting off small and working
towards more complex scenarios, you can ensure that the most basic parts of your system are correct before trying to
test more complex aspects.
|