2010

SOFTWARE ENG CONCEPT

AND TOOL
DESIGN PROBLEM

Airways Reservation System

SUBMITTED TO:
MONA LISA MAM SUBMITTED BY :
ANJANI KUNWAR
RA1803A10
10807973
B.TECH(CSE)-H
Problem :

Design an Airways Reservation System with

cancelling facility.
Elaborate the system using Date Flow Diagram
(DFD) at the 1st and 2nd Level.

Expectation from Students:

1.Software should able to find the best Airlines,

airlines having maximum bookings.
2.Customer satisfaction / feedback form should
be there
3. Draw the 1 and 2 level DFDs.
st nd

4.Design Class Diagram for Database

5.Write the Stored Procedure also.
 CONTENTS

1:Overview
1.1:Need of Airlines system
1.2: Feasibility
2:Analysis
3:Functional Requirements
3.1:User Accounts
3.2:Checking Availability
3.3:Making Reservations/Blocking/Confirmation
3.4:Confirm Ticket
3.5:Reschedule Ticket
3.6:Cancellation
4:Performance
4.1:Reliability
4.2:Usability
5:Software Product Feature
5.1:Associated Fuctionality requirement
5.2:Associated Fucntional Requirement
5.3: Performance Requirement
6:Database Design
7:Contents
7.1:Inventory Management
7.2:Availability Display and Reservation (PNR)
7.3:Fare Quote and Ticketing
8:Report Module
9:Block Diagram of ARS
10:Overall UML Structure
11: E-R Diagram
11.1:For Booking Department
12.2:For Cancellation
12:Data Flow Diagram
12.1:Context Diagram
12.2:Level 0 DFD
12.3:Level 1 DFD
12.4:Level 2 DFD
13:Algorithm
14:Testing Analysis
15:Class Diagram for Database
16:Some More DFD's
Airline Reservations System
An Airline Reservation System is part of the so-called Passenger Service Systems
(PSS), which are applications supporting the direct contact with the passenger.

The Airline Reservations System (ARS) was one of the earliest changes to
improve efficiency. ARS eventually evolved into the Computer Reservations
System (CRS). A Computer Reservation System is used for the reservations of a
particular airline and interfaces with a Global Distribution System (GDS) which
supports travel agencies and other distribution channels in making reservations for
most major airlines in a single system.

Overview
Airline Reservations Systems contain airline schedules, fare tariffs, passenger
reservations and ticket records. An airline's direct distribution works within their
own reservation system, as well as pushing out information to the GDS. A second
type of direct distribution channel are consumers who use the internet or mobile
applications to make their own reservations. Travel agencies and other indirect
distribution channels access the same GDS as those accessed by the airlines'
reservation systems, and all messaging is transmitted by a standardized messaging
system that functions primarily on TTY messaging called SITA. Since airline
reservation systems are business critical applications, and their functionally quite
complex, the operation of an in-house airline reservation system is relatively
expensive.

Prior to deregulation, airlines owned their own reservation systems with travel
agents subscribing to them. Today, the GDS are run by independent companies
with airlines and travel agencies as major subscribers.

The closed boundary above clearly delineates the system and the environment. The
diagram shows the interactions between the ARS software and the databases inside
the system. There are three databases internal to the system and which the system
maintains. DB-user is the database containing all the personal information of the
registered users of the ARS. This can be updated by the user by logging in to the
system. Information from this database is used during transactions like charging
the credit card etc. DB-schedule is a copy of the flight schedule database. The
latter exists independently and is updated by a flight scheduler system which is out
of scope of the ARS. DB-schedule is updated with the latest status of the flight
schedule database whenever there is any change in the latter. For example, if a
flight has been added to the schedule between two cities on Tuesdays, DB-
schedule gets updated with this change through a process with which we are not
concerned. It is external to the system and is out of the scope of this SRS. DB-
schedule also contains the base prices of tickets for various flight numbers. DB-
reservations are a database containing information regarding the number of seats
available on each class on different flights. It has provision for marking how many
of the reserved seats have been blocked but not yet bought. DB-reservations should
update itself using DB-schedule, for example, if a new flight is added. DB-
geography is a database, which contains information about the cities and towns
serviced by the airline. The distance between all cities and towns is contained in a
matrix form. There are three interfaces, one for the administrator, one for the
customer via web and another for the customer via phone. The administrator can
update DB-schedule with any changes in the base prices of flight tickets. The
system uses a pricing algorithm and dynamically determines the actual price from
this base price depending on the date of reservation vis-à-vis date of departure. The
customer interfaces (web and phone) enable multiple functions which are
described in the following section

Need of Airlines system

1) Faster System
2) Accuracy
3) Reliability
4) Informative
5) Reservations and cancellations from any where to any place

AIRLINE SYSTEM

RESERVATION CANCELLATION

UPDATION

FEASIBILITY

FEASIBILITY STUDY

Feasibility study is to check the viability of the project under consideration.

Theoretically various types of feasibilities are conducted, but we have conducted
three type of feasibilities explained as under.
ECONOMIC FEASIBILITY

With the manual system the operating cost of the system is about 60 Lacks P.A..
This cost comprises salary of 25 people, stationary, building rent, electricity, water,
telephone etc. But with the new system this reoccurring cost comes out to be about
20 Lacks P.A. Hence the new system is economically feasible.

TECHNICAL FEASIBILITY

The new system requires only 6 trained person to work with the system and in
overall 10 people per office are sufficient. So we will identify 6 best people from
existing system and train them.

As our existing system is purely manual, so we need a one time investment of Rs 4

Laks for the purchase of 7 computers, 5 Ticket printers, a laser printer, AC and
networking etc. It requires 20 Lacks PA as a operating cost.

With the above details our system is technically feasible as after investing 24
Lacks in a year, the company is still saving Rs 25 Lacks PA.

OPERATIONAL FEASIBILITY

The new solution is feasible in all sence but operationally it is not. The new system
demands the expulsion of at least 15 people from the company. It creates an
environment of joblessness and fear among the employees. It can lead to an
indefinite strike in the company also. So the management must take corrective
actions prior in advance in order to start the further proceedings.

ANALYSIS
REQUIREMENT ANALYSIS

Requirements are prone to issues of the ambiguity, incompleteness and

inconsistency techniques such as rigorous inspection have been shown to help deal
with these issues.Ambiguity, incompleteness and inconsistencies that can be
resolved in the requirement phase typically cost orders of the magnitude less to
correct than when these same issues are found in later stages of product
development.The purpose of developing the specified software is to describe the
analysis involved in the reservation of air ticket.

REQUIREMENT ANALYSIS

Requirements are prone to issues of the ambiguity, incompleteness and

inconsistency techniques such as rigorous inspection have been shown to help deal
with these issues.Ambiguity, incompleteness and inconsistencies that can be
resolved in the requirement phase typically cost orders of the magnitude less to
correct than when these same issues are found in later stages of product
development.The purpose of developing the specified software is to describe the
analysis involved in the reservation of air ticket.

FUNCTIONAL ANALYSIS

Input: Collecting the information of the person who is going to travel.

Output: The issue of ticket on the particular date specified by the traveler.
PROCESS

 Enter the details of the traveler.

 Check for availability of tickets.

 Inform the traveler the position of the available seat.

 Ask his/her decision whether to reserve the ticket or not.

 Positive reply-book ticket after receiving the amount for the cost of ticket.

 Issue the ticket.

 Ask the traveler to check in time so that he/she doesn’t miss the plan
because of delay.

 Update the database before the next booking is to be done.

 Functional Requirements

User Accounts

The passenger, who will henceforth be called the ‘user’, will be presented with 3
choices by the reservation system, as the first step in the interaction between them.
A user can choose one of these and his choice would be governed by whether he is
a guest or a registered user and whether he wants to check the availability of tickets
or also block/buy them. The terms ‘registered user’ and ‘guest’ are described
below.
A user who has traveled by the airline earlier would have been given a user id and
a password. He would have his personal information stored in the database referred
to earlier in section 2 as ‘DB-user’. This ‘personal information’ would be
henceforth referred to as ‘profile’. Such a user with a profile in DB-user shall be
called a ‘registered user’. A registered user will be able to check the availability of
tickets as well as block/buy a ticket by logging into the system.

A new user, on the other hand, would either have to

a) register himself with the system by providing personal information or

b) log into the system as a guest.
In case of ‘a’, the new user becomes a registered user.

In case of ‘b’, the new user would remain a guest.

A guest can only check the availability of tickets and cannot block or buy
tickets.

But a registered user can also act as a guest if he only wants to check the
availability of tickets. ‘Availability of tickets’ always refers to viewing the
flight schedule for given days, the price of tickets and any discount offers.
 The system shall present the user with an option to exit from the system at
any time during the following processes.

Registration and creation of user profile

The system shall require a user to register, in order to carry out any
transactions with it except for checking the availability of tickets. It will ask
the user for the following information at the least – a user id, a password,
first name, last name, address, phone number, email address, sex, age,
preferred credit card number. The system will automatically create a ‘sky
miles’ field and initialize it to zero in the user’s profile.

Checking Availability

After logging in a user (either a registered user or a guest), the system shall request
him to enter the following details – origin city and destination city. “City’ is
a generic term and refers to a city or town as the case may be. The origin and
destination cities would be entered as text.

The system shall now refer to the flight schedule database, referred to as ‘DB-
geography’ in section 2, and check if there is any ambiguity with the names of the
cities. In case there are more than two cities with same name as entered by the
user, the system shall list all of them (with more qualifications) and ask the user to
select one of them. In case, either the origin or destination cities are not listed in
DB-geography as being directly serviced by the airline, the system shall suggest
the nearest city to which service is available, including the distance of the
destination city from this nearest city.
After the origin and destination cities are ascertained, the system shall now
access the flight schedule database, referred to as ‘DB-schedule’ in section
2, and checks if there is a direct operational service between the two cities. If
not, the system shall suggest possible routes and transfer points using a
‘route selection algorithm’. The user shall now be presented with a choice of
either selecting one of the routes. In case he selects a route, the system shall
fill in the intermediate stop over points and create a multiple trip itinerary for
the user.
The system shall now ask the user to enter the following details - class, one-
way or round trip, departure date and the number of adult passengers,
children and senior citizens.

‘Class’ refers to business class/first class/club class/smoking/non smoking.

This choice shall be made by the user through a drop down menu indicating
all the possible combinations of choices.
One-way/round trip shall be either a drop down menu or a check box
selection. ‘Departure date’ refers to either a single date or a range of dates,
entered through a calendar-like menu. This menu shall not show dates in the
past or those dates that are too ahead in the future(as determined by the
airline policy). In case, the trip is a round trip, the system shall also ask the
user to enter the departure date on the return trip.
Having taken all the above input from the user, the system checks for any
false entries like the departure date on the return trip being earlier than the
departure date on the onward trip. In case of incompatibility, the system
shall display a suitable error message and prompt the user to enter the
information correctly.
Having taken all of the information as laid out above in 3.3.1 and 3.3.4, the
system shall now access the flight schedule database ‘DB-schedule’ and
queries it using the input provided by the user.
The system queries the reservation database ‘DB-reservations’ to check
which of the flights on the schedule have seats available. The system
displays the results in a suitable form (a tabular form) with the following
information depicted – for each flight number – the flight number, departure
time in origin city, arrival time in destination city, the duration of the flight
(taking into account the possibility of a change of time zone) and the number
of seats available on that flight.
There can be several flights between two cities and all of them will be listed
for the particular date that the user wants to depart from the Origin City. In
case, the user has entered a range of dates, the system shall display all the
flights for all those dates in the range.
If the user has requested a round trip, the system shall display two tables -
one for the onward trip and one for the return trip. There will be a check box
in front of each line in the table representing a flight with available seats.
The user is now asked to check one of the boxes reflecting a choice of a
flight number and time. In case of a round trip, the user is asked to check
one box each in the two tables.
The system shall now display the price of the ticket for the trip. This will be
the sum of the prices for all the members of the travel party being
represented by the user.
The system shall also list any rules regarding the cancellation of tickets –
what percentage of the price will be refunded within what date ranges. This
will be displayed as a table.
Making Reservations/Blocking/Confirmation

After having taken the user through the step 3.3, Checking Availability, The
system will now ask the user if he wishes to block/buy the ticket. If yes, and

a) if the user has been a guest, he will have to first register and become a
registered user and then log onto the system.
b) If the user is already a registered user, and if he has logged on already, he
can block/buy the ticket, but if he has been acting as a guest, he will have to
log on.
Having ensured that the user is logged on validly according to 3.4.1, the
system compares the departure date with the system date. If the departure
date falls within 2 weeks of the system date, the system informs the user that
he has no option to block the ticket and asks him if he would like to buy it.
If the difference between the departure date and system date is more than 2
weeks, the system asks the user if he would like to block or buy the ticket.
The system informs the user that he can block the ticket at no cost now. It
also informs him that if he chooses to block the ticket, he should make a
final decision before 2 weeks of the departure date. The system shall send an
email to the user, 3 weeks before the departure date as a reminder, in case he
decides to block the ticket now.
Having taken the input from the user in 3.4.2, the system shall now proceed
to update the reservation database DB-reservation. It will decrement the
number of available seats on the particular flight for the particular class by
the number of travelers being represented by the user.
In case of a blocking, the system makes a note of it in the database - to be
used if the user doesn’t turn up before 2 weeks of the departure date. It
generates a blocking number and displays it for the user to note down.
 In case the user buys the ticket, the system accesses his profile and charges
the price of the ticket to his credit card number. It simultaneously generates
a confirmation number and displays it to the user for him to note down. The
ticket has been reserved.
It adds the mileage of the trip (accounting for the number of travelers) to the
skymiles in his profile.

Confirm Ticket
A user who has earlier blocked a ticket after going through the steps 3.2 through
3.4, is required to either confirm the ticket before two weeks of the departure
date or the ticket stands cancelled.

To let the user confirm a ticket, the system shall first log him on and ask for his
blocking number. Then it accesses DB-reservation and removes the check mark,
which so far represented a blocked seat. The seat is now confirmed and reserved
for the user.
The system accesses DB-user and charges the price of the ticket to the credit card
number of the user. It simultaneously generates a confirmation number and
displays it for the user to note down. The ticket has been reserved.
It adds the mileage of the trip (accounting for the number of travelers) to the
skymiles in his profile.

Reschedule Ticket
The system shall present the user with an option to re-schedule his travel
party’s trip. In order to do this, the system first logs on the user and requests
his confirmation number. It will not allow a user to reschedule a blocked
ticket but only a confirmed ticket. Using this, it queries DB-reservation and
presents the details of the trip to the user, including but not limited to origin
city, destination city, date of departure and date of arrival (in case the trip is
a round trip).
The system shall now ask the user to select new dates from the calendar-
menu. It now goes through step 3.3.
In case, there are no available tickets for the dates entered, it displays a
suitable message informing him that rescheduling to that date is not possible.
In case there are tickets available, the system asks the user to select the flight
number for the trip (another for the return trip if the trip is a round trip) and
proceeds to update the database.
The system accesses DB-reservation and decrements the number of available
seats on the flight(s) by the number of members in the user’s travel party. It
then increments the entry for the previous flight by the same number to
reflect an increase in the available seats on it as a result of the rescheduling.
The system now checks if there is any difference in the prices of the tickets.
If so, it accesses DB-user and charges or credits the credit card as the case
may be. The system generates a new confirmation number and displays it to
the user.

Cancellation
The system shall also give the user an option to cancel a confirmed ticket or
a blocked ticket.
The latter case is simpler and will be dealt with first – the system shall first
log on the user and request the blocking number. Then it accesses DB-
reservation and updates it by incrementing the number of available seats by
the number of people in the user’s travel party.
In the former case, i.e., for a confirmed ticket, it asks for the confirmation
number and accesses DB-reservation and presents the details of the trip as in
step 3.6.1.
It then lists the applicable rules for cancellation of tickets and depending on
the system date and the departure date, it displays the % of the amount that
would be refunded if the user cancels the ticket.
After the user cancels the ticket, the system generates a cancellation number
and displays it for the user to note down. It accesses DB-reservation and
updates it by incrementing the number of available seats on that flight by the
number of travelers in the user’s party. It accesses DB-user and credits the
refund amount to his credit card number. The system then deducts the
mileage of the trip (taking into account the number of travelers in his party)
from the sky miles in his profile.

Update Profile
The system shall enable the user to update his profile at any time. Changes
can be made in fields including but not limited to address, phone number
and preferred credit card number.

View Ticket Status

The system shall allow a user to view all information about his trip. After
logging him on, it asks for his blocking number or his confirmation number.
It accesses DB-reservation and retrieves the details of the trip and presents
them to the user in a convenient format, including any last minute changes to
the flight timings etc. Such changes will be highlighted.
Query Flight Details

The system shall allow any user (registered or non registered) to access the
details about the arrival and departure times of a flight by requesting the user
to input the flight number and date. The system accesses DB-schedule and
presents the time of arrival and departure.

Telephone access
The system shall be accessible through a touch-tone telephone. The
telephonic interface shall, at the least, provide the customer with the facility
to check availability of tickets and query flight details. The system shall
walk the customer exactly through steps 3.3 and 3.9 respectively but through
a telephonic interface.

Performance
Response time of the Airline Reservation System should be less than 2
second most of the time. Response time refers to the waiting time while the
system accesses, queries and retrieves the information from the databases
(DB-user, DB-schedule etc) (A local copy of flight schedule database is
maintained as DB-schedule to reduce this access time)

ARS shall be able to handle at least 1000 transactions/inquiries per second.

ARS shall show no visible deterioration in response time as the number of
users or flight schedule data increases
Reliability
ARS shall be available 24 hours a day, 7 days a week
ARS shall always provide real time information about flight availability
information.
 ARS shall be robust enough to have a high degree of fault tolerance. For
example, if the user enters a negative number of passengers or a value too
large, the system should not crash and shall identify the invalid input and
produce a suitable error message.
ARS shall be able to recover from hardware failures, power failures and
other natural catastrophes and rollback the databases to their most recent
valid state.

Usability

ARS shall provide a easy-to-use graphical interface similar to other existing

reservation system so that the users do not have to learn a new style of
interaction.

The web interface should be intuitive and easily navigable Users should be
able to understand the menu and options provided by ARS.

Any notification or error messages generated by ARS shall be clear,

succinct, polite and free of jargon.

Integrity

Only system administer has the right to change system parameters, such as
pricing policy etc. The system should be secure and must use encryption to
protect the databases.

Users need to be authenticated before having access to any personal data.

Interoperability
ARS shall minimize the effort required to couple it to another system, such as
flight schedule database system.
3. SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACE REQUIREMENTS

User Interfaces

The interface must be easy to understand. The user interface includes

• SCREEN FORMATS/ORGANIZATION: The introductory screen will be

the first to be displayed which will allow the users to choose either of the
two options, viewing flight detail or booking a ticket.
• WINDOW FORMAT/ORGANIZATION: When the user chooses some
other option, then the information pertaining to that choice will be displayed
in a new window which ensures multiple windows to be visible on the
screen and the users can switch between them.
• DATA FORMAT: The data entered by the users will be alpha numeric.
• END MESSAGES: When there are some exceptions raising error like
entering invalid details, then error messages will be displayed prompting the
users to re-enter the details.

Hardware Interfaces
The system must basically support certain input and output devices. Their
descriptions are as follows.

Name of Item Description of Purpose Source of Input/

Description of output
Key board To accept data from Source of Input
user like pin code,
personal details, flight
details
Printer To print the bookings Destination of Output
mode E.g.: Destination
chosen with date and
timings
Software Interfaces

Not applicable since the product under considerations is an independent one.

Communication Interfaces

Every client system connected through LAN establishes a communication only

with the server and not with any client system. An LAN of 10 Mbps is used.

SOFTWARE PRODUCT FEATURES

FEATURE 1

The ability of the software is to provide the details of the flights available and
allow the customers to choose a particular destination and make a reservation.

PURPOSE

The purpose of this is to enable the users to view the different flights
available so as to make it convenient for him to make a reservation.

STIMULUS/RESPONSE

Once the user chooses the particular option, the web pages corresponding to
that are to be displayed on the screen i.e., it will display the different flights
available to their respective destinations and allow the customer to book a
ticket.
ASSOCIATED FUNCTIONAL REQUIREMENTS

FUNCTIONAL REQUIREMENTS

Once the user makes a reservation, he must be provided with a pin

code.

INTRODUCTION

The user must be provided with the required information within 10

seconds.

INPUTS

The user must enter the destination with date and timings and must
make reservation by giving his personal details like name, address,
age, gender, nationality.

PROCESSING

Recognizing the correct details are entered that a message is displayed

confirming his reservation and displays the pin code.

FEATURE 2

The software allows the user to modify an already existing reservation made
by the customer if in case there are any changes that are to be modified in
the reservations of the ticket.

PURPOSE

The purpose is to allow the customer to make any changes in his personal
details or flight booking details.

STIMULUS/RESPONSE

Once the user requests for changing his reservation, it must be displayed on
the screen prompting the customer to enter his pin code.

ASSOCIATED FUNCTIONALITY REQUIREMENTS

 FUNCTIONAL REQUIREMENTS

If the pin code provided by the customer does not match, then would
notify the person by displaying error messages.

INTRODUCTION

The system will allow the customer to modify his reservation

provided correct pin code has been entered by him.

INPUT

The user should enter his pin code which gives him access to modify
his reservation.

PROCESSING

The pin code is processed and checked for his validity. If it is correct
then the user can modify his reservation else an error message will be
displayed asking the user to enter the correct pin code number.

OUTPUT

Given the correct pin code, the user can now modify his reservation.
A new pin code will be generated for the customers.

FEATURE 3

The software allows the user to cancel an already existing reservation made by the
customer who has booked the ticket.

PURPOSE

The purpose is to allow the customer to cancel his reservation if not

required.

STIMULUS/RESPONSE

Once the user requests for canceling his reservation, it must be displayed on
the screen prompting the customer to enter his pin code.
 ASSOCIATED FUNCTIONAL REQUIREMENTS

FUNCTIONAL REQUIREMENTS

If the pin code provided by the customer does not match, then it
would notify the person by displaying error messages.

INTRODUCTION

The system will allow the customer to cancel his reservation provided
correct pin code has been entered by the customer.

INPUT

The user should enter his pin code which gives him access to cancel
his reservation.

PROCESSING

The pin code is processed and checked for its validity. If it is correct,
then the user can cancel his reservation else an error message will be
displayed asking the user to enter the correct pin code number.

FEATURE 4

The software must also give a report on the number of reservations made for a
particular flight.

PURPOSE

The purpose is to enable the administrator to view the number of people in a

particular flight.

STIMULUS/RESPONSE

Once the user requests for this option, all the details of the customers who
have made reservation will be displayed.
 ASSOCIATED FUNCTIONAL REQUIREMENTS

FUNCTIONAL REQUIREMENTS

If no reservations are made, then a message is displayed that no

bookings have been made.

INTRODUCTION

The system will allow the administrator to view all the details of the
customer who have made reservations.

INPUT

The administrator must enter the password so that access is given only
to him to view the details of all the customers.

PROCESSING

The password is processed and checked for its validity. If it is not

correct, then the administrator is asked to enter the correct password.

OUTPUT

Given the correct password, the administrator can view all the details
of customers with date and time of their bookings made.

PERFORMANCE REQUIREMENTS

• At any instant, a maximum of four nodes or users will be given access

simultaneously.
• Since the program handles multiple users, if more than one person attempts
to same date to the files stored in the data base, the program will lock the
data file using a 2-phase commit protocol to prevent simultaneous access.

DESIGN CONSTRAINTS

• Requires 256 MB on-board memory.

• Based completely on Windows functionality platform.
• The software should be portable and must be inaccessible to unauthorized
users.
SOFTWARE SYSTEM ATTRIBUTES

Reliability

The factors needed to establish the software expected reliability are

• The user inputs should be valid and within the given range.
• Normal termination of the program.

Availability

The factors guarantee the software’s availability includes proper termination and
correct input details. Also the resources used for the project development are
Microsoft Certified which speaks of its high quality standards.

Security

• It must be ensured that access will be provided to the authorized persons

through user ID and password.
• Network security will be provided by the use of firewalls.
• Checks can be performed at regular internals to ensure data integrity.

Maintainability

The software will be developed by implementing the concept of modularity which

in turn reduces the complexity involved in maintaining it. The administrator should
have a sound technical knowledge about maintaining the software and further
enhancements will be undertaken by the developer.

Portability

The application is portable which ensures its adaptability for use on different
computer terminals with different operating systems and standards.

LOGICAL DATABASE REQUIREMENTS

The system requires the use of text files to maintain the customers personal details
and his booking details. An entity must be used to specify the various departments
and the seats available in them. This information will be used frequently by the
authorities for verification.

DATABASE DESIGN
We use Oracle as the backend and use JDBC connectivity to access the database.
The servlets access the database using JDBC and output the results according to
the query, which again takes into account the options, selected by the user.
The following gives the various tables and their fields used in our database, which
was a major design decision of our project.

USERS Table contains the details of the users registered for our services.
The fields in this table are as follows:

USERID PASSWORD FNAME LNAME SSN

ADDRESS CARDTYPE CREDITCARD EXPMONTH
EXPYEAR POINTS

USERID is the PRIMARY KEY of this table.

TRANSACTIONS Table contains the details of all the transactions done by

the users through our site. The table contains the following fields:

TNO USERID TDATE OFNO DDATE

DAIRLINE DCITY TICKETS ACITY AAIRLINE
RDATE RFNO TOTAL

TNO is the PRIMARY KEY of this table.

 NEWS Table contains the details of the current news. This news includes
flight cancellations, flight delay information and other important weather
information. The table contains the following fields:

HEADLINEHREF

HEADLINE is the PRIMARY KEY of this table and the HREF is the
link to the file, which contains the complete data regarding the headline.

MOTELS Table contains the motel information for various cities. The
fields in this table are as follows:

CITY MOTEL ADDRESS DELUX LUXURY

(CITY,MOTEL) is the PRIMNARY KEY of this table. DELUX AND

LUXURY are the corresponding of the MOTEL.

AIRLINE Table contains the information about the various flight

availabilities and the related information. The table has the following fields:

FLIGHT DEPCITY DEPPORT DEPTIME ARRCITY

ARRPORT ARRTIME AIRLINE ECPRICE ECSEATS
BSPRICE BSSEATS

(FLIGHT, DEPTIME) is the PRIMARY KEY of this table.

We assumed three airline databases in the above format. For that we

created three different tables DELTA, UNITED, AMERICAN with the same
above schema.

Inventory Management
An airline’s inventory contains all flights with their available seats. The inventory
of an airline is generally divided into service classes (e.g. First, Business or
Economy class) and up to 26 booking classes, for which different prices and
booking conditions apply. Inventory data is imported and maintained through a
Schedule Distribution System over standardized interfaces. One of the core
functions of the inventory management is the inventory control. Inventory control
steers how many seats are available in the different booking classes, by opening
and closing individual booking classes for sale. In combination with the fares and
booking conditions stored in the Fare Quote System the price for each sold seat is
determined. In most cases inventory control has a real time interface to an airline’s
Yield management system to support a permanent optimization of the offered
booking classes in response to changes in demand or pricing strategies of a
competitor.

Availability Display and Reservation (PNR)

Users access an airline’s inventory through an availability display. It contains all

offered flights for a particular city-pair with their available seats in the different
booking classes. This display contains flights which are operated by the airline
itself as well as code share flights which are operated in co-operation with another
airline. If the city pair is not one on which the airline offers service it may display a
connection using its' own flights or display the flights of other airlines. The
availability of seats of other airlines is updated through standard industry
interfaces. Depending on the type of co-operation it supports access to the last seat
(Last Seat Availability) in real-time. Reservations for individual passengers or
groups are stored in a so-called Passenger Name Record (PNR). Among other data,
the PNR contains personal information such as name, contact information or
special services requests (SSRs) e.g. for a vegetarian meal, as well as the flights
(segments) and issued tickets. Some reservation systems also allow to store
customer data in profiles to avoid data re-entry each time a new reservation is
made for a known passenger. In addition most systems have interfaces to CRM
systems or customer loyalty applications (aka Frequent Traveler Systems). Before
a flight departs the so-called Passenger Name List (PNL) is handed over to the
Departure Control System that is used to check-in passengers and baggage.
Reservation data such as the number of booked passengers and special service
requests is also transferred to Flight Operations Systems, Crew Management and
Catering Systems. Once a flight has departed the reservation system is updated
with a list of the checked-in passengers (e.g. passengers who had a reservation but
did not check in (No Shows) and passengers who checked in, but didn’t have a
reservation (Go Shows)). Finally data needed for revenue accounting and reporting
is handed over to the administrative systems.

Fare Quote and Ticketing

The Fares data store contains fare tariffs, rule sets, routing maps, class of service
tables, and some tax information that construct the price - "the fare". Rules like
booking conditions (e.g. minimum stay, advance purchase, etc.) are tailored
differently between different city pairs or zones, and assigned a class of service
corresponding to its appropriate inventory bucket. Inventory control can also be
manipulated manually through the availability feeds, dynamically controlling how
many seats are offered for a particular price by opening and closing particular
classes.

The compiled set of fare conditions is called a fare basis code. There are two
systems set up for the interchange of fares data - ATPCO and SITA, plus some
system to system direct connects. This system distributes the fare tariffs and rule
sets to all GDSs and other subscribers. Every airline employs staff who code air
fare rules in accordance with yield management intent. There are also revenue
managers who watch fares as they are filed into the public tariffs and make
competitive recommendations. Inventory control is typically manipulated from
here, using availability feeds to open and close classes of service.

The role of the Ticketing complex is to issue and store electronic ticket records and
the very small number of paper tickets that are still issued. Miscellaneous Charges
Order (MCO)is still a paper document; IATA has working groups defining the
replacement document the Electronic Multipurpose Document (EMD) as at 2010.
The electronic ticket information is stored in a database containing the data that
historically was printed on a paper ticket including items such as the ticket number,
the fare and tax components of the ticket price or exchange rate information. In the
past airlines issued paper tickets; since 2008 IATA has been supporting a
resolution to move to 100% electronic ticketing. So far, the industry has not been
able to comply due to various technological and international limitations. The
industry is at 98% electronic ticket issuance today although electronic processing
for MCOs was not available in time for the IATA mandate.

REPORT MODULE

The tickets issued should have the details such as plane number, ticket number,
seat number, traveler’s name, time of departure. The traveler should be informed
about the check-in time.The names of the fields involved in the airline reservation
system are

 FLIGHT DETAILS

 CHECK AVAILABILITY
  BOOK TICKET

 VIEW SINGLE PASSENGER RECORD(by taking the ticket number)

 EXIT

MODULE 1:FLIGHT DETAILS

This module is used to view the flight details with ease and it tends the passenger
to book tickets without much difficulty.

MODULE 2:CHECK AVAILABILITY

This module is used to check the availability of the flights and the information of
the seats in that flight.

MODULE 3:SINGLE PASSENGER RECORD

This module is used to view the single passenger details with the help of the ticket
number issued after booking with input support information.

MODULE 4:BOOK TICKET

This module is used to book the ticket after checking the availability of tickets I the
BOOKING
flights. A ticket can be booked to a maximum of five just by entering the passenger
DEPARTMENT
name, age and their details.
RECEIVE
MODULE 5:EXIT
FLIGHT MAINTAINENCE CUSTOMER
BOOKING ,CANCELLATION
This module is used to exit from the reservation
REQUEST form.
PASSENGER

BLOCKDIAGRAM LIST

AIRLINE CONFIRMED

PASSENGER RESERVATION LIST REPORTS

WAITING LIST
SYSTEM
CANCELLATION

DATA STIRAGE DATA ACCESS

Passenger list,

Fleet info
Ticket reservation
concession
Cancellation, databas
Flight
e
Request for information,
enquiry
In passenger list : Passenger name,Address , tel_no , d_o_b, profession father
name,

Fleet info: No aircraft, club_pre_capacity, economic capacity, engine

type,cruisespeed,air length,

Flight info: f_name, f_code, c_code,t_exeseat no, t_economic seat no.

Concession: concession name , concession code , class , discount , v_o_t ,

baggage allowance , fare.

Move of payment: Passenger code ,Date of paid ,Current date, cash,

Debit,cheque,credit.

Fare: route , destination place ,source place ,Departure time, Arrival time,Flight
code,class,Fare.

Reservation: Ticket report, PNR, flight code, destination place, source place,
departure time arrival time , Class, number of passenger, Age, sex, Fare, seat .

Enquiry: Ticket no, seat number , pnr.

Cancellation : Pnr, ticket no, Days left, Basic amount, Cancel amount .

UML FOR AIRLINE RESERVATION SYSTEM

 TEL_NO

E-R DIAGRAM FOR BOOKING DEPARTMENT

ERD (Entity Relationship Diagram)

The object relationship pair can be graphically represented by a diagram

called Entity Relationship Diagram. It is mainly used in database applications but
now it is more commonly used in data design. The primary purpose of ERD is to
represent the relationship between data objects.

Various components of ERD are:

1. Entity 2. Relationship 3. Attribute.

 FLIGHT NUM
TEL_NO
DATE OF DEP
D_O_B
_NUM ROUTE

NAME
ADDRESS

PNR
STATUS

PASSENGER

WAITING
CONFIRM VALID ?

PNR
NAME BOOKING
STAND
2(ON THE
NAME
BY DATE SPOT)
BOOKING PNR
1(ON THE
SPOT) DEBIT BOOKING
PNR DATE

FARE
MODE OF PAYMENT D NO STATUS

PNR
STATUS
PNR CREDIT

CHEQUE FARE
CASH FARE

FARE PNR C NO

STATUS

STATUS CASH PAID

PAID
E-R DIAGRAM FOR CANCELLATION

TEL_NUM D_O_B FLIGHT_ID

T_DATE
PNR

ROUTE

NAME

STATUS

ADDRESS

Passenger

CANCEL
SEAT
?
AVAILABLE

PNR
FLIGHT_NUM
ARRIVAL
CANCEL

NAME
FLIGHTS
COST_ECO

T_DATE
DEPARTURE COST_EXE

SEAT STATUS D_CANCEL

SEATS_ECO

SEATS_EXE
 DATA FLOW DIAGRAM

Data Flow Diagram is one of the Functional Model which are used to represent
the flow of information in any computer based system. Three Generic
Functionalities:

1. Input 2. Process 3. Output

The data flow diagram depicts the information flow and the transforms that
are applied on the data as it moves from input to output.

CONTEXT DIAGRAM

Reservatio
Passeng Booking
n
er System
System

2
Reservation

User Airline Displ

reservation ay
System

3 Cancellation
LEVEL 0 DATA FLOW DIAGRAM

REQUEST FOR INFORMATIONFLIGHT/FARE/DISCOUNT

PASSENGER INFORMATION

1.0

GENERAL

ENQUIRY
BOOKING

ENQUIRY
2.0
NEW PNR INFORMATION
PASSENGER

ENQUIRY

RESERVATION REQUEST 3.0

BOOKING

TICKET CONFIRMATION &STATUS COUNTER

CANCELLATION REQUEST

4.0

CANCELLATION
ACKNOWLEGMENT
 LEVEL1 DATA FLOW DIAGRAM OF GENERAL ENQUIRY SYSTEM

PASSENGER

REQUEST FOR INFOR REQUIRED INFOR

MATION MATION

1.0

GENERAL R
I I
R I
ENQUIRY E
N N
E N
R Q
F F
Q F
E U
O O
U O
Q E
R R
E R
U S
M M
S M
E T
A A
T A
S
T T
T
T
I I
I
O O
O
N M
N 1.2 1.3
1.1
FARE DISCOUNT
FLIGHT
ENQUIRY
ENQUIRY

R I R I
R I

FLIGHT FARE DISCOUNT

 DATA FLOW DIAGRAM OF PASSENGER ENQUIRY SECTION

PASSENGER

ENTRY OF NEW RECORD OR

EXISTING
NEW PNR OR REQUIRED INFORMATION
PASSENGER ENQUIRY

U
PASSENGER R
R
N
ENQUIRY I E
E
I
N Q
Q
Q
F U
U
U
O E
E
E
S
S
P
T
T
N
2.2
R
NEW PASSENGER

PASSENGER ENQUIRY

R UNIQUE R INFORMATION
PNR

PASSENGE
PASSENGER
R
LEVEL 2 DFD OF BOOKING

PASSENGER

PASSENGER TICKET(ON THE SPOT)

REQUEST ACKNOLEDGEMENT(STAND BY)

BOOKING
UPDATE PASSENGER

ACKNOWLEDGEMENT
BOOKING
BOOKING BOOKING
NOW COUNTER
LATERUPDATE

STAND BY
ON THE
BOOKING
SPOT

CASH
ENTRY STAND BY DATE
PAYMENT
SET STATUS TO CONFIRM/WAITING
STATUS ACKNOLEDGE
BOOKING
BOOKING

CHOOSE
STATUS(PAID OR NOT)
MODE OF
PAYMENT
DEVIT NUMBER

DEVIT
PAY CASH MODE OF

PAYMENT STATUS
S

T S CREDIT NUMBER

C- T
A
NO A
T
CASH CREDIT

U T

S CHEQUE U
DFD OF CANCELLATION
 PASSENGER

REQUEST FORCANCELLATION ACKNOWLEDGEMENT

UPDATE

CANCELLATION CANCELLATION
SECTION
ACKNOLEDGEMENT

Class Diagram for AIR’s

VALIDITY CHEQUE

VALIDITY
CANCEL
CHEQUE
TICKET
A

C
RESHEDULE
K

REQUEST N CHEQUE
FOR VALID STATUS
O
CANCEL A
NEW
L DATE C
E
K
D

PASSENGER G PASSENGER PASSENGER

E
ALGORITHM
 RESERVATION

• A PERSON COME TO RESERVED ATICKET.

• THEN HE GIVES HIS FULL DETAILS

• IN CUSTOMER FORM THOSE DETAILS WERE WRITTEN.

• THEN COMPUTER CHEQUE THE DATE WHAT DATE THE

PERSON RESER VED

• DATE WISE IT CHEQUE THE FLIGHTS

• IF THE FLIGHT IS FLING THAT DAY

• THEN SYSTEM JUSTIFY THE SPECIFIC FLIGHT ID

• IT CHEQUE ITS SEAT CLASS.

• IF THE PASSENGER WANT TO ECONOMIC CLASS AND

WINDOW SIDE SEAT

• THEN SYSTEM CHEQUE IF THERE ANY SEAT IN ECONOMIC

CLASS WHICH IS INSIDE THE WINDOW

• IF SEAT IS EMPTY THEN SYSTEM RESERVED THE SEAT .

• THEN TICKET IS GENERATED.

• THE TICKET IS CONFIRMED.

 • IF THE CONDITION IS NOT APPLIED THEN IT CHEQUE NEXT
SEAT

• AND JUSTIFIED IT .

• IF IT IS NOT ALSO EMPTY THEN IT CHEQUE NEXT BY NEXT.

• IF THERE IS NO SEAT THEN SYSTEM TAKE TICKET WHICH IS

NOT CONFIRMED

• THEN IT GIVE WAITING LIST.

• END.

CANCELLATION

• A PASSENGER COME TO CANCEL THE TICKET

• THEN THE SYSTEM OPEN THE DELET FORM

• THEN CLICK SHOE COMMAND

• IT DISPLAY ALL THE PASSENGER LIST

• THEN SELECT THE PNR NUMBER AND CLICK DELET OPTION

• THE SYSTEM SHOW RECORD IS DELETED.

WHEN PASSENGER COME TO RESERVED A TICKET THEN SYSTEM
FIND OUT THE FLIGHT DETAILS.

SYSTEM CLICK FLIGHT DETAILS OPTION THEN THE FLIGHT

DETAILS FORM OPEN

THOSE SYSTEM ARE FOLLOWED .

FLIGHT_DETALS:-

• . IN FLIGHT DEAILS WE FIRST CREATE A FORM.

• . THEN WE MAKE ALL TEXT BOX.

• . WE CREATE COMMAN BOX..

• . IN THIS FORM WE ARE USE VARIOUS COMMAND BOX
THOSE ARE

• PREVIOUS,FIRST,NEXT, ADD,NEW,UPDATE, DELETE, SAVE

• . IN THIS FORM WE ADD NEW FLIGHT RECORD AND UPDATE

IT THEN THE

• VALU IS GO TO THE DATABASE.

• .WHEN WE CLICK NEXT , LAST , PREVIOUS, FIRST COMMAND

BUTTON
 • THEN IT SHOW VARIOUS THING SERIALLY.

• A PERSON COME TO KNOW THE TIMMINGS FOR THE FLIGHT

WHICH IS GO

• THEN WE CLICK SHOW COMMAND BUTTON.

CONCESSION

• FIRST IT CLICK THE CONCESSION BOX.

• CONCESSION BOX OPEN

• IT SELCT THE CETEGORI.

• THEN IT IS CALCULATE.

• AND THE FARE IS CALCULATE.

• THEN FINAL FARE IS GENERATE IN TICKET.

TESTING ANALYSIS

BLACKBOX TESTING: The black box testing is used to demonstrate that the
software functions are operational. As the name suggests in black box testing it is
tested whether the input is accepted properly and output is correctly produced. The
major focus o block box testing is on functions, operations, external interfaces,
external data and information.
WHITEBOX TESTING In white box testing the procedural details are closely
examined. In this testing the internals of software are tested to make sure that they
operate according to specifications and designs. Thus major focus of white box
testing is on internal structures, logic paths, control flows, data flows, internal data
structures, conditions, loops, etc

MAINTENANCE

In software engineering the software maintenance is the process of enhancing and

optimizing deployed software as well as remedying defects.

Software maintenance is one of the phases in the software development process

and follows deployment of the software into the field. The software maintenance
phase involves changes to the software in order to correct defects and deficiencies
found during the field usage as well as the addition of new functionality to improve
the software usability and applicability.

CONCLUSION:

When looking for solid AIRLINE RESERVATION SYSTEM

software, you want to find a solution that gives you the easy way of booking ticket.
Naturally, you first want to find the software that meets your needs, both now and
in the future. Engineering is based on designing different projects. Nowadays,”
most products and systems are becoming more complex in nature, and there is an
increasing demand relative to new technology applications at a time when our
natural resources are dwindling” now that’s where engineering jumps in. Business
depending on natural resources is no longer in a safe position. Engineering and
engineers are not only useful for the technologies and machineries in the business
world, but it is also constructive in different components of business such as
entertainment, telecommunication and etc

Database
Class Diagram for Database
Some More DFD's