Requirements for Example ATM System

The software to be designed will control a simulated automated teller machine (ATM) having
a magnetic stripe reader for reading an ATM card, a keyboard and display for interaction with
the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a
printer for printing customer receipts, and a key-operated switch to allow an operator to start
or stop the machine. The ATM will communicate with the bank's computer over an appropriate
communication link. (The software on the latter is not part of the requirements for this
problem.)

The ATM will service one customer at a time. A customer will be required to insert an ATM
card and enter a personal identification number (PIN) - both of which will be sent to the bank
for validation as part of each transaction. The customer will then be able to perform one or
more transactions. The card will be retained in the machine until the customer indicates that
he/she desires no further transactions, at which point it will be returned - except as noted below.

The ATM must be able to provide the following services to the customer:

1. A customer must be able to make a cash withdrawl from any suitable account linked to
the card, in multiples of $20.00. Approval must be obtained from the bank before cash
is dispensed.
2. A customer must be able to make a deposit to any account linked to the card, consisting
of cash and/or checks in an envelope. The customer will enter the amount of the deposit
into the ATM, subject to manual verification when the envelope is removed from the
machine by an operator. Approval must be obtained from the bank before physically
accepting the envelope.
3. A customer must be able to make a transfer of money between any two accounts linked
to the card.
4. A customer must be able to make a balance inquiry of any account linked to the card.

The ATM will communicate each transaction to the bank and obtain verification that it was
allowed by the bank. In the case of a cash withdrawl or deposit, a second message will be sent
after the transaction has been physically completed (cash dispensed or envelope accepted).

If the bank determines that the customer's PIN is invalid, the customer will be required to re-
enter the PIN before a transaction can proceed. If the customer is unable to successfully enter
the PIN after three tries, the card will be permanently retained by the machine, and the customer
will have to contact the bank to get it back.

If a transaction fails for any reason other than an invalid PIN, the ATM will display an
explanation of the problem, and will then ask the customer whether he/she wants to do another
transaction.

The ATM will provide the customer with a printed receipt for each successful transaction,
showing the date, time, machine location, type of transaction, account(s), amount, and ending
and available balance(s) of the affected account ("to" account for tranfers).

The ATM will have a an operator panel with a key-operated switch (located on the "inside the
bank" side) that will allow an operator to start and stop the servicing of customers. When the
switch is moved to the "off" position, the machine will shut down, so that the operator may
remove deposit envelopes and reload the machine with cash, blank receipts, etc. The operator
will be required to verify and enter the total cash on hand before starting the system from this
panel.
The following objects might be identified by performing domain analysis on the general
domain to which our problem belongs:

Tangible Entities

The ATM machine itself - containing the following

o Display
o Card reader
o Keyboard
o Cash dispenser
o Envelope acceptor
o Receipt printer
o Operator panel
Customer
ATM Card
Operator
Bank

Intangible Entities

Bank account

Events

Transaction - with the following specializations

o Cash withdrawl
o Deposit
o Transfer between accounts
o Balance inquiry

Interactions

System startup by operator

Customer usage session
Each kind of transaction listed above will involve some user interaction.
Repeat entry of an invalid PIN

NOTE: Though all of these objects are part of the general domain of our problem, not all will
need to be explicitly modelled by the simulated ATM system itself
 System Startup Use Case

The system is started up when the operator turns the switch on the operator panel to the "on"
position. The operator will be asked to enter the amount of money currently in the cash
dispenser. Then servicing of customers can begin - ending later when the operator turns the
switch back to the "off" position.

Session Use Case

A session is started when a customer inserts an ATM card into the card reader slot of the
machine, which reads the card as it is inserted. (If the reader cannot read the card due to
improper insertion or a damaged stripe, the card is ejected, an error screen is displayed, and
no session is started.) The customer is asked to enter his/her PIN, and is allowed to perform
one or more transactions, choosing the transaction type each time from a menu of options.
The session will initiate the appropriate transaction use case, and will furnish the customer's
card number and PIN to the transaction. After each successful transaction, the customer is
asked whether he/she would like to perform another; after a transaction that fails for any
reason other than repeated entries of an invalid PIN, the Failed Transaction Extension is
executed. When the customer is through performing transactions, the card is ejected from the
machine and the session ends.

Cash Withdrawl Transaction Use Case

A cash withdrawl transaction is started from within a session when the customer chooses cash
withdrawl from the menu of possible transaction types. The customer chooses a type of
account to withdraw from (e.g. checking) from a menu of possible accounts, and then
chooses a dollar amount from a menu of possible amounts. The system verifies that it has
sufficient money on hand to satisfy the request. If not, it reports a failure to the session, which
initiates the Failed Transaction Extension to report the problem. If there is sufficient cash, it
sends the customer's card number, PIN, chosen account and amount to the bank, which either
approves or disapproves the transaction. If the transaction is approved, the machine dispenses
the correct amount of cash and issues a receipt. If the transaction is disapproved due to an
incorrect PIN, the Incorrect PIN extension is executed. All other disapprovals are reported to
the session, which initiates the Failed Transaction Extension. The bank is notified whether or
not an approved transaction was completed in its entirety by the machine; if it is completed
then the bank completes debiting the customer's account for the amount.

Deposit Transaction Use Case

A deposit transaction is started from within a session when the customer chooses deposit
from the menu of possible transaction types. The customer chooses a type of account to
deposit to (e.g. checking) from a menu of possible accounts, and then chooses a dollar
amount by typing it on the keyboard. The system sends the customer's card number, PIN,
chosen account and amount to the bank, which either approves or disapproves the transaction.
If the transaction is approved, the machine accepts an envelope from the customer containing
cash and/or checks and then issues a receipt. (If the customer does not insert the envelope
within a specified period of time, this operation times out and the deposit transaction is
aborted.) If the transaction is disapproved due to an incorrect PIN, the Incorrect PIN
extension is executed. All other disapprovals are reported to the session, which initiates the
Failed Transaction Extension. The bank is notified whether or not an approved transaction
was completed in its entirety by the machine; if it is completed then the bank completes
crediting the customer's account for the amount - contingent on manual verification of the
deposit envelope contents by an operator later.

Transfer Transaction Use Case

A transfer transaction is started from within a session when the customer chooses transfer
from the menu of possible transaction types. The customer chooses a type of account to
transfer from (e.g. checking) from a menu of possible accounts, chooses a different account
to transfer to, and then chooses a dollar amount by typing it on the keyboard. The system
sends the customer's card number, PIN, chosen account and amounts to the bank, which
either approves or disapproves the transaction. If the transaction is approved, the machine
issues a receipt. If the transaction is disapproved due to an incorrect PIN, the Incorrect PIN
extension is executed. All other disapprovals are reported to the session, which initiates the
Failed Transaction Extension. The bank will consider the transaction complete once it has
been approved.

Balance Inquiry Transaction Use Case

A balance inquiry transaction is started from within a session when the customer chooses
balance inquiry from the menu of possible transaction types. The customer chooses a type of
account to inquire about. The system sends the customer's card number, PIN and chosen
account to the bank, which either approves or disapproves the transaction. If the transaction is
approved the bank sends the balance to the machine with the approval, and the system prints
it on a receipt. If the transaction is disapproved due to an incorrect PIN, the Incorrect PIN
extension is executed. All other disapprovals are reported to the session, which initiates the
Failed Transaction Extension.

Invalid PIN Extension

An invalid PIN extension is started from within a transaction when the bank reports that the
customer's transaction is disapproved due to an invalid PIN. The customer is required to re-
enter the PIN and the original request is sent to the bank again. If the bank now approves the
transaction, or disapproves it for some other reason, the original case is continued; otherwise
the process of re-entering the PIN is repeated. Once the PIN is successfully re-entered, it is
used for both the current transaction and all subsequent transactions in the session. If the
customer fails three times to enter the correct PIN, the card is permanently retained, a screen
is displayed informing the customer of this and suggesting he/she contact the bank, and the
entire customer session is aborted.
 Failed Transaction Extension

A failed transaction extension is started from a session when a transaction use case fails to
complete successfully for some reason other than repeated entries of an invalid PIN. A screen
is displayed informing the customer of the problem, and the customer is asked whether he/she
wants to do another transaction.
State Diagram

ATM Simulation Session State Diagram

A state diagram is an analysis tool that can be used when a system (or component of a
system) passes through a series of discrete states during operation. Trivially, the ATM itself
goes back and forth between two states - RUNNING and STOPPED. More interesting,
though, is the series of states an individual Session goes through as it gets the customer's PIN
and repeatedly gets transaction choices and performs them. A state diagram for a Session is
given below. It would also be possible (and perhaps desirable) to construct similar diagrams
for transactions. (Is an "exercise left for the student" lurking here?)
Transaction Interaction Diagram

An interaction diagram is an analysis tool that can be used when an object interacts with
various other objects to perform some task. One place this occurs in the ATM Simulation is
during the execution of a transaction, when the transaction must interact with the Customer
(via the ATM) to get specific information (such as choice of account(s), amount), with the
Bank, and with various components of the ATM (e.g. cash dispenser, printer). The diagram
below is an interaction diagram for a WithdrawlTransaction. This diagram was developed in
1998 (two years after the initial development of the system) - I'm still learning, too! The
system as implemented is not totally consistent with the diagram - perhaps if I had known
about interaction diagrams and done this diagram earlier the final system might have been a
bit different (and probably more elegant). It would, of course, also be possible (and desirable)
to draw similar diagrams for the other three types of transaction. (Is an "exercise left for the
student" lurking here?)
ATM Example System Class Diagram
ATM Problem CRC cards
1. Class ATM - with component parts:
1. Class CardReader
2. Class Display
3. Class Keyboard
4. Class CashDispenser
5. Class EnvelopeAcceptor
6. Class ReceiptPrinter
7. Class OperatorPanel
2. Class Session
3. Class Transaction - with subclasses:
1. Class WithdrawlTransaction
2. Class DepositTransaction
3. Class TransferTransaction
4. Class InquiryTransaction
4. Class Bank

Class ATM
Responsibility Collaborator(s)
Start up system operation OperatorPanel
Display
Start a session for each customer as he/she arrives CardReader
Session
Shut down on operator request OperatorPanel
Display
Get PIN from customer
Keyboard
Display
Get customer choice from a menu of options
Keyboard
Display
Get amount entry (typed in) from customer
Keyboard
Verify that sufficient cash is available for withdrawl CashDispenser
Dispense cash CashDispenser
Display
Accept deposit envelope from customer
Envelope Acceptor
Issue receipt to customer ReceiptPrinter
Display
Require customer to re-enter PIN
Keyboard
Inform customer of reason for failure of a transaction, Display
and ask if he/she wants another Keyboard
Return ATM card to customer CardReader
Display
Permanently retain customer card
CardReader
[ Class Description Form ]

Class CardReader
Responsibility Collaborator(s)
Check for readable card inserted
Return number read from card
Eject card
Retain card

[ Class Description Form ]

Class Display
Responsibility Collaborator(s)
Display "Insert Card" screen
Display "Enter PIN" screen
Display menu of choices
Display "Enter Amount" screen
Display "Deposit Envelope" screen
Display "Card unreadable" screen
Display "Transaction failed because ... want another?" screen
Display "Invalid PIN - re-enter" screen
Display "Card retained" screen
Echo input from the keyboard
Clear current message from screen when no longer needed

[ Class Description Form ]

Class Keyboard
Responsibility Collaborator(s)
Read PIN Display (echo *'s)
Read choice from menu
Read amount entry (typed) Display (echo amount)

[ Class Description Form ]

Class CashDispenser
Responsibility Collaborator(s)
Set initial cash on hand at startup
Report cash available
Dispense cash

[ Class Description Form ]

Class EnvelopeAcceptor
Responsibility Collaborator(s)
Accept envelope

[ Class Description Form ]

Class ReceiptPrinter
Responsibility Collaborator(s)
Print receipt

[ Class Description Form ]

Class OperatorPanel
Responsibility Collaborator(s)
Indicate state of on-off switch
Get initial cash on hand from operator

[ Class Description Form ]

Class Session
Responsibility Collaborator(s)
ATM
Perform session use case
Transaction
ATM
Perform invalid PIN extension
Transaction
Perform failed transaction extension ATM
Furnish card number to Transaction
Furnish PIN to Transaction

[ Class Description Form ]

 Class Transaction
Responsibility Collaborator(s)
WithdrawlTransaction
DepositTransaction
Allow customer to choose a transaction type
TransferTransaction
then create an object of appropriate subclass
InquiryTransaction
ATM
WithdrawlTransaction
DepositTransaction
Perform a particular transaction use case TransferTransaction
InquiryTransaction
Session

[ Class Description Form ]

Class WithdrawlTransaction
Responsibility Collaborator(s)
Get specifics from customer ATM
Session
Send to bank
Bank
ATM
Dispense cash, issue receipt, and notify bank when complete
Bank

[ Class Description Form ]

Class DepositTransaction
Responsibility Collaborator(s)
Get specifics from customer ATM
Session
Send to bank
Bank
ATM
Accept envelope, issue receipt, and notify bank when complete
Bank

[ Class Description Form ]

Class TransferTransaction
Responsibility Collaborator(s)
Get specifics from customer ATM
Session
Send to bank
Bank
Issue receipt ATM
[ Class Description Form ]

Class InquiryTransaction
Responsibility Collaborator(s)
Get specifics from customer ATM
Session
Send to bank
Bank
Issue receipt ATM

[ Class Description Form ]

Class Bank
Responsibility Collaborator(s)
Allow customer to choose an account type from a list of
ATM
possibilities
Initiate withdrawl
Finish withdrawl
Initiate deposit
Finish deposit
Do transfer
Do inquiry
Provide information about reason for rejection of a transaction

[ Class Description Form ]