Future Banking E-Transactions

1.INTRODUCTION
The application E- Transaction interface is designed to serve as the common user interface
between the banks. The main Vision of this project is to eliminate all the diversities
amongst banks, which generally client faces at the time of any transaction. By doing so
Client will used to only one Systematic Standard way of banking and there by they will be
at ease using this interface. The kind of functionality its capable of providing also reveals
the kind of banking facilities that a customer could get online. Of course, the bank that
implements this solution decides the features available to customers.

1.1 EXISTING SYSTEM:

Lets consider a condition when a bank customer is having bank accounts in more than
one bank. The online banking system available at present is bank specific. Each bank is
having its own interface to interact with the bank. A customer can login to the bank and
make the transactions using the online banking provided by the bank. The way he
interacts with different banks varies. The user must learn how to interact with each
system.

1.1.1 Limitations of Existing System:

A user requires accessing the system on the fly. The user interfaces designed by the
different banks will confuse the user. He requires to learn how to use each and every user
interface of the bank in which he is having accounts. This process may be time consuming
and too irritating for the user also. When he transfers the accounts, He may probably
prone to click the different action when shifting from one bank user interface to other.

1.2 PROPOSED SYSTEM:

The e-Transaction Interface provides the following system features.

This system provides a Common User Interface for the customers to log on to any
bank.

Here the user interface is Graphical User Interface.

This application is a Web based Application.

Being a web based application it doesnt require any client side installation.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

Any number of users can interact with the system simultaneously.

Eradicates the time consumed to learn how to use all the user interfaces of every
bank in which a customer is having account.

The transactions are secure.

1.2.1 Advantages Over Existing System:

The new system is cost effective

Improved productivity and service and services.

Enhance user interface.

Improved information presentation and durability.

Upgraded systems reliability, availability and flexibility.

Address human factors for better and uses acceptance.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

2. LITERATURE SURVEY
2.1 TECHNOLOGIES USED
2.1.1 Java
Java is a programming language, a runtime system, a set of development tools, an
application programming interface (API). The relationship between these elements is
depicted in figure.
The Java API contains predefined software packages with numerous platformindependent "hooks" into the native windowing and networking capabilities of the host
operating system. The Java API provides a single common API across all operating
system to which Java is ported.
The keys to Java's portability are its run time system, and its API. The run time system is
very compact, evolving from earlier Sun efforts to build a software platform for consumer
electronics. Because this platform was not designed around any existing microprocessor,
it was built from scratch to be simple and efficient. The fact that it was not tied to a given
hardware architecture enabled it to be architecture neutral. The Simple, efficient, compact
and architectural neutral nature of the runtime system allows it to be highly portable and
still provide effective performance.
The powerful windowing and networking features included in the Java API make it easier
for programmers to develop software that is both attractive and platform independent. For
example, Adam is a programming language that is highly standardized and supported on
most operating systems. Yet Adam applications are not very portable. This is because
Adam does not come with a common API that supports windowing and networking on all
platforms. Java differs from Adam and all other programming languages in that there is
one universal, but powerful, Java API for all operating systems platforms. That is why
Java is the most portable language.
Javas Magic: The Byte Code:
The key that allows java to solve both the security and the portability problems just
described is that the output of the java compiler is not an executable code. Rather, it is
Byte Code. Byte Code is a highly optimized set of instructions designed to be executed by
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

virtual machine that the java Run-time system emulates. This may come as it of surprise
as you know c++ is compiled, not interpreted-mostly because of performance concerns.
However, the fact that a java program is interpreted helps solve the major problems
associated with downloading the program over the Internet.
Here is why java was designed to be interpreted language. Because java programs are
interpreted rather than compiled .It is easier to run them in wide variety of environments.
Only the java runtime system needs to be implemented for each platform. Once the
runtime package exists for a given system any java program can run on it. If java were a
compiled langu8age then different versions of the same program will have to exist for
each type of CPU connected to the Internet. Thus interpretation is the easiest way to
create truly portable programs. Although java was designed to be interpreted, there is
technically nothing about java that prevents on the fly compilation of Byte Code into
native code. However, even if dynamic compilation were applied to Byte Code, the
portability and safety would still apply, because the run time system would still be in
charge of the execution environment.
The Java Buzz Words
No discussion of the genesis of java is complete without a look at the java buzzwords.
Although the fundamentals that necessitated the invention of java are portability and
security, there are other factors that played an important role on molding the final form of
the language. The java in the following list of buzzwords summed up the key
considerations.
Simple
Portable
Object-oriented
Robust
Multithreaded
Architectural-neutral
High performance
Distributed
Dynamic

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

2.1.2 JDBC
The database is the most important component of a company's information services
infrastructure. It is heart of the applications on which a company depends for its survival.
Any programming language must be able to provide an application with access to these
databases if it is to be considered a serious programming language.
The issues surrounding database access are often very difficult; other languages use either
proprietary APIs specific to individual databases or complex universal APIs such as
ODBC. Before starting any program the must be a need to used through data modeling
and database design.
JDBC Interfaces
JDBC defines eight interfaces that must be implemented by a driver in order to be JDBCcompliant:
i.

java.sql.Driver.

ii.

java.sql.Connection.

iii.

java.sql.Statement.

iv.

java.sql.PreparedStatement.

v.

java.sql.CallableStatement.

vi.

java.sql.ResultSet.

vii.

java.sql.ResultSetMetaData.

viii.

java.sql.DatabaseMetaData.

JDBC Driver Types

JDBC-ODBC Bridge:
ODBC driver is the only driver that can be used with the multiple databases and is vendor
independent. The ODBC interface remains constant no matter which database is used.
This means that this type of JDBC driver only needs to speak only one language ODBC.
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

Native-API -Party-Java Driver:

This makes use of local native libraries to communicate with the database. The driver
does this by making call to the locally installed native call level interface (CLI). The CLI
libraries are responsible for the actual communication with the database server.
JDBC-Net-All-Java-Driver:
The main difference when using this driver is that the native CLI libraries are placed on a
remote server and the driver uses a network protocol to facilitate communication between
the application and the driver .All c communication between the application and the
database server are 100% java to java. Communication between the database itself and the
server processes is still done with a native database CLI.
Native-Protocol-All-Java-Driver:
This kind of driver converts JDBC calls into the network protocol used by DBMS
directly. This allows a direct call from the client machine to the DBMS server and is a
practical solution for Internet access. Since many of these protocols are proprietary, the
database vendors themselves will be the primary source and database vendors have these
in progress.
Servlets
In the early days of the web, a server could dynamically construct a page by creating a
separate process to handle each client request. The process would open connection to one
or more databases in order to obtain the necessary information. It communicated with the
web server via an interface known as the Common Gateway Interface (CGI) .CGI allowed
the separate process to read data from HTTP request andwrite data to the HTTP response.
A variety of different languages were used to build CGI programs including C, C++ and
Perl.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

However, CGI suffered

serious performance problems. Creating a separate process for

each request was expensive, in terms of the processor and resources. It was also expensive
to open and close database connections for each request.

Servlets offer several advantages over CGI:

Performance is significantly better. Servlets execute within the address space of a web
browser. Creating a separate process to handle each request isnt necessary.
Servlets are platform-independent, because they are written in java. Several web servers,
from vendors such as Sun, Netscape and Microsoft offers the Servlets API. Programs
developed for this API can be moved to any of these environments without recompilation.
The java security manager on the server enforces a set of restrictions to protect the
resources on a server machine. You will see that some servlets are trusted and others are
un trusted. The full functionality of the class libraries is available to a servlet.
The life cycle of a servlet:
Three methods are central to the cycle of a servlet:

Init ()

Service ()

Destroy ()

They are implemented by every servlet and are invoked at specific times by the server.
Consider next a typical user scenario, to understand when these methods are called.
First, assume that a user enters a Uniform Resource Locator (URL) to the web browser.
The Browser then generates a HTTP request for this URL and sends it to the appropriate
server.
Second, the web server receives this HTTP request. The server maps this request to a
particular servlet. This servlet is dynamically retrieved and located into the address space
of the server.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

Third, the server invokes the init () method of the servlet. This method is invoked only
when the servlet is first loaded into the memory. You will see the initialization parameters
can be passed to the servlet so that it may configure itself.
Fourth, the server invokes the servlets service () method, which is called to process the
HTTP request. You will see that the servlet can read data that has been provided in the
HTTP request, and may also formulate an HTTP response for the client.
The servlet remains in the servers address space and is available to process any other
HTTP requests received from clients. The service () method is called for each HTTP
request.
Finally the server may decide to unload the servlet from its memory. The algorithms by
which this determination is made are specific to each server. The server calls destroy ()
method to relinquish any resources, such as file handlers that are allocated for a servlet.
Important data may be saved to a persistent store. The memory allocated for the servlet
and its objects can then be garbage collected.
Servlet Architecture Overview:
The central abstraction in the JSDK is the servlet interface. All servlets implements this
interface, either directly or more commonly by extending a class that implements it such
as HTTP servlet. The servlet interface provides for methods that manage the servlet and
its developing a servlet.
When a servlet accepts a call from client it receives two object one is servlet request and
the other is a servlet response. The servlet request class encapsulates the communication
from the back to the client.
The servlet request interface allows the servlet access to the information such as the
names of the parameters passed in by the client, the protocol (scheme) being used by the
client, and the names of the remote host that made the request and the server that received
it. It also provides the servlet with access to the input stream. Servlet classes of servlet
request allow the servlet to retrieve more protocol specific data. Input stream, through
which the servlet gets data from clients that are using application, protocols such as the
HTTP POST and PUT methods. Subclasses of servlet request allow the servlet to retrieve
more protocol specific data.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

The Servlet Response interfaces give the servlet methods to the client. It allows the servlet
to set the content length and mime type of the reply and provides an output stream.
Servlet output stream and a writer through which the servlet can send the reply data.
Subclasses of Servlet Response give the servlet more protocol specific capabilities. For
example, HTTP Servlet Response contains methods that allow the servlet to manipulate
the HTTP specific header information.
Services load and run servlets, which then accept zero or more requests from clients and
return data to them. They can also remove servlets. These are the steps of a servlets life
cycle.
When a service () loads a servlet, it runs the servlets init () method. Even though most
servlets are run in multi-threaded services, there are no concurrency issues during servlet
initialization. This is because the service calls the init () method once, when it loads the
servlet, and will not call it again unless it is reloading the servlet. The service cannot
reload a servlet until after it has removed the servlet by calling the destroy () method.
Initialization is allowed to complete before the client requests are handled or the servlet is
destroyed.
Each clients request has its call to the service () method run in its own servlet. The
method receives the clients request and sends the client its response. Servlets can run
multiple service () methods at a time .It is important therefore that service () methods be
written a thread -safe manner. Servlets until they are removed from the service. When a
service removes a servlet, it removes a servlet, it runs the servlet destroy () method. The
method is run once; the service3 will not run it again until after it reloads the reinitializes
the servlet. When the destroy () method runs, however, other threads might be running
service request .If in cleaning up, it is necessary to access shared resources that access
should be synchronized.
2.1.3 ORACLE
ORACLE is a relational Database management system that as a transparent interface
between the physical storage and logical presentation of data and provides the user with a
set of flexible & sophisticated tools to perform the operations basing on data and the data
structures.
Oracle is a modular system that consists of the Oracle database and several functional
packages.
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

10

Oracle tools do 4 major kinds of work:

Database Management

Data access & manipulation

Programming

For handling information the user can use these tools to:

Define a database

Query a database

Add, update, edit & delete data

Modify the structure of database

Export & Import data.

Connectivity between back-end & front-end

Database Management tools:

This usually includes the core programming of oracle's database management system .The
oracle database with its associated tables &views are stored in the oracle data dictionary.
The data dictionary stores information related to every fact of the database system
Data access & manipulation tools:
ORACLE uses the SQL command set for the purpose of data access & its manipulation.
Structured Query Language (SQL) includes all commands, which are used for data
access.
Reason for choosing ORACLE:

Applications developed on Oracle are completely portable to other versions of

programming. Programmers create a complex application in a single user
environment and then move it to multi-user platform.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

11

Oracle has several features that ensure integrity of user database. Database can be
made secure by restrictions access to only authorized users using the tools
available in ORACLE.

Oracle can perform effectively

on large database .It offers unique clustering

technique for storing data on the disk.

Oracle database

works

effectively

in

an

Intranet/Internet environment.

Since the Internet applications demands the data to be secure, ORACLE can be
chosen as the right tools for maintaining databases.

2.1.4 Java Script

JAVA script enables you to embed commands in an HTML page. When a compatible web
browser, such as Netscape Navigator 2 or higher or Internet explorer 3 or higher,
downloads the page, your JAVA script commands are loaded by the web browser as part
of the HTML document. These commands can be triggered when the user clicks page
items, manipulates gadgets and fields in an HTML form, or moves through the page
history list.
JAVA script is an interpreted language - the computer must evaluate the program every
time it is run. You embed your JavaScript commands within an HTML page, and any
browser that supports JavaScript can interprets the commands and act on them. JavaScript
is powerful and simple.
Scripting Language:
JavaScript enables Web authors to write small scripts that execute on the users browsers
rather than on the server. An application that collects data from a form and then posts it to
the server can validate the data for completeness and correctness, for example, before
sending it to the server. This can greatly improve the performance of the browsing session
because users dont have to send data to the server until it has been verified as correct.
Another important Web browser scripting languages such as JavaScript comes as a result
of the increased functionality being introduced for Web browsers in the form of Java
applets, plug-ins, Dynamic HTML elements, Active X Controls, and VRML objects and
Dept.of CSE
MREC(Autonomous)

Future Banking E-Transactions

12

worlds. Web authors can use each of these things to add extra functions and interactivity
to a Web page. Scripting language acts as the glue that binds everything together.
A Web page might use an HTML form to get some user input and then set a parameter for
a Java applet based on that input. It is usually a script that carries out.
Use of JavaScript:
JavaScript provides a fairly complete set of built-in functions and commands, enabling
you to perform math calculations, manipulate strings, play sounds, open new windows
and new URLs, and access and verify user input to your Web forms.
Code to perform these actions can be embedded in a page and executed when the page is
loaded. We can also write functions containing code that is triggered by events you
specify. You can write a JavaScript method that is called when the user clicks submit
button of a form, for example, or one that is activate when the user clicks a hyperlink on
the active page.
JavaScript can also set the attributes, or properties, of Web page elements, Active-x
controls, Java applets and other objects present in the browser.
This way, you can change the behavior of plug-ins or other objects without having to
rewrite them. Your JavaScript code could automatically set the text of an Active-X Label
Control, for example, based on what time the page is viewed.
JavaScript commands are embedded in your HTML documents. Embedding JavaScript in
your pages requires only one new HTML element: <SCRIPT> and </SCRIPT>. The
<SCRIPT> element takes the attribute LANGUAGE, which specifies the scripting
language to use when evaluating the script, and SRC, which can be used to load a script
from an external source.
The following are some simple rules to help you understand how the language is
structured:

JavaScript is case sensitive.

JavaScript is flexible about statements. A single statement can cover multiple lines,
and you can put multiple short statements on a single line - just make sure to add a
semicolon (;) at the end of each statement.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

13

Braces (the {and} characters) group statements into blocks; A block may be the body
of a function or a section of code that gets executed in a loop or as part of the
conditional test.

JavaScript is designed to resemble Java, which, in turn, looks a lot like C and C++. The
difference is that Java was built as a General-purpose object language; JavaScript, on the
other hand, is intended to provide a quicker and simpler language for enhancing Web
pages and servers.
2.1.5 Web Browser
A web browser is a software application for retrieving, presenting, and traversing
information resources on the World Wide Web. An information resource is identified by a
Uniform Resource Identifier (URI) and may be a web page, image, video, or other piece
of content. Hyperlinks present in resources enable users to easily navigate their browsers
to related resources.
2.1.6 Tomcat
Apache Tomcat is the servlet container that is used in the official reference
implementation for the java servlet and java server pages technologies. The java servlet
and java server pages specifications are developed by Sun under the java community
process.
Tomcat 5 implements the servlet 2.4 and java server pages 2.0 specifications includes
many additional features that make it useful platform for developing and deploying web
applications and web services.
Installing Tomcat
Installing tomcat on windows can be done easily using the windows installer. Tomcat will
be installed as a windows service no matter what setting is selected. Using the checkbox
on the component page sets the service as auto startup, so that tomcat is automatically
started when windows starts. For optimal security, the service should be affected by a
separate user, with reduced permissions.

Java location: The installer will use the registry or the JAVA_HOME environment
variable to determine the base path of the JDK or a JRE. If only a JRE is specified.
Tomcat will run but will be unable to compile JSP pages at runtime.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

14

Either all webapps will need to be precompiled, or the lib\tools. Jar file from a
JDK installation must be copied to the common\lib path of the tomcat installation.

Architecture Overview
Server:A server represents the whole container. A server element represents the entire
Catalina servlet container. Therefore, it must be the single outermost element in the
conf/server.xml configuration file. Its attributes represent the characteristics of a servlet
container as a whole. Tomcat provides a default implementation of the server interface,
and this is rarely customized by the users.
Engine:An engine represents request processing pipeline for a specific service. As a
service may have multiple connectors, the engine receive and processes all requests from
these connectors to exactly one engine. The service element is rarely customized by users,
as the default implementation is simple and sufficient.
Host:Host is an association of a network name to the tomcat server. An engine may
contain multiple hosts. Users rarely create custom hosts because the standard host
implementation provides significant additional functionality.

Connector: connector handles communications with the client. There are multiple
connectors available with tomcat, all of which implement the connector interface. These
include the coyote connector which is used for most HTTP traffic, especially when
running tomcat as a standalone server, and the JK2 connector which implements the AJP
protocol used when connecting tomcat to an apache HTTP server. Creating a customized
connector is significant effort.
Context: context represents a web application. A host may contain multiple contexts, each
with a unique path. The context interface may be implemented to create custom contexts.
But this is rarely the case because the standard context provides significant additional
functionality.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

15

3. SYSTEM ANALYSIS
3.1 SCOPE OF THE PROJECT
The e-Transaction Interface is the designed targeted at the future banking solution for the
users who is having multiple bank accounts at the multiple banks. This interface integrates
all existing banks and provide business solutions for both retail and corporate.
The main Vision of this project is to eliminate all the diversities amongst banks, which
generally client faces at the time of any transaction. By doing so Client will used to only
one Systematic Standard way of banking and there by they will be at ease using this
interface.

3.2 SOFTWARE REQUIREMENT SPECIFICATION

3.2.1 SDLC Methodologies
This document play a vital role in the development of life cycle (SDLC) as it describes
the complete requirement of the system. It means for use by developers and will be the
basic during testing phase. Any changes made to the requirements in the future will have
to go through formal change approval process.
A hybrid is the combination of two or more different things, aimed at achieving a
particular objective or goal. HYBRID MODEL is generally for large systems usually
made up of several sub-systems and the same process model does not have to be used for
Dept.of CSE
MREC(Autonomous)

Future Banking E-Transactions

16

all subsystems. The Hybrid model combines the top-down and bottom-up models. Using
the menu driven application example, the design team primarily works top down, but the
development team identifies two types of lower level components to work on at the same
time as the high-level components. Hybrid approach to software reuse in an ongoing
project that addresses a challenging software engineering task. The approach is driven by
an architectural design and makes use of both code components and program synthesis
technology.
The first type of low-level component would be existing software modules from other
projects that can be reused in the new project. This approach allows the development team
to make changes to the system early in the project if problems occur with the high risk
components. A new data access technique the team has not used before or a component
that might require high amounts of CPU processing time is an example of a high-risk lowlevel component. This hybrid model is used to access project risks that are related to
programming, human and material factors. In addition, the implemented programming
parts are tested for the purpose of assuring of their appropriate application.The hybrid
model is dependent on the five software development models such as waterfall, spiral,
iteration, V-shape and extreme programming models. The following diagram shows how a
hybrid model acts like:

Fig 3.1: Hybrid Model

Developers Responsibilities Overview:
The developer is responsible for:

Developing the system, which meets the SRS and solving all the requirements of
the system

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

17

Demonstrating the system and installing the system at client's location after the
acceptance testing is successful.

Submitting the required user manual describing the system interfaces to work on it

and also the documents of the system.

Conducting any user training that might be needed for using the system.
Maintaining the system for a period of one year after installation.

Functional Requirements is the specification of the function that the system must support.
Where as non functional requirements is the constraint on the operation of the system that
is not related directly to function of system.
Functional Requirements:
Inputs: The major inputs for the E-transaction Interface are the user name and passwords
of the customer, Administrator and the Banker, The account number and the bank name
associated with it, Transaction Passwords. Transaction Amount.
Output: The outputs are the Amount that is transferred between the accounts. The
verification reports of the bank. Bank Statements, Account status.
Performance Requirements:
Performance is measured in terms of ease of use of user interface.
The document is prepared keeping is view of the academic constructs of my Bachelors
Degree / Masters Degree from university as partial fulfillment of my academic purpose
the document specifies the general procedure that that has been followed by me, while the
system was studied and developed. The general document was provided by the industry as
a reference guide to understand my responsibilities in developing the system, with respect
to the requirements that have been pin pointed to get the exact structure of the system as
stated by the actual client.
The system as stated by my project leader the actual standards of the specification were
desired by conducting a series of interviews and questionnaires. The collected information
was organized to form the specification document and then was modeled to suite the
standards of the system as intended.
3.2.1 Software Requirements:
Server Side:
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

18

Microsoft Windows 2000 Prof

Internet explorer 5.0 or above or Netscape navigator.

Oracle 9i or Later versions.

JDK 1.4 or Later versions.

Apache Tomcat Web Server 4.0 or above.

TCP/IP Protocol suite.

Client Side:

Any Web Browser on any operating system.

3.2.2 Hardware Requirements:

Pentium IV Processor.
256 MB RAM.
40GB Hard Disk space.
Ethernet card with an Internet and Internet zone.

3.3 FEASABILITY STUDY

3.3.1Techinical Feasibility:
Evaluating the technical feasibility is the trickiest part of a feasibility study. This is
because, .at this point in time, not too many detailed design of the system, making it
difficult to access issues like performance, costs on (on account of the kind of technology
to be deployed) etc. A number of issues have to be considered while doing a technical
analysis.
i)

Understand the different technologies involved in the proposed system:

Before commencing the project, we have to be very clear about what are the
technologies that are to be required for the development of the new system.

ii)

Find out whether the organization currently possesses the required technologies:
o Is the required technology available with the organization?
o If so is the capacity sufficient?
For instance

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

19

Will the current printer be able to handle the new reports and forms required for
the new system?
3.3.2 Operational Feasibility:
Proposed projects are beneficial only if they can be turned into information systems that
will meet the organizations operating requirements. Simply stated, this test of feasibility
asks if the system will work when it is developed and installed. Are there major barriers to
Implementation? Here are questions that will help test the operational feasibility of a
project:

Is there sufficient support for the project from management from users? If the
current system is well liked and used to the extent that persons will not be able to
see reasons for change, there may be resistance.

Are the current business methods acceptable to the user? If they are not, Users
may welcome a change that will bring about a more operational and useful
systems.

Have the user been involved in the planning and development of the project

Early involvement reduces the chances of resistance to the system and in

General and increases the likelihood of successful project.

Since the proposed system was to help reduce the hardships encountered. In the existing
manual system, the new system was considered to be operational feasible.
3.3.3 Economic Feasibility:
Economic feasibility attempts 2 weigh the costs of developing and implementing a new
system, against the benefits that would accrue from having the new system in place. This
feasibility study gives the top management the economic justification for the new system.
A simple economic analysis which gives the actual comparison of costs and benefits are
much more meaningful in this case. In addition, this proves to be a useful point of
reference to compare actual costs as the project progresses. There could be various types
of intangible benefits on account of automation. These could include increased customer
satisfaction, improvement in product quality better decision making timeliness of
information, expediting activities, improved accuracy of operations, better documentation
and record keeping, faster retrieval of information, better employee morale.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

20

4.SYSTEM DESIGN
4.1 OVERALLDESIGN
Our Proposed system uses the MVC (Model View Controller Architecture for the project
Development).
Model View Controller Architecture:
MVC Architecture Defines that The controller is separated from the system model and View.
It is composed of three different layers. Being a Web based architecture. The User Interface is
completely separated from the entire Business Logic Layer. The database and business logic
are bounded to gather. The Database Layer and Business Logic Layer runs on the server
Machine and the User Interface Layer will run under the Client Machine. For developing the
User Interface we are having HTML and Java Script. For Business Login and Database
Connectivity Servlets and JSP are used. In the Backed the servlets and Jsps are connected to
Database through JDBC API. The web server plays a major role in connecting the client user
interface and the servlets and JSP.
Project Architecture

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

httpResponse

21

httpRequest

User Interface
(HTML / Java Script)

Servlets/JSPs
JDBC

Web Server
Oracle

Fig 4.1: Project Architecture

4.2UNIFIED MODELING LANGUAGE DIAGRAMS

The unified modeling language allows the software engineer to express an analysis model
using the modeling notation that is governed by a set of syntactic semantic and pragmatic
rules.
A UML system is represented using five different views that describe the system from
distinctly different perspective. Each view is defined by a set of diagram, which is as
follows.
User Model View

This view represents the system from the users perspective.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

22

The analysis representation describes a usage scenario from the end-users

perspective.

Structural model view

In this model the data and functionality are arrived from inside the system.

This model view models the static structures.

Behavioral Model View

It represents the dynamic of behavioral as parts of the system, depicting the

interactions of collection between various structural elements described in the
user model and structural model view.

Implementation Model View

In this the structural and behavioral as parts of the system are represented as
they are to be built.

Environmental Model View

In this the structural and behavioral aspects of the environment in which the system is to
be implemented are represented.
UML is specifically constructed through two different domains they are

UML Analysis modeling, which focuses on the user model and structural
model views of the system.

UML design modeling, which focuses on the behavioral modeling,

implementation modeling and environmental model views.

Use case Diagrams represent the functionality of the system from a users point of view.
Use cases are used during requirements elicitation and analysis to represent the
functionality of the system. Use cases focus on the behavior of the system from external
point of view.
Actors are external entities that interact with the system. Examples of actors include users
like administrator, bank customer etc., or another system like central database.
4.2.1 Er-Diagram

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

23
ID

ID

BID
CHECK

BNAME

BLOGIN

BANK

PWD

ACCNO

CID

BNAME
STATUS

REJECT
RELATED

ATYPE
ACTYPE

BNAME
ACCNO

ID

CLOGIN

BNAME
PWD

CUSTOMER

CNAME
TPW

ID

CID

STATUS

STATUS

BAL
PWD

ACNO
CREJECT

CID

BNAME

Fig 4.2: ER diagram for E-Transaction

4.2.2 Use Case Diagram

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

24

Fig 4.3: use case diagram for bank

Use case name

Login

Participating
actors

Customer, Admin, Banker

Flow of events

The Actor will give the user name and password to the system. The
system will verify the authentication.

Entry
Condition

The actor will enter the system by using username and password

Exit condition

If un authenticated should be exited

Quality
Requirements

Password must satisfy the complexity requirements.

Use case name

Bank Registration

Participating
actors

Admin

Flow of events

The administrator will all the details submitted by banker and creates
and place in the application.

Entry
Condition

Must satisfy all the norms given by the e-transaction interface site.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

25

Exit condition

Successful or Un successful completion of creation of account.

Quality
Requirements

All fields are mandatory.

Use case name

Customer Registration

Participating
actors

Customer

Flow of events

The customer must enter all his personal details.

Entry
Condition

View Home page

Exit condition

Registered customer should be successfully logged out. Error Message

should be displayed on Un successful creation.

Quality
Requirements

Best Error Handling techniques. Check on Mandatory fields.

Use case name

Amount Transaction

Participating
actors

Customer

Flow of events

The customer selects the target account and must give the amount to be
transferred across the accounts.

Entry
Condition

User should have an account and the destination account should be

valid one.

Exit condition

Transaction must be rolled back if exceptions are raised.

Quality
Requirements

Target account must be verified, amount entered must be valid. Cross

checking of account balance.

Use case name

Amount Transaction

Participating
actors

Customer

Flow of events

The customer selects the target account and must give the amount to be
transferred across the accounts.

Entry
Condition

User should have an account and the destination account should be

valid one.

Exit condition

Transaction must be rolled back if exceptions are raised.

Quality
Dept.of CSE

Target account must be verified, amount entered must be valid. Cross

MREC(Autonomous)

Future Banking E-Transactions

26

Requirements

checking of account balance.

Use case name

Account creation

Participating
actors

Customer

Flow of events

The customer must create the bank account by giving the necessary
data.

Entry
Condition

Actor must know the proper bank account number and the bank.

Exit condition

Not Applicable

Quality
Requirements

Not Applicable

Use case name

View Transaction Status

Participating
actors

Customer

Flow of events

The customer can view the whether the transaction is approved or

rejected..

Entry
Condition

Not Applicable.

Exit condition

Not Applicable

Quality
Requirements

Good Report Design

Use case name

Transaction Verification

Participating
actors

Banker

Flow of events

The Banker must verify the transaction before it was going to be

committed.

Entry
Condition

Banker must check the validity constraints

Exit condition

Banker must complete the task before exiting the system

Quality
Requirements

Not Applicable

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

27

Use case name

Account Verification

Participating
actors

Banker

Flow of events

The Banker can accept or reject the account that can be added to the
customer.

Entry
Condition

He must verify the account that is that account belongs to specified

person or not.

Exit condition

Not Applicable

Quality
Requirements

No Applicable

Use case name

Reports Generation

Participating
actors

Banker

Flow of events

The Banker can view the reports regarding the accounts and
transactions in specified time.

Entry
Condition

Duration of the Reports

Exit condition

Not Applicable

Quality
Requirements

Good Report Design

4.2.3 Class Diagrams

Class diagrams describe the structure of the system in terms of classes and objects. The
servlet api class diagram will be as follows.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

28

JSP: Implicit
Objects

Fig 4.4: class diagram for servlet API

Fig 4.5: class diagram for customer

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

29

Fig 4.6: class diagram for bank account

Fig 4.7: class diagram for transaction

4.2.4 Sequence Diagrams

Sequence Diagrams Represent the objects participating the interaction horizontally and
time vertically.

Sequence Diagram 1
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

30

: Login
Admin

: Create Bank Account

: Log Out

Use url
Press login button

Press Create Account

Time

Fig 4.8: sequence diagram for registration

Sequence Diagram 2

: Login

: Accounts

DB

Customer
Press login
button()

Get login page

()

Validate norms()
Press create accounts button()

Fig 4.9: sequence diagram for login

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

31

Sequence Diagram 3

:TX

: TXVerify

: DB

Customer
Press Amount submit ()

Wait for acceptance()

View last
transaction ()

Fig 4.10 sequence diagram to verify user

Sequence Diagram 4

: Login

Ban
ker

: TXValidate

:Account

: DB

Validate

Banker
Press login
button()
Press Accept/Reject
Button

Select Validate or Reject

Account()
Reports()

Fig 4.11 sequence diagram for transaction

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

32

4.3 DATA DICTIONARY

TABLES USED IN THIS PROJECT
Table Name: Bank
Column Name
Id
BName

Data type
Number
Varchar2
Tb 4.1: bank

Size
20
220

Description: This table stores the details about the bank identified by the id and with
associated Bank Name.
Table Name: Blogin
Column Name
Id
BID
PWD
BNAME
STATUS
Description:

Data type
Number
Varchar2
Varchar2
Varchar2
Number
Tb 4.2: bank login

Size
20
250
250
250
10

This table stores the login details of the bank.

Table Name: Clogin

Column Name
Id
CID
PWD
STATUS

Data type
Number
Varchar2
Varchar2
Number
Tb 4.3: customer login

Size
20
220
220
10

Description: This table stores the details about the Customer Login.
Table Name: CREJECT
Column Name
CID
PWD
ACCNO
BNAME

Data type
VARCHAR2
Varchar2
Varchar2
Varchar2
Tb 4.4: customer reject

Size
220
220
220
220

Description: This table stores the details about the accounts that were rejected by the
Administrator
Table Name: Customer
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

Column Name
Id
Accno
Atype
Cname
Bname
Bal
TPWD
Status

33

Data type
Varchar2
Varchar2
Varchar2
Varchar2
Varchar2
Number
Varchar2
Number
Tb 4.5: customer

Size
220
220
220
220
220
30
220
20

Description: This table stores the details about the Customer. It is effected when the
customer makes any transactions. The Bal field is effected when ever any withdraw, Deposit
or Transfer of money is done.
Table Name: Reject
Column Name
Cid
Accno
Actype
BName

Data type
Vachar2
Varchar2
Varchar2
Varchar2
Tb 4.6: create account

Size
220
220
220
220

Description: This table add an entry when any request from the customer for creating an
account is rejected by Administrator.
Table Name: taccept
Column Name
SCID
Sacno
Atype
Sbname
Sbal
Dcid
Dacno
dtype
DBal

Data type
Varchar2
Varchar2
Varchar2
Varchar2
Number
Varchar2
Varchar2
Varchar2
Varchar2
Tb 4.7: admin

Size
120
120
120
120
30
120
120
120
120

Description: This table adds an entry when ever a user transfers amount from one account to
another account. And must be accepted by the administrator.
Table Name: transfer
Column Name
Id
Saccno
Dept.of CSE

Data type
Number
Varchar2

Size
30
120
MREC(Autonomous)

Future Banking E-Transactions

Daccno
Amt
Atype
Dtype
Tpw
SBank
DBank

34

Varchar2
Number
Varchar2
Varchar2
Varchar2
Varchar2
Varchar2
Tb 4.8: transfer

120
30
120
120
120
120
120

Description: This table will be effected when a user transfers money between different
banks.

5.SYSTEM IMPLEMENTATION
5.1 MODULES DESCRIPTION:
5.1.1 Admin Module
Only an Administrator can have access to this module, He must accept or reject the
Banker who registered with the system. He performs the counter check on the banker who
applied for registration with the system. He must also authorize the pending user requests
also. If a user or banker registers with the system the administrator must authorize the
user or banker to register with the system. Finally it calls the sign out button, which will
take the administrator to the home page. The module will update the database after the
administrator has authorized or declined the user requests.
5.1.2 Banker Module
Through this module the banker can accept the request for registering the account of a
user with the system. And a banker can accept or decline any transaction from the user. If
a user requires to transfer some amount to any other account. The user request was first
sent to the banker. The banker verifies the request and then accepts or declines the
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

35

transaction. If he accepts the transaction then the transfer of funds starts. If he clicks on
decline then the request was rejected and notified to the user. In this module some special
care should be taken after the baker accepts the request. The transaction must be obey the
ACID properties. All the commands in the transaction must be executed successfully else
the entire process must be rolled back.
5.1.3 Customer Module
To become a customer to the system. The person must register with the system first. By
clicking on the sign in a person can have access to the application form, which consists of
the details about the person. Then the request is sent to the administrator. After the
administrator accepted the request from the customer, The customer can login to this
account. Then after logging in with the user name and password given by the
administrator. The system verifies the username and password with the database stored
and then it gives the access to the customer login page. The customer login page consists
of select account, create a new account, back and home page buttons. If a user requires to
register a new bank account. He clicks the new account and fills the particulars and click
on submit button. The request was sent to the specified bank admin for acceptance. After
acceptance the user can use the bank account for the funds transfer. The funds transfer
screen displays the current account balance in the bank and amount to be transferred and
the target account to which the funds to be transferred. The request is sent to the banker
for verification and acceptance. The funds are successfully transferred if the banker
accepts. The customer can also see the pending transfers. The present status of the transfer
from his login
5.2 SAMPLECODE
<HTML>
<HEAD>
<TITLE></TITLE>
</HEAD>
<script >
function call()
{
if(document.f.name.value==""){
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

36

alert("Please Enter Name");

document.f.name.setFocus=true;
return false;
}
if(document.f.pwd.value==""){
alert("Please Enter Ur Password");
return false;
}
}
</script>
<BODY bgcolor=#FFFFFF>

<center>
<BR><BR>
<font size="+2" color="#FF5C0F"><h2><b>WELCOME TO E-TRANSACTION
INTERFACE</b></h2></font>
<br>
<form method=post action="admincheck.jsp" name="f" onSubmit='return call()'>
<table>
<tr>
<td><b>Name:</b></td><td><input type="text" name="name" ></td>
</tr>
<tr><td>&nbsp;</td></tr>
<tr>
<td><b> Password:</b></td><td><input type="password" name="pwd"></td>
</tr>
</table>
<br><BR>
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

37

<input type="submit"
value="submit">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;
<input type="reset" value="reset">
</form>
<br>
</center>
</BODY>
</HTML>

6.SYSTEM TESTING
Testing is the process of detecting errors. Testing performs a very critical role for quality
assurance and for ensuring the reliability of software. The results of testing are used later
on during maintenance also.
The aim of testing is often to demonstrate that a program works by showing that it has no
errors. The basic purpose of testing phase is to detect the errors that may be present in the
program. Hence one should not start testing with the intent of showing that a program
works, but the intent should be to show that a program doesnt work. Testing is the
process of executing a program with the intent of finding errors.
Testing Objectives
The main objective of testing is to uncover a host of errors, systematically and with
minimum effort and time. Stating formally, we can say,
Testing is a process of executing a program with the intent of finding an error.
A successful test is one that uncovers an as yet undiscovered error.
A good test case is one that has a high probability of finding error, if it exists.
Dept.of CSE
MREC(Autonomous)

Future Banking E-Transactions

38

The tests are inadequate to detect possibly present errors.

The software more or less confirms to the quality and reliable standards.

6.1 TEST LEVELS

In order to uncover the errors present in different phases we have the concept of levels of
testing. The basic levels of testing are as shown below
Acceptance Testing
Client Needs
System Testing
Requirements
Design
Integration Testing
Code

Unit Testing

The philosophy behind testing is to find errors. Test cases are devised with this in mind. A
strategy employed for system testing is code testing.
6.1.1 Code Testing:
This strategy examines the logic of the program. To follow this method we developed
some test data that resulted in executing every instruction in the program and module i.e.
every path is tested. Systems are not designed as entire nor are they tested as single
systems. To ensure that the coding is perfect two types of testing is performed or for that
matter is performed or that matter is performed or for that matter is performed on all
systems.
Types Of Testing

Unit Testing
Link Testing

6.1.2 Unit Testing

Unit testing focuses verification effort on the smallest unit of software i.e. the module.
Using the detailed design and the process specifications testing is done to uncover errors
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

39

within the boundary of the module. All modules must be successful in the unit test before
the start of the integration testing begins.
In this project each service can be thought of a module. There are so many modules like
Login, HWAdmin, MasterAdmin, Normal User, and PManager. Giving different sets of
inputs has tested each module. When developing the module as well as finishing the
development so that each module works without any error. The inputs are validated when
accepting from the user.
In this application developer tests the programs up as system. Software units in a system
are the modules and routines that are assembled and integrated to form a specific function.
Unit testing is first done on modules, independent of one another to locate errors. This
enables to detect errors. Through this errors resulting from interaction between modules
initially avoided.

6.1.3 Link Testing

Link testing does not test software but rather the integration of each module in system.
The primary concern is the compatibility of each module. The Programmer tests where
modules are designed with different parameters, length, type etc.
6.1.4 Integration Testing
After the unit testing we have to perform integration testing. The goal here is to see if
modules can be integrated properly, the emphasis being on testing interfaces between
modules. This testing activity can be considered as testing the design and hence the
emphasis on testing module interactions.
In this project integrating all the modules forms the main system. When integrating all the
modules I have checked whether the integration effects working of any of the services by
giving different combinations of inputs with which the two services run perfectly before
Integration.
6.1.5 System Testing
Here the entire software system is tested. The reference document for this process is the
requirements document, and the goal os to see if software meets its requirements.
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

40

Here entire ATM has been tested against requirements of project and it is checked
whether all requirements of project have been satisfied or not.
6.1.6 Acceptance Testing
Acceptance Test is performed with realistic data of the client to demonstrate that the
software is working satisfactorily. Testing here is focused on external behavior of the
system; the internal logic of program is not emphasized.
In this project Network Management Of Database System I have collected some data
and tested whether project is working correctly or not.
Test cases should be selected so that the largest number of attributes of an equivalence
class is exercised at once. The testing phase is an important part of software development.
It is the process of finding errors and missing operations and also a complete verification
to determine whether the objectives are met and the user requirements are satisfied.

6.1.7 White Box Testing

This is a unit testing method where a unit will be taken at a time and tested thoroughly at
a statement level to find the maximum possible errors. I tested step wise every piece of
code, taking care that every statement in the code is executed at least once. The white box
testing is also called Glass Box Testing.
I have generated a list of test cases, sample data, which is used to check all possible
combinations of execution paths through the code at every module level.
6.1.8 Black Box Testing
This testing method considers a module as a single unit and checks the unit at interface
and communication with other modules rather getting into details at statement level. Here
the module will be treated as a block box that will take some input and generate output.
Output for a given set of input combinations are forwarded to other modules.
Criteria Satisfied by Test Cases
Test cases that reduced by a count that is greater than one, the number of additional test
cases that much be designed to achieve reasonable testing.
Test cases that tell us something about the presence or absence of classes of errors, rather
than an error associated only with the specific test at hand.
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

41

6.2 TEST CASES

6.2.1 Unit Testing:
Test Case
1

Name

Description Input Data

Expected
Output

Actual
Output

Test
Result

User

To verify
whether
user is a
register user
or not

User id and
password
with
validate
details

If user is
register
home page
will be
displayed

Home
page is
displayed

success

To verify
whether
Admin is a
register or
not

User id and
password
with
validate
details

If Valid
home page
will be
displayed

Home
page is
displayed

Login

Admin
Login

success

Tb 6.1:test cases for Unit Testing.

6.2.2 Integration Testing:
Test

Name

Case

Dept.of CSE

Descriptio
n

Input Data

Expected

Actual

Test

Output

Output

Result

MREC(Autonomous)

Future Banking E-Transactions

1

42

User

To verify

Insert login id

The

Process

with

whether

and password

process

checked

admin

process are

to perform

status

with

processing

transactions

must be

specified

or

and various

identified

completed

completed

processes.

Success

and
processing

Admin

To verify

Enter status of The

status
The

with user

whether the

the process

process

process is

status is

must be

done or

given or

finished or processing

not

still

Success

processing
Tb 6.2:test cases for Integration testing.
6.2.3 System Testing
Test Case

Name

Description

Input

Expected

Actual

Test

Data

Output

Output

Result
Success

Software

To verify

Run the

It should

It should

installation

whether

eclipse v6

display

display

supporting

version

window

window

screen

screen

s/w installed
or not
2

Hardware

Verify

Connect

Different

The home

Installation

whether

the server

modules

page will

supporting

and run

will be

be

softwares

the

displayed

displayed

are installed

program

Success

and
software is
recognized
by the
system
Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

43

Tb 6.3:test cases for System Testing.

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

44

7.OUTPUTS

Fig 7.1: home page

Fig 7.2: admin login

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

45

Fig 7.3: admins list

Fig 7.4: create new customer

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

46

Fig 7.5: customer login

Fig 7.6: customer request in process

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

47

Fig 7.7: create bank account

Fig 7.8: new user requests

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

48

Fig 7.9: bank admin request accepted

Fig 7.10: bank admin request declined

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

49

Fig 7.11: new user requests

Fig 7.12: user request accepted

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

50

Fig 7.13: banker login

Fig 7.14: select bank

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

51

Fig 7.15: enter account details

Fig 7.16: bank account login

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

52

Fig 7.17: banker list

Fig 7.18: list of accounts

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

53

Fig 7.19: select account type

Fig 7.20: list of transfer pendings

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

54

Fig 7.21: no records found

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

55

8. CONCLUSION
The FUTURE BANKING E-TRANSACTION was successfully designed and is tested
for accuracy and quality. During this project we have accomplished all the objectives and
this project meets the needs of the organization.
GOALS
1. Reduced entry work
2. Easy retrieval of information
3. Reduced errors due to human intervention
4. User friendly screens to enter the data
5. Web enabled.
6. Fast finding of information requested
By this project, we provide various facilities for customer as well as POS agent and staff
in their respective section of work. Customer can be able to give feedback, view menu,
deals and even about the restaurant. The work for POS agent has reduced by making the
order processing through online. Even for the kitchen staff the work is made easy by
providing the status update field.

8.1 LIMITATIONS OF THE SYSTEM:

1. System works in all platforms and its compatible environments.
2. Advanced techniques are not used to check the authorization.
3. It has an open feedback system which creates inefficiency in providing feedback and
storing it.
8.2 FUTURE ENHANCEMENTS:
It is not possible to develop a system that makes all the requirements of the user. User
requirements keep changing as the system is being used. Some of the future
enhancements that can be done to this system are:

Dept.of CSE

MREC(Autonomous)

Future Banking E-Transactions

56

As the technology:
1. Emerges, it is possible to upgrade the system and can be adaptable to desired
environment.
2. Because it is based on object-oriented design, any further changes can be easily
adaptable.
3. Based on the future security issues, security can be improved using emerging
technologies.

BIBLIOGRAPHY
Books:
[1]
Gary Cornell: Core Java, Volume II--Advanced Features, Pearson Education Sun
Dept.of CSE
MREC(Autonomous)

Future Banking E-Transactions

57

th

Microsystems, 9 Edition, Published in 2013.

[2] George Reese: Database Programming with JDBC and Java, O'Reilly Media, 2
Edition, Published in 2010.
[3]

nd

Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language
nd

User Guide, Pearson Education 2

Edition, Published in 2007.

[4] Roger S Pressman: Software engineering (A practitioners approach), McGraw-Hill

th

Education 6 Edition, Published in 2012.

[5]

Joshua Bloch: Effective Java Programming Language Guide, Addison-Wesley

nd

Professional 2

Edition, Published in 2008.

Websites:
[1] http://www.w3schools.com/
[2] http://www.cafevida.net/
[3] http://stackoverflow.com/
[4] http://en.wikipedia.org/wiki/Main_Page

Dept.of CSE

MREC(Autonomous)