UML Weekend Crash Course™ - To Parent Directory

Session 5—Understanding the Use Case Model 55
Withdraw Cash
Update Account
Withdraw Cash
with Overdraft
Protection
Protect Overdraft
Figure 5-6 Use Case notation for the Use Case diagram
By defining Use Cases in this manner, the system is defined as a set of requirements rather
than a solution. You do not describe how the system must work. You describe what the system
must be able to do. The Use Cases describe only those features visible and meaningful to
the actors who use the system. Keeping this in mind will help you avoid functional decomposition,
the breaking down of procedures and tasks into smaller and smaller processes until
you have described all the internal workings of the system. One of the pitfalls of systems
development is going over budget, which happens when you don’t limit the scope of each
task or you make a model too inclusive. The UML provides seven diagrams, in addition to the
Use Case Model, for fully describing the solution for the system, so remember that you can
save some work for later.
Tip
One very common question about Use Cases is, “What requirements belong
on the Use Case diagram and what requirements should be explained elsewhere”
The simplest answer I’ve found is, “Model only the features of the
system that can be seen by an actor.”
For example, the system must save data to a database, but the actor can’t
actually see this happening. The most they typically see is a message indicating
that it did. In this situation, the Use Case level requirement is a
message indicating success or failure on the save function, not the save
function itself.
Use Case relationships
So far, I’ve defined the system, actors, and Use Cases, but now you need to associate each
user with the system features they need to perform their jobs.