The E-Transaction Interface
Transcript of 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:
-
8/10/2019 The E-Transaction Interface
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
-
8/10/2019 The E-Transaction Interface
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.
-
8/10/2019 The E-Transaction Interface
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.
-
8/10/2019 The E-Transaction Interface
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
-
8/10/2019 The E-Transaction Interface
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.
-
8/10/2019 The E-Transaction Interface
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
-
8/10/2019 The E-Transaction Interface
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
&o-mn Name Data ty6e Sie
$#: 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
-
8/10/2019 The E-Transaction Interface
33/59
FUTURE BANKING E-TRANSACTIONS !!
Ta4e Name: $ustomer
&o-mn Name Data ty6e Sie
#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
&o-mn Name Data ty6e Sie
$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
&o-mn Name Data ty6e Sie
/$#: 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
&o-mn Name Data ty6e Sie
-
8/10/2019 The E-Transaction Interface
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
-
8/10/2019 The E-Transaction Interface
40/59
FUTURE BANKING E-TRANSACTIONS "
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
-
8/10/2019 The E-Transaction Interface
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
-
8/10/2019 The E-Transaction Interface
42/59
FUTURE BANKING E-TRANSACTIONS "
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.=
-
8/10/2019 The E-Transaction Interface
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.
-
8/10/2019 The E-Transaction Interface
44/59
FUTURE BANKING E-TRANSACTIONS ""
?.O$TP$TS
0ig W.=< home page
0ig W.G< admin login
-
8/10/2019 The E-Transaction Interface
45/59
FUTURE BANKING E-TRANSACTIONS "#
0ig W.< admins list
0ig W.C< create new customer
-
8/10/2019 The E-Transaction Interface
46/59
FUTURE BANKING E-TRANSACTIONS "$
0ig W.M< customer login
-
8/10/2019 The E-Transaction Interface
47/59
FUTURE BANKING E-TRANSACTIONS "%
0ig W.S< customer request in process
0ig W.W< create bank account
-
8/10/2019 The E-Transaction Interface
48/59
FUTURE BANKING E-TRANSACTIONS "&
0ig W.7< new user requests
0ig W.R< bank admin request accepted
-
8/10/2019 The E-Transaction Interface
49/59
FUTURE BANKING E-TRANSACTIONS "'
0ig W.=>< bank admin request declined
-
8/10/2019 The E-Transaction Interface
50/59
FUTURE BANKING E-TRANSACTIONS #
0ig W.==< new user requests
0ig W.=G< user request accepted
0ig W.=< banker login
-
8/10/2019 The E-Transaction Interface
51/59
FUTURE BANKING E-TRANSACTIONS #1
0ig W.=C< select bank
-
8/10/2019 The E-Transaction Interface
52/59
FUTURE BANKING E-TRANSACTIONS #
0ig W.=M< enter account details
0ig W.=S< bank account login
-
8/10/2019 The E-Transaction Interface
53/59
FUTURE BANKING E-TRANSACTIONS #!
0ig W.=W< banker list
0ig W.=7< list of accounts
-
8/10/2019 The E-Transaction Interface
54/59
FUTURE BANKING E-TRANSACTIONS #"
0ig W.=R< select account type
0ig W.G>< list of transfer pendings
-
8/10/2019 The E-Transaction Interface
55/59
FUTURE BANKING E-TRANSACTIONS ##
0ig W.G=< no records found
-
8/10/2019 The E-Transaction Interface
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
-
8/10/2019 The E-Transaction Interface
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.
-
8/10/2019 The E-Transaction Interface
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
-
8/10/2019 The E-Transaction Interface
59/59