1

How Use Cases Evolve
 Early efforts typically define most of the major use cases.


The refining stages complete the process by describing all the use cases needed to define the system.
We have “enough” use cases when they describe all possible ways in which the system can be used, at a level of specificity suitable to drive design, implementation, and testing.
 Use case refinement is not system decomposition.
2

The Steps in Refining a Use
Case
 Review the actors – Upon closer examination there may be more actors
(not seen by the user) that interact with the use case. (E.g., Light Bank)
 Review the name – Make sure that the name of the use case indicates what is achieved by its interaction with the actor(s). (E.g., change “Turn Light
On/Off” to “Control Light”)
3

The Steps in Refining a Use
Case (Cont’d)
 Refine the description – Update the description as necessary based on changes made.
 Define and refine the flow of events –
Based on the changes in the description, refine the event flow. This is usually a textual description, but it could be in the form of UML interaction diagrams or some other representation.
4

The Steps in Refining a Use
Case (Cont’d)
 Define and refine the flow of events (cont’d) –
Be sure to document all alternative flows, including all error conditions. ( Defining and managing alternative flows and error conditions may be as much work, and contribute as much or more to the ultimate success of the system, as developing the requirements, architecture, and implementation for the “happy day” flow .)
Now is a good time for brainstorming, especially involving testers.
5

The Steps in Refining a Use
Case (Cont’d)
 Identify the pre- and post-conditions –
 A pre-condition is the state of the system and its surroundings that is required before the use case can begin.
 Post-conditions are the states the system can be in, including the state of persistent data, after the use case ends.
 The states described by pre- or postconditions should be states that the user can observe.
6

The Steps in Refining a Use
Case (Cont’d)
 Identify the pre- and postconditions (cont’d) –



A pre-condition is a constraint on when a use case can start. It is not the event that starts the use case.
Pre- and post-conditions for a use case are not for only one individual flow, although you can define them at that level.
A post-condition for a use case should be true regardless of which alternative flows were executed. If the action could fail, you cover it in the postcondition by saying “If nothing failed then . . .”
7

The Steps in Refining a Use
Case (Cont’d)
 Identify the pre- and postconditions (cont’d) –

 Post-conditions can be an important tool for describing use cases. You first define what the use case is supposed to achieve, the post-condition.
You can then describe how to reach this condition
(the flow of events needed.)
Identify special requirements – Identify any nonfunctional requirements, like those relating to usability, reliability, performance, etc. that might be relevant for the specific use case in question.
8

Extending Use Cases Using the <<extend>> Relationship




Why extend an existing use case rather than simply rewriting original one.
The extend relationship can simplify maintenance of the use and allow the team to focus and elaborate on the extended functionality, as an entity, without worrying about rereading or managing the base case itself.
When an extension is envisioned as a use case is developed, extension points can be provided in the base use case as a map to “future features”.
The extended use case may represent optional behavior, as opposed to a new, basic, or alternate flow.
9



From the perspective of the flow of events, under certain defined circumstances, a use case executes the extended flow of the use case as if it were an alternate flow, but upon completion, flow of the use case returns to the extension point in the base use case.
In order to apply this construct, all that is required it to indicate the extension points in the basic flow and the conditions under which the extended flow is to be executed.
10



These conditions are expressed in what is called a condition guard, which is a state that must be true for the extension to execute.
In order to simplify maintenance, the conditional guard and the extension points may be described in the extending use case, in which case the base use case will be entirely unaffected by the existence of the extension.
11

Including Use Cases in Other
Use Cases




Often certain patterns of user and system behavior reoccur in a variety of places.
This cause the generation of redundant documentation in multiple use cases.
An when a change is required in this common behavior, it has to be made in multiple places.
A new use case can be defined with just this common behavior and accessed, just like a subprogram, using the include relationship.
12