1.

INTRODUCTION

1.1 About The Project

The aim of the project is to design a graphical user interface that helps the user in performing
various transactions. The technology used in ATMs has gone through various phases from basic
payment functions to value-added functions such as balance enquiry, printing statements
.Banking customers also used ATM for cash deposits, but more so the ATM is used for
withdrawing cash. However due to differing nature in the business environment, there are certain
pockets in every city where traders form queues to deposit money every morning.

The system “ATM Simulator “ consists of 2 modules.

1. Savings Account

2. Current Account

Before starting the transactions, user is first allowed to login with his/her accounted, Pin number.
If “cancel” button is pressed it comes to the first screen. If we give correct AccountID,
PinNumber user can perform transactions either from savings account or current account.

EXISTING SYSTEM

The main objective of the Existing system solution is to be automated the various functions and
activities of the ATM. The solution will facilitate to the bank employees and the account holders
with the different modules. This solution is very much necessary for the private sector banks and
the corporate sector. The banking industry will take a new shape and explore like never before.
Using the solution the bankers and account holders can generate various kinds of reports.In the
existing system developer has kept in mind about various difficulties of the user. with the
development of the existing system developer has facilitated the user to perform different
transaction by sitting in front of computer in home.

Proposed System

In earlier days, lot of transactions took place manually bank holders use to maintain account
details in registers(books).But as more and more account holders are increased, it was very
tedious to verify or search each and every account in books.A very small mistake in transactions
leads to great loss of money with account holders.

Scope of the System

The proposed system scope is Standalone. In future it can be enhanced to be a global
communication medium.

Feasibility Study:
Preliminary investigation examines project feasibility, the likelihood the system will be
useful to the organization. The main objective of the feasibility study is to test the Technical,
Operational and Economical feasibility for adding new modules and debugging old running
system. All systems are feasible if they are given unlimited resources and infinite time. There
are aspects in the feasibility study portion of the preliminary investigation:

• Technical Feasibility
• Operation Feasibility
Economical Feasibility

3.1 TECHNICAL FEASIBILITY

The technical issue usually raised during the feasibility stage of the investigation includes the
following:

• Does the necessary technology exist to do what is suggested?

• Do the proposed equipments have the technical capacity to hold the data required to use
the new system?
• Will the proposed system provide adequate response to inquiries, regardless of the
number or location of users?
• Can the system be upgraded if developed?
Are there technical guarantees of accuracy, reliability, ease of access and data security?

3.2 OPERATIONAL FEASIBILITY

OPERATIONAL FEASIBILITY

User-friendly

Customer will use the forms for their various transactions i.e. for adding
new routes, viewing the routes details. Also the Customer wants the
reports to view the various transactions based on the constraints.
Theses forms and reports are generated as user-friendly to the Client.
Reliability
The package wills pick-up current transactions on line. Regarding the
old transactions, User will enter them in to the system.
Security
The web server and database server should be protected from hacking,
virus etc
Portability
 The application will be developed using standard open source software
(Except Oracle) like Java, tomcat web server, Internet Explorer Browser
etc these software will work both on Windows and Linux o/s. Hence
portability problems will not arise.
Availability

This software will be available always.

Maintainability

The system called the ewheelz uses the 2-tier architecture. The 1st tier is the GUI, which is
said to be front-end and the 2nd tier is the database, which uses My-Sql, which is the back-
end.

The front-end can be run on different systems (clients). The database will be running at the
server. Users access these forms by using the user-ids and the passwords.

3.3 ECONOMIC FEASILITY

The computerized system takes care of the present existing system’s data flow and
procedures completely and should generate all the reports of the manual system
besides a host of other management reports.

It should be built as a web based application with separate web server and database
server. This is required as the activities are spread through out the organization
customer wants a centralized database. Further some of the linked transactions take
place in different locations.

Open source software like TOMCAT, JAVA, Mysql and Linux is used to minimize the cost
for the Customer.
1.MODULES

The system “ATM Simulator “ consists of 2 modules.

1. Savings Account

2. Current Account

Before starting the transactions, user is first allowed to login with his/her accounted, Pin number.
If “cancel” button is pressed it comes to the first screen. If we give correct AccountID,
PinNumber user can perform transactions either from savings account or current account.

Savings Account

From Savings account, we are authorized to perform transactions like fast cash,
Cash withdrawal, Mini Statement, Balance Enquiry, Deposit, Transfer kind of
operations.In order to Transfer money from Account A to Account B we are already
logged on to Account A we have to type Account B’s account number and type how
much money we want to transfer.

If user desires to deposit some amount he/she can type how much amount he wants
to deposit and we can also take print out of our balance.

User can check how much amount is remaining and what is the Ledger Balance that
is remaining if he wish to take print out he can or else he can deny.

User can press Mini Statement button in which he has to put his ID number and
Debit card or credit card number.

User can press “Fast Cash” button in which he is allowed to withdraw

R.S.10,100R.S.,1000R.s.,1500R.S. and he can take print statement of the
transactions Or else deny.
User can press “Cash Withdrawal” button and press the amount he wants to
withdraw. user can even take the print out of the balance if required.

Current Account

From Current account, we are authorized to perform transactions like fast cash,
Cash withdrawal, Mini Statement, Balance Enquiry, Deposit, Transfer kind of
operations.

In order to Transfer money from Account A to Account B we are already logged on

to Account A we have to type Account B’s account number and type how much
money we want to transfer.

If user desires to deposit some amount he/she can type how much amount he wants
to deposit and we can also take print out of our balance.

User can check how much amount is remaining and what is the Ledger Balance that
is remaining if he wish to take print out he can or else he can deny.

User can press Mini Statement button in which he has to put his ID number and
Debit card or credit card number.

User can press “Fast Cash” button in which he is allowed to withdraw

R.S.10,100R.S.,1000R.s.,1500R.S. and he can take print statement of the
transactions Or else deny.

User can press “Cash Withdrawal” button and press the amount he wants to
withdraw. user can even take the print out of the balance if required.

Software and Hardware Requirements

The following software and hardware are recommended for the company.

Hardware Requirements:
 Processor : Pentium

Speed : 233 MHz

Monitor : Samtron

HardDisk : 4.2 GB

RAM : 128 MB

Software Requirements:

• Programming Language: Java

• Operating System: Windows XP/2000/2003, LINUX, Solaris
• IDEs: Eclipse with My Eclipse plugins/Net Beans/RAD
 2.0 SYSTEM SPECIFICATION

The software to be designed will control a simulated automated teller machine (ATM) having a
magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for
interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples
of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator
to start or stop the machine. The ATM will communicate with the bank's computer over an
appropriate communication link. (The software on the latter is not part of the requirements for
this problem.)

The ATM will service one customer at a time. A customer will be required to insert an ATM
card and enter a personal identification number (PIN) - both of which will be sent to the bank for
validation as part of each transaction. The customer will then be able to perform one or more
transactions. The card will be retained in the machine until the customer indicates that he/she
desires no further transactions, at which point it will be returned - except as noted below.

The ATM must be able to provide the following services to the customer:

1. A customer must be able to make a cash withdrawal from any suitable account linked to
the card, in multiples of $20.00. Approval must be obtained from the bank before cash is
dispensed.
2. A customer must be able to make a deposit to any account linked to the card, consisting
of cash and/or checks in an envelope. The customer will enter the amount of the deposit
into the ATM, subject to manual verification when the envelope is removed from the
machine by an operator. Approval must be obtained from the bank before physically
accepting the envelope.
3. A customer must be able to make a transfer of money between any two accounts linked to
the card.
4. A customer must be able to make a balance inquiry of any account linked to the card.

A customer must be able to abort a transaction in progress by pressing the Cancel key instead of
responding to a request from the machine.

The ATM will communicate each transaction to the bank and obtain verification that it was
allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it
has been approved. In the case of a deposit, a second message will be sent to the bank indicating
that the customer has deposited the envelope. (If the customer fails to deposit the envelope
within the timeout period, or presses cancel instead, no second message will be sent to the bank
and the deposit will not be credited to the customer.)

If the bank determines that the customer's PIN is invalid, the customer will be required to re-
enter the PIN before a transaction can proceed. If the customer is unable to successfully enter the
PIN after three tries, the card will be permanently retained by the machine, and the customer will
have to contact the bank to get it back.
If a transaction fails for any reason other than an invalid PIN, the ATM will display an
explanation of the problem, and will then ask the customer whether he/she wants to do another
transaction.

The ATM will provide the customer with a printed receipt for each successful transaction,
showing the date, time, machine location, type of transaction, account(s), amount, and ending
and available balance(s) of the affected account ("to" account for transfers).

The ATM will have a key-operated switch that will allow an operator to start and stop the
servicing of customers. After turning the switch to the "on" position, the operator will be
required to verify and enter the total cash on hand. The machine can only be turned off when it is
not servicing a customer. When the switch is moved to the "off" position, the machine will shut
down, so that the operator may remove deposit envelopes and reload the machine with cash,
blank receipts, etc.

The ATM will also maintain an internal log of transactions to facilitate resolving ambiguities
arising from a hardware failure in the middle of a transaction. Entries will be made in the log
when the ATM is started up and shut down, for each message sent to the Bank (along with the
response back, if one is expected), for the dispensing of cash, and for the receiving of an
envelope. Log entries may contain card numbers and dollar amounts, but for security will never
contain a PIN.
INTRODUCTION TO JAVA

About Java:

Initially the language was called as “oak” but it was renamed as “java” in 1995.The
primary motivation of this language was the need for a platform-independent(i.e.
architecture neutral)language that could be used to create software to be embedded
in various consumer electronic devices.
• Java is a programmer’s language
• Java is cohesive and consistent
• Except for those constraint imposed by the Internet environment. Java gives the
programmer, full control

Finally Java is to Internet Programming where c was to System Programming.

Importance of Java to the Internet

Java has had a profound effect on the Internet. This is because; java expands the Universe
of objects that can move about freely in Cyberspace. In a network, two categories of objects
are transmitted between the server and the personal computer. They are passive
information and Dynamic active programs. in the areas of Security and probability. But Java
addresses these concerns and by doing so, has opened the door to an exciting new form of
program called the Applet.

Applications and applets. An application is a program that runs on our Computer under
the operating system of that computer. It is more or less like one creating using C or C++
.Java’s ability to create Applets makes it important. An Applet I san application, designed to
be transmitted over the Internet and executed by a Java-compatible web browser. An applet
I actually a tiny Java program, dynamically downloaded across the network, just like an
image. But the difference is, it is an intelligent program, not just a media file. It can be react
to the user input and dynamically change.

Java Architecture

Java architecture provides a portable, robust, high performing environment for

development. Java provides portability by compiling the byte codes for the Java Virtual
Machine, which is then interpreted on each platform by the run-time environment. Java is a
dynamic system, able to load code when needed from a machine in the same room or
across the planet.

Compilation of code

When you compile the code, the Java compiler creates machine code
(called byte code)for a hypothetical machine called Java Virtual
Machine(JVM). The JVM is supposed t executed the byte code. The JVM is
created for the overcoming the issue of probability. The code is written and
compiled for one machine and interpreted on all machines .This machine is
called Java Virtual Machine.

Compiling and interpreting java source code.

 Java
interpreterm
acintosh

Java
Pc
interpreter
compiler Java Byte
code
Macintosh
compiler
Platform
Source SPARC independ
code ent Java
Compiler
interpreter(
SPARC)

)))

During run-time the Java interpreter tricks the byte code file into thinking that it is
running on a Java Virtual Machine. In reality this could be an Intel Pentium windows
95 or sun SPARCstation running Solaris or Apple Macintosh running system and all
could receive code from any computer through internet and run the Applets.

Simple:

Java was designed to be easy for the Professional programmer to learn and to use
effectively. If you are an experienced C++ Programmer. Learning Java will oriented features
of C++ . Most of the confusing concepts from C++ are either left out of Java or implemented
in a cleaner, more approachable manner. In Java there are a small number of clearly
defined ways to accomplish a given task.

Object oriented

Java was not designed to be source-code compatible with any other

language. This allowed the Java team the freedom to design with a
blank state. One outcome of this was a clean usable, pragmatic
approach to objects. The object model in Java is simple and easy to
extend, while simple types, such as integers, are kept as high-
performance non-objects.

Robust

The multi-platform environment of the web places extraordinary

demands on a program, because the program must execute reliably in a
variety of systems. The ability to create robust programs. Was given a
high priority in the design of Java. Java is strictly typed language; it
checks your code at compile time and runtime.
Java virtually eliminates the problems of memory management and deal location, which
is completely automatic. In a well-written Java program, all run-time errors can and should
be managed by your program.
4.4.2 Servlets/JSP

INTRODUCTION

A Servlet Is a generic server extension. a Java class that can be

loaded
Dynamically to expand the functionality of a server.Servlets are commonly used with web
servers. Where they can take the place CGI scripts.

A servlet is similar to proprietary server extension, except that it runs inside a Java Virtual
Machine (JVM) on the server, so it is safe and portable

Servlets operate solely within the domain of the server.

Unlike CGI and Fast CGI, which use multiple processes to handle separate program or
separate requests, separate threads within web server process handle all servlets. This
means that servlets are all efficient and scalable.

Servlets are portable; both across operating systems and also across web servers. Java
Servlets offer the best possible platform for web application development.

Servlets are used as replacement for CGI scripts on a web server, they can extend any sort
of server such as a mail server that allows servelts t extend its functionality perhaps by
performing a virus scan on all attached documents or handling mail filtering tasks.
Servlets provide a Java-based solution used to address the problems currently associated
with doing server-side programming including inextensible scripting solutions platform-
specific API’s and incomplete interface.

Servlets are objects that conform to a specific interface that can be plugged into a Java-
based server.Servlets are to the server-side what applets are to the server-side what
applets are to the client-side-object byte codes that can be dynamically loaded off the net.
They differ form applets in than they are faceless objects(with out graphics or a GUI
component).They serve as platform independent, dynamically loadable,plugable helper byte
code objects on the server side that can be used to dynamically extend server-side
functionality.

For example an HTTP servlet can be used to generate dynamic HTML content when you
use servlets to do dynamic content you get the following advantages:

• They’re faster and cleaner then CGI scripts

• They use a standard API( the servlet API)
• They provide all the advantages of Java (run on a variety of servers without needing
to be rewritten)

A t t r a c t i v e n e s s o f S e r v l e t s:

They are many features of servlets that make them easy and attractive to tuse
these include:

• Easily configure using the GUI-based Admin tool]

• Can be Loaded and Invoked from a local disk or remotely across the network.
• Can be linked together or chained, so that on servlet can call another servlet, or
several servlets in sequence.
 • Can be called dynamically from with in HTML, pages using server-side include-
tags.
• Are secure-even when downloading across the network, the servlet security
model and servlet and box protect your system from unfriendly behavior.,

Advantages of the servlet API

One of the great advantages of the servlet API is protocol independent. It assumes
nothing about:

• The protocol being used to transmit on the net

• How it is loaded
• The server environment it will be running in
• These quantities are important, because it allows the Servlet API to be
embedded in many different kinds of servers.There are other advantages to the
servelt API as well These include:
• It’s extensible-you can inherit all your functionality from the base classes made
available to you
• It’s simple small, and easy to use.

Features of Servlets:

• Servlets are persistent.Servlet are loaded only by the web server and can
maintain services between requests.
• Servlets are fast. Since servlets only need to be l\loaded once, they offer much
better performance over their CGI counterparts.
• Servlets are platform independent.
• Servlets are extensible Java is a robust, object-oriented programming language,
which easily can be extended to suit your needs.
 • Servlets are secure
• Servlets are used with a variety of client.

Servlets are classes and interfaces from tow packages,javax .servlet and
javax.servlet.http.The java.servlet package contains classes t support generic, protocol-
independent servlets.The classes in the javax.servelt.http package To and HTTP specific
functionality extend these classes

Every servlet must implement the javax.servelt interface.Most servlets implement it by

extending one of two classes.javax.servlet.GenericServlet or javax.servlet.http.HttpServlet.A
protocol-independent servlet should subclass Generic-Servlet.while an Http servlet should
subclass HttpServlet, which is itself a subclass of Generic-servlet with added HTTP-specific
functionality.

Unlike a java program, a servlet does not have a main() method,Instead the server in the
process of handling requests invoke certain methods of a servlet.Each time the server
dispatches a request to a servlet, it invokes the servelts Service() method,

A generic servlet should override its service() method to handle requests as appropriate for
the servlet.The service() accepts two parameters a request object and a response object
.The request object tells the servlet about the request, while the response object is used to
return a response

InContrast.anHttp servlet usually does not override the service() method.Instead it overrides
doGet() to handle GET requests and doPost() to handle Post requests. An Http servlet can
override either or both of these modules the service() method of HttpServlet handles the
setup and dispatching to all the doXXX() methods.which iswhy it usually should not be
overridden
The remainders in the javax.servlet and javax.servlet.http.package are largely support
classes .The ServletRequest and ServletResponse classes in javax.servlet provide access
to generic server requests and responses while HttpServletRequest and
HttpServletResponse classes in javax.servlet provide access to generic server requests and
responses while HttpServletRequest and HttpServletResponse in javax.servlet.http provide
access a HTTP requests and responses . The javax.servlet.http provide contains an
HttpSession class that provides built-in session tracking functionality and Cookie class that
allows quickly setup and processing HttpCookies.

Loading Servlets:

Servlets can be loaded from their places. From a directory that is on the
CLASSPATH. The CLASSPATH of the JavaWebServer includes service
root/classes/, which is where the system classes reside

From the <SERVICE_ROOT/servlets/directory.This is not in the server’s classpath. A class

loader is used to create servlets form this directory.New servlets can be added-existing
servlets can be recompiled and the server will notice these changes. From a remote
location.For this a code base like http://nine.eng/classes/foo/ is required in addtion to the
servlet’s class name.Refer to the admin Gui docs on servlet section to see how to set this
up.

Loading Remote Servlets

Remote servlets can be loaded by:

• Configuring the admin Tool to setup automatic loading of remote servlets.

• Selectiong up server side include tags in .html files
 • Defining a filter chain Configuration

Invoking Servlets

A servlet invoker is a servlet that invokes the “server” method on a named servlet.If the
servlet is not loaded in the server,then the invoker first loades the servlet(either form local
disk or from the network) and the then invokes the “service” method.Also like applets,local
servlets in the server can be identified by just the class name.In other words, if a servlet
name is not absolute.it is treated as local.

A Client can Invoke Servlets in the Following Ways:

• The client can ask for a document that is served by the servlet.
• The client(browser) can invoke the servlet directly using a URL, once it has been
mapped using the SERVLET ALIASES Section of the admin GUI
• The servlet can be invoked through server side include tags.
• The servlet can be invoked by placing it in the servlets/directory
• The servlet can be invoked by using it in a filter chain

The Servlet Life Cycle:-

The Servlet life cycle is one of the most exciting features of Servlets.This life cycle is
a powerful hybrid of the life cycles used in CGI programming and lower-level NSAPI
and ISAPI programming.
The servlet life cycle allows servlet engines to address both the performance and
resource problems of CGI and the security concents of low level server API
programming.

Servlet life cycle is highly flexible Servers hava significant leeway in how they choose to
support servlets.The only hard and fast rule is that a servlet engine must confor to the
following life cycle contact:

• Create and initialize the servlets

• Handle zero or more service from clients
• Destroy the servlet and then garbage Collects it.

It’s perfectly legal for a servlet t be loaded, created an initialzed in its own JVM,only to be
destroyed an dgarbage collected without hancdling any clientrequest or after handling just
one request

The most common and most sensible life cycle implemntations for HTTP servelts are:

Single java virtual machine and astatine persistence.

Init and Destroy:-

Just like Applets servlets can define init() and destroy() methods, A servlets
init(ServiceConfig) method is called by the server immediately after the server constructs the
servlet’s instance.Depanding on the server and its configuration, this can be at any of these
times
 • When the server states
• When the servlet is first requested, just before the service() method is invoked
• At the request of the server administrator

In any case, nit() is guaranteed to be called before the servlet handles its first request

The init() method is typically used to perform servlet initialization creating or loading objects
that are used by the servlet in handling of its request. In order to providing a new servlet any
information about itself and its environment, a server has to call a servelts init() method and
pass an object that implement the ServletConfig interface.

This ServletConfig object supplies a servlet with information about its initialization
parameters.These parameters are given to the servlets and are not associated with any
single request.They can specify initial values, such as where a counter should begin
counting, or default values, perhaps a template to use when not specified by the request,

The server calls a servlet’s destroy() method when the servlet is about to be unloaded. In
the destroy() method, a servlet should free any resources it has acquired that will not be
garbage collected. The destroy() method also gives a servlet a chance to write out its
unsaved. cached information or any persistent information that should be read during the
next call to init().

Session Tracking:
HTTP is a stateless protocol, it provides no way for a server to recognize that a sequence
of requests is all from the same client. This causes a problem for application such as
shopping cart applications. Even in chat application server can’t know exactly who’s making
a request of several clients.
The solution for this is for client to introduce itself as it makes each request, Each clients
needs to provide a unique identifier that lets the server identify it, or it needs to give some
information that the server can use to properly handle the request, There are several ways
to send this introductory information with each request Such as:

USER AUTHORIZATION:

One way to perform session tracking is to leverage the information that comes
with
User authorization. When a web server restricts access to some of its resources to only
those clients that log in using a recognized username and password. After the client logs in,
the username is available to a servlet through getRemoteUser()

Wean use the username to track the session. Once a user has logged in, the browser
remembers her username and resends the name and password as the user views new
pages on the site. A servlet can identify the user through her username and they’re by

Track her session.

The biggest advantage of using user authorization to perform session tracking is that it’s
easy to implement. Simply tell the protect a set of pages, and use getRemoteUser() to
identify each client.Another advantage is that the technique works even when the user
accesses your site form or exists her browser before coming back.

The biggest disadvantage of user authrization is that it requires each user to register for an
account and then log in in each time the starts visiting your site. Most users will tolerate
registering and lagging in as a necessary evil when they are accessing sensitive
information, but its all overkill for simple session tracking.Other problem with user
authorization is that a user cannot simultaneously maintain more than one session at the
same site.

Hidden Form Fields:

One way to support anonymous session tracking is to use hidden from fields. As the
name implies, these are fields added to an HTML, form that are not displayed in the
client’s browser, They are sent back to the server when the form that contains them
is submitted.

In a sense, hidden form fields define constant variables for a form. To a servlet
receiving a submitted form, there is no difference between a hidden fields and a
visible filed.

As more and more information is associated with a clients session . It can become
burdensome to pass it all using hidden form fields. In these situations it’s possible to
pass on just a unique session ID that identifies as particular clients session.

That session ID can be associated with complete information about its session that
is stored on the server.

The advantage of hidden form fields is their ubiquity and support for anonymity.
Hidden fields are supported in all the popular browsers, they demand on special
server requirements, and they can be used with clients that haven’t registered or
logged in.

The major disadvantage with this technique, however is that works only for a
sequence of dynamically generated forms, The technique breaks down immediately
with static documents, emailed documents book marked documents and browser
shutdowns.

URL Rewriting:
 URL rewriting is another way to support anonymous session tracking, With URL
rewriting every local URL the user might click on is dynamically modified. or
rewritten, to include extra, information. The extra information can be in the deform of
extra path information, added parameters, or some custom, server-specific.URL
change. Due to the limited space available in rewriting a URL, the extra information
is usually limited to a unique session.

Each rewriting technique has its own advantage and disadvantage

Using extra path information works on all servers, and it works as a target for forms
that use both the Get and Post methods. It does not work well if the servlet has to
use the extra path information as true path information

The advantages and disadvantages of URL.rewriting closely match those of hidden

form fileds,The major difference is that URL rewriting works for all dynamically
created documents, such as the Help servlet, not just forms. With the right server
support, custom URL rewriting can even work for static documents.

Persistent Cookies:

A fourth technique to perform session tracking involves persistent cookies. A cookie

is a bit of information. sent by a web server to a browser that can later be read back
form that browser. When a browser receives a cookie, it saves the cookie and there
after sends the cookie back to the server each time it accesses a page on that
server, subject to certain rules. Because a cookie’s value can uniquely identify a
client, cookies are often used for session tracking.

Persistent cookies offer an elegant, efficient easy way to implement session

tracking. Cookies provide as automatic an introduction for each request as we could
hope for. For each request, a cookie can automatically provide a client’s session ID
or perhaps a list of clients performance. The ability to customize cookies gives them
extra power and versatility.
The biggest problem with cookies is that browsers don’t always accept cookies
sometimes this is because the browser doesn’t support cookies. More often its
because

The browser doesn’t support cookies. More often its because the user has
specifically configured the browser to refuse cookies.

The power of serves:

The power of servlets is nothing but the advantages of servlets over other
approaches, which include portability, power, efficiency, endurance, safety
elegance,integration,extensibility and flexibility.

Portability:

As servlets are written in java and conform to a well defined and widely accepted
API.they are highly portable across operating systems and across server
implementation

We can develop a servlet on a windows NT machine running the java web server
and later deploy it effortlessly on a high-end Unix server running apache. With
servlets we can really “write once, serve every where”

Servlet portability is not the stumbling block it so often is with applets, for two
reasons

First,Servlet portability is not mandatory i.e. servlets has to work only on server
machines that we are using for development and deployment

Second, servlets avoid the most error-prone and inconstancy implemented portion of
the java languages.

Power:

Servlets can harness the full power of the core java. API’s: such as Networking
and Url access, multithreading, image manipulation, data compression, data base
connectivity, internationalization, remote method invocation(RMI) CORBA
connectivity, and object serialization, among others,
Efficiency And Endurance:

Servlet invocation is highly efficient, Once a servlet is loaded it generally remains

in the server’s memory as a single object instance, There after the server invokes
the servelt to handle a request using a simple, light weighted method invocation
.Unlike the CGI, there’s no process to spawn or interpreter to invoke, so the servlet
can begin handling the request almost immediately, Multiple, concurrent requests
are handled the request almost immediately. Multiple, concurrent requests are
handled by separate threads, so servlets are highly scalable.

Servlets in general are enduring objects. Because a servlets stays in the server’s
memory as a single object instance. it automatically maintains its state and can hold
onto external resources, such as database connections.

Safety:

Servlets support safe programming practices on a number of levels.

As they are written in java,servlets inherit the strong type safety of the java
language. In addition the servlet API is implemented to be type safe. Java’s
automatic garbage collection and lack of pointers mean that servlets are generally
safe from memory management problems like dangling pointers invalid pointer
references and memory leaks.

Servlets can handle errors safely, due to java’s exception – handling mechanism.
If a servlet divides by zero or performs some illegal operations, it throws an
exception that can be safely caught and handled by the server.

A server can further protect itself from servlets through the use of java security
manager.A server can execute its servlets under the watch of a strict security
manager.

Elegance:
 The elegance of the servlet code is striking .Servlet code is clean, object oriented
modular and amazingly simple one reason for this simplicity is the served API itself.
Which includes methods and classes to handle many of the routine chores of servlet
development. Even advanced to operations like cookie handling and session
tracking tracking are abstracted int convenient classes.

Integration:

Servlets are tightly integrated with the server. This integration allows a servlet to
cooperate with the server in two ways . for e.g.: a servlet can use the server to
translate file paths, perform logging, check authorization, perform MIME type
mapping and in some cases even add users to the server’s user database.

Extensibility and Flexibility:

The servlet API is designed to be easily extensible. As it stands today the API
includes classes that are optimized for HTTP servlets.But later it can be extended
and optimized for another type of servlets.It is also possible that its support for HTTP
servlets could be further enhanced.

Servlets are also quite flexible, Sun also introduced java server pages. which offer a way to
write snippets of servlet code directly with in a static HTML page using syntax similar to
Microsoft’s Active server pages(ASP)

4.4.3 JDBC

What is JDBC?

any relational database. One can write a single program using the JDBC API,and the JDBC
is a Java Api for executing SQL,Statements(As a point of interest JDBC is trademarked
name and is not an acronym; nevertheless,Jdbc is often thought of as standing for Java
Database Connectivity. It consists of a set of classes and interfaces written in the Java
Programming language.JDBC provides a standard API for tool/database developers and
makes it possible to write database applications using a pure Java API
Using JDBC, it is easy to send SQL statements to virtually program will be able to send SQL
.statements to the appropriate database. The Combination of Java and JDBC lets a
programmer writes it once and run it anywhere.

What Does JDBC Do?

Simply put,JDBC makes it possible to do three things

o Establish a connection with a database

o Send SQL statements
o Process the results
o JDBC Driver Types
o The JDBC drivers that we are aware of this time fit into one of four categories
o JDBC-ODBC Bridge plus ODBC driver
o Native-API party-java driver
o JDBC-Net pure java driver
o Native-protocol pure Java driver

An individual database system is accessed via a specific JDBC driver that implements the
java.sql.Driver interface. Drivers exist for nearly all-popular RDBMS systems, through few are
available for free. Sun bundles a free JDBC-ODBC bridge driver with the JDK to allow access
to a standard ODBC,data sources, such as a Microsoft Access database, Sun advises
against using the bridge driver for anything other than development and very limited
development.

JDBC drivers are available for most database platforms, from a number of vendors and
in a number of different flavours. There are four driver categories

Type 01-JDBC-ODBC Bridge Driver

 Type 01 drivers use a bridge technology to connect a java client to an ODBC database
service. Sun’s JDBC-ODBC bridge is the most common type 01 driver. These drivers
implemented using native code.

Type 02-Native-API party-java Driver

Type 02 drivers wrap a thin layer of java around database-specific native code libraries
for Oracle databases, the native code libraries might be based on the OCI(Oracle call
Interface) libraries, which were originally designed for c/c++ programmers, Because type-02
drivers are implemented using native code. in some cases they have better performance
than their all-java counter parts. They add an element of risk, however, because a defect in
a driver’s native code section can crash the entire server

Type 03-Net-Protocol All-Java Driver

Type 03 drivers communicate via a generic network protocol to a piece of custom

middleware. The middleware component might use any type of driver to provide the actual
database access. These drivers are all java, which makes them useful for applet deployment
and safe for servlet deployment

Type-04-native-protocol All-java Driver

Type o4 drivers are the most direct of the lot. Written entirely in java, Type 04 drivers
understand database-specific networking. protocols and can access the database directly
without any additional software

JDBC-ODBC Bridge
 If possible use a Pure Java JDBC driver instead of the Bridge and an ODBC driver. This
completely eliminates the client configuration required by ODBC.It also eliminates the
potential that the Java VM could be corrupted by an error in the native code brought in by
the Bridge(that is, the Bridge native library, the ODBC driver manager library, library, the
ODBC driver library, and the database client library)

WHAT IS The JDBC-ODBE Bridge ?

The JDBC-ODBC Bridge is a Jdbc driver, which implements JDBC operations by translating
them into ODBC operations. To ODBC it appears as a normal application program. The
Bridge is implemented as the sun.jdbc.odbc Java package and contains a native library
used to access ODBC.The Bridge is joint development of Intersolv and Java Soft

4.4.4 Oracle

Oracle is a relational database management system, which organizes data in the form of
tables. Oracle is one of many database servers based on RDBMS model, which manages a
seer of data that attends three specific things-data structures, data integrity and data
manipulation.

With oracle cooperative server technology we can realize the benefits of open,
relational systems for all the applications. Oracle makes efficient use of all systems
resources, on all hardware architecture; to deliver unmatched performance, price
performance and scalability. Any DBMS to be called as RDBMS has to satisfy Dr.E.F.Codd’s
rules.

Features of Oracle:

Portable
 The Oracle RDBMS is available on wide range of platforms ranging from PCs to super
computers and as a multi user loadable module for Novel NetWare, if you develop application
on system you can run the same application on other systems without any modifications.

Compatible

Oracle commands can be used for communicating with IBM DB2 mainframe RDBMS
that is different from Oracle, which is Oracle compatible with DB2. Oracle RDBMS is a high
performance fault tolerant DBMS, which is specially designed for online transaction processing
and for handling large database applications.

Multithreaded Server Architecture

Oracle adaptable multithreaded server architecture delivers scalable high performance

for very large number of users on all hardware architecture including symmetric multiprocessors
(sumps) and loosely coupled multiprocessors. Performance is achieved by eliminating CPU, I/O,
memory and operating system bottlenecks and by optimizing the Oracle DBMS server code to
eliminate all internal bottlenecks.

Oracle has become the most popular RDBMS in the market because of its ease of use

• Client/server architecture.
• Data independence.
• Ensuring data integrity and data security.
• Managing data concurrency.
• Parallel processing support for speed up data entry and online transaction processing
used for applications.
• DB procedures, functions and packages.
Dr.E.F.Codd’s Rules

These rules are used for valuating a product to be called as relational database
management systems. Out of 12 rules, a RDBMS product should satisfy at least 8 rules + rule
called rule 0 that must be satisfied.

RULE 0: Foundation Rule

For any system to be advertised as, or claimed to be relational DBMS should manage
database with in it self, with out using an external language.

RULE 1: Information Rule

All information in relational database is represented at logical level in only one way as
values in tables.

RULE 2: Guaranteed Access

Each and every data in a relational database is guaranteed to be logically accessibility

by using to a combination of table name, primary key value and column name.

RULE 3: Systematic Treatment of Null Values

Null values are supported for representing missing information and inapplicable
information. They must be handled in systematic way, independent of data types.

RULE 4: Dynamic Online Catalog based Relation Model

The database description is represented at the logical level in the same way as ordinary
data so that authorized users can apply the same relational language to its interrogation as they
do to the regular data.
RULE 5: Comprehensive Data Sub Language

A relational system may support several languages and various models of terminal use.
However there must be one language whose statement can express all of the following:

Data Definitions, View Definitions, Data Manipulations, Integrity, Constraints,

Authorization and transaction boundaries.

RULE 6: View Updating

Any view that is theoretical can be updatable if changes can be made to the tables that
effect the desired changes in the view.

RULE 7: High level Update, Insert and Delete

The capability of handling a base relational or derived relational as a single operand

applies not only retrieval of data also to its insertion, updating, and deletion.

RULE 8: Physical Data Independence

Application program and terminal activities remain logically unimpaired whenever any
changes are made in either storage representation or access method.

RULE 9: Logical Data Independence

Application programs and terminal activities remain logically unimpaired whenever any
changes are made in either storage representation or access methods.

RULE 10: Integrity Independence

 Integrity constraints specific to particular database must be definable in the relational
data stored in the catalog, not in application program.

RULE 11: Distributed Independence

Whether or not a system supports database distribution, it must have a data sub-
language that can support distributed databases without changing the application program.

RULE 12: Non Sub-Version

If a relational system has low level language, that low language cannot use to
subversion or by pass the integrity rules and constraints expressed in the higher level relational
language.

Oracle supports the following Codd’s Rules

Rule 1: Information Rule (Representation of information)-YES.

Rule 2: Guaranteed Access-YES.

Rule 3: Systematic treatment of Null values-YES.

Rule 4: Dynamic on-line catalog-based Relational Model-YES.

Rule 5: Comprehensive data sub language-YES.

Rule 6: View Updating-PARTIAL.

Rule 7: High-level Update, Insert and Delete-YES.

Rule 8: Physical data Independence-PARTIAL.

Rule 9: Logical data Independence-PARTIAL.

Rule 10: Integrity Independence-PARTIAL.

 Rule 11: Distributed Independence-YES.

Rule 12: Non-subversion-YES.

4.4.5 HTML

Hypertext Markup Language(HTML), the languages of the world wide

web(WWW), allows users to produces web pages that included text,
graphics and pointer to other web pages (Hyperlinks).

HTML is not a programming language but it is an application of ISO Standard

8879,SGML(Standard Generalized Markup Language),but

Specialized to hypertext and adapted to the Web. The idea behind Hypertext one point to
another point. We can navigate through the information based on out interest and
preference. A markup language is simply a series of items enclosed within the elements
should be displayed.

Hyperlinks are underlined or emphasized works that load to other documents or some
portions of the same document.

Html can be used to display any type of document on the host computer, which can be
geographically at a different location. It is a versatile language and can be used on any
platform or desktop

HTML provides tags(special codes) to make the document look attractive.

 HTML provides are not case-sensitive. Using graphics,fonts,different sizes, color, etc.. can
enhance the presentation of the document. Anything

That is not a tag is part of the document it self.

Basic Html Tags:

<!-- --> Specific Comments.

<A>………</A> Creates Hypertext links.

<B>………</B> Creates hypertext links.

<Big>……..</Big> Formats text in large-font

<Body>…….</Body> contains all tags and text in the Html-document

<Center>……</Center> Creates Text

<DD>………..</DD> Definition of a term.

<TABLE>……</TABLE> creates table

<Td>………..</Td> indicates table data in a table.

<Tr>………..</Tr> designates a table row

<Th>……….</Th> creates a heading in a table.

A D V A N T A G E S:-

• A HTML document is small and hence easy to send over the net.It is small
because it does not include formatted information.
• HTML is platform independent
HTML tags are not case-sensitive.
4.4.6 JAVA SCRIPT

The Java Script Language

JavaScript is a compact , object-based scripting language for developing client and server
internet applications. Netscape Navigator 2.0 interprets JavaScript statements embedded
directly in an HTML page. and Livewire enables you to create server-based applications
similar to common gateway interface(cgi) programs.

In a client application for Navigator, JavaScript statements embedded in an HTML Page can
recognize and respond to user events such as mouse clicks form

Input, and page navigation.

For example, you can write a JavaScript function to verify that users enter valid information
into a form requesting a telephone number or zip code . Without any network transmission,
an Html page with embedded Java Script can interpret the entered text and alert the user
with a message dialog if the input is invalid or you can use JavaScript to perform an action
(such as play an audio file, execute an applet, or communicate with a plug-in) in response to
the user opening or exiting a page.

DATA FLOW DIAGRAMS:

A data flow diagram is a logical model of a system. The model does not depend on hardware,
software and data structures of the organization. There is no physical implication in a data flow
diagram. Because the diagram is a graphic picture of the logical system, it tends to be easy for
every non-technical user to understand and thus serves as an excellent communication tool.
Finally a data flow diagram is a good starting point for system design.

To construct a data flow diagram it uses four basic symbols. They are given below.

Rectangle:

The above symbol is used to define source or destination of data.

Circle or Rounded Corners Rectangle:

The above symbols are defined to represent a process that transforms or modifies the data.
 UMLDIAGRAMS

3.21 INTRODUCTION

UML is a notation that resulted from the unification

Of Object Modeling Technique and Object Oriented Software Technology .UML has been
designed for broad range of application.
Hence, it provides constructs for a broad range of systems and activities.

An Overview of UML in five notations

1.use case diagrams

Use cases are used during requirements elicitation and analysis

To represent the functionality of the system.Use cases focus on the behaviour of the system
from the external point of view.The actor are
Outside the boundary of the system,whereas the use cases are inside the boundary of the system.

2.class diagrams

Class diagrams to describe the structure of the system. Classes

Are abstraction that specify the common structure and behaviour of a set
Of objects.
Class diagrams describe the system in terms of objects, classes,
attributes, operations and their associations.

3.Sequence diagrams
 Sequence diagrams are used to formalize the behaviour of the system
and to visualize the communication among objects. They are useful for identifying
additional objects that participate in the use cases. A Sequence diagram represents
the interaction that take place among these objects.

4.Statechart diagrams

State chart diagrams describe the behaviour of an individual object as

a number of states and transitions between these states. A state represents a
particular set of values for an object. The sequence diagram focuses on the
messages exchanged between objects, the state chart diagrams focuses on the
transition between states.

5.Activity diagrams
An activity diagram describes a system in terms of activities. Activities are states
that represents the execution of a set of operations. Activity diagrams are similar to
flowchart diagram and data flow.

Use Cases for Example ATM System

System Startup Use Case

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.

Interaction Diagrams for Example ATM System

UML defines two types of Interaction Diagram: the Sequence Diagram and the Collaboration
Diagram. In order to illustrate both types, the major use cases are documented using Sequence
Diagrams, and the specific subcases of transaction (withdrawal, etc.) and the Invalid PIN
Extension are documented using Collaboration Diagrams. (The major reason for using two
different types of diagram is pedagogical - to illustrate each type.)

• Sequence Diagram for System Startup Use Case

• Sequence Diagram for System Shutdown Use Case
• Sequence Diagram for Session Use Case
• Sequence Diagram for Transaction Use Case (Since transaction is abstract,
this gives the overall flow of a transaction. See the interactions below for
specific concrete cases.)
• Collaboration realizing specifics of Withdrawal Transaction Use Case
• Collaboration realizing specifics of Deposit Transaction Use Case
• Collaboration realizing specifics of Transfer Transaction Use Case
• Collaboration realizing specifics of Inquiry Transaction Use Case
• Collaboration realizing Invalid PIN Extension
 Initial Functional Test Cases for Example ATM System
The following initial test cases can be identified early in the design process as a vehicle for
checking that the implementation is basically correct. No attempt has been made at this point to
do thorough testing, including all possible errors and boundary cases. That needs to come later.
These cases represent an initial check that the functionality specified by the use cases is present.

Some writers would argue for developing test cases like these in place ofuse cases. Here, they are
presented as a vehicle for "fleshing out" the use cases, not as a substitute for them.
 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

System is Enter a
System System accepts
requesting cash legitimate System is on
Startup initial cash amount
amount amount

System output
Perform a should demonstrate
Connection to the
System System has just legitimate that a connection
bank is
Startup been turned on inquiry has been
established
transaction established to the
Bank

System is shut System is on

System down when the and not Activate the "off"
System is off
Shutdown switch is turned servicing a switch
"off" customer

Connection to the Verify from the bank

System Bank is terminated System has just side that a
Shutdown when the system been shut down connection to the
is shut down ATM no longer exists

System is on
System reads a Card is accepted;
and not Insert a readable
Session customer's ATM System asks for
servicing a card
card entry of PIN
customer

Card is ejected;
System is on
System displays an
System rejects an and not Insert an
Session error screen;
unreadable card servicing a unreadable card
System is ready to
customer
start a new session

System is System displays a

System accepts
Session asking for entry Enter a PIN menu of transaction
customer's PIN
of PIN types

Session System allows System is Perform a System asks

customer to displaying menu whether customer
 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

perform a of transaction wants another

transaction
transaction types transaction

System is
System allows
asking whether System displays a
multiple
Session customer wants Answer yes menu of transaction
transactions in one
another types
session
transaction

System is
Session ends when
asking whether System ejects card
customer chooses
Session customer wants Answer no and is ready to start
not to do another
another a new session
transaction
transaction

Individual types of
Transactio
transaction will be
n
tested below

Enter an
System handles an A readable card The Invalid PIN
Transactio incorrect PIN and
invalid PIN has been Extension is
n then attempt a
properly entered performed
transaction

System asks Menu of

Choose System displays a
Withdrawa customer to transaction
Withdrawal menu of account
l choose an account types is being
transaction types
to withdraw from displayed

System asks
customer to Menu of System displays a
Withdrawa Choose checking
choose a dollar account types is menu of possible
l account
amount to being displayed withdrawal amounts
withdraw

Withdrawa System performs a System is Choose an System dispenses

l legitimate displaying the amount that the this amount of cash;
withdrawal menu of system currently System prints a
 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

correct receipt
showing amount and
correct updated
has and which is balance;
transaction withdrawal not greater than System records
properly amounts the account transaction correctly
balance in the log (showing
both message to the
bank and approval
back)

System has
been started up
with less than
System verifies the maximum Choose an System displays an
that it has withdrawal amount greater appropriate
Withdrawa
sufficient cash on amount in cash than what the message and asks
l
hand to fulfill the on hand; system currently customer to choose
request System is has a different amount
requesting a
withdrawal
amount

System displays an
Choose an
System verifies appropriate
System is amount that the
that customer's message and offers
Withdrawa requesting a system currently
balance is customer the option
l withdrawal has but which is
sufficient to fulfill of choosing to do
ammount greater than the
the request another transaction
account balance
or not.

Withdrawa A withdrawal System is Press "Cancel" System displays an

l transaction can be displaying menu key appropriate
cancelled by the of account message and offers
customer any time types customer the option
prior to choosing of choosing to do
the dollar amount another transaction
 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

or not.

System displays an
A withdrawal
appropriate
transaction can be System is
message and offers
Withdrawa cancelled by the displaying menu Press "Cancel"
customer the option
l customer any time of dollar key
of choosing to do
prior to choosing amounts
another transaction
the dollar amount
or not.

System asks Menu of

System displays a
customer to transaction Choose Deposit
Deposit menu of account
choose an account types is being transaction
types
to deposit to displayed

System asks System displays a

Menu of
customer to enter Choose checking request for the
Deposit account types is
a dollar amount to account customer to type a
being displayed
deposit dollar amount

System is
displaying a
System asks Enter a System requests
request for the
Deposit customer to insert legitimate dollar that customer insert
customer to
an envelope amount an envelope
type a dollar
amount

Deposit System performs a System is Insert an System accepts

legitimate deposit requesting that envelope envelope;
transaction customer insert System prints a
properly an envelope correct receipt
showing amount and
correct updated
balance;
System records
transaction correctly
in the log (showing
 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

message to the
bank, approval back,
and acceptance of
the envelope)

System displays an
A deposit
appropriate
transaction can be System is
message and offers
cancelled by the displaying menu Press "Cancel"
Deposit customer the option
customer any time of account key
of choosing to do
prior to inserting types
another transaction
an envelope
or not.

System displays an
A deposit
System is appropriate
transaction can be
requesting message and offers
cancelled by the Press "Cancel"
Deposit customer to customer the option
customer any time key
enter a dollar of choosing to do
prior to inserting
amount another transaction
an envelope
or not.

System displays an
A deposit
System is appropriate
transaction can be
requesting message and offers
cancelled by the Press "Cancel"
Deposit customer to customer the option
customer any time key
insert an of choosing to do
prior to inserting
envelope another transaction
an envelope
or not.

A deposit System displays an

transaction is System is appropriate
cancelled requesting Wait for the message and offers
Deposit automatically if an customer to request to time customer the option
envelope is not insert an out of choosing to do
inserted within a envelope another transaction
reasonable time or not.
 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

System asks Menu of System displays a

customer to transaction Choose Transfer menu of account
Transfer
choose an account types is being transaction types specifying
to transfer from displayed transfer from

Menu of
System asks System displays a
account types
customer to Choose checking menu of account
Transfer to transfer from
choose an account account types specifying
is being
to transfer to transfer to
displayed

System asks Menu of System displays a

customer to enter account types Choose savings request for the
Transfer
a dollar amount to to transfer to is account customer to type a
transfer being displayed dollar amount

System prints a
correct receipt
showing amount and
System is
correct updated
System performs a displaying a
Enter a balance;
legitimate transfer request for the
Transfer legitimate dollar System records
transaction customer to
amount transaction correctly
properly type a dollar
in the log (showing
amount
both message to the
bank and approval
back)

System displays an
A transfer
System is appropriate
transaction can be
displaying menu message and offers
cancelled by the Press "Cancel"
Transfer of account customer the option
customer any time key
types specifying of choosing to do
prior to entering
transfer from another transaction
dollar amount
or not.

Transfer A transfer System is Press "Cancel" System displays an

 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

appropriate
transaction can be
displaying menu message and offers
cancelled by the
of account customer the option
customer any time key
types specifying of choosing to do
prior to entering
transfer to another transaction
dollar amount
or not.

System displays an
A transfer
System is appropriate
transaction can be
requesting message and offers
cancelled by the Press "Cancel"
Transfer customer to customer the option
customer any time key
enter a dollar of choosing to do
prior to entering
amount another transaction
dollar amount
or not.

System asks Menu of

System displays a
customer to transaction Choose Inquiry
Inquiry menu of account
choose an account types is being transaction
types
to inquire about displayed

System prints a
correct receipt
showing correct
System performs a System is balance;
legitimate inquiry displaying menu Choose checking System records
Inquiry
transaction of account account transaction correctly
properly types in the log (showing
both message to the
bank and approval
back)

Inquiry An inquiry System is Press "Cancel" System displays an

transaction can be displaying menu key appropriate
cancelled by the of account message and offers
customer any time types customer the option
prior to choosing of choosing to do
an account another transaction
 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

or not.

Enter an
incorrect PIN;
Attempt an
Invalid PIN Customer is asked inquiry Customer is asked to
Extension to reenter PIN transaction on re-enter PIN
the customer's
checking
account

Request to re- Original transaction

Invalid PIN Correct re-entry of
enter PIN is Enter correct PIN completes
Extension PIN is accepted
being displayed successfully

An incorrect PIN
A correctly re-
has been re-
entered PIN is This transaction
Invalid PIN entered and Perform another
used for completes
Extension transaction transaction
subsequent successfully as well
completed
transactions
normally

An appropriate
Incorrect re-entry Request to re- message is
Invalid PIN Enter incorrect
of PIN is not enter PIN is displayed and re-
Extension PIN
accepted being displayed entry of the PIN is
again requested

Enter incorrect
Correct re-entry of Request to re- PIN the first Original transaction
Invalid PIN
PIN on the second enter PIN is time, then completes
Extension
try is accepted being displayed correct PIN the successfully
second time

Invalid PIN Correct re-entry of Request to re- Enter incorrect Original transaction
Extension PIN on the third try enter PIN is PIN the first time completes
is accepted being displayed and second successfully
times, then
 Function Being Initial System
Use Case Input Expected Output
Tested State

System is started
System Activate the "on" System requests
when the switch is System is off
Startup switch initial cash amount
turned "on"

correct PIN the

third time

An appropriate
Three incorrect re- message is
entries of PIN Request to re- displayed;
Invalid PIN Enter incorrect
result in retaining enter PIN is Card is retained by
Extension PIN three times
card and aborting being displayed machine;
transaction Session is
terminated

Analysis Classes
An initial reading of the use cases suggests that the following will be part of the system.

• A controller object representing the ATM itself (managing the boundary

objects listed below.)

• Boundary objects representing the individual component parts of the ATM:

o Operator panel.
o Card reader.
o Customer console, consisting of a display and keyboard.
o Network connection to the bank.
o Cash dispenser.
o Envelope acceptor.
o Receipt printer.

• Controller objects corresponding to use cases. (Note: class ATM can handle
the Startup and Shutdown use cases itself, so these do not give rise to
separate objects here.)
o Session
o Transaction (abstract generalization, responsible for common features,
with concrete specializations responsible for type-specific portions)
 • An entity object representing the information encoded on the ATM card
inserted by customer.
• An entity object representing the log of transactions maintained by the
machine.

This leads to the following diagram of analysis classes:

Click on a class icon to go to links to various kinds of information about it

Class Diagram for Example ATM System

Shown below is the class diagram for the ATM system. The basic structure of the class diagram
arises from the responsibilities and relationships discovered when doing the CRC cards and
Interaction Diagrams. (If a class uses another class as a collaborator, or sends a message to an
object of that class during an Interaction, then there must either be an association linking objects
of those classes, or linking the "sending" class to an object which provides access to an object of
the "receiving" class.)

In the case of the ATM system, one of the responsibilities of the ATM is to provide access to its
component parts for Session and Transaction objects; thus, Session and Transaction have
associations to ATM, which in turn has associations to the classes representing the individual
component parts. (Explicit "uses" links between Session and Transaction, on the one hand, and
the component parts of the ATM, on the other hand, have been omitted from the diagram to
avoid making it excessively cluttered.)

The need for the various classes in the diagram was discovered at various points in the design
process.

• Some classes were discovered when doing analysis (see the Analysis Class
Diagram developed earlier.)
• Some classes were discovered when doing CRC cards
o Message - used to represent a message to the bank.
o Receipt - used to encapsulate information to be printed on a receipt.
o Status - used to represent return value from message to the bank.
o Balances - used to record balance information returned by the bank.

• Some classes were discovered when doing detailed design or writing code
o Money - used to represent money amounts, in numerous places.
o AccountInformation - contains names of various types of accounts
customer can choose from

That is, OO design is not a "waterfall" process - discoveries made when doing detailed design
and coding can impact overall system design.

To prevent the diagram from becoming overly large, only the name of each class is shown - the
attribute and behavior "compartments" are shown in the detailed design, but are omitted here.
Click on a class icon for links to further information about it

State Charts for Example ATM System

Three of the objects we have identified have behavior that is sufficiently complex to warrant
developing a State Chart for them. (These are the objects that were identified as the major
controller objects.)
• The object representing the machine itself (responsible for the System
Startup and Shutdown use cases)
• Objects representing a customer session (one per session) (responsible for
the Session use case)
• Objects representing an individual transaction (one per transaction)
(responsible for the Transaction use case, use cases for the specific types of
transaction, and Invalid PIN extension).
 Package Diagram for Example ATM System
The package diagram shows how the various classes are grouped into packages. There are two
"top-level" classes - ATMMain and ATMApplet - which allow the system to be run
(respectively) as an application or as an Applet. (Only one of the two would be instantiated in
any particular use of the system.)

Each of these classes, in turn, depends on the package atm which contains the class ATM that
represents the system as a whole, and the class Session that represents one session. ATM
depends on Session, and vice versa - since the ATM creates Sessions, and each Session, in turn,
uses the ATM to interact with the customer.

The subpackage transaction contains the classes used to represent individual transactions that a
customer initiates. The class Session depends on the transaction package because it creates
individual transaction objects. These, in turn, again depend on the ATM to interact with the
customer.

The subpackage physical contains the classes that represent the various physical components of
the ATM. For the purposes of this simulation, these are simulated by a GUI. A real ATM would
have quite different classes in this package - classes that actually control its physical
components. The class ATM makes use of these components, and Session and the various kinds
of transaction gain access to them through ATM to actually perform the needed operations.

Finally, the package banking contains classes that represent the banking enterprise itself and the
information communicated back and forth between the ATM and the bank - i.e. classes which
might be the same in a totally different implementation of an ATM that interacts with the same
bank.

This is, of course, a simulation. However, most of the code that is specific to the simulation
resides in the package physical, plus the two top-level classes. Presumably, the other classes and
packages might be similar in a real system.
Screen Shots
Main Screen
Login Screen
Account Selectiom Screen
Savings Account Screen
Balance Enquiry Screen
Satement Print Screen
Cash WithDraw Screen
Getting Recipt After WithDraw