project

1. INTRODUCTION & OBJECTIVES
The main objective of the proposed solution is to be automated the various functions and activities of the bank through Internet. The solution will facilitate to the bank employees and the account holders with the different modules. This solution is very much necessary for the private sector banks and the corporate sector. The banking industry will take a new shape and explore like never before. Using the solution the bankers and account holders can generate various kinds of reports.

BUSINESS REQUIREMENTS:

Searching Capabilities:
For the account holder’s convenience and on hand information, this solution provides certain searching and checking features for his account. The account holder can any time and any number of time can log on and search for various details as the account’s balance, details of transactions, interest amounts, debits / credits, etc. The account holder will have his unique id and password for logging on to the account’s information.

User friendly:
The solution provides very simple and modified features, which are very easy to view and operate various features. The said project is designed and organized in very simplified manner to suit the current requirements of the account holders of various models such as Saving Bank Account, Current Account and Recurring Deposit Account.

Transaction Management:
The transaction made through either net or manually in bank need to have a consistency with respect to the account details and other related information like transaction details across various databases.

Value Added Service
The solution provides good number of value added services in comparison to the normal banking services. Account holder can view his accounts and give the instructions of making payment to various government organizations for various services. An account holder can issue the instructions to transfer certain amount to any particular account number of the same / different bank. Individual can log on to the site and open new bank account in his name online by following the simplified registration form instructions

Security
The Net Banking system deals with a lot of proprietary information for its users, which are confidential. It is therefore imperative to provide a means though which information can be kept confidential. This is also ensures that the data that is put into the system maintains its integrity because malicious or unauthorized individual will not have access to alter them. The security is at two different levels, one at account holder and other at administrative level at the bank’s office.

2.i. IDENTIFICATION OF NEED
The Net Banking is a web-based application some of its features are pointed out here:
The proposed system can be accessed from any part of the world, as opposed to stand alone or manual system, and provides information at any time, anywhere round the clock to the customers.
Even though it is a web-based application it will keep the details of its clients private and no body is allowed to tinker with the details.
The customer needs to register, by which he is given user name and password through which he can login and do the transactions whatever he wants to do. It provides easy to use and user friendly interface for the user.
The system provides freedom to the user to move freely around various screens and status of the system returned, as it was when he left the screen.
by expert personalities maintaining the web site.
The user can access the system at any time, because it’s 24-hour online from any where in the world.
The customer can do all the work online without persisting him to go to the bank like he can deposit the money, transfer amount from account to another account, can get this available balance, able to see the transaction reports that has done etc to mention a few.
The customer can save his money and time that is a valuable one in today’s day- to – day life.

2.ii. PRELIMINARY INVESTIGATION
1) New Account

Opening an account is possible through Internet. Account can be opened in the following methods explained below.

 Savings Account
Input
Customer Details.
Output
Alert message.

 Current Account
Input
Customer Details.
Output
Alert message.

 Credit Card
Customer needs to open a savings/current account bank account before opening the credit card account. Credit card account will be linked with their savings/current account. Customer needs to give their account detail when applying for the credit card.

Input
Customer account details
Output
Alert message

 Term Deposit
Term Deposit can be of two types: Flexible deposit and Cumulative deposit.
 Flexible Deposit
Flexible deposit has links with the savings bank account.
 Input
 Customer details
 Amount

 Period
o Years
o Months
o Days
 Renewal Option
o Repay the deposit
o Auto Renewal
 Principal only
 Principal along with interest
 Output
Alert message.

 Cumulative Deposit

 Input
 Customer details
 Amount
 Period
o Years
o Months
o Days

 Output
Alert message

 Recurring Deposit

 Input
 Customer details
 Period
 Installment amount
 Output
Alert message

2) Teller Services
Customer can use the facility of Teller to receive the details of their account. Teller services component provides the following services:

 Account Summary
 Transaction Details
 Card Transaction
 Interest Statement
 Un Cleared Cheque
 Account Summary
Customer can go to the Teller option and select the Account Summary. It provides account summary of the customer. Account summary will be grouped as:
 Regular Accounts
 Investment Accounts
 Loan Accounts
 Credit card Account

On selecting the account summary field, the type of accounts field will be displayed. Here the customer selects their account type and the account number will be entered further. On entering these, the account summary is displayed. Further, customer can enter from and to dates to see the opening balance and the closing balance.
 Input
 Account Type
 Account Number
 Statement Duration
 Output
 Date
 Description
 Credit/Debit
 Amount
 Balance
3) Transaction Details
User can use the transaction details option to obtain the details of their particular transactions.

 Input
 Account type
 Account number
 Period of transaction

 Output
Transaction history for the specified period

Card Transaction
The card transaction option will be provided for displaying the card transaction details.

 Input
 Card Type
 Card Number
 Period of transaction

 Output
 Card Number
 Account Number
 Expiry Date
 Date of transaction
 Pay To
 Amount

4) Interest Statement
In this option, a customer receives statement on interest earned/debited in their account for a particular period

 Input
 Account Type
 Account Number
 Interest type (accrued/credited/debited)
 From and to dates

 Output
 Date
 Description (loan no. or flexi deposit no etc)
 Interest Accrued/Credited/Debited
 Interest credited during last year
 Interest credited during the current year

5) Un Cleared Cheque
Here, a customer gets report about the Un Cleared Cheque. A separate table is being maintained for tracking cheque clearance.

 Input
 Account type
 Account number

 Output
Details of Un-Cleared Cheque:
 Date
 Drawn on
 Cheque number
 Amount
6) Transaction Services
This module offers two types of services:

 Funds Transfer
 Tax Payment
 Funds Transfer
Customers can use this service for regular payment from one account to another.
 Input
 Origin account number
 Destination account number
 Destination Bank
 Destination Branch
 Transfer Amount
 Frequency (One Time/Monthly/Quarterly/Yearly)
 Transfer Date
 Output
Alert message. In case if there is no sufficient fund in the origin account, the same must be alerted to the customer.

 Tax Payment
The Tax Payment component facilitates the customer to calculate tax payment amount and remit the same to the tax collecting authority.

Options provided to the customer include:

 Tax Payment request
 Tax Payment modification
 Tax Payment Cancellation

 Input
 Account Type
 Account Number
 Tax Payer ID
 Taxing Period
 Income during the above period
 Tax Payment amount
 Tax Collecting Authority

 Output
Alert message.

7) Bill Payment Services
Bill Payment Service components facilitate customers to instruct the banks to issue payment to their bills regularly against utilities such as electricity, gas, water etc. Customer nominates the service provider to the bank, provided the bank has a tie up with the provider. Service providers publish the bills to the bank and the customers will be alerted subsequently. Bank will make payment to these service providers as they get on line instructions from the customer. Bank debits service charge from customer’s account for providing the service.

Following details will be displayed and the customer has multiple options to choose:
 Bill No.
 Bill date
 Bill period
 Payee
 Amount
 Description
 Select for payment (check box)
Customer has to select bills to be paid from the check box option. The customer also gives the account number in which the amount has to be debited.
 Output
Alert message will be displayed to the user showing the service charge amount that will be debited from his account.
8) Other Payments
Other Payments component incorporates the following services:

 Recurring Payments
 Remittances
 Recurring Payments
A customer can move the regular payment facility from one account to another. Bank determines the service charge for providing the service to the user. It will be displayed to the user for information to decide for utilizing the services provided by the bank.

Here, the Customer instructs the bank to remit their recurring payment.

 Input
User has to enter the following fields:
 Payee Name
 Payment frequency
 Start date
 End date
 Payment Amount
 Account Type
 Account No.
 Branch
 Output
Alert message showing the service charge for providing the service.

 Remittances
Following services are provided to the customer:

 Transferring funds from one account to another within the bank.
 Making remittances.

Service charges will be displayed for the customer to avail the facility and will be determined by the bank.

 Input
The customer provides following details:
 Payee name
 Payee bank name and branch
 Payee account number
 Amount
 Account type
 Account No.
 Branch

 Output
Alert message showing the service charge to be debited from the customer’s account.

9) Requests
Under this module, the customer can request for the following services:

 Cheque Reorder
 New Card Request
 Draft / Cashier’s Cheque
 Stop Payment
 Cheque Reorder

In this case, the customer requests bank to issue a new chequebook and the bank may charge the customer for it.

 Input
 Account Type
 Account No.

 Output
Alert message showing the service charge to be debited from the customer’s account.

 New Card Request
In this process, the customer requests for a new card when he has lost his current card.

Input
 Card No.
 Card Type
 Lost on Date

Output

Alert message showing the service charge to be debited from the customer’s account.

 Draft / Cashier Cheque
The customer requests bank to issue draft/cashier’s cheque. Bank may deliver the DD/cashier’s cheque at users’ doorstep or payee’s doorstep. Bank will charge customer accordingly.

 Input
Options to user:
 Draft
 Cashier’s cheque

Further, customer enters the following details:
 Payee name
 Drawn on
 Amount
 Delivery options
o Deliver at customer’s doorstep
o Deliver at payee’s doorstep
 Payee’s address
o Door No.
o Street
o Area
o City
o PIN

 Output
Alert message showing the service charge to be debited from the customer’s account.

 Stop Payment
In this process, the customer informs the bank to hold payment for the cheques he has issued.
 Input
 Account Number
 Branch
 Cheque No

 Output
On entering the cheque number, following will be displayed:

 Payee Name
 Date of issue
 Branch

Alert message also will be displayed to the customer with service charge.

10) Maintenance Services
Maintenance Services module comprises the following components:

 Open another account
 Close account
 Modify account info
 Modify customer info
 Open Another Account
In this process, an existing customer opens another account.
 Input
 Customer ID
 Customer details

 Output
Alert message showing the new account number.

 Close Account
In this process, an existing account holder closes his account.

 Input
 Account type
 Account number
 Branch
 Reason
 For remittance of balance
o Account Transfer
 Account number
 Bank name
 Branch
o Cashier’s cheque details

 Output
Account summary will be presented to the customer. Check list will be provided to the customer regarding pending standing instructions, pending Cheque etc.

 Modify Account Info
In this process, a customer modifies his account information.

 Input
Customer has to enter the following information:
 Account type
 Account number
 Branch
 Mode of operation
 Account link
 Threshold

 Output
Alert message displaying that the account details have been modified.

 Modify Customer Info
In this process, the customer wants to change information about him such as address, phone number etc.

 Input
 Account type
 Account number
 Branch
 Applicant number
 Customer details

 Output
Alert message showing that the customer’s details have been modified.

11) User Alerts
The User Alerts module consists of the following processes:

 Credit card payment
 Flexible deposit maturity

The module provides options to user to receive the alert messages. Customer requests will be maintained in the database and the alert messages will be triggered whenever required and reach the customer through email. In addition, these alert messages will be consolidated and displayed when the user logs into the application.

 Credit Card Payment
User will be provided with two options:

 Two days before the due date
 One week before the due date

 Input
 Credit Card number
 Bank name
 Branch
 Alert message option

 Output
Alert message displaying that the customer’s request was processed.

 Flexible Deposit Maturity
User will be provided with two options:

 Two days before the date of maturity
 One week before the date of maturity

 Input
 Account number
 Amount
 Start date
 Maturity date
 Bank
 Branch

 Output
Alert message displaying that the customer’s request was processed.

3.FEASIBILITY STUDY
All projects are feasible – given unlimited resources and infinite time! Unfortunately, the development of computer-based system or product is more likely plagued by a scarcity of resources and difficult delivery dates. It is both necessary and prudent to evaluate the feasibility of a project at the earliest possible time. Months or years of effort, thousands or millions of dollars, and untold professional embarrassment can be averted if an ill-conceived system is recognized early in the definition phase.

Feasibility and risk analysis are related in many ways. If project risk is great the feasibility of producing quality software is reduced. During product engineering, however, we concentrate our attention on four primary areas of interest:

Technical Feasibility

This application in going to be used in an Internet environment called www (World wide web). So, it is necessary to use a technology that is capable of providing the networking facility to the application. This application as also able to work on distributed environment. Application on developed with J2EE (Java 2 Enterprise Edition platform) Technology. One major advantage in application is platform neutral. We can deploy and used it in any operating system.
GUI is developed using HTML.to capture the information from the customer. HTML is used to display the content on the browser. It uses TCP/IP protocol. It is an interpreted language. It is very easy to develop a page/document using HTML some RAD (Rapid Application Development) tools are provided to quickly design/develop our application. So many objects such as button, text fields, and text area etc are providing to capture the information from the customer.
We can use this application in any OS. They can have their own security and transactional advantages. But are the responsible for selecting suitable and secured OS, which is suitable to our application.
The back-end Oracle 8i and front-end application are platform independent. So we can port this enterprise application in any environment. Both are having their individual configuration to get better performance and backup issues.
Economical Feasibility
In present system customer need to go to biller’s place to pay the bill. So he/she needs to spend some time to complete this protocol. It is time consuming process some times customer not able to spend that much of time. In such case needs to pay some additional payment to the biller for late payment.
If it is developed in electronic payment system, He can pay the bill from any where in the world. No need to travel to pay the bills. For doing this process electronically have to spend some time.
Operational Feasibility:
In our application front end is developed using GUI. So it is very easy to the customer to enter the necessary information. But customer has some knowledge on using web applications before going to use our application.

4. SOFTWARE ENGINEERING PARADIGM APPLIED

DESIGN SPECIFICATION
Design of software involves conceiving planning out and specifying the externally observable characteristics of the software product. We have data design, architectural design and user interface design in the design process. These are explained in the following section. The goals of design process it to provide a blue print for implementation, testing, and maintenance activities.

DATA DESIGN
The primary activity during data design is to select logical representations of data objects identified during requirement analysis and software analysis. A data dictionary explicitly on the elements of the data structure. A data dictionary should be established and used to define both data and program design.

DESIGN METHODOLOGY
The two basic modern design strategies employed in software design are
1. Top Down Design
2. Bottom Up Design
Top Down Design is basically a decomposition process, which focuses on the flow of control. At later stages it concern itself with the code production. The first step is to study the overall aspects of the tasks at hand and to break it into a number of independent modules. The second step is to break each one of these modules further into independent sub-modules. The process is
Repeated one to obtain modules, which are small enough to group mentally and to code in a straightforward manner. One important feature is that at each level the details of the design at the lower level are hidden. Only the necessary data and control that must be called back and forth over the interface are defined.
In a bottom-up design one first identifies and investigates parts of design that are most difficult and necessary designed decision are made the reminder of the design is tailored to fit around the design already chose for crucial part. It vaguely represents a synthesis process explained in previous section.
One storage point of the top-down method is that it postpones details of the decision until the last stage of the decision. It allows making small design changes when the design is half way through. There is danger that the specifications will be incompatible and this will not be discovered until late in the design process. By contrast the bottom-up strategy first focuses on the crucial part so that feasibility of the design is tested at early stage.
In mixing top-down and bottom-up design it often appears that we start in the middle of the problem and work our way both up and down there. In a complex problem, it is often difficult to decide how to modularize the various procedures in such cases one might consider a list of system inputs and decide what functions are necessary to process these inputs. This is called back to front design. Similarly one can start with the required outputs and work backwards evolving so called front-back design. We have applied both the top down and bottom up approach in our design approach.

DATABASE DESIGN
Databases are normally implemented by using a package called a Data Base Management System (DBMS). Each particular DBMS has somewhat unique characteristics, and so such, general techniques for the design of database are limited. One of the most useful methods of analyzing the data required by the system for the data dictionary has developed from research into relational database, particularly the work of E.F.Codd. this method of analyzing data is called “Normalization”. Unnormalized data are converted into normalized data by three stages. Each stage has a procedure to follow.
NORMALIZATION
The first stage is normalization is to reduce the data to its first normal form, by removing repeating items showing them as separate records but including in them the key fields of the original record.
The next stage of reduction to the second normal form is to check that the record, which one is first normal form, all the items in each record are entirely dependent on the key of the record. If a data item is not dependent on the key of the record, but on the other data item, then it is removed with its key to form another record. This is done until each record contains data items, which are entirely dependent on the key of their record.
The final stage of the analysis, the reduction of third normal form involves examining each record, which one is in second normal form to see whether any items are mutually dependent. If there are any item there are removed to a separate record leaving one of the items behind in the original record and using that as the key in the newly created record.

BUSINESS MODELING:
The information flow among business function is modeled in a way that answers the following questions: what information drives the business process? What information is generated? What generate it? Where does the information go? Who process it?
DATA MODELING:
The information flow defined as a process of the business modeling is refined into a set of data objects that are needed to support the business. The characteristics (called attributes) of each object are identified and relationships between these objects are defined.
PROCESS MODELING:
The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing description are created for addition, modifying, deleting, or retrieving a data object.
THE LINEAR SEQUENTIAL MODEL:
The linear sequential model for software engineering some times called the “classic model” or the “water fall model,” the linear sequential suggests a systematic, sequential approach to software development that begins at eth system level and process through analysis, design, coding, testing, and maintenance.
The linear sequential model is the oldest and the most widely used paradigm for software engineering. Modeled after the conventional engineering cycle, the linear sequential model encompasses the following activities:
1) SYSTEM/INFORMATION ENGINEERING AND MODELLING:
 Because software is always part of a larger system (or business), work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when software must interface with other elements such as hardware, people, and databases.
 System engineering and analysis encompasses requirements gathering at the system level with a small amount of top-level analysis and design. Information engineering encompasses requirements gathering at the strategic business level and at the strategic business level and at the business area level.
2) SOFTWARE REQUIREMENTS ANALYSIS:
 The requirements gathering process is intensified and focused specifically on software. To understand the nature of the programs to be built, the software Engineer must under stand the information domain for the software, as well as required function, behavior, performance, and inter facing. Requirements for the both the system and the software are documented and reviewed with the customer.
3) DESIGN:
 Software design is actually a multi step process that focuses on four distinct attributes of a program: data structure, software architecture, interface representations, and procedural detail. The design process translates requirements into a representation of the software that can be assessed for quality before code generation begins. Like requirements the design is documented and becomes part of the software configuration.
4) CODE GENERATION:
 The design must be translated into a machine-readable form. The code generation step performs this task. If design is performed in a detailed manner, code generation can be accomplished mechanistically.

5) TESTING:
 Once code has been generated, program testing process focuses on the logical internals of the software, assuring that all statements have been tested, and on the functional externals that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with required results.

6) MAINTENANCE:
 Software will undoubtedly undergo change after it is delivered to the customer. Change will occur because errors have been encountered, because the software must be adapted to accommodate changes in its external environment (e.g., a change required because of a new operating system or peripheral devices), or because the customer requires functional or performance enhancement. Software maintenance reapplies each of the preceding phases to an existing program rather than a new one

5. SOFTWARE AND HARDWARE SPECIFICATIONS
Net Banking System is a network-based application. When we talk about hardware and software, we have to mention requirements on both the Client and Server part.
• Internet connection with 33.6 KBPS Modem.
• Pentium 2.77 GHz. 40 GB HDD, 512 MB RAM (Server).
• Any P.C with Windows compatibility, 64 MB RAM (Client).
• JDK 1.4 Enterprise Edition (J2EE)
• Weblogic version 7.0.
• Enterprise Java Beans
• JDBC/ODBC drivers installed.
• Functional Java enabled browser.
• Data Base (Oracle).
• Operating System (Windows).

INTERNET TERMINOLOGY
Java and Internet:
The Internet helped catapult Java to the forefront of programming and Java in turn has had a profound effect on the Internet. The reason is simple: Java expands the universe of objects that can move about freely in cyberspace. In a network, there are two broad categories of objects transmitted between the Server and your Personal Computer: passive information and dynamic, active programs like an object that can be transmitted to your computer, which is a dynamic, self-executing program. Such a program would be an active agent ton the client computer, yet the server would initiate it. As desirable as dynamic, networked programs are, they also present serious problems in the areas of security and portability. Prior to Java cyberspace was effectively closed to half the entities that now live there. Java addresses these concerns and doing so, has opened the door to an exiting a new form of program.
The rise of server-side Java applications is one of the latest and most exciting trends in Java programming. It was first hyped as a language for developing elaborate client-side web content in the form of applets. Now, Java is coming into its own as a language ideally suited for server-side development. Businesses in particular have been quick to recognize Java’s potential on the server-Java is inherently suited for large client/server applications. The cross platform nature of Java is extremely useful for organizations that have a heterogeneous collection of servers running various flavors of the Unix of Windows operating systems. Java’s modern, object-oriented, memory-protected design allows developers to cut development cycles and increase reliability. In addition, Java’s built-in support for networking and enterprise API provides access to legacy data, easing the transition from older client/server systems.
Java Servlets are a key component of server-side java development. A Servlets is a small, plug gable extension to a server that enhances the server’s functionality. Servlets allow developers to extend and customize and Java enabled server a web server, a mail server, an application server, or any custom server with a hitherto unknown degree of portability, flexibility and ease.
JAVA SERVER PAGE (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.
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 Pages lifecycle and its interaction with associated components.
The JSP engine for a particular server might be built-in or might be provided through a 3rd –party add-on. As long as the server on which you plan to execute the Java Server Pages supports the same specification level as that to which the file was written, no change should be necessary as you move your files from server to server. Note, however, that instructions for the setup and configuration of the files may differ between files.

COMPOSITION
It was mentioned earlier that the Java Server Pages architecture could 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 Serves. As the default scripting language, Java Server Pages use the Java Programming language. This means that scripting on the server side can take advantage of the full set of capabilities that the Java programming language offers.
PROCESSING
A Java Server Pages file is essentially an HTML document with JSP scripting or tags. It may have associated components in the form of. class, .jar, or .ser files- -or it may not. The use of components is not required.
The Java Server Pages file has a .jsp extension to identify it 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 customer. Because it is standard HTML, the dynamically generated response looks no different to the customer browser than a static response.

ACCESS MODELS
A Java Server Pages file may be accessed in at least two different ways: A client request comes directly into a Java Server Page.

In this scenario, suppose the page accessed reusable Java Bean components that perform particular well-defined computations like accessing a database. The result of the Bean’s 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. A request comes through a servlet.

The servlet generates the dynamic content. To handle the response to the client, the servlet creates a Bean and stores the dynamic content (sometimes called the result set) in the Bean. The servlet then invokes a Java Server Page that will present the content along with the Bean containing the generated from the servlet.
There are two APIs to support this model of request processing using Java Server Pages. One API facilitates passing context between the invoking servlet and the Java Server Page. The other API lets the invoking servlet specify which Java Server Page to use.
In both of the above cases, the page could also contain any valid Java code. The Java Server Pages architecture separation of content from presentation- -it does not mandate it.
JDBC requires that the SQL statements be passed as Strings to Java methods. For example, our application might present a menu of database tasks from which to choose. After a task is selected, the application presents prompts and blanks for filling information needed to carry out the selected task. With the requested input typed in, the application then automatically invokes the necessary commands.
In this project we have implemented three-tier model, commands are sent to a “middle tier” of services, which then send SQL statements to the database. The database process the SQL statements and sends the results back to the middle tier, which then sends them to the user. JDBC is important to allow database access from a Java middle tier.

What Is JDBCTM?
JDBCTM is a JavaTM API for executing SQL statements. (As a point of interest, JDBC is a trademarked name and is not an acronym; nevertheless, JDBC is often thought of as standing for "Java Database Connectivity".) It consists of a set of classes and interfaces written in the Java programming language. JDBC provides a standard API for tool/database developers and makes it possible to write database applications using a pure Java API.
Using JDBC, it is easy to send SQL statements to virtually any relational database. In other words, with the JDBC API, it isn't necessary to write one program to access a Sybase database, another program to access an Oracle database, another program to access an Informix database, and so on. One can write a single program using the JDBC API, and the program will be able to send SQL statements to the appropriate database. And, with an application written in the Java programming language, one also doesn't have to worry about writing different applications to run on different platforms. The combination of Java and JDBC lets a programmer write it once and run it anywhere.
Java being robust, secure, easy to use, easy to understand, and automatically downloadable on a network, is an excellent language basis for database applications. What is needed is a way for Java applications to talk to a variety of different databases. JDBC is the mechanism for doing this.
JDBC extends what can be done in Java. For example, with Java and the JDBC API, it is possible to publish a web page containing an applet that uses information obtained from a remote database. Or an enterprise can use JDBC to connect all its employees (even if they are using a conglomeration of Windows, Macintosh, and UNIX machines) to one or more internal databases via an intranet. With more and more programmers using the Java programming language, the need for easy database access from Java is continuing to grow.
MIS managers like the combination of Java and JDBC because it makes disseminating information easy and economical. Businesses can continue to use their installed databases and access information easily even if it is stored on different database management systems. Development time for new applications is short. Installation and version control are greatly simplified. A programmer can write an application or an update once, put it on the server, and everybody has access to the latest version. And for businesses selling information services, Java and JDBC offer a better way of getting out information updates to external customers.
CONNECTION
A connection object represents a connection with a database. A connection session includes the SQL statements that are executed and the results that are returned over the connection. A single application can have one or more connections with a single database, or it can have connections with many different databases.
OPENING A CONNECTION
The standard way to establish a connection with a database is to call the method DriverManager.getConnection. This method takes a string containing a URL. The Driver Manager class, referred to a the JDBC management layer, attempts to locate a driver than can connect to the database represented Driver classes, and when the method get Connection is called, it checks with each driver in the list until it finds one that can connect uses this URL to actually establish the connection.
_{-usually the driver or the database connectivity mechanism, which may be supported by one or more drivers. A prominent example of a sub protocol name is “oracle”, which has been reserved for URLs that specify “thin”-style data source names.
_{- a way to identify the database. The sub names can vary, depending on the sub protocol, and it can have a sub name with any internal syntax the driver writer chooses. The point of a sub name is to give enough information to locate the database.
SENDING STATEMENT:
Once a connection is established, it is used to pass SQL statements to its underlying database. JDBC does not put any restrictions on the kinds of SQL statements that can be sent; this provides a great deal of flexibility, allowing the use of database-specific statements or even non-SQL statements. It requires, however, that the user be responsible for making sure that the underlying database can process the SQL statements being sent and suffer the consequences if it cannot.
DRIVER MANAGER:
The Driver Manager class is the management layer of JDBC, working between the user and the drivers. It keeps track of the drivers that are available and handles establishing a connection between a database and the appropriate driver. It addition, the driver manager class attends to things like driver login time limits and the printing of log and tracing messages. The only method in this class that a general programmer needs to use directly is DriverManager.getConnection. As its name implies, this method establishes a connection to a database.

A JAVA2 Platform, Enterprise Edition Deployment

Acquiring a reference to a home object

Life cycle of a Stateful Session Bean(SFSB):

ORACLE 8i
Introduction to Oracle:
Any programing environment used to create containers, to manage human data, in the conceptualization as a Data Management System. Traditionally, the block of human data being managed is called a Database. Hence, in very simple terms, these programming environments can the conceptualized as Database Management Systems, in short DBM systems.
All Databases Management Systems (that is, Oracle is DBMS) allow users to create containers for data stories and management. These containers are called ‘cells’. The minimum information that has to be given to Oracle for a suitable container to be constructed, which can hold free from human data, is
The cell name
The cell length
Another name that programming environments use for a ‘Cell’ is ‘Field’. These can the conceptualized as follows.
Basic Database Concepts:
A database is a corporate collection of data with some inherent meaning, designed, built and populated with data for a specific purpose. A database stores data that is useful to us. This data is only a part of the entire data available in the world around us.
To be able to successfully design and maintain databases we have to do the following:
Identify which part of the world’s data is of interest to us.
Identify what specific objects in that part of the world’s data are of interest to us.
Identify a relationship between the objects.
Hence the objects, their attributes and the relationship between them that are of interest to us are still owed in the database that is designed, built and populated with data for a specific purpose.
Characteristics of a Database Management System:

It represents a complex relationship between data.
Keeps a tight control of debtor redundancy.
Enforces user-defined rules to ensure integrity of table data.
Has a centralized data dictionary for the storage of information pertaining to data and its manipulation.
Ensures that data can be shared across applications.
Enforces data access authorization has automatic, intelligent backup and recovery procedures for data.
Have different interfaces via which users can manipulate data.
Relational Database Management:
A relational database management system uses only its relational capabilities to manage the information stored in its databases.

Information Representation:
All information stored in a relational database is represented only by data item values, which are stored in the tables that make up the database. Associations between data items are not logically represented in any other way, such as the use of pointers from one table to the other.

Logical accessibility:
Every data item value stored in relational database is accessible by stating the nature of the table it is stored in, the name of the column under which it is stored and the value of the primary key that defines the row in which it is stored.
Representation of null values:
The database management system has a consistent method for representing null values. For example, null values for numeric data must be distinct from zero or any other numeric and for the character data it must be different from a string of blanks or any other character value.
Catalogue facilities:
The logical description of the relation database is represented in the same manner as ordinary data. This is done so that the facilities of the relation database management system itself can be used to maintain database description.
Data Language:
The relational database management system may support many types of languages for describing data and accessing the database. However, there must be at least one language that uses ordinary character strings to support the definition of data, the definition of views, the manipulation of data, constraints on data integrity, information concerning authorization and the boundaries for recovery of units.
View Updatability:
Any view that can be defined using combination of basic tables, that are theoretically updateable, these capital of being updated by the relational database management system.
Insert, Update and Delete:
Any operand that describes the results of a single retrieval operation is capable of being applied to an insert update or delete operation as well.
Physical data independence:
Changes made to physical storage representation or access methods do not require changes to be made to application programmers.
Logical Data Independence:
Changes made to tables, that do not modify any data stored in that table, do not require changes to be made to application programmers.
Integrity Constraints:
Constraints that apply to entity integrity and referential integrity are specifiable by the data language implemented by the database management system and not by the statements coded into the application program.
Database Distribution:
The data language implemented by the relation database management system supports the ability to distribute the database without requiring changes to be made to application programmers. This facility must be provided in the data language, whether or not the database management system itself supports distributed databases.
Non- Subversion:
If the relational database management system supports facilities that allow application programmers to operate on the tables a row at a time, an application programmer using this type access is prevented from by passing entity integrity or referential integrity constraints that are defined for the database.

6.i. DATABASE DESIGN

1) ACCOUNT_TYPES Table contains details of different types of Accounts.

Field Name Data Type/Size Description
ACC_TYPE_CD Char(2) Account Type Code (Primary Key)*
ACC_TYPE_DESC Varchar(20) Account Type Description
MIN_AMT Number(5) Minimum Amount to Deposit
INTEREST_RATE Number(4,2) Rate of Interest
MIN_PERIOD Number(2) Minimum Period in Months

*Possible values are:
SB – Saving Banks Account CA – Current Account
CC – Credit Card Account TD – Term Deposit
RD – Recurring Deposit

2) STATES Table contains details of the Indian States.

Field Name Data Type/Size Description
STATE_CD Char(2) State Code (Primary Key)
STATE_NAME Varchar(30) State Name

3) ACCOUNTS Table contains details of each Account.

Field Name Data Type/Size Description
ACCOUNT_NO Char(8) Account Number (Primary Key)
ACC_CAT Char(1) Account Category*
OPERATION_MODE Char(1) Operation Mode#
OPEN_DATE Date Opening Date
BALANCE_AMT Number(10,2) Balance Amount
INT_NAME Varchar(25) Introducer’s Name
INT_ACC_NO Char(8) Introducer’s Account Number
BRANCH Varchar(20) Introducer’s Branch
KNOW_APPLICANTS Number(2)) Introducer knows applicants since number of months

* Possible values include:
S – Single J – Joint C – Custodial

# Possible values include:
S – Self F – Former/Survivor E – Either/Survivor C –

4) CUSTOMERS Table contains details of each Customer.

Field Name Data Type/Size Description
Cust_code Char(7) Customer Code (Primary Key)
APPLICANT_NO Number(1) Applicant Number (1 or 2 or 3)
ACCOUNT_NO Char(8) Account Number
ACCOUNT_NO2 Char(8) Second Account Number (Optional)
CUST_FNAME Varchar(25) Customer’s First Name
CUST_MNAME Varchar(25) Customer’s Middle Name
CUST_LNAME Varchar(25) Customer’s Last Name
HOUSE_NO Varchar(10) House Number
STREET1 Varchar(20) Street Name
STREET2 Varchar(20) Street Name
AREA Varchar(20) Area Name
CITY Varchar(20) City Name
PIN Char(6) PIN Code
STATE_CD Char(2) State Code
RES_PHONE Char(13) Residence Phone
CELL_PHONE Char(10) Cell Phone
EMAIL Varchar(30) E-Mail Address
NO_YEARS_ADDRESS Number(2) Number of years residing in the address
PROFESSION Varchar(20) Profession Name
ORGANIZATION Varchar(20) Organization Name
WORKING_SINCE Date Date since working
DESIGNATION Varchar(20) Designation Name
OFF_DOOR_NO Varchar(10) Office Door Number
OFF_STREET Varchar(20) Office Street Name
OFF_AREA Varchar(20) Office Area Name
OFF_CITY Varchar(20) Office City Name
OFF_PIN Char(6) Office PIN Code
OFF_STATE_CD Char(2) Office State Code
OFF_PHONE Char(13) Office Phone Number
PAN_GIRN Char(10) PAN/GIRN Number
GENDER Char(1) Gender (Male/Female)
BIRTH_DATE Date Date of Birth
MAR_STATUS Char(1) Marital Status
REL_FIRST_APP Varchar(10) Relationship with the First Application
EDUCATION Varchar(20) Educational Qualification
MONTHLY_INCOME Number(6) Monthly Income
GUARDIAN_NAME Varchar(25) Guardian Name

5) TERM_DEPOSITS Table contains details of Term Deposit Accounts

Field Name Data Type/Size Description
ACCOUNT_NO Char(8) Account Number
DEPOSIT_AMT Number(10,2) Deposit Amount
TENURE_YEARS Number(2) Tenure Years
TENURE_MONTHS Number(2) Tenure Months
TENURE_DAYS Number(2) Tenure Days
PAYMENT_PERIOD Char(1) Payment Period*
RENEWAL_OPTION Char(1) Renewal Option#
ACCOUNT_NO Char(8) Account Number

* Possible values include:
M – Monthly Q – Quarterly O – On Maturity

# Possible values include:
P – Principal only D – Repay Deposit B – Principal + Interest

6) TERM_DEPOSIT_ALERTS Table contains details of Alerts for Term Deposits.

Field Name Data Type/Size Description
ACCOUNT_NO Char(8) Account Number
ALERT_OPTION Char(1) Alert Option*

* Possible values include:
T – Two days O – One week (before the date of maturity)

7) TRANSACTIONS Table contains details of Credit and Debit Transactions.

Field Name Data Type/Size Description
ACCOUNT_NO Char(8) Account Number
TRANS_TYPE Char(1) Transaction Type*
TRANS_DESC Varchar2(30) Transaction Description
AMOUNT Number(10,2) Transaction Amount
TRANS_DATE Date Transaction Date
TRANS_MODE Char(1) Transaction Mode#

* Possible values include:
C – Credit D – Debit
# Possible values include:
C – Cash Q – Cheque D – Demand Draft I – Internet S – Service Charge

8) NOMINEE Table contains details of Nominees.

Field Name Data Type/Size Description
ACCOUNT_NO Char(8) Account Number
NOM_NAME Varchar(25) Nominee Name
NOM_ADDR Varchar(40) Nominee Address
NOM_AGE Number(3) Nominee Age
RELATIONSHIP Varchar(10)) Relationship with Account Holder

9) CREDIT_CARDS Table contains details of Credit Card Accounts.

Field Name Data Type/Size Description
CREDIT_CARD_NO Char(10) Credit Card Number (Primary Key)
ACCOUNT_NO Char(8) Account Number
ISSUE_DATE Date Date of Issue
EXPIRY_DATE Date Date of Expiry
MAX_AMT Number(6) Maximum Credit Amount
STATUS Char(1) Status*

* Possible values include:
V – Valid L – Lost

10) CARD_TRANSACTIONS Table contains details of Card Transaction.

Field Name Data Type/Size Description
CREDIT_CARD_NO Char(10)
DESCRIPTION Varchar(50)
CREDIT_AMT Number(10,2)
CREDIT_DATE Date
PAYTO Varchar(30)

11) CREDIT_CARD_ALERTS Table contains details of Alerts for Credit Cards.

Field Name Data Type/Size Description
CREDIT_CARD_NO Char(10) Credit Card Number
ALERT_OPTION Char(1) Alert Option*

* Possible values include:
T – Two days O – One week (before the date of maturity)

12) RECURRING_DEPOSITS Table contains details of Recurring Deposit Accounts.

Field Name Data Type/Size Description
ACCOUNT_NO Char(8) Account Number
INSTAL_AMT Number(10,2) Installment Amount
TENURE_YEARS Number(2) Tenure Years
TENURE_MONTHS Number(2) Tenure Months
TENURE_DAYS Number(2) Tenure Days

13) LOAN_TYPES Table contains details of different Types of Loans.

Field Name Data Type/Size Description
LOAN_TYPE Char(3) Loan Type Code (Primary Key)
LOAN_DESC Varchar(20) Loan Type Description
INTEREST_RATE Number(4,2) Rate of Interest

14) LOANS Table contains details of Loans availed by different Account Holders.

Field Name Data Type/Size Description
LOAN_CODE Char(9) Loan Code (Primary Key)
LOAN_TYPE Char(3) Loan Type Code
ACCOUNT_NO Char(8) Account Number
APPLIED_DATE Date Date of applying for Loan
LOAN_PERIOD Number(3) Loan Period in Months
LOAN_AMT Number(6) Loan Amount
EMI Number(6) Equal Monthly Installments
DOC_DETAILS Long Document Details
STATUS Char(1) Status
NO_OF_INSTAL Number(3) Total Number of Installments
LAST_PAID Date Date of Last Payment

15) CHEQUES Table contains details of Cheques submitted by the Account Holders.

Field Name Data Type/Size Description
CHEQUE_NO Varchar(10) Cheque Number
PAYER_ACC_NO Char(8) Account Number of Payer
PAYER_BANK Varchar(20) Bank of Payer
PAYER_BRANCH Varchar(15) Branch of Payer Bank
PAYEE_ACC_NO Char(8) Account Number
CHEQUE_DATE Date Cheque Date
SUBMITTED_DATE Date Submitted Date
CHEQUE_AMT Number(10,2) Cheque Amount
STATUS Char(2) Status of Cheque
16) FUNDS_TRANSFERS Table contains details of Funds Transfers.

Field Name Data Type/Size Description
FUNDS_TRANS_CODE Char(10) Funds Transfer Code
ORIGIN_ACC_NO Char(8) Origin Account Number
TRANS_AMT Number(10,2) Transfer Amount
TRANS_DATE Date Transfer Date
DEST_ACC_NO Char(8) Destination Account Number
DEST_BANK Varchar2(20) Destination Bank Name
DEST_BRANCH Varchar2(20) Destination Bank Branch
FREQUENCY Char(1) Frequency of Transfer
INSTALMENTS Number(2) Number of Installments

17) TAX_PAYMENTS Table contains the details of Tax Payments.

Field Name Data Type/Size Description
TAX_PAY_CODE Char(10) Tax Payment Code
ORIGIN_ACC_NO Char(8) Origin Account Number
TAX_PAYER_ID Char(10) Tax Payer ID
TAX_PAY_DATE Date Tax Payment Date
TAX_FROM Date Tax From Date
TAX_TO Date Tax To Date
INCOME Number(10,2) Income during above period
TAX_AMOUNT Number(8,2) Tax Amount
TAX_AUTHORITY Varchar(30) Tax Authority

18) BILL_PAYMENTS Table contains the details of Bill Payments.

Field Name Data Type/Size Description
BILL_PAY_CODE Char(10) Bill Payment Code
ACCOUNT_NO Char(8) Account Number
BILL_NO Char(10) Bill Number
BILL_DATE Date Bill Date
BILL_FROM Date Bill From Date
BILL_TO Date Bill To Date
PAYEE Varchar(30) Payee Name
BILL_AMOUNT Number(10,2) Bill Amount
BILL_DESC Varchar(30) Bill Description

19) CHEQUE_REORDER Table contains the details of the Cheque Reorders.

Field Name Data Type/Size Description
CHEQ_RO_CODE Char(9) Cheque Reorder Code
ACCOUNT_NO Char(8) Account Number
REQUEST_DATE Date Request Date

20) DRAFT_CHEQUE Table contains the details of Drafts and Cheques Issued.

Field Name Data Type/Size Description
ACCOUNT_NO Char(8) Account Number
DD_OR_CHEQ Char(1) DD or Cheque
PAYEE Varchar(30) Payee Name
DRAWN_ON Date Drawn On Date
DD_CHEQ_NO Varchar(10) DD or Cheque Number
AMOUNT Number(10,2) Amount
DELIVERY Char(1) Delivery Option*
PAYEE_DOOR_NO Varchar(10) Payee Door Number
PAYEE_STREET Varchar(20) Payee Street
PAYEE_AREA Varchar(20) Payee Area
PAYEE_CITY Varchar(20) Payee City
PAYEE_PIN Char(6) Payee PIN Code
STATUS Char(1) Status

* Possible values include:
C – Customer’s doorstep P – Payee’s doorstep

6.ii. DATA FLOW DIAGRAMS

ZERO-LEVEL

DFD-I

DFD-II

DFD-III

DFD-IV

DFD-V

DFD-VI

DFD-VII

DFD-VIII

DFD-IX

DFD-X

DFD-XI

DFD-XII

DFD-XIV

7. SAMPLE CODE

8. CODE EFFICIENCY

MEASURES OF CODE EFFICIENCY
The code is designed with the following characteristics in mind.
1. Uniqueness: The code structure must ensure that only one value of the code with a single meaning is correctly applied to a give entity or attribute.
2. Expandability: The code structure are designed for in a way that it must allow for growth of it’s set of entities or attributes, thus providing sufficient space for the entry of new items with in each classification.
3. Conciseness: The code requires the fewest possible number of positions to include and define each item.
4. Uniform size and format: Uniform size and format is highly desirable in mechanized data processing system. The addition of prefixes and suffixes to the root code should not be allowed especially as it is incompatible with the uniqueness requirement.
5. Simplicity: The codes are designed in a simple manner to understand and simple to apply.
6. Versatility: The code allows modifying easily to reflect necessary changes in conditions, characteristics and relationship of the encode
7. d entities. Such changes must result in a corresponding change in the code or coding structure.
8. Sortability: Reports are most valuable for user efficiency when sorted and presented in a predetermined format or order. Although data must be sorted and collaged, the representative code for the date does not need to be in a sortable form if it can be correlated with another code that is sortable.
9. Stability: Codes that do not require to be frequently updated also promote use efficiency. Individual code assignments for a given entity should be made with a minimal likelihood of change either in the specific code or in the entire coding structure.
10. Meaningfulness: Code is meaningful. Code value should reflect the characteristics of the coded entities, such as mnemonic features unless such a procedures results in inconsistency and inflexibility.
11. Operatability: The code is adequate for present and anticipated data processing both for machine and human use. Care is taken to minimize the clerical effort and computer time required for continuing the operation.

9. OPTIMIZATION OF CODE

INTRODUCTION:

A good program is not the one that solves the intended problem alone but the one that does it efficiently. An ideal compiler should produce target code that is as good as can be written by hand crafted meticulously to run on the target machine in the most efficient manner both in terms of time of execution and memory requirements. The reality however is that this goal is achieved only in limited, cases and that too with difficulty. Nonetheless, the code produced by straight forward compiling algorithms can often be made more space and time efficient. This is accomplished by applying transformations on the produced code. These transformations aiming at optimization of compiled code are known as code optimization and compilers that apply code improving transformations are called optimizing compilers.
The optimization may be machine dependent or machine independent. A machine independent optimization is a set of program transformations that improve the target code without taking into consideration any properties of the target machine. Machine dependent optimizations, such as register allocation and utilization of special machine instruction sequences, on the other hand, depend on the target machine.
The overall performance of a program can be effectively improved if we can identify the frequently executed parts of a program and then make these parts as efficient as much as possible. According to Pareto principle, most programs spend ninety per cent of their execution time in ten percent of the code. While the actual percentages may vary, it is often the case that a small fraction of a program accounts for most of the running time. Profiling the run-time execution of a program on representative input data accurately identifies the heavily traveled regions of a program. Unfortunately, a compiler does not have the benefit of sample input data, so it must make best guess as to where the program hot spots are.
In practice, the program's inner loops are good candidates for improvement. In a language that emphasizes control constructs like while and for statements, the loops may be evident from the syntax of the program; in general, a process called contra/¬flow analysis identifies loops in the flow graph of a program.
The best technique for deciding what transformations are worthwhile to put into a compiler is to collect statistics about the source programs and evaluate the benefit of a given set of optimizations on a representative sample of real source programs.
Organization for an optimizing compiler
There are often levels at which a program can be improved algorithm level, source program level, intermediate level or target level. Since the techniques needed to analyze and transform a program do not change significantly with the level, this chapter concentrates on the transformation of intermediate code using the organization shown below:

In the code optimizer programs are represented by flow graphs, in which edges indicate the flow of control and nodes represent basic blocks. Unless otherwise specified a program means a single procedure.
Sources of Optimization
Let us see some of the most useful code-improving transformations. If looking only at can perform it the statements in a basic block are called local otherwise, it is called global. Many transformations can be performed at both the local and global levels. Local transformations are usually performed first.

Function-preserving Transformations
There are a number of ways in which a compiler can improve a program without changing the function it computes. Common sub-expression elimination, copy propagation, dead code elimination, and constant folding are common examples of such function-preserving transformations.
Frequently, a program will include several calculations of the same value, such as an offset in an array. The programmer cannot avoid some of these duplicate calculations because they lie below the level of detail accessible within the source language.

Common sub-expressions
An occurrence of an expression E is called a common sub-expression if E was previously computed, and the values of variables in E have not changed since the previous computation. We can avoid recomputing the expression if we can use the previously computed value. Removing such command sub-expressions may optimize the code.
COPY PROPAGATION
The idea behind the copy-propagation transformation is to use g for f, wherever possible after the copy statement f: =g.
Dead-Code
A variable is live at a point in a program if its value can be used subsequently; otherwise, it is dead at that point. A related idea is dead or useless code, statements that compute values that never get used. While the programmer is unlikely to introduce any dead code intentionally, it may appear as the result of previous transformations. Deducing at compile time that the value of an expression is a constant and using the constant instead is known as constant folding.
LOOP OPTIMIZATIONS
Loops are very important place for optimizations where programs tend to spend the bulk of their time. rf we decrease the number of instructions in an inner loop, even if we increase the amount of code outside that loop, the running time of a program may be improved considerably. Three important techniques for loop optimization are - code motion, which moves code outside a loop; induction-variable elimination, which we apply to eliminate loop indices from the inner loops; and reduction in strength, which replaces an expensive operation by a cheaper one, such as a multiplication by an addition. Some of the loop optimization techniques are discussed below:
Code Motion
Code motion is an important modification that decreases the amount of code in a loop. It takes an expression and transforms it yielding the same result independent of the number of times a loop is executed (i.e. a loop-invariant computation) and places the expression before the loop. The assumption made here is that an entry for the loop exists. For instance, evaluation of aaa is a loop-invariant computation in the following while-statement:
While (i < = aaa)
Code motion will transform it into the following equivalent statements:
ttt = aaa;
While (i < = ttt)
Clearly the code motion technique has reduced the number of computations in this form.
Induction Variables And Reduction In Strength
Code motion may not be applicable to all the situations. Loops are usually processed from inside to outside. For example, consider the following loops:
Note that the values of j and t2 remain in lock step; every time the value of j decreases by 1, that of t2 decreases by 5 because 5* j is assigned to t2. Such identifiers are called induction variables.
By the process of induction variable elimination in a loop, it may be possible to get rid of all but one when more than one induction variables are present.
Basic Blocks Optimization
Many of the structure-preserving transformations can be implemented by constructing a directed-cyclic-graph (DAG) for a basic block. There is a node in the DAG for each of the initial values of the variables appearing in the basic block, and there is a node n associated with each statement s within the block. The children of n are those nodes corresponding to statements that are the last definitions prior to s of the operands used by s. Node n is labeled by the operator applied at s, and also attached to n is the list of variables for which it is the definition within the block. We also note those nodes, if any, whose are live on exit from the block; these are the output nodes.

10. VALIDATION CHECKS
In the text boxes like name, address etc., only alphabets and number could be entered thus if the operator by mistake enters other special characters, it would not be entered.
In the text boxes like age, telephone number only numbers could be entered.
If the users do not fill any of the fields, which could not be empty,, a message would be displayed asking to enter the required parameters.
When a user starts the applications, a login form will be displayed prompting to enter the username and password, if even any one of them is not matched with the details stored in the database, the user will be warned to re-enter the correct details.
While entering the details of new customer, the customer number which cannot be null value will be automatically generated which is one greater than the highest number existing previously.
When the details of one customer are modified even if one parameter is missed a message will be displayed asking to enter complete details.

11. SYSTEM TESTING & IMPLEMENTATION

SOFTWARE TESTING TECHNIQUES:
Software testing is a critical element of software quality assurance and represents the ultimate review of specification, designing and coding.

TESTING OBJECTIVES:
1. Testing is process of executing a program with the intent of finding an error.
2. A good test case design is one that has a probability of finding an as yet undiscovered error.
3. A successful test is one that uncovers an as yet undiscovered error.

These above objectives imply a dramatic change in view port.
Testing cannot show the absence of defects, it can only show that software errors are present.

TEST CASE DESIGN:
Any engineering product can be tested in one of two ways:
1. White Box Testing: This testing is also called as glass box testing. In this testing, by knowing the specified function that a product has been designed to perform test can be conducted that demonstrates each function is fully operation at the same time searching for errors in each function. It is a test case design method that uses the control structure of the procedural design to derive test cases. Basis path testing is a white box testing.

Basis Path Testing:
i. Flow graph notation
ii. Cyclomatic Complexity
iii. Deriving test cases
iv. Graph matrices
Control Structure Testing:
i. Condition testing
ii. Data flow testing
iii. Loop testing

2. Black Box Testing: In this testing by knowing the internal operation of a product, tests can be conducted to ensure that “ all gears mesh”, that is the internal operation performs according to specification and all internal components have been adequately exercised. It fundamentally focuses on the functional requirements of the software.
The steps involved in black box test case design are:
i. Graph based testing methods
ii. Equivalence partitioning
iii. Boundary value analysis
iv. Comparison testing
SOFTWARE TESTING STRATEGIES:
A software testing strategy provides a road map for the software developer. Testing is a set of activities that can be planned in advance and conducted systematically. For this reason a template for software testing a set of steps into which we can place specific test case design methods should be defined for software engineering process. Any software testing strategy should have the following characteristics:
1. Testing begins at the module level and works “outward” toward the integration of the entire computer based system.
2. Different testing techniques are appropriate at different points in time.
3. The developer of the software and an independent test group conducts testing.
4. Testing and Debugging are different activities but debugging must be accommodated in any testing strategy.

Unit Testing: Unit testing focuses verification efforts in smallest unit of software design (module).

1. Unit test considerations
2. Unit test procedures

Integration Testing: Integration testing is a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing. There are two types of integration testing:

1. Top-Down Integration: Top down integration is an incremental approach to construction of program structures. Modules are integrated by moving down wards throw the control hierarchy beginning with the main control module.

2. Bottom-Up Integration: Bottom up integration as its name implies, begins construction and testing with automatic modules.

3. Regression Testing: In this contest of an integration test strategy, regression testing is the re execution of some subset of test that have already been conducted to ensure that changes have not propagate unintended side effects.
VALIDATION TESTING:
At the culmination of integration testing, software is completely assembled as a package; interfacing errors have been uncovered and corrected, and a final series of software tests – validation testing may begin. Validation can be fined in many ways, but a simple definition is that validation succeeds when software functions in a manner that can be reasonably expected by the customer.
Reasonable expectation is defined in the software requirement specification – a document that describes all user-visible attributes of the software. The specification contains a section titled “Validation Criteria”. Information contained in that section forms the basis for a validation testing approach.
VALIDATION TEST CRITERIA:
Software validation is achieved through a series of black-box tests that demonstrate conformity with requirement. A test plan outlines the classes of tests to be conducted, and a test procedure defines specific test cases that will be used in an attempt to uncover errors in conformity with requirements. Both the plan and procedure are designed to ensure that all functional requirements are satisfied; all performance requirements are achieved; documentation is correct and human-engineered; and other requirements are met.
After each validation test case has been conducted, one of two possible conditions exist: (1) The function or performance characteristics conform to specification and are accepted, or (2) a deviation from specification is uncovered and a deficiency list is created. Deviation or error discovered at this stage in a project can rarely be corrected prior to scheduled completion. It is often necessary to negotiate with the customer to establish a method for resolving deficiencies.
CONFIGURATION REVIEW:
An important element of the validation process is a configuration review. The intent of the review is to ensure that all elements of the software configuration have been properly developed, are catalogued, and have the necessary detail to support the maintenance phase of the software life cycle. The configuration review sometimes called an audit.
Alpha and Beta Testing:
It is virtually impossible for a software developer to foresee how the customer will really use a program. Instructions for use may be misinterpreted; strange combination of data may be regularly used; and output that seemed clear to the tester may be unintelligible to a user in the field.
When custom software is built for one customer, a series of acceptance tests are conducted to enable the customer to validate all requirements. Conducted by the end user rather than the system developer, an acceptance test can range from an informal “test drive” to a planned and systematically executed series of tests. In fact, acceptance testing can be conducted over a period of weeks or months, thereby uncovering cumulative errors that might degrade the system over time.
If software is developed as a product to be used by many customers, it is impractical to perform formal acceptance tests with each one. Most software product builders use a process called alpha and beta testing to uncover errors that only the end user seems able to find.
A customer conducts the alpha test at the developer’s site. The software is used in a natural setting with the developer “looking over the shoulder” of the user and recording errors and usage problems. Alpha tests are conducted in controlled environment.
The beta test is conducted at one or more customer sites by the end user of the software. Unlike alpha testing, the developer is generally not present. Therefore, the beta test is a “live” application of the software in an environment that cannot be controlled by the developer. The customer records all problems that are encountered during beta testing and reports these to the developer at regular intervals. As a result of problems reported during bets test, the software developer makes modification and then prepares for release of the software product to the entire customer base.
IMPLEMENTATION:
Implementation is the process of having systems personnel check out and put new equipment into use, train users, install the new app Depending on the size of the organization that will be involved in using the application and the risk associated with its use, systems developers may choose to test the operation in only one area of the firm, say in one department or with only one or two persons. Sometimes they will run the old and new systems together to compare the results. In still other situation, developers will stop using the old system one-day and begin using the new one the next. As we will see, each implementation strategy has its merits, depending on the business situation in which it is considered. Regardless of the implementation strategy used, developers strive to ensure that the system’s initial use in trouble-free.
Once installed, applications are often used for many years. However, both the organization and the users will change, and the environment will be different over weeks and months. Therefore, the application will undoubtedly have to be maintained; modifications and changes will be made to the software, files, or procedures to meet emerging user requirements. Since organization systems and the business environment undergo continual change, the information systems should keep pace. In this sense, implementation is ongoing process.
Evaluation of the system is performed to identify its strengths and weakness. The actual evaluation can occur along any of the following dimensions.
Operational Evaluation: assessment of the manner in which the system functions, including ease of use, response time, suitability of information formats, overall reliability, and level of utilization.
Organization Impact: Identification and measurement of benefits to the organization in such areas as financial concerns operational efficiency, and competitive impact. Includes impact on internal and external information flows.
User Manager Assessment: Evaluation of the attitudes of senior and user mangers within the organization, as well as end-users.
Development Performance: Evaluation of the development process in accordance with such yardsticks as overall development time and effort, conformance to budgets and standards, and other project management criteria. Includes assessment of development methods and tools.
Unfortunately system evaluation does not always receive the attention it merits. Where properly managed however, it provides a great deal of information that can improve the effectiveness of subsequent application efforts.

12. SYSTEM SECURITY MEASURES
Security in software engineering a broad topic. This script limits its scope to defining and discussing software security, software reliability, developer responsibility, and user responsibility.

COMPUTER SYSTEMS ENGINEERING
Software security applies information security principles to software development. Information security is commonly defined as "the protection of information systems against unauthorized access to or modification of information, whether in storage, processing or transit, and against the denial of service to authorized users of the provision of service to unauthorized users, including those measures necessary to detect, document, and counter such threats."
Many questions regarding security are related to the software life cycle itself. In particular, the security of code and software processes must be considered during the design and development phase. In addition, security must be preserved during operation and maintenance to ensure the integrity of a piece of software.
The mass of security functionality employed by today's networked world, might deceive us into believing that our jobs as secure system designers are already done. However, computers and networks are incredibly insecure. The lack of security stems from two fundamental problems. Systems, which are theoretically secure, may not be secure in practice. Furthermore, systems are increasingly complex; complexity provides more opportunities for attacks. It is much easier to prove that a system is insecure than to demonstrate that one is secure to prove insecurity, one simply exploits certain system vulnerability. On the other hand, proving a system secure requires demonstrating that all possible exploits can be defended against (a very daunting, if not impossible, task).

GOOD PRACTICE
Security requires more managing and mitigating risk than it does technology. When developing software one must first determine the risks of a particular application. For example, today's typical web site may be subject to a variety of risks, ranging from defacement, to distributed denial of service (DDoS, described in detail later) attacks, to transactions with the wrong party.
Once the risks are identified, identifying appropriate security measures becomes tractable. In particular, when defining requirements, it is important to consider how the application will be used, who will be using the application, etc. With that knowledge, one can decide whether or not to support complex features like auditing, accounting, no repudiation, etc.
Another potentially important issue is how to support naming. The rise of distributed systems has made naming increasingly important. Naming is typically handled by rendezvous: a principal exporting a name advertises it somewhere, and someone wishing to use that name searches for it (phone books and directories are examples). For example, in a system such as a resource discovery system, both the resources and the individuals using those resources must be named. Often there are tradeoffs with respect to naming: while naming can provide a level of indirection, it also can create additional problems if the names are not stable. Names can allow principals to play different roles in a particular system, which can also be useful.

13. COST ESTIMATION OF THE PROJECT
For a given set of requirements it is desirable to know how much it will cost to develop the software to satisfy the given requirements, and how much time development will take. These estimates are needed before development is initiated. The primary reason for cost and schedule estimation is to enable the client or developer to perform a cost-benefit analysis and for project monitoring and control. Automation more practical use of these estimates is in bidding for software projects, where the developers must give cost estimates, to a potential client for the development contract.
For a software development project, detailed and accurate cost and schedule estimates are essential prerequisites for managing the project. Otherwise, even simple questions like “is the project late”, “are there cost overruns” and “when is the project likely to complete” cannot be answered. Cost and schedule estimates are also required to determine the staffing level for a project during different phases. It can be safely said that cost and schedule estimates are fundamental to any form of project management and generally always required for a project.

Cost in a project is due to the requirements for software, hardware, and human resources. Hardware resources are such things as the computer time, terminal time, and memory required for the project, whereas software resources include the tools and compilers needed during development. The bulk of the cost of software development is due to the human resources needed, and most cost estimation procedures focus on this aspect. Most cost estimates are determined in terms of person-months (PM). By properly including the “Overheads” (i.e. the cost of hardware, software, office space etc,) in the dollar cost of the person-month, besides including the direct cost of the person-month, most costs for a project can be incorporated by using PM as the basic measure.
Estimates can be based in subjective opinion of some person or determined through the user of models. Though there are approaches to structure the opinions of persons for achieving a consensus on the cost estimate it is generally accepted that it is important to have a more scientific approach to estimate though the user of models.
Uncertainties in cost estimation:

One can perform cost estimation at any point in the software life circle. As the cost of the project depends on the nature and characteristics of the project, at any point, the accuracy of the estimate will depend on the among or reliable information we have about the final product. Clearly, when the product is delivered, the cost can be accurately determined, as all the data about the project and the resources spent be fully known by then. This is cost estimation with complete knowledge about be fully known by then. This is cost estimation with complete knowledge about the project. On the other extreme is the point when the project is being initiated or during the feasibility study. At this time

14. SCREENS

15. PERT CHART
PERT CHART:

Program Evaluation Review Technique, PERT can be both a cost and a time management system. PERT is organized by events and activities or tasks. PERT has several advantages over bar charts and is likely to be used with more complex projects. One advantage of PERT is that it is scheduling device that also shows graphically which tasks must be completed before others are begun.
Also, by displaying the various task paths, PERT enables the calculation of a critical path. Each path consists of combinations of tasks, which must be completed. PERT controls time and cost during the project and also facilitates finding the right balance between completing a project on time and completing it within the budget.

Gantt Chart ( Bar Chart ):

A Bar Chart is perhaps the simplest form of formal project management. The bar chart is also known as Gantt Chart. It is used almost exclusively for scheduling purposes and therefore controls only the time of projects.
Gantt Charts are a project control technique that can be used for several purposes, including scheduling, budgeting and resource planning. A Gantt Chart is a Bar Chart, with each bar representing an activity. The bars are drawn against a time line. The length of each bar is proportional to the length of time planned for the activity.

16.FUTURE SCOPE OF APPLICATION

The Net Banking System for the recruitment process can be further developed into a separate, automated system with the following enhancements:

• A mail server can be implemented to send mails directly from the system to the inbox of the recipient. The code needed for the same is being implemented except the mail server.
• Help file can be included. The system, as of now, does not support any help facility for the users of the system. A help menu can be provided with a special function key and help command in the main page itself. Help can be either introduced as a separate window, a reference to a printed manual or as one or two line suggestion produced in a fixed screen location.
• The system can use typed commands, as they were once the most common mode of communication with the system. The typed command can be provided through control sequence or function keys or typed word.
• A training module can be included in the system. This module can be used to train the users of the system about the systems usage. The training module can be in the form of a HTML file describing different commands usage and the overall function of the system. This would be a handy tool for the developer to train the HR department people.

17.BIBLIOGRAPHY

The following books and manuals provided a lot of help to us in making this project a reality.
JAVA COMPLETE REFERENCE
PATRICK NAUGHTON,
HERBERT SCHILDT
JAVA HOW TO PROGRAM
DEITERL & DEITEL
JAVA UNLEASHED
JDBC DATABASE ACCESS WITH JAVA
GRAHAM AMELTON,
RICK CATTEL,
MATDENE FISHER.
SERVLET PROGRAMMING
O’RELLY
SOFTWARE ENGINEERING
R. E. FAIRELY
SOFTWARE ENGINEERING
PRESSMAN
AN INTEGRATED APPROACH TO SOFTWARE
ENGINNERING
PANKAJ JALOTE
NAROSA PUBLISING HOUSE
FUNDAMENTALS OF DATABASE SYSTEMS
ELMASRI & NAVATHE
ADDISON WESLY
LEARN SQL IN 21 DAYS
TECH MEDIA
SQL, PL/SQL
IVAN BAYROSS
BPB PUBLICATIONS

SYSTEM ANALYSIS AND DESIGN
ELIAS M AWAD
GALGOTIA
J2EE 2ND EDITION
WROX PRESS}}

project

Wednesday, December 17, 2008

FAQS

Documentation of "ONLINE BANKING" Project

Followers

Blog Archive

About Me