UML Weekend Crash Course™ - To Parent Directory

72
Saturday Morning
You reply that you want to withdraw from your primary checking account.
The system then asks you how much you want to withdraw.
You say that you want $47.
The system gives you a nasty error message saying it can’t handle that number
(because it’s not a multiple of 20) and you need to try again.
Then you say you want $4,700.
The system again complains that you can’t take that much money out in a 48-hour
period.
“Okay, okay! Give me $100,” you tell the system.
Now the system is happy and it gives you the money and a receipt.
When goals remain separate from implementation, you can evolve systems whose interface
designs remain stable while their implementations take advantage of ever-improving user
interface technologies. This conversation could just as easily have happened with any manufacturer’s
ATM even if it held different cash denominations (10’s versus 20’s), connected
directly to a bank, or connected via a nationwide network. Also, you begin to see that some
of the steps don’t necessarily have to happen in the sequence presented here. The goal of the
dialog is to uncover just what really needs to happen and what variations could be valid.
Even ATM interface designs vary. Have you ever seen an ATM designed for blind people
It performs the exact same conversation but with a different user interface. My home banking
software accomplishes essentially the same function, too, but with still a different
design for the interface. The system asks all the questions at once and I provide all the
answers at once. Same design, different interface.
Use Case termination
Although there is usually only one triggering event to start a Use Case, there are often
many ways to end one. You can pretty much count on some kind of normal termination
where everything goes as planned and you get the result you anticipated. But things do go
wrong. This could mean shutting down the Use Case with an error message, rolling back a
transaction, or simply canceling. Each termination mechanism has to be addressed in the
dialog.
The list of termination options is a bit redundant with the dialog, but just as was the
case with pre-conditions, this redundancy provides some good checks and balances.
Post-conditions
Post-conditions describe a state of the system that must be true when the Use Case ends. You
may never know what comes after the Use Case terminates, so you must guarantee that the
system is in a stable state when it does end. In fact, some people use the term guarantee for
just this reason. You guarantee certain things to be true when this Use Case completes its
job. You might, for instance, guarantee to give the user a receipt at the end of the transaction,
whether it succeeded or failed. You might promise to notify the user of the result
of an attempted save to the database.