UML Exercise ATM Use-case diagram

Question

I have an assignment in which the following conditions are set forth:

Brief Statement of Purpose: An ATM is an electronic device designed for automated dispensing of money. A user can withdraw money quickly and easily after authorization. The user interacts with the system through a card reader and a numerical keypad. A small display screen allows messages and information to be displayed to the user. Bank members can access special functions such as ordering a statement Brief Summary of Requirements: The ATM is required 1. To allow authorized card holders to make transactions

1. Card holders shall view and/or print account balances
2. Card holder shall make cash withdrawals
3. Card holder shall make cash or check deposits
4. Card holder shall quit session

To allow bank members to access additional, special services

1. A bank member shall be able to order a statement
2. A bank member shall be able to change security details (e.g. PIN number)

To allow access to authorized bank staff

1. Authorized staff can gain access to re-stock the machine

2. Authorized staff are able to carry out routine servicing and maintenance

3. To keep track of how much money it contains and alert bank staff when stocks are getting low

Additional Notes: Users shall be able to access the ATM by punching in their account number and PIN. Once the system has verified that the account is active and the PIN matches with the account number, the system offers the users four choices. Users can withdraw money, deposit money, check balance or quit the session. The user must have a minimum of $100 in his / her account. At the end of any transaction a printed copy of the transaction is provided to the user. A transaction could be - withdraw money, deposit money or check balance. Once the user has completed a transaction, the system offers the user the same four choices, until the user decides to quit.

The system shall interface with the device to dispense cash, the device to accept cash or check and the printer. Since we have not studied databases in this course, the system will keep all the information in two RandomAccess files. One file will hold the passwords and the other account balances.

I have built the following use-case diagram but am confused about how detailed it's supposed to be and what should be an extension/inclusion and what should just be a base case. Any feedback would be welcomed.

Should bank members and card holders be separate or together? Technically bank members can do more than a card holder like update security details or order statements, but aren't all bank members card holders?

Here is the other version I have, minus quit not being a use case, are there other factors that are incorrect?

Answer 1

Here are a couple of observations:

• As commented, Quit is no use case as it does not add any value to the actor. Rather it looks like post-conditions for other use cases.
• Generalizing use cases is a bad idea (although allowed per UML). A use case shows a single unique piece of added value for a actor using the system under consideration. In that context grouping serveral use cases under the hat of a "common" use case is not helpful. Rather connect the specializations directly with the actor and remove that Transaction.
• Instead of duplicating the Bank Members's associations to Quit/Transaction you can draw a generalization to Auth Card Holders.
• Better use the singular for an actor. It's a general role name and per se covers any amount of real persons/machines.
• A part of the requirement/description are scenarios which go into use cases. It's common mistake to try to expose these in functional decomposition in use cases.

Your attempt is not bad. But creating use cases from requirements is not easy and needs a lot of experience. So (like always) I recommend to read Bittner/Spence about use cases. (Do not read the UML specs to get an idea of UC synthesis. They are at best able to give the syntax how to use bubbles and stick men.)

---

As commented by www.admiraalit.nl there "might be" applications for generalizing use cases and you can discuss that controversially. It's my own preference to not use them since using it wrongly is more easy than using it right. The same goes for export/import. Avoid it as long as you don't know exactly what it's good for. You tend to starting functional decomposition which is not what UCs are good for.