Design an ATM

An automated teller machine (ATM) is an electronic telecommunications instrument that provides the clients of a financial institution with access to financial transactions in a public space without the need for a cashier or bank teller. ATMs are necessary as not all the bank branches are open every day of the week, and some customers may not be in a position to visit a bank each time they want to withdraw or deposit money.

Requirements and Goals of the System

The main components of the ATM that will affect interactions between the ATM and its users are:

1. Card reader: to read the users' ATM cards.
2. Keypad: to enter information into the ATM e.g. PIN. cards.
3. Screen: to display messages to the users.
4. Cash dispenser: for dispensing cash.
5. Deposit slot: For users to deposit cash or checks.
6. Printer: for printing receipts.
7. Communication/Network Infrastructure: it is assumed that the ATM has a communication infrastructure to communicate with the bank upon any transaction or activity.

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

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

How ATM works?

The ATM will be managed by an operator, who operates the ATM and refills it with cash and receipts. The ATM will serve one customer at a time and should not shut down while serving. To begin a transaction in the ATM, the user should insert their ATM card, which will contain their account information. Then, the user should enter their Personal Identification Number (PIN) for authentication. The ATM will send the user's information to the bank for authentication; without authentication, the user cannot perform any transaction/service.

The user's ATM card will be kept in the ATM until the user ends a session. For example, the user can end a session at any time by pressing the cancel button, and the ATM Card will be ejected. The ATM will maintain an internal log of transactions that contains information about hardware failures; this log will be used by the ATM operator to resolve any issues.

1. Identify the system user through their PIN.
2. In the case of depositing checks, the amount of the check will not be added instantly to the user account; it is subject to manual verification and bank approval.
3. It is assumed that the bank manager will have access to the ATM's system information stored in the bank database.
4. It is assumed that user deposits will not be added to their account immediately because it will be subject to verification by the bank.
5. It is assumed the ATM card is the main player when it comes to security; users will authenticate themselves with their debit card and security pin.

Use cases

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

Operator: The operator will be responsible for the following operations:

1. Turning the ATM ON/OFF using the designated Key-Switch.
2. Refilling the ATM with cash.
3. Refilling the ATM's printer with receipts.
4. Refilling the ATM's printer with INK.
5. Take out deposited cash and checks.

Customer: The ATM customer can perform the following operations:

1. Balance inquiry: the user can view his/her account balance.
2. Cash withdrawal: the user can withdraw a certain amount of cash.
3. Deposit funds: the user can deposit cash or checks.
4. Transfer funds: the user can transfer funds to other accounts.

Bank Manager: The Bank Manager can perform the following operations:

1. Generate a report to check total deposits.
2. Generate a report to check total withdrawals.
3. Print total deposits/withdrawal reports.
4. Checks the remaining cash in the ATM.

Here is the use case diagram of our ATM system:

Activity Diagram

Customer authentication: Following is the activity diagram for a customer authenticating themselves to perform an ATM transaction:

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

Code

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

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

Enums and Constants: Here are the required enums, data types, and constants:

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.

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, and it is a difference in behaviour, which is what makes them two classes.

Customer, Card, and Account: "Customer" encapsulates the ATM user, "Card" the ATM card, and "Account" can be of two 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, and the only difference between them is that a savings account adds a withdrawal cap. That is a difference in behaviour, which is what makes inheritance right here instead of 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.

Stage 2: the parts of the machine

The dispenser is the interesting one. Deciding whether 85 dollars can be paid out of the notes currently loaded is the dispenser's job, not the withdrawal's. It works largest note first and 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, and 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, which is what the description above means by the card being kept until the customer is finished. Because it is the one place the card lives, every failed authentication has to eject before it returns, and that is visible in the next stage.

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

Components 1 to 6 in the list above become one class each, and none of them knows anything about a transaction. Only one arrow leaves this stage, and it points at Card, because 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: these are the physical slots money is posted into, and the deposit transactions in the next stage are a different idea with a similar name.

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 ordering inside Withdraw is worth reading closely. It checks the note denominations, then the account, then the dispenser, and only takes the money from the account 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 encapsulate 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 because cash and check deposits share an amount but differ in when the money becomes spendable. One arrow leaves the tree: a transfer names the account it pays into.

Stage 4: the machine itself

The ATM holds the parts, runs the session, and serves one customer at a time. Holding the current customer and account on the machine is what makes that 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. Every arrow from ATM to a component is composition, the filled diamond, 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 that hold whoever is standing at the machine right now, and holding them on the machine is what makes one customer at a time true rather than merely stated. The bank owns its machines, which is the last diamond.

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 colour 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 for which this software has been designed. It has attributes like 'atmID' to distinguish it from other available ATMs, and 'location' which defines the physical address of the ATM.

• CardReader: To encapsulate the ATM's card reader used for user authentication.

• CashDispenser: To encapsulate the ATM component which will dispense cash.

• Keypad: The user will use the ATM's keypad to enter their PIN or amounts.

• Screen: Users will be shown all messages on the screen and they will select different transactions by touching the screen.

• Printer: To print receipts.

• DepositSlot: User can deposit checks or cash through the deposit slot.

• Bank: To encapsulate the bank which owns the ATM. The bank will hold all the account information and the ATM will communicate with the bank to perform customer transactions.

• Account: We'll have two types of accounts in the system: 1)Checking and 2)Saving.

• Customer: This class will encapsulate the ATM's customer. It will have the customer's basic information like name, email, etc.

• Card: Encapsulating the ATM card that the customer will use to authenticate themselves. Each customer can have one card.

• Transaction: Encapsulating all transactions that the customer can perform on the ATM, like BalanceInquiry, Deposit, Withdraw, etc.