ATM Simulation Example

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 1

TABBLE OF CONTENTS

I. REQUIREMENT SPECIFICATION........................................................................................................................... 2

1. REQUIREMENTS STATEMENT FOR EXAMPLE ATM SYSTEM ....................................................................................... 2

2. USE CASES FOR EXAMPLE ATM SYSTEM .................................................................................................................. 4
3. FLOWS OF EVENTS FOR I NDIVIDUAL USE CASES ........................................................................................................ 5
4. SEQUENCE BASED SPECIFICATION...........................................................................................................................15
5. I NITIAL FUNCTIONAL TEST CASES FOR EXAMPLE ATM SYSTEM ...............................................................................18

II. DESIGN ...................................................................................................................................................................27

6. CLASS DESCRIPTIONS.............................................................................................................................................27
7. STRUCTURAL VIEW: CLASS DIAGRAM FOR EXAMPLE ATM SYSTEM .........................................................................29
8. STATE CHARTS FOR EXAMPLE ATM SYSTEM ..........................................................................................................31

III. IMPLEMENTATION ..............................................................................................................................................33

1. DETAILED DESIGN .................................................................................................................................................33

2. PACKAGE DIAGRAM FOR EXAMPLE ATM S YSTEM ..................................................................................................44

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 2

I. Requirement Specification

1. Requirements Statement 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 customer console (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 withdrawal 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.

A customer must be able to abort a transaction in progress by pressing the Cancel key instead of
responding to a request from the machine.

The ATM will communicate each transaction to the bank and obtain verification that it was
allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 3

has been approved. In the case of a deposit, a second message will be sent to the bank
indicating that the customer has deposited the envelope. (If the customer fails to deposit the
envelope within the timeout period, or presses cancel instead, no second message will be sent
to the bank and the deposit will not be credited to the customer.)

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 transfers).

The ATM will have a key-operated switch that will allow an operator to start and stop the
servicing of customers. After turning the switch to the "on" position, the operator will be
required to verify and enter the total cash on hand. The machine can only be turned off when it
is not servicing a customer. 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 ATM will also maintain an internal log of transactions to facilitate resolving ambiguities
arising from a hardware failure in the middle of a transaction. Entries will be made in the log
when the ATM is started up and shut down, for each message sent to the Bank (along with the
response back, if one is expected), for the dispensing of cash, and for the receiving of an
envelope. Log entries may contain card numbers and dollar amounts, but for security
will never contain a PIN.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 4

2. Use Cases for Example ATM System

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 5

3. Flows of Events for Individual Use Cases

a. System Startup Use Case

The system is started up when the operator turns the operator switch to the "on"
position. The operator will be asked to enter the amount of money currently in the cash
dispenser, and a connection to the bank will be established. Then the servicing of
customers can begin.

b. System Shutdown Use Case

The system is shut down when the operator makes sure that no customer is using the
machine, and then turns the operator switch to the "off" position. The connection to the
bank will be shut down. Then the operator is free to remove deposited envelopes,
replenish cash and paper, etc.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 6

c. Session Use Case

A session is started when a customer inserts an ATM card into the card reader slot of
the machine. The ATM pulls the card into the machine and reads it. (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 the session is aborted.) The customer is asked to enter
his/her PIN, and is then allowed to perform one or more transactions, choosing from a
menu of possible types of transaction in each case. After each transaction, the customer
is asked whether he/she would like to perform another. When the customer is through
performing transactions, the card is ejected from the machine and the session ends. If a
transaction is aborted due to too many invalid PIN entries, the session is a lso aborted,
with the card being retained in the machine.

The customer may abort the session by pressing the Cancel key when entering a PIN or
choosing a transaction type.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 7

d. Transaction Use Case

Note: Transaction is an abstract generalization. Each specific concrete type of
transaction implements certain operations in the appropriate way. The flow of events
given here describes the behavior common to all types of transaction. The flows of
events for the individual types of transaction (withdrawal, deposit, transfer, inquiry) give
the features that are specific to that type of transaction.

A transaction use case is started within a session when the customer chooses a
transaction type from a menu of options. The customer will be asked to furnish
appropriate details (e.g. account(s) involved, amount). The transaction will then be sent
to the bank, along with information from the customer's card and the PIN the customer
entered.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 8

If the bank approves the transaction, any steps needed to complete the transaction (e.g.
dispensing cash or accepting an envelope) will be performed, and then a receipt will be
printed. Then the customer will be asked whether he/she wishes to do another
transaction.

If the bank reports that the customer's PIN is invalid, the Invalid PIN extension will be
performed and then an attempt will be made to continue the transaction. If the
customer's card is retained due to too many invalid PINs, the transaction will be
aborted, and the customer will not be offered the option of doing another.

If a transaction is cancelled by the customer, or fails for any reason other than repeated
entries of an invalid PIN, a screen will be displayed informing the customer of the reason
for the failure of the transaction, and then the customer will be offered the opportunity
to do another.

The customer may cancel a transaction by pressing the Cancel key as described for each
individual type of transaction below.

All messages to the bank and responses back are recorded in the ATM's log.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 9

e. Withdrawal Transaction Use Case

A withdrawal transaction asks the customer to choose a type of account to withdraw
from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount
from a menu of possible amounts. The system verifies that it has sufficient money on
hand to satisfy the request before sending the transaction to the bank. (If not, the
customer is informed and asked to enter a different amount.) If the transaction is
approved by the bank, the appropriate amount of cash is dispensed by the machine
before it issues a receipt. (The dispensing of cash is also recorded in the ATM's log.)

A withdrawal transaction can be cancelled by the customer pressing the Cancel key any
time prior to choosing the dollar amount.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 10

f. Deposit Transaction Use Case

A deposit transaction asks the customer to choose a type of account to deposit to (e.g.
checking) from a menu of possible accounts, and to type in a dollar amount on the
keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a
deposit from this customer to this account. If the transaction is approved, the machine
accepts an envelope from the customer containing cash and/or checks before it issues a
receipt. Once the envelope has been received, a second message is sent to the bank, to
confirm that the bank can credit the customer's account - contingent on manual
verification of the deposit envelope contents by an operator later. (The receipt of an
envelope is also recorded in the ATM's log.)

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 11

A deposit transaction can be cancelled by the customer pressing the Cancel key any time
prior to inserting the envelope containing the deposit. The transaction is automatically
cancelled if the customer fails to insert the envelope containing the deposit within a
reasonable period of time after being asked to do so.

g. Transfer Transaction Use Case

A transfer transaction asks the customer to choose a type of account to transfer from
(e.g. checking) from a menu of possible accounts, to choose a different account to
transfer to, and to type in a dollar amount on the keyboard. No further action is
required once the transaction is approved by the bank before printing the receipt.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 12

A transfer transaction can be cancelled by the customer pressing the Cancel key any
time prior to entering a dollar amount.

h. Inquiry Transaction Use Case

An inquiry transaction asks the customer to choose a type of account to inquire about
from a menu of possible accounts. No further action is required once the transaction is
approved by the bank before printing the receipt.

An inquiry transaction can be cancelled by the customer pressing the Cancel key any
time prior to choosing the account to inquire about.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 13

i. 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 use 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.

If the customer presses Cancel instead of re-entering a PIN, the original transaction is
cancelled.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 14

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 15

4. Sequence based specification

a. Abstraction level

The transactions are considered at the general level, i.e. only the Transaction Use Case is
considered and not detailed ones like Inquiry Transaction Use Case or Deposit Transaction Use
Case. All other use cases are considered.

The transaction information are always correct, i.e. the only reason for a transaction not
working is an incorrect PIN.

b. Requirement Tags

Tags Requirements
1 System Startup Use Case
2 System Shutdown Use Case
3 Session Use Case
4 Transaction Use Case
5 Invalid PIN Extension

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 16

c. Stimuli

Stimulus Description Symbol Trace

Switch turned ON Operator turns the switch to the “ON” position SON 1
Operator enters the amount of money initially in the
Enter initial cash INIT 1
cash dispenser
Switch turned OFF Operator turns the switch to the “OFF” position SOFF 2
ATM card is inserted A customer inserts properly an ATM card into the card GOODCARD 3
properly reader slot of the machine
ATM card is inserted A customer inserts improperly an ATM card into the BADCARD 3
improperly card reader slot of the machine
Cancel key is pressed A customer pressed the cancel key CANCEL 3
Good pin is entered GOODPIN 3
Bad pin is entered BADPIN 3
Transaction details
TRANSINFO
are entered

d. Responses

Response Description Trace

Operator is asked to enter the amount of money initially in the
Wait for initial cash 1
cash dispenser
A connection to the bank will be established. Then the servicing of
Servicing starts 1
customers can begin
Servicing stops The connection to the bank will be shut down 2
The ATM pulls the card into the machine and reads it and the
Session starts 3
customer is asked to enter his/her PIN
Card is ejected 3
Session is aborted 3
Transaction starts 4
Receipt is printed 4
Customer’s card is
4
retained
Transaction is
4
cancelled

e. Enumeration of sequences

Only sequences of length 0, 1, 2 and 3 are enumerated. You will be asked in an exercise class to
continue the enumeration.

Sequence Response Equivalence Trace

 Null D1

D1 The ATM is initially off

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 17

Sequence Response Equivalence Trace

SON Wait for initial cash 1
INIT Illegal D1
SOFF Illegal D1
GOODCARD Illegal D1
BADCARD Illegal D1
CANCEL Illegal D1
GOODPIN Illegal D1
BADPIN Illegal D1
TRANSINFO Illegal D1

Sequence Response Equivalence Trace

SON SON null SON D2
SON INIT Servicing starts 1
SON SOFF Servicing stops  2
SON GOODCARD null SON D3
SON BADCARD null SON D3
SON CANCEL null SON D3
SON GOODPIN null SON D3
SON BADPIN null SON D3
SON TRANSINFO null SON D3

D2 After the switch is turned on, its physically impossible to turn it on again
D3 After the switch is turned on, the only valid Stimuli is INIT and SOFF

Sequence Response Equivalence Trace

SON INIT SON null SON INIT D2
SON INIT INIT null SON INIT D4
SON INIT SOFF null  D1
SON INIT GOODCARD Session starts 3
SON INIT BADCARD Card is ejected SON INIT 3
SON INIT CANCEL null SON INIT D5
SON INIT GOODPIN null SON INIT D5
SON INIT BADPIN null SON INIT D5
SON INIT TRANSINFO null SON INIT D5

D4 Initial cash entry is only available once during the startup

D5 As long as no session has started, any press on the keyboard is ignored

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 18

5. Initial Functional Test Cases for Example ATM System

The following initial test cases can be identified early in the design process as a vehicle
for checking that the implementation is basically correct. No attempt has been made at
this point to do thorough testing, including all possible errors and boundary cases. That
needs to come later. These cases represent an initial check that the functionality
specified by the use cases is present.

Some writers would argue for developing test cases like these in place of use cases.
Here, they are presented as a vehicle for "fleshing out" the use cases, not as a substitute
for them.

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

System is
System System accepts Enter a legitimate
requesting cash System is on
Startup initial cash amount amount
amount

System output
Perform a should demonstrate
System Connection to the System has just
legitimate inquiry that a connection has
Startup bank is established been turned on
transaction been established to
the Bank

System is shut
System is on and
System down when the Activate the "off"
not servicing a System is off
Shutdown switch is turned switch
customer
"off"

Connection to the Verify from the bank

System Bank is terminated System has just side that a
Shutdown when the system is been shut down connection to the
shut down ATM no longer exists

System reads a System is on and Card is accepted;

Insert a readable
Session customer's ATM not servicing a System asks for entry
card
card customer of PIN

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 19

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

Card is ejected;
System is on and System displays an
System rejects an Insert an
Session not servicing a error screen;
unreadable card unreadable card
customer System is ready to
start a new session

System displays a
System accepts System is asking
Session Enter a PIN menu of transaction
customer's PIN for entry of PIN
types

System allows System is

System asks whether
customer to displaying menu Perform a
Session customer wants
perform a of transaction transaction
another transaction
transaction types

System is asking
System allows
whether System displays a
multiple
Session customer wants Answer yes menu of transaction
transactions in one
another types
session
transaction

System is asking
Session ends when
whether System ejects card
customer chooses
Session customer wants Answer no and is ready to start
not to do another
another a new session
transaction
transaction

Individual types of
Transactio
transaction will be
n
tested below

Enter an incorrect
A readable card The Invalid PIN
Transactio System handles an PIN and then
has been Extension is
n invalid PIN properly attempt a
entered performed
transaction

Choose System displays a

Withdraw System asks Menu of
customer to choose transaction Withdrawal menu of account
al
an account to types is being transaction types

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 20

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

withdraw from displayed

System asks
Menu of account System displays a
Withdraw customer to choose Choose checking
types is being menu of possible
al a dollar amount to account
displayed withdrawal amounts
withdraw

System dispenses
this amount of cash;
System prints a
Choose an correct receipt
System performs a System is amount that the showing amount and
legitimate displaying the system currently correct updated
Withdraw
withdrawal menu of has and which is balance;
al
transaction withdrawal not greater than System records
properly amounts the account transaction correctly
balance in the log (showing
both message to the
bank and approval
back)

System has been

started up with
less than the
maximum Choose an System displays an
System verifies that
withdrawal amount greater appropriate message
Withdraw it has sufficient
amount in cash than what the and asks customer to
al cash on hand to
on hand; system currently choose a different
fulfill the request
System is has amount
requesting a
withdrawal
amount

Choose an System displays an

System verifies that System is amount that the appropriate message
Withdraw customer's balance requesting a system currently and offers customer
al is sufficient to fulfill withdrawal has but which is the option of
the request ammount greater than the choosing to do
account balance another transaction

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 21

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

or not.

System displays an
A withdrawal
appropriate message
transaction can be
System is and offers customer
Withdraw cancelled by the Press "Cancel"
displaying menu the option of
al customer any time key
of account types choosing to do
prior to choosing
another transaction
the dollar amount
or not.

System displays an
A withdrawal
appropriate message
transaction can be System is
and offers customer
Withdraw cancelled by the displaying menu Press "Cancel"
the option of
al customer any time of dollar key
choosing to do
prior to choosing amounts
another transaction
the dollar amount
or not.

System asks Menu of

System displays a
customer to choose transaction Choose Deposit
Deposit menu of account
an account to types is being transaction
types
deposit to displayed

System asks System displays a

Menu of account
customer to enter Choose checking request for the
Deposit types is being
a dollar amount to account customer to type a
displayed
deposit dollar amount

System is
System asks displaying a System requests that
Enter a legitimate
Deposit customer to insert request for the customer insert an
dollar amount
an envelope customer to type envelope
a dollar amount

System accepts
System performs a System is envelope;
legitimate deposit requesting that Insert an System prints a
Deposit
transaction customer insert envelope correct receipt
properly an envelope showing amount and
correct updated

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 22

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

balance;
System records
transaction correctly
in the log (showing
message to the bank,
approval back, and
acceptance of the
envelope)

System displays an
A deposit
appropriate message
transaction can be
System is and offers customer
cancelled by the Press "Cancel"
Deposit displaying menu the option of
customer any time key
of account types choosing to do
prior to inserting
another transaction
an envelope
or not.

System displays an
A deposit
System is appropriate message
transaction can be
requesting and offers customer
cancelled by the Press "Cancel"
Deposit customer to the option of
customer any time key
enter a dollar choosing to do
prior to inserting
amount another transaction
an envelope
or not.

System displays an
A deposit
System is appropriate message
transaction can be
requesting and offers customer
cancelled by the Press "Cancel"
Deposit customer to the option of
customer any time key
insert an choosing to do
prior to inserting
envelope another transaction
an envelope
or not.

A deposit System is System displays an

transaction is requesting Wait for the appropriate message
Deposit cancelled customer to request to time and offers customer
automatically if an insert an out the option of
envelope is not envelope choosing to do
inserted within a another transaction

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 23

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

reasonable time or not.

System asks Menu of System displays a

customer to choose transaction Choose Transfer menu of account
Transfer
an account to types is being transaction types specifying
transfer from displayed transfer from

System asks Menu of account System displays a

customer to choose types to transfer Choose checking menu of account
Transfer
an account to from is being account types specifying
transfer to displayed transfer to

System asks Menu of account System displays a

customer to enter types to transfer Choose savings request for the
Transfer
a dollar amount to to is being account customer to type a
transfer displayed dollar amount

System prints a
correct receipt
showing amount and
System is correct updated
System performs a
displaying a balance;
legitimate transfer Enter a legitimate
Transfer request for the System records
transaction dollar amount
customer to type transaction correctly
properly
a dollar amount in the log (showing
both message to the
bank and approval
back)

System displays an
A transfer
System is appropriate message
transaction can be
displaying menu and offers customer
cancelled by the Press "Cancel"
Transfer of account types the option of
customer any time key
specifying choosing to do
prior to entering
transfer from another transaction
dollar amount
or not.

A transfer System is Press "Cancel" System displays an

Transfer transaction can be displaying menu key appropriate message
cancelled by the of account types and offers customer

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 24

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

customer any time specifying the option of

prior to entering transfer to choosing to do
dollar amount another transaction
or not.

System displays an
A transfer
System is appropriate message
transaction can be
requesting and offers customer
cancelled by the Press "Cancel"
Transfer customer to the option of
customer any time key
enter a dollar choosing to do
prior to entering
amount another transaction
dollar amount
or not.

System asks Menu of

System displays a
customer to choose transaction Choose Inquiry
Inquiry menu of account
an account to types is being transaction
types
inquire about displayed

System prints a
correct receipt
showing correct
System performs a balance;
System is
legitimate inquiry Choose checking System records
Inquiry displaying menu
transaction account transaction correctly
of account types
properly in the log (showing
both message to the
bank and approval
back)

System displays an
An inquiry
appropriate message
transaction can be
System is and offers customer
cancelled by the Press "Cancel"
Inquiry displaying menu the option of
customer any time key
of account types choosing to do
prior to choosing
another transaction
an account
or not.

Invalid PIN Customer is asked Enter an incorrect Customer is asked to

Extension to reenter PIN PIN; re-enter PIN

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 25

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

Attempt an
inquiry
transaction on
the customer's
checking account

Request to re- Original transaction

Invalid PIN Correct re-entry of
enter PIN is Enter correct PIN completes
Extension PIN is accepted
being displayed successfully

An incorrect PIN
A correctly re- has been re-
This transaction
Invalid PIN entered PIN is used entered and Perform another
completes
Extension for subsequent transaction transaction
successfully as well
transactions completed
normally

An appropriate
Incorrect re-entry Request to re- message is displayed
Invalid PIN Enter incorrect
of PIN is not enter PIN is and re-entry of the
Extension PIN
accepted being displayed PIN is again
requested

Enter incorrect
Correct re-entry of Request to re- Original transaction
Invalid PIN PIN the first time,
PIN on the second enter PIN is completes
Extension then correct PIN
try is accepted being displayed successfully
the second time

Enter incorrect
PIN the first time
Correct re-entry of Request to re- Original transaction
Invalid PIN and second
PIN on the third try enter PIN is completes
Extension times, then
is accepted being displayed successfully
correct PIN the
third time

Three incorrect re- Request to re- An appropriate

Invalid PIN entries of PIN Enter incorrect message is displayed;
enter PIN is
Extension result in retaining PIN three times Card is retained by
being displayed
card and aborting machine;

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 26

Function Being Initial System

Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

transaction Session is terminated

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 27

II. Design

6. Class descriptions
Class Responsibilities Collaboration
OperatorPanel
Start up when switch is turned on CashDispenser
NetworkToBank
Shut down when switch is turned off NetworkToBank
ATM
Start a new session when card is inserted by CustomerConsole
customer Session
Provide access to component parts for sessions
and transactions

Tell ATM when card is inserted ATM

Read information from card Card
CardReader
Eject card
Retain card

Keep track of cash on hand, starting with initial

amount
CashDispenser
Report whether enough cash is available
Dispense cash Log

Display a message
Display a prompt, accept a PIN from keyboard
Display a prompt and menu, accept a choice from
CustomerConsole keyboard
Display a prompt, accept a dollar amount from
keyboard
Respond to cancel key being pressed by customer

Accept envelope from customer; report if timed

EnvelopeAcceptor Log
out or cancelled

Log messages sent to bank

Log responses from bank
Log
Log dispensing of cash
Log receiving an envelope

Initiate connection to bank at startup

Message
Log
NetworkToBank Send message to bank and wait for response
Balances
Status
Terminate connection to bank at shutdown

OperatorPanel Inform ATM of changes to state of switch ATM

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 28

Allow operator to specify amount of initial cash

ReceiptPrinter Print receipt Receipt

ATM
CardReader
Perform session use case Card
Session
CustomerConsole
Transaction
Update PIN value if customer has to re-enter it

ATM
CustomerConsole
Withdrawal
Allow customer to choose a type of transaction
Deposit
Transfer
Inquiry
ATM
CustomerConsole
Withdrawal
Transaction
Deposit
(Abstract class)
Transfer
Perform Transaction Use Case
Inquiry
Message
NetworkToBank
Receipt
ReceiptPrinter
CustomerConsole
Perform invalid PIN extension Session
CardReader

CustomerConsole
Perform operations peculiar to withdrawal CashDispenser
Withdrawal
transaction use case Message
Receipt

CustomerConsole
Perform operations peculiar to deposit Message
Deposit
transaction use case EnvelopeAcceptor
Receipt

CustomerConsole
Perform operations peculiar to transfer
Transfer Message
transaction use case
Receipt

CustomerConsole
Perform operations peculiar to inquiry transaction
Inquiry Message
use case
Receipt

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 29

Represent account balance information returned

Balances
by bank

Represent information encoded on customer's

Card
ATM card

Represent information to be sent over network to

Message
bank

Receipt Represent information to be printed on a receipt

Represent transaction status information

Status
returned by bank

7. Structural view: Class Diagram for Example ATM System

Shown below is the class diagram for the ATM system. The basic structure of the class
diagram arises from the responsibilities and relationships discovered when doing the
CRC cards and Interaction Diagrams. (If a class uses another class as a collaborator, or
sends a message to an object of that class during an Interaction, then there must either
be an association linking objects of those class es, or linking the "sending" class to an
object which provides access to an object of the "receiving" class.)

In the case of the ATM system, one of the responsibilities of the ATM is to provide
access to its component parts for Session and Transaction objects; thus, Session and
Transaction have associations to ATM, which in turn has associations to the classes
representing the individual component parts. (Explicit "uses" links between Session and
Transaction, on the one hand, and the component parts of the ATM, on the other hand,
have been omitted from the diagram to avoid making it excessively cluttered.)

The need for the various classes in the diagram was discovered at various points in the
design process.

That is, OO design is not a "waterfall" process - discoveries made when doing detailed
design and coding can impact overall system design.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 30

To prevent the diagram from becoming overly large, only the name of each class is
shown - the attribute and behavior "compartments" are shown in the detailed design,
but are omitted here.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 31

8. State Charts for Example ATM System

Three of the objects we have identified have behavior that is sufficiently complex to
warrant developing a State Chart for them. (These are the objects that were identified
as the major controller objects.)

 The object representing the machine itself (responsible for the System Startup
and Shutdown use cases)
 Objects representing a customer session (one per session) (responsible for the
Session use case)
 Objects representing an individual transaction (one per transaction) (responsible for
the Transaction use case, use cases for the specific types of transaction, and
Invalid PIN extension).

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 32

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 33

III. Implementation

1. Detailed Design
A major task of detailed design is to spell out, in detail, the attributes and methods
needed by each class (the second and third "compartments" of the representation for
each class in a class diagram.)

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 34

The methods needed by each class are implicit in the responsibilities assigned to the
class in the CRC cards, and become explicit in the Interaction Diagrams. A responsibility
listed for a class on its CRC card generally maps into a method or methods in the
detailed design. Likewise, any time an object belonging to a given class is shown as the
recipient of a message in either a Sequence or Collaboration Diagram, the class needs a
corresponding method. Many of the needed attributes are also either explicitly or
implicitly present in the diagrams; the need for others becomes evident as the code for
the class is being written. (Thus detailed design and coding are a "round trip" process -
detailed design dictates coding, and coding leads to elaboration of the detailed design.)

In designing this system, a few key design decisions were made:

 The class ATM is made an active class - that is, the ATM object has its own
thread. Using the Java thread facllity leads to defining a run() method in this
class whose body is executed by the ATM's thread. The fact that class ATM is
active is indicated in class diagrams by enclosing it in a heavier outline.

 Certain signals initiate computation - e.g. the signals from the operator console
when the state of the switch is changed, or from the card reader when a card is
inserted. In the GUI simulation of the ATM, these signals are sent by the
"actionPerformed()" method of the appropriate GUI button; in a real ATM they
would be sent by the physical components themselves, which might then also
need to be active classes. (Note: this forms an exception to the rule that a
responsibility on a CRC card translates into a method in the design - in this case
the class sends a signal, rather than receiving it, so it does not need a method
directly corresponding to the responsibility.)

 The Transaction hierarchy consists of the abstract class Transaction and four
concrete subclasses (Withdrawal, Deposit, Transfer and Inquiry). The class
Transaction has a "virtual constructor" called makeTransaction() which asks the
customer to choose a transaction type and then constructs and returns an object

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 35

of the appropriate subclass. The Transaction class is made responsible for

carrying out the Transaction use case and the Invalid PIN extension; for the
former, it makes use of abstract methods getSpecificsFromCustomer() and
completeTransaction() which are implemented concretely by each subclass.

 The class Receipt is abstract. The completeTransaction() method of each kind of

transaction creates a concrete instance that contains the information relevant to
that kind of transaction.

 The class Status is abstract. The send() method of NetworkToBank constructs a

concrete instance that contains the information appropriate to the response
received from the bank to a particular message.

ATM

- id: int

- place: String

- bankName: String

- bankAddress: InetAddress

- cardReader: CardReader

- cashDispenser: CashDispenser

- customerConsole: CustomerConsole

- envelopeAcceptor: EnvelopeAcceptor

- log: Log

- networkToBank: NetworkToBank

- operatorPanel: OperatorPanel

- receiptPrinter: ReceiptPrinter

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 36

- state: int

- switchOn: boolean

- cardInserted: boolean

- OFF_STATE: final int

- IDLE_STATE: final int

- SERVING_CUSTOMER_STATE: final int

+ ATM(id: int, place: String, bankName: String, bankAddress: InetAddress)

+ run()

+ switchOn()

+ switchOff

+ cardInserted()

+ getID(): int

+ getPlace(): String

+ getBankName(): String

+ getCardReader(): CardReader

+ getCashDispenser(): CashDispenser

+ getCustomerConsole(): CustomerConsole

+ getEnvelopeAcceptor(): EnvelopeAcceptor

+ getLog(): Log

+ getNetworkToBank(): NetworkToBank

+ getOperatorPanel(): OperatorPanel

+ getReceiptPrinter(): ReceiptPrinter

- performStartup()

- performShutdown()

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 37

CardReader

- atm: ATM

+ CardReader(atm: ATM)

+ readCard(): Card

+ ejectCard()

+ retainCard()

CashDispenser

- log: Log

- cashOnHand: Money

+ CashDispenser(log: Log)

+ setInitialCash(initialCash: Money)

+ checkCashOnHand(amount: Money): boolean

+ dispenseCash(amount: Money)

CustomerConsole

+ CustomerConsole()

+ display(message: String)

+ readPIN(prompt: String): int throws Cancelled

+ readMenuChoice(prompt: String, menu: String []): int throws Cancelled

+ readAmount(prompt: String): Money throws Cancelled

EnvelopeAcceptor

- log: Log

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 38

+ EnvelopeAcceptor(log: Log)

+ acceptEnvelope() throws Cancelled

Log

+ Log()

+ logSend(message: Message)

+ logResponse(status: Status)

+ logCashDispensed(amount: Money)

+ logEnvelopeAccepted()

NetworkToBank

- log: Log

- bankAddress: InetAddress

+ NetworkToBank(log: Log, bankAddress: InetAddress)

+ openConnection()

+ closeConnection()

+ sendMessage(message: Message, out balances: Balances): Status

OperatorPanel

- atm: ATM

+ OperatorPanel(atm: ATM)

+ getInitialCash(): Money

ReceiptPrinter

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 39

+ ReceiptPrinter()

+ printReceipt(receipt: Receipt)

Session

- atm: ATM

- pin: int

- state: int

- READING_CARD_STATE: final int

- READING_PIN_STATE: final int

- CHOOSING_TRANSACTION_STATE: final int

- PERFORMING_TRANSACTION_STATE: final int

- EJECTING_CARD_STATE: final int

- FINAL_STATE: final int

+ Session(atm: ATM)>

+ performSession()

+ setPIN(int pin)

Transaction

# atm: ATM

# session: Session

# card: Card

# pin: int

# serialNumber: int

# message: Message

# balances: Balances

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 40

- TRANSACTION_TYPES_MENU: final String []

- nextSerialNumber: int

- state: int

- GETTING_SPECIFICS_STATE: final int

- SENDING_TO_BANK_STATE: final int

- INVALID_PIN_STATE: final int

- COMPLETING_TRANSACTION_STATE: final int

- PRINTING_RECEIPT_STATE: final int

- ASKING_DO_ANOTHER_STATE: final int

# Transaction(atm: ATM, session: Session, card: Card, pin: int)

+ makeTransaction(atm: ATM, session: Session, card: Card, pin: int): Transaction throws
Cancelled

+ performTransaction(): boolean throws CardRetained

+ performInvalidPinExtension(): Status throws Cancelled, CardRetained

+ getSerialNumber(): int

# getSpecificsFromCustomer(): Message throws Cancelled

# completeTransaction(): Receipt throws Cancelled

Withdrawal

- from: int

- amount: Money

+ Withdrawal(atm: ATM, session: Session, card: Card, pin: int)

# getSpecificsFromCustomer(): Message throws Cancelled

# completeTransaction(): Receipt

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 41

Deposit

- to: int

- amount: Money

+ Deposit(atm: ATM, session: Session, card: Card, pin: int)

# getSpecificsFromCustomer(): Message throws Cancelled

# completeTransaction(): Receipt throws Cancelled

Transfer

- from: int

- to: int

- amount: Money

+ Transfer(atm: ATM, session: Session, card: Card, pin: int)

# getSpecificsFromCustomer(): Message throws Cancelled

# completeTransaction(): Receipt

Inquiry

- from: int

+ Inquiry(atm: ATM, session: Session, card: Card, pin: int)

# getSpecificsFromCustomer(): Message throws Cancelled

# completeTransaction(): Receipt

AccountInformation

+ ACCOUNT_NAMES: final String[]

+ ACCOUNT_ABBREVIATIONS: final String []

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 42

Balances

- total: Money

- available: Money

+ Balances()

+ setBalances(total: Money, available: Money)

+ getTotal(): Money

+ getAvailable(): Money

Card

- number: int

+ Card(number: int)

+ getNumber(): int

Message

+ WITHDRAWAL: final int

+ INITIATE_DEPOSIT: final int

+ COMPLETE_DEPOSIT: final int

+ TRANSFER: final int

+ INQUIRY: final int

- messageCode: int

- card: Card

- pin: int

- serialNumber: int

- fromAccount: int

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 43

- toAccount: int

- amount: int

+ Message(messageCode: int, cardNumber: Card, pin: int, serialNumber: int,

fromAccount: int, toAccount: int, amount: Money)

+ toString(): String

+ setPIN(pin: int)

+ getMessageCode(): int

+ getCard(): Card

+ getPIN(): int

+ getSerialNumber(): int

+ getFromAccount(): int

+ getToAccount(): int

+ getAmount(): Money

Money

- cents: long

+ Money(dollars: int)

+ Money(dollars: int, cents: int)

+ Money(toCopy: Money)

+ toString(): String

+ add(amountToAdd: Money)

+ subtract(amountToSubtract: Money)

+ lessEqual(compareTo: Money): boolean

Receipt

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 44

- headingPortion: String []

# detailsPortion(): String []

- balancesPortion: String []

# Receipt(atm: ATM, card: Card, transaction: Transaction, balances: Balances)

+ getLines(): Enumeration

Status

+ toString(): String

+ isSuccess(): boolean

+ isInvalidPIN(): boolean

+ getMessage(): String

2. Package Diagram for Example ATM System

The package diagram shows how the various classes are grouped into packages. There
are two "top-level" classes - ATMMain and ATMApplet - which allow the system to be
run (respectively) as an application or as an Applet. (Only one of the two would be
instantiated in any particular use of the system.)

Each of these classes, in turn, depends on the package atm which contains the class
ATM that represents the system as a whole, and the class Session that represents one
session. ATM depends on Session, and vice versa - since the ATM creates Sessions, and
each Session, in turn, uses the ATM to interact with the customer.

The subpackage transaction contains the classes used to represent individual

transactions that a customer initiates. The class Session depends on the transaction
package because it creates individual transaction objects. These, in turn, again depend
on the ATM to interact with the customer.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 45

The subpackage physical contains the classes that represent the various physical
components of the ATM. For the purposes of this simulation, these are simulated by a
GUI. A real ATM would have quite different classes in this package - classes that actually
control its physical components. The class ATM makes use of these components, and
Session and the various kinds of transaction gain access to them through ATM to
actually perform the needed operations.

Finally, the package banking contains classes that represent the banking enterprise itself
and the information communicated back and forth between the ATM and the bank - i.e.
classes which might be the same in a totally different implementation of an ATM that
interacts with the same bank.

This is, of course, a simulation. However, most of the code that is specific to the
simulation resides in the package physical, plus the two top-level classes. Presumably,
the other classes and packages might be similar in a real system.

AG Software Engineering: Processes and Measurement

 ATM Simulation Example 46

AG Software Engineering: Processes and Measurement