Use case diagram for ATM system
This use case diagram shows what people and systems can do with an ATM. A **Customer** and a **Bank server** interact with five use cases inside the ATM boundary, linked by include and extend relationships. It is a good starting point for students learning UML and for developers outlining ATM or banking software requirements.
Example: Use case diagram for ATM system: click to open it in the editor and change it.
Actors
- Customer: the primary actor. Starts Withdraw cash, Check balance and Transfer funds.
- Bank server: a secondary actor on the right side. It takes part in Withdraw cash and Transfer funds, where the bank's records must be updated.
Use cases inside the ATM boundary
| Use case | Connected to | Relationship |
|---|---|---|
| Withdraw cash | Customer, Bank server | Association |
| Check balance | Customer | Association |
| Transfer funds | Customer, Bank server | Association |
| Authenticate (PIN) | Withdraw cash, Check balance, Transfer funds | «include» |
| Print receipt | Withdraw cash | «extend» |
Include and extend relationships
Authenticate (PIN) is included by Withdraw cash, Check balance and Transfer funds. This means every one of those actions always requires the customer to enter a valid PIN first. Modeling it once as a shared use case avoids repeating the same steps three times.
Print receipt extends Withdraw cash. It is optional behavior that only happens under certain conditions, such as when the customer asks for a receipt. The base withdrawal works fine without it.
How to adapt it for your project
- Add use cases your ATM needs, such as Deposit cash or Change PIN, and decide if they include Authenticate (PIN).
- Link Check balance to the Bank server if your design fetches balances live.
- Let Print receipt extend Transfer funds or Check balance too, if receipts are offered there.
- Add actors like a Technician for maintenance tasks such as refilling cash.
Tip: Arrows for «include» point from the base use case to the included one, while «extend» arrows point from the optional use case to the base. Here, Withdraw cash points to Authenticate (PIN), but Print receipt points to Withdraw cash.
Frequently asked questions
What are the actors in a use case diagram for an ATM system?
This diagram has two actors: the **Customer**, who starts transactions, and the **Bank server**, which takes part in withdrawals and fund transfers.
Why is Authenticate (PIN) an include relationship in the ATM use case diagram?
Withdrawing cash, checking a balance and transferring funds all require PIN verification every time. «include» shows this mandatory shared step once instead of repeating it in each use case.
What is the difference between include and extend in the ATM diagram?
«include» marks behavior that always happens, like **Authenticate (PIN)**. «extend» marks optional behavior, like **Print receipt**, which is added to **Withdraw cash** only when needed.
Make your own use case diagram with AI →