1.

Introduction to the ATM system

This is a complete example of object-oriented analysis, design, and programming
applied to a moderate size problem: the simulation of an Automated Teller Machine.
Beginning with a statement of requirements, the process proceeds through
analysis, overall design, and detailed design and implementation, culminating with some
suggestions for maintenance.
Analysis is done by identifying the use cases and detailing a flow of events for
each. Analysis culminates in identifying classes implied by the use cases, and
documenting them using an Analysis Class Diagram
Design begins by using CRC cards to assign responsibilities to the various
classes. The static structure of the design is summarized by means of an overall Class
Diagram. Then the dynamic aspects of the design are developed, using State Charts for
the major controller classes, plus an Interaction Diagram for each of the main use cases.

Using these Pages

Probably the best way to start using these pages is to first read the requirements, and then
work through the entire analysis, design, and implementation process.
1. Begin with the Statement of Requirements and then view the Use Cases. The Use
Case document has a Use Case Diagram and a series of flows of events, one for
each use case.
2. Having looked at the requirements/analysis documents, you can then study the
design phase by viewing the CRC cards, the overall Class Diagram, and the
Statechart and Interaction Diagrams.
o

There is one CRC card for each class, incorporating all responsibilities of
the class arising from all of the use cases, linked to from the icon for the
class in either Class Diagram. The CRC cards were created by "walking
through" each use case, assigning the responsibility for each task to some
class.

The Class Diagram pulls together all of the structural information from the
CRC Cards and shows the needed links between classes. Each class icon is
o
o

linked to other relevant design documents, including a detailed design for

that class.
For the major controller classes, there is also a Statechart diagram
depicting the various states the corresponding object can be in. This, too,
is accessible from the class's icon in either Class Diagram.
Finally, there is one Interaction diagram for each use case, linked to from
the use case flow of events. This shows the objects that work together to
realize the use case, and the flow of messages between them. This records
the same assignment of responsibilities as in the CRC cards, but in a
different way (organized by use case, rather than by class), with additional
detail. (These, rather than the CRC cards, were actually used when
creating the detailed design. CRC cards are not actually a UML diagram,
but are a useful tool to help in discovering the design that does get
recorded in UML Interaction diagrams.)

In terms of the order in which these would be created, the Analysis Class Diagram
and the CRC cards would be done first, then the overall Class Diagram, and
finally the Statechart and Interaction Diagrams. Thus, to understand the design
process, these could be read in the order they were created. However, in terms of
understanding the design itself, it may be desirable to read the Class Diagram
first.
2. The detailed design document was developed directly from the Interaction
diagrams and Class Diagram. The former determined what methods the class
would need, and both the former and the latter determined what attributes were
needed.
In terms of actually writing the code, the skeletons for the various classes were
created directly from the detailed design. The individual method bodies were
fleshed out by using the Statechart and Interaction diagrams. Each message on the
Interaction diagram becomes a line or so of code in the implementation. The
controller classes for which a statechart was done have a method that is structured

as a finite state machine based on the statechart (run() in ATM; performSession()

in Session; performTransaction() in Transaction.)
Although this web site shows a finished product in which the various design
documents and the code are in agreement, the reality is that the coding process
demonstrated the need for slight changes to the various design documents, so in
some cases the design documents were modified to conform to the code, rather
than vice versa. (However, the bulk of the design did exist before the code was
written! The idea is to use the design documents to guide coding, not to produce
design documents after the fact!)
3. Under the Quality Assurance heading, there is a link to an executable (applet)
form of the Java implementation, which you can run if you have a JDK 1.1.x (or
later) compliant browser. Enjoy!
4. Finally, under the Maintenance heading, there is a link to a page of suggested
changes. One such change deals with implementing a stated requirement that is
missing from the design and implementation presented here. (This would never
happen in real life, of course :-) ) Can you find the missed requirement? Other
changes have to do with adding additional features to the system. These make
interesting exercises for the reader.

ATM Use Case Diagram

TM Use Case Diagram

ATM Use Case

Diagram Content Summary

Documentation

This is the ATM system use case diagram. It descript the geneal actions that user will
perform to the ATM machine.
UseCase Withdraw Money
Documentation
This is the withdraw money use case. User must login before using this use case. After
user has login, the system will ask for the amount that he want to withdraw. Once the
amount was entered, system will check for the current balance of the user. If the balance
is ok, then the requested amount of money will be dispense to the user, and current
balance will be updated. If the balance is not enough, then the system will inform the user
that he doesn't have enough amount of money to withdraw.
UseCase Transfer Money
Documentation
This is the transfer money use case. It require the user must login first. After the user has
login, the user will ask to enter the receiver's account number. Once the receiver's account
number was entered, then the system will then prompt the user to enter the amount that
he want to transfer. After the user has enter the amount, the system will check for account
balance of the user. If the balance is ok, then the system will do the transfer, otherwise the
system will prompt the user that he doesn't have enough balance and the action will be
cancel.

UseCase Check Balance

Documentation

This is the check balance use case. It require the user must login first. After the user has
login, the system will list out the accounts that the user have, and ask to select the
account for query the balance. Once the user has select the account, the system will
displays the balance to the user.
UseCase Deposit Money
Documentation
This is the deposit money use case. It require user to login first. After user has login, the
system will ask for the amount that he want to deposit. Once the user has entered the
amount, the system will send out the envelop. The user will then put the same amount of
money as he entered into the envelop and insert it into the ATM system. After the system
receive the envelop, then it will show the deposit success message on the screen, and
print out the receipt.
UseCase Login
Documentation
This is the login use case, all other action are depend on this use case. When user login, it
require user to enter the account password. Once the system receive the password, then it
will verify the password with the account. If the password is valid, login was success.
Otherwise it will prompt the user that the password was invalid, and ask for the password
again.
Actor User
Documentation
This is the ATM system user.

ATM Class Diagram

ATM Class Diagram

Diagram Content Summary

Documentation

This is the ATM system class diagram.

Class CardController
Documentation
This is the Card Controller. It is use to determine the card is a valid ATM card or not,
control the card reader when to read date from the card, also when to eject the card.
Class CashDispenser
Documentation
This is the cash dispenser. It control how the cash dispense to the user.
Class ATMController
Documentation
This is the ATM Controller class. It is the main controller of the ATM machine. It contain
the methods for user to perform withdraw/deposit/transfer money, check balance and
login. Also it contain method to verify the card that the user inserted is a valid ATM card
or not.
Class BankConsortium
Documentation
This is the Bank Consortium. It act as the middle man between the ATM system and the
Bank.

Class Account
Documentation

This is the Account class. It hold the account information such as account number,
password(PIN), account type and the current balance.
Class Bank
Documentation
This is the Bank. It holds the bank information and the accounts.
Package atm
Documentation
This is the ATM system. It contain classes that directly related to the ATM machine.
Package consortium
Documentation
This is the consortium package.
Package bank
Documentation
This is the Bank package.

ATM Sequence Diagram

Diagram Content Summary

Documentation

This is the subsystem level sequence diagram for the ATM system normal scenario
withdraw money use case. It expends from the system level sequence diagram, shows
how different subsystems inside the ATM system work together.
Actor User
Documentation
This is the ATM user, which will perform several tasks on the ATM system.
Object ATM
Documentation
This is the ATM subsystem.
Object Bank
Documentation
This is the Bank subsystem.
Object Bank Consortium
Documentation
This is the Bank Consortium subsystem. The bank consortium acts as the middle man
between the ATM subsystem and the Bank.

ATM Collaboration Diagram

Diagram Content Summary

Actor User
Documentation
This is the ATM system user.
Message to Card Reader
Name : insert card
Sequence number : 1
Message to KeyPad
Name : enter PIN
Sequence number : 13
Message to KeyPad
Name : select withdraw money
Sequence number : 23
Message to KeyPad
Name : enter amount
Sequence number : 27

Object Card Reader

Message to User
Name : card
Sequence number : 39
Message to Card Controller
Name : verify card
Sequence number : 2
Parent : boundary object

Object KeyPad
Message to ATM Controller
Sequence number : 4
Message to ATM Controller
Name : PIN code
Sequence number : 14
Message to ATM Controller
Name : withdraw money
Sequence number : 24

Message to ATM Controller

Name : withdraw request

Sequence number : 28
Parent : boundary object

Object Display
Message to User
Name : show PIN request
Sequence number : 12
Message to User
Name : show services request
Sequence number : 22
Message to User
Name : show enter amount request
Sequence number : 26
Message to User
Name : show withdraw success message
Sequence number : 36

Message to User

Name : main screen

Sequence number : 43
Parent : boundary object

Object Cash Dispenser

Message to User
Name : cash
Sequence number : 41
Parent : boundary object

Object Card Controller

Message to Card Reader
Name : reject card
Sequence number : 38
Message to Display
Name : ask forPIN
Sequence number : 11

Message to ATM Controller

Name : verify card

Sequence number : 3
Parent : control object

Object ATM Controller

Message to Card Controller
Name : verify card
Sequence number : 10
Message to Card Controller
Name : reject card
Sequence number : 37
Message to Display
Sequence number : 4
Message to Display
Sequence number : 4
Message to Display
Sequence number : 14

Message to Display

Name : ask for select services

Sequence number : 21
Message to Display
Name : ask for amount
Sequence number : 25
Message to Display
Name : withdraw success
Sequence number : 35
Message to Display
Name : show main screen
Sequence number : 42
Message to Cash Dispenser
Name : dispense cash
Sequence number : 40
Message to Bank Consortium

Name : verify card

Sequence number : 4
Message to Bank Consortium
Name : verify account
Sequence number : 15
Message to Bank Consortium
Name : withdraw request
Sequence number : 29
Parent : control object

Object Bank Consortium

Message to ATM Controller
Name : card valid
Sequence number : 9
Message to ATM Controller
Name : account OK
Sequence number : 20
Message to ATM Controller

Name : withdraw OK

Sequence number : 34
Message to Bank
Name : verify card
Sequence number : 5
Message to Bank
Name : verify account with Bank
Sequence number : 16
Message to Bank
Name : withdraw request
Sequence number : 30
Parent : control object

Object Bank
Message to Bank Consortium
Name : card valid
Sequence number : 8
Message to Bank Consortium

Name : account OK

Sequence number : 19
Message to Bank Consortium
Name : withdraw OK
Sequence number : 33
Message to Account
Name : verify card
Sequence number : 6
Message to Account
Name : verify account
Sequence number : 17
Message to Account
Name : withdraw request
Sequence number : 31
Parent : control object

Object Account

Message to Bank
Name : card valid
Sequence number : 7
Message to Bank
Name : account OK
Sequence number : 18
Message to Bank
Name : withdraw OK
Sequence number : 32
Parent : entity object

SwimLane
Children:
Actor
SwimLane boundary object
Children:
Card Reader, KeyPad, Display, Cash Dispenser

SwimLane control object

Children:
Card Controller, ATM Controller, Bank Consortium, Bank
SwimLane entity object
Children:
Account

ATM State Diagram

Diagram Content Summary

Documentation

This is the state diagram of the ATM system, which model the detail state changes in the
withdraw money scenario.
Initial State InitialState
Transition link to Main screen
Transition link to Main screen

State process transaction

Transition link transaction success to Main screen
Transition link transaction success to Main screen
Transition link from wait for entering amount

State wait for entering amount

Transition link enter amount to process transaction
Transition link enter amount to process transaction
Transition link users cancel action to Cancel
Transition link from wait for selecting services

State wait for selecting services

Transition link select withdraw money to wait for entering amount

Transition link select withdraw money to wait for entering amount

Transition link users cancel action to Cancel
Transition link from wait for account verification

State wait for account verification

Transition link account OK to wait for selecting services
Transition link account OK to wait for selecting services
Transition link bad PIN to wait for PIN
Transition link from wait for PIN

State wait for PIN

Transition link enter PIN code to wait for account verification
Transition link enter PIN code to wait for account verification
Transition link user cancels action to Cancel
Transition link from Main screen, wait for account verification

State Main screen

Transition link insert card to wait for PIN

Transition link insert card [valid card] to wait for PIN

Guard detail
Name: valid card
Transition link insert card [invalid card] to Main screen

Guard detail
Name: invalid card
Transition link from process transaction, InitialState, Main screen, Cancel

State Cancel
Transition link operation cancel to Main screen
Transition link from wait for PIN, wait for entering amount, wait for selecting services.

ATM Card Controller

Diagram Content Summary

Documentation

This is the state diagram of the Card Controller. It is use to model the state change of a
control object. It shows up the detail state change of the first phrase verify ATM card
action.
Initial State InitialState2
Transition link to Check card type

State Check card type

Transition link reject [not a valid ATM card] to Final State
Transition link OK [is a ATM card] to Check card with bank consortium
Transition link from InitialState2

State Check card with bank consortium

Transition link reject [ the card issuer bank not in the list of the bank
consortium to Final State
Transition link OK [the ATM card is valid] to FinalState2
Transition link from Check card type

Final State FinalState

Transition link from

Check card type, Check card with bank consortium

Final State FinalState2

Transition link from
Check card with bank consortium

ATM User Activity Diagram

Diagram Content Summary

Documentation

This is the activity diagram for the atm user. It's shows that action that the user will
perform in the withdraw money scenario.
Initial State InitialState3
Transition link to Insert card

Action State Insert card

Transition link to Enter PIN
Transition link from InitialState3

Action State Enter PIN

Documentation
Pre-condition in this stage: the ATM card must be valid.
Entry Action
Name :
Transition link to Select withdraw services
Transition link from Insert card

Action State Select withdraw services

Documentation

Pre-condition: the PIN must be valid

Transition link to Enter amount
Transition link from Enter PIN

Action State Enter amount

Transition link to SynchronizationBar
Transition link from Select withdraw services

Action State Get Card

Transition link to SynchronizationBar3
Transition link from SynchronizationBar

Action State Get Money

Transition link to SynchronizationBar3
Transition link from SynchronizationBar

Synchronization BarSynchronizationBar
Documentation

Assume the cash and ATM card are dispense to the user at the same time.
Transition link to Get Money
Transition link to Get Card
Transition link from Enter amount

Synchronization BarSynchronizationBar3
Transition link to FinalState3
Transition link from Get Money, Get Card

Final State FinalState3

Transition link from SynchronizationBar3

ATM Card Controller Activity Diagram

Diagram Content Summary

Documentation

This activity diagram shows how the card controller works.

Initial State InitialState4
Transition link to Receive Card

Action State Receive Card

Transition link to Decision
Transition link from InitialState4

Action State Card is Valid

Transition link to FinalState4
Transition link from Decision

Action State Card is invalid

Transition link to SynchronizationBar5
Transition link from Decision

Action State Show error message

Transition link to SynchronizationBar6
Transition link from SynchronizationBar5

Action State Eject card

Transition link to SynchronizationBar6
Transition link from SynchronizationBar5

Decision Point Decision

Transition link to Card is Valid
Transition link to Card is invalid
Transition link from Receive Card

Synchronization BarSynchronizationBar5
Documentation
Assume the error message and eject the invalid card are done in the same time.
Transition link to Show error message
Transition link to Eject card
Transition link from Card is invalid

Synchronization BarSynchronizationBar6
Transition link to FinalState5

Transition link from Show error message, Eject card

Final State FinalState4

Transition link from Card is Valid

Final State FinalState5

Transition link from SynchronizationBar6

ATM Component Diagram

Reciept
printer
Transaction
details

Card reader

Cash
dispenser
Account info
Update
Account info
ATM
machine
Network
interface

Bank server
Network
interface

Diagram Content Summary

Documentation
A component diagram in the Unified Modeling Language, depicts how components are
wired together to form larger components and or software systems.
Components are wired together by using an assembly connector to connect the required
interface of one component with the provided interface of another component.
This illustrates the service consumer - service provider relationship between the two
components.
An assembly connector is a connector between two components that defines that one
component provides the services that another component requires.
An assembly connector is a connector that is defined from a required interface or port to a
provided interface or port.

ATM Deployment Diagram

Diagram Content Summary

Documentation
Deployment diagram models the physical deployment of artifacts on nodes.
The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles
within the boxes.
Nodes may have subnodes, which appear as nested boxes.
A single node in a deployment diagram may conceptually represent multiple physical
nodes, such as a cluster of database servers.
The diagram that follows illustrates two Nodes (the ATM itself, which is the focus of this
example), and the Bank Server, through which all connections to the inter-bank network
are made. Though the Bank Server is out of scope for the builders of the ATM, we show
it here to illustrate how network bandwidth can be documented. The diagram also shows
the processes and threads which execute on the ATM Node, which are discussed in the
next step Allocate processes to nodes.