Determining State Classes
Recall that Use Cases contain a set of event flows, organized as a dialog between one or more Actors and a System.
Here is a sample event flow for a hypothetical ATM use case called “Withdraw Cash”:
|
Actor Action |
System Response |
|
1. Customer inserts bank card |
2. Ask for PIN |
|
3. Customer enters PIN |
4. If accurate PIN, present service options |
|
5. Customer chooses to withdraw cash |
6. Inquire amount to withdraw |
|
7. Customer enters amount |
8. If funds requested available, dispense cash |
|
9. Customer retrieves cash |
10. Thank current Customer, prepare for next Customer |
The process of deciding on the appropriate State classes is iterative and somewhat subjective. For example, you could create a separate State for each action/response pair, or you could use some other criteria. Here’s a sample set of States for this Use Case:
AuthenticationState (flows 1-4)
ChoosingAmongOptionsState (flows 4-7)
EnsuringFundsAvailabilityState (flow 8)
DispensingCashState (flows 8-10)
In general, we decide which event flow steps belong to which State object. If you can’t think of more than one state, that’s okay, more may come in the future. You are laying the foundation for scalable, adaptable code.
Guidelines
There are no hard and fast rules, but generally we choose States based upon some time-consuming action that yields some verifiable response which leads to an “idle” state – where the System requires more interaction from the Actor.