The best representation for a scenario is:
-
Sequence diagram, if the primary focus is on the sequence of messages and the interaction of multiple object roles
-
Timing diagram, if the primary focus is on the timing of events and when the object roles involved change states
with respect to each other
Sequence diagrams are usually the best representation for most scenarios. Scenarios should contain:
-
A comment that describes:
-
-
the use case the scenario describes
-
the name of the scenario
-
the purpose of the scenario
-
an overview of the message flow
-
pre- conditions
-
post- conditions
-
At least 3 messages
-
Parameters on messages (operations or event receptions) and return values
-
Quality of service constraints
-
Textual comment describing why the scenario is unfolding as it is unfolding
When the same message flow exists for a set of values (e.g. fault conditions resulting in exactly the same
behavior) then the scenario should describe the equivalent class for the scenario - that is, it should
enumerate the list of values for which the scenario is valid, within a constraint.
When constructing a set of scenarios for a use case, each transition path in the use case state machine should be
represented in at least once scenario. To come up with the minimal spanning set of scenarios, keep adding
scenarios until all requirements bound to that use case are represented within at least one scenario. You may choose to
add more scenarios if desired, but the minimal spanning set must be captured.
|