Index

Chapter 1: Introduction .......................................................................................................3

1.1 Problem Statement:...........................................................................................................3
1.3 Scope:................................................................................................................................4
1.4 Platform Specification:......................................................................................................5
Chapter 2: System Analysis .................................................................................................6
2.1 Identification of the Need:................................................................................................6
2.2 Preliminary Investigation:.................................................................................................6
Chapter 3: Feasibility Study ............................................................................................8
3.1 Technical Feasibility:........................................................................................................8
3.2 Economical Feasibility:.....................................................................................................8
3.3 Operational Feasibility:.....................................................................................................9
Chapter 4: Technology Used ..............................................................................................10
Container getContentPane( ).....................................................12
void add(comp).........................................................................12
Chapter 5: Technical Part ..........................................................................................16
5.1 Project Standard:.............................................................................................................16
5.2 Proposed Tools:...............................................................................................................16
5.3 JAVA Sockets:................................................................................................................16
5.3.1 Definition:................................................................................................................16
5.3.2 Java Socket Classes:.................................................................................................16
5.3.3 Socket Transmission Modes:...................................................................................19
Chapter 6: Software Engineering Approach ................................................................20
6.1 Software Engineering Paradigm Applied: .............20
6.1.1 Description:..............................................................................................................20
6.1.2 Advantages and Disadvantages: .............................................................................22
6.1.3 Reasons for Use:......................................................................................................23
6.2 Requirement Analysis:........................................................................................................23
6.2.3 Requirement Elicitation:..............................................................................................24
6.3 Planning Managerial Issue:.................................................................................................27
6.3.1 Planning Scope:............................................................................................................27
6.3.2 Project Resources:........................................................................................................27
6.3.3 Team Organization:......................................................................................................28
6.3.3.1 Team Structure......................................................................................................30
6.3.4 Risk Analysis:...................................................................................................................30
6.4 Design:.................................................................................................................................35
6.4.1 Design Concepts:..........................................................................................................35
6.4.2 Dataflow Diagrams:.....................................................................................................42
6.5 Implementation Phase:........................................................................................................45
6.5.1 Language Used Characteristics:...................................................................................45
6.6. Testing:...............................................................................................................................49
6.6.1 Testing Objectives:.......................................................................................................49
8.1 Limitation of the Project:................................................................................................68
8.2 Difficulties Encountered:................................................................................................69

1
8.3 Future Enhancement Suggestion:...................................................................................69
9.1 Reference Books:............................................................................................................71
9.2 Other Documentations and resources:............................................................................71

2
Chapter 1: Introduction..................................................................................
...........................................................................................................................
...........................................................................................................................
...........................................................................................................................

1.1 Problem Statement:

The goal of this design is provide an interface which allows the controlling
authority to remotely configure the system and to be accessible by a wide
range of people. The interaction provides direct manipulation and natural
language interfaces. Input will be in the form of a graphical user interface.
Output will be from high resolution graphics, and printed forms. The
representation of information will be textual with iconic augmentation.
Because of safety and privacy concerns the system will be put in fixed
locations inside enclosures which will limit the interaction to one person at a
time.
The primary goal of developing such software is to develop software so
that consumer can access a bank’s computer and carry out their own financial
transactions without the mediation of a bank employee.

 Who is the application for?

A number of companies provide ATM products. Consequently, only a

vendor or a large financial company could possibly justify the cost and effort
of building ATM software. A small vendor would need some special feature
to differentiate itself from the crowd and attract attention. Though this
software fully implement the functionally of the ATM that is available in the

3
market today, but largely it includes all the essential features that an ATM
software must have.

 What problem will it solve?

The ATM software is intended to serve both bank and customer. For the
bank, ATM software increases automation and reduces manual handling of
routine paperwork. For the customer the ATM is ubiquitous and always
available, handling routine transactions whenever and whenever the customer
desires.

 Where will it be used?

ATM software has become essential to financial institutions. Customers

take it for granted that a bank will have an ATM machine. ATM machines are
available at many stores, sporting events, colleges and other locations
throughout the world.
 How will it work?

We will adopt a three-tier architecture to separate the user interface

from programming language, and programming language from the database.
In reality the architecture is n-tier architecture, because there can be any
number of programming language communicating with each other.

1.3 Scope:
Any software development effort is a financial institutions. From an
economic perspective, it is desirable to minimize the investment, maximize

4
the revenue, and realize revenue as soon as possible. The domains of the
software are the financial institutions. Customer takes it for granted that a
bank will have an ATM machine. ATM machine are available at many stores,
sporting events, colleges and other locations throughout the world.

1.4 Platform Specification:

1.4.1 Hardware:

 CPU (to control the user interface and transaction devices)

 Magnetic and/or Chip card reader (to identify the customer)
 A Key-Board to provide input for the system
 Display (used by the customer for performing the transaction)

1.4.2 Software:

 Windows–XP.
 Application tool – Java Development Kit.

1.4.3 Implementation Language:

JAVA 2

5
Chapter 2: System Analysis

2.1 Identification of the Need:

The requirement of this project comes when End-Users want to

fetch money from his/her existing bank account. Thus using a right technique
or approach will not only help the user in terms of time, but will also get the
correct information. Using an ATM, customers can access their
bank accounts in order to make cash withdrawals, credit card cash advances,
and check their account balances as well as purchase prepaid cell phone
credit. If the currency being withdrawn from the ATM is different from that
which the bank account is denominated in (e.g.: Withdrawing Japanese Yen
from a bank account containing US Dollars), the money will be converted at a
wholesale exchange rate. Thus, ATMs often provide the best possible
exchange rate for foreign travelers and are heavily used for this purpose as
well.

2.2 Preliminary Investigation:

There are 1.5 million ATMs deployed around the world today and this
figure is forecast to reach 2 million by 2011 according to Retail Banking
Research. With 63% of all bank customer transactions taking place via the
ATM, the ATM is one of the most fundamental and important of all channels
for customers. It is time that ATMs evolve from being simply a mechanism
for cash withdrawal to become an integral part of the customer’s

6
communication with the bank. In order to minimize costs and to ensure that
the ATM channel remains self sufficient, it is becoming increasingly
important to offer a broader transaction set via the ATM. With the advent of
new Windows based software combined with any ATM hardware, banks can
now offer revenue generating facilities such as mobile top-up and bill
payment as well as provide a vehicle for targeted third party and own products
and services advertising.

7
Chapter 3: Feasibility Study

3.1 Technical Feasibility:

All projects are feasible, given unlimited resources and infinite time.
Unfortunately, the development of a computer based system or product is
more likely suffered by a scarcity of resources and difficult delivery dates. It
is both necessary and prudent to evaluate the feasibility of a project at the
earliest possible time. However during the development of our project we
concentrate on the following feasibility:

Resource Availability:

Are the hardware and software resources required available to develop

the application?
Technology:

Has the relevant technology progressed to the stage that will support the
system?

3.2 Economical Feasibility:

Economic justification is “bottom – line “consideration for most

system. Economic justification includes a broad range of concern that includes
cost-benefit analysis, long term corporate income strategies, and cost of
resources needed for development. As far as monetary matters are concerned

8
we need hard disk space of 2GB and a Pentium processor. These are only
requirements, which can be easily met.

3.3 Operational Feasibility:

Operational feasibility is mainly concerned with issues like whether the

system will be used if it is developed and implemented. Whether there will be
resistance from users that will affect the possible application benefits?

The answer to these questions is:

Yes, as the system is developed for the convenience of the network
administrator who is the main user of the system.
A block diagram of a generalized ATM System is shown below.

9
Chapter 4: Technology Used

Socket programming in JAVA. We have used JAVA Programming

Language and the kit used is JDK.
JAVA is a platform independent language, which is the biggest benefit
of using it. JAVA does not use pointer because pointer are security loophole.
Applet is a special type of JAVA program that has been used to implement the
system. It provides better security .It is portable and provide high
performance.
Our project has been completely coded in JAVA, one of the most
powerful programming languages. Java is an Object-Oriented Programming
Language developed by Sun Microsystems that plays to the strength of the
Internet. Object-Oriented Programming (OOP) is an unusual, but powerful
way to develop software. In OOP, a computer program is considered to be a
group of objects that interact with each other.
Java is also related to C++, which is a direct descendent of C. java
derives its syntax from C and many of its object oriented features are
influenced by C++.
Another design decision to make Java simpler is its elementary data
types and objects. The language enforces very strict rules regarding
variables--in almost all cases, you have to use variables as the data type they
were declared to be, or use explicit casts to manipulate them. This
arrangement permits mistakes in variable use to be caught when the program
is compiled, rather than letting them creep into a running program where
they're harder to find. As a result, programs behave in a more predictable
manner.

10
 “Java is just a small, simple, safe, object-oriented, interpreted or
dynamically optimized, byte-coded, architecture-neutral, garbage-collected,
multithreaded programming language with a strongly typed exception-
handling mechanism for writing distributed, dynamically extensible
programs.”
A Java program is created as a text file with the file extension .java. It is
compiled into one or more files of byte codes with the extension .class. Byte
codes are a set of instructions similar to the machine code instructions created
when a computer program is compiled. The difference is that machine code
must run on the computer system it was compiled for; byte codes can run on
any computer system equipped to handle Java programs.
Java Development Kit (JDK):
When the Java programming language was introduced in 1995, the only
development tool available was the Java Development Kit (JDK) from Sun.
This set of command-line tools makes it possible to write, compile, and debug
Java programs (among other things). However, the JDK is a far cry from
integrated development environments such as Visual Basic and Borland C++.
An integrated development environment (IDE) is software that combines
several development tools into a single, cohesive package. The assortment
usually includes a source code editor, compiler, debugger, and other utilities.
These tools work together through the development process; most packages
are highly visual and rely on windows, drag-and-drop, and other graphical
elements. The goal is to make software design faster, more efficient, and
easier to debug.

Following is a list of the main components of the JDK:

11
  Runtime interpreter
 Compiler
 Applet viewer
 Debugger
 Class file dissembler
 Header and stub file generator
 Documentation generator
 Archive
 Digital signer
 Remote Method Invocation tools
 Sample demos and source code
 API source code

Exploring Swing:
The Swing-related classes are contained in javax.swing. Many other Swing-
related components exist such as:
JApplet:
Fundamental to Swing is the JApplet class, which extends Applet.
For adding a component to an instance of JApplet one can call add ( ) for
the content pane of the JApplet object. The content pane can be obtained via
the method shown here:

Container getContentPane( )
The add( ) method of Container can be used to add a component to a content
pane. Its form is shown here:

void add(comp)

12
Here, comp is the component to be added to the content pane.
Text Fields:
The Swing text field is encapsulated by the JTextComponent class, which
extends JComponent. It provides functionality that is common to Swing text
components. One of its subclasses is JTextField, which allows you to edit one
line of text.
Buttons:
Swing buttons provide features that are not found in the Button class defined
by the AWT. Swing buttons are subclasses of the AbstractButton class,
which extends JComponent. AbstractButton contains many methods that
allow you to control the behavior of buttons, check boxes, and radio buttons.
The JButton Class
The JButton class provides the functionality of a push button. JButton allows
an icon, a string, or both to be associated with the push button. Some of its
constructors are shown as:
JButton(Icon i)
JButton(String s)
JButton(String s, Icon i)
Here, s and i are the string and icon used for the button.
Check Boxes:
The JCheckBox class, which provides the functionality of a check box, is a
concrete implementation of AbstractButton. Its immediate superclass is
JToggleButton, which provides support for two-state buttons. Some of its
constructors are shown here:
JCheckBox(Icon i)
JCheckBox(Icon i, boolean state)
JCheckBox(String s)

13
JCheckBox(String s, boolean state)
JCheckBox(String s, Icon i)
JCheckBox(String s, Icon i, boolean state)
Here, i is the icon for the button. The text is specified by s. If state is true, the
check box is initially selected. Otherwise, it is not.
The state of the check box can be changed via the following method:
void setSelected(boolean state)
Here, state is true if the check box should be checked.
Combo Boxes:
Swing provides a combo box (a combination of a text field and a drop-down
list) through the JComboBox class, which extends JComponent. A combo
box normally displays one entry. However, it can also display a drop-down
list that allows a user to select a different entry. You can also type your
selection into the text field. Two of JComboBox’s constructors are shown
here:
JComboBox( )
JComboBox(Vector v)
Here, v is a vector that initializes the combo box.
Items are added to the list of choices via the addItem( ) method, whose
signature is shown here:
void addItem(Object obj)
Here, obj is the object to be added to the combo box.
Tables:
A table is a component that displays rows and columns of data. You can drag
the cursor on column boundaries to resize columns. You can also drag a
column to a new position. Tables are implemented by the JTable class, which
extends JComponent. One of its constructors is shown as:

14
JTable(Object data[ ][ ], Object colHeads[ ])
Here, data is a two-dimensional array of the information to be presented, and
colHeads is a one-dimensional array with the column headings.
Here are the steps for using a table in an applet:
1. Create a JTable object.
2. Create a JScrollPane object. (The arguments to the constructor specify the
table and the policies for vertical and horizontal scroll bars.)
3. Add the table to the scroll pane.
4. Add the scroll pane to the content pane of the applet.

15
Chapter 5: Technical Part

The technical description of a project is specified in terms of the

following:

5.1 Project Standard:

Project standard defines the kind or type of the project. Our project is
application software.

5.2 Proposed Tools:

We will be making use of JAVA programming language as a software
tools for the development of the application.

5.3 JAVA Sockets:

5.3.1 Definition:
A socket is one endpoint of a two-way communication link between
two programs running on the network. A socket is bound to a port number so
that the TCP layer can identify the application that data is destined to be sent.

5.3.2 Java Socket Classes:

The Socket class has been defined in java.net package. Java supports
two types of Socket communication.
 TCP (Transmission Control Protocol) Sockets
 UDP (User Datagram Protocol) Sockets
A Socket is a logical software construct. Each Socket is associated with
a particular port number. A port is not a physical entity like a place but it is
logical thing. From a particular port number we can transmit and receive
information. The lower port numbers are reserved for some particular services

16
like SMTP (Simple Mail Transfer Protocol) runs on port number 25, HTTP
(Hyper Text Transfer Protocol) on port number 80. Therefore generally a port
number greater than 2000 is chosen to avoid conflicts. Anything that
understands the standard protocol can plug into the socket and can
communicate. Both TCP/IP and UDP Sockets can be created.
TCP/IP Sockets are used to implement reliable, bi-directional,
persistent, point-to-point, stream based connections between hosts. A Socket
can be used to connect two Java’s I/O system to other programs that may
reside on local or remote machine.
Java has two types of Sockets.
 Server Socket: For Server

 Socket: For Client

The Socket class is designed to connect to the server sockets. The

creation of the Socket object implicitly establishes a connection between
client and server.

Normally, a server runs on a specific computer and has a socket that is

bound to a specific port number. The server just waits, listening to the socket
for a client to make a connection request.

On the client-side: The client knows the hostname (IP address) of the
machine on which the server is running and the port number on which the
server is listening. To make a connection request, the client tries to make
contact with the server on the server's machine and port. The client also needs
to identify itself to the server so it binds to a local port number that it will use
during this connection. This is usually assigned by the system.

17
 If everything goes well, the server accepts the connection. Upon
acceptance, the server gets a new socket bound to the same local port and also
has its remote endpoint set to the address and port of the client. It needs a new
socket so that it can continue to listen to the original socket for connection
requests while tending to the needs of the connected client.

On the client side, if the connection is accepted, a socket is successfully

created and the client can use the socket to communicate with the server.
The client and server can now communicate by writing to or reading
from their sockets.
Therefore we can say that “A socket is one endpoint of a two-way
communication link between two programs running on the network. A socket
is bound to a port number so that the TCP layer can identify the application
that data is destined to be sent.”

An endpoint is a combination of an IP address and a port number.

Every TCP connection can be uniquely identified by its two endpoints. That
way we can have multiple connections between your host and the server. The
java.net package in the Java platform provides a class “Socket” that

18
implements one side of a two-way connection between one Java program and
another program on the network. The Socket class sits on top of a platform-
dependent implementation, hiding the details of any particular system from
our Java program. By using the java.net.Socket class instead of relying on
native code, your Java programs can communicate over the network in a
platform-independent fashion. Additionally, java.net includes the
ServerSocket class, which implements a socket that servers can use to listen
for and accept connections to clients.

5.3.3 Socket Transmission Modes:

Sockets have two major modes of operation: connection-oriented and

connectionless modes. Connection-oriented sockets operate like a telephone:
they must establish a connection and then hang up. Everything that flows
between these two events arrive in the same order it was sent. Connectionless
sockets operate like the mail: delivery is not guaranteed, and multiple pieces
of mail may arrive in a different order than they were sent.

The mode we use is determined by an application's needs. If reliability

is important, connection-oriented operation is better. File servers must have all
their data arrive correctly and in sequence. If some data is lost, the server's
usefulness is invalidated.

Connectionless operation uses the User Datagram Protocol (UDP). A

datagram is a self-contained unit that has all the information needed to attempt
its delivery. Think of it as an envelope-it has a destination and return address
on the outside and contains the data to be sent on the inside. A socket in this

19
mode does not have to connect to a destination socket; it simply sends the
datagram. The UDP protocol promises only to make a best-effort delivery
attempt. Connectionless operation is fast and efficient, but not guaranteed.

Connection-oriented operation uses the Transport Control Protocol

(TCP). A socket in this mode must connect to the destination before sending
data. Once connected, the sockets are accessed using a streams interface:
open-read-write-close. Everything sent by one socket is received by the other
end of the connection in exactly the same order it was sent. Connection-
oriented operation is less efficient than connectionless operation, but it's
guaranteed.

Chapter 6: Software Engineering Approach

6.1 Software Engineering Paradigm Applied:

6.1.1 Description:

20
 Software Engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and works
efficiently. It is a layered technology. The bedrock that supports software
engineering is a quality focus. Software engineering encompasses a process
management technical methods and tools.
The foundation for software engineering is the process layer. Process
defines a framework for a set of key process areas. Software engineering
methods provide the technical how-to for building software. Software
engineering tools provided automated or semi automated support for the
process and the methods.

Incremental Model:

Incremental model combines elements of the linear sequential model

with the iterative philosophy of prototyping. The incremental model applies
linear sequences in a staggered fashion as calendar time progresses. Each
linear sequence produces a deliverable increment of the software. In our
project we intend to use this Linear Sequential Model (Waterfall Model)
because our project Task modules are dependent closely on each other.
Therefore if we try our hands on a Concurrent Model then the complexity in
its implementation could make the conditions worse. We require completing
one task at a time so as to pave the way for other task to begin. Such high
degree of dependency makes the condition ideal for using the Incremental
Model. Implementing this model in this project heightens the efficiency of the
system and yet maintains the complexity under control.

21
 Fig. Showing the Incremental Model

6.1.2 Advantages and Disadvantages:

Advantages:

 Early increments can be developed with few people.

 Increments can be planned to manage technical risks.
 Deadlines can be managed in an effective manner.

Disadvantages:

 Reusability of codes among the modules is minimum.

 Integration testing is difficult to do.

22
6.1.3 Reasons for Use:

The project can be created through a series of delivery steps with each
delivery steps adding a new feature to the existing product. Thus the process
model suited to the project is Incremental Model. It combines elements of the
Linear Sequential model with the interactive philosophy of prototyping.

Our project demanded to be on time so this model helped us in the right

way. Such an approach does not call for many people working on the initial
increments so it served us right. And such increments were very well planned
with minimized set of technical risks coming our way.

6.2 Requirement Analysis:

Requirements are a feature of a system or description of something that

the system is capable of doing in order to fulfill the system’s purpose. It
provides the appropriate mechanism for understanding what the customer
wants, analyzing the needs, assessing feasibility, negotiating a reasonable
solution unambiguously, validating the specification and managing the
requirements as they are translated into an operational system.
The requirement analysis founded a base on the new Information
System that is to be implemented and provided the guidelines to move further
on developing this project.
6.2.1 Functional Requirements
The functional requirements are organized in two sections; Requirements of
the ATM and Requirements of the bank computer.
∗ Requirements of the ATM

23
− authorization process
− transaction (withdrawal process)
∗ Requirements of the bank computer
− authorization process (bank code and password)
− transaction
6.2.2 Non-functional Requirements
The non-functional requirement is bellowed.
∗ The ATM network has to be available 24 hours a day.
∗ Each bank may be processing transactions from several ATMs at the same
time.
∗ The ATM must be able to use several data formats according to the data
formats that are provided by the database of different banks.

6.2.3 Requirement Elicitation:

Acknowledgement: A response sent by the receiver to indicate the
successful receipt and acceptance of data.
Broadcasting: Transmission of a message to all nodes in a network.
Buffer: Memory set aside for temporary storage.
Class: A template for creating objects. A class defines data and methods
and is a unit of organization in a Java program. It can pass on its public data
and methods to its subclasses.
Client: A program that initiates communication with another program
called the server.

24
 Client Server Model: The model of interaction between two application
programs in which a program at one end (client) request a service from a
program at the other end (server).
Guided Media: Transmission media with a physical boundary.
IP address: A 32bit address used to uniquely define a host on an
Internet.
Java: An object-oriented programming language for creating
distributed, executable applications
Local Area Network (LAN): A network connecting devices inside a
single building or inside buildings close to each other.
Mbps: Mega bits per second.
Message: A message is the content of the communication between 2
processes.
Method: A function that can perform operations on data.
Model: A model is a representation of the system.
Network Interface Card (NIC): An electronic device, internal or
external to a station that contains circuitry to enable a station to be connected
to the network.
Object: A variable defined as being a particular class type. An object
has the data and methods as specified in the class definition.
Operation: An operation is a function that can be performed on an
object.
Port: A number used to identify TCP/IP applications. Generally a port
is an entry or exit point.
Process: It is an operating system concept that captures the idea of a
program in execution. A process is always executing at some points in a
program.

25
 Processor: It is the part of a computer system that executes instructions.
It is also called a CPU.
Robot: A term for software programs that automatically explore the
Web for a variety of purposes. Robots that collect resources for later database
queries by users are sometimes called spiders.
Server: A program that can provide services to other programs, clients.
Socket: In TCP/IP, an addressable point that consists of an IP address
and a TCP or UDP port number that provides applications with access to
TCP/IP protocols.

Socket Address: The complete designation of a TCP/IP node consisting

of a 32-bit IP address and a 16-bit port number.
TCP/IP (Transmission Control Protocol/Internet Protocol): The set of
protocols used for network communication on the Internet.
Thread: A thread is software object that can be dispatched and executes
in an address space.
Throughput: The number of bits that can pass through a point in one
second.
Topology: A structure of network including physical arrangement of
devices.
User: a user is person who is using a computer system by running
processes on it.
Performance:

While deciding the performance of any software, its speed, response

time, throughput, resource utilization & efficiency must be taken into
consideration.

26
Reliability:
The reliability is the mean time to failure, accordingly the to have
higher reliability the mean time to failure should be very large. This software
provides relevant results and these results would be quick. As far as recovery
is concerned, it provides reliable and consistent recovery of complete file.
Supportability:
This software is supportable on Windows XP Platform and all others
which JAVA Framework.
Usability:
The software can be used to provide various services of the ATM
systems that are used by the banks and any other financial institutions. It can
be used as a computerized telecommunications device that provides
the clients of a financial institution with access to financial transactions in a
public space without the need for a cashier, human clerk or bank teller.

6.3 Planning Managerial Issue:

6.3.1 Planning Scope:

Project planning describes the data and control to be preceding
function, performance, constraints, interfaces and reliability. Functions
described in the statement of scope are evaluated and in some cases refined to
provide more detail prior to the beginning of estimation.

6.3.2 Project Resources:

1. Human Requirements:
The human requirements for the software refer to the number of
persons required for developing, using, and maintaining the product. The

27
 minimum human requirement for our project is 1. However, our team for
the project development consists of 4 members. However, for using and
maintaining the software, one person would suffice.

2. Hardware Requirement:

Our software can work on a system with minimum hardware

configuration. Each system can even be a 450 MHz processor. A 96MB &
128 MB RAM would also suffice.

3. Software Requirement:

The application is platform independent. So it can run on Windows XP.

It does not require any other software than JDK 1.4 to run.

4. Skills possessed by developers:

The developers of this software should be well versed with Java

language.

5. Time:

The stipulated time for the development of the application was 4-5
months.

6.3.3 Team Organization:

There are basically four types of project teams namely:-

28
 1. Democratic Decentralized (DD)
2. Controlled Decentralized (CD)
3. Controlled Centralized (CC)
4. Democratic Decentralized (DD)

Democratic Decentralized (DD)

The team structure can be specified as The team working to build this
software comprises of three members under the guidance of a project guide.
Our software engineering team has no permanent leader. Rather, “task
coordinators are appointed for short durations and then replaced by others
who may coordinate different tasks”. Decisions on problems and approach are
made by group consensus and are taken democratically. Communication
among team members is horizontal.

Controlled Decentralized (CD)

In CD organization there is a defined leader. Leader co-operate specific
task. Secondary leader perform sub-task Problem solving is group activity.
Communication between team members is horizontal or vertical.

Controlled Centralized (CC)

In CC organization there is a defined leader. Top level is problem-
solving team. Team leader manages every thing. Communication between
team members is vertical.

29
6.3.3.1 Team Structure

The software team for our project is a Democratic Decentralized (DD)

team. The salient features of our team are:
1. There is no permanent leader of the team.
2. The decision making process is a team activity.
3. The communication between the team members is horizontal.

6.3.4 Risk Analysis:

Risk Identification and Types:

A risk is any unfavorable event or circumstance that can occur while a

project is underway. If a risk becomes true, it can hamper the successful and
timely completion of a project. Therefore, it is necessary to anticipate and
identify different risks that a project is susceptible to. Risk management aims
at dealing with all kind of risks that might affect a project.

30
Type of risks:
Project risk:
Project risks threaten the project plan.
For example: If a project risk occurs in reality, then it is likely that the project
schedule will slip and that the cost will increase.
Project risk identify potential budgetary, schedule, personnel, resource,
customer and requirements problems and their impact on software project.

The project risk in our application id that due to sudden illness of a

team member, the schedule may be affected and all the requirements may not
be met practically.

Technical risk:
Technical risk threatens the quality and timeliness of the software to be
produced. A technical risk makes implementation difficult or at times,
impossible. Technical risk identifies the potential design, implementation,
interfacing, maintaining and verification problems.

The technical risk of our project includes that it may be difficult to

represent a full length on a single screen and how to implement the difficulty
level concept.

Business risk:
Business risk threatens the viability of the software to me built.
Business risk often jeopardizes the product or project. This risk occurs when a
product or a system is built correctly but it is not wanted in the market (known
as market risk) .or when a product is built without keeping the overall

31
business strategy of the company in mind (known as strategic risk), or when a
product does not fetch the price in the market it is expected to (known sell
risk), or the tem members do not work cohesively towards completing the
product (management risk), or when the cost of the product exceeds the
budgetary allocation (known as budget risk) .
The business risk in our project in our project lies in the fact that it may
not be required as it may not give that feel of the preparation or a better
application by other professionals might have been developed.

Known risk:
Known risk is risks that are previously known to the developers. These
risks include t he delays related to the delivery date of the project. The known
risk of our project is that it may not be submitted on desired date.

Predictable risk:
Predictable risk are risks that can be foretold based on experience
gained in developing past project, Or in developing previous segments gained
in developing past projects, or in developing previous segments of the current
project. For example a risk ignored in the analysis phase is likely to cause a
risk in the design phase.

In our project test generation module can pose a few problems as to

decide an equal distribution of different types of questions and to decide the
next test.

Unpredictable risk:

32
 Unpredictable risks are undesirable events that occur unexpectedly.
This type of risk covers such situations like the one where the user changes his
requirement during the development of the project.

The unpredictable risk which may exist is the formatting issue related to
the display of the test.

Risk Projection Table:

A risk table is a technique for Risk Projection. Risk Projection is an

attempt to delineate the effects of risk based on two factors – the probability
that the risk is real, and the consequences associated with the occurrence of
the risk, should the risk occur.

S. Risk
No. Risk Category Probability Impact Exposure
Application designed
1 becomes outdated BI 40% 2 0.8
2 Inexperienced Developers SE 60% 2 1.2
3 Delivery Date tightened BI 50% 2 1
4 Cost Exceeds Budget BI 25% 3 0.75
5 Change in Requirement PS 10% 4 0.4
Technology will not meet
6 expectations TE 60% 1 0.6
Design Problems and
7 Bugs SE 20% 2 0.4
8 Insufficient Time for TE 20% 2 0.4

33
 Testing
9 Lack of Training on Tools DE 80% 2 1.6

Legend used in risk projection table

BI = Business Impact
SE = Staff Size and Experience
PS = Product Size
TE = Technology to be built
DE = Development Environment

Risk Impact categories:

 Catastrophe
 Critical
 Marginal
 Negligible
Risk Prioritization:

Based on the impact of the individual risks, we can prioritize them in

the order of their removal as follows
Decreasing Priority

Design does not meet requirements.

 Size of Project becomes large.

34
  Delivery Deadline will be tightened.
 Insufficient Time for Testing
 Larger Number Of user than Planned.
 Customer changes the requirements.
 Lack of Training on Development Tools.
 Technology does not meet requirements.
 End users resist system.
 Project Loss due to Hard Disk Failure.

Project specific risks:

 Unformatted image can be sent by the client machine causes the

server could not align the image of different client machine.
 The network connection can not be maintained.
 Due to load server machine may go done.
 The network may not respond well under load.

6.4 Design:

6.4.1 Design Concepts:

A set of fundamental software design concepts has evolved over the

past three decades. Each provides the software designer with a foundation
from which more sophisticated design methods can be applied.

A short description of the various design concepts is presented below:

35
Abstraction:

There are three types of abstractions that are generally encountered:

Procedural Abstractions:

A procedural abstraction is a named sequence of instruction that has a

specific and limited function. There are three levels of procedural abstraction,
they are:

1. Higher Level:

To provide the security services to the Clients when they connect to the
outside network. To accomplish this task we restrict the unauthorized access
of different clients.

2. Middle Level:

We provide security services by different techniques such as

authentication, administration, usage auditing etc. in our project.

3. Lower Level:

We have different modules to provide the security to the clients. The

different modules of our project are Basic services module, Security Services

36
module, Identification Services module, Administration Services module,
Usage Accounting Services module, Caching module.

Data abstraction:

1. Higher Level:
The packets are flowing between proxy server and client and vice
versa.

2. Lower Level:
The data flowing through different modules are IP addresses of
different Machines, Login, Log-off time, services requested and response
provided.

Refinement:

Software refinement is a top-down design strategy originally proposed by

Niklaus Writh. A hierarchy is developed by decomposing a macroscopic
statement of function (a procedural abstraction) in a step-wise fashion until
programming language statements are reached.
Refinement is actually a process of elaboration. Refinement causes the
designer to elaborate on the original statement, providing more and more
detail as each successive refinement (elaboration) occurs.

Modularity:

37
Software architecture embodies modularity; that is, software is divided into
separately named and addressable components called modules that are
integrated to satisfy problem requirements. Modularization reduces the effort
and complexity of the problem, hence it should be followed, but care should
be taken to avoid under modularity or over modularity.

Design Techniques:

 Bottom up Design
 Top-Down Design
 Hybrid Design

1. Bottom up Design:

This approach lead to a style of design where we decide how to combine

lower level modules to provide larger ones; to combine those to provide even
larger ones, and so on, till we arrive at one big module which is whole of the
desired program.

Since the design progress from bottom layer upwards, the method is called
bottom up design. The main argument for this design is that if we start coding
a module soon after its design, the chances of recoding is high; but the coded
module can be tested and design can be validated sooner than module whose
sub modules have not yet been designed .The limitation of this design is that

38
we need to use a lot of intuitions to decide exactly what functionality a
module should provide.

If we get it wrong, then at higher level, we will find it is not as per

requirement; than we have to redesign at a lower level. If a system is to be
build from an existing system this approach is more suitable, as it starts from
some existing modules.

39
2. Top-Down Design:

A top-down design approach starts by identifying the major modules of the

system, decomposing them into there lower level modules and iterating until
the desired level of details is achieved. This is stepwise refinement; starting
from an abstract design, in each step the design is refined to a more concrete
level, until we reach a level when no more refinement is required and the
design can be implemented directly.

Most design methodologies are based on this approach and this is suitable, if
the specification is clear and development is from scratch. If coding of a part
start soon after design, nothing can be tested until all its subordinate modules
are coded.

40
3. Hybrid Design:

Pure top-down and pure bottom-up approaches are often not practical. For a
bottom up approach to be successful, we must have a good notion of the top at
which the design should be heading.

Without a good idea about the operations needed at the higher layers, it is
difficult to determine what operations the current layers should support.

For top-down approach to be effective, some bottom up approach is essential

for the following reasons:

41
  To permit common sub modules.
 Near the bottom of the hierarchy, where the intuitions is simpler, and
the need for the bottom-up testing is greater.
 In the use of pre-written library modules, in particular, reuse of
modules.

6.4.2 Dataflow Diagrams:

As in our project no database is used therefore there is no Entity/Relationship

Diagram, Control Flow Diagram, State Transition Diagram and dataflow
diagram except that the data is flowed across the LAN using TCP/IP protocol.

42
43
44
6.5 Implementation Phase:

6.5.1 Language Used Characteristics:

The main features of Java which makes it such a widely used language
across the globe are described as follows:

Java Is Small and Simple:

However, Java has been described as "C++ minus" because of elements

of C++ that were omitted. The most complex parts of C++ were excluded
from Java, such as pointers and memory management. These elements are
complicated to use, and are thus easy to use incorrectly. Finding a pointer
error in a large program is an experience not unlike searching for the one-
armed man who framed you for murder. Memory management occurs
automatically in Java--programmers do not have to write their own garbage-
collection routines to free up memory.

Another design decision to make Java simpler is its elementary data

types and objects. The language enforces very strict rules regarding
variables--in almost all cases, you have to use variables as the data type they

45
were declared to be, or use explicit casts to manipulate them. This
arrangement permits mistakes in variable use to be caught when the program
is compiled, rather than letting them creep into a running program where
they're harder to find. As a result, programs behave in a more predictable
manner.

Java Is Object Oriented:

Object-oriented programming (OOP) is a powerful way of organizing

and developing software. The short-form description of OOP is that it
organizes a program as a set of components called objects. These objects exist
independently of each other, and they have rules for communicating with
other objects and for telling those objects to do things. Think back to how
Star7 devices were developed as a group of independent devices with methods
for communicating with each other. Object-oriented programming is highly
compatible with what the Green project was created to do and, by extension,
for Java as well.

Java inherits its object-oriented concepts from C++ and other languages
such as Smalltalk. The fact that a programming language is object oriented
may not seem like a benefit to some. Object-oriented programming can be an
intimidating subject to tackle, even if you have some experience programming
with other languages. However, object-oriented programs are more adaptable
for use in other projects, easier to understand, and more bug proof. The Java

46
language includes a set of class libraries that provide basic variable types,
system input and output capabilities, and other functions. It also includes
classes to support networking, Internet protocols, and graphical user interface
functions.

Java Is Safe:

Another thing essential to Java's success is that it is safe. The original

reason for Java to execute reliably was that people expect their waffle irons
not to kill them or to exhibit any other unreliable behavior. This emphasis on
security was well-suited for Java's adaptation to the World Wide Web.

Java provides security on several different levels. First, the language

was designed to make it extremely difficult to execute damaging code. The
elimination of pointers is a big step in this regard. Pointers are a powerful
feature, as the programmers of C-like languages can attest, but pointers can be
used to forge access to parts of a program where access is not allowed, and to
access areas in memory that are supposed to be unalterable. By eliminating all
pointers except for a limited form of references to objects, Java is a much
more secure language.

Another level of security is the byte code verifier. Before a Java

program is run, a verifier checks each byte code to make sure that nothing
suspicious is going on.

In addition to these measures, Java has several safeguards that apply to

applets. To prevent a program from committing random acts of violence

47
against a user's disk drives, an applet cannot, by default, open, read, or write
files on the user's system.

Java Is Platform Independent:

Platform independence is another way of saying that Java is

architecture neutral. If both terms leave you saying "huh?" they basically
mean that Java programs don't care what system they're running on.

Most computer software is developed for a specific operating system.

Platform independence is the capability of the same program to work on
different operating systems; Java is completely platform independent. A
Java .class file of byte code instructions can execute on any platform without
alteration.

Java is Architecture-Neutral:

The Java designers made several hard decisions in the Java language
and the Java Virtual Machine in an attempt to alter the situation of programs
not running on the same machine after few days. Their goal was “Write once;
run anywhere, any time, forever”.

48
Java is distributed:

Java is designed for the distributed environment of the Internet, because

it handles TCP/IP protocols. The feature of inter-address-space messaging is
done with the help of the package Remote Method Invocation”. This feature
brings an unparalleled level of abstraction to the client/server programming.

Java is Dynamic:

Java programs carry with them substantial amounts of run-time type

information that is used to verify and resolve accesses to objects at run-time.
This makes it possible to dynamically link code in a safe and expedient
manner. This is crucial to the robustness of the applet environment.

Platform and tools used:

Platform is any windows operating system with JVM

6.6. Testing:

6.6.1 Testing Objectives:

Software Testing is a critical element of software quality assurance and

the ultimate review of specification, design and code generation. Testing of
the software leads to uncovering of errors in the software and reveal that
whether software’s functional and performance are met. Testing also provides
a good indication of software reliability as software quality as a whole. The

49
result of different phases are evaluated and then compared with the expected
results. If the errors are uncovered they are debugged and corrected. A
strategy approach to software testing has the generic characteristics:

 Testing begins at the module level and works outwards towards the
integration of the entire computer based system.
 Different testing techniques are appropriate at different point of time.
 Testing and debugging are different activities, but debugging must be
accommodating in the testing strategy.

A strategy for the software testing must accommodate low level test
that are necessary to verify that a small source code segment is performing
correctly according to the customers’ requirement and that of developers’
expectations.

Testing Objectives:

 Testing is the process of executing a program with the intent of finding

an error.
 A good test case is one which has a high probability of finding an as yet
undiscovered error.
 A successful test is one that uncovers an as yet undiscovered error.

Our objective is to design tests that systematically uncover different classes of

errors and to do so with minimum amount of time and effort.

50
Testing Principles:

• All tests should be traceable to customer requirements.

• Tests should be planned long before testing begins.
• The Pareto principle applies to software testing.
• Testing should begin “in the small” and progress towards testing “in the
large”.
• Exhaustive testing is not possible.
• To be most effective, testing should be conducted by an independent
third party.

6.6.2 Testing Methods and Strategies Used:

Test Case Design:

Black box testing:

This testing alludes to tests that are conducted at the software interface.
Although they are designed to uncover errors, black-box tests are used to
demonstrate that software functions are operational, that input is properly
accepted and output is correctly produced, and that the integrity of external
information is maintained. A black-box test examines the fundamental aspects
of a system with little regard for internal logical structure of the software.

51
White box testing:

White box software testing is predicated on close examination of

procedural detail. Logical paths through the software are tested by providing
the test cases that exercise specific sets of conditions or loops. The “status of
program” may be examined at various points to determine if the expected or
asserted status corresponds to the actual status.

The testing method used for the encryption and decryption in

cryptography is White box testing also called glass box testing in combination

52
with Black Box testing. White Box testing is a test case design method that
uses control structure of procedural design to derive test cases. Using the
white box testing methods, the software engineer can derive test cases that
guarantees that

 All independent paths within a dingle module have been exercised at

least once.
 Exercise all logical decisions on their true false sights.
 Execute all loops at their loops and within their operational bounds.
 Exercise internal data structures to assure their validity.

White Box Testing should not be dismissed as impractical. A limited no

of important logical parts can be and exercised. Important data structures can
be probed for their validity. It includes Basis path testing and Control
Structure testing (condition testing, data flow testing and loop testing).

Black Box testing, on the other hand focuses on the functional

requirements of the software. It enables a software engineer to derive a set of

53
input conditions that will fully exercise all functional requirements for a
program. This approach is complementary to White Box testing and is likely
to uncover a different class of errors than White Box method.

Black Box testing attempts to find errors in the following categories:

 Incorrect or missing functions.

 Interface errors.
 Errors in Data Structures or external Database access.
 Performance errors.
 Initialization and termination errors.

Unlike White Box testing, which is performed early in the testing

process, Black Box testing tends to be applied during the later stages of
testing. Attention in the black box testing is focused on the information.

54
Chapter 7: Design

7.1Use Case diagram for ATM

The use case partition the functionality of a system into a small number
of discrete units, and all system behavior must fall under some use case. Each
use case should represent a kind of service that the system provides,
something that provides value to the actor.
A particular person may be both a bank teller and the customer of
the same bank. For the ATM application, the actors are Customer and Bank.
Following figure shows the use case diagram

 Initiate Session: The ATM establishes the identity of the user and
makes available a list of accounts and actions.

55
• The ATM asks the user to insert a card.
• The user inserts a cash card.
• The ATM accepts the card and reads its serial number.
• The ATM requests the password.
• The user enters password.
• The ATM verifies the password by contacting the bank.
• The ATM displays a menu of accounts and commands.
• The user choices the command to terminate the session.
• The ATM asks the user to insert the card.

 Query Account: The system provides general data for an account such
as the current balance, date of last transactions, and date for mailing last
statement.

• The ATM displays a menu of accounts and commands.

• The user chooses to query an account.
• The ATM contacts the bank which returns the data.
• The ATM displays account data for user.
• The ATM displays a menu of accounts and commands.

 Process Transaction: The ATM performs an action that affects an

account’s balance, such as deposit, withdraw, and transfer. The ATM

56
 ensures that all completed transactions are ultimately written to the
bank’s database.

• The ATM displays a menu of accounts and commands.

• The user selects an account withdrawal.
• The ATM asks for the amount cash.
• The user enters the cash amount.
• The ATM verifies that the withdrawal satisfy its policy limits.
• The bank verifies that the account has sufficient funds.
• The ATM dispenses the cash and asks the user to take it.
• The user takes the cash.
• The ATM displays a menu of accounts and commands.
• The ATM displays a menu of accounts and commands.

 Transmit Data: The ATM uses the consortium’s facilities to

communicate with appropriate bank computers.

• The ATM requests account data from the consortium.

57
 • The consortium accepts the requests and forwards it to the appropriate
bank.
• The bank receives the requests and retrieves the desired data.
• The bank sends the data to the consortium.
• The consortium routes the data to the ATM.

7.2 Architecture of the ATM system

The ATM system is a hybrid of an interactive interface and a
transaction management system. The entry stations are interactive interfaces-
their purpose is to interact with a human to gather information needed to
formulate a transactions. Specifying the entry stations consists of constructing
a class model and a state model. The purpose is to maintain data and allow it
to be updated over a distributed network under controlled transactions.
Following fig. shows the architecture of the system.

58
 The only permanent data stores are in the bank computers. A database
ensures that data is consistent and available for concurrent access. The ATM
systems process each transaction as a single batch operation, locking an
account until the transaction is complete.
Concurrency arises because there are many ATM stations, each
of which can be active at any time. There can be only one transaction per
ATM station.
The bank computer is the only unit with only unit with any nontrivial
procedures, but even those are mostly just database updates. The only
complexity might come from failure handling. The bank computers must have
capacity to handle the expected worst-case load, and they must have enough
disk storage all transactions.
The system must contain operations for adding and deleting ATM
stations and bank computers. Each physical unit must protect itself against the

59
failure or disconnection from the rest of the network. A database protects
against loss of data. However, a special attention must be paid to failure
during a transaction so that neither the user nor the bank loses money – this
may require a complicated acknowledgement protocol before committing the
transaction.

7.3 Application State Model

The application state model focuses on application classes and
augments the domains state model. Application classes are more likely to have
important temporal behavior than domain classes.
First identify application classes with multiple states and use the
interaction model to find events for these classes. Then organize permissible
event sequence for each class with a state diagram. Next, check the state
diagrams against the class and interaction models to ensure consistency.
Following figure shows the ATM application class model.

60
7.4 ATM Simulation Transaction Interaction Diagram

An interaction diagram is an analysis tool that can be used when an object

interacts with various other objects to perform some task. One place this
occurs in the ATM Simulation is during the execution of a transaction, when
the transaction must interact with the Customer (via the ATM) to get specific
information (such as choice of account(s), amount), with the Bank, and with
various components of the ATM (e.g. cash dispenser, printer). The diagram
below is an interaction diagram for a Withdrawal Transaction.

61
7.4 Use Cases for ATM System

Flows of Events for Individual Use Cases

System Startup Use Case

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

62
System Shutdown Use Case

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

63
A session is started when a customer inserts an ATM card into the card reader
slot of the machine. The ATM pulls the card into the machine and reads it. (If
the reader cannot read the card due to improper insertion or a damaged stripe,
the card is ejected, an error screen is displayed, and the session is aborted.)
The customer is asked to enter his/her PIN, and is then allowed to perform one
or more transactions, choosing from a menu of possible types of transaction in
each case. After each transaction, the customer is asked whether he/she would
like to perform another. When the customer is through performing
transactions, the card is ejected from the machine and the session ends. If a
transaction is aborted due to too many invalid PIN entries, the session is also
aborted, with the card being retained in the machine.

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

Transaction Use Case

Note: Transaction is an abstract generalization. Each specific concrete type of

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

A transaction use case is started within a session when the customer chooses a
transaction type from a menu of options. The customer will be asked to
furnish appropriate details (e.g. account(s) involved, amount). The transaction

64
will then be sent to the bank, along with information from the customer's card
and the PIN the customer entered.

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

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

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

The customer may cancel a transaction by pressing the Cancel key as

described for each individual type of transaction below.

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

Withdrawal Transaction Use Case

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

A withdrawal transaction can be cancelled by the customer pressing the

Cancel key any time prior to choosing the dollar amount.

Deposit Transaction Use Case

A deposit transaction asks the customer to choose a type of account to deposit

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

A deposit transaction can be cancelled by the customer pressing the Cancel

key any time prior to inserting the envelope containing the deposit. The

66
transaction is automatically cancelled if the customer fails to insert the
envelope containing the deposit within a reasonable period of time after being
asked to do so.

Transfer Transaction Use Case

A transfer transaction asks the customer to choose a type of account to

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

A transfer transaction can be cancelled by the customer pressing the Cancel

key any time prior to entering a dollar amount.

Inquiry Transaction Use Case

An inquiry transaction asks the customer to choose a type of account to

inquire about from a menu of possible accounts. No further action is required
once the transaction is approved by the bank before printing the receipt.

An inquiry transaction can be cancelled by the customer pressing the Cancel

key any time prior to choosing the account to inquire about.

Invalid PIN Extension

67
An invalid PIN extension is started from within a transaction when the bank
reports that the customer's transaction is disapproved due to an invalid PIN.
The customer is required to re-enter the PIN and the original request is sent to
the bank again. If the bank now approves the transaction, or disapproves it for
some other reason, the original use case is continued; otherwise the process of
re-entering the PIN is repeated. Once the PIN is successfully re-entered, it is
used for both the current transaction and all subsequent transactions in the
session. If the customer fails three times to enter the correct PIN, the card is
permanently retained, a screen is displayed informing the customer of this and
suggesting he/she contact the bank, and the entire customer session is aborted.

If the customer presses cancel instead of re-entering a PIN, the original

transaction is cancelled.

Chapter 8: Conclusion

8.1 Limitation of the Project:

The project currently possesses some limitations such as:

68
 1. Software is restricted to work in a LAN.
2. If the server processor is slow then bottleneck problem on server occur.
3. Software works well in a LAN with star topology and in other
topologies it is restricted to some limited number of clients because of
a single link used.

8.2 Difficulties Encountered:

 Once the keyboard & mouse locked, there is no way to unlock them
except restarting the system.
 Improper money checking can cause the possibility of a customer
receiving counterfeit banknotes from an ATM.

8.3 Future Enhancement Suggestion:

Although ATMs were originally developed as just cash dispensers, they have
evolved to include many other bank-related functions. In some countries,
especially those which benefit from a fully integrated cross-bank ATM
network (e.g.: Multibanco in Portugal), ATMs include many functions which
are not directly related to the management of one's own bank account, such as:

 Deposit currency recognition, acceptance, and recycling

 Paying routine bills, fees, and taxes (utilities, phone bills, social
security, legal fees, taxes, etc.)
 Printing bank statements
 Updating passbooks
 Loading monetary value into stored value cards

69
 Purchasing
 Postage stamps.
 Lottery tickets
 Train tickets
 Concert tickets
 Movie tickets
 Shopping mall gift certificates

70
Chapter 9: Bibliography and References

9.1 Reference Books:

1. Java Complete Reference - Herbert Shildt
2. Java Network Programming – Oreilley Publications
3. Computer Network – Tanenbaum
4. Software Engineering – Roger S. Pressman

9.2 Other Documentations and resources:

1. www.java.com
2. www.sun.java.com
3. www.sitepoint.com
4. www.oreilley.com
5. www.wikipedia.com

71