Index

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

1.1 Problem Statement:................................................................................3

1.2 Objectives:.............................................................................................3

1.3 Scope:....................................................................................................4

1.4 Platform Specification:..........................................................................4

1.4.1 Hardware:.....................................................................................4

1.4.2 Software:.......................................................................................4

1.4.3 Implementation Language:...........................................................4

Chapter 2: System Analysis............................................................................5

2.1 Identification of the Need:.....................................................................5

2.2 Preliminary Investigation:.....................................................................5

Chapter 3: Feasibility Study............................................................................6

3.1 Technical Feasibility:.............................................................................6

3.2 Economical Feasibility:.........................................................................6

3.3 Operational Feasibility:.........................................................................6

Chapter 4: Technology Used:..........................................................................7

4.1 Technology Used:..................................................................................7

Chapter 5: Technical Part..............................................................................10

5.1 Project Standard:..................................................................................10

5.2 Proposed Tools:...................................................................................10

5.3 JAVA Sockets:.....................................................................................10

5.3.1 Definition:.....................................................................................10

5.3.2 Java Socket Classes:......................................................................10

5.3.3 Socket Transmission Modes:........................................................12

Chapter 6: Software Engineering Approach.................................................14

1

6.1 Software Engineering Paradigm Applied:...........................................14

6.1.1 Description:...................................................................................14

6.1.2 Advantages and Disadvantages:....................................................15

6.1.3 Reasons for Use:............................................................................15

6.2 Requirement Analysis:............................................................................16

6.2.1 Functional Requirements:................................................................16

6.2.2 Non-functional Requirements:..........................................................18

6.2.3 Requirement Elicitation:...................................................................18

6.3 Planning Managerial Issue:.....................................................................18

6.3.1 Planning Scope:................................................................................18

6.3.2 Project Resources:............................................................................19

6.3.3 Team Organization:..........................................................................19

6.3.3.1 Team Structure...........................................................................20

6.3.4 Risk Analysis:...................................................................................23

6.4 Design:....................................................................................................27

6.4.1 Design Concepts:..............................................................................27

6.4.2 Dataflow Diagrams:..........................................................................30

6.5 Implementation Phase:............................................................................30

6.5.1 Language Used Characteristics:.......................................................30

6.6. Testing:...................................................................................................33

6.6.1 Testing Objectives:...........................................................................33

6.6.2 Testing Methods and Strategies Used:.............................................34

Chapter 7: Design..........................................................................................37

7.1 Use Case diagram for ATM:...................................................................33

7.2 Architecture of the ATM system:...........................................................33

7.3 Application State Model:........................................................................33

7.4 ATM Simulation Transaction Interaction Diagram:...............................33

2

7.5 Use Cases for ATM system:...................................................................33

Chapter 8: Conclusion...................................................................................37

8.1 Limitation of the Project:.....................................................................37

8.2 Difficulties Encountered:.....................................................................37

8.3 Future Enhancement Suggestion:........................................................37

Chapter 9: Bibliography and References......................................................38

9.1 Reference Books:.................................................................................38

9.2 Other Documentations and resources:.................................................38

3

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

market today, but largely it includes all the essential features that an ATM

software must have.

4

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

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

5

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

6

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

7

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.

8

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

9

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.

10

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.

11

“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:

Runtime interpreter

12

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)

Here, comp is the component to be added to the content pane.

13

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)

JCheckBox(String s, boolean state)

14

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:

JTable(Object data[ ][ ], Object colHeads[ ])

15

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.

16

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

17

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.

18

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

19

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

20

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:

21

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.

22

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.

23

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

24

− 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.

25

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.

26

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.

27

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

28

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:-

29

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.

30

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.

31

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

32

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:

33

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.

No. Risk Category Probability Impact

Risk

Exposure

1

Application designed

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

6

Technology will not meet

expectations TE 60% 1 0.6

34

7

Design Problems and

Bugs SE 20% 2 0.4

8

Insufficient Time for

Testing TE 20% 2 0.4

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

35

Design does not meet requirements.

Size of Project becomes large.

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.

36

Decr

easing

Priority

Decr

easing

Priority

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

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:

37

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

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

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.

38

Modularity:

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

39

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.

40

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.

41

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:

42

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.

43

44

45

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

46

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

47

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

48

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”.

49

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

50

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.

51

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.

52

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

53

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

54

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.

55

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.

56

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 ensures that all completed transactions are ultimately written to the bank’s database.

57

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

64

A transaction use case is started within a session when the customer chooses a

transaction type from a menu of options. The customer will be asked to

furnish appropriate details (e.g. account(s) involved, amount). The transaction

will then be sent to the bank, along with information from the customer's card

and the PIN the customer entered.

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.

65

Withdrawal Transaction Use Case

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

withdraw from (e.g. checking) from a menu of possible accounts, and to

choose a dollar amount from a menu of possible amounts. The system verifies

that it has sufficient money on hand to satisfy the request before sending the

transaction to the bank. (If not, the customer is informed and asked to enter a

different amount.) If the transaction is approved by the bank, the appropriate

amount of cash is dispensed by the machine before it issues a receipt. (The

dispensing of cash is also recorded in the ATM's log.)

A withdrawal transaction can be cancelled by the customer pressing the

Cancel key any time prior to choosing the dollar amount.

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

66

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

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

transaction is automatically cancelled if the customer fails to insert the

envelope containing the deposit within a reasonable period of time after being

asked to do so.

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.

67

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

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.

68

Chapter 8: Conclusion

8.1 Limitation of the Project:

The project currently possesses some limitations such as:

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:

69

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

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