Object-Oriented

Analysis and Design

ATM
ATM PROJECT
PROJECT

AUTOMATED
AUTOMATED
TELLER
TELLER
MACHINE
MACHINE
Source:OBJECT-ORIENTED
MODELING AND DESIGN
James Rumbaugh, Michael Blaha,
William Premerlani, Frederick Eddy,
William Lorensen

PAUL VOUGNY - EPITA 2008

PROBLEM STATEMENT

The human cashier

ATM enter account and
network transaction data

Cashier
Station
Cash card

ATM Communication Account

Bank
Computer
Account
ATM Central
Computer
Account
Bank
ATM
Computer
Account
OBJECT MODELING
Classes

Software Banking Cashier ATM Consortium Bank

network

Bank Account Transaction Cashier Account Transaction

computer station data data

Central Cash User Cash Receipt System

computer card

ATM classes Recordkeeping Security Access Cost Customer

extracted provision provision
from problem
statement
nouns

ATM classes
Transaction
identified from
log
knowledge of
problem
domain Communications
line
 Bad Classes

vague irrelevant
attribute
System Cost
Receipt
Account
Security data
provision Cash
implementation
Recordkeeping Transaction
provision data Access
Transaction
Banking log
redundant Software
network
User Communications
line

Eliminating
unnecessary
classes from Good Classes
ATM problem
Bank Cash
Account ATM Bank Cashier
computer card

Cashier Central
Consortium Customer Transaction
station computer
Dictionary Data
dictionary for
ATM classes

Account - a single account in a bank against which transactions can be applied.

Accounts may be of various types, at least checking or savings. A customer can
hold more than one account.

ATM - a station that allows customers to enter their own transactions using cash
cards as identification. The ATM intercats with the customer to gather transaction
information, sends the transaction information to the central computer for validation
and processing, and dispenses cash to the user. We assume that an ATM need not
operate independently of the network.

Bank - a financial institution that holds accounts for customers and that issues cash
cards authorizing access to accounts over the ATM network.

Bank computer - the computer owned by a bank that interfaces with the ATM
network and the bank's own cashier stations. A bank may actually have its own
internal network of computers to process accounts, but we are only concerned with
the one that talks to the network.
Cash card - a card assigned to a bank customer that authorizes access of accounts
using an ATM machine. Each card contains a bank code and a card number, most
likely coded in accordance with national standards on credits cards and cash cards.
The bank code uniquely identifies the bank within the consortium. The card number
determines the accounts that the card can access. A card does not necessarily
access all of a customer's accounts. Each cash card is owned by a single customer,
but multiple copies of it may exist, so the possibility of simultaneous use of the same
card from different machines must be considered.

Cashier - an employee of a bank who is authorized to enter transactions into

cashier stations and accept and dispense cash and checks to customers.
Transactions, cash, and checks handled by each cashier must be logged and
properly accounted for.

Cashier station - a station on which cashier enter transactions for customers.

Cashiers dispense and accept cash and checks: the station prints receipts. The
cashier station communicates with the bank computer to validate and process the
transactions.

Central computer - a computer operated by the consortium which dispatches

transactions between the ATMs and the bank computers. The central computer
validates bank codes but does not process transactions directly.
Consortium - an organization of banks that commissions and operates the ATM
network. The network only handles transactions for banks in the consortium.

Customer - the holder of one or more accounts in a bank. A customer can consist of
one or more persons or corporations; the correspondence is not relevant to this
problem. The same person holding an account at a different bank is considered a
different customer.

Transaction - a single integral request for operations on the accounts of a single

customer. We only specified that ATMs must dispense cash, but we should not
preclude the possibility of printing checks or accepting cash or checks. We may also
want to provide the flexibility to operate on accounts of different customers, although
it is not required yet. The different operations must balance properly.
Associations
Verb phrases:

Banking network includes cashiers and ATMs

Consortium shares ATMs
Bank provides bank computer
Bank computer processes transaction against account
Bank owns cashier station
Cashier station communicates with computer
Cashier enters transaction for account
ATMs communicate with central computer about transaction
Central computer clears transaction with bank
ATM accepts cash card
ATM interacts with user Implicit verb phrases:
ATM dispenses cash
ATM prints receipts Consortium consists of banks
System handles concurrent access Bank holds account
Banks provide software Consortium owns central computer
Cost apportioned to banks System provides recordkeeping
System provides security
Customers have cash cards

Associations Knowledge of problem domain:

from ATM
problem Cash card accesses accounts
statement Bank employs cashiers
 Building the Object model Initial object
diagram for
ATM system

Consists
of Holds Has
Consortium Bank code Bank Account Customer

Employs Concerns
Owns Owns
Owns
Communicates
Central with Bank
Cashier Has
computer computer Accesses

Communicates Concerns
Entered by
with
Communicates
with
Cashier Entered on Cashier
station transaction

Entered on Remote Cash

ATM
transaction card
Authorized by
 Issues
card
Account
code Holds Has Customer
account balance
Consists Bank name
Consortium code credit limit
Bank of address
type
code name
employee
code
station
Owns Owns code Concerns
Employs
Owns Accesses Has
Communicates Cashier
Central with Bank
Bank name Concerns
computer computer
code
station station Entered by
code code
Cashier
Communicates transaction
with kind
Communicates Cashier Entered on date-time
with station amount
ATM Entered on
cash on hand Remote
dispensed transaction
kind Cash
date-time card
ATM object model amount Authorized by
with attributes password
 Entry Transaction
station Entered on kind Concerns
date-time
amount

ATM Cashier
cash on hand station Cashier Remote
dispensed transaction transaction
Communicates Communicates
with with Entered by
station station
code Cashier
Communicates code
name
Central with Bank
Bank Owns
computer computer Authorized
code
Employs by

Owns Owns Issues Cash

station card
code Customer password
Consortium employee
Bank Bank name Has
code code
address
Consists of name
card Has
code Account Accesses
ATM object model account
with attributes code balance
and inheritance Holds credit limit
type
 Transaction
Entered on date-time Consists of

Update
amount
Entry Cashier Remote kind
station transaction transaction

Concerns
Entered by
ATM Cashier Started by
cash on hand station
dispensed Cashier
name

Owns Owns Issues

Cash
Employs authorization
Has
Customer password
station
station name Identifies limit
code
code employee address
Bank
Consortium code
Bank
Cash card
code Consists of name Has
card bank-code
code card-code
account
Account serial number
ATM object model code
balance
after further credit limit Accesses
Holds
revision type
Grouping classes into Modules

ATM Problem:
The model we present is small and would not
require breakdown into modules, but it could serve
as a core for a more detailed model.
DYNAMIC MODELING
Format for
Interface ATM
interface

Possible ATM layout

1 2 3
>Messages to user
> 4 5 6 CLEAR

7 8 9 CANCEL

* 0 # ENTER

cash card receipts cash slot

Scenarios

The ATM asks the user to insert a card; the user inserts a cash card.
The ATM accepts the card and reads its serial number.
The ATM requests the password; the user enters "1234".
The ATM verifies the serial number and password with the consortium; the
consortium checks it with bank "39" and notifies the ATM of acceptance.
The ATM asks the user to select the kind of transaction (withdrawal, deposit,
transfer, query); the user selects withdrawal.
The ATM asks for the amount of cash; the user enters $100.
The ATM verifies that the amount is within predefined policy limits and asks the
consortium to process the transaction; the consortium passes the request to
the bank, which eventually confirms success and returns the new account
balance.
The ATM dipenses cash and asks the user to take it; the user takes the cash.
The ATM asks whether the user wants to continue; the user indicates no.
The ATM prints a receipt, ejects the card, and asks the user to take them; the
user takes the receipt and the card.
The ATM asks the user to insert a card.
Normal
ATM
scenario
The ATM asks the user to insert a card; the user inserts a cash card.
The ATM swallows the card and reads its serial number.
The ATM requests the password; the user enters "9999".
The ATM verifies the serial number and password with the consortium, which
rejects it after consulting the appropriate bank.
The ATM indicates a bad password and asks the user to renter it; the user
enters "1234" which the ATM successfully verifies with the consortium.
The ATM asks the user to select the kind of transaction; the user selects
withdrawal.
The ATM asks for the amount of cash; the user has a change of mind and hits
"cancel".
The ATM ejects the card and asks the user to take it; the user takes it.
The ATM asks the user to insert a card.
ATM
scenario
with
exceptions
User ATM Consortium Bank
insert card actor
request password (active object) passive object
enter password
verify account
verify card with bank
bank account OK
account OK object
request kind
enter kind
request amount
enter amount
process transaction
process bank transaction state
bank transaction succeed }
transaction succeed
dispense cash event
request take cash
take cash
request continuation
terminate
print receipt Event trace
eject card for ATM
scenario
request take card
take card
display main screen

By scanning a
particular column
in the trace, we User
can see the events
that directly affect
a particular object.
Only these events
can appear in the
state diagram for
the object.
insert card
enter password, enter kind
enter amount
take cash, take card
cancel, terminate, continue
ATM
display main screen
unreadable card message
request password
request kind, request amount transaction succeed
canceled message transaction failed
eject card, failure message account OK
dispense cash, request take cash bad account
request continuation bad password
print receipt, request take card bad bank code
bad account message
verify account
bad bank code message
process transaction

verify card with bank,

process bank transaction

Event flow Bank Consortium

diagram for bank transaction succeed,
ATM example bank transaction failed bank, bank account OK
bad bank account, bad bank password
This diagram
summarizes events
between classes
✘ Paths in the object diagram show possible information flows.
without regard for
✘ Paths in the event flow diagram show possible control flows. sequence
 Building the Dynamic model

process transaction verify account

[bad code]
/ bad bank code
do: process bank transaction do: verify bank code

[good code]
bad bank account
/ bad account
do: verify card with bank
bad bank password
/ bad password
bank transaction failed bank transaction succeed
/ transaction failed / transaction successed bank account OK
/ account OK

State diagram
for class
Consortium
 process bank transaction verify card with bank
[invalid]
/ bad bank account
do: update account do: verify card number

[valid]
[invalid]
/ bad bank password
do: verify password

[failure] [succeed]
/ bank transaction failed / bank transaction successed [valid]
/ bank account OK

State diagram
for class
Bank
 Wait for Interrput
network responds
network do: canceled
response message
insert card enter
cancel
[readable] password
Main screen do: request do: verify
do: display password account
main screen bad
insert card password
account OK
[unreadable]
take Unreadable
card do: unreadable cancel bad
card message account do: request kind
cancel
Card ejected Cancel enter
do: eject card; do: canceled
kind
request take card message
cancel
do: request
Finish amount
do: bad account message
do: print receipt

terminate enter amount

continue
cancel take transaction
do: request cash do: dispense cash; succeed do: process
continuation request take cash transaction
wait 5
seconds
transaction
State diagram failed do: failure
for class ATM message
cancel
 FUNCTIONAL MODELING

Identifying Input and Output Values

All input and output values are parameters of ATM events.

✘ Inputs events that only affect the flow of control, such as cancel, terminate,
or continue, do not supply input values.

✘ Acknowledgment events, such as take cash or take card similarly,

do not supply data.

bank code,
Cash card code
card

password,
ATM
transaction kind, Input and
account type, output values
amount for ATM
system boundary system
User cash,
receipt,
messages
 Building Data Flow Diagrams

A data flow diagram is usually constructed in layers. The top layer may consist of a
single process.

Input and output values are supplied and consumed by external objects, such as
User and Cash card.

Account

bank code,
Cash balance
card code
card

perform generate
read input
transaction outputs

password,
Top level transaction kind, cash,
data flow diagram account type, receipt,
for ATM amount messages
User
 Consortium

bank code select bad bank code

control
bank signal
bank
decision select invalid card code
function card code card card authorization
password
accounts
password verify bad password
password
account type select bad account
account
Account

balance

Data flow diagram amount, transaction kind update transaction failed

for ATM account
perform transaction
process cash, receipt
Describing Functions

update account (account, amount, transaction-kind) -> cash, receipt, message

If the amount on a withdrawal exceeds the current account balance

reject the transaction and dispense no cash
If the amount on a withdrawal does not exceed the current account balance
debit the account and dispense the amount requested
If the transaction is a deposit
credit the account and dispense no cash
If the transaction is a status request
dispense no cash
In any case
the receipt shows ATM number, date, time, account number,
transaction-kind, amount transacted (if any), and new balance

Function
description for
update account
function
 Adding Operations

Operations in object-oriented programming languages can correspond to:

✘ queries about attributes or associations in the model:

account.balance, cash_card.bank

✘ events in the dynamic model:

cancel sent from user to ATM

✘ functions in the functional model:

update account

Operations from State Actions and Activities

Actions and activities in the state diagram may be functions. These functions having
interesting computational structure should be defined as operations on the object
model.

✘ Consortium has the activity verify bank code

✘ Bank has the activity verify password
 Operations from Functions

Each function in the data flow diagram corresponds to an operation on an object

(or possibly several objects).

Organize the functions into operations on objects.

We can define:

✘ verify_password as an operation on class Card_authorization

✘ update_account as an operation on class Account

In expanding the definition of update_account, it may be convenient to define

simpler operations for each kind of transaction:

✘ account :: withdraw (kind, amount) -> status

✘ account :: deposit (kind, amount) -> status
 Shopping List Operations

Shopping list operations permit considering future possible needs while the
organization of classes is still fluid.

They provide an opportunity to broaden the base of an object definition beyond the
narrow needs of the immediate problem.

Some operations not already required by the ATM problem include:

account :: close
account :: authorize_cash_card (cash_card_authorization)
bank :: create_savings_account (customer) -> account
bank :: create_checking_account (customer) -> account
bank :: create_cash_card (customer) -> cash_card_authorization
cash_card_authorization :: remove_account (account)
cash_card_authorization :: close
SYSTEM DESIGN
Identifying Inherent Concurrency
If the ATM statement contained the requirement that each machine should
continue to operate locally in the event of a central system failure (perhaps
with reduced limits on translations), then we would have no choice but to
include a CPU in each ATM machine with a full control program.

Defining Concurrent Tasks

While the bank is verifying an account or processing a bank transaction,
the ATM machine is idle.

If the ATM is controlled directly by a central computer, then the ATM object
can be folded together with the bank transaction object as a single task.

Estimating Hardware Resource Requirements

The system designer must estimate the required CPU processing power by
computing the steady state load as the product of the number of transactions
per second and the time required to process a transaction.
Architecture

✘ The entry stations are interactive interfaces:

their purpose is to interact with a human to gather information needed to

formulate a transaction.

✘ The consortium and banks are primarily a distributed

transaction management system:

their purpose is to maintain a database of information and to allow it to be

updated over a distributed network under controlled conditions.
Architecture event
of ATM Consortium driven Bank
ATM system stations computer computers

Cashier
ATM
Consortium Cashier
phone pemanent station
Cash lines data store Database
card station
code Account

phone
Customer
lines
User bank
Card
user code
authorization
interface

Transaction Transaction Transaction

The topology is a simple star.

The consortium computer communicates with all the ATM stations and with
all the bank computers.
OBJECT DESIGN

Procedure-driven System

State model for the ATM class:

First, we identify the main path of control, which corresponds to

- the reading of a card
- querying the user for transaction information
- processing the transaction
- printing a receipt
- ejecting the card.

Alternative flows of control occur if the customer wants to

process more than one transaction or if the password is bad
and the customer is asked to try again.
 Main screen
insert card Pseudocode

Request password do forever

display main screen
enter password read card
repeat
Verify account ask for password
bad account read password
account OK verify account
until account verification is OK
Request kind repeat
repeat
enter kind ask for kind of transaction
read kind
Request amount ask for amount
read amount
enter account start transaction
wait for it to complete
Process transaction until transaction is OK
transaction
dispense cash
failed transaction succeed wait for customer to take it
ask whether to continue
Dispense cash until user asks to terminate
take cash eject card
wait for customer to take card
Request continuation
continue
terminate
ATM The cancel event cound be added to
Finish
control
the flow control and implemented as
Card ejected goto exception handling code.
take card