The E-Transaction Interface

8/10/2019 The E-Transaction Interface

1/59

FUTURE BANKING E-TRANSACTIONS 1

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. hen 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 #nterface provides the following system features.

This system provides a $ommon %ser #nterface for the customers to log on to any

bank.

Here the user interface is &raphical %ser #nterface.

This application is a eb based Application.

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

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 !"antages O"e# Existing System:


2/59

FUTURE BANKING E-TRANSACTIONS

The new system is cost effective

#mproved productivity and service and services.

Enhance user interface.

#mproved information presentation and durability.

%pgraded systems reliability! availability and fle(ibility.

Address human factors for better and uses acceptance.

2. LITERT$RE S$R%EY

2.1 TE&'NOLOGIES $SED

2.1.1 (a"a


3/59

FUTURE BANKING E-TRANSACTIONS !

)ava is a programming language! a runtime system! a set of development tools! an

application programming interface *A+#,. The relationship between these elements is

depicted in figure.

The )ava A+# contains predefined software packages with numerous platform"independent -hooks- into the native windowing and networking capabilities of the host

operating system. The )ava A+# provides a single common A+# across all operating

system to which )ava is ported.

The keys to )avas portability are its run time system! and its A+#. The run time system is

very compact! evolving from earlier /un efforts to build a software platform for consumer

electronics. 'ecause this platform was not designed around any e(isting 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 /imple! 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 )ava A+# make it easier

for programmers to develop software that is both attractive and platform independent. 0or

e(ample! Adam is a programming language that is highly standardi1ed and supported onmost operating systems. 2et Adam applications are not very portable. This is because

Adam does not come with a common A+# that supports windowing and networking on all

platforms. )ava differs from Adam and all other programming languages in that there is

one universal! but powerful! )ava A+# for all operating systems platforms. That is why

)ava is the most portable language.

(a"a)s Magi*: T+e ,yte &o!e:

The key that allows 3ava to solve both the security and the portability problems 3ust

described is that the output of the 3ava compiler is not an e(ecutable code. 4ather! it is

'yte $ode. 'yte $ode is a highly optimi1ed set of instructions designed to be e(ecuted by

virtual machine that the 3ava 4un"time system emulates. This may come as it of surprise

as you know c55 is compiled! not interpreted"mostly because of performance concerns.

However! the fact that a 3ava program is interpreted helps solve the ma3or problems

associated with downloading the program over the #nternet.


4/59

FUTURE BANKING E-TRANSACTIONS "

Here is why 3ava was designed to be interpreted language. 'ecause 3ava programs are

interpreted rather than compiled .#t is easier to run them in wide variety of environments.

6nly the 3ava runtime system needs to be implemented for each platform. 6nce the

runtime package e(ists for a given system any 3ava program can run on it. #f 3ava were a

compiled langu7age then different versions of the same program will have to e(ist for

each type of $+% connected to the #nternet. Thus interpretation is the easiest way to

create truly portable programs. Although 3ava was designed to be interpreted! there is

technically nothing about 3ava that prevents on the fly compilation of 'yte $ode into

native code. However! even if dynamic compilation were applied to 'yte $ode! the

portability and safety would still apply! because the run time system would still be in

charge of the e(ecution environment.

T+e (a"a ,- /o#!s

8o discussion of the genesis of 3ava is complete without a look at the 3ava bu11words.

Although the fundamentals that necessitated the invention of 3ava are portability and

security! there are other factors that played an important role on molding the final form of

the language. The 3ava in the following list of bu11words summed up the key

considerations.

/imple

+ortable

6b3ect"oriented

4obust

9ultithreaded

Architectural"neutral

High performance

:istributed

:ynamic

2.1.2 (D,&

The database is the most important component of a companys information services

infrastructure. #t is heart of the applications on which a company depends for its survival.


5/59

FUTURE BANKING E-TRANSACTIONS #

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 A+#s specific to individual databases or comple( universal A+#s such as6:'$. 'efore starting any program the must be a need to used through data modeling

and database design.

(D,& Inte#fa*es

):'$ defines eight interfaces that must be implemented by a driver in order to be ):'$"

compliant specifications includes

many additional features that make it useful platform for developing and deploying web

applications and web services.

Instaing Tom*at

#nstalling 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. %sing the checkbo(

on the component page sets the service as NautoO startup! so that tomcat is automatically

started when windows starts. 0or optimal security! the service should be affected by a

separate user! with reduced permissions.

)ava location< The installer will use the registry or the )AFAPH69E environment

variable to determine the base path of the ):@ or a )4E. #f only a )4E is specified.

Tomcat will run but will be unable to compile )/+ pages at runtime.

Either all webapps will need to be precompiled! or the libQtools. )ar file from a

):@ installation must be copied to the commonQlib path of the tomcat installation.

#*+ite*t-#e O"e#"ie


14/59

FUTURE BANKING E-TRANSACTIONS 1"

Se#"e#:A server represents the whole container. A server element represents the entire

$atalina servlet container. Therefore! it must be the single outermost element in the

confserver.(ml configuration file. #ts attributes represent the characteristics of a servlet

container as a whole. Tomcat provides a default implementation of the server interface!

and this is rarely customi1ed 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 e(actly one engine. The service element is rarely customi1ed by users!

as the default implementation is simple and sufficient.

'ost:Host is an association of a network name to the tomcat server. An engine may

contain multiple hosts. %sers rarely create custom hosts because the standard host

implementation provides significant additional functionality.

&onne*to#: 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 HTT+ traffic! especially when

running tomcat as a standalone server! and the )@G connector which implements the A)+protocol used when connecting tomcat to an apache HTT+ server. $reating a customi1ed

connector is significant effort.

&ontext< conte(t represents a web application. A host may contain multiple conte(ts! each

with a unique path. The conte(t interface may be implemented to create custom conte(ts.

'ut this is rarely the case because the standard conte(t provides significant additional

functionality.


15/59

FUTURE BANKING E-TRANSACTIONS 1#

3. SYSTEM NLYSIS

3.1 S&OPE O T'E PRO(E&T

The e"Transaction #nterface 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 e(isting banks and provide business solutions for both retail and corporate.

The main Fision of this pro3ect is to eliminate all the diversities amongst banks! which

generally client faces at the time of any transaction. 'y doing so $lient will used to only

one /ystematic /tandard way of banking and there by they will be at ease using this

interface.

3.2 SOT/RE RE;$IREMENT SPE&II&TION

3.2.1 SDL& Met+o!oogies

This document play a vital role in the development of life cycle */:L$, as it describes

the complete requirement of the system. #t 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 ob3ective or goal. H2'4#: 96:EL is generally for large systems usually

made up of several sub"systems and the same process model does not have to be used for

all subsystems. The Hybrid model combines the top"down and bottom"up models. %singthe menu driven application e(ample! the design team primarily works top down! but the


16/59

FUTURE BANKING E-TRANSACTIONS 1$

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

pro3ect 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 e(isting software modules from other

pro3ects that can be reused in the new pro3ect. This approach allows the development team

to make changes to the system early in the pro3ect 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 $+% processing time is an e(ample of a high"risk low"

level component. This hybrid model is used to access pro3ect risks that are related to

programming! human and material factors. #n 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! F"shape and e(treme programming models. The following diagram shows how a

hybrid model acts like

Tb C.=< bank

Des*#i6tion: This table stores the details about the bank identified by the id and with

associated 'ank 8ame.

Ta4e Name: 'login

&o-mn Name Data ty6e Sie#d 8umber G>

'#: FarcharG GM>

+: FarcharG GM>

'8A9E FarcharG GM>

/TAT%/ 8umber =>

Tb C.G< bank login

Des*#i6tion: This table stores the login details of the bank.

Ta4e Name: $login

&o-mn Name Data ty6e Sie

#d 8umber G>

$#: FarcharG GG>

+: FarcharG GG>

/TAT%/ 8umber =>

Tb C.< customer login

Des*#i6tion: This table stores the details about the $ustomer Login.

Ta4e Name: $4E)E$T


$#: FA4$HA4G GG>

+: FarcharG GG>

A$$86 FarcharG GG>

'8A9E FarcharG GG>

Tb C.C< customer re3ect

Des*#i6tion: This table stores the details about the accounts that were re3ected by the

Administrator


33/59

FUTURE BANKING E-TRANSACTIONS !!

Ta4e Name: $ustomer


#d FarcharG GG>

Accno FarcharG GG>

Atype FarcharG GG>

$name FarcharG GG>'name FarcharG GG>

'al 8umber >

T+: FarcharG GG>

/tatus 8umber G>

Tb C.M< customer

Des*#i6tion: This table stores the details about the $ustomer. #t is effected when the

customer makes any transactions. The 'al field is effected when ever any withdraw! :eposit

or Transfer of money is done.

Ta4e Name: 4e3ect


$id FacharG GG>

Accno FarcharG GG>

Actype FarcharG GG>

'8ame FarcharG GG>

Tb C.S< create account

Des*#i6tion: This table add an entry when any request from the customer for creating an

account is re3ected by Administrator.

Ta4e Name: taccept


/$#: FarcharG =G>

/acno FarcharG =G>

Atype FarcharG =G>

/bname FarcharG =G>

/bal 8umber >:cid FarcharG =G>

:acno FarcharG =G>

dtype FarcharG =G>

:'al FarcharG =G>

Tb C.W< admin

Des*#i6tion: This table adds an entry when ever a user transfers amount from one account to

another account. And must be accepted by the administrator.

Ta4e Name: transfer



34/59

FUTURE BANKING E-TRANSACTIONS !"

#d 8umber >

/accno FarcharG =G>

:accno FarcharG =G>

Amt 8umber >

Atype FarcharG =G>

:type FarcharG =G>

Tpw FarcharG =G>

/'ank FarcharG =G>

:'ank FarcharG =G>

Tb C.7< transfer

Des*#i6tion: This table will be effected when a user transfers money between different

banks.

8.SYSTEM IMPLEMENTTION

8.1 MOD$LES DES&RIPTION 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 +rogrammer tests where

modules are designed with different parameters! length! type etc.

9.1.7 Integ#ation 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.

#n this pro3ect integrating all the modules forms the main system. hen integrating all the

modules # have checked whether the integration effects working of any of the services by


40/59


giving different combinations of inputs with which the two services run perfectly before

#ntegration.

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

Here entire ZAT9 has been tested against requirements of pro3ect and it is checked

whether all requirements of pro3ect have been satisfied or not.

9.1.9 **e6tan*e Testing

Acceptance Test is performed with realistic data of the client to demonstrate that the

software is working satisfactorily. Testing here is focused on e(ternal behavior of the

system; the internal logic of program is not emphasi1ed.

#n this pro3ect Z8etwork 9anagement 6f :atabase /ystem # have collected some data

and tested whether pro3ect is working correctly or not.

Test cases should be selected so that the largest number of attributes of an equivalence

class is e(ercised at once. The testing phase is an important part of software development.

#t is the process of finding errors and missing operations and also a complete verificationto determine whether the ob3ectives are met and the user requirements are satisfied.

9.1.? /+ite ,ox 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 ma(imum possible errors. # tested step wise every piece of

code! taking care that every statement in the code is e(ecuted at least once. The white bo(testing is also called &lass 'o( Testing.

# have generated a list of test cases! sample data! which is used to check all possible

combinations of e(ecution paths through the code at every module level.

9.1.@ ,a*> ,ox 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


41/59

FUTURE BANKING E-TRANSACTIONS "1

the module will be treated as a block bo( that will take some input and generate output.

6utput for a given set of input combinations are forwarded to other modules.

$riteria /atisfied by Test $ases

Test cases that reduced by a count that is greater than one! the number of additional testcases 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.

9.2 TEST &SES

9.2.1 $nit Testing:

Test &ase Name Des*#i6tion In6-t Data Ex6e*te!

O-t6-t

*t-a

O-t6-t

Test

Res-t

= %ser

Login

To verify

whether

user is a

register user

or not

%ser id and

password

with

validate

details

#f user is

register

home page

will be

displayed

Home

page is

displayed

success


42/59


G Admin

Login

To verify

whether

Admin is a

register or

not

%ser id and

password

with

validate

details

#f Falid

home page

will be

displayed

Home

page is

displayed

success

Tb S.=


43/59

FUTURE BANKING E-TRANSACTIONS "!

G Hardware

#nstallation

Ferify

whether

supporting

softwares

are installed

and

software is

recogni1ed

by the

system

$onnect

the server

and run

the

program

:ifferent

modules

will be

displayed

The home

page will

be

displayed

/uccess

Tb S.


44/59

FUTURE BANKING E-TRANSACTIONS ""

?.O$TP$TS

0ig W.=< home page

0ig W.G< admin login


45/59

FUTURE BANKING E-TRANSACTIONS "#

0ig W.< admins list

0ig W.C< create new customer


46/59

FUTURE BANKING E-TRANSACTIONS "$

0ig W.M< customer login


47/59

FUTURE BANKING E-TRANSACTIONS "%

0ig W.S< customer request in process

0ig W.W< create bank account


48/59

FUTURE BANKING E-TRANSACTIONS "&

0ig W.7< new user requests

0ig W.R< bank admin request accepted


49/59

FUTURE BANKING E-TRANSACTIONS "'

0ig W.=>< bank admin request declined


50/59


0ig W.==< new user requests

0ig W.=G< user request accepted

0ig W.=< banker login


51/59

FUTURE BANKING E-TRANSACTIONS #1

0ig W.=C< select bank


52/59


0ig W.=M< enter account details

0ig W.=S< bank account login


53/59

FUTURE BANKING E-TRANSACTIONS #!

0ig W.=W< banker list

0ig W.=7< list of accounts


54/59

FUTURE BANKING E-TRANSACTIONS #"

0ig W.=R< select account type

0ig W.G>< list of transfer pendings


55/59

FUTURE BANKING E-TRANSACTIONS ##

0ig W.G=< no records found


56/59

FUTURE BANKING E-TRANSACTIONS #$

@. &ON&L$SION

The $T$RE ,NAING E0TRNS&TIONwas successfully designed and is tested

for accuracy and quality. :uring this pro3ect we have accomplished all the ob3ectives and

this pro3ect meets the needs of the organi1ation.

GOLS

=. 4educed entry work

G. Easy retrieval of information

. 4educed errors due to human intervention

C. %ser friendly screens to enter the dataM. eb enabled.

S. 0ast finding of information requested

'y this pro3ect! we provide various facilities for customer as well as +6/ agent and staff

in their respective section of work. $ustomer can be able to give feedback! view menu!

deals and even about the restaurant. The work for +6/ 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.

@.1 LIMITTIONS O T'E SYSTEM:

=. /ystem works in all platforms and its compatible environments.

G. Advanced techniques are not used to check the authori1ation.

. #t has an open feedback system which creates inefficiency in providing feedback and

storing it.

@.2 $T$RE EN'N&EMENTS:

#t is not possible to develop a system that makes all the requirements of the user. %ser

requirements keep changing as the system is being used. /ome of the future

enhancements that can be done to this system are


57/59

FUTURE BANKING E-TRANSACTIONS #%

As the technology:

=. Emerges! it is possible to upgrade the system and can be adaptable to desired

environment.

G. 'ecause it is based on ob3ect"oriented design! any further changes can be easily

adaptable.

. 'ased on the future security issues! security can be improved using emerging

technologies.


58/59

FUTURE BANKING E-TRANSACTIONS #&

,I,LIOGRP'Y

,oo>s:

[=\ &ary $ornell< $ore )ava! Folume ##""Advanced 0eatures! +earson Education U/un

9icrosystems! Rth

Edition! +ublished in G>=.

[G\ &eorge 4eese< :atabase +rogramming with ):'$ and )ava! 64eilly 9edia! Gnd

Edition! +ublished in G>=>.

[\ &rady 'ooch! )ames 4umbaugh! #var )acobson< The %nified 9odeling Language

%ser &uide! +earson Education Gnd

Edition! +ublished in G>>W.

[C\ 4oger / +ressman< /oftware engineering *A practitioners approach,! 9c&raw"Hill

Education Sth

Edition! +ublished in G>=G.

[M\ )oshua 'loch< Effective )ava U +rogramming Language &uide! Addison"esley

+rofessional Gnd

Edition! +ublished in G>>7.

/e4sites:

[=\ http


59/59

The E-Transaction Interface

Documents

Transcript of The E-Transaction Interface