Object-Oriented Analysis and Design 33911
- What information must the actor provide to the system?
Enter a Personal ID number.
Aha! We need use cases for obtaining and editing the Personal ID number. - What information does the actor hope to get from the system?
Balances, and so on.
You can often find additional use cases by focusing on the attributes of the objects in the
domain. The customer has a name, a PIN, and an account number; do you have use cases
to manage these objects? An account has an account number, a balance, and a transaction
history; have these elements been captured in the use cases?
After the customer use cases have been explored in detail, the next step in fleshing out
the list of use cases is to develop the use cases for each of the other actors. The following
list shows a reasonable first set of use cases for the ATM example:
- Customer checks his balances.
- Customer deposits money to his account.
- Customer withdraws money from his account.
- Customer transfers money between accounts.
- Customer opens an account.
- Customer closes an account.
- Customer logs in to his account.
- Customer checks recent transactions.
- Bank clerk logs in to special management account.
- Bank clerk makes an adjustment to a customer’s account.
- A back-office system updates a user’s account based on external activity.
- Changes in a user’s account are reflected in a back-office system.
- The ATM signals it is out of cash to dispense.
- The bank technician fills the ATM with cash and supplies.
Creating the Domain Model
After you have a first cut at your use cases, the requirements document can be fleshed
out with a detailed domain model. The domain modelis a document that captures all you
know about the domain (the field of business you are working in). As part of your
domain model, you create domain objects that describe all the objects mentioned in your
use cases. So far, the ATM example includes these objects: customer, bank personnel,
back-office systems, checking account, savings account, and so forth.