Theoretical Background

J2EE DOMAIN OVERVIEW

Today, more and more developers want to write distributed transactional applications for the enterprise and leverage the speed, security, and reliability of server-side technology. To reduce costs and fast-track enterprise, design and development, the JavaTM2 Platform, Enterprise Edition (J2EETM ) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The J2EE platform gives you a multi-tiered distributed application model, the ability to reuse components, a unified security model and flexible transaction control. Not only can you deliver innovative customer solution to market faster than ever, but you are platform-independent J2EE component-based solutions not tied to the products and APIs of any one vendor.

DISTRIBUTED MULTI TIERED(N-TIERED) APPLICATIONS:

The J2EE platform uses multi tiered distributed application model. This means application logic is divided into components according to functions, and the various application components that make up a J2EE application are installed on different machines depending on which tier in the multi tiered J2EE environment the application component belongs. Fig. 1 shows two multi tiered J2EE applications divided into the tier described in the bullet listed below. The J2EE application parts shown in following figure is presented in J2EE Application Components.

CLIENT TIER COMPONENTS RUN ON THE CLIENT MACHINE. APPLICATION TIER COMPONENTS BETWEEN THE CLIENT AND THE

SERVER. WEB TIER COMPONENTS RUN ON THE TOMCAT4.1 SERVER.

While a J2EE application can consist of three tier, J2EE multi-tiered applications because they are distributed over three different locations: client machines, J2EE server machine, and the database or legacy machines at the backend. Three-tiered applications that run in this way extend the standard two tiered client and server model by placing a multithreaded application server between the client application and back-end storage.

One of the recurring themes that you will run into with J2EE is the notion of supporting application that are partitioned into several levels, or Tiers. That is an architectural cornerstone of J2EE and merits a little explanation. The overview presented here will be a good introduction or review that will help lay the foundation for understanding the rationale behind much of J2EE’s design and services it provides.

Figure: n-Tier Architecture

A software application is composed of, we can break it down into three fundamental concerns, or logical layer. The first area of concern is displaying stuff of the user and collecting data from the user. That user interface layer is often called presentation layer, since its job is to present stuff of the user and provide a means for the user too present stuff of the software system. The presentation layer includes the part of the software that creates and controls the user interface and validates the user action.Underlying the presentation layer is the logic that makes the application work, and handles the important processing. The logic in a payroll application that, for example, multiples the hours worked by the salary to determined how much to pay some one, is one example of this kind of logic. This logic layer is called the business rules layer, or more in formally the middle tier.

All non-trivial business applications need to read and store data, and the part or the software that is responsible for reading and writing data-from whatever source that might be forms the data access layer.

J2EE APPLICATION COMPONENTS

J2EE applications are made up of components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and communicates with other components. The J2EE specification defines the following J2EE components:

Application clients and applets are client components. Java Servlet and JavaServer PagesTM (JSPTM) technology components are web

components. Enterprise JavaBeansTM(EJBTM) components (enterprise beans) are business

components.J2EE components are written in the Java programming language and compiled in the same way as any program in the language. When you work with the J2EE platform, the difference is that J2EE components are assembled into a J2EE application, verified that they are well-formed and in compliance with the J2EE specification, and deployed to production where they are run and managed by J2EE server.

CLIENT COMPONENTS

A J2EE application can be web-based or non-web-based. An application client executes on the client machine for a non-web-based J2EE application, and a web browser downloads web pages and applets to the client machine for a web-based J2EE application.

APPLICATION CLIENTS

An application client runs on a client machine and provides a way for users to handle tasks such as J2EE system or application administration. It typically has a graphical user interface created from Swing or Abstract Window Toolkit (AWT) APIs, but a command-line interface is certainly possible. Application clients directly access enterprise beans running in the business tier. However, if the J2EE application client requirements warrant it, an application client can open an HTTP connection to establish communication with a servlet running in the web tier.

WEB BROWSERS

The user’s web browser downloads static or dynamic Hypertext Markup Language (HTML), Wireless Markup Language (WML), or Extensible Markup Language (XML) web pages from the web tier. Dynamic web pages are generated by servlets or pages created with JavaServer Pages technology (JSP Pages) running in the web tier.

APPLETS

A web page downloaded from the web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java VM installed in the web browser. However, client systems will likely need Java Plug-in and possibly a security policy file so the applet can successfully execute in the web browser. JSP pages are the preferred API for creating a web-based client program because no plug-ins or security policy files are needed on the client systems. Also, JSP pages enable cleaner and more modular application design because they provide a way to separate applications programming from web page design. This means personnel involved in web page design do not need to understand Java programming language syntax to do their jobs. Applets that run in other network-based systems such as hand held devices or car phones can render Wireless Markup Language (WML) pages generated by a JSP page or a servlet running on the J2EE server. The WML page is delivered over Wireless Application Protocol (WAP) and the network configuration requires a gateway to translate WAP to HTTP and back again. The gateway translates the WAP request coming from the handheld device to an HTTP request for the J2EE server, and then translates the HTTP server response and WML page to a WAP server response and WML page for display on the handheld device.

JAVABEANSTM COMPONENT ARCHITECTURE

The client tier might also include a component based on the JavaBeansTM component architecture (JavaBeans component) to manage the data flow between an application client and applet and components running on the J2EE server. JavaBeans components are not considered J2EE components by the J2EE specification. JavaBeans components written for the J2EE platform have instance variable and get and set methods for accessing the data in the instance variables. JavaBeans used in this way are typically simple in design and implementation, but should conform to the naming and design conventions outlined in the JavaBeans component architecture.

J2EE SERVER COMMUNICATIONS

Figure 2 shows the various elements that can make up the client tier. The client communicates with the business tier running on the J2EE server either directly or as in the case of a client running in a browser, by going through JSP pages or servlets running in the web tier.

Figure2: Server Communications

THIN CLIENTS

J2EE applications use a thin client. A thin client is a lightweight interface to the application that does not do things like query databases, execute complex business rules, or connect to legacy applications. Heavyweight operations like these are off-loaded to web or enterprise beans executing on the J2EE server where they can leverage the security, speed, services, and reliability of J2EE server-side technologies.

WEB COMPONENTS

J2EE web components can be either JSP pages or servlets. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets, but allow a more natural approach to creating static content.

Static HTML pages and applets are bundled with web components during application assembly, but are not considered web components by the J2EE specification. Server-side utility classes can also be bundled with web components, and the HTML pages, are not considered web components.

Like the client tier and as shown in Figure 3, the web tier might include a Java-Beans object to manage the user input and send that input to enterprise beans running in the business tier for processing.

Figure 3: Web Tier and J2EE Application

N-Tier Architecture of J2EE:

JDBC

Java Database Connectivity (JDBC) is a standard Java interface for connecting to relational database from Java. JDBC provides cross-DBMS connectivity to a wide range of Structured Query Language (SQL) databases. It also provides access to others tabular data sources such as spreadsheets or flat files, with the JDBC 2.0 Application Program Interface (API). You can use the JDBC API to take advantage of the Java Platform’s “Write Once, Run Anywhere” capabilities for industrial-strength, cross-platform applications that require access enterprise data. With a JDBC driver, you can connect all corporate data even in heterogeneous environment.

JAVA ON THE SERVER

Java byte code on the server instead of or in addition to the client enabling you to build tradition client/server application and modern thin-client Web applications. Two key server-sides Java technologies are Servlets and JavaServer Pages. Servlets are protocol and platform-independent server-side components which extend the functionality of a Web Server. JavaServer Pages (JSPs) extend the functionality of Servlets by allowing Java Servlet code to be embedded in an HTML file.

Java Servlets are platform and server-independent Java technology. They are Java program that run as a module inside any request or response-oriented server, such as Hypertext Transfer Protocol (HTTP) server, to produce dynamic content. You write Servlets in Java; therefore you use Sun Microsystems Java Servlet Application Program Interface (API) to develop and extend your Web Servers. Servlet API is a standard Java extension. It provides interfaces that a Java Servlet program can use to communicate with its server environment and with the client.

Java Server Pages (JSP) simplifies the process of building Web-based applications containing dynamic content by allowing you to embed dynamic content in a standard Hyper Text Markup Language (HTML) or XML Web page. The JavaServer Pages is a standard is based on the Java Servlet standard for writing dynamic server-site Web service module in pure Java. They allow you to create dynamic Web pages and Web-based applications and embedding pure Java code scriplets in a Web page. In addition, Java Server Pages can contain references to Java Script, standard Java Beans components, or Java code resident on the server. This allows you to leverage the power of enterprise Java components.

Oracle 9i as is an integrated middle-tier server that implements Java presentation and application server standard of servlets and JSP. By replicating load-balanced middle-tier Oracle9iAS servers, system administrators can scale up internet applications without touching the data servers in the back-tier. Because both Oracle servers implement the same standard Java platform, deployment decisions can be made and changed without impacting the design and implementation of the application code. This write once, deploy anywhere capability is a key benefit of oracle9i

THE ORACLE ADVANTAGE

Oracle9i provides a complete, integrated set of products to enable the development, debugging and deployment of Java database applications for the internet. Oracle9iAS is a key component offering many benefits: 1. Oracle9iAS can make your development 3 times faster because it offers a

comprehensive and integrated development and deploy environment for e-business applications. All the components of Oracle9iAS are integrated and in turn they are integrated with the development tools to make your development productive.

2. Oracle9iAS can run applications three times faster by levering the pretend caching technologies built into product. Together, the data cache and the web cache can improve the site performance 3-fold.

3. Oracle9iAS can make your site run for 1/3rd of the cost. The web cache can significantly reduce the hardware needed to support the same no. of uses. An integrated product lets you focus on your business rather than playing system integrator.

4. Working with one vendor significantly reduces your support cost and time.5. Build Java Application-design, develop and debug-using JDeveloper (Oracle

internet Developer Suite).6. Store data-Object, Relational, files, word, messages, XML-in the Oracle9i database

server.

7. Deploy and Run Applications on a scalable, reliable, secure and highly performance platform-the Oracle9i Application server.

WHAT IS JSP?

JSP or Java Server Pages are high level extension of servlet and it enables the developers to embed java code in html pages. JSP files are finally compiled into a servlet by the JSP engine. Compiled servlet is used by the engine to serve the requests.

BENEFITS OF JSP

Java Server Pages (JSP) technology enables Web developers and designers to rapidly develop and easily maintain, information-rich, dynamic Web pages that leverage existing business systems. As part of the Java technology family, JSP technology enables rapid development of Web-based applications that are platform independent. JSP technology separates the user interface from content generation, enabling designers to change the overall page layout without altering the underlying dynamic content.

Separating the static HTML from the dynamic content provides a number of benefits over servlets alone, and the approach used in Java Server Pages offers several advantages over competing technologies such as ASP, PHP, or Cold Fusion. JSP is widely supported and thus doesn’t lock you into a particular operating system or Web server and that JSP gives you full access to servlet and Java technology for the dynamic part, rather than requiring you to use an unfamiliar and weaker special-purpose language.

JSP ARCHITECTURE

About the Model 2 versus Model 1 Architecture:

Early web application design regarded the JSP page as the focal point for the entire application. Termed Model 1 architecture, the JSP page not only contains the display elements to output HTML, but is also responsible for extracting HTTP request parameters, call the business logic (implemented in JavaBeans, if not directly in the JSP), and handle the HTTP session. Although Model 1 is suitable for simple applications, this architecture usually leads to a significant amount of scriptlets (Java code embedded within HTML code in the JSP page), especially if there is a significant amount of request processing to be performed.

The following diagram illustrates the JSP Model 1 architecture.

As a response to the Model 1 architecture, Apache Software Organization developed the Jakarta Project's Struts framework. Struts is an open source framework for building web applications that integrate with standard technologies, such as Java Servlets, JavaBeans, and JSP. Struts offers many benefits to the web application developer, including Model 2 implementation of Model-View-Controller (MVC) design patterns in JSP web applications. The MVC Model 2 paradigm applied to web applications lets you separate display code (for example, HTML and tag libraries) from flow control logic (Struts action classes).

The following figure illustrates the Model 2 web application architecture, where Servlets control the flow of the web application and delegate the business logic to external components, usually JavaBeans or EJBs, while JSP pages generate the HTML for web browsers:

The following information gives a brief overview of the MVC Model 2 design pattern and the role of Oracle ADF: The Model portion of an MVC-based system typically comprises JavaBean classes that define the internal state of the system; they also specify the actions that can be taken to change that state. When you create your web application using the Oracle Application Development Framework (Oracle ADF), binding to the model layer is handled for you. Otherwise, you will need to create the data binding implementation for the view layer. The View portion is constructed using JSP technology or Oracle ADF UIX technology. JSP pages can contain static HTML (or XML) text called "template text", plus the ability to insert dynamic content based on the interpretation (at page request time) of special action tags. The JSP environment includes a set of custom JSP tag libraries (such as the Struts tag libraries), standard JSP action tags (such as those described in the JavaServer Pages Specification), and a facility to install your own JSP custom tag libraries. When you use the Oracle Application Development Framework (Oracle ADF), you can take advantage of the data binding facilities in JDeveloper that allow your web pages to display databound dynamic content from the model layer. For complete information about the data controls in JDeveloper. The Controller portion of the application is focused on receiving requests from the client (typically a user running a web browser), deciding what business logic function is to be performed, and then delegating responsibility for producing the next phase of the user interface to an appropriate View component. In Struts, the primary components of the Controller is a servlet of class ActionServlet and the class RequestProcessor. When you use the Struts Page Flow Diagram in JDeveloper, you can work with a visual representation of the application logic.

JSP WORKING

Although what is written in JSP often looks more like a regular HTML file than a servlet, behind the scenes, the JSP page is automatically converted to a normalservlet, with the static HTML simply being printed to the output stream associated with the servlet’s service method. This translation is normally done the first time the page is requested. To ensure that the first real user doesn’t get a momentary delay when the JSP page is translated into a servlet and compiled, developers can simply request the page themselves after first installing it. Many Web servers also let you define aliases so that a URL that appears to reference an HTML file really points to a servlet or JSP page.

Figure: JSP Lifecycle

Basic JSP Lifecycle

Once compilation is complete, the JSP lifecycle has these phases:

Loading and instantiation: The server finds the java class for the JSP page and loads it into the Virtual Machine. After the class is loaded, the JVM creates one or more instances of the page. This can occur right after loading, or it can occur when the first request is made.

Initialization: The JSP page is initialized. If you need to execute code during initialization, you can add a method to the page that will be called during initialization.

Request processing: The page responds to a request. After performing its processing, a response is returned to the client. The response consists solely of HTML tags or other data; none of the java code is sent to the client.

End of life: The server stops sending requests to the JSP. After all current requests are finished processing, any instances of the class are released. If you need code to execute and perform any cleanup actions, you can implement a method that will be called before the class instance is released.

When a client sends a request for a JSP, the web server gives the request to the JSP container, and the JSP container determines which JSP page implementation class should handle the request. The JSP container then calls a method of the JSP page implementation class that processes the request and returns a response through the container and web server to the client.

Packaging Applications

A J2EE application is delivered in an Enterprise Archive (EAR) file, a standardJava Archive (JAR) file with an .ear extension. Using EAR files and modulesmakes it possible to assemble a number of different J2EE applications usingsome of the same components. No extra coding is needed; it is only a matter ofassembling (or packaging) various J2EE modules into J2EE EAR files.An EAR file (see Figure 1–6) contains J2EE modules and deployment descriptors.A deployment descriptor is an XML document with an .xml extension thatdescribes the deployment settings of an application, a module, or a component.Because deployment descriptor information is declarative, it can be changedwithout the need to modify the source code. At runtime, the J2EE server readsthe deployment descriptor and acts upon the application, module, or componentaccordingly.There are two types of deployment descriptors: J2EE and runtime. A J2EEdeployment descriptor is defined by a J2EE specification and can be used to configuredeployment settings on any J2EE-compliant implementation. A runtimedeployment descriptor is used to configure J2EE implementation-specificparameters. For example, the Sun Java System Application Server Platform Edition8 runtime deployment descriptor contains information such as the contextroot of a web application, the mapping of portable names of an application’sresources to the server’s resources, and Application Server implementation-specificparameters, such as caching directives. The Application Server runtimedeployment descriptors are named sun-moduleType.xml and are located in thesame directory as the J2EE deployment descriptor.

Figure 1–6 EAR File Structure

A J2EE module consists of one or more J2EE components for the same containertype and one component deployment descriptor of that type. An enterprise beanmodule deployment descriptor, for example, declares transaction attributes andsecurity authorizations for an enterprise bean. A J2EE module without an applicationdeployment descriptor can be deployed as a stand-alone module. The fourtypes of J2EE modules are as follows:• EJB modules, which contain class files for enterprise beans and an EJBdeployment descriptor. EJB modules are packaged as JAR files with a .jarextension.• Web modules, which contain servlet class files, JSP files, supporting classfiles, GIF and HTML files, and a web application deployment descriptor.Web modules are packaged as JAR files with a .war (web archive) extension.• Application client modules, which contain class files and an applicationclient deployment descriptor. Application client modules are packaged asJAR files with a .jar extension.• Resource adapter modules, which contain all Java interfaces, classes,native libraries, and other documentation, along with the resource adapterdeployment descriptor. Together, these implement the Connector architecture(see J2EE Connector Architecture, page 22) for a particular EIS.Resource adapter modules are packaged as JAR files with an .rar(resource adapter archive) extension.

SSL

INTRODUCTION TO SSL

SSL, or SECURE SOCKET LAYER, is a technology which allows web browsers and web servers to communicate over a secured connection. This means that the data being sent is encrypted by one side, transmitted, and then decrypted by the other side before processing. This is a two-way process, meaning that both the server AND the browser encrypt all traffic before sending out data.

Another important aspect of the SSL protocol is Authentication. This means that during your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a "Certificate", as proof the site is who and what it claims to be. In certain cases, the server may also request a Certificate from your web browser, asking for proof that you are who you claim to be. This is known as "Client Authentication," although in practice this is used more for business-to-business (B2B) transactions than with individual users. Most SSL-enabled web servers do not request Client Authentication.

SSL CERTIFICATION

In order to implement SSL, a web server must have an associated Certificate for each external interface (IP address) that accepts secure connections. The theory behind this design is that a server should provide some kind of reasonable assurance that its owner is who you think it is, particularly before receiving any sensitive information. While a broader explanation of Certificates is beyond the scope of this document, think of a Certificate as a "digital driver's license" for an Internet address. It states what company the site is associated with, along with some basic contact information about the site owner or administrator.

This "driver's license" is cryptographically signed by its owner, and is therefore extremely difficult for anyone else to forge. For sites involved in e-commerce, or any other business transaction in which authentication of identity is important, a Certificate is typically purchased from a well-known Certificate Authority (CA) such as VeriSign or Thawte. Such certificates can be electronically verified -- in effect, the Certificate Authority will vouch for the authenticity of the certificates that it grants, so you can believe that that Certificate is valid if you trust the Certificate Authority that granted it.

In many cases, however, authentication is not really a concern. An administrator may simply want to ensure that the data being transmitted and received by the server is private and cannot be snooped by anyone who may be eavesdropping on the connection. Fortunately, Java provides a relatively simple command-line tool, called keytool, which can easily create a "self-signed" Certificate. Self-signed Certificates are simply user generated Certificates which have not been officially registered with any well-known CA, and are therefore not really guaranteed to be authentic at all. Again, this may or may not even be important, depending on your needs.

System Development Life Cycle (SDLC)

The Systems Development Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project from investigation of initial requirements through analysis, design, implementation and maintenance of the completed application.Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, rapid prototyping, incremental models. Mostly, several models are combined into some sort of hybrid methodology.The steps involved in the SDLC process are:

[1] Identification of problems:

The proposal to develop a new information system started with a formal request resulting from the identification of existing problems identified in the current systems. It provides a broad statement of user requirements-what the user expect the system to do and thus sets the direction of the project. This phase also sets the bounds, which define what part of the system can be changed by the project and what parts remain the same. The three important factors are -project goal, project bounds and resource limits. Problem definition demands the analyst to develop a thorough understanding of the existing System, parts of which has to be automated. This requires interaction with the clients, end users as well as studying manuals and procedures. Understanding the properties of the System that does not exist is more difficult and requires loads of creative thinking as well as a good problem definition. It is the job of the analyst to make aware the client of new probabilities with the automated System, thus, helping both to specify the requirements. Problem definition is a vital step in software requirement specification that gives a clear over-view of the System. In short to understand the objectives of the software to be built, the analyst must define the problem and understand the information-domain for the software, as well as, required function, behavior, performance and interface

[2]Software Requirement Analysis:

Prior to the beginning of development of software, it is obligatory to understand clearly the precise requirements of the customer and document them properly. In other words, the Requirements Analysis and Specification determines that what is the motive behind developing the product. Building a product without clearly understanding the requirement and improperly documenting the specification is bound to lead to dissatisfactory solution to the clients and ultimately lead to the rejection of the product. Thus, it is ensured for a successful project, it is obligatory to understand and document the requirements and specifications of the customers adequately and proceed accordingly thereafter.The Requirements Analysis and Specification is carried out in two stages:

1) Requirement Gathering and Analysis: This stage involves interviewing the customers and end users regarding the product to be developed, their specific requirements and suggestions.

2) Software Requirement Specification (SRS): The Software Requirement Specification is a documentation in which all requirements specified by the customer are organized in a systematic order so that it can be produced at various stages of the project for precise development of the product. The SRS is a documentation used by a wide variety of users such as, the end user, the customers, the software developers, test engineers, project managers etc. The SRS document can be viewed as a documentation of a contract between the developer and the customer as both of them has to agree to the SRS document before any sort of development begin.

The SRS documents contain the following aspects of the system:

I. Functional requirements which discuss the functionalities required from the system. The SRS document clearly describes each function which the system would support along with the corresponding input and output dataset.

II. Non-functional requirements that deals with the characteristics of the system that cannot be expressed as functions such as portability, usability etc.

III. Goals of implementation give general suggestions regarding the development. This section is concerned with the issues such as reusability of the system, new device support in the future etc.

[3]Feasibility Analysis

Feasibility Analysis of a project is performed with the aim to determine that whether it would technically and economically feasible to undertake the project. In other words, is there sufficient resources, technical and economical, available to develop the product. It involves the analysis of the problem and collection of all the relevant information relating to the project such as inputs to the system, processing of the inputs, the output required to be produced by the system and various constraints on the behavior of the system.

Feasibility Analysis is mainly of two types:

1) Technical Feasibility: Technical feasibility refers to the analysis that whether the technical support required to develop the product is available in sufficiency or not. In this, we opted for the J2EE platform to develop the product because it seemed ideal for the project to be developed in J2EE platform due to its unmatched features and very much user-friendliness. More over, using HTML, JSP to develop the front-end provide an excellent layout to the project. At the back-end, Oracle 9i as the database as it in the most commonly used database and most people could access it with ease. Thus, it is quite obvious that the project is technically feasible.

2) Economic Feasibility: Whether the project to be undertaken is economically feasible or not is determined by the Economic Feasibility Analysis. It involves the study that if there is sufficient finance available to complete the project. It is quite obvious that in order to develop a product, technical backup alone is not sufficient. Adequate capital is very much necessary for the successful completion of the project. Moreover, it also has to be determined that whether the capital spent on developing the project would fetch handsome returns or not; otherwise there is no point in developing the product, if it does not fetch any profit at all. In this case, the software is scheduled to develop with optimized cost in order to make the project economically feasible.

[4] System analysis:

System Analysis is the most basic and pervasive process involved in managing an organization. It means deciding in advance what action to take and when and how to take them. Planning is needed firstly for committing and allocating the organization limited resources towards achieving its objectives in the best possible manner and secondly for anticipating the opportunities and problems. As a whole 5 members have worked in the making of the software aiming towards their common goal i.e. to make it very effective and user friendly. In our Online Air Booking & Management, we plan the total system in such a methodical way, that the entire software is user-friendly and less expensive. We also highlight the area of Total Time Estimation i.e. to reduce the time effort to develop the software. The entire module is thoroughly tested by all the developer and equally examined by the friendly customer

[5] Design of the system:The potential systems subsystems, functional and technical component parts must be re-evaluated to determine how the system is to meet the requirements identified at the analysis phase.

In this instance a prototype system should be run in a simulated operational environment with real staff but test data which would not affect the real operation of the old system still continuing, and would allow the system to be tested safely and adequately on the sample data as well as the people who will have to make it work in future.

[6] Implementation:

The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like Compilers, Interpreters and Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal and Java are used for coding. In the development of the Online Banking software, we chose Java as the Programming language.

[7]Testing:

Testing is the process to execute a program with the intentions of finding errors. Testing a program consists of subjecting the program to a set of test inputs and observing the program to a set of test inputs and observing if the program behaves as expected.

The main objectives of Software Testing are:

i) Testing is a process of executing a program with the intent of finding errors.

ii) A good test case is one that has a high probability of finding “as yet undiscovered errors”.

iii) A successful test is one that uncovers as yet undiscovered errors.

Unit Testing

Unit Testing is undertaken when a module of the project has been coded and successfully reviewed. In case of unit testing, each of the modules is tested individually with the test cases and the behavior of the module to the inputs is recorded accordingly. It is quite obligatory of each module of a project because through it, the very primitive level errors can be detected and corrected.

Integration TestingIntegration Testing is performed with the objective of testing module interfaces in order to ensure that there are no errors in the parameter passing when one module invokes another module. During integration testing, different modules of a system are integrated in a planned manner using an integration plan. The integration plan specifies the steps and the order in which modules are combined to realize the full system. After each integration step, the partially integrated system is fasted.

System TestingSystem Testing is performed to validate a fully developed system to assure that it meets its specific requirements. System Testing is also referred to as Validation Testing as it validates the development of the product according to the SRS document System Testing is of three types:

1. Alpha Testing→ System Testing carried out by the test team within the developing organization.

2. Beta Testing→ System Testing performed by a selected group of friendly customers.

3. Acceptance Testing→ System Testing performed by the customer to determine whether to accept or reject the delivery of the product.

[8]Acceptance, installation, deployment:

This is the final stage of the development of the software where the developed software is installed at the client’s place and all the applications are deployed so as to enable the client to use the software for his intended requirement.

[9]Maintenance

Maintenance refers to any changes made to the product after it has been delivered to the customer. Maintenance of software products is concerned with correction of errors; enhance features, part to new platforms etc. Software maintenance is an important activity of a large number of organizations. It is quite natural that the customers would prefer using the existing software products to run on newer platforms, in newer environments and with enhanced features. Moreover, maintenance of a software product is essential to rectify the bugs observed while the system is in use. Thus, software maintenance is quite an important activity in the development of the product because it is almost certain that the customer would ask for further rectification of the product after its delivery and thus one has to be prepared to meet the customers’ requirements.

Feasibility Study

Feasibility Study Design

DesignCoding

Coding

ImplementationImplementation

TestingTesting

MaintenanceMaintenance

AnalysisAnalysis

Waterfall Model

Waterfall Model:

Feasibility study: Establishes a high-level view of the intended project and determines its goals.

Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation.

Coding and unit testing: The real code is written here. The code is then the unit testing is carried out.

Integration and system testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

Maintenance: What happens during the rest of the software's life: changes, correction, additions, and moves to a different computing platform and more? This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

IEEE RECOMMENDED PRACTICE FOR SOFTWARE DESIGN DESCRIPTION (IEEE STD 1016- 1998)

Scope

This is a recommended practice for describing software designs. This is designed by IEEE (Institution of Electronics Engineers) and is known as IEEE Standard (IEEE std. 1016-1998) for software design description (SDD). An SDD is a representation of a software system that is used as a medium for communicating software design information.

References

This standard shall be used in conjunction with the following publications.(i) IEEE std 830-1998, IEEE recommended practice for software requirements specifications(ii) IEEE std 610.12-1990, IEEE glossary of software engineering terminology.

Definitions

Few important definitions are given below:(i) Design entity. An element (Component) of a design that is structurally

and functionally distinct from other elements and that is separately named and referenced.

(ii) Design View. A subset of design entity attribute information that is specifically suited to the needs of a software project activity.

(iii) Entity attribute. A named property or characteristics of a design entity. I provides a statement of fact about the entity.

(iv) Software design description (SDD). A representation of a software system created to facilitate analysis, planning, implementation and decision making. A blueprint or model of the software system. The SSD is used as the primary medium for communicating software design information.

Purpose of an SDD

The SDD shows how the software system will be structured to satisfy the requirements identified in the SRS. It is basically the translation of requirements into a description of the software structure, software components, interfaces, and data necessary for the implementation phase. Hence, SDD becomes the blue print for the implementation activity.

Design Description Information Content

(i) Introduction. The SDD is a representation or model of the system to be created. The model should provide the precise design information needed for planning and implementation of the software system. It should represent partitioning of the system into design entities and describe the important properties and relationship among those entities.

(ii) Design entities. A design entity is an element (component) of a design that is structurally and functionally distinct from other elements and that is separately named and referenced.

Design entities result from a decomposition of the software system requirements. The objective is to divide the system into separate components that can be considered, implemented, changed, other components.

The entities may have different nature, but may have common characteristics. Each design entity will have a name, purpose, and function. There are common relationship among entities such as interfaces or shared data. The common characteristics of entities are

described by design entity attributes.

(iii) Design entities. A design entity attribute is a named characteristic or property of a design entity. It provides a statement of fact about the

entity.

Design attributes can be thought of as questions about design entities. The answers to those questions are the values of the attributes. All the questions can be answered, but the content of the answer will depend upon the nature of the entity. The collection of answers provides a complete description of an entity.

All attributes shall be specified for each entity. Attribute descriptions should include references and design considerations such as tradeoffs and assumptions when appropriate. In some cases, attribute descriptions may have the value none. When additional attributes are identified for a specific software project, they should be included in the design description. The attributes and associated information items

are defined in the following subsections (from ‘a’ to ‘j’).

(a) Identification. The name of the entity: Two entities shall not have the same name. The names for the entities may be selected to characterize their nature. This will simplify referencing & tracking in addition to providing identification.

(b) Type. A description of the kind of entity. The type attribute shall describe the nature of entity. It may simply name the kind of entity, such as subprogram, module, procedure, process, or data store. Alternatively, design entities may be grouped into major classes to assist in location an entity dealing with a particular type of information. For a given design description, the chosen entity types shall be applied consistently.

(c) Purpose. A description of why the entity exists. The purpose attribute shall provide the rationale for the creation of the entity. Therefore, it shall designate the specific functional and performance requirements for which the entity is created.

(d) Function. A statement of what the entity does. The function attribute shall state the transformation applied by the entity to inputs to procedure the desired output. In the case of a data entity, this attribute shall state the type of information stored or transmitted by the entity.

(e) Subordinates. The identification of all entities composing this entity. The subordinates attribute shall identify the “composed of relationship” for an entity. This information is used to trace requirements to design entities and to identify parent/child structural relationships through a software system decomposition.

(f) Dependencies. A description of the relationships of this entity with other entities. The dependencies attribute shall identify the uses or requires the presence of relationship for an entity. These relationships are often graphically depicted by structure charts, data flow diagrams etc.

(g) Interface. A description of how other entities interact with this entity. The interface attribute shall describe the methods of interaction and the rules governing those interactions. The methods of interaction include the mechanisms for invoking or interrupting the entity, for communicating through parameters, common data areas or messages, and for direct access to internal data. The rules governing the interaction include the communications protocol, data format, acceptable values, and the meaning of each value. This attribute shall provide a description of the input ranges, the meaning of inputs & outputs, the type and format of each input or output error codes. For information systems, it should include inputs, screen formats, and a complete description of the interactive language.

(h) Resources. A description of the elements used by the entity that are external to the design. The resources attributes shall identify and describe all of the resources external to the design that are needed by this entry to perform its function. The interaction rules and method are using the resource shall be specified by this attribute. This attribute provides information about items such as physical devices (printers), software services (like math libraries, OS services), and processing resources (like CPU cycles, memory allocation, buffers).

(i) Processing. A description of the rules used by the entity to achieve its function. The processing attributes shall describe the algorithm used by the entity to perform a specific task and shall include contingencies. This description is a refinement of the function attribute.

(j) Data. A description of data elements internal to the entity. The data attribute shall describe the method of the representation, initial values, use, semantics, format, and acceptable values of internal data. The description of data may be in the form of a data dictionary that describes the content, structure, and use of all data elements. Data information shall describe everything pertaining to the use of data or internal data structure by this entity. Its shall include data specifications such as formats, number of elements, and initial values. Its shall also includes the structure to be used for representing data such as file structures, arrays, stacks, queues, and memory partition.

Design Description Organisation

Each design writer may have a different view of what are considered the essential aspect of a software design. The organisation of SDD is given in Table 5.1. This is one of the possible ways to organize and format the SDD.

Table 5.1: Organisation of SDD

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions and acronyms

2. References

3. Decomposition description

3.1 Module decomposition

3.1.1 Module 1 description

3.1.2 Module 2 description

3.2 Concurrent Process decomposition

3.2.1 Process 1 description

3.2.2 Process 2 description

3.3 Data decomposition

3.3.1 Data entity 1 description

3.3.2 Data entity 2 description

4. Dependency description

4.1 Intermodule dependencies

4.2 Interprocess dependencies

4.3 Data dependencies

5. Interface description

5.1 Module Interface

5.1.1 Module 1 description

5.1.2 Module 2 description

5.2 Process interface

5.2.1 Process 1 description

5.2.2 Process 2 description

6. Detailed design

6.1 Module detailed design

6.1.1 Module 1 detail

6.1.2 Module 2 detail

6.2 Data detailed design

6.2.1 Data entry 1 detail

6.2.2 Data entry 2 detail

Entity attribute information can be organized in several ways to reveal all of the essential aspects of a design. There may be number of ways to view the design. Hence, each design view represents a separate concern about a software system. Together, these vies provide a comprehensive description of the design in a concise and usable form that simplifies information access and assimilation. A recommended organisation of the SDD

into separate design views to facilitate information access and assimilation is given in Table 5.2.

Table 5.2: Design view

Design View Scope Entity attribute Example representation

Decomposition description

Partition of the system into design entities

Identification, type purpose, function, subordinate

Hierarchical decomposition diagram, natural language

Dependency description

Description of relationships among entities of system resources

Identification, type, purpose, dependencies, resources

Structure chart, data flow diagrams, transaction diagrams

Interface description

List of everything a designer, developer, tester needs to know to use design entities that make up the system

Identification, function, interfaces

Interface files, parameter tables

Detail description

Description of the internal design details of an entity

Identification, processing, data

Flow chart, PDL etc

5.6 OBJECT ORIENTED DESIGN:

"Object Oriented" has clearly become the buzzword of choice in the industry. Almost everyone talks about it. Almost everyone claims to be doing it, and almost everyone says it is better than traditional function oriented design. Object oriented design is the result of focusing attention not on the function performed by the program, but instead on the data that are to be manipulated by the program. Thus, it is orthogonal to functional oriented design.

Object Oriented Design begins with an examination of the real world "things" that are part of the problem to be solved. These things (which we will call objects) are characterized individually in terms of their attributes (transient state information) and behaviour (functional process information). Each object maintains its own state, and offers a set of services to other objects. Shared data areas are eliminated and objects communicate by message passing (e.g. parameters). Objects are independent entities that may readily be changed because all state and representation information is held within

the object itself. Objects may be distributed and may execute either sequentially or in parallel [BOOC03].5.6.1 Basic ConceptsObject Oriented Design is not dependent on any specific implementation language. Problems are modelled using objects. Objects have:

Behaviour (they do things) State (which changes when they do things)

For example, a car is an object. It has state: whether its engine is running; and it has a behaviour: starting the car, which changes its state from "engine not running" to "engine running".

The various terms related to object oriented design are Objects, Classes, Abstraction, Inheritance and Polymorphism.

(i) Objects: The word "Object" is used very frequently and conveys different meaning in different circumstances. Here, meaning is an entity able to save a state (information) and which offers a number of operations (behaviour) to either examine or affect this state. Hence,an object is characterized by number of operations and a state which remembers the effect of these operations [JAC098].All objects have unique identification and are distinguishable. Two bananas may be of same colour, shape and texture but still are different. Each has an identity. There may be four dogs of same colour, breed & size but all are distinguishable. The term identity means that objects are distinguished by their inherent existence and not by descriptive properties [JOSH03]. As discussed above, object is an entity, which has a state (whose representation is hidden from other objects) and a defined set of operations, which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects, which request these services when some computation is required. In principle, objects communicate by passing messages to each other and these messages initiate object operations.

(ii) Messages: Conceptually, objects communicate by message passing. Messages consist of the identity of the target object, the name of the requested operation and any heroperation needed to perform the function. In some distributed systems, object communicationsare implemented directly as text messages which objects exchange. The receiving object parsesthe message, identifies the service and the associated data and carries out the requested service. Messages are often implemented as procedure or function calls (name = procedure name, information= parameter list).

(iii) Abstraction: In object oriented design, complexity is managed using abstraction. Abstraction is the elimination of the irrelevant and the amplification of the essentials.We can teach someone to drive any car using an abstraction. We amplify the essentials: we teach about the ignition and steering wheel, and we eliminate the details, such as

details of the particular engine in this car or the way fuel is pumped to the engine where a spark ignites it, it explodes pushing down a piston and driving a crankshaft [FIEL01].Problems usually have levels of abstraction. We can see a car at a high level of abstrac-tion for driving, but mechanics need to work at a lower level of abstraction. They do care about details and need to know about batteries and engines.However, there are abstractions at the mechanic's level too. The mechanic might test or charge a battery without caring that inside the battery there is a complex chemical reaction going on. A battery designer would care about these details but would not care about, say, the Electronics that goes into the car's stereo.We have seen that we can look at the details such as the battery or stereo design, and they are separated in manageable chunks and by using abstraction and ignoring the details, we can also look at the whole car as a manageable chunk.

(iv) Class: In any system, there shall be number of objects. Some of the objects may have common characteristics and we can group the objects according to these characteristics. This type of grouping in known as a class. Hence, a class is a set of objects that share, a common structure and a common behaviour.

We may have a class "car" with objects like Indica, Santro, Maruti, Indigo. These objects are related due to some common characteristics to constitute a class named "car". A class may be object defined as [JAC098]:

"A class represents a template for several objects and describes how these objects are structured internally. Objects of the same class have the same definition both for their operations and for their information structures.

In object oriented system, each object belongs to a class. An objects, that belongs to a certain class is called an instance of that class. We often use object & instance as synonyms. Hence, an instance is an object created from a class. The class describes the structure (behaviour and information) of the instance, while the current state of the instance is defined by the operations performed on the instance.

We may define a class "car" and each object that represents a car becomes an instance of this class. In this class "car", Indica, Santro, Maruti, Indigo are instances of this class as shown in following figure: 5.20

Fig. 5.20: Indica, Santro, Maruti, Indigo are all Instances of the class "car".

We may have different types of classes depending upon common characteristics. The class is the static description and the object is an instance in runtime of that class.

Imagine a picture made up of squares. Each square is an object. It has a state: its colour and position, and behaviour. We can, amongst other things, change its colour and draw it. Each square is different but has much in common with other squares. So, we abstract out the commonalities: they share the same behaviour and have same sort of attributes. We have ignored same sort of attributes. We have ignored the particular values of the attributes.

Classes are useful because they act as a blueprint for objects. If we want a new square we may use the square class and simply fill in the particular details (i.e., colour and position). Fig. 5.21 shows how we can represent the square class.

Fig.: The square class.

Square

ColourPoint [4]

Set Colour ()Draw ()

Name

Attributes

Operations

Class Square

(v) Attributes: An attribute is a data value held by the objects in a class. The square class has two attributes; a colour and array of points. Each attribute has a value for each object instance. For example, colour may be different in different objects and ''array of points" size may also be different in different squares. The attributes are shown as second part of the class as shown in above figure.

(vi) Operations: An operation is a function or transformation that may be applied to or by objects in a class. In the square class, we have two operations: set colour() and draw(). All objects in a class share the same operations. Each operation has a target object as an implicit argument. The behaviour of the operation depends on the class of its target. An object "knows" its class, and hence the right implementation of the operation [JOSH03]. Operations are shown in the third part of the class as indicated in Fig. 5.21.

(vii) Inheritance: Imagine that, as well as squares, we have triangle class. Fig. 5.22 shows the class for a triangle.

Fig 5.22: The triangle class

Now, comparing Fig, 5.21 and Fig. 5.22, we can see that there is some difference be-tween triangle and squares classes. Triangles have three vertices; squares have four. Also, the way that these shapes are drawn is different. However, there are some similarities. For example, we can set the colour of both and both can be drawn (even if the way they are drawn is different). It would be nice if we could abstract; eliminate the details of each shape and amplify the fact that both can have their colors set and can be drawn, For example, at a high level of abstraction, we might want to think of a picture as made up of shapes and to draw the picture, we draw each shape in turn. We want to eliminate the irrelevant details: we do not care that one shape is a square and the other is a triangle as long as both can draw themselves.To do this, we consider the important parts out of these classes in to a new class called Shape. Fig. 5.23 shows the results.

Fig. 5.23: Abstracting common feature in a new class.

This sort of abstraction is called inheritance. The low level classes (known as subclasses or derived classes) inherit state and behaviour from this high level class (known as a super class or base class).

Hence, a triangle object will have a colour, a setcolour () operation, three point and a draw () operation. We can inherit three sorts of things:(i) State: colour(ii) Operations: setcolour () should be able to set the colour for any shape (iii) The interface of an operation:Shape contains the interface of the draw () operation because draw () interface for trian-gle and square is identical but code for the operation remains in the subclasses because it is different.

(viii) Polymorphism: When we abstract just the interface of an operation and leave the implementation to subclasses it is called a polymorphic operation and process is called So, we can abstract by pulling out important state, behaviour and interface into a new class. We can polymorphism.

also abstract by combining object's inside a new object. In the car example, a car combines a battery, engine and other objects into a new object and provides a simple interface for driving that hides these details. There are different sorts of abstraction and finding the best ways to apply abstraction to a problem is what design is all about.

Another example may be for a base class shape, polymorphism enables the programmer to define different area methods for any number of derived classes, such as circles, rectangles and triangles. No matter what shape an object is, applying the area method to it will return the correct results. Polymorphism is considered to be a requirement of any true object-oriented programming language (OOPL).

(ix) Encapsulation (Information Hiding): Encapsulation is also commonly referred to as "Information Hiding”. It consists of the separation of the external aspects of an object from the internal implementation details of the object. The external aspects of an object are accessible by other objects through methods of object, while the internal implementations of those methods are hidden from the external object sending the message. Thus, it is possible to change the implementation without updating the clients as long as the interface is unchanged. Clients will not be affected by changes in implementation, thus reducing the "ripple effect" in which a correction to one operation forces the corresponding correction in a client operation which in turn causes a change in a client of the client. This makes maintenance is easier and less expensive.Encapsulation deals with permitting or restricting a client class' ability to modify the attributes or invoke the methods of the class or object of concern. If a class allows another to modify its attributes or invoke its methods, the attributes and methods are said to be part of the class' public interface. If a class doesn't allow another to modify its attributes or invoke its methods, those are part of the class' private implementation. Thus, Encapsulation protects a) An object's internal state from being corrupted by its clients and b) Client code from changes in the object's implementation.

A "Queue" provides a good example of this characteristic. A queue is an abstract concept that represents an ordered list of things. The implementation of a queue may by an array or it may be by a linked-list. If the implementation were known, a developer writing a client of the queue class may use this knowledge and directly access the internal storage mechanism. If the implementation changed, the client would then have to be modified also. This type of tight coupling between classes would cause a very brittle system and would increase maintenance costs as parts of the system were modified. Therefore, the levels of encapsulation that a language supports and how those mechanisms are used directly impacts the level of coupling between classes and it can significantly affect the cost of maintenance in an application.

(x) Hierarchy: Hierarchy involves organizing something according to some particular order or rank (e.g., complexity, responsibility, etc.). It is another mechanism for reducing the complexity of software by being able to treat and express sub-types in a generic way. This hierarchy is implemented in software via a mechanism called "Inheritance". Just as a child inherits genes from its parent, a class can inherit attributes and behaviour from its parent. The parent class is commonly referred to as the supper-class and the child class as the subclass. Classes at the same level of the hierarchy should be at the same level of abstraction.

Using a hierarchy to describe differences or variations of a particular concept provides for more descriptive and cohesive abstractions, as well as a better allocation of responsibility. In any one system, there may be multiple abstraction hierarchies (e.g., in a financial application, you may have different types of customers and accounts). Generalization can be used to realize a hierarchy within an object-oriented system, starting at the most general of the abstractions, and then defining more specialized abstractions through sub-classing. Generalization can take place in several stages, which lets you, model complex, and multilevel inheritance hierarchies. General properties are placed in the upper part of the inheritance hierarchy, and special properties lower down. In other words, you can use generalization to model specialization of a more general concept.

This relationship can be easily understood by the Fig. 5.24 below,

Fig. 5.24: Hierarchy.

In summary, with object-oriented design, we use abstraction to break a problem into manageable chunks. We can comprehend the problem as a whole or study parts of the problem at lower level of abstraction.If we work at an appropriate level of abstraction then any problems we find can be solved relatively easily. As an example of not working at the right level of abstraction, imagine that we tried to build a house by going out with some bricks and just building. The chances are we would finish, try to put the bath in and discover that the bathroom is too small. So, we have to knock down and rebuild a wall. Meaning, thereby, lot of work, assuming it could be done. If we had designed the house including, where the fittings were going. We would have noticed the problem and fixing it would have taken about 30 seconds with our eraser and pencil.

Steps to Analyze and Design Object Oriented System:

There are various steps in the analysis and design of an object oriented system and are given in Fig. 5.25.(i) Create use case model: First step is to identify the actors interacting with the system. We should then write the use case and draw the use case diagram.(ii) Draw activity diagram (If required.):

Activity Diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. It is essentially like a flow chart. Fig. 5.26 shows the activity diagram processing an order to deliver some goods.

Fig. 5.25: Steps for analysis and design of object oriented system.

Fig. 5.26: Activity diagram.(iii) Draw the interaction diagram: An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them. Interaction diagrams address the dynamic view of a system. A sequence diagram is an interaction diagram that emphasizes the time ordering of messages; a collaboration diagram is an interaction diagram that emphasizes the structural organisation of the objects that send and receive messages.

Sequence diagrams and collaboration diagrams are isomorphic, meaning that we can take one and transform it into the other.

Steps to draws interaction diagrams are as under;(a) Firstly, we should identify that the objects with respects to every use case. (b) We draw the sequence diagrams for every use case.(c) We draw the collaboration diagrams for every use case.Many object analysis techniques define only one type of object, which can be used any where in the system. Jacobson et.al [JAC098] has chosen to use three object types. The reason for this is to have a structure that is more flexible and adaptable to changes. The object types used is this analysis model are entity objects, interface objects and control objects as given in Fig. 5.27.

Fig. 5.27: Object types

The entity object models information in- the system that should be held for a longer time, and should typically survive a use case. All behaviour naturally coupled in this informa-tion should be placed in the entity object. For a login use case, login-detail may be the entity object. The interface object models behaviour & information that is dependent on the interface to the system. Thus everything concerning any interface to the system is placed in an interface object. For example login screen of the login use case.(iv) Draw the class diagram: The class diagram shows the relationship amongst classes. There are four types of relationships in class diagrams.(a) Association are semantic connection between classes. When an association connects two classes, each class can send messages to the other in a sequence or a collaboration diagram. Associations can be bi-directional or unidirectional.

(b) Dependencies connect two classes. Dependencies are always unidirectional and show that one class, depends on the definitions in another class.

(c) Aggregations are stronger form of association. An aggregation is a relationship between a whole and its parts.

d) Generalizations are used to show an inheritance relationship between two classes.

We may design the class diagram of a complete system. Obviously, this may become very huge, for complex systems. In such a case, one class diagram is made for each use case. This restricts the size of the class diagram and is useful when delegating/assigning the task to a software developer; since he/she would only need to see the related class diagram of the assigned use case; rather than looking at the complete class diagram and then filtering out the concepts related to his/her use-case. We may also draw object diagram, which shows a set of objects and their relationships. They represent static

snapshots of instances of the things found in class diagrams, from the perspective of real cases.

(v) Design of state chart diagrams: A state chart diagram is used to show the state space of a given class, the event that cause a transition from one state to another, and the actions that result from a state change. It shows the changing behaviour of an object in re-sponse to different events. State transition diagrams are made only for the objects that are either very complicated or have a very dynamic behaviour with respect to various events. Normally, we would not need to make state diagrams. A state transition diagram for a "book" in the airline system is given in Fig. 5.28.

Fig. 5.28: Transition chart for airline management system

(vi) Draw component and development diagram: Component diagrams address the static implementation view of a system they are related to class diagrams in that a compo-nent typically maps to one or more classes, interfaces or collaboration. Deployment Diagram Captures relationship between physical components and the hardware.After the completion of above mentioned steps, we will have many documents and com-plete understanding of flow of data, control and relationships of classes. These things are the foundations for implementing an object oriented system.

5.6.3 Case Study of Online Air booking & Management System:

The problem statement for online air booking & management system is given below:

Problem statement:

A software has to" be developed for automating the manual air booking & management system of an aviation company. The system should be web application in nature. It should be designed to provide functionality's as explained below:

An aviation company has decided to engage a software company for the automation of Online Air Booking Management System. The following documents are required to be prepared.1. Problem statement

2. Context Diagram

3. Data flow diagram

4. ER diagram

5. Use case diagram

6. Use case

7. SRS as per IEEE stander 830-1993

These seven documents may provide holistic view of the system to be developed. The SRS will act as contract document between developers (Software Company) and client (Aviation Company).1. The initial problem statement:

The problem statement is the first document which is normally prepared by the client. It only the superficial view of the system as per clients’ perspective and exception. It is the input to the requirement engineering process where final product is SRS.

The problem statement of Online Air Booking Management System of an aviation company is given below:

The purpose of the airline reservation system is to help the travel agent must be able to find all of the flights meeting a passenger’s needs and make reservation based on the passenger’s preferences.

2. Goal of the system:

2.1 The purpose of the system is to help the travel agent sell tickets

2.1.1 The system must help the travel agent find all of the flights meeting a passenger’s needs.

2.1.1.1 The System must be able to find all flights with a given origin and destination.

2.1.1.2 The system must display the arrival and departure time, the price and the flight number for each flight it finds.

2.1.1.3 The passenger will choose a flight based on the displayed information.

2.1.2 The system must let the travel agent makes reservations

2.1.3 The system must allow the travel agent to cancel reservations.

2.1.4 The system must be able to friend all reservation on a given flight after a given date…derived from 2.2.2

2.1.5 The customers who book their flight online they will make payment by credit card, Internet Banking, Debit card.

2.2 The system must provide a means for the airline administrator to manage flights.

2.2.1 The system must allow the airline administrator to schedule new flights.

2.2.2 The system must allow the airline administrator to drop flight from the schedule.

2.2.3 The system must allow the airline administrator to change the fare for a flight.

2.2.4 The system must allow the airline administrator to show different reports depending on different criteria.

3. Constraints:

3.1 Implementation constraints:3.1.1 The airline reservation system must be implemented in Windows – Apache Tomcat – Oracle – JSP.

3.2 Performance constraints:3.2.1 The responses of the airline reservation system must be fast

enough not to irritate the customers of the travel agents. 3.2.1.1 Response time less than a second are good.

3.2.1.2 The average response time for travel agent request should be less than ten second.3.2.1.3 Situation in which a travel agent request takes more than a minute should be rare.

3.2.1.3.1 Rare means average less than once per week travel agent.

3.2.1.4 The system must be able to handle 10,000 reservations per day.

3.2.1.5 The system must be able to support 300 travel agents.

3.3 Resource Constraints:3.3.1 The system must be developed by three people in ten weeks.

Context Flow Diagram

Entity Relationship Diagram

Use case Diagram

1. USE CASE: SIGN IN OR LOGIN

1.1 Brief Description: This use case describes how users login/sign in into the Online Airlines Booking System.

1.2 Actors: Customer, Administrator1.3 Flow of events: 1.3.1 Basic Flow:

1. The system requests that the actors enter his / her username, password.2. The actor enters / her username, password.3. The system validates the entered username, password & logs the actor into the

system with his or her own page. 1.3.2 Alternative Flow: 2. a. Invalid username or password:

If in the basic flow the actor enters an invalid username, password, system displays an error message. The actor can choose to either return to the beginning of the basic flow or cancel the login, at which point the use case ends. Actors will be requested to system to get his/her password and also register them with new username & password.

1.4 Special requirements: None1.5 Pre-conditions: All actors have a username and password. In case of new customer,

he/she will be requested to register them with new username, password & personal details.

1.6 Post Conditions: If the use case was successful, the actor is logged the system with their own page. If the actor is an administrator then she / he will have access to only screen corresponding to the Add flight, modify flight, cancel flight, view report, customer account maintain, add airport module of the system. If the actor is a customer then he / she will have access to only the screen corresponding to the search flight, book flight, and payment modules of the system.Administrator and customer will be differentiated by index id which is a field of the table. In case of administrator index id will be 2 and in case of customer index id will be 1.

2. Use Case: Registration for User

2.1 Brief Description: The use case documents the procedure for registration of the user for further requirement.

2.2 Actor: Administrator, customer.2.3 Pre-condition: User has to book a flight before registration.2.4 Post-condition: User successfully registered.2.5 Flow of events:

2.5.1 Basic flow: This use case starts after the user books a flight. System displays a form with required fields. User fills up the form with necessary information.

2.5.2 Alternative Flow: User cancels his/her action.

2.6 Special Requirements: None2.7 Related Use Case: None

3. USE CASE: SEARCH A FLIGHT

3.1 Brief Description: This use case allows the actor to search flight on the basis of origin, destination, arrival time, departure time and preferable class.

3.2 Actors: Customer 3.3 Flow of events:

3.3.1 Basic flow: This use case starts when the customer wishes to book a flight or to enquiry flights. Customer provides a destination and dates to the system. The system enquires the airline database about the available flights & presents them to the customer.

1. Customer select search available flight first.2. Selects origination city3. Selects destination city4. Selects departure date5. Selects return date6. Selects one way or two way7. Selects connections or nonstop8. Submit criteria9. System validates the customer data. Data is valid if customer enters a start and end cities that the system provides service to and valid dates such that the starts date is not prior to the end date & vice versa. Invalid data are empty cities & dates that do not exist.10. System shows list of flights that met customer’s criteria and each item in the list has an associated price and a “Book this Flight” option.

3.3.2 Alternative Flow:1. Flight not found: If there is no such flight matching the search criteria then a message will be displayed.2.(10.a) After displaying the list of flight a customer can select cancel option then system display the main option screen.3. (8.a) If customer does not complete the main option screen with the input data and a note starting that certain required data is missing.

3.4 Special Requirement: None 3.5 Pre condition: Actor has successfully navigated to the main options screen. 3.6 Post condition: A list of flight matching the search criteria is presented. 3.7 Extension points: None

4. USE CASE: BOOKING A FLIGHT

4.1 Brief description: This use case allows the customer to book a flight.4.2 Actor: Customer4.3 Flow of events: 4.3.1 Basic flow:

1. Customer selects the “Book this flight” option from the list of the flights presented.2. The system displays a screen with three types of options viz. by cash, by credit card, by internet banking.

2.1 If the user choose the by cash option then the system displays a text box for entering the cash amount.2.2 If the user choose the by credit card option then the system displays a screen with input fields for entering a credit card number, cardholder name, and credit card expiration date. 2.3 If the user choose the by internet banking option then the system displays a screen with input fields for entering account number and bank name.

3. After entering required data customer clicks the submit button.4. System displays the details of the reservation.5. Customer then selects the "Complete Reservation" option.6. The system displays the main options screen. The message "Reservation Successfully Made" is also displayed.

4.3.2 Alternative Flow:1. (3.a) If the customer does not complete all the necessary fields. Then system redisplays the input fields from step 2 with the input data and a note stating that certain required data is missing or invalid.2. (3.b) If the customer selects cancel option then system displays the screen with three options.3. (5.a) If the customer selects cancel option before selecting the “Complete Reservation” option then system displays the screen with three options.

4.4 Special requirement: None4.5 Pre-condition: Actor has successfully generated a list of flights as documented in the

"Search for Flights" use case.4.6 Post-condition: A reservation has been made.4.7 Extension Points: None.

5. USE CASE: PAYMENT FOR TICKET

5.1 Brief Description: This use case allows a customer to purchase the ticket for a reserved flight.5.2 Actor: Customer5.3 Flow of Events: 5.3.1 Basic Flow:

1. This use case starts when the customer selects the "Purchase Ticket" link from the list of options.2. The system displays a screen with an input field for a reservation number.3. Customer enters a reservation number and clicks the "Submit" button.4. The system displays the details of the reservation.5. Customer selects the "Purchase Ticket" option.6. The system displays a screen with three types of options viz. by cash, by credit card, by internet banking.

6.1 If the user choose the by cash option then the system displays a text box for entering the cash amount.6.2 If the user choose the by credit card option then the system displays a screen with input fields for entering a credit card number, cardholder name, and credit card expiration date. 6.3 If the user choose the by internet banking option then the system displays a screen with input fields for entering account number and bank name.

7. After entering required data customer clicks the submit button.8. System displays the main options screen. The message "Ticket Successfully Purchased" is also displayed

5.3.2 Alternative Flow:1. (3.a) If customer selects the "Cancel" option Then system displays the main options screen.2. (5.a) If customer selects the "Cancel" option Then system displays the main options screen.3. (7.a) If customer selects the "Cancel" option Then system displays the main options screen4. (7.b) If the customer does not complete all the necessary fields. Then system redisplays the input fields from step 6 with the input data and a note stating that certain required data is missing or invalid.

5.4 Special Requirements: None.5.5 Pre-Conditions: Actor has successfully made a reservation as documented in the

"Make a Reservation" use case.5.6 Post-conditions: A ticket has been purchased.5.7 Extension Points: None.

6. Use Case: User Account Information Change

6.1 Brief Description: The use case documents the procedure for changing the user account information if users want.

6.2 Actor: Administrator, customer.6.3 Pre-condition: User must be logged into the system.6.4 Post-condition: User account information changed.6.5 Flow of events:

6.5.1 Basic flow: This use case starts when the user wishes to change his/her account information. 1. User selects the “My Account” link.

2. The system will display the screen with basic profile, change password, change Personal details, change contact details, journey details options.

3. Once the user provides the requested information, one of the sub-flows is executed.

If the user selects the basic profile link then system show his/her profile details.

If the user selects the change password link then system will show the screen that will allow the user to change his/her password.

If the user selects the change personal details link then the system will show the screen that will allow the user to change his/her personal details.

If the user selects the change contact details link then the system will show the screen that will allow the user to change his/her contact details.

If the user selects the journey details link then the system will display the details of his/her journey.

6.5.2 Alternative Flow: user doesn’t change his/her account information.6.6 Special Requirements: None6.7 Related Use Case: None

7. USE CASE: MAINTAIN FLIGHT

7.1 Brief description: This use case allows the administrator to maintain flight information. This includes adding, modifying, canceling flight information from the system.

7.2 Actors: Administrator 7.3 Flow of events:

7.3.1 Basic Flow: This use case starts when the administrator wishes to add, modify and cancel flight information from the system.

1. Administrator’s page allows selecting an option either Add flight, Modify flight, or canceling flight.

2. Once the administrator select one of the sub-flows is executed If the administrator selects “Add flight”, the Add flight sub flow

is executed. If the administrator selects “Modify flight”, the Modify flight sub

flow is executed. If the administrator selects “Cancel flight”, the Cancel flight sub

flow is executed7.3.1.1 Add Flight:

1. The system requests that the administrator enter the flight information. This includes:a) Flight No. - Should be unique for every flight.b) Originc) Destinationd) Aircraft Typee) Weightf) Capacity of economic class, Business class & General class.g) Fare of economic class, Business class & General class.h) Departure Timei) Arrival Timej) No. of stop overk) Available day

7.3.1.2 Modify Flight:1. System requests that the Administrator to select the Flight No.2. Administrator selects the Flight No. The system retrieves and displays

the flight information.3. Administrator makes the desired changes to the flight information. This

includes any of the information specified in the Add Flight sub flow.4. Once the Administrator update the information, the system updates the

flight details with the updated information.7.3.1.3 Cancel Flight:

1. System requests that the administrator to select the Flight No.2. Administrator selects the Flight no. The system prompts the

administrator to confirm the deletion of the flight. 3. The administrator confirms deletion. 4. The system deletes the flight information.

7.3.2 Alternative Flow:

7.3.2.1 Flight not found: If in the modify flight or cancel flight sub-flow, a flight with the specified Flight No. does not exist, then the system displays an error message. The Administrator can then enter a different flight no. or cancel the operation, at which point the use case ends.

7.3.2.2 Modify Cancelled: If in the Modify Flight sub-flow, the Administrator decides not to modify the flight information. The update is cancelled and the basic flow is restarted at the beginning.

7.3.2.3 Delete Cancelled: If in the cancel Flight sub-flow, the administrator decides not to delete the flight information, the delete is cancelled and the basic flow is re-started at the beginning.

7.4 Special requirements: None.7.5 Pre conditions: The administrator must be logged onto the system before this use

case begins.7.6 Post conditions: If the use case was successful, the flight information is added,

modified or deleted from the system. Otherwise, the system state is unchanged.

a. Extension points: None.

8. Use Case: Login Maintain

8.1 Brief Description: The use case documents the procedure for maintaining Login Details.

8.2 Actor: Administrator.8.3 Pre-condition: Administrator must be logged into the system.8.4 Post-condition: If use case is successful, the login details should be updated,

otherwise the system state is unchanged. 8.5 Flow of events:

8.5.1 Basic flow: The use case starts when the administrator wishes to add, delete, and modify some details of login.

The corresponding changes will be done. The use case end.

8.5.2 Alternative Flow: None8.6 Special Requirements: None8.7 Related Use Case: None

9. USE CASE: GENERATE REPORTS

9.1 Brief Description: The use case documents the procedure for generating the reports as desired by the Administrator.9.2 Actor: Administrator.9.3 Pre-condition: Administrator must be logged into the system. 9.4 Post-condition: If use case is successful, the various reports, regarding the details of the flight, sales, user, etc. are generated. 9.5 Flow of events:9.5.1 Basic flow: This use case starts when an Administrator wants to generate reports of the Airline Booking System.

The system display the various report generating criteria to the user, which can be about flight, passengers, users, booking rate, route details and sales report etc.

The Administrator selects the criteria and enters the various parameters based on the criteria selected.

The system generates the report and sends that to printer.

The use case ends.

9.5.2 Alternative Flow: 9.5.2.1 Printer out of paper or low on ink: If the printer goes out of paper or low on ink, then the printing operation is aborted and the necessary action needs to be taken, which can be feeding paper to the printer or replacing the ink cartridge. The use case ends.

9.6 Special Requirements: None9.7 Related Use Case: None

10. Use Case: User Account Maintain

10.1 Brief Description: The use case documents the procedure for maintaining User Account Details.

10.2 Actor: Administrator.10.3 Pre-condition: Administrator must be logged into the system.10.4 Post-condition: If use case is successful, the user details should be updated,

otherwise the system state is unchanged.10.5 Flow of events:

10.5.1 Basic flow: The use case starts when the administrator wishes to add, delete, and modify some details of user.

The corresponding change will be done. The use case end.

10.5.2 Alternative Flow: None10.6 Special Requirements: None10.7 Related Use Case: None

11. Use Case: Login Maintain

11.1 Brief Description: The use case documents the procedure for maintaining Login Details.

11.2 Actor: Administrator.11.3 Pre-condition: Administrator must be logged into the system.11.4 Post-condition: If use case is successful, the login details should be updated,

otherwise the system state is unchanged. 11.5 Flow of events:

11.5.1 Basic flow: The use case starts when the administrator wishes to add, delete, and modify some details of login.

The corresponding changes will be done. The use case end.

11.5.2 Alternative Flow: None11.6 Special Requirements: None11.7 Related Use Case: None

12. Use case: Add Airport.

12.1 Brief Description: The use case allows the user to add airport.12.2 Actor: Administrator.12.3 Pre-condition: Administrator must be logged into the system.12.4 Post-condition: If use case is successful, the airport details should be added;

otherwise the system state is unchanged.12.5 Flow of events:

12.5.1 Basic flow: The use case starts when the administrator wishes to add airport. User selects the Add airport link. System will display a form with required field. User fill up the form with necessary information

12.5.2 Alternative Flow: User cancel the operation.12.6 Special Requirements: None12.7 Related Use Case: None

13. Use Case: Promotional Offer

13.1 Brief Description: The use case documents the procedure for issues or retrieves the promotional offer.

13.2 Actor: Administrator.13.3 Pre-condition: Administrator must be logged into the system.13.4 Post-condition:13.5 Flow of events:

13.5.1 Basic flow:13.5.2 Alternative Flow:

13.6 Special Requirements: None13.7 Related Use Case: None

14. Use Case: Sign out or Logout

14.1 Brief Description: This use case describes how a user logout/sign-out from the Online Airlines Booking System.

14.2 Actor: Administrator, customer.14.3 Pre-condition: User must be log into the system.14.4 Post-condition: User successfully logout from the system.14.5 Flow of events:

14.5.1 Basic flow: This use case starts when the user wishes to quit the system. User click on Logout link. System will display a log in screen for further use.

14.5.2 Alternative Flow: The user doesn’t logout. 14.6 Special Requirements: None14.7 Related Use Case: None

Sequence Diagram

Sequence Diagram-Login

Sequence Diagram-Registration

Sequence Diagram-Search Flight

Sequence Diagram-Reservation

Sequence Diagram-Payment

Sequence Diagram-User Account Maintain

Sequence Diagram-Flight maintain

Sequence Diagram-Login Maintain

Sequence Diagram-Report Generation

Sequence Diagram-User Account Maintain

Sequence Diagram-Log out

Class Diagram

Entity Classes Attributes & Its Method::

In this design, we have shown class diagram of entity classes only. This entity class generally becomes tables in the database. The other diagram of the design document can be drawn using rational rose facilities (or other tools) and may or may not be required in each case study. All these diagram are the foundation of the implementation phase.

Database Schema

Query of Database

CREATE TABLE user_login_details( index_no number (2),login_id varchar2 (10),user_password varchar2 (10),password_question varchar2 (50),password_answer varchar2 (20),PRIMARY KEY (login_id),UNIQUE (user_password) );INSERT INTO user_login_details VALUES(1,'pkjana123','pkjana123','what is your pets name?','tomy');INSERT INTO user_login_details VALUES(1,'mpal123','mpal123','what is your favourite drinks?','fruity');INSERT INTO user_login_details VALUES(2,'sital01','sital01','what was your first job?','teachership');INSERT INTO user_login_details VALUES(3,'subho01','subho01','what was your first love?','rose');INSERT INTO user_login_details VALUES(4,'surajit','surajit','what is your goal?','honest');

CREATE TABLE user_personal_details(login_id varchar2 (10),user_first_name varchar2 (50),user_last_name varchar2 (50),fathers_name varchar2 (50),guardian_name varchar2 (50),date_of_birth date,sex varchar2 (10),marital_status varchar2 (15),occupation varchar2 (20),no_of_family_members number (2),FOREIGN KEY (login_id) REFERENCES user_login_details (login_id) ON DELETE CASCADE);INSERT INTO user_personal_details VALUES('pkjana123', 'Pabitra Kumar', 'Jana', 'Parameswar Jana', 'Sachinandan maiti', TO_DATE('18-JUL-1981', 'DD-MM-YYYY'), 'Male', 'Single', 'student', 5);INSERT INTO user_personal_details VALUES('mpal123', 'Mousumi', 'Pal', 'Sitansu sekhar Pal', '', TO_DATE('12-DEC-1983', 'DD-MM-YYYY'), 'Female', 'Single', 'student', 5);

INSERT INTO user_personal_details VALUES('sital01', 'Sital Chandra', 'Mondal', 'Sarat Chandra Mondal', '', TO_DATE('12-DEC-1976', 'DD-MM-YYYY'), 'Male', 'Married', 'Engineer', 4);INSERT INTO user_personal_details VALUES('subho01', 'Subhasis', 'Pan', 'Srikanta Pan', '', TO_DATE('12-DEC-1980', 'DD-MM-YYYY'), 'Male', 'Single', 'Software Professonal', 6);INSERT INTO user_personal_details VALUES('surajit', 'Subhojit', 'Sarkar', 'Sujit Sarkar', '', TO_DATE('12-DEC-1975', 'DD-MM-YYYY'), 'Male', 'Single', 'Business', 8);

CREATE TABLE user_contact_details(login_id varchar2 (10),land_phone_no varchar2 (20),cell_phone_no varchar2 (20),email_id varchar2 (50),address_of_communication varchar2 (200),state1 varchar2 (40),pin_no1 varchar2 (10),address_of_permanent_residence varchar2 (200),state2 varchar2 (40),pin_no2 varchar2 (10),FOREIGN KEY (login_id) REFERENCES user_login_details (login_id) ON DELETE CASCADE);INSERT INTO user_contact_details VALUES('pkjana123', '03322223333', '+919830643431', 'pkjana81@yahoo.com', '213A,Dumdum road, kolkata', 'west Bengal', '700074', 'Srikhoda, Patashpur, Purba Medinipur', 'west Bengal', '721439');INSERT INTO user_contact_details VALUES('mpal123', '0332489132', '+91983245461', 'mousumi_pal123@yahoo.com', '16A, jawpur road, kolkata', 'west Bengal','700074', '16A, jawpur road, kolkata', 'west Bengal', '700074');INSERT INTO user_contact_details VALUES('sital01', '0322222834', '+91983245661', 'sital_mondal@gmail.com', '420B, B.T. Road, kolkata', 'west Bengal', '700072', '420B, B.T. Road, kolkata', 'west Bengal', '700072');INSERT INTO user_contact_details VALUES('subho01', '033293847', '+9193365712', 'sobhasispan@accenture.biz', '23, Dimond Hurber rd, kolkata', 'west Bengal', '700070', '23, Dimond Hurber rd, kolkata', 'west Bengal', '700070');INSERT INTO user_contact_details VALUES('surajit', '033293847', '+9193365712', 'surajit@ibm.biz', '203, Dimond Hurber rd, kolkata', 'west Bengal', '700070', '203, Dimond Hurber rd, kolkata', 'west Bengal', '700070');

CREATE TABLE aircraft_details(aircraft_type varchar2 (20),capacity number (5),no_of_aircraft number (5),company_name varchar2 (20),PRIMARY KEY (aircraft_type));INSERT INTO aircraft_details VALUES('AIRBUS345', 500, 10, 'AIRBUS');INSERT INTO aircraft_details VALUES('AIRBUS333', 500, 2, 'AIRBUS');INSERT INTO aircraft_details VALUES('BOEING777', 500, 4, 'BOEING');INSERT INTO aircraft_details VALUES('BOEING787', 500, 7, 'BOEING');

CREATE TABLE aircraft_internal_details(model_no varchar2 (20),purchase_date date,manufacture_date date,expire_date date,weight number (10,2),flying_time number (9),aircraft_type varchar2 (20),PRIMARY KEY (model_no),FOREIGN KEY (aircraft_type) REFERENCES aircraft_details);

CREATE TABLE flight_details(flight_id varchar2 (10),from_city_id varchar2 (30),to_city_id varchar2 (30),departure_time varchar2 (10),arrival_time varchar2 (10),departure_date date,arrival_date date,aircraft_type varchar2 (20),no_of_stop_over number (2),via_city_id varchar2 (30),PRIMARY KEY (flight_id),FOREIGN KEY (aircraft_type) REFERENCES aircraft_details);INSERT INTO flight_details VALUES('F001', 'DEL', 'CCU', '10:50 AM', '11:00 AM', TO_DATE('20-JUL-2008', 'DD-MM-YYYY'), TO_DATE('20-JUL-2008', 'DD-MM-YYYY'), 'AIRBUS345', 0, '');INSERT INTO flight_details VALUES('F002', 'CCU', 'DEL', '10:50 AM', '11:00 AM', TO_DATE('21-JUL-2008', 'DD-MM-YYYY'), TO_DATE('21-JUL-2008', 'DD-MM-YYYY'), 'AIRBUS345', 0, '');

INSERT INTO flight_details VALUES('F003', 'DEL', 'CCU', '10:50 AM', '11:00 AM', TO_DATE('22-JUL-2008', 'DD-MM-YYYY'), TO_DATE('22-JUL-2008', 'DD-MM-YYYY'), 'AIRBUS345', 1, 'LKO');INSERT INTO flight_details VALUES('F004', 'CCU', 'DEL', '10:50 AM', '11:00 AM', TO_DATE('23-JUL-2008', 'DD-MM-YYYY'), TO_DATE('23-JUL-2008', 'DD-MM-YYYY'), 'AIRBUS345', 1, 'LKO');INSERT INTO flight_details VALUES('F005', 'MUM', 'CCU', '10:50 AM', '11:00 AM', TO_DATE('24-JUL-2008', 'DD-MM-YYYY'), TO_DATE('24-JUL-2008', 'DD-MM-YYYY'), 'AIRBUS345', 0, '');INSERT INTO flight_details VALUES('F006', 'CCU', 'MUM', '10:50 AM', '11:00 AM', TO_DATE('25-JUL-2008', 'DD-MM-YYYY'), TO_DATE('25-JUL-2008', 'DD-MM-YYYY'), 'AIRBUS345', 0, '');INSERT INTO flight_details VALUES('F007', 'BLR', 'CCU', '11:50 AM', '12:00 AM', TO_DATE('20-JUL-2008', 'DD-MM-YYYY'), TO_DATE('20-JUL-2008', 'DD-MM-YYYY'), 'AIRBUS345', 1, 'HYD');

CREATE TABLE business_class(flight_id varchar2 (10),seat_lw number (3),seat_lm number (3),seat_ls number (3),seat_rw number (3),seat_rm number (3),seat_rs number (3),seat_total number (3),fare_rate number (8,3),FOREIGN KEY (flight_id) REFERENCES flight_details ON DELETE CASCADE);INSERT INTO business_class VALUES('F001', 18, 16, 16, 18, 16, 16, 100, 3000);INSERT INTO business_class VALUES('F002', 18, 16, 16, 18, 16, 16, 100, 3000);

CREATE TABLE economy_class(flight_id varchar2 (10),seat_lw number (3),seat_lm number (3),seat_ls number (3),seat_rw number (3),seat_rm number (3),seat_rs number (3),seat_total number (3),fare_rate number (8, 3),FOREIGN KEY (flight_id) REFERENCES flight_details ON DELETE CASCADE);INSERT INTO economy_class VALUES('F001', 60, 60, 80, 80, 60, 60, 400, 2000.50);

INSERT INTO economy_class VALUES('F002', 60, 60, 80, 80, 60, 60, 400, 2000.50);

CREATE TABLE general_class(flight_id varchar2 (10),seat_lw number (3),seat_lm number (3),seat_ls number (3),seat_rw number (3),seat_rm number (3),seat_rs number (3),seat_total number (3),fare_rate number (8, 3),FOREIGN KEY (flight_id) REFERENCES flight_details ON DELETE CASCADE);INSERT INTO general_class VALUES('F001', 40, 30, 30, 40, 30, 30, 200, 2500);INSERT INTO general_class VALUES('F002', 40, 30, 30, 40, 30, 30, 200, 2500);

CREATE TABLE reservation_details(reservation_id varchar2 (20),reservation_date_time date,no_of_seat number (3),class_of_seat varchar2 (20),payment_type varchar2 (30),mode_of_trip varchar2 (20),amount number (9, 3),flight_id varchar2 (10),user_id varchar2 (10),PRIMARY KEY (reservation_id),FOREIGN KEY (flight_id) REFERENCES flight_details,FOREIGN KEY (user_id) REFERENCES user_login_details (login_id) ON DELETE CASCADE );

CREATE TABLE passenger_details(passenger_id varchar2 (20),reservation_id varchar2 (20),ticket_no varchar2 (20),seat_no varchar2 (20),passenger_name varchar2 (100),dob date,sex varchar2 (10),address_of_communication varchar2 (200),state varchar2 (40),pin_no varchar2 (10),phone_no varchar2 (20),email_id varchar2 (20),meal_peference varchar2 (30),special_assistance varchar2 (30),PRIMARY KEY (passenger_id),FOREIGN KEY (reservation_id) REFERENCES reservation_details (reservation_id) ON DELETE CASCADE);

CREATE TABLE payment_card_details(reservation_id varchar2 (20),transaction_id varchar2 (25),card_mode varchar2 (50),card_no varchar2 (22),card_type varchar2 (25),card_expire_date date, bank_name varchar2 (50),FOREIGN KEY (reservation_id) REFERENCES reservation_details (reservation_id) ON DELETE CASCADE);

CREATE TABLE payment_bank_details(reservation_id varchar2 (20),transaction_id varchar2 (25),bank_name varchar2 (50),account_no varchar2 (25),account_type varchar2 (15),bank_IFSC_code varchar2 (15),FOREIGN KEY(reservation_id) REFERENCES reservation_details (reservation_id) ON DELETE CASCADE);

CREATE TABLE airport_details(airport_index number (2) NOT NULL,airport_id varchar2 (5),airport_name varchar2 (100),airport_place varchar2 (50),airport_country varchar2 (50),PRIMARY KEY (airport_id));

CREATE TABLE feedback_details(login_id varchar2(10),fback_details varchar2(200),feedback_date date,FOREIGN KEY(login_id) REFERENCES user_login_details(login_id) ON DELETE CASCADE);

Software Requirement Specification

1. Introduction:

The current trend in Airlines is online reservation. In concurrent to our traditional

airlines booking system online is gradually gaining entry. Advancement of network and

information technology have further catalyzed the process.

In online the Airlines database resides at a central server. Individuals of various

statuses (such as customers, Administrator, etc) can access the server database from any

location, for which all they need is a network connection and a web browser. They can

log in, using their ID and password which allows them to transact with the server as per

authorization granted against the corresponding user name & password. Customers can

now access booking facility from any location. Administrator can maintain flight details,

customer account details from any location.

The aforesaid managements are used to be more time consuming, complex and error

prone when handled manually. This computerized system will resolve the problems

effectively to some extent.

1.1 Purpose:

This specification document describes the capabilities that will be provided by the

software application ‘Airlines management system’. It also states the various required

constrains by which the system will abide. The intended audiences for this document are

the development team, testing team and end users of the product.

1.2 Scope:

The Airlines management System is collection of interactive programme which

will be used for following tasks-

Keeping track of flight’s information, flight’s time schedules, flight’s

fare chart etc.

Keeping track of customer’s personal as well as contact details and log in

information.

Printable reports will be generated.

Allow the user to search a flight, book a flight and make payment for the

ticket via online.

Allow the Administrator to add, update, & cancel a flight and add a

airport.

1.3 Definition, Acronyms, and Abbreviations:

Following abbreviation have been used throughout this document:

JSP: Java Server Page

DBMS: Database Management System

J2EE: Java2 Enterprise Edition

1.4 References:

i) Airlines website: For information about flight booking, flight schedule

ii) IEEE Recommended practice for Software Requirement Specifications-IEEE

Std 830-1993.

1.5 Overview

The rest of this SRS document describes the various system requirements,

interfaces, features, and functionality in details.

2. Overall Description

Airlines management system is an online system. This system can be used by the

user, Administrator and Booking clerk. The users are offered to search a flight, book a

flight and make a payment for the ticket via online. A user who will book a flight for first

time should be allowed to be registered. The old user can log in with their user id and

password for promotional offer, if any.

The Administrator is offered to manage the flight details, flight schedule, user

account & view report. Administrator can also add a airport. The software will also

generate different reports.

2.1 Product Perspective:

The application will be a window-based, self-contained and independent software

product.

2.1.1 System Interfaces

None

2.1.2 User Interfaces

The following screens will be provided:

Login Screen:

This screen will allow the user to enter the username and password (Administrator,

Register user, Booking officer, Travel Agent). It will also allow the user to access

different screens based upon the user’s role.

General user registration Screen:

This screen will allow the new general user, who book at least one flight, to register into

the system.

Flight search & Book screen:

This screen will be accessible to the general and registered user. It will allow the user to

enter the origin, destination, departure date, return date, class of service etc. On the basis

of these criteria software will search the flight from the database and allow the user to

book the flight.

Payment Screen:

This screen will be generating dynamically. The ordinary user can booked their flight

through online via credit card, debit card, and internet banking. The booking officer has

additional option i.e. by cash.

Reservation date change screen:

This screen will be accessible to the General user, booking officer, Travel agent. They

cancel the ticket and as well as book the ticket.

Front End Client

Application (with data

entry/update/delete/view and

reporting facility)

BackendDatabase

My Account Screen:

This screen will help to user to change their personal details, contact details and login

details. This screen also helps to show their basic profile and journey details.

Ticket cancel screen:

This screen will be accessible only to the registered user. It will allow the user to enter

their reservation Id and ticket Number to cancel their ticket.

Various Offer search screen:

This screen will be accessible by General user, booking officer, Travel agent. It will

allow the user to search various type offers.

Flight maintain screen:

This screen will be accessible only to the Administrator. It will allow the user to add,

modify, and cancel the particular flight.

Report generation screen:

This screen will be accessible only to the Administrator. It will allow the user to generate

the various types of reports. The following report will be generated:

Flight Details Report: Printable report will be generated to show the list of flight

details daily, weekly, monthly, few months, yearly.

Ticket Sales Report: Printable report will be generated to show the list of ticket

sales details daily, weekly, monthly, few months, and yearly.

Passenger Report: Printable report will be generated to show the list of

passenger according to different parameters.

User’s Report: This report will show about user account and personal details

and his/her journey details.

Frequent Traveler Report: This report will show about journey details of

frequent traveler.

Traveler Feedback Report: This report will show the feedback of different

customer.

Booking Rate Report: This report will show the tariff of a particular flight or

particular route.

Route Details Report: This report will show the route details of different flight.

Cancel Flight Report: This report will show the list of details of canceled flight.

Ticket Cancel Report: This report will show the list of details of canceled ticket.

Maintain user screen:

This screen will allow the administrator to create, modify, and delete a user account like a

new administrator, booking officer, travel agent, general user.

Promotional offer maintain screen:

This screen will be accessible only to the Administrator. It will allow the user to maintain

the various offers.

Aircraft maintain screen:

This screen will allow the administrator to add and delete the aircraft.

Add airport screen:

This screen will allow the administrator to add and delete the airport.

2.1.3 Hardware Interface

Pentium IV, 1.6 GHz

512 MB RAM

40 GB HDD

15” Monitor

104 keys Keyboard

1.44 Floppy Disk Drive

52X CD ROM Drive

Inkjet printer

2.1.4 Software Interface

Operating System : Windows 2000,XP

Environment : JDK 1.5

Web Server : Apache Tomcat 5.5

Editor/IDE Used : Notepad, Dream Weaver MX 2004

Technology Used : HTML, Java, JSP

RDBMS : Oracle 9i

Documentation : MS Office 2003

Others : Natty ware’s Pixie

2.1.5 Communication Interfaces

None

2.1.6 Memory Constrains

At least 64MB RAM and 2 GB space on hard disk will be required for running the

application.

2.1.7 Operations

This product release will not cover any automated housekeeping aspects of the

database. The DBA at the client site will be responsible for manually deleting

old/non-required data. Database backup and recovery will also have to be handled by

the DBA.

2.1.8 Site Adaptation Requirements

The terminal at client site will have to support the hardware and software interfaces specified in above section.

2.2 Product Functions

The system will allow access to registered user, administrator, booking officer.

Depending upon the user’s role, he/she will be able to access specific module of the

system.

A summary of the major functions that the software will perform:

A Login facility for enabling only authorized access to the system.

Normal user will be able to search flights depending upon date, destination, origin

etc. and register them to the system.

Registered user will be able to search, book, cancel a flight and also make

payment.

Travel agent will be able to search, book, cancel a flight and also make payment

and have a special agreement with the company.

Booking officer will be able to search, book, cancel a flight and also make

payment. He also view the daily sales report and issue original ticket against

general user ticket.

Administrator will be able to add/modify/delete a flight.

Administrator will also be able to add airport, show report, issue promotional

offer.

Administrator will also be able to maintain login and user account.

2.3 User Characteristics

Educational level: At least graduate should be comfortable with English

language.

Experience: Should be well versed/informed about the airlines system.

Entry of Flight details or modification can be done only by

Administrator.

Technical expertise: Should be comfortable using general-purpose

applications on a computer.

2.4 Constraints

i) It is dependent on the internet. So downloading the page from the server to client

takes more time if the speed of the internet is slow and if many people request at a time it

would be also slow due to server capacity problem.

ii) Bank transaction may hamper due to hacker and internet speed.

iii) Users at Airlines will have to implement a security policy to safeguard the

personal details and bank information from being modified by unauthorized users.

2.5 Assumptions and Dependencies

The system could not book more than eight people at a time

We could book two flights at a time in this system.

This software is suitable for Internet Explorer.

2.6 Apportioning of requirements:

Not required.

3. Specific Requirements

This section contains the software requirements to a level of detail sufficient to enable

designers to design the system, and testers to test that system.

3.1 External Interface Requirements

3.1.1 User Interface

The following screens will be provided:

Login Screen:

This will be the login screen that will display. It will allow user to access different

screens based upon the user’s role. Various fields available on this screen will be

i) User ID: Textbox-Alphanumeric of length up to 10 characters.

ii) Password: Textbox-Alphanumeric of length up to 8 characters.

iii) Button: Two button one submit another reset.

User Registration Screen:

Normal User: This screen will allow user to register into the system. Various fields

available on this screen will be

i) User ID: Textbox-Alphanumeric of length up to 10 characters.

ii) Password: Textbox-Alphanumeric of length up to 8 characters

iii) Retype Password: Textbox-Alphanumeric of length up to 8 characters

iv) Name: Textbox-Only alphabet and white spaces of length up to 50 characters

v) Father Name: Textbox-Only alphabet and white spaces of length up to 50 characters

vi) Date of Birth: three select control for Date, month, year.

vii) Sex: Select male, female, others

viii) Address: Textbox-Alphanumeric and special character.

ix) Contact no.: Textbox-only number

x) E-mail: Textbox-Alphanumeric, _, @

xi) Button: Two button one submit another reset.

System User: Same as normal user but there is a extra select control for users role.

Flight Search screen: Various fields available on this screen will be

i) Flight Category: choose radio button for domestic or international flight

ii) Flight Mode: choose radio button for one-way or two-way flight mode.

iii) Origin: select the airport name.

iv) Destination: select the airport name but selected origin airport name not display here.

v) Arrival Date: three select option for day, month, year format.

vi) Departure Date: three select option for day, month, year format. If one-way flight

mode selected then it will be disabled.

vii) No of Member: three select button for adult, child (1-12years), infant (0-1years)

respectively.

viii) Service Class: select one from three option viz. general class, economy class,

business class.

ix) Flight Type: Select one from two option viz. non-stop, one-stop.

x) Button: Two button one submit another reset.

Payment Mode Screen: The screen allows the user to choose different mode of

payment. Various fields available on this screen will be

By cash: Payment by cash allow to booking officer.

i) Amount: only displayed

By credit card: Payment by credit card allow to registered user and booking officer

i) Amount: only displayed

ii) Credit card type: select from options

iii) Credit card Number: Textbox-only numeric value. Length upto 19.

iv) Name on card: Textbox-Alphabet and white space

v) Service Bank: select option

vi) Expire date: select two option for month and year

By Debit card: Payment by debit card allow to registered user and booking officer

i) Amount: only displayed

ii) Debit card type: select option

iii) Debit card Number: Textbox-only numeric value. Length up to 19.

iv) Name on card: Textbox-Alphabet and white space

v) Service Bank: select option

vi) Expire date: select two option for month and year

By Internet Banking: Payment through internet banking allow to registered user and

booking officer.

i) Account number: Textbox- Alphanumeric

ii) Account type: select from options

iii) Bank name: select from option

iv) Bank Brach IFSC code: Alphanumeric. Up to 11 character.

v) Net banking used id: Textbox-Alphanumeric.

vi) Net banking password: Textbox

x) Button: Two button one submit another reset.

Passenger Details Screen:

This screen allow to user to insert the passenger information. Various fields available on

this screen will be

i) Seat Position: select the seat position from left window, left-middle, left-side, right

window, right-middle, and right-side

ii) Title: select one option Mr., Mrs., Miss etc.

iii) First name: Textbox-Only alphabet and white spaces of length up to 50 characters

iv) Last name: Textbox- Only alphabet and white spaces of length up to 50 characters

v) Date of birth: three select control for Date, month, year.

vi) Sex:

vii) Address: Textbox-Alphanumeric and special character.

viii) Contact number: Textbox-only number.

ix) Email Address: Textbox-Alphanumeric, _, @

x) Meal preference: select one from the option viz. veg., nonveg, jain.

xi) Special Assistance: select one option from the baby trolley and wheel chair.

xii) Button: Two button one submit another reset.

Report Generation Screen

Flight details Report:

The screen allows the user to view & generate several reports. Various fields available on

this screen will be

i) Select flight report mode: select the option from daily, weekly, monthly, few months,

yearly

ii) Button: Two button one submit another reset.

Others report are there……………..

Home Page Screen:

Login Screen: same as above mentioned

Flight Search Screen: same as above mentioned

Menu: There are different drop down menu option

3.2 System Features

3.2.1 User Account Maintenance

DescriptionThe system will maintain information about various users who will be able to access the system. User Id, User name, Password, personal details etc.

Validity Check i) Only user with role Administrator will be authorized to access the User Accounts Information Maintenance module. ii) User Name cannot be blank iii) User ID cannot be blank iv) User Id should be unique for every user v) Password cannot be blank Sequencing Information User Account for a particular user has to be created in order for the system to be accessible to that user. Every user will log in to the same interface.Error Handling/Response to Abnormal Situations If any of the above validations/sequencing flow does not hold true, appropriate error messages will be prompted to the user for doing the needful.

3.2.1 Flight maintenance DescriptionThe system will maintain information about different flight. The following information would be maintained for each flight:flight no, origin, destination arrival time, departure time, flight type, travel cost, etc.

The system will allow add/modify/deletion of new/existing flight and also have the ability to list all available flight for a particular.Validity Check

Only user with role Administrator will be authorized to access the fight information maintain module.

Flight no will be unique. Flight no can't be blank. Arrival & departure time can't be blank. Source & destination must be selected. Flight type must be selected. If middle stop between source and destination selected then middle airport will be

selected.Sequencing InformationFlight information for a particular route will have to be entering in the system before any customer’s request for flight search.

Error Handling/Response to Abnormal SituationsIf any of the validations/sequencing flow does not hold true appropriate error massage will be prompted to the user for doing the needful.

3.2.3 Promotional offer Maintenance Description

The system will maintain the information about several promotional offer time to time. The following information maintains offer_issue_date_time, offer_retrive_date_time, price percentage, fly route.The system will allow add/modify/deletion of new/existing flight and also have the ability to list all available flight for a particular.Validity Check

Only user with role Administrator will be authorized to maintain promotional offer information module.

Offer type should not be blank Offer duration should not be blank. In case of senior citizen age limit must be check. Offer price should not be blank. Fly route must not be blank.

Sequencing InformationPromotional offer information for a particular route will have to be entered in the system before any customer’s request for offer search.Error Handling/Response to Abnormal SituationsIf any of the validations/sequencing flow does not hold true appropriate error massage will be prompted to the user for doing the needful.

3.2.4 Ticket Generation:Description:The system will generate ticket for different passenger. The ticket will have the following format:

Validity Check:In case of original ticket issue the Booking officer will enter the ticket number.

Sequencing Information:The user must be booked the flight before generating the ticket. That means flight details, payment details, passenger details must be store into system before ticket generate.

Error Handling/Response to Abnormal SituationsIf any of the validations/sequencing flow does not hold true appropriate error massage will be prompted to the user for doing the needful.

3.2.5 Report GenerationThere are various reports that will be generated by the Administrator and Booking officer.

Flight Details Report:

Description:The report will show the flight details both date and route wise.

The report will have the following format.

Validity Checks:i) Only administrator will be authorized to access the report generation.ii) Report type must be chooseiii) Date or route must be selected.

Sequencing Information:Report for a particular date can be generated by the system only after flight info has been entered in the system for the given flight.

Error Handling/Response to Abnormal SituationsIf any of the validations/sequencing flow does not hold true appropriate error massage will be prompted to the user for doing the needful.

Sales Report:

Description:

The report will show the sales details both date and route wise.

The report will have the following format:

Route wise sales Report:

Date wise sales Report:

Validity Checks:i) Only administrator will be authorized to access the report generation.ii) Report type must be chooseiii) Date or route must be selected.

Sequencing Information:Report for a particular date can be generated by the system only after flight info has been entered in the system for the given flight.

Error Handling/Response to Abnormal SituationsIf any of the validations/sequencing flow does not hold true appropriate error massage

will be prompted to the user for doing the needful.

3.3 Performance Requirements

None

3.4 Design Constraints

None

Software System Attributes

Security

The application will be password protected. Users will have to enter correct username,

password in order to access the application.

Maintainability

The application will be designed in a maintainable manner. It will be easy to incorporate

new requirements in the individual modules (i.e., Flight info, user info, report generation,

user account info)

Portability

The application will be easily portable on any windows-based system that has Apache

Tomcat, Oracle9i installed

3.6 Logical Database Requirements

The following information will be placed in a database:

i) User_login_details: index_no, login_id, user_password, password_question, password_answerii) user_personal_details: login_id, user_first_name, user_last_name, fathers_name, guardian_name, date_of_birth, sex, marital_status, occupation, no_of_family_membersiii) user_contact_details: login_id, land_phone_no, email_id, address_of_communication, state1,pin_no1, address_of_permanent_residence, state2, pin_no2iv) aircraft_details: aircraft_type, capacity, no_of_aircraft, company_namev) aircraft_internal_details: model_no, purchase_date, manufacture_date, expire_date, weight, flying_time, aircraft_typevi) flight_details: flight_id, from_city_id, to_city_id, departure_time, arrival_time, departure_date, arrival_date, aircraft_type, no_of_stop_over, via_city_idvii) business_class: flight_id, seat_lw, seat_lm, seat_ls, seat_rw, seat_rm, seat_rs, seat_total, fare_rateviii) economy_class: flight_id, seat_lw, seat_lm, seat_ls, seat_rw,

seat_rm, seat_rs, seat_total, fare_rate

ix) general_class: flight_id, seat_lw, seat_lm, seat_ls, seat_rw, seat_rm, seat_rs, seat_total, fare_rate

x) reservation_details: reservation_id, reservation_date_time, no_of_seat, class_of_seat, payment_type, mode_of_trip, amount, flight_id, user_idxi) passenger_details: passenger_id, reservation_id, ticket_no, seat_no, passenger_name, dob, sex, address_of_communication, state, pin_no, phone_no, email_id, meal_peference, special_assistancexii) payment_card_details: reservation_id, transaction_id, card_mode, card_no, card_type, card_expire_date, bank_namexiii) payment_bank_details: reservation_id, transaction_id, bank_name, account_no, account_type, bank_IFSC_codexiv) airport_details: airport_index, airport_id, airport_name, airport_place, airport_countryxv) feedback_details: login_id, fback_details, feedback_date

3.7 Other Requirements:

None

Snapshot of the Web Pages

Phoenix Air Home Page

Login Screen

Booking Officer User Interface Screen

Flight Booking Screen

After Search Screen

Reservation Screen

Passenger Details Screen

Payment Mode Screen

Payment By Credit Card Screen

Payment By Internet Banking Screen

Ticket

Ticket Cancel Screen

Administrator Interface

Flight Maintain Screen

Add Flight Screen

Cancel Flight Screen

Add Aircraft Screen

Delete Aircraft Screen

Add Airport Screen

Delete Aircraft Screen

User Account Maintain Screen

System User Registration Screen

Report Generation Screen

Daily Flight Report

Weekly Flight Report

My Account Screen

User’s Basic Profile

Change Password Details Screen

Change Personal Details Screen

Change Contact Details Screen

Password Recovery Screen

Second Password Recovery Screen

Final Password Recovery Screen

Logout Screen

Feedback Screen

User Error Login Screen

One of the Menu Item

Problem Areas

We have faced various types of problems during different phases of the development. Since automation of the whole airline booking and management system is not a simple task, it took considerable time to understand the actual requirements of the project. The exact module to be implemented & their concerned task took considerable time & complexity. The planning phase was the main complex & time demanding task. Next was the interface designing & coding phase. In this phase we did not use any IDE that’s why we have faced some problems. After coding, mainly database connection oriented program was viewing its completion. However, it was the one kind of major problem. Due to some technical fault in the lab, initially database connection could not be made. This problem made a major barrier to the coding phase which caused unnecessary delay. We have faced some problem during software installation also which are related to our project. We faced similar port number problem during Oracle9i and Apache Tomcat Web Server installation. That’s why had to install and reinstall Oracle9i and Apache Tomcat Web Server for a number of times. Finally the Database connection was successful with proper configuration of Apache Tomcat witch literally completed the phase except some pending minor finishing touches. The testing phase went more or less smoothly with usual share of ups and downs.

Further Modification

Though the developed modules successfully meet the project requirements, however

there are provisions for further modifications. The package can be improved and updated

with time and requirement. These changes can be incorporated from time to time.

The interfaces must be updated from time to time to keep make the process

interesting. New type of accounts may be introduced in future. In the package Fixed

Deposit accounts interest rates are of two categories depending on a threshold time span.

Instead of one threshold time various other time thresholds can be introduced to facilitate

a more varied range of interest rates & hence more flexibility.

Due to technical reasons, not too much consideration could be made on concurrency control measures. Hence in future these provisions may be incorporated.

Conclusion

The proposed software system for online Air Booking and Management system has been prepared. It now remains to be seen how the system scale when actually put into practice. This is because of the fact that the testing of the system has been done using test data which is not huge in volume, but categorical. The entire project was successfully deployed at a number of sites and been tested to provide reliable service.

However, it is also a fact that the assumption made during preparation of the system may be done with and further development on the system is possible. It needs to be mentioned that the system on which the software is going to be run needs to be secure since it contents confidential data regarding the account details of customers which should not be tampered with.

This project develop by us is fully parameterized so if the user wants to modify, delete or add some thing, he/she can do it with ease.

The software is using JSP & servlet at the font end and Oracle9i at the back end. The software can be accessed by the registered customer, general user. The software is expected to provide an efficient, quick and accurate management of the database.

Due to limited time we can not develop the following parts: Return(Two-way) Flight Booking Promotional offer area. Travel agent part Frequent flyer facilities. Few parts of report generation. Feedback report viewing by customer care.

Bibliography

Books Referred:

Professional Java Server Programming by Allamaraju ET. AL

The complete Reference Java 2 Fifth Edition by Herber Schildt

Beginning J2EE 1.4 by Kevin Mukhar & James L. Weaver.

SQL, PL/SQL, The programming Language of Oracle by Ivan Bayross

Software Engineering by K. K. Aggarwal & Yogesh Singh

Software Engineering- A Practitioner’s Approach by Roger Pressman

Website referred:

www.java.sun.com

www.w3c.org

www.w3school.com

www.flykingfisher.com

www.jetairways.com

www.airindia.in