Embed Size (px)
Citation preview
DESIGN PROBLEM
Airways Reservation System
SUBMITTED TO:
MONA LISA MAM
2010
SUBMITTED BY :
ANJANI KUNWAR
RA1803A10
10807973
B.TECH(CSE)-H
SOFTWARE ENG CONCEPT AND TOOL
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 1st and 2nd level DFDs.4.Design Class Diagram for Database5.Write the Stored Procedure also.
CONTENTS
1:Overview 1.1:Need of Airlines system 1.2: Feasibility2:Analysis3: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:Cancellation4:Performance 4.1:Reliability 4.2:Usability 5:Software Product Feature 5.1:Associated Fuctionality requirement 5.2:Associated Fucntional Requirement 5.3: Performance Requirement6:Database Design
7:Contents 7.1:Inventory Management 7.2:Availability Display and Reservation (PNR) 7.3:Fare Quote and Ticketing8:Report Module9:Block Diagram of ARS10:Overall UML Structure11: E-R Diagram 11.1:For Booking Department 12.2:For Cancellation12:Data Flow Diagram 12.1:Context Diagram 12.2:Level 0 DFD 12.3:Level 1 DFD 12.4:Level 2 DFD13:Algorithm14:Testing Analysis15:Class Diagram for Database16: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 system1) Faster System2) Accuracy3) Reliability4) Informative5) Reservations and cancellations from any where to any place
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.
AIRLINE SYSTEM
CANCELLATIONRESERVATION
UPDATION
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 TicketA 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.
CancellationThe 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.
PerformanceResponse 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
ReliabilityARS 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.
InteroperabilityARS 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 user like pin code, personal details, flight details
Source of Input
Printer To print the bookings mode E.g.: Destination chosen with date and timings
Destination of Output
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 ARRCITYARRPORT ARRTIME AIRLINE ECPRICE ECSEATSBSPRICE 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 flights. A ticket can be booked to a maximum of five just by entering the passenger name, age and their details.
MODULE 5:EXIT
This module is used to exit from the reservation form.
BLOCKDIAGRAM
AIRLINE
RESERVATION
SYSTEM
database
REPORTS
Ticket reservation
Cancellation,
Request for enquiry
Passenger list,
Fleet info
concession
Flight information,
Fare details,
PASSENGER
BOOKING
DEPARTMENT
FLIGHT MAINTAINENCE BOOKING ,CANCELLATION
RECEIVE
CUSTOMER
REQUEST
DATA STIRAGE DATA ACCESS
PASSENGER
LIST
CONFIRMED
LISTWAITING LIST
CANCELLATION
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
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.
TEL_NO
D_O_B
PNR
NAME
FLIGHT NUM
_NUM
DATE OF DEP
ROUTE
ADDRESS
STATUS
PASSENGER
CONFIRM VALID ?WAITING
BOOKING 1(ON THE SPOT)
NAMEPNR
MODE OF PAYMENT
CASHCHEQUE
DEBIT
CREDITPNR
FARE
CASH PAIDSTATUS
PNR
FARE
STATUS
PAID
PNR
FARE
D NO STATUS
STATUS
FARE
C NOPNR
BOOKING 2(ON THE SPOT)
STAND
BY DATE
BOOKINGDATE
PNR
NAME
TEL_NO
E-R DIAGRAM FOR CANCELLATION
ADDRESS
NAME
Passenger
PNR
TEL_NUM D_O_B FLIGHT_IDT_DATE
ROUTE
STATUS
SEAT
AVAILABLE
?
FLIGHTS
ARRIVAL
DEPARTURE
SEAT
FLIGHT_NUM
COST_ECO
COST_EXE
SEATS_ECO
SEATS_EXE
CANCEL
?
CANCEL
PNR
NAME
T_DATE
D_CANCELSTATUS
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. OutputThe 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
1
2
3
Reservation
System
Booking System
Passenger
User Airline reservation System
Display
Cancellation
Reservation
LEVEL 0 DATA FLOW DIAGRAM
REQUEST FOR INFORMATIONFLIGHT/FARE/DISCOUNT
LEVEL1 DATA FLOW DIAGRAM OF GENERAL ENQUIRY SYSTEM
PASSENGER
1.0
GENERAL
ENQUIRY
3.0
BOOKING
COUNTER
4.0
CANCELLATION
2.0
PASSENGER
ENQUIRY
BOOKING
ENQUIRY
NEW PNR INFORMATION
RESERVATION REQUEST
TICKET CONFIRMATION &STATUS
CANCELLATION REQUEST
ACKNOWLEGMENT
INFORMATION
PASSENGER
REQUIRED INFOR MATION
REQUEST FOR INFOR MATION
1.0
GENERAL
ENQUIRYR
E
Q
U
E
S
T
1.3
DISCOUNT
I
N
F
O
R
M
A
T
I
O
M
1.2
FARE
ENQUIRY
1.1
FLIGHT
ENQUIRY
R
E
Q
U
E
S
T
I
N
F
O
R
M
A
T
I
O
N
R
E
Q
U
E
S
T
I
N
F
O
R
M
A
T
I
O
N
RI
R I R I
FLIGHT FARE DISCOUNT
DATA FLOW DIAGRAM OF PASSENGER ENQUIRY SECTION
LEVEL 2 DFD OF BOOKING
PASSENGER
NEW PNR OR REQUIRED INFORMATIONENTRY OF NEW RECORD OR EXISTING
PASSENGER ENQUIRY
PASSENGER
ENQUIRY
2.2
PASSENGER
ENQUIRY
NEW
PASSENGER
R UNIQUEPNR
R INFORMATION
R
E
Q
U
E
S
T
U
N
I
Q
U
E
P
N
R
R
E
Q
U
E
S
T
I
N
F
O
PASSENGER PASSENGER
BOOKING
PASSENGER
BOOKING
COUNTERBOOKING NOW
ACKNOWLEDGEMENT
BOOKING
LATERUPDATE
PASSENGER
REQUEST
TICKET(ON THE SPOT)
ACKNOLEDGEMENT(STAND BY)
ON THE
SPOT
STAND BY
BOOKING
BOOKING
SET STATUS TO CONFIRM/WAITINGCASH PAYMENT
STATUS
MODE OF
PAYMENT
STATUS(PAID OR NOT)CHOOSE MODE OF PAYMENT
ENTRY STAND BY DATE
ACKNOLEDGE
DEVIT NUMBER
STATUS
CREDIT NUMBER
S
T
A
T
U
S
CREDIT
CHEQUE
CASH
PAY CASH
S
T
A
T
U
S
C-
NO
BOOKING
DEVIT
UPDATE PASSENGER
DFD OF CANCELLATION
VALIDITY CHEQUE
PASSENGER
ACKNOWLEDGEMENTREQUEST FORCANCELLATION
CANCELLATION SECTION
CANCELLATION
UPDATE
ACKNOLEDGEMENT
VALIDITY
CHEQUECANCEL
TICKET
RESHEDULE
A
C
K
N
O
L
E
D
G
E
REQUESTFOR
CANCEL
PASSENGER
A
C
K
NEWDATE
PASSENGERPASSENGER
STATUSCHEQUEVALID
Class Diagram for AIR’s
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
