Automatic Teller Machine (ATM)

&
Cash Deposit Machine (CDM)

Software Design Specification

(SDS)

Lecturer: Dr Yew Kwang Hooi

Team Members:
1. Hari Saresh – 23261
2. Danial bin Abd Rahman – 19074
3. Kines Kesavan – 23326
4. Joseph Mabor – 23113
5. Lagindran A/L Anandarajah – 23237
6. Nor Hani Nabila Binti Haji Kamarrulzaman - 24064
 Document Control

Document Name ATMS Software Design Specification

Reference Number ATMS_SDS
Version 1.0
Project Code SDA_ATMS
Status In-Use
Date Released 28th March 2020

Name Position Signature

Kines Kesavan Business Analyst
Hari Saresh Lead Developer
Danial Rahman Team Leader

Version History

Version Release Date Section Amendments

1.0 28/3/2020 All Original Document

2
 Table of Contents

Document Control 2
Version History 2
Table of Contents 3
Introduction 5
Purpose 5
Scope 5
Intended Audience 5
Product 5
Definition & Acronyms 6
Overview 8
System Consideration 9
Assumptions and Dependencies 9
Related Software and Hardware 9
End user Characteristic 9
General Constraints 10
Goals and Guidelines 10
Development Methods 10
System Architecture and Strategies 11
System Architecture 11
Subsystem Architecture 12
Start Up (Component Diagram) 14
Shutdown (Component Diagram) 14
Withdrawal (Component Diagram) 15
Deposit (Component Diagram) 15
Transfer (Component Diagram) 16
Balance Inquiry (Component Diagram) 16
System States 17
Start Up (State Diagram) 17
Shutdown (State Diagram) 18
Session Verification (State Diagram) 19

3
 Withdrawal (State Diagram) 21
Deposit (State Diagram) 23
Transfer (State Diagram) 25
Balance Inquiry (State Diagram) 27
Appendix 28
Sequence Diagram 28
Data Flow Diagram 28
Communication Diagram 28
C.1 Withdrawal 29
C.2 Cash Deposit 30
C.3 Transfer 31
C.4 Balance Inquiry 32

4
 Introduction

Purpose
The purpose of this SDS document is to provide the details of the design of the system. This
document gives a better understanding of the design process for this system. It addresses the
design implementation of Automated Teller Machine System.

Scope
This document is written for the ATMS. This document contains information about the system
consideration, system architecture, low level design and high-level design.

Intended Audience
The intended audiences of this document are the lecturer of the Software Design and
Architecture course, Dr Yew Kwang Hooi, and any of his associates he deems necessary.

These are the outputs of undergraduate student's team project and is strictly for education
purposes only.

Product
The name of product is Automated Teller Machine System or "ATMS' in short. ATMS is a
system which consist of a Cash Deposit Machine (CDM) which allows the user to deposit,
withdraw, inquire and transfer money to/from their account(s).

5
Definition & Acronyms

Definitions

ATM

An Automated Teller Machine (ATM) is the physical machine that offers in cash withdrawal,
cash deposit, fund transfer and balance inquiry.

IDLE

A state of ATMs where the system is "On" but not servicing any user. In this state, ATMS is
waiting for the insertion of an ATM card to initiate a user session.

Operator

A bank personnel responsible for physical maintenance activities on the ATM, including but not
limited to starting up and shutting down ATM, refilling the cash dispenser in ATM and removing
cheque envelopes from the ATM.

Transaction

A transaction is a task performed using ATM by a user, including a Cash Withdrawal, Cash
Deposit, Fund Transfer and Balance Inquiry.

User

A user is a bank customer who holds an ATM card and is accessing the ATM.

6
Acronyms

SDS

System Design Specifications

SRS

System Requirement Specifications

ADA

Americans with Disability Act

ATM

Automated Teller Machine

ATMS

Automated Teller Machine System

IEEE

Institute of Electrical and Electronics Engineers

I/O

Input or output

7
GUI

Graphical User Interface

OOAD

Object-Oriented Analysis and Design

PIN

Personal Identification Number

RGB

Red Green Blue (Colour model)

Overview

This document consists of 3 sections:

Section 1 contains the purpose, scope, intended audience. product definitions & acronyms

Section 2 contains the system considerations, including assumptions and constraints,

Section 3 contains system architecture of ATMS to be implemented.

Appendix A contains sequence diagrams of ATMS

Appendix B contains data flow diagram of ATMS

Appendix C contains communication diagrams of ATMS

8
 System Consideration

Assumptions and Dependencies

The assumptions and dependencies of ATMS are as follows:

Related Software and Hardware

ATMS is embedded software on an ATM machine which only works on ATM machine with a
dedicated LAN cable for internet connection. The ATM machine internet connection also shares
the same access with the attached CCTV camera for the bank to surveillance the ATM area.

End user Characteristic

There are mainly two roles targeted for ATMS, the following table describes the expected level
of knowledge and access for each role.

Role Description Required Knowledge Required Access

Bank Operator Bank worker who Basic knowledge on Special Bank
performs maintenance ATM maintenance access card, ATM
activities on ATM skills, refilling ATM machine keys
Machine cash dispenser,
extracting cash
envelopes from ATM.
Bank Security Bank worker who Basic knowledge on Username &
Surveillance performs surveillance CCTV camera access password access
activities from the through IP address of
CCTV camera attached the camera on modern
to the ATM machine browser like Google
Chrome
User General individual who Basic knowledge on Bank access card
uses the ATM bank transaction,
including cash
withdrawal, cash
deposit, bank transfer
& balance enquiry

Table 1.0 Intended Users, required knowledge and required Access

9
General Constraints
ATMS is built as a Java application and can only run on environment that enables Java. Can only
perform a transaction while having an active connection with the bank transaction server. The
money inside the bank should be sufficient for user to dispense money. Security of the ATM
machine also need to be very secured from external hack or misuses.

Goals and Guidelines

The major goal for the ATMS is to provide the required services to end users in a design similar
to the ATM currently in-use by the industry. This is to avoid confusion to users due to total
unfamiliarity. Apart from that, the system must be secured from being hacked or misused. If in
case any malicious activities have been identified through the system or by camera surveillance,
the alarm attached on the ATM machine will rang and automatically call the local authorities.

Development Methods
The Object-Oriented Analysis and Design (OOAD) was identified as the most desirable
approach and therefore adopted for the system design. The process method is as follow:

1. Analyzing requirement
2. UML design (Use Case Diagram)
3. Analyzing the classes that will be needed for implementation
4. Designing the class diagram, sequence diagram and state charts.
5. Detailed design and implementation
6. Testing
7. Maintenance

10
 System Architecture and Strategies

System Architecture
The architecture used for ATM consists of two layers of classes. The "top-level" classes are
ATMMain and ATMApp. Both classes allow the system to be run as an application. 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 sequence diagram for Session (Figure17.0) is attached in Appendix A. For
data flow of ATMS, refer to Figure 19.0 in Appendix B

The sub package transaction contains the classes used to represent individual transactions that a
customer initiate. The class Session depends on the transaction package because it creates
individual transaction objects. These depend on the ATM to interact with the customer.

The sub package physical contains the classes that represent the various physical components of
the ATM. The class ATM makes use of these components, and Session and the various kinds of
transaction gain access to them through ATM to perform the needed operations. The general
sequence diagram for Transaction (Figure 18.0) is attached in Appendix A.

11
 Figure 1.0 ATM System Architecture

Subsystem Architecture
This section illustrates the components within each subsystem of ATM using component
diagrams.

The subsystem of ATM is listed in the table below (Table 2.0), along with their tasks:

Component Tasks
OperatorPanel -Inform ATM of changes to state of switch
-Allow operator to specify amount of initial cash

ATM - Start up when switch is turn on by operator.

-Shut down when switch is turned off by operator.
-Start a new session when card is inserted by customer.
-Provide access to component parts for sessions and transactions.

12
 CashDispenser - Keep track of cash on hand, starting with initial amount.
-Report whether enough cash is available.
-Cash Dispenser

CustomerConsole -Display a message.

-Display a prompt, accept a PIN from keyboard.
-Display a prompt and menu, accept a choice from keyboard.
-Display a prompt, accept a dollar amount from keyboard.
-Respond to cancel key being passed by customer.

CardReader -Inform ATM when card is inserted.

-Read information from card.
-Eject card.
-Retain card

Log -Log storage account information of customer.

-Log dispensing of cash.
-Log receiving an envelope.

Receipt -Represent information to be printed on a receipt.

ReceiptPrinter -Print receipt.

EnvelopeAcceptor -Accept envelope from customer, report if time out or cancelled.

Table 2.0: ATM Subsystems

13
Start Up (Component Diagram)
The sequence in which the components function can be found in the sequence diagram (Figure
15.0) located in Appendix A.

Figure 2.0 Component Diagram – Start Up

Shutdown (Component Diagram)

The sequence diagram in which the components function can be found in the sequence diagram
(Figure 16.0) located in Appendix A.

Figure 3.0 Component Diagram – Shut Down

14
Withdrawal (Component Diagram)
The communication between the component can be found in the communication diagram (Figure
20.0) located in Appendix C.

Figure 4.0 Component Diagram – Withdrawal

Deposit (Component Diagram)

The communication between the component can be found in the communication diagram (figure
21.0) located in Appendix C.

Figure 5.0 Component Diagram – Cash Deposit

15
Transfer (Component Diagram)
The communication between the component can be found in the communication diagram (figure
22.0) located in Appendix C.

Figure 6.0 Component Diagram – Transfer

Balance Inquiry (Component Diagram)

The communication between the component can be found in the communication diagram (figure
23.0) located in Appendix C.

16
 Figure 7 Component Diagram – Balance Inquiry

System States
This section explains the states of each features.

Start Up (State Diagram)

Figure 8.0 State Diagram – System Start Up

S1: In “Off” state, the ATM screen displays the messages “Not available”.

S2: After turning it on, the system enters the “idle” state where it displays the messages “Please
insert the card”. In “idle” state, the system can start a session when a user inserts a card.

17
Shutdown (State Diagram)

Figure 9.0 State Diagram – Shut Down

S1: In “Idle” State, the operator can turn off the system for maintenance activities, leaving it in
“Off” state.

S2: In “Off” state, the ATM screen displays the message “Not Available”.

18
Session Verification (State Diagram)

Figure 10.0 State Diagram – Session Verification

S1: During the start of a session, the system reads the card inserted and verifies the validity of
the card. In case it is unreadable, the card is ejected, ending the session (S5).

S2: Otherwise, the system proceeds to read the PIN entered by the customer. This stage can be
cancelled by customer by pressing the "Cancel" button, resulting in ejection of the card (S5).

19
S3: When the PIN is received, the system displays a list of transaction that the customer can
perform. This stage can be cancelled by customer by pressing the "Cancel" button, resulting
ejection of the card (S5).

S4: After performing a transaction, user can perform another transaction or ends the session.

20
Withdrawal (State Diagram)

Figure 11.0 State Diagram – Withdrawal

21
S1: User chooses "Withdrawal" as Transaction Type at this state to proceed with withdrawal
(S2).

S2: User chooses the Account Type to withdraw from. System will return to this state as long as
the account type chosen is invalid. Alternatively, user can cancel transaction, returning to
Transaction Menu (S1).

S3: User chooses the amount to withdraw. System will return to this state as long as the input for
amount is invalid. Alternatively, user can cancel transaction, returning to Transaction Menu (S1).

S4: Then, system checks for the balance in account. If balance is sufficient, system proceeds to
dispensing cash and print receipt (S5). If balance is insufficient, system proceeds to ask if user
wants to continue the session (S6).

S5: User can choose to continue to perform another transaction, where system proceeds to
Transaction Menu (S1). Otherwise, system will eject card (S7).

S6: User can choose to continue to perform another transaction after a failed transaction, where
system proceeds to Transaction Menu (S1). Otherwise, system will eject card (S7).

S7: System terminates session and ejects card.

22
Deposit (State Diagram)

Figure 12.0 State Diagram – Deposit

23
S1: User chooses “Deposit” as Transaction Type at this state to proceed with deposit (S2).

S2: User chooses the Account Type to deposit. System will return to this state as long as the
account type chosen is invalid. Alternatively, user may choose to cancel transaction system
asking if user wants to perform another transaction (S6)

S3: User inputs the amount to deposit. If amount is invalid, system will ask it user wants to
perform another transaction. Alternatively, user may choose to cancel transaction, resulting in
system asking if user wants to perform another transaction (S6).

54: User inserts the cash envelope. Alternatively, user may choose to cancel transaction,
resulting in system asking if user wants to perform another transaction (S6).

S5: System prints receipt. Then, system asks if user wants to perform another transaction.

S6: User can choose to continue to perform another transaction, where system proceeds to
Transaction Menu (S1). Otherwise, system will eject card (S7).

S7: System terminates session and ejects card.

24
Transfer (State Diagram)

Figure 13.0 State Diagram – Transfer

25
S1: In this state the system ask user what type of transaction does the user want to do, Withdraw,
Transfer, Balance Enquiry & Deposit. If Cancel button is pressed, the system will directly go to
S6.

S2: After choosing Transfer in S1, the user will be required to enter account type to transfer from
and if the input is valid user will be directed to S3. Upon invalid input, the system will continue
to display the same screen which required user to enter account type to transfer from. If Cancel
button is pressed, the system will directly go to S5.

S3: After entering valid account to transfer from the user will be required to enter account type to
transfer to and if the input is valid user will be directed to S4. Upon invalid input, the system will
continue to display the same screen which required user to enter account type to transfer to. If
Cancel button is pressed, the system will directly go to S5.

S4: After entering valid account to transfer to the user will be required to enter amount to
transfer and if the input is valid user will be directed to S5. Upon invalid input or if Cancel
button is pressed, the system will directly go to S5.

S5: This state will ask user whether user want to perform another transaction or not. Upon
invalid input, the system will continue to display the same screen which will ask user whether
user want to perform another transaction or not. If user wants to perform another transaction the
system will lead user back to S1. Else, system will go to S6.

S6: At this state, user session is cancelled and user card is ejected.

26
Balance Inquiry (State Diagram)

Figure 14.0 State Diagram – Balance Inquiry

S1: User chooses "Fund Transfer" as Transaction Type at this state to proceed with withdrawal
(S2). Alternatively, user can press "Cancel", resulting in system ejecting card (S4).

S2: User chooses the Account Type to inquire. If account is invalid, system will stay in this state,
requesting user to re-enter account. Alternatively, user can cancel transaction, resulting in system
asking if user wants to perform another transaction (S3).

S3: System asks if user wants to perform another transaction. If user chooses "Yes", system will
display Transaction Menu (S1). If user chooses "No", system will terminate session and ejects
card (S4).

27
 Appendix
Sequence Diagram
The sequence diagram of components in ATM are shown below.

A.1 Start Up

A.2 Shut Down

A.3 Session Verification

A.4 Transaction (General)

Data Flow Diagram

The data flow diagram of components in ATM is shown below:

Communication Diagram
The communication diagram of components in ATM are illustrated.

28
C.1 Withdrawal

29
C.2 Cash Deposit

30
C.3 Transfer

31
C.4 Balance Inquiry

32