Escolar Documentos
Profissional Documentos
Cultura Documentos
Interface
CONTENTS
1. Abstract
2. Problem Definition
3. System Analysis
4. Feasibility Study
5. ER-Diagrams
6. Normalization and Database Design
7. Test Cases
8. System Testing
9. Architectural Design
10.
11.
DFDs
Abstract
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 E-
Transaction 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 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.
Modules
1) Banker Module
This module deals with the Accounts Pending, Pending Transfers,
and Reports regarding transactions.
2) Customer Module
This module a customer can register him self to the system,
customer can login into the system. A customer can add a new
ABOUT THE
ORGANIZATION
PROBLEM
DEFINITION
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.
System
Analysis
FEASIBILITY
STUDY
Feasibility Report
TECHINICAL 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)
ii)
Is
the
required
technology
available
with
the
organization?
o
Will the current printer be able to handle the new reports and forms
required for the new system?
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:
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?
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.
ECONOMIC FEASIBILITY:
Economic
feasibility
attempts
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,
INTRODUCTION
Purpose: The main purpose for preparing this document is to give a general
insight into the analysis and requirements of the existing system or situation
and for determining the operating characteristics of the system.
Scope: This Document plays a vital role in the development life cycle (SDLC)
as it describes the complete requirement of the system. It is meant for use
by the 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.
Developing the system, which meets the SRS and solving all the
requirements of the system?
2)
3)
4)
Conducting any user training that might be needed for using the
system.
5)
Performance Requirements:
Performance is measured in terms of ease of use of user interface.
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.
Chapter 4
Software Requirement
Specification
Required Hardware
Pentium IV Processor.
256 MB RAM.
40GB Hard Disk space.
Ethernet card with an Internet and Internet zone.
Required Software
Server Side:
Client Side:
Any Web Browser on any operating system.
Chapter 5
Modules
Description
Number of Modules:
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.
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 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.
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.
SOFTWARE
PROFILE
Client Server
Technologies
Client Server
Over view:
With the varied topic in existence in the fields of computers, Client Server is
one, which has generated more heat than light, and also more hype than
reality. This technology has acquired a certain critical mass attention with its
dedication conferences and magazines. Major computer vendors such as IBM
and DEC; have declared that Client Servers is their main future market. A
survey of DBMS magazine reveled that 76% of its readers were actively
looking at the client server solution. The growth in the client server
development tools from $200 million in 1992 to more than $1.2 billion in
1996.
Client server implementations are complex but the underlying concept is
simple and powerful. A client is an application running with local resources
but able to request the database and relate the services from separate
remote server. The software mediating this client server interaction is often
referred to as MIDDLEWARE.
The typical client either a PC or a Work Station connected through a network
to a more powerful PC, Workstation, Midrange or Main Frames server usually
capable of handling request from more than one client. However, with some
configuration server may also act as client. A server may need to access
other server in order to process the original client request.
The key client server idea is that client as user is essentially insulated from
the physical location and formats of the data needs for their application. With
the proper middleware, a client input from or report can transparently access
and manipulate both local database on the client machine and remote
databases on one or more servers. An added bonus is the client server opens
the door to multi-vendor database access indulging heterogeneous table
joins.
Time-sharing changed the picture. Remote terminal could view and even
change the central data, subject to access permissions. And, as the
central data banks evolved in to sophisticated relational database
with non-programmer query languages, online users could formulate
adhoc queries and produce local reports with out adding to the MIS
applications software backlog. However remote access was through
dumb terminals, and the client server remained subordinate to the
Slave\Master.
About Java
Initially the language was called as oak but it was renamed as Java in
1995. The primary motivation of this language was the need for a platformindependent (i.e., architecture neutral) language that could be used to create
software to be embedded in various consumer electronic devices.
firewall
Translating a Java program into byte code helps makes it much easier to run
a program in a wide variety of environments. The reason is, once the runtime package exists for a given system, any Java program can run on it.
Although Java was designed for interpretation, there is technically nothing
about Java that prevents on-the-fly compilation of byte code into native
code. Sun has just completed its Just In Time (JIT) compiler for byte code.
When the JIT compiler is a part of JVM, it compiles byte code into executable
code in real time, on a piece-by-piece, demand basis. It is not possible to
compile an entire Java program into executable code all at once, because
Java performs various run-time checks that can be done only at run time.
The JIT compiles code, as it is needed, during execution.
Java Virtual Machine (JVM)
Beyond the language, there is the Java virtual machine. The Java virtual
machine is an important element of the Java technology. The virtual machine
can be embedded within a web browser or an operating system. Once a piece
of Java code is loaded onto a machine, it is verified. As part of the loading
process, a class loader is invoked and does byte code verification makes sure
that the code thats has been generated by the compiler will not corrupt the
machine that its loaded on. Byte code verification takes place at the end of
the compilation process to make sure that is all accurate and correct. So byte
code verification is integral to the compiling and executing of Java code.
Overall Description
Java Source
Java
.Class
JavaVM
Java Architecture
Java architecture provides a portable, robust, high performing environment
for development. Java provides portability by compiling the byte codes for
the Java Virtual Machine, which is then interpreted on each platform by the
run-time environment. Java is a dynamic system, able to load code when
needed from a machine in the same room or across the planet.
Compilation of code
When you compile the code, the Java compiler creates machine code (called
byte code) for a hypothetical machine called Java Virtual Machine (JVM). The
JVM is supposed to execute the byte code. The JVM is created for overcoming
the issue of portability. The code is written and compiled for one machine and
interpreted on all machines. This machine is called Java Virtual Machine.
PC Compiler
Source
Code
..
..
Byte code
Macintosh
Compiler
..
SPARC
Java
Java
Interpreter
(PC)
Compiler
(Platform
Indepen
dent)
Java
Interpreter
(Macintosh)
Java
Interpreter
(Spare)
During run-time the Java interpreter tricks the byte code file into thinking
that it is running on a Java Virtual Machine. In reality this could be a Intel
Pentium Windows 95 or SunSARC station running Solaris or Apple Macintosh
running system and all could receive code from any computer through
Internet and run the Applets.
Simple
Java was designed to be easy for the Professional programmer to learn and
to use effectively. If you are an experienced C++ programmer, learning Java
will be even easier. Because Java inherits the C/C++ syntax and many of the
object oriented features of C++. Most of the confusing concepts from C++
are either left out of Java or implemented in a cleaner, more approachable
manner. In Java there are a small number of clearly defined ways to
accomplish a given task.
Object-Oriented
Java was not designed to be source-code compatible with any other
language. This allowed the Java team the freedom to design with a blank
slate. One outcome of this was a clean usable, pragmatic approach to
objects. The object model in Java is simple and easy to extend, while simple
types, such as integers, are kept as high-performance non-objects.
Robust
The multi-platform environment of the Web places extraordinary demands on
a program, because the program must execute reliably in a variety of
systems. The ability to create robust programs was given a high priority in
the design of Java. Java is strictly typed language; it checks your code at
compile time and run time.
Java virtually
eliminates the
problems of
SERVLETS
Introduction
The Java web server is JavaSoft's own web Server. The Java web server is
just a part of a larger framework, intended to provide you not just with a web
server, but also with tools. To build customized network servers for any
Internet or Intranet client/server system. Servlets are to a web server, how
applets are to the browser.
About Servlets
Servlets provide a Java-based solution used to address the problems
currently
associated
with
doing
server-side
programming,
including
Attractiveness of Servlets
There are many features of Servlets that make them easy and attractive to
use. These include:
How it is loaded
Its extensible - you can inherit all your functionality from the base
classes made available to you.
Features of Servlets
Servlets are persistent. Servlet are loaded only by the web server
and can maintain services between requests.
Servlets are fast. Since Servlets only need to be loaded once, they
offer much better performance over their CGI counterparts.
Servlets
are
extensible.
Java
is
robust,
object-oriented
Loading Servlets
Servlets can be loaded from three places
From a directory that is on the CLASSPATH. The CLASSPATH of
the
This is
*not* in the
servers class path. A class loader is used to create Servlets from this
directory. New Servlets can be added - existing Servlets can be recompiled
and the server will notice these changes.
From a remote location. For this a code base like http: // nine.eng / classes /
foo / is required in addition to the Servlets class name. Refer to the admin
GUI docs on Servlet section to see how to set this up.
Loading Remote Servlets
Remote Servlets can be loaded by:
1. Configuring the Admin Tool to setup automatic loading of remote
Servlets
2. Setting up server side include tags in. shtml files
3. Defining a filter chain configuration
Invoking Servlets
A Servlet invoker is a Servlet that invokes the "service" method on a named
Servlet. If the Servlet is not loaded in the server, then the invoker first loads
the Servlet (either from local disk or from the network) and the then invokes
the "service" method. Also like applets, local Servlets in the server can be
identified by just the class name. In other words, if a Servlet name is not
absolute, it is treated as local.
A client can invoke Servlets in the following ways:
The client can ask for a document that is served by the Servlet.
The client (browser) can invoke the Servlet directly using a URL, once
it has been mapped using the Servlet Aliases section of the admin GUI.
JavaScript
JavaScript is a script-based programming language that was developed by
Netscape Communication Corporation. JavaScript was originally called Live
Script and renamed as JavaScript to indicate its relationship with Java.
JavaScript supports the development of both client and server components of
Web-based applications. On the client side, it can be used to write programs
that are executed by a Web browser within the context of a Web page. On
the server side, it can be used to write Web server programs that can process
information submitted by a Web browser and then updates the browsers
display accordingly
Even though JavaScript supports both client and server Web programming,
we prefer JavaScript at Client side programming since most of the browsers
supports it. JavaScript is almost as easy to learn as HTML, and JavaScript
There are many other differences but the important thing to remember is
that
JavaScript and Java are separate languages. They are both useful for
Advantages
-->
Specifies comments
<A>.</A>
<B>.</B>
<BIG>.</BIG>
<BODY></BODY>
<CENTER>...</CENTER>
Creates text
<DD></DD>
Definition of a term
<DL>...</DL>
<FONT></FONT>
<FORM>...</FORM>
<FRAME>...</FRAME>
<H#></H#>
<HEAD>...</HEAD>
<HR>...</HR>
<HTML></HTML>
<META>...</META>
<SCRIPT></SCRIPT>
<TABLE></TABLE>
Creates a table
<TD></TD>
<TR></TR>
<TH></TH>
Advantages
A HTML document is small and hence easy to send over the net.
It is small because it does not include formatted information.
JDBC-ODBC Bridge, which we will cover shortly. The question now becomes
"Why do you need JDBC?" There are several answers to this question:
1. ODBC is not appropriate for direct use from Java because it uses a C
interface. Calls from Java to native C code have a number of
drawbacks in the security, implementation, robustness, and automatic
portability of applications.
2. A literal translation of the ODBC C API into a Java API would not be
desirable. For example, Java has no pointers, and ODBC makes
copious use of them, including the notoriously error-prone generic
pointer "void *". You can think of JDBC as ODBC translated into an
object-oriented interface that is natural for Java programmers.
3. ODBC is hard to learn. It mixes simple and advanced features
together, and it has complex options even for simple queries. JDBC, on
the other hand, was designed to keep simple things simple while
allowing more advanced capabilities where required.
4. A Java API like JDBC is needed in order to enable a "pure Java"
solution. When ODBC is used, the ODBC driver manager and drivers
must be manually installed on every client machine. When the JDBC
driver
is
written
completely
in
Java,
however, JDBC
code
is
client, and the machine housing the database as the server. The network can
be an Intranet, which, for example, connects employees within a corporation,
or it can be the Internet.
JAVA
Application
JDBC
DBMS
Java applet or
Html browser
Client machine
DBMS-proprietary protocol
Database server
Application
Server (Java)
JDBC
DBMS
sends them to the user. MIS directors find the three-tier model very
attractive because the middle tier makes it possible to maintain control over
access and the kinds of updates that can be made to corporate data. Another
advantage is that when there is a middle tier, the user can employ an easyto-use higher-level API which is translated by the middle tier into the
appropriate low-level calls. Finally, in many cases the three-tier architecture
can provide performance advantages.
Until now the middle tier has typically been written in languages such as C
or C++, which offer fast performance. However, with the introduction of
optimizing compilers that translate Java byte code into efficient machinespecific code, it is becoming practical to implement the middle tier in
Java. This is a big plus, making it possible to take advantage of Java's
robustness, multithreading, and security features. JDBC is important to
allow database access from a Java middle tier.
JDBC Driver Types
The JDBC drivers that we are aware of at this time fit into one of four
categories:
JDBC-ODBC Bridge
If possible, use a Pure Java JDBC driver instead of the Bridge and an
ODBC driver. This completely eliminates the client configuration required
by ODBC. It also eliminates the potential that the Java VM could be
corrupted by an error in the native code brought in by the Bridge (that is,
the Bridge native library, the ODBC driver manager library, the ODBC
driver library, and the database client library).
for
which
an
ODBC
driver
is
available.
The
Bridge
is
implemented as the
Sun.jdbc.odbc Java package and contains a native library used to access
ODBC. The Bridge is a joint development of Innersole and Java Soft.
Java Server Pages (JSP)
Java server Pages is a simple, yet powerful technology for creating and
maintaining dynamic-content web pages. Based on the Java programming
language, Java Server Pages offers proven portability, open standards,
and a mature re-usable component model .The Java Server Pages
architecture enables the separation of content generation from content
presentation. This separation not eases maintenance headaches; it also
allows web team members to focus on their areas of expertise. Now, web
page designer can concentrate on layout, and web application designers
on programming, with minimal concern about impacting each others
work.
Features of JSP
Portability:
Java Server Pages files can be run on any web server or web-enabled
application server that provides support for them. Dubbed the JSP engine,
this support involves recognition, translation, and management of the
Java Server Page lifecycle and its interaction components.
Components
It was mentioned earlier that the Java Server Pages architecture can
include reusable Java components. The architecture also allows for the
embedding of a scripting language directly into the Java Server Pages file.
The components current supported include Java Beans, and Servlets.
Processing
A Java Server Pages file is essentially an HTML document with JSP
scripting or tags. The Java Server Pages file has a JSP extension to the
server as a Java Server Pages file. Before the page is served, the Java
Server Pages syntax is parsed and processed into a Servlet on the server
side. The Servlet that is generated outputs real content in straight HTML
for responding to the client.
Access Models:
A Java Server Pages file may be accessed in at least two different ways. A
clients request comes directly into a Java Server Page. In this scenario,
suppose the page accesses reusable Java Bean components that perform
particular well-defined computations like accessing a database. The result
of the Beans computations, called result sets is stored within the Bean as
properties. The page uses such Beans to generate dynamic content and
present it back to the client.
In both of the above cases, the page could also contain any valid Java
code. Java Server Pages architecture encourages separation of content
from presentation.
Steps in the execution of a JSP Application:
1. The client sends a request to the web server for a JSP file by giving the
name of the JSP file within the form tag of a HTML page.
2. This request is transferred to the JavaWebServer. At the server side
JavaWebServer receives the request and if it is a request for a jsp file
server gives this request to the JSP engine.
3. JSP engine is program which can understands the tags of the jsp and
then it converts those tags into a Servlet program and it is stored at the
server side. This Servlet is loaded in the memory and then it is executed
and the result is given back to the JavaWebServer and then it is
transferred back to the result is given back to the JavaWebServer and
then it is transferred back to the client.
JDBC connectivity
The JDBC provides database-independent connectivity between the J2EE
platform and a wide range of tabular data sources. JDBC technology allows
an Application Component Provider to:
Perform connection and authentication to a database server
Manager transactions
Move SQL statements to a database engine for preprocessing and
execution
Execute stored procedures
Inspect and modify the results from Select statements
Purpose
The generated application is the first version upon the system. The overall
system is planned to be in the formal of distributed architecture with
homogeneous database platform. The major objective of the overall system
is to keep the following components intact.
Chapter
8
ER-DIAGRAMS
Entity-relationship model
Databases are used to store structured data. The structure of this data, together with other
constraints, can be designed using a variety of techniques, one of which is called entityrelationship modeling or ERM. The end-product of the ERM process is an entityrelationship diagram or ERD. Data modeling requires a graphical notation for
representing such data models. An ERD is a type of conceptual data model or semantic
data model.
The first stage of information system design uses these models to describe information
needs or the type of information that is to be stored in a database during the requirements
analysis. The data modeling technique can be used to describe any ontology (i.e. an
overview and classifications of used terms and their relationships) for a certain universe
of discourse (i.e. area of interest). In the case of the design of an information system that
is based on a database, the conceptual data model is, at a later stage (usually called
logical design), mapped to a logical data model, such as the relational model; this in turn
is mapped to a physical model during physical design. Note that sometimes, both of these
phases are referred to as "physical design".
There are a number of conventions for entity-relationship diagrams (ERDs). The classical
notation is described in the remainder of this article, and mainly relates to conceptual
modelling. There are a range of notations more typically employed in logical and
physical database design, including information engineering, IDEF1x (ICAM DEFinition
Language) and dimensional modelling.
Common symbols
Primary key
A sample ER diagram
A weak entity is an entity that can't be uniquely identified by its own attributes alone, and
therefore must use as its primary key both its own attributes and the primary key of an
entity it is related to. A weak entity set is indicated by a bold rectangle (the entity)
connected by a bold arrow to a bold diamond (the relationship). Double lines can be used
instead of bold ones.
Attributes in an ER model may be further described as multi-valued, composite, or
derived. A multi-valued attribute, illustrated with a double-line ellipse, may have more
than one value for at least one instance of its entity. For example, a piece of software
(entity=application) may have the multivalued attribute "platform" because at least one
instance of that entity runs on more than one operating system. A composite attribute may
itself contain two or more attributes and is indicated as having at least contributing
attributes of its own. For example, addresses usually are composite attributes, composed
of attributes such as street address, city, and so forth. Derived attributes are attributes
whose value is entirely dependent on another attribute and are indicated by dashed
ellipses. For example, if we have an employee database with an employee entity along
with an age attribute, the age attribute would be derived from a birth date attribute.
Sometimes two entities are more specific subtypes of a more general type of entity. For
example, programmers and marketers might both be types of employees at a software
company. To indicate this, a triangle with "ISA" on the inside is drawn. The superclass is
connected to the point on top and the two (or more) subclasses are connected to the base.
A relation and all its participating entity sets can be treated as a single entity set for the
purpose of taking part in another relation through aggregation, indicated by drawing a
dotted rectangle around all aggregated entities and relationships.
Alternative diagramming conventions
Crow's Feet
The "Crow's Feet" notation is named for the symbol used to denote the many sides of a
relationship, which resembles the forward digits of a bird's claw. You can see this claw
shape in the diagram to the right, representing the same relationship depicted in the
Common symbols section above.
In the diagram, the following facts are detailed:
This notation is gaining acceptance through common usage in Oracle texts, and in tools
such as Visio and PowerDesigner, with the following benefits:
ID
ID
BNAM
E
BANK
BID
CH
EC
K
BLOGIN
ACCN
O
PW
D
CID
REJECT
ATYPE
STATUS
RELAT
ED
BNAM
E
ACCN
O
ACTYP
E
BNAM
E
ID
CLOGIN
BNAM
E
CUSTOMER
PWD
CNAM
E
TPW
BAL
PWD
STATU
S
ACNO
CREJECT
BNAM
E
ID
CID
CID
DATABASE
DESIGN
STATU
S
The same fact can be expressed on multiple records; therefore updates to the table
may result in logical inconsistencies. For example, each record in an
unnormalized "DVD Rentals" table might contain a DVD ID, Member ID, and
Member Address; thus a change of address for a particular member will
potentially need to be applied to multiple records. If the update is not carried
through successfullyif, that is, the member's address is updated on some records
but not othersthen the table is left in an inconsistent state. Specifically, the table
provides conflicting answers to the question of what this particular member's
address is. This phenomenon is known as an update anomaly.
There are circumstances in which certain facts cannot be recorded at all. In the
above example, if it is the case that Member Address is held only in the "DVD
Rentals" table, then we cannot record the address of a member who has not yet
rented any DVDs. This phenomenon is known as an insertion anomaly.
There are circumstances in which the deletion of data representing certain facts
necessitates the deletion of data representing completely different facts. For
example, suppose a table has the attributes Student ID, Course ID, and Lecturer
ID (a given student is enrolled in a given course, which is taught by a given
lecturer). If the number of students enrolled in the course temporarily drops to
zero, the last of the records referencing that course must be deletedmeaning, as
a side-effect, that the table no longer tells us which lecturer has been assigned to
teach the course. This phenomenon is known as a deletion anomaly.
Candidate key: A candidate key is a minimal superkey, that is, a superkey for
which we can say that no proper subset of it is also a superkey. {DVD ID,
Member ID} would be a candidate key for the "DVD Rentals" table.
History
Edgar F. Codd first proposed the process of normalization and what came to be known as
the 1st normal form:
Edgar F. Codd used the term "non-simple" domains to describe a heterogeneous data
structure, but later researchers would refer to such a structure as an abstract data type.
Normal forms
The normal forms (abbrev. NF) of relational database theory provide criteria for
determining a table's degree of vulnerability to logical inconsistencies and anomalies. The
higher the normal form applicable to a table, the less vulnerable it is to such
inconsistencies and anomalies. Each table has a "highest normal form" (HNF): by
definition, a table always meets the requirements of its HNF and of all normal forms
lower than its HNF; also by definition, a table fails to meet the requirements of any
normal form higher than its HNF.
The normal forms are applicable to individual tables; to say that an entire database is in
normal form n is to say that all of its tables are in normal form n.
Newcomers to database design sometimes suppose that normalization proceeds in an
iterative fashion, i.e. a 1NF design is first normalized to 2NF, then to 3NF, and so on.
This is not an accurate description of how normalization typically works. A sensibly
designed table is likely to be in 3NF on the first attempt; furthermore, if it is 3NF, it is
overwhelmingly likely to have an HNF of 5NF. Achieving the "higher" normal forms
(above 3NF) does not usually require an extra expenditure of effort on the part of the
designer, because 3NF tables usually need no modification to meet the requirements of
these higher normal forms.
Edgar F. Codd originally defined the first three normal forms (1NF, 2NF, and 3NF).
These normal forms have been summarized as requiring that all non-key attributes be
dependent on "the key, the whole key and nothing but the key". The fourth and fifth
normal forms (4NF and 5NF) deal specifically with the representation of many-to-many
and one-to-many relationships among attributes. Sixth normal form (6NF) incorporates
considerations relevant to temporal databases.
First normal form
Note that all relations are in 1NF. The question of whether a given
representation is in 1NF is equivalent to the question of whether it is a
relation.
Note that if none of a 1NF table's candidate keys are composite i.e.
every candidate key consists of just one attribute then we can say
immediately that the table is in 2NF.
There must be no non-trivial join dependencies that do not follow from the
key constraints. A 4NF table is said to be in the 5NF if and only if every
join dependency in it is implied by the candidate keys.
Data type
Number
Varchar2
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
Data type
Number
Size
20
BID
PWD
BNAME
STATUS
Description:
Varchar2
Varchar2
Varchar2
Number
250
250
250
10
Data type
Number
Varchar2
Varchar2
Number
Size
20
220
220
10
Description: This table stores the details about the Customer Login.
Data type
VARCHAR2
Varchar2
Varchar2
Varchar2
Size
220
220
220
220
Description: This table stores the details about the accounts that were rejected
by the Administrator
Table Name: Customer
Column Name
Id
Accno
Atype
Cname
Bname
Bal
Data type
Varchar2
Varchar2
Varchar2
Varchar2
Varchar2
Number
Size
220
220
220
220
220
30
TPWD
Status
Varchar2
Number
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.
Data type
Vachar2
Varchar2
Varchar2
Varchar2
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
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.
Data type
Number
Varchar2
Varchar2
Number
Varchar2
Varchar2
Varchar2
Varchar2
Varchar2
Size
30
120
120
30
120
120
120
120
120
Description: This table will be effected when a user transfers money between
different banks.
SOFTWARE
ARCHITECTURE
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.
The Block Diagram of the Architecture is as follows.
User Interface
(HTML / Java Script)
httpRespo
nse
httpReque
st
Web Server
Servlets/JSP
s
JDBC
Design
Document
Oracl
e
view
represents
the
system
from
the
users
perspective.
ii. 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
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
e-Transaction Interface
LOGIN
BANK REGISTRATION
CUSTOMER REGISTRATION
AMOUNT TRANSCATION
ACCOUNT CREATON
TRANSACTION VERIFICATION
ACCOUNT VERIFICATION
REPORTS GENEATION
Banker
Admin
Customer
Use case
name
Participating
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Login
Use case
name
Participating
Bank Registration
Admin
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Use case
name
Participating
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Customer Registration
Use case
name
Participating
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Amount Transaction
Use case
name
Participating
actors
Amount Transaction
Customer
The customer must enter all his personal details.
View Home page
Registered customer should be successfully logged out. Error
Message should be displayed on Un successful creation.
Best Error Handling techniques. Check on Mandatory fields.
Customer
The customer selects the target account and must give the
amount to be transferred across the accounts.
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.
Customer
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
The customer selects the target account and must give the
amount to be transferred across the accounts.
User should have an account and the destination account
should be valid one.
Transaction must be rolled back if exceptions are raised.
Use case
name
Participating
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Account creation
Use case
name
Participating
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Use case
name
Transaction Verification
Customer
The customer must create the bank account by giving the
necessary data.
Actor must know the proper bank account number and the
bank.
Not Applicable
Not Applicable
Customer
The customer can view the whether the transaction is
approved or rejected..
Not Applicable.
Not Applicable
Good Report Design
Participating
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Banker
Use case
name
Participating
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Account Verification
Use case
name
Participating
actors
Flow of
events
Entry
Condition
Exit
condition
Quality
Requirement
s
Reports Generation
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
Banker
The Banker can view the reports regarding the accounts and
transactions in specified time.
Duration of the Reports
Not Applicable
Good Report Design
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.
JSP: Implicit
Objects
SEQUENCE DIAGRAMS
Sequence Diagrams Represent the objects participating the interaction
horizontally and time vertically.
Sequence Diagram 1
: Login
Admin
: Log Out
Create Bank
Account
Use url
Press login button
Time
Sequence Diagram 2
: Accounts
DB
Customer
Get login page ()
Press login button()
Validate norms()
Sequence Diagram 3
(TX: Transactions)
:TX
: TXVerify
: DB
Customer
Press Amount
submit ()
Wait for acceptance()
Sequence Diagram 4
Coding
:
Login
Banker
:
Banker
Privel
: TXValidate
:Account
Validate
Reports()
: DB
Chapter
10
Screens
Chapter
11
Testing &
Debugging
Strategies
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.
Psychology of Testing
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.
The tests are inadequate to detect possibly present errors.
The software more or less confirms to the quality and reliable
standards.
Levels of Testing
In order to uncover the errors present in different phases we have the
concept of levels of testing.Acceptance
The basic levels of testing are as shown
Testing
below
Client Needs
System Testing
Requirements
Design
Integration Testing
Code
Unit Testing
System 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.
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
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 this
errors resulting from interaction between modules initially avoided.
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.
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.
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 ATM has been tested against requirements of project and it is
checked whether all requirements of project have been satisfied or not.
Acceptance Testing
Acceptance Test is performed with realistic data of the client to demonstrate
that
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.
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.
Chapter
12
User Manual
Installation
Make sure that the system meets the software and hardware requirements.
Server Side Installation:
Deploy the content of the folder eti into the webapps folder of the web
server.
For example : <tomcat-home>\webapps\
Database Schema Import:
Login to oracle with system as username and <password> (default is
manager) as password. User create user command to create a user called
eti with a password eti.
Create user eti identified by eti;
Grant resource and connect privileges to the user by using grant command.
Grant connect to eti;
Grant resource to eti;
Close the sql command prompt.
Copy the file eti.dmp in the eti folder to the respected drive.
User import command to import the schema into the eti directory.
Imp system/manager fromuser=eti touser=eti file=eti.dmp;
After completion of import.
Start the tomcat server
Login to tomcat manager as admin
Click on eti.
Then you will get the home page of the e-Transaction interface.
Client Side Installation:
Being the web-based system make sure that internet explorer installed on
the system.
Access the application using http://<server-ip>:8080
Enter tomcat-manager.
Access eti application.
Chapter1
3
Conclusions &
Recommendations
Bibliography:
References for the Project Development 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
Oracle 10g Books Online and Online Help support.
Web Enable Commercial Application Development Using Java 2.0 by
Ivan Bayross
Professional Java Server Programming Subhramanyam Allamaraju.
Inside Servlets.
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.