- Let's Review that Process...
- Meet Neil & Gordon...
- Task List
- The Development Process
- ...One More Time
- System Design
- Agile Waterfalls
- Use Cases
- What If...?
- UML State Diagrams
- An Example
- Specification Components
- User Requirements
- ...One More Time
- Creating executables
- Compiled or Interpreted?
- Just-in-Time...
This chapter is from the book
This chapter is from the book
This chapter is from the book
What If...?
Our use case describes an ideal interaction between the user and the system. That’s great, but we all know that the world hardly ever runs according to plan, and a resilient system can’t ignore that. So in addition to the ideal case, you’ll need to capture what could go wrong (as best you can), and what the system should do when it does. Think of them as Murphy’s Law cases...
In our simple example, the ingredient the user is looking for might not be on the list. Or there might be a system problem. For example, the database containing the ingredients and suppliers might not be available at runtime. What should the system do when these things happen?
Alternate paths through the system aren’t always the result of problems, of course. Sometimes the user just needs to do something a little differently. Whatever their source, these alternate paths should be captured as part of the use case. Our revised version looks like this:
Put on Your Thinking Hat
Time to try writing some use cases on your own. Based on the descriptions below, try writing out the basic steps and one or two alternate paths for each case.
“Our recipes are based on a number of servings that’s right for the restaurant, but for catering, we often need to scale them up or down. That math is really ugly, and it’s easy to make mistakes.”
“The catering side of the restaurant is starting to really take off. I keep the clients’ contact details in my agenda, so if Gordon needs to contact them directly, he has to ask me for them. That’s a waste of time.”
Extra credit: Each of these use cases implies the existence of others. Can you identify them?
How’d You Do?
These cases are based on imaginary conversations. Your imaginary conversation might be different, so don’t worry if you have slightly different results. The important thing is that you get some practice thinking through the steps.
“Our recipes are based on a number of servings that’s right for the restaurant, but for catering, we often need to scale them up or down. That math is really ugly, and it’s easy to make mistakes.”
)
“The catering side of the restaurant is starting to really take off. I keep the clients’ contact details in my agenda, so if Gordon needs to contact them directly, he has to ask me for them. That’s a waste of time.”
Ideal Case:
- System displays list of clients, alphabetically by type.
- User selects client from list. System displays contact details.
Client not found:
No action.
System error:
System displays descriptive message.
Extra Credit:
The client details system implies a case to enter and edit client details, while the portioning system implies a case to enter ingredients and one to enter recipes. Both systems probably require a printing case, as well.
Did you think of any others?