See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/281464572

Advance Requirement & Software Engineering

Research · September 2015

DOI: 10.13140/RG.2.1.5053.8727

CITATIONS READS

0 716

1 author:

Nasreen Ahmad
De Montfort University
17 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Nasreen Ahmad on 04 September 2015.

The user has requested enhancement of the downloaded file.

 Advance Requirement & Software Engineering
Nasreen Iqbal
Msc. Software Engineering
P13194231@myemail.dmu.ac.uk
De Montfort University

1. REQUIREMENT SPECIFICATION & TEMPLATE

This section covered requirement number 1 & 2 for the task 1.
1.1. Introduction
An analyst who understands the requirement and has the ability to use the tools, that represents the quality slandered
in the requirement. “The system shall” is the phrase clearly specified in the requirement that referred the IEEE
recommended practice 830.
Automated Teller Machine that highly complicated in the implementation, required recommended slandered
supportive provisions to cover all the minor or major requirements. The functional and non-functional requirements
for the ATM simulation system will discuss in the following recommended framed template.
1.1.1. Purpose
This document describes the software requirements for a simulation Automated Teller Machine. It is intended
for the developer, designer, stockholder and maintainer of the ATM System.
1.1.2. Scope
The functional and nonfunctional specification of the ATM is to support a computerized banking system to cover
its basic requirements.
1.1.3. Out of Scope
 Software to communicate between ATM and bank, is not part of the requirement
 The bank will integrate with the ATM Hardware but later.
 The Hardware not been yet developed.
1.1.4. Definitions
Account
A single account in a bank against the transactions can be applied, with at least checking and savings.
ATM
A terminal that allows customers to enter their own transactions using account number as identification. The
ATM interacts with the customer to gather transaction information and forward to the Bank database for
validation and dispenses cash to the customer. We assume that an ATM will operate all validations and
processing independently because bank trusted and authorized.
Bank
A financial services group that holding customer accounts and authorizing access to accounts over the ATM
machine.
Account Number
A unique number assigned to a bank customer that authorizing access to accounts using an ATM machine.
Customer
Customer is the holder of one or more accounts in a bank. One customer holding an account at a different bank is
considered a different customer in each bank.
Transaction
Process a transaction request for operation from the customer. We have only specified that ATM must dispense
cash or accepting envelopes.
Operator
It should be easy to maintain the whole system. The maintainer will only bank authorized person, who allowed
for the ATM dispenser refilling, removal of envelop and shut down and restart the ATM.

1 | Page
 1.1.5. Abbreviations
Throughout this document the following abbreviations are used.
 k is the maximum withdrawal per day and account.
 m is the maximum withdrawal per transaction
 n is the minimum cash in the ATM to permit a transaction
 t is the total fund in the ATM at start of day
1.2. Overview
This section does not state specific requirements. Instead, it provides a background for requirements. This section
usually consists of six subsections, as follows:
1.2.1. Product Perspective
The bank will communicate with the bank computer over an appropriate communication link in the latest stage
with the integration of bank software (Not included in the requirement)
1.2.2. Product functions
The purpose of the ATM software must support computerized banking database to maintain their accounts and
process transactions. ATM communicates with the bank database, interacts with the user to carry out the
transaction dispenses cash. All these activities considered using logical database without caring its physical
location.
1.2.3. Key Stakeholders
 Customer
 Operator
 Bank
 ATM
1.2.4. Constraints
This section will provide a general description of items that limits the developer‟s options.
 The bank will communicate with the ATM through the appropriate communication link.
 The software should encapsulate the functionality of the hardware devices within software components.
 The ATM hardware is not developed.
 The ATM must interact with the banks database.
1.2.5. Assumptions and dependencies
. The assumptions and dependencies represent the risk.
 The bank will integrate the software with the ATM‟s hardware at a later time.
 Bank trusts the ATM to access the information in the database without security measures.
 ATM Hardware will available at the time of installation.
 Develop a simulation first version.
 Absence of bank database connection.
1.2.6. MoSCow Criteria / Requirements Prioritisation
The requirements will be prioritized which divides the requirements into the following four categories:
Priority Ranking Description
M – Must Have Describes a requirement that must be satisfied with the final solution to be
considered a success.
S – Should Have Describes a high-priority item that should be included in the solution if it is
possible. This is often a critical requirement but can be satisfied in other
ways if required.
C – Could Have A requirement which is considered desirable but not necessary. This will be
included when time and resources permit.
W – Won’t Have Represents a requirement that stakeholders have agreed but will not be
implemented in a given release, may consider for the future.

2 | Page
 1.2.7. Intended Audience and Document Overview
The intended audience of this document is a developer‟s group or system administrators who would use the
library to control ATM system.
1.3. Specific Requirements
The specific requirement focused mainly on functional requirements of ATM and bank system.
1.3.1. External Interface Requirement
1.3.1.1. User interfaces
The interface of the ATM must represent the ergonomic requirements. We can distinguish this section with
the hardware interface, software interface and communication interfaces, but currently we have no hardware
and no communication software from the bank, we are running software on the PC therefore only the user
interfaces needed. The followings are the possible interface to the ATM.
 Screen that display Messages
 Withdrawal screen
 Deposit Screen
 Operator screen
1.3.1.2. Hardware interfaces
Not Applicable
1.3.1.3. Software interfaces
Not Applicable
1.3.1.4. Communications interfaces
Not Applicable.
1.3.2. Functional Requirement
The functional requirements are organized in two sections: First requirements of the ATM and second
requirements of the bank. Please note there are some requirements not specified in the coursework, but we tried
to target because of quality system development.
1.3.2.1. Requirements of the ATM
The requirements for the automated teller machine are organized in the following way. General
requirements, requirements for authorization, requirements of the bank database and function requirement.
1.3.2.1.1. General
Functional FR01
Requirement ID
Priority M
Requirement Initialize parameters t,k,m,n
Description
Input ATM is initialized with t Pounds. K,m,n are entered.
Processing Loading the parameters
Output Parameters are set.

Functional FR02
Requirement ID
Priority S
Requirement ATM should display Welcome Screen.
Description

Functional FR03
Requirement ID

3 | Page
 Priority S
Requirement If the ATM is running out of money.
Description
Output Display an error message and No Welcome Screen display

1.3.2.1.2. Authorization:
The authorization starts after a customer has entered his card in the ATM.
Functional FR04
Requirement ID
Priority M
Requirement Screen displays Main message and prompt to enter 5 digit account number.
Description
Input Customer enter 5 digit account number
Processing The ATM verifies the account number with the bank database.
Output ATM Accept or reject authorization after verification from the bank
database

Functional FR05
Requirement ID
Priority S
Requirement If the Account number is valid, then ATM should prompt the PIN number.
Description
Input Enter 5 digits PIN Number
Processing ATM do PIN verified with the bank database.
Output Authentication accept or reject

Functional FR06
Requirement ID
Priority S
Requirement The Account number should be logged for record tracing.
Description
Input Account number entered by the user
Processing Log the number in the log-file, stored in the system
Output Update the log file.

Functional FR07
Requirement ID
Priority M
Requirement Different negative answers from an ATM while doing an authorized activity
Description from the bank computer for authorization dialog.
Input Response from bank database or authorization dialog:
Bad account number: if the account number was wrong.
Bad PIN Number: if the PIN number was wrong.
Processing ATM gets any of these errors from the bank database; the user will get the

4 | Page
 appropriate message.
Output Message display and return to main menu (FR02).

Functional FR08
Requirement ID
Priority S
Requirement If Account number and PIN number is ok, then authorization process is
Description finished.
Input The ATM gets acceptance from the bank database for the authorization
process.
Processing Finishing authorization
Output Start a transaction dialog. Screen display main menu (FR10)

Functional FR09
Requirement ID
Priority C
Requirement If the account number or PIN Number entered more than 3 times and each
Description time both the numbers are invalidated. A message will be displayed that the
customer should call the bank.
Input Entering a wrong Account / PIN number more than 3 times in a session.
Processing Verified and check the counter (infinite loop used here)
Output Display error message that „the customer should call the bank‟.

1.3.2.1.3. Functions
These are the requirements for the different functions the ATM should provide after authorization.
Functional FR10
Requirement ID
Priority M
Requirement After Authentication, ATM will display the main menu contained 4 options
Description
Input Authorization successfully completed. An ATM display withdrawal menu
containing the withdrawal amount
1- View balance
2- Withdraw cash
3- Deposit fund
4- Exit
Processing ATM will process transactions from the following above options, exit if
customer chooses 4.

Functional FR11
Requirement ID
Priority M
Requirement The kind of transactions the ATM offers is: Withdrawal.
Description

5 | Page
Input Authorization successfully completed. An ATM display withdrawal menu
containing the withdrawal amount
20 (Option 1), 40 (Option 2), 60 (Option 3), 100 (Option 4), 200 (Option 5),
6 (Cancel)
Processing ATM will begin transaction process or cancel the session
Output Transaction accepted or rejected based on selection.

Functional FR12
Requirement ID
Priority M
Requirement The kind of transactions the ATM offers is: Deposit.
Description
Input Authorization successfully completed. Screen prompts to type deposit
amount
Type 0 – Cancel
The user must enter the number of pens, no decimal accepted
Processing Start Deposit processed, or the user chooses Exit typing 0
Output ATM Ask for the envelop or display welcome menu (FR02)

1.3.2.1.4. Withdrawal Function

The withdrawal requirement is based on the Simulated ATM system; there will be no physical
interaction with the cash dispenser. The function will ask user to collect money and user will press ok
to complete the transaction.
Functional FR13
Requirement ID
Priority M
Requirement The kind of transactions the ATM offers is: Withdrawal.
Description
Input Authorization successfully completed. Customer inputs a menu (FR10)
selection using Keypad.
Processing The withdrawal amount entered is greater than the user‟s account balance
Output ATM Display message stating problem and the system prompt to enter
smaller amount. System Return to withdrawal menu (FR10)

Functional FR14
Requirement ID
Priority C
Requirement Customer selected Cancel option from the withdrawal menu.
Description
Input Customer selected 6 as cancel from the withdrawal menu (FR10)
Processing ATM terminates the withdrawal menu.
Output The System display Thank you message and returned to Welcome Screen
(FR02)

Functional FR15
Requirement ID

6 | Page
 Priority M
Requirement The kind of transactions the ATM offers is: Withdrawal.
Description
Input The customer selects a choice from the menu (FR10) for the withdrawal
Processing Selected withdrawal amount is less than or equal to the user‟s account
balance
Output The system accepted transaction and begin process to check the cash
dispense for the selected amount.

Functional FR16
Requirement ID
Priority M
Requirement Dispense slot contained greater than the selecting withdrawal amount.
Description

Processing ATM debit withdrawal amount from the users‟ account from the bank
database.
Output The Cash Dispenser dispensed the desired amount, Display message,
reminding user to collect amounts from the Cash Dispenser.

Functional FR17
Requirement ID
Priority M
Requirement Cash Dispense contained not enough value.
Description
Processing The system checks the cash dispenser for the available balance and prompts
to select lesser amount.
Output A message displays indicating the problem and prompt to select, the less
amount; System return to the withdrawal menu (FR10).

Functional FR18
Requirement ID
Priority C
Requirement If the money is dispensed, the amount is logged.
Description
Input The number of 20£ bills requested is dispensed to the customer.
Processing Entered the details against the account number in the log.txt file stored in the
system.
Output Details logged along with the account number, the response sent to the bank.

1.3.2.1.5. Deposit Function

The Deposit slot here texture as a real ATM process, in the real hardware the slot might send the
signal to ATM indicating that envelope deposited, the ATM, then sends messages to the bank
indicating that envelope deposited and the bank will credit the amount, to simulate this operation into
the ATM, included deposit slot in the development. If the customer fails to deposit the envelope
within the timeout period, or presses cancel instead, the deposit will not be credited to the customer.
Functional FR19
Requirement ID

7 | Page
Priority C
Requirement The kind of transactions the ATM offers is: Deposit.
Description
Input Authorization successfully completed. Customer Entered the amount to
deposit
Processing Verified entered amount, System rejected the real number
Output The Message appeared to remember that “Enter amount in pens only”, return
to FR13 and wait

Functional FR20
Requirement ID
Priority M
Requirement The kind of transactions the ATM offers is: Deposit.
Description
Input Customer entered amount in the pens to deposit
Processing Verified the entered amount value, the system calculates the amount divided
by 100 to obtain a number representing pound (e.g. 125/100=1.25)
Output The screen displayed a message to the user to insert a deposit envelope into
the deposit slot.

Functional FR21
Requirement ID
Priority M
Requirement Deposit Slot Receive the Envelop
Description
Input Prompt to insert Envelop into deposit slot
Processing If the envelope received within 2 minutes, then ATM credited the deposited
amount to the user‟s account.
Output The screen displays a Thank You Message, return to the main menu and
wait for additional transaction or choose exit.

Functional FR22
Requirement ID
Priority M
Requirement Deposit Slot Not Receive the Envelop in the specific period of time.
Description
Input Customer not insert Envelop into the deposit slot
Processing ATM waits for 2 minutes, deposit slot not received envelop.
Output The screen displays a message that the system has cancelled the transaction,
display main menu (FR10) and wait for user input.

Functional FR23
Requirement ID
Priority S
Requirement The Customer chooses to cancel
Description

8 | Page
 Input Customer Entered 0 (Zero) to exit.
Processing ATM cancels the transaction
Output The screen return to main menu (FR02)

1.3.2.1.6. View Balance

Functional FR24
Requirement ID
Priority M
Requirement Process balance inquiry
Description
Input Entered view balance option from the main menu FR10
Processing ATM retrieves balance from the bank account
Output The screen displays the user‟s account balance, return to the main menu
(FR10) and wait for another input.

1.3.3. Requirements of the Bank Database for the ATM

1.3.3.1. Authorization:
The bank gets a request from the ATM to verify an account. If the bank database determines that the
customer's account number / PIN is invalid, the customer will be required to re-enter the details. The bank
will check If the customer is unable to successfully enter the account number / PIN after three tries, the bank
will send a message to the customer stated to contact the bank.
Functional FR25
Requirement ID
Priority S
Requirement If it is not a valid bank Account number, the ATM will send a message to
Description the Customer
Input Invalid bank Account number.
Processing The ATM, check from the bank database, if the bank account is invalid. A
bank account is valid if the account number available in the database.
Output The ATM displays the message “Invalid Bank Account”

Functional FR26
Requirement ID
Priority S
Requirement The ATM, checks the bank database if the PIN invalid.
Description
Input Invalid PIN
Processing The ATM, check from the bank database, if the PIN is invalid. A PIN is
invalid if the PIN number (hexadecimal) doesn't match in the database.
Output Invalid PIN.

Functional FR27
Requirement ID
Priority S
Requirement The ATM will check the bank database if the PIN valid.

9 | Page
 Description
Input Valid PIN
Processing The ATM, check from the bank database, if the PIN is valid. A PIN is valid
if the PIN number (hexadecimal) matches in the database.
Output Valid PIN Number.

Functional FR28
Requirement ID
Priority M
Requirement ATM counts the number of wrong PIN and Account entries
Description
Input Repeatedly invalid PIN / Account number entered

Processing Update count for invalid PIN / Account number for the account. If it reached
the maximum limit then ATM must cancel the transaction.
Output The ATM Display the message “Invalid PIN/ account number attempt”,
return to main menu (FR02)

Functional FR29
Requirement ID
Priority S
Requirement If it is a valid Account and a valid PIN but there are problems with the
Description account.
Input Valid Account Number and PIN
Processing The problem occurred in the system, ATM will send a problem message
Output The ATM Display error message and return to welcome screen

Functional FR30
Requirement ID
Priority S
Requirement If it is a valid Account number, a valid PIN and there are no problems with
Description the account
Input Valid Account/ PIN number.
Processing Process Message
Output ATM receives “Account ok” from the database
1.3.3.2. Transaction:
The ATM will communicate with the bank in each transaction and obtain verification. The transaction will
be considered complete by the bank once it has been approved. If a transaction fails for any other reason
rather than an invalid PIN or invalid account number, the ATM will display a description of the problem,
and prompt to do another transaction.
Functional FR31
Requirement ID
Priority M
Requirement After a request the ATM computer processes the transaction
Description

10 | P a g e
Input Request to process a transaction on an account and amount „m‟ to withdraw.
Processing Process a transaction. Update k parameter for a month
Output If transaction succeeded, the ATM displays the message “Transaction
Succeeded”. If not, it will display “Transaction Failed”.

Functional FR32
Requirement ID
Priority M
Requirement Update account after the money is dispensed
Description
Input The response from ATM about money dispensed, deduction from the t
parameter
Processing Updates account by the ATM in the bank database
Output New account record

Functional FR33
Requirement ID
Priority S
Requirement ATM dispenser has a limit „k‟ for each account.
Description
Input Request to process the transaction
Processing Check if the amount of money doesn‟t exceed k parameter
Output If the amount exceeds the limit the transaction will fail and display the
message, return to main menu.

Functional FR34
Requirement ID
Priority S
Requirement If the deposit slot received the envelope, actually user will press OK
Description button to accept.
Input Deposit slot
Processing ATM manipulates with the bank database
Output The ATM credits the deposit amount to the user‟s account balance.

Functional FR35
Requirement ID
Priority M
Requirement If Successfully Execute the Transaction.
Description
Input Transaction Completed
Processing Check transaction over
Output The system will return to the main menu and wait for another transaction.

Functional FR36

11 | P a g e
 Requirement ID
Priority W
Requirement If the transaction has encountered with k, m, n constraints abbreviation
Description
Input The transaction starts
Processing ATM, check abbreviations with k, m, n and invalidate any of them
Output Display error message, return to the main menu.

1.3.3.3. Session:
Functional FR37
Requirement ID
Priority M
Requirement The ATM session begins
Description
Input Customer Input the identity
Processing The authentication verified by the bank database and executing the
transaction.
Output The system will wait for user input using the main menu.

Functional FR38
Requirement ID
Priority S
Requirement ATM session Ended or Cancelled by the user
Description
Input Customer Inputs selection or choose exit.
Processing The Session completed its transaction or terminated by the user exit
selection or other termination occurred, logged the account number in the
log file.
Output „Thank You‟ message display and return to the main menu (FR02)

1.3.4. Bank Operation panel activity

The ATM will have operated switch that will allow authorized operator to start and stop the servicing of
customers by turning OFF/ON ATM. The operator will be required to remove envelops from the slot and enter
the total cash on hand while ATM turned OFF, which in turn not servicing a customer. The Operator required to
verify and confirm when the machine turned ON.
The Operator is presuming that no physical interaction yet, the simulation only shuts down and start up the PC.
Functional FR39
Requirement ID
Priority M
Requirement ATM Operator Panel turns off
Description
Input The switch Off of the ATM system by the operator.
Processing The ATM system shutdown.
Output The Operator removes envelops from the deposit slot and refill the cash
dispenser. (Simulate)

12 | P a g e
 Functional FR40
Requirement ID
Priority M
Requirement ATM Operator Panel turn On
Description
Input The Switch On by the operator.
Processing The Operator verified filled dispenser and deposit slot and confirmed before
ATM Switch-On.
Output The ATM System-Up and initialized parameters, display “Welcome
Screen”, ready to use.

1.3.5. Non Functional requirement

The non-functional quality requirements are little tricks to gather, it included interface requirement,
maintenance, time, reliability, survivability, security and operating requirement. In simulation do not much non-
functional activity recorded, but few are very important as per check list.
1.3.5.1. Performance requirements
Functional FR41
Requirement ID
Priority M
Requirement The error message should display at least few second.
Description

Functional FR42
Requirement ID
Priority M
Requirement If there is no response from the user within 2 minutes the transaction cancel
Description and return to main menu.

Functional FR43
Requirement ID
Priority M
Requirement The ATM dispenses money if and only if the withdrawal from the account is
Description processed and verified by the bank database.

Functional FR44
Requirement ID
Priority M
Requirement Cash dispensed shall not exceed £500/- and Cash deposit limit (i.e. £2000/-
Description limit)

Functional FR45
Requirement ID
Priority M
Requirement The ATM interface should be user friendly. Easy to expand and easily
Description repaired

13 | P a g e
1.3.6. Attributes
The attributes included to synchronize the process.
1.3.6.1. Safety and Security Requirements
The ATM network should provide maximal security. In order to make that much more transparent there are
the following requirements. This security check will come later on.
1.3.6.2. Availability
The ATM network has to be available 24 hours (check later on)
1.3.6.3. Maintainability
Only maintainers are allowed to Switch On and OFF for the ATM machine, operated by bank staff only.
The ATM will maintain an internal log of transactions to resolve ambiguities arising from a failure in the
middle of a transaction. All entries will be made in the log when the ATM is started up and shut down, all
messages will sent to the Bank in each transaction along with the dispensing of cash, and for the receiving of
an envelope. Log entries may contain account number and amount in pounds, but do remember the PIN
number never logged for security reason.
1.3.7. Other Requirements
1.3.7.1. Data Base
ATM must be able to use several data formats according to the data provided by the databases. As we
assume the bank data as logical database and location doesn‟t consider, therefore we recommended the data
file for the data manipulation. This will occupy small space in the system and easy to access using ODBC
connection.

14 | P a g e
References
IEEE Std 830-1998 Recommended Practice for Software Requirements Specifications.
IEEE Std 1002-1987 (Reaff 1992), IEEE Standard Taxonomy for Software Engineering Standards.
IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions.
„The Art of Requirements Triage‟, Alan Davis, IEEE computer, March 2003
Software Requirements. Karl E. Wieger. Windows Press

15 | P a g e
2. USE CASES
UML Use Case Diagrams can be used to describe the functionality of a system, usually referred as behavior diagrams
used to describe a set of actions. This session designed the ATM system, including withdrawal, deposit, authenticated
user, etc. The UML Model attached to the complete conceptual view. All attached Diagrams can be viewed in the
Appendix A at the end of the report.

2.1. ATM System:

Represent the overall functionalities of a system in general. ATM System Use Case designed to perform the visual
effect of the requirement. The requirement described as:
1. Screen display menu
2. User required to enter a selection
3. Session begins
4. Authentication checks from the bank
5. The transaction starts or cancel
6. The operator performs the ATM operation
7. Wait for the next transaction
2.2. User Authentication System:
The system begins with the user authentication process.
1. Screen display Welcome message and prompt to enter the account number
2. User input 5 digit account number
3. Prompt to enter a PIN
4. User input PIN number in 5 digests.
5. ATM authenticates the user with the bank database.
6. If authenticated, then main menu display for selection.
7. If not authenticated, then error message display and return to step one for the re - authentication process.
2.3. ATM Session:
The session begins with the user verification.
1. Display Menu
2. Customer Input PIN / Account number
3. The session begins
4. Verified inputs from the bank database
5. If verification success, then transaction begins
6. Session completed.
7. If verification unauthorized then session cancels and ATM display menu

2.4. ATM Transaction:

The Transaction fulfills the following requirement in the Use Case diagram.
1. User Inputs using selection
2. The transaction begins by user authentication from the bank database.
3. If verified ok then the transaction completed its process.
4. If authentication not verified then transaction cancel by ATM and display message.
5. The user may cancel the transaction anytime, the ATM will display Thank you message.
6. Log Updated
2.5. Withdrawal System:
ATM withdrawal Use case designed, based on requirements, as stated, that cash dispenser has no physical
intervention but simulate.
1. Display Menu
2. The customer enters the Account / PIN number
3. User authenticated checked by the bank
4. Session created
5. Customer Enter Amount
6. Verified Amount from the bank
7. If amount > available balance, then ATM display menu to enter less amount
8. If amount<= available balance, then ATM, checks cash dispenser
9. If cash dispenser <= amount then ATM debit amount from the bank account
10. The amount dispensed by the ATM and send message to the customer
11. Session completed

16 | P a g e
 12. If the cash dispenser has > amount display message and ask to deposit less amount.
13. The user can cancel any time transaction, the session will terminate immediately.
14. Log updated
15. Section completed

2.6. Deposit System:

Deposit Use case follows the following requirements. The deposit slot has been nothing, just an operational but
assuming.
1. Display Menu
2. The customer enters the Account / PIN number
3. Session created
4. User authenticated checked by the bank
5. Customer Enter Amount
6. Execute calculation in real number (125/100=1.25)
7. ATM asks to insert envelop
8. ATM, wait 2 minutes, if envelope received, then ATM, credit amount in bank data
9. If not received within the Pacific Time than ATM, cancel the transaction and display message and wait for
user input.
10. User cancels the transaction anytime, the session terminated immediately.
11. Log updated
12. Section completed

2.7. Display Balance functionality:

Display Balance Use case follows the following requirements
1. Display Menu
2. The customer enters the Account / PIN number
3. Session created
4. User authenticated checked by the bank
5. User Input amount
6. User Authenticate process
7. If approved authentication, then the transaction will approve
8. Balance retrieved from the bank database and display on screen
9. Log updated
10. Section completed

2.8. Operator Panel:

The operator panel Use case will follow the following requirements.
1. Operator shuts down the system
2. Operator Refill the dispenser and removed the envelope
3. Operator verify before restart the system
4. Restart the system

17 | P a g e
3. THE MODEL VIEW-CONTROL FRAMEWORK (MVC)
The MVC architecture separates presentation and interaction or communication of the system data. The MVC
Architecture is structured into three logical components that interact with each other. The MVC defined in the
following categories.
 The Model component manages the system data and associated operations on that data.
 The View component defines and manages how the data is presented to the user.
 The Controller component handles the user interface and manages user interaction, i.e. key presses and passes
these interactions to the model and view.
The MVC normally used for client and server architecture that include a user interface, considering that the MVC
used only when the future requirements for interaction and presentation of data are unidentified.

3.1. Benefits and Justification using MVC

MVC is simply a pattern that perfectly an ideal that exists in the back of the mind when designing classes.
Mostly it works to avoid mixing code from the three categories into one class. The following below are
categories best describes its advantage.
3.1.1. Supports multiple views
MVC separated view from the model and leaving no direct dependency from the model to the view, same data
has multiple views at the same time. In the ATM simulation the different interfaces display the same data from
the shared model, but show it in a different way.
3.1.2. Accommodates change
The user interface requirements have a tendency to change more quickly than business rules. The most inspiring
benefit of this type of development, it‟s granting that adding new types of views to the system generally does not
affect the model because the model does not depend on the views. As a result, the scope of change is confined to
the view. In this ATM project the changes are expected during the development process due to lack of hardware
and data communication.
3.1.3. Testing Considerations
The other strong reason is that, testability is greatly enhanced when deploying Model-View-Controller. The
component uses testing faces difficulty when they are highly dependent, especially when talking about the user
interface components. These types of components frequently require a complex setup just to test a simple
function and it is hard to separate the problem to a specific component. The ATM system requirement looking
for less interface testing with hazel free version.

18 | P a g e
3.1.4. Use of MVC in ATM System
In the ATM requirement the following important facts to be considered.
3.1.5. Model Object
The application maintained control information represented by the control. The ATM system using use-cases,
the control will examine the participating objects in use case descriptions. This phase will map interactions,
activity of the user to model components, i.e. classes, objects, operations, attributes, relationships. The below
objects will integrate with the Model.
 Operator
 Customer
 Bank database
 Cash
3.1.6. View Object
In this phase considered the system interface with the actor. The ATM work with the view objects which
represent a user interface component, that continue to the user level terms. Each actor interacts with at least one
view object in each use case. This each view object collects information from the actor and that information will
use by the model and control. The view objects will be as follows:
 Display
 Withdraw cash
 Deposit
 Messages
3.1.7. Control Object
This face will coordinate model and view objects with the reasons, because the ATM system related to the Use-
Case and have no physical counterpart in the real world. This phase will collect information from view objects
whenever the user entered data for dispatch to model objects. That will represent application control flows. The
followings are the control objects in the ATM simulation system.
 Operator Panel (“Operator Panel” use case)
 User verification controller (“User Authentication-UseCase” use case)
 Dispense controller (“Withdraw UseCase” use case)
 Deposition controller (“Deposit UseCase” use case)
 Balance view controller (“Balance Enquiry-UseCase” use case)
 Transaction view control („Transaction-UseCase‟)
 Session View Control („Session-UseCase)

19 | P a g e
 MVC (Model , View and Control) high level Design of the System

Operator
Panel ATM

Session

Customer
Console

Bank
Customer
Transaction

Cash
Dispenser

Log

Deposit Slot

Note: the example as above present in the Use-Case diagram concept.

3.1.8. Critical Analysis
The overall evaluation and justification says that the decision for the MVC framework will help in interfaces for
interaction between component and user, the other most important result focusing upon the cost reduction in the
testing phase because the MVC separates data in three components and that make sense to test these components
individually. As a result reduce the number of user interface test cases. The ATM modeling begins after the
MVC pattern design, which helps to stimulate the system and shorten the work and time.

20 | P a g e
4. SYSTEM ARCHITECTURE DESIGN
The Architecture designing, invokes the early stage of the system design process, which represents the link between
specification and design processes. Software architecture is a collection of components and connectors and these
components are the system's functional elements. The system architecture is a process in which desired functionality
is met by hardware and software components, these components are related to each other.
“The IEEE recommendation defines architecture as the fundamental organization of a system embodied in its
components, their relationships to each other and to the environment and the principles guiding its design and
evolution”
The IEEE Recommended practice for Software Architecture development defined as a conceptual framework
consists of collection of views using UML language for the documenting.
Critical analysis:
In this system the architecture doesn't exist as whole because the simulation would work only with the presentation
view using classes and their data and flow movements. The architecture consists of hardware and software
components with the connecters and in our simulation ATM system the hardware components and connectors are
missing. Therefore, this system will talk about the software component and its operation behaviors between the
classes along with the data flow. As we studied that the Architecture required physical and logical concepts along
with the client and server tiered architecture. This simulation wouldn‟t complete architecture features, therefore we
shall discuss the ATM model view design using classes and their communication behaviors through different UML
Diagrams.
3.2. Design Patterns
Software design depends on an architectural style that will provide the framework to meet a system's non-functional
methods. Design patterns define the implementation strategies of those architecture components and connectors. A
good architecture will make use of design patterns, but has a broader goal. The ATM is suggested with the Model
View Controller, as reasons discussed earlier. This system is represented as an interaction model using MVC.
3.2.1. Implementation Modelling and View of Architecture
3.2.1.1. UML Language of Architecture
UML is a language for visualizing, specifying, constructing, and documenting the artifacts of a software
system. UML is a graph that representing a common semantic language provides a comprehensive system
for the full life cycle. ATM modelling designed in UML because:
 To represent complete system
 Establish coupling between concepts and codes.
 Inheritance complex and critical system
 Create a modelling usable by both human and machine.
The UML defines nine graphical diagrams:
 Class diagram
 Use-case diagram
 Behavior diagram
o Interaction diagram
 Sequence diagram
 Collaboration diagram
o State chart diagram
o Activity diagram
 Implementation diagram
o Component diagram
o Deployment diagram
3.2.1.2. UML Class Model
The ATM class model will create the responsibilities and relationships of the classes expose the basic
structure of the class diagram. In this class structure designing we shall decide the class and their
relationship with the various possible concepts that build the complete class modelling of the ATM system.
3.2.1.3. Identifying the Classes
Nouns / Naming for the Classes
ATM Screen PIN

21 | P a g e
 User Keypad Bank database
bank amount account number

customer cash dispenser balance inquiry

account deposit slot Deposit
£20 bill / cash withdrawal
balance deposit envelope

 The classes of the given name or nouns that have a sense in the ATM system.
 ATM / Bank customer / Bank will use as the actor in the Use-Case diagram.
 The ACCOUNT NUMBER and PIN important attributes of a blank database. They don‟t exhibit
behavior. Therefore Model them as attributes of a BANK DATABASE class.
 Using an attribute of the class that models the CASH DISPENSER which represents the presence of
receipts and amount in the system.
 The BANK is not an ATM part that‟s why it does not need to model in the class.
 The AMOUN attributes of the classes are most suitable for the class modelling.
 The CUSTOMER represents entities outside of the system because they interact with our ATM system,
but we cannot consider modelling them as classes in the ATM software.
 Logically class model do not model "£20 bill" or "deposit envelope" as classes.
 We analyze that the simply acknowledging the receipt of a deposit envelope, an operation performed by
the class deposit slot is sufficient to represent the presence of an envelope in the system.
 The transaction behavior models the three types of transactions as individual classes.
 Withdrawal
 Balance inquiry
 Deposit
3.2.1.4. Candidate Classes
The structure class candidates have been finalized for the ATM class modelling. The transactions and
sessions are the behavior of the system that will hold the information of the customer activity. The following
classes will model the system.
 ATM
 Screen
 Keypad
 Cash Dispenser
 DepositSlot
 BankDatabase,
 BalanceInquiry
 Withdrawal
 Deposit
 Transaction
 Session
3.2.1.5. UML Composition Relationship
The composition has an additional property of dependency because an object of a subclass cannot exist
without linked to an object to the main class. The solid diamond lines attached to the class of ATM (below)
indicate that class ATM has a composition relationship with classes DepositSlot and Screen. The properties
are:
 The composition suggests a whole/part relationship.
 The Screen / DepositSlot class that has the solid diamond line at its end of the association line is the
whole to the ATM.
 In this way an object of class ATM is shaped from class Screen and DepositSlot. The physical
representation of the model has explained that an ATM "has a" screen and a deposit slot. The "has-a"
relationship defines composition diagram.

22 | P a g e
 Screen
DepositSlot 1

1
1 ATM
has-a
has-a
1

3.2.1.6. Class Operations in the ATM System

An operation is a service that provides the object of a class. In the below chart the classes and their verbs
regulate the operations of our ATM classes. The class model in the initial stage will decide and set the
operations for the system.
Class Verbs and verb phrases

BankDatabase Authenticates customer, retrieves an account balance, credits and debit an

account.
Screen Displays messages to the customer
Keypad Receives numeric input from the user
CashDispenser Dispenses cash and indicates whether it contains enough cash to satisfy a
withdrawal request.
DepositSlot Receives a deposit envelope

ATM Executes financial transactions

BalanceInquiry Retrieve balance from the customer account from the bank database.

Withdrawal Withdraw an amount in number of limits in a session, the customer account will
be checked for the sufficient amount.
Deposit The amount deposit from customer will verified by the bank after physically
check the deposited envelop by the customer. The ATM will credit the amount for
the customer account in the bank database but available balance will reflect after a
physical check of the crash and after the cake release from the source bank.
Transaction All the 3 transaction headed by the transaction operation of the single session.

Session Session logged for the single user, for the specific period. Once the transaction
will complete or cancelled in anyway, the session will expire and customer will
inform, otherwise the session will continue until customer will complete all the
transactions.
Operator The ATM operation will take care for the ATM machine ON/OFF by the bank
staff. Also, this operation will be responsible for the filling cash in the dispenser
and removing envelop from the deposit slot.

3.2.1.7. Generalization or using derive class into the ATM System

The generalization to the model derived a UML relationship. In ATM Class we established the inheritance
relationship between base class Transaction and its three derived classes using the arrow symbol with
triangular hollow arrowheads. The purpose of this designing is to encapsulate the various functionalities into
one class that represent the complete the transaction package.
Withdrawal

Transaction Deposit

BalanceEnquiry

23 | P a g e
3.2.1.8. Overriding in Class Modelling
Overriding mechanism achieved by polymorphism, this method has identical name and signature and are
placed in the same hierarchy but in the different classes. In this ATM Model the overridden used by the
transaction class and its derived classes, withdrawal, deposit and balance inquiries. The virtualization of the
base class operation gives preferences to its derived class to override operation based on their individual
functions.
3.2.1.9. Complete Class Modelling
The following complete class structure designed consists of 12 classes related to each other that help to
build the model view and will follow the same concept in the entire program. The attached Appendix B for
the Class Model.
3.2.1.10. Packages Modelling:
Packages are the container of grouped classes. In ATM system we created 4 packages and grouped their
relevant classes into them. The ATM Package inherited the Transaction sub package and physical sub
package. The concept is to all the classes in these two packages will share with the ATM Package.
 ATM Package: The ATM package has many classes and interfaces for their components. The
package will represent all the classes anywhere it imports. An ATM that represents the complete
system, and the class session that represents one session in having multiple transactions. Since the
ATM creates Sessions, and each Session in turn uses the ATM to interact with the customer.

Heading

PackATM
Package PackATM
PackPhysical
ATM

-AuthenticatUser() : bool
Class cashDespense extends ATM
-OperationPanel() : int
-CreateSession()
-GetLogDetails()
{
PackTrans
Session

+CreateSession()
DispenseCash()

 Bank Package: The bank package banking contains classes}that represent the banking enterprise
itself and the information communicated back to the requester, here requester is ATM.

Bank Package

Package packBank
PackBank

Class account extendes

BankDatabase
BankDatabase
{
+AuthenticatUser() : bool
+GetAvailableBal() : float
+GetTotalBal() : float
+Credit()
Debit()
+Debit()

}
 Transaction Package: The transaction package will encapsulate the transaction operation. This
package becomes a sub package of the ATM system, as this package considered as ATM part of
the operation. The sub package 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 classes in turn, again, depend on the ATM
to interact with the customer.

24 | P a g e
 Transaction Package

package PackTrans
PackATM::PackTrans Class Deposit extends
Transaction
Tranasction
-<<property>>AccountNumber : int{ReadOnly} {
+Execute()
Execute()
Deposit Withdrawal
-AccountNumber : int BalanceEnquiry -AccountNumber : int }
-amount : float -AccountNumber : int -Amount : float
+Execute() +Execute() +Execute()

 ATM Physical Package: This package treated as a part of the ATM system because it contained
the component software of the ATM system. The sub package 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.

ATM Physical
package PackATM:PackPhysical

PackATM::PackPhysical
Class CashDispenser
{

Operator
DispenseCash()
CashDispenser DepositSlot Screen
-atm : ATM
-BillCount : int = 500
+SwitchOn() : bool
}
+DispenseCash() +IsDepositEnvelopReceived() : bool +DisplayMessage()
+SwitchOff() : bool
+IsSufficientCashAvailable() : bool

The Screen shot below will give the UML Model package and their class hierarchy:
The UML Model designed according to the requirement of the system. We will attach Model along
with this report to view actual Model for reference. The Model comprised the entire diagram with
the class operations and attributes that will describe the data flow from attribute to attribute and
from class to another class.

25 | P a g e
  ATM Package Model: The Complete ATM Model package developed to carry forward as an
encapsulated concept in the development process. The final model can be viewed in the Appendix
B
3.2.1.11. Interfaces Modelling and Architecture Pattern
As we discussed in MVC section that software will have views and controller component, integration of
both view and controller is called MVC design. The View Components in the MVC are responsible for user
input and output. The user-Interface relents on the following view controls. The welcome screen is the main
user interface, but to facilitate, we created separate three more interfaces i.e. withdrawal screen and deposit
screen. The „Owner‟ interface is responsible for removing deposits and adding cash, a simple interface (e.g.,
a switch or button) that can be used to initialize the ATM. We will visualize all these interfaces in to
diagram attached in the Appendix B.
The purpose of the customer user interface should be instinctive to perform all the transactions for the user
without any human assistance. The following below interfaces designed for the ATM.
 Welcome Screen (interacts with keypad and screen)
 Withdraw screen (interacts with keypad and screen) (optional)
 Deposit screen (interacts with keypad and screen) (optional)
 Owner Interface (interaction with keypad and screen) (optional)
3.2.1.12. Component
Component denotes a physical part of the system that implements a piece of software program. The ATM
system has the following component; we will discuss the component and its architecture without caring that
how the designed software will work in its first version. Software developed to connect different hardware
components that will represent ATM machine as whole. Obviously, this version has simulation, but Deposit
slot and Cash dispenser will integrate concepts in the system that will complete the structure and functional
procedure.
 Screen
 Keypad
 Cash Dispenser
 Deposit Slot
 Key Operator
3.2.1.13. Deployment
The ATM deployment diagram is a very simple, consisting ATM client as ATM PC contained interfaces for
the components. The ATM client PC will create a logical data file that simply extracts the data from the
database and manipulate at the same time without caring any security prevention. A deployment diagram in
the Unified Modeling Language serves to model the physical deployment of artifacts on deployment targets.
In deployment we described in the diagram a ATM node inherited the components and interfaces, connected
to the conceptual logical database. This database could be within the same computer or using different
machines, sounds a server. We created excel sheet and deploy into the same computer as a data file.
3.2.2. Behavior Diagram
3.2.2.1. Use Case Diagram
Based on above Use Case Diagrams the further diagrams will create and discuss.
3.2.2.2. States Diagrams in the ATM System
We are now ready to design the State charts based on above defined classes and Use-cases. State chart
diagrams describe the dynamic behavior and are useful in modelling reactive objects whose states are
triggered by specific events. Each object in a system goes through a series of discrete states. In the ATM the
Three of the objects identified that have behavior that is sufficiently complex to permit developing a State
Chart for them.
 The object representing the machine itself, responsible for the System Start-up and Shutdown use
case.
 Objects representing a customer single session, responsible for the session use case
 Objects representing an individual transaction responsible for the transaction use cases for the
specific types of transaction and invalid PIN extension.
o State-ATM Session
o State –Transactions
o State-ATM Operation

26 | P a g e
3.2.2.3. Activities in the ATM System
The Activity Diagram represents the movement from class to class as view, below diagram uses the
following process:
 Withdraw / deposit money Diagram from a bank account through an ATM. The involved classes of
the activity are the customer, ATM Machine, and Bank. The process begins at the red start and
ends pointed at the concentric red/black stop / start circles.
 Verification Diagram of customer authenticated by the bank directly interaction of ATM.
The following diagrams are in the Model
o ActivityWithdrawal
o ActivityDeposit
o ActivityUserAuthenticate
o ActivityBalanceEnquiry

3.2.2.4. Interaction Diagram

Now we shall move to the next step from collaboration to the interaction UML diagram. The UML provides
several types of interaction diagrams that model the behavior of a system by modeling how objects interact
with one another. Here we will discuss collaboration and sequence diagrams.
 The first diagram in the interaction will focus on the Collaboration diagram emphasizes which objects
participate in collaborations. The invalid Account / PIN Extension is documented using Collaboration
Diagrams.
 We will demonstrate the sequence diagram which emphasizes when messages sent between objects.
The major use cases are documented using Sequence Diagrams, and the specific subclass of the
transaction.
3.2.2.4.1. Collaboration Diagram
When two objects communicate with each other to accomplish a task known as collaborate.
Collaboration consists of an object of one class sending a message to an object of another class.
An object sends the message to an object
of class... of class...

ATM DisplayMessage Screen

GetInput Keypad
AuthenticateUser BankDatabase
Execute BalanceInquiry
Execute Withdrawal
Execute Deposit
BalanceInquiry GetAvailableBalance BankDatabase
GetTotalBalance BankDatabase
DisplayMessage Screen
Withdrawal DisplayMessage Screen
GetInput Keypad
GetAvailableBalance BankDatabase
IsSufficientCashAvailable CashDispenser
Debit BankDatabase
DispenseCash CashDispenser
Deposit DisplayMessage Screen
GetInput Keypad
IsDepositEnvelopeReceived DepositSlot

27 | P a g e
 Credit BankDatabase

BankDatabase AuthenticateUser Stored Value

AvailableBalance (get) Stored Value
TotalBalance (get) Stored Value
Debit Stored Value
Credit Stored Value
Session CreateSession Session

Transaction Execute Transaction

The Collaboration objects are connected with solid lines. The messages are passed between objects
along these lines in the shown direction by arrows. The filled arrow in represents a message or
synchronous call in the UML. We tried to design the following Collaboration diagram based on
essential requirements.
o Withdrawal
o Deposit
o Balance inquiries
o Authentication
In deposit diagram the credit only responsible for the available balance and total balance will take care
after the verification of envelope and check release, that can done by the bank in its account database.
Because the requirement is only looking bank database provided by bank pc, therefore the account
class not included.
3.2.2.4.2. Sequence Diagrams
A sequence diagram which helps model the timing of collaborations more clearly. The below
withdrawal sequence diagram shows a modeling the sequence of interactions that occur when a
Withdrawal executes.

The dotted or solid line extending down from an object‟s rectangle is that object‟s lifeline, which
represents the progression of time. Actions typically occur along an object‟s lifeline in chronological
order from top to bottom. The activation, shown as a thin vertical rectangle, indicates that an object is
executed. The requirement emphasized to create the following ATM sequence diagram.
o Balance inquiries
o Deposit
o Withdrawal
o Session
o User Authentication
5.5. ATM BPMN Model
The primary objective of the BPMN is to provide a system to the business users, from the business analysts that
create the initial drafts of the processes, to the technical developers responsible for implementing the technology that
will perform those processes, and finally, to the business people who will manage and monitor those processes. The
BPMN will represent the structure of the ATM that understandable for the stockholder, developers and of course
other involved groups. We tried to encapsulate the entire formulation of the ATM system as a whole process. The
Model attached in Appendix B.
5.6. Critical Analysis
Architectures provide benefits of reusability, robustness and - especially - maintainability to software code.
Conceptually the Architecture categories as follows:
a. The architecture is 3 types‟ models, components / connectors and allocation.
b. The System can have more than one structure, model structure, interaction, behavior and
deployment.
c. The view represents of structure and their relationship.

28 | P a g e
When we collect all the above information then architecture becomes abstract model architecture that
represented structure. ATM here structured the model and merged with the interaction and behaviors using
UML different diagrams that represent the viewpoints and behaviors.
This section reviewed several phases of the architecture and finally concluded that we have a perfect model
view, but an architecture design will not cover all its phases respectively. When we start reading architecture,
we found myself stuck and many attempts revealed that ATM in this requirement cannot shape an architecture
because the lack of physical components and the connectors. The constraints in the requirement emphasized me
to shape the model view.
The UML on the other hand is very easy and useful tool to design a dynamic model, only basic knowledge
enough to develop models in this tool. The main phase is to design the classes and their relevant operations, the
other diagrams and models designed based on these classes that only required to link accordingly. The data flow
and operational procedures can be viewed in these UML diagrams dynamically. We would attach UML Model
along with the report, all the other diagrams and classes with deployment diagrams attached to this report for
reference.

29 | P a g e
5. CLASSES REFINEMENT ANALYSIS
5.1. Introduction
Based on our previous use-case and the class model design, the classes will be structured and packed with the
operations, these classes flow data from one class to another class which shape the entire software system.
5.2. Classes
Classes are the descriptor for the set of objects with the same attribute and operations. It serves as a template for
object creation. These objects contained the values to confirm the attribute type defined class. We will create an
ATM class structure as a replicate of above ATM Use-Case and architecture model. Thus, We will move step by step
from model structure to class structure to derive class, the stages will provide the refinement of the basic classes to
the conceptual ATM class design..
5.3. Further Refinement in the Candidate Classes
Based on requirement, we need to drill down the candidature of the classes to build appropriate runtime system. The
class transaction and session will add into the model. The session will denote to assign the session to each transaction
for a period of time. The session will dismiss when the customer will cancel the transaction or the ATM rejects the
transaction due to some errors. The transfer class already defined in the architecture model, but will further refine for
the system.
1. ATM
2. Screen
3. Keypad
4. CashDispenser
5. DepositSlot
6. BankDatabase,
7. BalanceInquiry
8. Withdrawal
9. Deposit
10. Transaction
11. Session

5.4. The Classes, Attributes

Attributes contained information in the form of data, these data traverse from class to class perform an action
triggered by the user. The ATM class has significant attributes that holding information of the customer. The
refinement in the class attributes focused on the normalization, we eliminated the account number from the
„withdrawal‟ and „depositors‟ class because these two classes will become derived class for the „transfer‟ base class,
therefore in the plan we will offer authorization to these two classes to extract an account number from their base
class. The following structures and specification will expand our intention.
Class Descriptive Attributes and phrases

ATM Authenticate to the user

Withdrawal account number

amount
Deposit account number
amount
CashDispenser BillCount
[begins each day loaded with £500 of £20 bills]
Operator Atm as ATM type
Transaction Account number

Model Attribute

30 | P a g e
 PackPhysical::Operator PackPhysical::CashDispenser
-atm : ATM -BillCount : int = 500
+SwitchOn() : bool +DispenseCash(in amount : double) : void
+SwitchOff() : bool +IsSufficientCashAvailable(in amount : double) : bool

PackATM::ATM
-UserAuthenticat : bool
-OperationPanel() : int
+GetLog() : char
+CreateSession() : void
PackTrans::Tranasction
-AccountNumber : int{ReadOnly}
+Execute()
+GetAccountNumber(in AccountNo : int) : int

PackBank::BankDatabase PackTrans::Withdrawal
-AccountNumber : int -Amount : double
-PIN : int +Execute()
-AvailableBalance : double
-TotalBalance : double
+AuthenticatUser(in UserPIN : int, in AccountNo : int) : bool
+GetAvailableBal(in AccountNo : int) : double PackTrans::Deposit
+GetTotalBal(in AccountNo : int) : double -amount : double
+Credit(in AccountNo : int, in amount : double) +Execute()
+Debit(in accountNo : int, in amount : double)

5.4.1. Attribute Specification in details

ATM UserAuthenticated The ATM will responsible to authenticate the customer to access
their account from the system.
=bool
BalanceEnquiry Each transaction involves an "account number" that corresponds
to the account of the user making the transaction; therefore the
base class will share its public attribute account number with its
derived classes. Further the balanceEnquiry class does not need a
mount attribute.
Withdrawal amount = float Users must enter a specific "amount" to withdraw. The class
withdrawal sharing one attribute called account number from
their base class transaction. This attribute involved in each
transaction to correspond with the bank database to extract the
customer account number. The other attribute in withdrawal
specified the amount attribute that carry the requested amount by
the customer during his / her transaction session.
Depot amount = float Users must enter a specific "amount" to deposit in pens only, the
exception trigger fired if decimal entered by customer. The class
Deposit also sharing one attribute called account number from
their base the transaction base class. This attribute involved in
each transaction to correspond with the bank database to extract
the customer account number.
CashDispense billCount =integer  The cash dispenser "begins each day loaded with £500
of £20 bills“
 The number of bills will counted by the billCount
attribute, that aims to determine whether enough cash is
on hand to satisfy withdrawal requests.
Screen, Keypad, Our design process has not yet revealed any attributes
DepositSlot, Session,
At early stages in the design process, classes often lack attributes
ATM, Screen Class
(and operations). Such classes should not be eliminated,
however, because attributes (and operations) may become
evident in the later phases of design and implementation.
BankDatabase Class AccountNumber= The Bank database has several attributes, the requirements stated
that each bank has an account number and PIN to authenticate
Integer
user. The class also contained availableBalance and totalBalance
PIN=integer that will maintain the amount of the customer and this deposit
amount available for the transaction only when the bank will
AvailableBalance
verify the customer authentication. The bank record the amount
=double of money that a user deposited, therefore availableBalance will
track the amount that user will withdraw and totalAmount will

31 | P a g e
 TotalBalance= hold the on-deposit amount i.e. amount available plus amount
waiting for verification.
double
Transaction AccountNumber= The transaction class using public visible accountNumber
integer attributes as read only that in return the visibility is read only all
other classes of the ATM system. The accountNumber will share
by its 3 derived classes, i.e. withdrawal, balanceEnquiry and
Deposit class.
Operator ATM type The operator should have atm type attribute to identification
ATM number that logs the details of the specific ATM machine.

5.5. Visibility
More refinement required for the classes and we shall assign access modifiers that determined the visibility, or
accessibility, of an object‟s attributes and operations to other objects. The UML employs visibility marker that
exhibits the visibility of attributes and operations. The ATM attributes typically are private for the other classes and
protected for the derived classes. The visibilities are many types.
 Public visibility is indicated by a plus sign (+) and
 Private visibility a minus sign (–) indicates.
 Protected

PackATM::ATM
-UserAuthenticat : bool
-OperationPanel() : int
+GetLog() : char

5.6. Navigability & Association

The navigability arrows indicate in which direction an association can be traversed. In this way the programmers use
navigability arrows to help determine which objects need references to other objects. Here the DepositSlot and screen
associated with the class ATM.

DepositSlot Screen
1
-AccountNumber : int
-Amount : decimal ATM 1 +DisplayMessage()
+Execute() 1
+IsDepositEnvelopReceived() : bool
-UserAuthenticated() : bool
-SystemOperation() : int 1
-CreatSession()
-GetLogDetails()

1
1

BankDatabase

+AthenticateUser() : bool
+GetAvailableBalance() : float
+GetTotalBalance() : float
+Credit()
+Debit()

Class diagram with navigability arrows

5.7. Composite Relationship Properties

As we already discussed the relationship between the architecture designing. The relationship can be formed by one
class that can represent the whole, either the screen is part of the ATM or the ATM is part of the screen but ATM
cannot represent both as the whole in the relationship. If the ATM is destroyed, then the other parts of ATM which
are screened, and deposit slot also destroyed.
 A part may belong to only one whole at a time, although the part may be removed and attached to another
whole, which then assumes responsibility for the part.
 If a “has-a” relationship does not satisfy one or more of these criteria, hollow diamonds are used to indicate
aggregation.
 We model object of classes called BankDatabase, keybord, screen, operator, cash dispenser and deposit slot.
 Class ATM has a one-to-one relationship with class BankDatabase that means one ATM object
authenticates users against one BankDatabase object.
 If the user is performing a withdrawal, then all other parts of the system must interact with the database to
retrieve or update customer account information.
 Classes have attributes (data) and operations (behaviors).

32 | P a g e
  For each such word and phrase plays a significant role in the ATM system, later we shall create an attribute
and assign it to one or more of the classes identified.
 We shall create attributes to represent any additional data that a class may need, as such needs become clear.
Class Diagram For The ATM System Model

CashDispenser
keyPad 1

Screen 1 DepositSlot

1
11 1 1

ATM Operator

1
0..1
1
-Authnticates User 1

BankDatabase

5.8. Modelling Operations in details

In the architecture modelling we defined the operations for the classes, here we shall refine these operations and
explain their reasons of presents in the system.

Class Operation In Descriptions

ATM: UserAuthenticate()::bool
OperationalPanel()::int
CreateSession()
GetLog()::char
BankDatabase: AuthenticateUser(UserPIN,AccountNo) The database is the object that contained the necessary
::bool
GetAvailableBal(AccountNo)::float
GetTotalBal(AccountNo)::float
Credit(AccountNo,amount)
Debit(AccountNo,amount)
The ATM is the central and the main class deal with the
entire classes throughout the life cycle and provides
access to component parts for sessions and transactions.
The UserAuthenticate operation verified the
authenticated customer from the bank database and
return yes or no as book that allow user to perform the
transaction. The OperationPanel is responsible for the
operator activity by sending ATM confirmation in
return to the operator class. The CreateSession
operation responsible to check the number of
transactions in one session performed accordingly with
the collaboration Session Class. GetLog operation
records all the account numbers and their relevant
activities with the status that interacts for the day and
store within the system, this information transfer to the
bank for their record.
account information to determine that the PIN and
account number entered by the user matches in the
bank database, therefore the class required
authentication function. This class validates the
authentication of user account and PIN to access
account information requested by the ATM. This class
likewise has other operations provide services to the
ATM based on their functionality. The
GetAvailableBal () and GetTotalBal () both operations
access by the BalanceEnquiry class and Get
Availablebal () operation access by the withdrawal calls
to get only the available balance to check and verify
with the withdrawal amount entered by the user. The
Credit() and Debit() operation must perform the
operation debit and credit amount from the account

33 | P a g e
 database.

Screen: DisplayMessage(message) This class commonly used by other classes to display

the various messages to the customer along with error
messages generated by the system.
Keypad: GetInput()::int This operation used by many classes to extract the input
from the user. This class directly interacts with the
customer.
CashDispenser: DispenseCash(amount) The Dispenser will dispense the cash to the customer
by DispenseCash operation, but this class indicates that
IsSufficientCashAvailable(amount)
it will check the sufficient amount in the dispenser
::bool before dispense with using IsSufficientCashAvailable
(). This operation will return true or false to the ATM
indicating whether to dispense amount or reject
requests.
DepositSlot: IsDepositEnvelopReceived() The requirement document stated that deposit slot will
check envelop received a flag. For this requirement the
::bool
Deposit Class created IsDepositEnvelopReceived() that
return bool to the ATM. The operation will wait for a
specific time and then credit the balance in the
database. If envelop not received (not press OK) within
specific time, then the transaction will cancel by the
ATM.
BalanceInquiry: Execute() Retrieve balance for the custom from the bank account
database.
Withdrawal: Execute() The Customer withdraws the amount from their
account, the bank account and cash dispenser checked
for the sufficient amount before dispense by the ATM
system. The account number extracts from the abstract
class Transaction, the class gets amount from the
keyboard. The execute function executes all withdrawal
operations for the given account number and transfer
amount of the abstract class to add in the account.
Deposit: Execute() This class extracts the account number from abstract
class Transaction, and amount populates from the
keypad. The execute operation will verify the envelope
deposited to the deposit slot within a specific time, if
yes then the amount will send to the abstract class to
credit amount in the banks database but total balance
will reflect after physical check of the cash or deposited
cheque release from the source bank.
Transaction: Execute() The transaction class responsible to extract the account
number from the bank database by GetAccountNumber
GetAccountNumber(AccountNo)
operation and make available for their subclasses as
::int read only attribute AccountNumber. Execute operation
responsible to credit or debit amount from the bank
database using bankDatabase Class.
Session: CreateSession() The CreateSession operation will lock the entire
transaction for the period of time. Each session is for a
single customer and their multiple transactions
respectively.

34 | P a g e
 PackATM::Session PackPhysical::KeyPad PackPhysical::Operator PackTrans::Withdrawal PackPhysical::CashDispenser
-atm : ATM -Amount : double -BillCount : int = 500
+CreateSession() +GetInput() : int +SwitchOn() : bool +Execute() +DispenseCash(in amount : double) : void
+SwitchOff() : bool +IsSufficientCashAvailable(in amount : double) : bool
PackPhysical::DepositSlot PackTrans::Deposit PackTrans::BalanceEnquiry
PackTrans::Tranasction
-amount : double -AccountNumber : int{ReadOnly}
+IsDepositEnvelopReceived() : bool +Execute() +Execute()
+Execute()
+GetAccountNumber(in AccountNo : int) : int
PackATM::ATM PackBank::BankDatabase
-UserAuthenticat : bool PackPhysical::Screen
-OperationPanel() : int +AuthenticatUser(in UserPIN : int, in AccountNo : int) : bool
+GetLog() : char +GetAvailableBal(in AccountNo : int) : double +DisplayMessage(in message : unsigned char)
+CreateSession() : void +GetTotalBal(in AccountNo : int) : double
+Credit(in AccountNo : int, in amount : double)
+Debit(in accountNo : int, in amount : double)

Operation Structure View

5.9. Derived Class / Generalization into the ATM System

One more step forward toward generalization to model inheritance specifies a UML relationship. In ATM Class
diagram established the derived relationship between base class „Transaction‟ and its three derived classes by using
the arrows with triangular hollow arrowheads.
As the diagram below showing, classes BalanceInquiry, Withdrawal and Deposit shares accountNumber a read only
attribute from their abstract class Transaction, as these derived classes become concrete for the base class.

PackTrans::Withdrawal
-Amount : double
+Execute()

PackTrans::Tranasction PackTrans::Deposit
-AccountNumber : int{ReadOnly} -amount : double
+Execute() +Execute()
+GetAccountNumber(in AccountNo : int) : int

PackTrans::BalanceEnquiry

+Execute()

Now the Withdrawal is a type of Transaction, we draw an association line directly between the ATM class and
Withdrawal class, so the derived class Withdrawal inherits base class Transaction‟s association with class ATM.
Similarly the other 2 derived classes BalanceInquiry and Deposit also inherits same as withdrawal class and replaces
the previously omitted associations between classes BalanceInquiry and Deposit, and class ATM.
The association between Transaction and BankDatabase require a reference to the BankDatabase so that they can
access and modify account information. An association between class Transaction and the Screen display output to
the user via the Screen. Class Withdrawal still participates in associations with the CashDispenser and the Keypad.
5.10. The complete refinement in the class diagram
The class diagram can be viewed in the Appendix C.
5.11. Discussion / Conclusion:
The overall analysis of this section was challenging, we need to achieve both, ATM real World and simulation in this
design. To model the classes become more challenging, step by procedure required each and every phase must
clearly define and explained. The classes developed with some extra coding to maintain the simulation. For example
we don‟t have deposit slot and dispenser component available, but we created classes and included in the structure to
blend this system with the real world because it's included in the requirement.
The generalization in the class model was a little tricky and took a lot time to finalize the structure. In the beginning
we created three classes, i.e. withdrawal, deposit, and balanceEnquiry for transaction but when refined them, we
added another class called transaction to represent these three classes. Similarly in first structure we created
accountNumber attribute for all these four classes to manipulate with the bank account but when refined these classes
we realized that repetition of attributes will failure of generalization and then thought about virtual class in their
derived classes.

35 | P a g e
6. TRACEABILITY ANALYSIS
Traceability refers to the ability to describe and follow the life of a requirement in both forwards and backwards.
During the software life cycle the requirements traceability analysis performing an important part as it ensures that
all of the requirements have been adequately considered during each phase of the project and make sure that there
has nothing skipped in the developed system due to missing requirements.
 Requirements management deals with the process of managing changes in the requirements during the
requirements engineering process and system development.
 Requirements traceability is concerned with the relationships between requirements (dependencies), their
sources and the system design.
 CASE tools are necessary for the requirements, storage and management.

6.1. Types of Traceability Matrix:

 Forward Traceability – Mapping of Requirements to Test cases
 Backward Traceability – Mapping of Test Cases for Requirements
 Bidirectional Traceability - A Good Traceability matrix is the References from test cases to basis
documentation and vice versa.

6.2. Requirements Traceability Matrix

The Requirements Traceability Matrix is the best and most common way to ensure the entire requirement tested. In
the ATM project we design matrix to follow the forward and backward trace to make sure that each and every
requirement and business specification covered.
6.2.1. Forward Traceability
The forward traceability in the ATM is used to verify that all derived using case requirements are associated
with correspondence classes and their operations started from a Business specification to requirement
specification. We will also emphasize to target the behavior and interaction diagram related to use case that
reflects the behavior of Use-Cases.
Business Requirement: The phase will start with the business requirement based on stockholder specification,
this business requirement traceable to the requirement of the system.
Requirements - During this phase, the business and system use cases need to be validated against the functional
and system requirements, to ensure complete coverage.
Use-Case-Classes - During the matrix development the Use-Case traverse from requirement for associated
classes.
Testing – Use Case test coverage is a key metric in the testing activities as it ensures that all the requirements
and use cases have supporting test cases that will validate the functionality works as expected.
Result – The result for the test depend its approval (pass, fail), follow with the description.

The Screen Short Attached in the Appendix D

6.2.2. Backwards / Reverse Traceability

The backward traceability refers to the need to Use-Cases the lineage and source of all the classes defined in the
system Use-Case Specification. The matrix reflects class functionality to requirement gathering. The following
covered this matrix requirement.
Classes and Use-Case: The class and their operation reflect the Use-Case traceability that makes sure that the
requirement specification has covered.
Requirements: The traceability will assess the requirement specification that reflects the class quality and
correctness.
Business specification: The backward traceable ended with the business check, ensuring that the classes and its
functions covered the entire requirement from stockholder to business.
.The Screen Short Attached in the Appendix D

36 | P a g e
Conclusion/ Discussion:
The traceability matrix designed to cover overall coverage from business to classes development. Our
observation and analysis denotes that the traceable matrix force you to complete the pending or hidden
information as per requirement. When we created matrix, we left few diagrams do designed but once we trace,
found weakness and include them.
But it has not only benefits but carrying drawbacks also. Our opinion is that this matrix is the indexing of the
report that asked some extra work. Rewriting details and descriptions in the matrix are much time consuming.
We spend time to understand the matrix and follow some of the example matrix provided in the lab and then
used logic to complete this matrix. We are sure this matrix is little different but tried to cover all in fewer sheets.

37 | P a g e
 Appendix A

The Use Cases

38 | P a g e
 ATM System

-<<message>>
Display Screen

-<<message>>

Bank Computer
Begin Session Cancel Transaction
with Data File

Log «extends»
«extends»

Input Value ATM Transaction Authentication

«extends» -<<include>>
:Customer «extends» «extends»
«extends»

Bank
Balance Enquiry
Withdrawal PIN/ACC Validate

Depost

«uses»

Cancel / Exit System Shutdown

Max Withdrawal
«uses»

System Up
Display Thank you

Operator

39 | P a g e
 Authentication

Display Message
-<<message>>
More than 3
attempts
Authentication
Failed
Bank
«extends»
Insert 5 disgit
«extends»
Account Number
«uses»

Authenticated User

«uses»
:Customer
«extends»
ATM
Insert 5 digit PIN
Number

Account / PIN
Validate

Selection / Main
Menu

40 | P a g e
 ATM Session

Display Message

Session Begin Session Cancelled

Bank

Authentication
Failed
«extends»

«extends»
Account / PIN
Input Value Authenticated User
Validate

«extends» «extends»

:Customer ATM
«extends»
Log Authenticated

Cancel / Exit

«uses» Performed
Transaction

Display Thank you

Session Completed

41 | P a g e
 ATM Transaction

Display Message

Session Begin UnAuthenticated

Bank

Log

«extends»

«extends» «uses»
Transaction
Input Value Transaction Authenticated User
Approved

«extends» «extends»
ATM
:Customer
«extends»

Balance Enquiry Withdrawal

Cancel / Exit

Depost
«uses»

Display Thank you

42 | P a g e
 ATM Withdrawal
Display Message

Session Begin

Transaction
Disaproved Bank
«extends»

«extends»
Input Value Authenticated User

«extends» «uses»

ATM
:Customer Transaction
Log Approved

Selection / Main
Check Account
Menu

«extends»
«extends»

«extends»
Choose Smaller
Greater Amount Less / Equal Amount
Amount

«extends»

Not Sufficient «extends»

Cancel / Exit Check Dispenser
Amount Amount
«uses»

«extends»

Display Thank you

Session Cancelled Sufficient Amount

Session Completed

«extends»

Display Message to
Debit
Collect Amount

43 | P a g e
 ATM Deposit System

Display Message

Session Cancelled

Session Begin

Transaction
Disaproved
«extends» -<<message>>

«extends»
Input Value Authenticated User
«uses»

«extends»

:Customer Transaction Bank

Approved

Log

«uses»
Input Specified {Calculate entered pens
Deposit Amount into Real number =125/100=1.25}

Cancel / Exit Not Received

«uses»

Display Thank you

«extends» Attempt to Receive
Screen Display /
Credit
Insert Envolop Envelope

-Success

Session Cancelled
Received

44 | P a g e
 ATM Balance Enquiry

Display Message

Bank

-_1
Session Cancelled
Transaction
Disaproved
«extends» -_1

Input Value Authenticated User

«uses»
«extends»
:Customer

Transaction Bank
Log
Approved

Session Begin

Transaction

«extends»

«extends»
View Balance Balance Enquiry

«uses»
Cancel / Exit Display Thank you

45 | P a g e
 Operation Panel

Remove Deposit
Envelop

«extends»

«extends»
System Shutdown Switch Off

«extends»

Operator
Re Load Cash

Bank

«uses»
Varification Switch On

«uses»

System Up

{The System initialize with the t pounds and k,m,n,r abrevation.}

46 | P a g e
 Appendix B
Architecture Designing

47 | P a g e
 Class Model Of the ATM system

1
1

keyPad 1 Operator
CashDispenser 1

1
0..1
1 0..1
1
Screen 0..1
DepositSlot 1
1 0..1 1 Withdrawal
0..1
1 0..1
1 ATM
1 1

1
1
Execute Transaction Deposit

1
0..1

AuthenticatedUser 0..1
BalanceEnquiry
1
1
Session BankDatabase 1

Access / Modify Account balance

48 | P a g e
ATM Package
ATM Physical
PackATM
PackATM::ATM
-UserAuthenticat : bool
-OperationPanel() : int
+GetLog() : char
+CreateSession() : void
PackATM::Session
+CreateSession()
PackATM::PackPhysical PackPhysical::Operator
PackPhysical::KeyPad
-atm : ATM
+GetInput() : int +SwitchOn() : bool
+SwitchOff() : bool
PackPhysical::CashDispenser PackPhysical::DepositSlot PackPhysical::Screen
-BillCount : int = 500
+DispenseCash(in amount : double) : void +IsDepositEnvelopReceived() : bool +DisplayMessage(in message : unsigned char)
+IsSufficientCashAvailable(in amount : double) : bool
Transaction Package
PackATM::PackTrans
PackTrans::Tranasction
-AccountNumber : int{ReadOnly}
+Execute()
+GetAccountNumber(in AccountNo : int) : int
PackTrans::Deposit PackTrans::Withdrawal
PackTrans::BalanceEnquiry
-amount : double -Amount : double
+Execute() +Execute()
+Execute()
Bank Package
PackBank
PackBank::BankDatabase
-AccountNumber : int
-PIN : int
-AvailableBalance : double
-TotalBalance : double
+AuthenticatUser(in UserPIN : int, in AccountNo : int) : bool
+GetAvailableBal(in AccountNo : int) : double
+GetTotalBal(in AccountNo : int) : double
+Credit(in AccountNo : int, in amount : double)
+Debit(in accountNo : int, in amount : double)
49 | P a g e
 User Interface and its component dependency

«interface»
Wecome Screen
+Display Message() : Wecome Screen

«interface» «interface» «interface»

Deposit Screen «uses» «uses» Owner Withdrawal Screen
+Execute() : Deposit +SwitchOn() : +Execute() : Withdrawal
+SwitchOff() :
«uses»
«uses»
«uses» Screen KeyPad
-atm : ATM
+DisplayMessage() +GetInput() : int +SwitchOn() : bool
+SwitchOff() : bool
-Varifies -Varifies
1

DepositSlot ATM CashDispenser BalanceEnquiry

-Varifies
-BillCount : int = 500 -AccountNumber : int
-AuthenticatUser() : bool 0..1 +DispenseCash()
+IsDepositEnvelopReceived() : bool +Execute()
-OperationPanel() : int +IsSufficientCashAvailable() : bool
-Varifies
-CreateSession()
-GetLogDetails()

1
-access 1 -Varifies
1
1
BankDatabase
Deposit
Withdrawal
-AccountNumber : int
+AuthenticatUser() : bool -AccountNumber : int
-amount : float
+GetAvailableBal() : float -Amount : float
+Execute() +GetTotalBal() : float +Execute()
+Credit()
+Debit()

50 | P a g e
ATM Components deployment with thier Interfaces

Screen

Screen

Deposit Screen

DepositSlot KeyPad

Owner
Withdrawal Screen

CashDesponser Operator

51 | P a g e
ATM Deployment Diagram
ATM client Machine

Screen CashDispenser

Screen CashDesponser

Customer

:Customer

KepPad DepositSlot

KeyPad DepositSlot

Operator
Bank
Operator

Bank

ATM Deployment Client and Server Architecture

Two Tier Architecture

ATM Deployment Diagram

ATMClient PC / Matchine
BankDatabase
CashDesponser Withdrawal Screen

<<Logical Database>>
DepositSlot Deposit Screen <<deploy>>

Database File
1 0..1
Operator Owner

Screen

KeyPad Screen

52 | P a g e
State Diagram

State Diagram for ATM System

Power On/ OFF

Stop Activity
Switch On ready To Serve
Shutdown
ATM Transaction

Session Start

Welcome Message / Input Perform Transaction

Transaction Successful /
Or Cancel Transaction

Transaction Over

{The System initialize with the t pounds and k,m,n,r abrevation.}

53 | P a g e
The other try

54 | P a g e
 State Diagram for Transaction
Transaction

Display Screen
Entered PIN / Account Number

Cancel Transaction
Getting Card Number / PIN Number

Invalid Authentication
Handle Invalid Authorisation Authenticate Validity / Approved Bank Data

Validate The
Authentication Authentication Validate

Transaction Withdrawal / Deposit / Balance Enquiry Success

Wait for Another Transaction

55 | P a g e
State Session

Display Screen

-Input Account/ PIN Number

-Cancel Pressed
Read Account / PIN

-Transaction Choosen
-Cancel Pressed
Choose Trnasaction
-Transaction Choosen

Transaction Started
-Another Transaction Choosen
-Completed Transaction

-Abort due to more than 3 tries

Cancel Transaction

56 | P a g e
State Session

Display Screen

-Input Account/ PIN Number

-Cancel Pressed
Read Account / PIN

-Transaction Choosen
-Cancel Pressed
Choose Trnasaction
-Transaction Choosen

Transaction Started
-Another Transaction Choosen
-Completed Transaction

-Abort due to more than 3 tries

Cancel Transaction

57 | P a g e
 Activity Diagram For Deposit
Customer ATM Matchine Bank

Chosen Cancel / Wait for User Input

Display Main Menu

Choose 3=Deposit Amount

Input From Main Menu Screen Prompt Enter Deposit Amount Credit Amount from the Account

Chosen 4
Enter Deposit Amount Credit Amount
=Exit
From the
Account
Set Amount Attribute

User Specifies amount

Display Message to Deposit Envelop to Slot

Choose
Zero to Attempt to receive Envelop
Cancel
Received Envelop

Not
Received
Display Message that System Cancel Transaction

Cancel Transaction
Transaction Completed
or User Exit

58 | P a g e
 Activity Diagram For Withdrawal

Chosen
Cancel
Display Menu / Option To Cancel Cancel / Exit

Enter
Amount
Select Option From Menu Set Amount Attribute Get Available Balance

Amount <=
Available
Check Cash Dispenser Balance

Amount >
Insufficient Sufficient Cash Available Balance
Cash Available Available
Debit Account

Dispense Amount

Message Take Money

Cash Not Dispense

or user not
Cancelled

Cash Dispense or
user Cancelled

59 | P a g e
 Activity Diagram For User Authenticated

Customer ATM Bank

Display Welcome Screen

User Authentoicate

Enter Account Number

Enter PIN Number ACCOUNT / PIN Authenticate

-Account / PIN validate

-Account / PIN InValidate

Display Main Menu

-Authentication Completed

Display Error Message

-ATM Return to Welcome Screen

Another Try
Customer Authentication Verification Activity

Enter Account Number / PIN

Display Incorrect PIN / Please Try Again

Access Transaction / Account

60 | P a g e
 Activity Diagram For Balance Enquiry
Customer ATM Bank

Welcome Screen

Athenticate User

Enter Account / PIN Number User Athenticated

Authorisation Failed

Authenticated
Display Main Menu

Thank You Message

Choose 4=Exit
Choose Input
Get Available Balance
Choose 1 =View Balance

Display Balance

Transaction Completed

61 | P a g e
 Collaboration in the ATM Deposit

:KeyPad :Screen

1. GetInput(amount)
MainATM:::Customer
:BankDatabase :ATM
2. UserAthenticate(Boolean) 3. Execute() 6. DisplayMessage()
5. Cretid()

:Deposit

4. IsDepositEnvelopReceived(bool)

:DepositSlot

Incase of Invalid Pin / Account Number and Insufficient Amount in the account and Dispenser,
will go to display Screen

62 | P a g e
 Collaboration in the ATM withdrawal

:KeyPad :Screen

1. GetInput()
2. UserAthenticateed
MainATM::Operator (Bool)
:BankDatabase :ATM
3. Execute() 8. DisplayMessage
(message)

5. GetAvaliableBalance
(AccountNumber) :Withdrawal
6. Debit()
4. IsSufficientCashAvaliable()
7. DispenseCash()

:CashDispenser
6-4. AvailableBalance

Property Get Accessor

Incase of Invalid Pin and Insufficient Amount in the account and Dispenser,
will effect diplay Screen

63 | P a g e
 Collaboration in the ATM Balance Enquiry

:Screen

5. DisplayMessage
1. UserAthenticated
(message)
(false)
MainATM:::Customer
:UserAuthenticated :BalanceEnquiry
3. GetAvaliableBalance
(AccountNumber)
2. Validate(boolean) 4. GetTotalBalance
(AccountNumber)
:BankDatabase

3. GetTotalBalance(AccountNumber)
4. GetAvailableBalance(AccountNumber)

Propert get Accessory

Collaboration Authentication Process

Au
the
n

:ATM
tica

ut()
tUs

etI np e
G icat
ut:=
er:=

t
etInp uthen
Au

G serA
U
the
n tica
tUs
er(U

:KeyPad
ser
P IN
,A

MainATM:::Customer
cco
un

:BankDatabase
tNo
)

ge
M essa
play
Dis

:Screen

64 | P a g e
 Sequence Diagram models a Balance Enquiry

:BalanceEnquiry
:Screen :BankDatabase

:DisplayMessage(message)

:Session

:UserAuthenticated(bool)

CreateSession()

:GetAvailableBalance(AccountNumber)

:GetTotalBalance(AccountNumber)

DisplayMessage

65 | P a g e
 User Authentication

:Screen :ATM :BankDatabase

:Customer
DisplayMessage(message)

GetInput:=GetInput()

AuthenticatUser:=AuthenticatUser(UserPIN, AccountNo)

DisplayMessage(message)

DisplayMessage

66 | P a g e
 Sequence diagram that models a Withdrawal

:Withdrawal :KeyPad :BankDatabase :CashDispenser

:Screen
:Session
DisplayMessage(message)

GetInput:=GetInput()

CreateSession()

GetAvailableBal:=GetAvailableBal(AccountNo)

GetTotalBal()

IsSufficientCashAvailable:=IsSufficientCashAvailable(amount)

Debit

DisplayMessage

DispenseCash
DisplayMessage

67 | P a g e
 Sequence diagram that models a Deposit

:Deposit :Session
:Screen
DisplayMessage :BankDatabase
:Depost Slot
:KeyPad

GetInput:=GetInput()

DisplayMessage(message)

CreateSession()

IsDepositEnvelopReceived:=IsDepositEnvelopReceived()

Credit(AccountNo, amount)

DisplayMessage(message)

68 | P a g e
 Sequence-ATM Session

:Transaction
:ATM

:Screen
:Customer

DisplayMessage(message) :Session

AuthenticatUser

CreateSession()

Execute()

69 | P a g e
 Quit
Depost /
Customer

Customer

Withdrawal Enter
Display Screen
Select Option Amount
Cancel
Cash
Despense
Enquiry
Check
Enter Balance
Account Enter PIN
Number

Enquiry Withdrawal

Received No
Received Received Received
Account Exit Session
PIN Authentication Command
Number
Deposit Display
Message
Take Money
Computer

Check Deposit
Slot
ATM

Amount<=Balance Amount>Balance

Received
Envelop

Debit

Card /
Bank

PINAuthenticat Credit
ion
check Bank Database
Account

70 | P a g e
 Appendix C
Refinement Classes

71 | P a g e
 ATM Class Model

1
1

PackPhysical::KeyPad 1 PackPhysical::CashDispenser 1
PackPhysical::Operator
-BillCount : int = 500
+GetInput() : int -atm : ATM +DispenseCash(in amount : double) : void
+SwitchOn() : bool 1
+IsSufficientCashAvailable(in amount : double) : bool 0..1
+SwitchOff() : bool
0..1
1 1
PackPhysical::Screen
PackTrans::Withdrawal
1 0..1 1
-Amount : double
1 +DisplayMessage(in message : unsigned char) 0..1
+Execute()
PackATM::ATM 0..1
PackPhysical::DepositSlot 11
-UserAuthenticat : bool 0..1 1
1 -OperationPanel() : int 1
+IsDepositEnvelopReceived() : bool +GetLog() : char Execute PackTrans::Tranasction
+CreateSession() : void
1 PackTrans::Deposit
-AccountNumber : int{ReadOnly} -amount : double
PackATM::Session 1 +Execute() +Execute()
0..1
+GetAccountNumber(in AccountNo : int) : int

+CreateSession() -access 1
AuthenticatedUser
0..1 PackTrans::BalanceEnquiry
PackBank::BankDatabase
-AccountNumber : int = 12345 +Execute()
-PIN : int = 54321
-AvailableBalance : double 1
-TotalBalance : double
+AuthenticatUser(in UserPIN : int, in AccountNo : int) : bool
+GetAvailableBal(in AccountNo : int) : double
Access / Modify Account balance
+GetTotalBal(in AccountNo : int) : double
+Credit(in AccountNo : int, in amount : double)
+Debit(in accountNo : int, in amount : double)

72 | P a g e
 Appendix D
The Traceable

73 | P a g e
Business Traceable Chart

Traceable Matrix Business to Requirement

Functional Requirement
Technical Specification
Business Requirement

Business Requirement

Architecture Design

System Component
Short Description

Design Elements

Use Case ID
Document

Priority
ID

ID
BR01 User Interface The Interface will invoke all the requirement, that Screen Interface, Sequence M FR01,FR02,FR03 UC01
(Welcome Menu) allow user to perform transaction without Bank Staff Diagram

BR02 Main Menu The Interface require to display transaction options Screen Interface, Sequence H FR04,FR05,FR06,FR07,FR08,FR09,FR10 UC01
along with the exit choice Diagram

BR03 Withdrawal System Customer will complete their withdrawal transaction Screen, ActivityWithdrawal, H FR11,FR13,FR14,FR15,FR16,FR17,FR18 UC07
keypad, Cash Collaboration-Withdrawal,
Dispenser Sequence-Withdrawal
SAD-14-01-14-1-1.0

BR04 Deposit System Customer deposit their money to the bank Screen, ActivityWithdrawal, H FR12,FR19,FR20,FR21,FR22,FR23 UC06
KeyPad, Collaboration-Withdrawal,
Deposit Slot Sequence-Withdrawal

BR05 View Balance Customer able to view their balance Screen, ActivityWithdrawal, H FR24 UC05
KeyPad Collaboration-Withdrawal,
Sequence-Withdrawal

BR06 Transaction Process to complete the transaction Screen, ActivityWithdrawal, M FR31,FR32,FR33,FR34,FR35,FR36 UC08
KeyPad Collaboration-Withdrawal,
Sequence-Withdrawal

74 | P a g e
 BR07 Session Session will hold all the information for the Internal ActivityWithdrawal, M FR37,FR38 UC04
customer during transaction Collaboration-Withdrawal,
Sequence-Withdrawal

BR08 Operation System Operator required to refill the dispenser and Operator ActivityWithdrawal, H FR39,FR40 UC03
remove envelope from the deposit slot while ATM Collaboration-Withdrawal,
switched off. Sequence-Withdrawal

BR09 Bank Bank database available for the manipulation and None ActivityWithdrawal, H FR25,FR26,FR27,FR28,FR29,FR30 UC02
required to complete authentication and bank Collaboration-Withdrawal,
account Sequence-Withdrawal

BR10 Performance Business requirement for the basics needs and Screen, ActivityWithdrawal, M FR41,FR42,FR43 UC02
check keyPad Collaboration-Withdrawal,
Sequence-Withdrawal

BR11 account Customer a person or organization that creates one or more

accounts. Only the account holder is authorized to
deposit or withdraw money from these accounts.
Only the account holder is authorized to close
these accounts.

BR12 Accounts A record of an amount of money owned by the

account's holder, but held by the bank.

Requirement Traceable Chart

Traceable Matrix Requirement to Business to Use Case to Classes

75 | P a g e
 Requirement ID
Functional

Requirement Type

Type Description
Requirement Sub-

Description
Requirement
Functional

Status

Release Number

Priority (H/M/L)

Requirement ID
Business

Use Case ID

Class ID

Test ID

Tested On

Source
Requirement

Change Request ID
FR01 Service Technical ATM initialized with t Pounds. Approve 1 M BR01 UC03 CL05 TC01 State - ATM 1.1
Introduction K, m,n are abbreviation d Transactions

FR02 Service Technical ATM should display initial Approve 1 M BR01 UC01 CL06 TC02 Sequence ATM 1.1
Introduction Welcome display. d Diagram

FR03 Service Technical If the ATM is running out of Approve 1 M BR01 CL03 TC03 State - ATM 1.1
Introduction money d Transactions

FR04 Application Functional Screen display Main message Approve 1 H BR01 UC02 CL02, TC04 Sequence ATM 1.1
and prompt to enter 5 digit d CL06, Diagram, Activity
CL09 Diagram
account number.

FR05 Application Technical If the Account number is valid Approve 1 H BR01 UC02 CL02, TC05 Sequence Bank 1.1
d CL06, Diagram, Activity
the ATM should prompt the PIN
CL09 Diagram
number.

76 | P a g e
FR06 Application Quality The Account number should be Approve 1 M BR01 UC02 CL02, TC06 Sequence Bank 1.1
logged for record tracing. d CL06, Diagram, Activity
CL09 Diagram

FR07 Application Security & Different negative answers from Approve 1 H BR01 UC02 CL02, TC07 Sequence Bank 1.1
Control
ATM while doing authorization d CL06, Diagram, Activity
CL09 Diagram
activity from the bank computer
for authorization dialog.

FR08 Application Functional If Account number and PIN number Approve 1 H BR01 UC02 CL02, TC08 StateChart Bank 1.1
are ok the authorization process is d CL06,
finished. CL09

FR09 Application Security & If the account number or PIN Approve 1 H BR01 UC02 CL02, TC09 Activity Diagram Bank 1.1
Control Number entered more than 3 times d CL06,
and each time both invalidate. A CL01
message will be displayed that the
customer should call the bank.

77 | P a g e
FR10 Service Functional After Authentication, ATM will Approve 1 M BR02 CL06 TC10 Collaboration ATM 1.1
Introduction display main menu contained 4 d Diagram
options

FR11 Service Technical ATM will check the sufficient amount Approve 1 H BR02 CL03 TC11 Component ATM 1.1
Introduction in the dispenser d Diagram,
StateDiagram

FR12 Service Functional Authorization successfully Approve 1 M BR02 CL04 TC12 Collaboration ATM 1.1
Introduction completed. Screen prompt to type d Diagram
deposit amount

FR13 Application Functional Authorization successfully Approve 1 H BR03 UC07 CL07, TC13 Activity Diagram ATM 1.1
completed. Customer inputs a menu d CL06,
(FR10) selection using Keypad. CL01,
CL03

FR14 Application Functional Customer selected Cancel option Approve 1 L BR03 UC07 CL07, TC14 Activity Diagram Custo 1.1
from the withdrawal menu. d CL06, mer
CL01,
CL03

FR15 Application Functional Customer select a choice from menu Approve 1 L BR03 UC07 CL7,C TC15 Activity Diagram Custo 1.1
(FR10) for the withdrawal d L6,CL mer
1,CL3

78 | P a g e
FR16 Application Technical Dispense slot contained greater than Approve 1 L BR03 UC07 CL7,C TC16 Activity Diagram ATM 1.1
selected withdrawal amount. d L6,CL
1,CL3

FR17 Application Technical Cash Dispense contained not Approve 1 L BR03 UC07 CL7,C TC17 Activity Diagram ATM 1.1
enough value. d L6,CL
1,CL3

FR18 Application Security & If the money is dispensed, the Approve 1 M BR03 UC07 CL7,C TC18 StateChart ATM 1.1
Control amount is logged. d L6,CL
1,CL3

FR19 Application Functional Authorization successfully Approve 1 L BR04 UC06 CL1,C TC19 Activity Diagram ATM 1.1
completed. Customer Entered the d L4,CL
amount to deposit 6,CL1
1

FR20 Application Functional Customer entered the pens amount Approve 1 M BR04 UC06 CL1,C TC20 Activity Diagram Custo 1.1
to deposit d L4,CL mer
6,CL1
1

FR21 Application Technical Deposit Slot Receive the Envelop Approve 1 L BR04 UC06 CL1,C TC21 Activity Diagram Bank 1.1
d L4,CL
6,CL1
1

FR22 Application Technical Deposit Slot Not Receive the Approve 1 L BR04 UC06 CL1,C TC22 Activity Diagram Bank 1.1
Envelop in the specific period of time d L4,CL
6,CL1
1

FR23 Application Functional The Customer choose exit from the Approve 1 M BR04 UC06 CL1,C TC23 Activity Diagram Custo 1.1
Deposit Transaction d L4,CL mer
6,CL1
1

79 | P a g e
FR24 Application Functional Process balance enquiry Approve 1 H BR05 UC05 CL1,C TC24 SequenceDiagra Bank 1.1
d L12,C m and Activity
L6 Diagram

FR25 Technical Security & If it is not a valid bank Account Approve 1 M BR09 UC07,U CL09 TC25 Collaboration Bank 1.1
Control number, the ATM will send a d C06,UC Diagram
message to the Customer 05

FR26 Technical Security & The ATM will check bank database if Approve 1 H BR09 UC07,U CL09 TC26 SequenceDiagra Bank 1.1
Control the PIN invalid. d C06,UC m and Activity
05 Diagram

FR27 Technical Security & The ATM will check bank database if Approve 1 H BR09 UC07,U CL09 TC27 SequenceDiagra Bank 1.1
Control the PIN valid. d C06,UC m and Activity
05 Diagram

FR28 Technical Security & ATM count number of wrong PIN and Approve 1 H BR09 UC07,U CL09 TC28 SequenceDiagra Bank 1.1
Control Account entries d C06,UC m and Activity
05 Diagram

80 | P a g e
FR29 Technical Technical If it is a valid Account and a valid PIN Approve 1 M BR09 UC07,U CL09 TC29 Activity Diagram Bank 1.1
but there are problems with the d C06,UC
account the ATM will send a 05
problems message

FR30 Technical Technical If it is a valid Account number, a valid Approve 1 M BR09 UC07,U CL09 TC30 Activity Diagram Bank 1.1
PIN and there are no problems with d C06,UC
the account 05

FR31 Application Functional After a request the ATM computer Approve 1 L BR06 UC08 CL10 TC31 SequenceDiagra ATM 1.1
processes the transaction d m and Activity
Diagram

FR32 Application Functional Update account after money is Approve 1 L BR06 UC08 CL10 TC32 Activity Diagram Bank 1.1
dispensed d

FR33 Application Security & ATM dispenser has a limit k for each Approve 1 M BR06 UC08 CL10 TC33 SequenceDiagra ATM 1.1
Control account about the amount of money d m and Activity
that is available via cash dispenser Diagram
each day

81 | P a g e
FR34 Application Functional If the deposit slot received the Approve 1 M BR06 UC08 CL10 TC34 Activity Diagram ATM 1.1
envelope, actually user will press OK d
button to accept

FR35 Application Technical If Successfully Execute the Approve 1 L BR06 UC08 CL10 TC35 Activity Diagram ATM 1.1
Transaction d

FR36 Application Quality If transaction has encountered with k, Approve 1 M BR07 UC04 CL08 TC36 SequenceDiagra ATM 1.1
m, n constraints abbreviation d m and Activity
Diagram

FR37 Application Technical Customer Input the identity, The Approve 1 M BR07 UC04 CL08 TC37 SequenceDiagra Custo 1.1
authentication verified by the bank d m and Activity mer
database and executing the Diagram
transaction.

FR38 Application Technical ATM session Ended or Cancelled by Approve 1 L BR07 UC04 CL08 TC38 Activity Diagram ATM 1.1
the user d

FR39 Technical Security & ATM Operator Panel turn off Approve 1 H BR08 UC03 CL02 TC39 Activity Diagram Bank 1.1
Architecture Control d

FR40 Technical Security & ATM Operator Panel turn On Approve 1 H BR08 UC03 CL02 TC40 Activity Diagram Bank 1.1
Architecture Control d

82 | P a g e
 FR41 Deploy Quality Error message should be displayed Approve 1 M BR10 CL06 TC41 Collaboration ATM 1.1
at least 30 sec d Diagram

FR42 Application Quality If there is no response from user Approve 1 M BR10 CL11 TC42 SequenceDiagra Bank 1.1
within 2 minutes the transaction d m and Activity
cancel and return to main menu Diagram
(FR02)

FR43 Application Security & The ATM dispenses money if and Approve 1 M BR10 CL10 TC43 Activity Diagram ATM 1.1
Control only if the withdrawal from the d
account is processed and verified by
the bank database.

The Traceable Matrix from Use Case to Class

Traceable Matrix Use Case to Classes

Use Case ID

Use Case Name

Description
Use Case

Requirement ID
Business

Requirement ID

Class ID

Number
Test Case

Implemented In
83 | P a g e
UC01 ATM-System- Overall ATM system Activity in one short BR01 FR01,FR02,FR03 CL01 TC01 Activity-Authenticate Diagram,
Use Case Collaboration-Authentication,
(UC01) Sequence-UserAuthenticate

UC02 User The case diagram described the very first BR09, BR10 FR04, CL02,CL06, TC01, Activity-Authenticate Diagram,
Athentication- interaction with the customer by Authentication in FR05,FR06,FR07,FR CL09 TC2,TC3,T Collaboration-Authentication,
UseCase(UC0 term of verifying Account number and PIN number 08,FR09,FR25,FR26, C4,TC5,TC Sequence-UserAuthenticate
2) from the bank database. Monitor the number of FR27,FR28,FR29,FR 6,TC7,TC8,
attempts in one. 30 TC9,TC10,
TC11,TC12

UC03 Operator An an important activity created in Use Case BR08 FR39,FR40 CL04,CL10, TC02 Diagram: State-ATM Operation
Panel-Use diagram, that the Operator panel followed by CL05
Case(UC03) Switch On and Switch Off of the ATM system in
order to System Shutdown and system Start-up.
Also Activity will take care the filling cash dispenser
and removing the envelop from the slot. The
Activity show how the account number logged in
the system for tracing. It also specify if there is any
other internal error arose by the bank account.

UC04 Session-Use The Session Use Case demonstrated the BR07 FR37,FR38 CL11,CL03, TC03 Sequence-ATM Session
Case(UC04) beginning of session activity and the ending of its CL05
session for the single user, the purpose of this
session to carry forward as many as transactions in
one session.
UC05 Balance This diagram visualised the balance enquiry activity BR05 FR24 CL12,CL06, TC04 Diagrams: Collaboration-
Enquiry-Use between customer and Bank database by ATM CL03,CL05 BalanceEnquiry, Sequence-
Case(UC05) system. BalanceEnquiry

UC06 Deposit-Use When we use transaction as deposit amount by the BR04 FR19,FR20,FR21,FR CL08,CL07, TC05 Diagrams: ActivityDeposit,
Case(UC06) customer the Use Case diagram generate its visual 22,FR23 CL03,CL05 Collaboration-Deposit, Sequence-ATM
activity starting from selection by the user and Deposit
ended by the credit this amount in the bank
account database by the ATM system. This
Diagram will also demonstrate that how the user
couldn't enter real number from the computer
keyboard as per requirement, that this keyboard
has decimple to enter.

84 | P a g e
 UC07 Withdrawal- Withdrawal Use Case is diagram is very simple BR03 FR13,FR14,FR15,FR CL08,CL09, TC06 , Collaboration-Withdrawal,
Case-Use because it has given no choice instead of selecting 16,FR17,FR18 CL03,CL05, Sequence-Withdrawal
Case(UC07) 6 chooses from the menu, therefore no more CL01
calculation and coding to protect and check the
entries. This withdrawal Usecase verify the actual
amount from the bank and from the dispenser. The
purpose of this check to make sure that account
balance and cash dispenser has sufficient amount
to pay.

UC08 ATM- The important diagram in ATM system is BR06 FR31,FR32,FR33,FR CL08,CL11, TC07 State -Transactions
Transaction- transaction, that authorised the user and its 34,FR35,FR36 CL10,CL05
Use transaction from the bank and allow or cancel the
Case(UC08) transaction.

The Traceable Matrix Class to Use Case to Requirement to Business Specification

Traceable Matrix Classes to Use Case

Class ID

Class Name

Class Description

Class Operation

Implemented On

Priority

UseCase ID

Requirement ID

Business Requirement ID
CL0 KeyPad The class operation must get input from th user. If we recall the
1 requirement that in many situation customers may enter account
number, PIN number and amounts in pens, all are indicating that Sequence Diagram, Class Model,
to enter only numeric values. We must keep in mind that the
GetInput
Collaboration
M UC01 FR02 BR01
keypad currently computer key board therefore we must take
care that user should enter ONLY numeric values.

CL0 Operator
2 Operator class will invoke the SwitchOFF and SwitchON
SwitchOn , Sequence Diagram, Class Model, FR04,FR05FR06,FR0
operation to perform technical activities by the bank staff, that
SwitchOFF Collaboration
M UC02 BR08
responsible for the refilling dispense and removing of envelope 7,FR08,FR09

85 | P a g e
CL0 CashDispens Cash Dispenser is little tricky as it has no physical existence but
3 er I use this to complete the withdrawal process and display
withdrawal amount on the screen. In the real hardware the IsSufficientAmountA FR03,FR11,FR13,FR
dispenser must send the signal to ATM that weather Dispenser vailable(amount), Sequence Diagram, Class Model, UC05,UC06,
has sufficient amount or not to dispense, to simulate this I DispenseCash(amou Collaboration
H 14,FR15,FR16,FR17, BR08
UC07
created a attribute that will perform the same attitude. The nt) FR18
tribute initializing the maximum amount for the dispenser fulfilling
the requirement.

CL0 DepositSlot
4 Deposit Slot in the real ATM system might send signal to ATM
IsDepositEnvelopRe Sequence Diagram, Class Model, FR19,FR20.FR21,FR
that slot received envelope, to simulate this operation that ATM
ceived Collaboration
H UC03 BR04
invoke to find out the envelope in the slot. 22,FR23

CL0 ATM The ATM in the real development might require more operations
5 but to simulate I created basics operations that collaborate with
the system and other classes to complete the requirements. UC03,UC05,
GetLog,
Operation 'UserAuthenticated' must satisfied the boolean to Sequence Diagram, Class Model,
invoke the user transactions and behaviour. likewise
CreateSession,
Collaboration
H UC06,UC07, FR01 BR01
OperatorPanel UC08,UC04
'CreateSession and 'OperationPanel' invoke to other subclasses
in the system. The Operation panel will work for the system
checks.

CL0 Screen All visual outputs display through the screen class only. Based
6 on requirement document the output can be various, such as
'welcome screen', 'error messages', 'thank you messages' etc. Sequence Diagram, Class Model, FR02,FR04,FR05,FR BR01,BR
the screen also use to prompt and messages. Therefore this
DisplayMessage
Collaboration
M UC05
06,FR07,FR08,FR09 03
single class will do all the prompts and messages activity
throughout the cycle.

CL0 Withdrawal The withdrawal class invoke with the amount entered by the
7 user. The execute operation that override the base class virtual
Sequence Diagram, Class Model, FR13,FR14,FR15,FR
operation Execute for their specific purpose. Like withdrawal Execute
Collaboration
H UC06 BR03
override the execute function of base class transaction for their 16,FR17,FR18
own concrete implementation.

CL0 Session
Sessions operation begin from the authentication and ended up
8 after completion of transaction or another exit /cancelation. The Sequence Diagram, Class Model, UC05,UC06,
operation logged all the activities of the user and send to ATM
CreateSession
Collaboration
M FR36,FR37,FR38 BR07
UC07,UC08
and ATM will record into the LOG.

CL0 BankDatabas AuthenticateUser(Us

9 e erPin,AccountNo),
GetAvailableBalance
Authenticate user and provide the account number to the ATM
(AccountNo),
along with their balance. Manipulate with the credits and debits
GetTotalBalance(Ac Sequence Diagram, Class Model, FR25,FR26,FR27,FR
of the account balance, sending appropriate messages to the
countNo), Collaboration
H UC02 BR09
ATM, all these operations played major role in the development 28,FR29,FR30
Credit(AcoountNo,a
cycle
mount),
Deposit(AcoountNo,
amount)

86 | P a g e
 CL1 Transaction
0 Transaction has three major operations that become derived
classes for the transaction class,to represent the financial
transaction that the ATM system perform. This is a best example
for the generalization or derives classes for the based classes.
The derived classes extract the account number from the base
class public getAccountNumber operation for the Execute, Sequence Diagram, Class Model, FR31,FR32,FR33,FR
implementation. the execute operation become pure virtual GetAccountNumber Collaboration
M UC03 BR06
34,FR35
function this make transaction an abstract class and force any
class derived from transaction that must be derived class to
implement pure virtual function. The benefit to invoke inheritance
in the system to share common interface that is virtual execute
operation from the base class 'Transaction'

CL1 Deposit Execute H UC04,UC08 BR04

1 Deposit class become a derive class for the base class
Sequence Diagram, Class Model, Fr19,Fr20,FR21,FR22
transaction, that override the execute operation of transaction
Collaboration ,FR23,Fr42
virtual execute function for their implementation.

CL1 BalanceEnqui This class become derived class to implement virtual function Execute H UC05 FR24 BR05
2 ry from the base class that perform balance view for the customer.
Sequence Diagram, Class Model,
This class required only account number to display balance
Collaboration
therefore this operation will performed by public
getAccountNumber function from the transaction base class.

87 | P a g e

View publication stats