1.

ABSTRACT
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 provides business solutions for both retail and corporate.
This system acts as a standard interface between the clients and all the banks that register
with the system and clients who maintains accounts in various banks dont have to visit
individual banks website to make money transactions instead he can directly log on to ETransaction Interface and make any kind of request and get his work fulfilled and in the backend
the system will take care of all the obligation required in order to carry on transaction smoothly
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 use to only one
Systematic Standard way of banking and thereby 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.

2. SCOPE
In system development life cycle (SDLC) document plays a critical role because document
describes the full requirement of the system. It is meant for use by the developers and will be
basically during testing phase. Any changes done to requirements later will have to go through
formal change approved procedure.

2.1 Need of study

To give the general insight into the analysis and requirements of the systems which are
existing or situation and for establish the operating feature of the system is the main purpose of
this document

2.2 E-Transactions and E-Banking

New information technologies and emerging business forces have triggered a new wave of
financial innovation - electronic banking (e-banking).

This study utilizes an innovation model to analyze the impact of e-banking on the
incumbent banks.

The results indicate that the nature of e-banking innovation is disruptive, leading to drastic
changes in both technological knowledge and business model.

We further identify eight core capabilities that are necessary for the banks to cope with the
change, each appearing to address either technical or business aspects of e-banking
transformation. The findings have the potential to contribute to the understanding of
impacts occurring in the change associated with e-banking and offer rich insights for the
incumbent banks to exploit e-banking opportunities.

The banking and financial industry (BFI) is transforming itself in unpredictable ways
powered in an important way by advances in information technology.

Since the 1980s, commercial banking has continuously innovated through technologyenhanced products and services, such as multi-function ATM, tele-banking, electronic
transfers, and electronic cash cards.

Over the past decade, the Internet has clearly played a critical role in providing online
services and giving rise to a completely new channel. In the Internet age, the extension of
commercial banking to the cyberspace is an inevitable development.

E-banking creates unprecedented opportunities for the banks in the ways they organize
financial product development, delivery, and marketing via the Internet. While it offers new
opportunities to banks, it also poses many challenges such as the innovation of IT
applications, the blurring of market boundaries, the breaching of industrial barriers, the
entrance of new competitors, and the emergence of new business models.

However, to successfully cope with the challenge of the e-banking innovation, the
incumbent banks must understand the nature of the change and capability barriers that it
presents. Without this understanding, attempts to migrate to e-banking may be doomed to
failure.

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

3.2 Drawbacks Of Existing System

When a user has multiple accounts in multiple banks the user must have the complete
knowledge of accessing all the accounts as each bank has a protocol of its own.
With the existing system it is very difficult for a user to adapt to different protocols one
after the other and this may result in unsuccessful banking and is liable to transaction
failures.
Hence the e-transaction interface banking methodology is introduced so that the user can
have a hassle free online banking experience.

3.3Proposed System

The e-Transaction Interface provides the following system features.

1. This system provides a Common User Interface for the customers to log on to any bank.
2. Here the user interface is Graphical User Interface.
3. This application is a Web based Application.
4. Being a web based application it doesnt require any client side installation.
5. Any number of users can interact with the system simultaneously.
6. Eradicates the time consumed to learn how to use all the user interfaces of every bank in
which a customer is having account.

4. REQUIREMENTS SPECIFICATION
4.1 Functional Requirements
Functional Requirements is the specification of the function that the system must support.
Whereas non functional requirements are the constraint on the operation of the system that is not
related directly to function of system
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 Password, Transaction amount.
Output: The outputs are the Amount that is transferred between the accounts. The verification
reports of the bank. Bank Statements, Account status.

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

4.3 Scope of the Development Project

Database Tier: The concentration is applied by adopting wide range of DBMS.
User Tier: The user interface is developed in a browser specific environment to have web based
architecture. The components are designed using HTML standards and Java server pages power
the dynamic of the page design. Java Script for Loading graphics and Validations.
Data Base Connectivity Tier: The communication architecture is designed by concentrated on
the standards of servlets and JSPs.

4.4 Required Hardware

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

4.5 Required Software

Server Side:

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

5.MODULES DESCRIPTION
5.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.2 Banker Module

Through this module the banker can accept the request for registering the account
of a user with the system.

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

6. DESIGN
6.1 Use Case Model
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.
SYSTEM NAME

Use case 1

Use case 2

Actor

Actor

Use case n

USE CASES OF E-TRANSACTION INTERFACE

Use case name

Participating
actors
Flow of events
Entry
Condition

Login
Customer, Admin, Banker
The Actor will give the user name and password to the system. The
system will verify the authentication.
The actor will enter the system by using username and password

Exit condition
Quality
Requirements

If un authenticated should be exited

Password must satisfy the complexity requirements.

Use case name

Bank Registration

Participating
actors
Flow of events

Admin

Entry
Condition
Exit condition
Quality
Requirements

The administrator will all the details submitted by banker and creates
and place in the application.
Must satisfy all the norms given by the e-transaction interface site.
Successful or Un successful completion of creation of account.
All fields are mandatory.

Entry
Condition
Exit condition
Quality
Requirements

User should have an account and the destination account should be

valid one.
Transaction must be rolled back if exceptions are raised.
Target account must be verified, amount entered must be valid.
Cross checking of account balance.

Use case name

Participating
Use case name
actors
Participating
Flow
actorsof events

Account creation
Customer
View Transaction Status

Flow of events
Entry
Condition
Entry

Customer
The customer must create the bank account by giving the necessary
data.
The customer can view the whether the transaction is approved or
Actor
must know the proper bank account number and the bank.
rejected..
Not Applicable.

Condition
Exit condition
Quality
Requirements

Not Applicable
Good Report Design

Use case name

Participating

Transaction Verification
Banker

10

actors
Flow of events
Entry
Condition
Exit condition
Quality
Requirements
Use case name
Participating
actors
Flow of events
Entry
Condition
Exit condition
Quality
Requirements

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

committed.
Banker must check the validity constraints
Banker must complete the task before exiting the system
Not Applicable

Account Verification
Banker
The Banker can accept or reject the account that can be added to the
customer.
He must verify the account that is that account belongs to specified
person or not.
Not Applicable
No Applicable

11

12

e-Transaction Interface

LOGIN
BANK REGISTRATION

CUSTOMER REGISTRATION

AMOUNT TRANSCATION

ACCOUNT CREATON

VIEW TRANSCATION STATUS

TRANSACTION VERIFICATION

ACCOUNT VERIFICATION

REPORTS GENEATION

13

Banker

Admin

Customer

6.2 Class Diagram

Class diagrams describe the structure of the system in terms of classes and objects.
A class diagram in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's classes their attributes,
operations and the relationships among the classes.

14

6.3 Sequence Diagram

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

15

Admin

:
Login
Use url

: Create
Bank
Account

: Log Out

Press login button

Press Create Account

Time

Sequence Diagram 2
:

Customer

Login

: Accounts

DB

Get login page ()

Validate norms()
Press create accounts
button()

Sequence Diagram 3
(TX: Transactions)

16

:TX

: TXVerify

: DB

Customer
Press Amount
submit ()
Wait for acceptance()

View last
transaction ()

Sequence Diagram 4

:
Login

Banke
r
Privel

: TXValidate

:Account
Validate

: DB

Banker
Press login
button() Select Validate
or Reject
Press Accept/Reject
Button
Select Validate or Reject
Account()

Reports()

6.4 Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and

17

actions with support for choice, iteration and concurrency.

In the Unified Modeling Language activity diagrams can be used to describe the
business and operational step-by-step workflows of components in a system.
An activity diagram shows the overall flow of control.

Activity diagram fig 1

18

Activity diagram fig 2

6.5 Component Diagram

In the Unified Modeling Language a component diagram depicts how components are
wired together to form larger components and or software systems. They are used to illustrate
the structure of arbitrarily complex systems.

19

6.6 Data Dictionary

Tables

Tname

Tab type

Bank

Table

BLogin

Table

CLogin

Table

Transfer

Table

Creject

Table

Customer

Table

Reject

Table

Taccept

Table

Customer details

Column name

Data type

Size

User name
Password
First name
Last name
Login type
Login status

varchar
varchar
varchar
varchar
varchar
varchar

50
50
50
50
50
50

Customer Profile

20

Constraints
PK
N
N
N
N
N

Column name

Data type

Size

Constraints

Login id

varchar

50

FK

City

varchar

50

State

varchar

50

Country

varchar

50

Locale

varchar

50

Account number

Int

50

Customer id

varchar

50

Data type
int
varchar
int
int
varchar
varchar

Size
20
50
20
20
50
50

Constraints
PK
N
N
N
N
N

Account Information

Column name
Account number
Account type
Destination account
Amount
Transaction id
Transaction password

New user Requests

Column name
User name
Password
Bank name

Data type
varchar
varchar
varchar

Size
220
220
220

21

Constraints
PK
N
N

Operations

varchar

220

7. CODING
7.1 Code for bank login
<HTML>
<HEAD>
<TITLE> </TITLE>
</HEAD>
22

<script >
function call()
{
if(document.f.bid.value=="null"){
alert("Please Enter Ur Name");
document.f.uname.setFocus=true;
}
if(document.f.pwd.value=="null"){
alert("Please Enter Ur Password");
return false;
}
if((document.f.bid.value=="null")||(document.f.pwd.value=="null"))
{
alert("Please Enter Username& password");
document.f.uname.setFocus=true;
}
}
</script>
<BODY >
<br><br>
<center>
<BR><BR>
<b><h2><u>WELCOME TO E-TRANSACTION INTERFACE</u></h2></b></font>
<br>
<br><br>
<br>
<form method=post action="bloginch.jsp" name="f" onSubmit='return call()'>
<table width="40%" cellpadding="5" cellspacing="5">
<colgroup span=2 >
<tr>
<td><b>Username:</b></td><td><input type="text" name="bid" ></td>
</tr>

23

<tr>
<td><b> Password:</b></td><td><input type="password" name="pwd"></td>
</tr>
<tr>
<td><b> Select Bank:</b></td><td><SELECT NAME="bl"><option>ICICI</option>
<option>UTI</option>
<option>HDFC</option>
<option>HSBC</option></SELECT></td>
</tr>
</table>
<br> <BR><BR>
<input

type="submit"

value="

Login

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

7.2 Code for admin login

<HTML>
<HEAD>
<TITLE> </TITLE>
</HEAD>
<script >
function call()

24

">

{
if(document.f.name.value==""){
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>
<input type="submit" value="submit">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input type="reset" value="reset">

25

</form>
<br>
</center>
</BODY>
</HTML>

7.3 Customer login

<HTML>
<HEAD>
<TITLE> </TITLE>
</HEAD>
<script >
function call()
26

{
if(document.f.cid.value==""){
alert("Please Enter Customer Id");
document.f.cid.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="logincheck.jsp" name="f" onSubmit='return call()'>
<table>
<tr>
<td><b>Customer ID:</b></td><td><input type="text" name="cid" ></td>
</tr>
<tr><td>&nbsp;</td></tr>
<tr>
<td><b> Password:</b></td><td><input type="password" name="pwd"></td>
</tr>
</table>
<br> <BR>
<input type="submit" value="submit"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input

type="reset"

value="reset">&nbsp;&nbsp;&nbsp;&nbsp;<input

name=back value="Home" onClick="window.location='home.jsp'">

27

type="button"

<center><h2><b><a href="newcustomer.jsp"><font color="#FF5C0F"><BR>New User?????

Click here</font> </a></b></h2></center>
</form>
<br>
</center>
</BODY>
</HTML>

7.4 New bank user

<HTML>
<HEAD>
<TITLE> </TITLE>
</HEAD>
<script >
function call()

28

{
if(document.f.id.value==""){
Alert ("Please Enter Id");
document.f.id.setFocus=true;
return false;
}
If (document.f.pwd.value==""){
alert("Please Enter Ur Password");
return false;
}
if(!((document.f.pwd.value)==(document.f.pwd1.value)))
{
alert("enter correct password");
return false;
}
if(document.f.bname.value==""){
alert("Please Enter Bank Name");
return false;
}
}
</script>
<BODY bgcolor=#FFFFFF>
<Center>
<BR><BR>
<font size="+2" color="#FF5C0F"><h2>E-Transaction Interface</b></h2></font>
<br>
<form method=post action="bankprocess.jsp" name="f" onSubmit='return call()'>
<table>
<tr>
<td><h3>User ID:</b></td><td><input type="text" name="id" ></td>
</tr>

29

<tr><td>&nbsp;</td></tr>
<tr>
<td><h3> Password:</b></td><td><input type="password" name="pwd"></td>
</tr><tr></tr><tr></tr>
<tr>
<td><h3>Retype Password:</b></td><td><input type="password" name="pwd1"></td>
</tr><tr></tr><tr></tr>
<tr>
<td><h3>Enter Bank Name:</b></td><td><input type="text" name="bname" ></td>
</tr>
</table>
<br> <BR>
<input type="submit" value="submit"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input type="reset" value="reset">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input type="button" name=back value=" BACK " onClick="window.location='blogin.jsp'">
</form>
<br>
</center>
</body>
</html>

7.5 New customer

<HTML>
<HEAD>
<TITLE> </TITLE>
</HEAD>
<script >
function call()

30

{
if(document.f.id.value==""){
alert("Please Enter Customer Id");
document.f.id.setFocus=true;
return false;
}
if(document.f.pwd.value==""){
alert("Please Enter Ur Password");
return false;
}
if(!((document.f.pwd.value)==(document.f.pwd1.value)))
{
alert("enter correct password");
return false;
}
}
</script>
<BODY bgcolor=#FFFFFF>
<center>
<BR><BR>
<font size="+2" color="#FF5C0F"><h2>E-Transaction Interface</b></h2></font>
<br>
<form method=post action="customerprocess.jsp" name="f" onSubmit='return call()'>
<table>
<tr>
<td><h3>Customer ID:</b></td><td><input type="text" name="id" ></td>
</tr>
<tr><td>&nbsp;</td></tr>
<tr>
<td><h3> Password:</b></td><td><input type="password" name="pwd"></td>
</tr><tr></tr><tr></tr>
<tr>

31

<td><h3>Retype Password:</b></td><td><input type="password" name="pwd1"></td>

</tr><tr></tr><tr></tr>
</table>
<br> <BR>
<input type="submit" value="submit"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input type="reset" value="reset">&nbsp;&nbsp;&nbsp;&nbsp;
<input type="button" name=back value=" BACK " onClick="window.location='login.jsp'">
</form>
<br>
</center>
</BODY>
</HTML>

7.6 Validating a user login

<%@ page import="java.sql.*" %>
<%
String cid=request.getParameter("cid");
String pwd=(String)request.getParameter("pwd");
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

32

Connection con=DriverManager.getConnection("jdbc:odbc:eti","eti","eti");
int ind=0;
System.out.println("cid");
System.out.println(cid);
System.out.println("cid");
PreparedStatement st=con.prepareStatement("select * from clogin where cid=? and pwd=?");
st.setString(1,cid);
st.setString(2,pwd);
ResultSet rs=st.executeQuery();System.out.println("inout fist if");
if(rs.next()){
System.out.println("in fist if");
ind=rs.getInt(4);
System.out.println("ind value"+ind);
if(ind==1){

System.out.println("in fist if2");

session.setAttribute("id",cid);
response.sendRedirect("user.jsp");
}else{response.sendRedirect("process.jsp");}
}else{ response.sendRedirect("loginfailure.jsp");}
%>

33

7.7 Processing a customer request

<%@ page import ="java.sql.*" %>
<%
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
float bal=200;
Connection con=DriverManager.getConnection("jdbc:odbc:eti","eti","eti");
String id=request.getParameter("id");
int ii=0;
String pwd=request.getParameter("pwd");
PreparedStatement ps3=con.prepareStatement("select * from clogin where cid=? ");
ps3.setString(1,id);
ResultSet rs3=ps3.executeQuery();
// System.out.println("hiii");
if(rs3.next()){System.out.println("hiii22");
response.sendRedirect("exist.jsp");
}
else{
PreparedStatement ps1=con.prepareStatement("select MAX(id) from clogin");
ResultSet rs2=ps1.executeQuery();
if(rs2.next()){
String s=rs2.getString(1);
if(s==null){
ii=1;}else{ii=Integer.parseInt(s)+1;}}
int ind=0;
PreparedStatement st=con.prepareStatement("insert into clogin values(?,?,?,?)");
st.setInt(1,ii);
st.setString(2,id);
st.setString(3,pwd);
st.setInt(4,ind);
st.executeUpdate();
response.sendRedirect("process.jsp"); }
%>

34

8. SCREEN SHOTS
E-TRANSACTIONS HOME PAGE

35

E-TRANSACTIONS LOGIN PAGE

36

E-TRANSACTIONS BANK MODULE

37

E-TRANSACTIONS ADMIN MODULE

38

E-TRANSACTIONS CUSTOMER LOGIN

39

E-TRANSACTIONS SELECTING A BANK

40

E-TRANSACTIONS BANK LOGIN

41

9. TESTING
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 de

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

9.1 System Testing

Testing the behavior of the whole software/system as defined in software requirements
specification (SRS) is known as system testing, its main focus is to verify that the customer
requirements are fulfilled.
System testing is done after integration testing is complete. System testing should test
functional and non functional requirements of the software.
The reference document for this process is the requirements document, and the goal os to
see if software meets its requirements.

9.2 Integration Testing

Integration testing is the phase in software testing in which individual software modules
are combined and tested as a group. It occurs after unit testing and before validation testing.
The purpose of integration testing is to verify functional, performance, and
reliability requirements placed on major design items.
.

42

9.3 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 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 these errors resulting from interaction between modules initially avoided.

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

43

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

44

9.6 Test cases for E-banking and E-transactions

Test case
number
Test case 1

Test case 2

Test case 3

Test case 4

Test case 5

Test case 6

Test case

Step
Actual
Expected
description/user
output
output
action
Correct
User Enters
login
Login
combination
Correct
validated
validated
of username
combination of
and password
username and
password
Correct
When the user
Pass word
Pass word
username and
enters Correct
field cannot
field cannot
empty
username and
be empty
be empty
password
empty password
Creating a
When the user
Customer id
Customer id
new customer
creates a
already exists already exists
account with
customer
already
account with an
existing
already existing
customer id
customer id and
clicks on
Submit button.
Entering the
When the user
Account
Account
wrong
enters the wrong number is too number is too
account
account number short or long short or long
number i.e.
in the Enter
(invalid)
(invalid)
too short or account number
long
and clicks on
Submit.
Entering the
When the user
Account
Account
right account
enters the right
summary is
summary is
number
account number
displayed
displayed
in the Enter
account number
and clicks on
Submit
Entering the
When the user
Transaction
Transaction
wrong
Enters the
remains
remains
destination
wrong
incomplete
incomplete
account while
destination
transferring
account while
amount
transferring
amount

45

status
pass

Fail

Fail

Fail

pass

fail

Test case
number
Test case 7

Test case 8

Test case 9

Test case 10

Test case

Step
description/user
action
Entering the
When the user
right
Enters the right
destination
destination
account while account while
transferring
transferring
amount
amount
When the
bank rejects a
user request
of creating a
new account
When the
bank accepts
a user request
of creating a
new account
Transferring
the amount
more than the
existing
amount.

The user creates

account and
sends the banker
the request
which is rejected
The user creates
account and
sends the banker
the request
which is
accepted
When the user
transfers more
than the
available amount
in the account.

46

Actual
output

Expected
output

status

The
transaction is
complete and
the amount
gets
transferred
successfully
The account
is not created

The
transaction is
complete and
the amount
gets
transferred
successfully

Pass

The account
is created and
the user can
access the
account .

The account
is created and
the user can
access the
account .

Pass

The
transaction
fails to
complete

The
transaction
fails to
complete

fail

Fail

10. CONCLUSION
The entire project has been developed and deployed as per the requirements
stated by the user, it is found to be bug free as per the testing standards that are implemented.
Any specification untraced errors will be concentrated in the coming versions, which are
planned to be developed in near future.
The system at present does not take care of the money payment methods, as the consolidated
constructs need SSL standards and are critically to be initiated in the first face; the application of
the credit card transactions is applied as a developmental phase in the coming days. The system
needs more elaborative technicality for its inception and evolution.

47

11. BIBLIOGRAPHY
References for the Project Development w were taken from the following Books
and Web Sites.

JAVA Technologies

JAVA Complete Reference by Herbert Sheildt and Patrick Naughton

Java Script Bible Gold Edition

Java.sun.com tutorials

Software Engineering by Roger Pressman

Object-Oriented Software Engineering Using UML, Pattern and Java Second

Edition by Bernd Bruegge, Allen H.Duetoit.

48