UML Weekend Crash Course™ - To Parent Directory

Session 7—Building the Use Case Narrative 71
value between 1 and 10, the second must be an integer greater than 100, and the character
string can only be 30 characters in length. Without publishing these pre-conditions, anyone
who wants to use your Use Case is forced into relying on trial and error to find the correct
set of values.
Tip
Notice how rapidly we bring precision to the model from the simple beginnings
of the Use Case diagram. You’ll find the analysis process akin to pulling a
thread on an old sweater. If you keep pulling, eventually you’ll unravel the
whole complex problem (while your mother yells at you for destroying a perfectly
good sweater). Using simple checklists to remind you of the questions
to ask can expedite the process and build a successful pattern of thought for
problem solving. As you gain experience, modify the list of questions and tasks
to improve the process and to make it your own.
The goal is not to become a disciple of a particular technique, but to find a
technique that works for you.
Use Case initiation
A Use Case has to start somehow, but how Some Use Cases start because an actor says,
“Start.” For example, you can select an option on a menu. The action tells the system to
open the application. Time can also trigger a Use Case. Most software shops have scheduling
software that kicks off programs at a preset time. Other Use Cases are implemented as objects
themselves that watch for a point in time. A Use Case may be triggered by a system event
like an error condition, a lost connection, or a signal from a device.
Use Case initiation provides a place to think through all the possible triggers that could
launch the Use Case. This is critical when you start thinking about reusing Use Cases. If five
actors and/or Use Cases plan on using the same Use Case, then you need to know how each
user plans to kick it off. If each has different expectations, then you could be creating a
problem. Multiple triggering mechanisms lead to high coupling and low independence. In
other words, every time you change one of the triggers, you need to change the corresponding
Use Case and make certain that you haven’t created problems with the other triggering
mechanisms. More triggers mean more complicated and costly maintenance.
Dialog
The dialog refers to a step-by-step description of the conversation between the Use Case
(the system) and the user (an actor or another Use Case). Very often, it is helpful to model
this sequence of events using an Activity diagram just as you might model a procedure for
communication between two business units.
For example, you want to withdraw money, so you access the ATM at your local bank. The
following dialog ensues:
You get past the security check Use Case, and you’re presented with a menu of options.
You choose “Withdraw.”
The system immediately asks you which account you want to withdraw the money
from.