Grokking the Object Oriented Design Interview

0% completed

Design an ATM

On This Page

Requirements and Goals of the System

How ATM works?

Use cases

Activity Diagram

Sequence Diagram

Code

Stage 1: the money and the card

Stage 2: the parts of the machine

Stage 3: the five transactions

Stage 4: the machine itself

The finished class diagram

What we left out, and what to say about it

An automated teller machine (ATM) is a machine that lets a bank's customers do their banking in a public place. It works without a cashier or a bank teller.

ATMs are needed because not every bank branch is open every day of the week. Some customers cannot visit a branch each time they want to withdraw or deposit money.

Requirements and Goals of the System

The main parts of the ATM that shape how users interact with it are:

Card reader: reads the user's ATM card.
Keypad: lets the user enter information, for example a PIN.
Screen: shows messages to the user.
Cash dispenser: pays out cash.
Deposit slot: takes in cash or checks from the user.
Printer: prints receipts.
Communication/Network Infrastructure: we assume the ATM can talk to the bank on every transaction or activity.

The user can have two types of accounts: 1) Checking, and 2) Savings. The user should be able to perform these five transactions on the ATM:

Balance inquiry: see the amount of funds in each account.
Deposit cash: deposit cash.
Deposit check: deposit checks.
Withdraw cash: withdraw money from their checking account.
Transfer funds: transfer funds to another account.

How ATM works?

An operator manages the ATM. The operator refills it with cash and receipts. The ATM serves one customer at a time and should not shut down while serving.

To begin a transaction, the user inserts their ATM card. The card holds their account information. Then the user enters their Personal Identification Number (PIN). The ATM sends the user's information to the bank for authentication. Without authentication, the user cannot perform any transaction.

The ATM keeps the card until the user ends the session. The user can end a session at any time by pressing the cancel button, and the card is ejected. The ATM also keeps an internal log of transactions, including hardware failures. The operator uses this log to resolve issues.

Identify the system user through their PIN.
A deposited check is not added to the account at once. It waits for manual verification and bank approval.
We assume the bank manager can access the ATM's system information stored in the bank database.
We assume user deposits are not added to their account immediately, because the bank verifies them first.
We assume the ATM card is the main part of security. Users authenticate with their debit card and security PIN.

Use cases

Here are the actors of the ATM system and their use cases:

Operator: responsible for these operations:

Turning the ATM on and off with the key switch.
Refilling the ATM with cash.
Refilling the ATM's printer with receipts.
Refilling the ATM's printer with ink.
Taking out deposited cash and checks.

Customer: can perform these operations:

Balance inquiry: view the account balance.
Cash withdrawal: withdraw a certain amount of cash.
Deposit funds: deposit cash or checks.
Transfer funds: transfer funds to other accounts.

Bank Manager: can perform these operations:

Generate a report of total deposits.
Generate a report of total withdrawals.
Print the total deposits and withdrawals reports.
Check the remaining cash in the ATM.

Here is the use case diagram of our ATM system:

Activity Diagram

Customer authentication: here is the activity diagram for a customer authenticating themselves before an ATM transaction:

Withdraw: here is the activity diagram for a user withdrawing cash:

Deposit check: here is the activity diagram for a customer depositing a check:

Transfer: here is the activity diagram for a user transferring funds to another account:

Sequence Diagram

Here is the sequence diagram for a balance inquiry transaction:

Code

The rest of this lesson builds the design one stage at a time. Each stage adds a few classes. Each stage ends with something the machine can do that it could not do before.

Stage	What it adds	What works after it
1	Accounts, cards, customers	A PIN can be checked and a balance read
2	Dispenser, screen, printer, slots	The machine can count out notes
3	The five transactions	Money moves, and each rule lives in one place
4	Bank and ATM	A whole session runs, one customer at a time

The code compiles and runs in Python, Java and C++.

Each stage below also adds its classes to one diagram. The classes from earlier stages stay exactly where they were, drawn in grey. So the picture fills in as the build goes on. By the last stage you have seen a reason for every box in the finished diagram.

Enums and Constants: here are the required enums, data types, and constants. An enum is a type with a fixed set of named values, like the account types:

Python3

. . . .

Stage 1: the money and the card

An account tracks two numbers, not one. The total balance is what the account holds. The available balance is what can be spent today. They differ the moment a check is deposited, because a check has to clear.

The savings account overrides one method to add its withdrawal limit. That is the only difference between the two account types. It is a difference in behavior, and that is what makes them two classes.

Customer, Card, and Account: "Customer" stands for the ATM user, "Card" for the ATM card, and "Account" for one of two account types, checking or savings:

The card and the accounts are named in the description above, and they produce every class in this stage. Account is abstract, with checking and savings below it. An abstract class is never created on its own, only through its subclasses. Inheritance is the right choice when subclasses differ in behavior. Here the only difference is the savings withdrawal cap, so it is inheritance and not a type field. Customer points at its card and its accounts with plain arrows, because none of them is destroyed when another one is. The legend after the diagram shows how to read every arrow used in this lesson.

Python3

. . . .

Stage 2: the parts of the machine

The dispenser is the interesting one. Deciding whether 85 dollars can be paid out of the notes loaded right now is the dispenser's job, not the withdrawal's. It works largest note first. It reports failure when the amount cannot be made exactly.

Note the two deposit slots. These are the physical slots a customer posts money into. The deposit transactions in the next stage are a different idea with a similar name. Mixing them up is an easy mistake to make.

The card reader is small, and it carries a rule. It holds the card for as long as the session lasts, and gives it back when the session ends. That is what the description above means by the card being kept until the customer is finished. Because the card lives in one place, every failed authentication has to eject it before it returns. You will see that in the next stage.

CardReader, CashDispenser, Keypad, Screen, Printer and the deposit slots: the parts the customer touches:

Parts 1 to 6 in the list above become one class each. None of them knows anything about a transaction. Only one arrow leaves this stage, and it points at Card. The card reader is where the card sits for the length of a session. DepositSlot is abstract, with a cash slot and a check slot below it. Read that name carefully. It is the physical slot money is posted into, not the deposit transaction of the next stage.

Python3

. . . .

Stage 3: the five transactions

Each of the five transactions is a class with one execute method. That keeps every rule in one place. The withdrawal rules are in Withdraw, and nothing else has to know them.

The order inside Withdraw is worth reading closely. It checks the note denominations, then the account, then the dispenser. It takes the money from the account only after the notes have been counted out. Debiting first and dispensing second is how a machine takes money without giving any.

Transaction and its subclasses: customers can perform different transactions on the ATM. These classes hold them:

The five transactions in the list above become five classes under one abstract Transaction, each with its own execute. That is what keeps the withdrawal rules inside Withdraw and out of everything else. Deposit sits in the middle of the tree. Cash and check deposits share an amount, but they differ in when the money becomes spendable. One arrow leaves the tree: a transfer names the account it pays into.

Python3

. . . .

Stage 4: the machine itself

The ATM holds the parts, runs the session, and serves one customer at a time. It holds the current customer and account itself. That is what makes the one-customer rule true rather than merely stated.

Bank and ATM: the machine assembles the parts and drives a session from card to receipt:

The machine arrives last and owns its parts. Composition is the ownership arrow, drawn as a filled diamond, and it means the part dies with its owner. Every arrow from ATM to a part is composition, because the parts are the machine. Scrap the machine and they go with it. The two arrows to Customer and Account are different. They are plain associations, which point at an object without owning it. They hold whoever is standing at the machine right now. The bank owns its machines, which is the last diamond.

Python3

. . . .

The finished class diagram

Now that every class exists, here is the whole model in one picture. It is the same picture the four stages have been filling in, with every class in full color at last. Nothing on it appears here for the first time.

Here are the main classes of the ATM System:

ATM: the main part of the system, the one this software is designed for. It has attributes like 'atmID' to tell it apart from other ATMs, and 'location' for its physical address.
CardReader: the ATM's card reader, used for user authentication.
CashDispenser: the part of the ATM that pays out cash.
Keypad: the user enters their PIN or an amount on the keypad.
Screen: shows all messages to the user. Users pick a transaction by touching the screen.
Printer: prints receipts.
DepositSlot: the user deposits checks or cash through the deposit slot.
Bank: the bank that owns the ATM. The bank holds all the account information, and the ATM talks to the bank to perform customer transactions.
Account: we have two types of accounts in the system: 1) Checking and 2) Saving.
Customer: the ATM's customer. It holds the customer's basic information like name and email.
Card: the ATM card the customer uses to authenticate. Each customer can have one card.
Transaction: all the transactions the customer can perform on the ATM, like BalanceInquiry, Deposit, and Withdraw.

What we left out, and what to say about it

This design covers the five transactions and six of the seven parts. The seventh is the network link to the bank. The description above assumes it rather than asks for it. PIN retry limits, card capture after three failures, receipt paper levels, journal logs for audit, and talking to another bank's network are all absent. That was a decision.

Two places where a reviewer will question the design, and the honest answer to each:

The PIN is compared inside Card. A real machine sends it to the bank, encrypted, and never holds it. The comment in the code says so. Saying it out loud is worth more than quietly modeling it wrong.
A withdrawal debits the account after dispensing. That is the right order for the customer. It also means a crash between the two leaves the bank short. A real system makes the pair atomic, so both happen or neither does. It then reconciles from the machine's journal.

💡 In the interview: the detail worth raising is the split between total and available balance. It is what makes the check deposit correct rather than convenient. Expect two follow ups. The first is "what if the machine cannot make the amount", which is the plan method on the dispenser. The second is "what if the power fails halfway through a withdrawal", which is the ordering question above.

Mark as Completed

Reading Progress

Vote for new content

On This Page

Requirements and Goals of the System

How ATM works?

Use cases

Activity Diagram

Sequence Diagram

Code

Stage 1: the money and the card

Stage 2: the parts of the machine

Stage 3: the five transactions

Stage 4: the machine itself

The finished class diagram

What we left out, and what to say about it