Академический Документы
Профессиональный Документы
Культура Документы
ON THE
AIRLINE
RESERVATION
SYSTEM
ACKNOWLEDGEMEN
T
The project work in this report is an outcome of continual work and
intellectual support from various sources. It is almost impossible to
express adequately the debts owed to many persons who have been
instrumental in imparting this work a successful status. It is however a
matter of great pleasure to express my gratitude and appreciation to all
those people who had helped in completion of this project.
We would like to take the opportunity to thank MRS. SWATI
KATHURIA for giving us an opportunity to work on this project, which
not only has increased our awareness but also has taught the importance
of teamwork, it is because of her guidance, constant encouragement and
CERTIFICATE
This is to certify that this is a record of the project work on AIRLINE
RESERVATION SYSTEM done sincerely and satisfactorily by
SUFYAN HAROON (228) and AKANSHA AGGARWAL (232) in
partial fulfillment of Computer science (H) IV semester of KESHAV
MAHAVIDLAYA, DELHI.
This report has not been submitted for any other examination and does
not form part of any other course undergone by candidate and qualifies
for submission of project evaluation purpose.
Signature of candidate
TABLE OF CONTENT
Page number
6-35
7-11
8
1.2 Scope
10
1.4 Overview
2. Overall Description
11
12-19
13-14
15-16
17
17
18
18
3. Functional Requirements
19-34
20-33
34
35-36
37
38
38
Page Number
II Software Design Documentation
1. Introduction
39-55
40
1.1 Introduction
41
1.2 Scope
42
2. Data Design
43-64
2.1 Introduction
44-46
47-48
49
53-63
64
3. Architectural Design
65-72
3.1 Introduction
66
67-71
3.3 Partitioning
72
4. Testing
73-83
4.1 Objective
74-75
76
77-79
80-83
SOFTWARE
REQUIREMENT
SPECIFICATION
1. INTRODUCTION
1.1 OBJECTIVE
8
1.2 SCOPE
9
OUT OF SCOPE
1. No trip management, hotel bookings, etc.. are included.
2. The function is limited till the issue of tickets. No boarding
passes or other documents are issued.
LIMITATIONS
The administrator is intimidated through the internet about the
changes in the flight schedules. He then, makes the necessary
updation in the database.
10
11
1.4 OVERVIEW
Air transport industry is an area of commerce in which aircraft are
employed to carry passengers, freight and mail etc. Air transport
companies operate scheduled flights and non-scheduled services over
local, regional, national and international routes.
Manually, it is very laborious and slow as well, to generate the seat
assignments, flight scheduling, and aircraft loading hence an automation
system of interaction with airlines reservation is necessitated. Airlines
reservation system originated in the mid-1950s as relatively
unsophisticated internal system to help with tasks (as above said).
Airlines reservation basically includes issuing tickets to passengers
who want to fly to a particular destination a particular day and time.
Thus, the various activities that the airlines reservation encounter
are checking the plane that flies to a particular from a starting point,
checking the availability of seats in that particular flight and to issue the
tickets if the seat is available. Then there is problem of cancellation. If a
passenger for some reason wants to cancel a confirmed ticket, then the
penalty is calculated based on the time the cancellation is made and the
balance amount is refunded. The amount to be refunded is based upon
the airlines cancellation policy.
12
2. OVERALL
DESCRIPTION
13
2.1 PRODUCT
PERSPECTIVE
Before the automation, the system suffered from the following
DRAWBACKS:
The existing system is highly manual involving a lot of paper work
and calculation and therefore may be erroneous. This has lead to
inconsistency and inaccuracy in the maintenance of data.
The data, which is stored on the paper only, may be lost, stolen or
destroyed due to natural calamity like fire and water.
The existing system is sluggish and consumes a lot of time causing
inconvenience to customers and the airlines staff.
Due to manual nature, it is difficult to update, delete, add or view
the data.
Since the number of passengers have drastically increased
therefore maintaining and retrieving detailed record of passenger is
extremely difficult.
An airline has many offices around the world, an absence of a link
between these offices lead to lack of coordination and
communication.
14
15
2.2 PRODUCTION
FUNCTIONS
Booking agents with varying levels of familiarity with computers
will mostly use this system. With this in mind, an important feature of
this software is that it be relatively simple to use. The scope of this
project encompasses:
Search
from the displayed list. All the details of the flight are shown :1.
2.
3.
4.
5.
6.
Flight Number
Date, time and place of departure
Date, time and place of arrival
Flight Duration
Fare per head
Number of stoppages 0, 1, 2
16
Review : If the seats are available, then the software prompts for
the booking of flight. The flight information is shown. The total
fare including taxes is shown and flight details are reviewed.
Traveller Information
Payment :
Cancellation :
17
2.3 USER
CHARACTERISTICS
EDUCATIONAL LEVEL:-At least user of the system should
be comfortable with English language.
TECHNICAL EXPERTISE: - User should be comfortable
using general purpose applications on the computer system.
Booking Agent
Customer/Passenger
Keyboard
Printer
18
Mouse
Internet
2.5 GENERAL
CONSTRAINTS
Software constraints:
The system will run under windows98 or higher platforms of
operating system.
2.6 ASSUMPTIONS
AND DEPENDICIES
19
3. FUNCTIONAL
REQUIREMENTS
20
22
2.
Use case ID: - Search for flights
Goal in context:- Agent/user wishes to search for available flights
b/w 2 cities for the chosen date
Primary actor: - Booking agent
Pre-condition:- Actor has successfully navigated to the main
options screen.
Success end condition: - A list of flights matching the search
criteria is presented.
Failed end condition: - A list of flights matching the search
criteria is not presented.
23
24
3.
Use case ID: - Selecting a flight.
Goal In context: - An agent wishes to select a particular flight from
the list displayed.
Success end condition: - All the selected flight and fair details are
presented.
25
26
4.
Use case ID: - Traveller information
Goal in context: - An agent wishes to enter the personal details of
the passenger.
27
28
29
5.
Use case ID: - Payment
Goal in context: - Agent wishes to finalize the reservation by
taking the payment from customer.
Primary actor: - Booking agent
Pre condition: - Actor has successfully navigated to the payment
screen.
Success end condition: - A reservation has been made.
Failed end condition: - A reservation has not been made.
30
31
6.
Use case ID: - Cancel Reservation
Goal in context: - A customer wishes to cancel a reservation.
Primary actor: - Booking agent
Pre - condition: - 1. A reservation has already been made.
Success end
cancelled.
32
33
34
3.2 PERFORMANCE
REQUIREMENTS
35
3.3 DESIGN
CONSTRAINTS
There are a number of factors in the clients environment that may
restrict the choices of a designer. Such factors include standards that
must be followed, resource limits, operating environment, reliability and
security requirements and policies that may have an impact on the
design of the system. An SRS (Software Requirements Analysis and
Specification) should identify and specify all such constraints.
37
3.4 HARDWARE
REQUIREMENTS
For the hardware requirements the SRS specifies the logical
characteristics of each interface b/w the software product and the
hardware components. It specifies the hardware requirements like
memory restrictions, cache size, the processor, RAM size etc... those are
required for the software to run.
38
3.5 SOFTWARE
REQUIREMENTS
Any window based operating system with DOS support are
primary requirements for software development. Windows XP,
FrontPage and visual basic (V) for making screen dumps are
required.
The systems must be connected via LAN and connection to
internet is mandatory.
3.6 OTHER
REQUIREMENTS
Software should satisfy following requirements as well:
SECURITY
PORTABILITY
CORRECTNESS
EFFICIENCY
FLEXIBILTY
TESTABILTY
REUSABILTY
39
SOFTWARE
DESIGN
DOCUMENTATION
40
1. INTRODUCTION
41
1.1 INTRODUCTION
Software Design sits at the kernel of software engineering and is applied
regardless of the software process model that is used. Beginning once
software requirements have been analyzed and specified, software design is
the first of three technical activities- designs, code, generation and test- that
are required to build and verify the software. Each activity transforms
information in a manner that ultimately results in validated computer
software.
Software design is more creative process rather than analysis coz it
deals with the development of the actual mechanics for a new workable
system. While analyzing, it is possible to produce the correct model of an
existing system. However, there is, no such thing a correct design. Good
design is always system dependent and what is good design for one system
may be bad for another.
A SRS document tells us what a system does, and becomes input to the
design process, which tells us how a software system works. Designing
software system means determining how requirements are realized and result
is a software design document (SDD). Thus the purpose of the design phase
is to produce a solution to a problem given in SRS document.
The flow of information during software design is illustrated in fig1.
Software requirements, manifested by the data, functional and behavioral
models feed the design tasks. Using number of design methods the design
tasks produces a data design, an architectural design, an interface design and
a component design.
42
1.2 SCOPE
The most challenging and creative phase of the system life cycle is
SYSTEM DESIGN. It shows how the software system will be structured to
satisfy the requirements identified in the SRS. It refers to the technical
specifications that will meet the stated requirements. The design
specifications that get generated at the end of this phase are technical in
nature and are the blueprint for the implementation activity.
Thus the scope of SDD encompasses: User interface
Manual procedure
Data base design
Program structure
43
2. DATA DESIGN
44
2.1 INTRODUCTION
The data design transforms the information domain model created
during analysis into the data structures that will be required to implement the
software. The data object and relationships defined in the entity relationship
diagram and the detailed data content depicted in the data dictionary provides
the basis for the data design of software architecture.
Data design also referred as data architecting creates a model of data that
is represented at a high level of abstraction. This data model is then refined
into progressively more implementation specific representation that can be
processed by the computer- based system. The data object defined during
software requirement analysis is modeled using ERD. The data design
translates these elements of the requirements model into data structures at the
software component level and, when necessary, a database architecture at the
application level.
45
COMPONENT
LEVEL
DESIGN
This document
consists of state
transition diagram,
control
specification
document, process
specification.
INTERFACE DESIGN
This document consists of state
transition diagram, control
specification document, process
specification.
ARCHITECTURAL DESIGN
This document in software design document
consists of data flow diagrams and architectural
styles (Data flow architecture).
DATA DESIGN
The data design consists of entity relationship diagram, data
dictionary data structures and data modeling.
46
47
DATA MODELLING
DATA MODELLING answers a set of specific questions that are
relevant to any data processing application. It tells
48
Entity
Relationshi
p
Diagram
Data
Dictionar
y
Data
Flow
Diagra
m
State
Transition
Diagram
At the core of the model lies the data dictionary- a repository that
contains descriptions of all date objects consumed or produced by the
software.
Three different diagrams surround the core.
The entity relation diagram depicts relationships b/w data objects.
ERD is the notation that is used to conduct the data modeling activity.
The data flow diagram serves two purposes:
1. To provide an indication of how data are transformed
as they move through the system
2. To depict the functions that transforms the data flow.
The state transition diagram indicates how the system behaves as a
consequence of external events it represents the behavior of a system
49
by depicting its states and the events that cause the system to change
state.
50
S. No.
Relationship
Participating entities
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Contact
Search
Books
Follows
Departs
Arrives
Boards
Purchase
Owns
Uses
Cancel
Cancel
Plans
Pays
Receives
Customer, agent
Agent, flight
Agent, flight
Flight, route
Flight, airport
Flight, airport
Passenger, flight
Customer, tickets
Customer, credit card
Customer, credit card
Customer, journey
Agent, ticket
Customer, journey
Customer, fare
Agent, fare
S.No.
Entity
Attributes
1.
Passenger
2.
Flight
3.
Airport
4.
Route
5.
Ticket
First name
Last name
Address
Phone no.
e-mail id
gender
Number
Source
Destination
Departure time
Arrival time
Fare
Duration
No. of seats
Status
No. of stoppages
Name
City
State
Id
Id
Departure airport id
Arrival airport id
Distance
Number
Date
Fare
Status
Name
Age
52
6.
Customer
7.
Credit card
8.
Booking agent
9.
Journey
10.
Fare
53
Gender
Address
Class
First name
Last name
Age
Gender
Phone no.
Address
e-mail id
Type
Number
Expiration date
Name
CVC no.
Username
Password
Source
Destination
Duration
Basic
Taxes
No. of passengers
Total
2.2.3
Dictionary
Data
1.
Name :- Passenger
Aliases:- None
Where used / how used:-
S. no
Field name
Data type
Description
1.
First name
Characters
2.
Last name
Characters
3.
Address
.4
Phone no.
Both
characters and
numbers.
Integer
5.
e-mail id
First name of
the passenger
Last name of
the passenger
Residential
address of the
passenger
Phone number
of passenger
e-mail id of the
passenger
6.
Gender
Characters,
numbers and
symbols
One character
long
54
Sex of the
passenger
2.
Name:- Flight
Aliases:- None
Where used / how used:- Passenger travels through the flight
from source to destination.
Description:S.No
Field name
1.
Number
2.
3.
.4
5.
6.
7.
Data type
Description
Both
Number of the
characters and
flight.
numbers
Source
Characters
City from which
the flight
departs.
Destination
Characters
City at which
the flight
arrives.
Departure time
Time
Time at which
flight departs
from the source
airport.
Arrival time
Time
Time at which
flight arrives at
the destination
airport.
Fare
Currency
Amount to be
paid exclusive
of taxes.
Duration
Time
Time the flight
55
8.
No. of seats
Integer
9.
Status
Characters
10.
No. of
stoppages
Integers
56
takes as it takes
off till it lands.
Capacity of the
flight.
Whether the
flight is
scheduled or
cancelled.
The number of
times the flight
stops before
reaching the
destination.
3.
Name:- Airport
Aliases:- None
Where used / how used:- A flight either arrives or departs from
the airport.
Description:S.No
Field name
Data type
Description
1.
City
Characters
2.
State
Characters
3.
Country
Characters
4.
Airport-Id
Both
characters and
numbers.
Name of the
city where the
airport is
situated.
State of the
country of to
which the city
belongs.
Name of the
nation where
the airport is
situated
Unique
identification
number of the
airport.
57
4.
Name:- Route
Aliases:- None
Where used / how used:-
destination.
Description:S.No
Field name
Data type
1.
Route-Id
Both
characters and
numbers.
2.
Departure
airport id
3.
Arrival airport
id
.4
Distance
Description
Unique
identification
number of the
route.
Both
Id of the airport
characters and from where the
numbers.
flight for the
route departs.
Both
Id of the airport
characters and
at which the
numbers.
flight for the
route arrives.
Float
Distance in
kilometers
between the
source and
destination.
5.
58
Name:- Ticket
Aliases:- None
Where used / how used:Description:-
S.No
Field name
1.
Number
2.
Date
3.
Fare
.4
Status
5.
Name
6.
Age
7.
Gender
8.
Address
Data type
Description
Both
Unique
characters and identification
numbers.
number of each
ticket.
Date
Date of
departure of
flight for which
the ticket is
booked.
Currency
Amount that
has been paid
to book the
ticket.
Characters
Whether the
ticket is booked
or cancelled.
Characters
Name of the
passenger.
Integer
Age of the
passenger
One character
Sex of the
long
passenger.
Both
Residential
characters and address of the
numbers.
passenger.
59
9.
Class
Characters
6.
Name: -Customer
60
Whether the
ticket is for
economy or
executive class.
Aliases:- None
Where used / how used:-
to the agent.
Description: S.No
Field name
Data type
Description
1.
First name
Characters
2.
Last name
Characters
3.
Age
Integer
4.
Address
Both
characters and
numbers.
First name of
the passenger
Last name of
the passenger
Age of the
passenger
Residential
address of the
passenger.
5.
Phone no.
Integer
6.
e-mail id
7.
Gender
Characters,
numbers and
symbols
One character
long
7.
Name:- Credit card
61
Phone number
of passenger
e-mail id of the
passenger
Sex of the
passenger
Aliases:- None
Where used / how used:-
payment.
Description:S.No
Field name
Data type
Description
1.
Type
Characters
2.
Number
Integer
3.
Expiration date
Date
.4
Name
Characters
5.
CVC no.
Integer
Type of the
credit card
:Master, Visa
etc.
Number of the
credit card.
Date on which
the card
expires.
Name of the
passenger
Last three
digits on the
back side of the
card.
8.
Name:- Booking agent
Aliases:- None
62
on behalf of customer.
Description:S. no
Field name
Data type
Description
1.
Username
Characters
2.
Password
Characters
User name of
the Booking
agent.
Password
assigned to that
user name.
9.
Name:- Journey
Aliases:- none
63
S.No
Field name
Data type
Description
1.
Source
Characters
2.
Destination
Characters
3.
Duration
Integer
Name of the
city & country
from where the
journey begins.
Name of the
city & country
the journey
ends.
For how many
days the
journey is
scheduled for.
10.
Name:- Fare
Aliases:- None
64
reservation final.
Description:S.No
Description
1.
Basic
Currency
Basic fare to be
paid per head.
2.
Taxes
Float
3.
No. of
passengers
Integer
4.
Total
Currency
Taxes to be
applied to the
basic fare.
Number of
people making
the journey.
Total fare to be
paid for all
heads.
65
2.2.4 ENTITY
RELATIONSHIP
DIAGRAM
66
CREDIT
CARD
TICKET
AIRPORT
purchas
e
arrive
s
depar
ts
cance
l
own
s
book
s
FLIGHT
CUSTOMER
AGENT
contact
s
searc
h
board
s
uses
follo
ws
receive
s
pay
s
plan
s
FARE
canc
el
PASSENGER
ROUTE
JOURNEY
kno
ws
67
3. ARCHITECTURAL
DESIGN
68
3.1 INTRODUCTION
The architectural design defines the relationship between major
structural elements of the software, the design pattern that can be used to
achieve the requirements that have been defined for the system, and the
constraints that affect the way in which architectural design patterns that- can
be applied. The architectural design representation-the framework of the
computer-based system- can be derived from the system specification, the
analysis model and the interaction of sub systems defined within the analysis
model.
69
TICKET
AIRLINES
RESERVATION
SYSTEM
ADMINISTRATOR
CUSTOMER
70
LEVEL1 DFD
AGENT
LOGIN DETAILS
RESERVATION DATABASE
LOGIN
RESERVATION
ADMINISTRATOR
CANCELLATION
TICKET
FLIGHT
71
CUSTOMER
AGENT
READ
INPUT
MAIN OPTIONS SCREEN
ADMINISTRATOR
VERIFY
USERNAME
&
PASSWORD
LOGIN DETAILS
72
ERROR MESSAGE
LEVEL 2 DFD
RESERVATION
AGENT
ADMINISTRATOR
FLIGHTS
SEARC
H
TICKET
DETAILS
SELECT
TRAVELLER
INFORMATION
PAYMENT
CUSTOMER
73
RESERVATION DATABASE
LEVEL 2 DFD
CANCELLATION
AGENT
RESERVATION DETAILS
READ
DETAILS
VERIFY
DETAILS
PROCESS
CANCELLATION
74
CUSTOMER
3.3 PARTIONING
LOGIN
SEARCH
RESERVATION
SELECTION
REVIEW
75
CANCELLATION
TRAVELLER
PAYMENT
INFORMATION
4. TESTING OF THE
DOCUMENT
76
TESTING often accounts for more project than any other software
engineering activity. If it is conducted haphazardly, time is wasted,
unnecessary effort is expended, and even worse, errors sneak through
undetected. It would therefore seem reasonable to establish a systematic
strategy for testing software. The software testing is a critical step of the
software quality assurance and represents the ultimate review of
specification, design and code generation.
4.1 OBJECTIVE OF
SYSTEM TESTING
Once a system has been designed, it is necessary to undergo an
exhaustive testing before installing the system. This is important because
in some cases a small system error, not detect and corrected early before
installation, may explode into a much larger problem later on. Testing is
performed when user is asked to assist in identifying all possible
situations. That might arise as regards the factors that effort was put to
tackle the problem under consideration.
Any engineering product can be tested in one of two ways:
Knowing the specified function that a product has been designed to
perform.
Knowing the internal working of the product.
77
The first test approach is called black box testing and the second, white
box testing.
When computer software is considered, black box testing alludes to
tests that are conducted at the software interface. Although they are
designed to uncover errors, black box tests are used to demonstrate that
software functions are operational, that input is properly accepted and
output is correctly produced, and the integrity of external information is
maintained. A black box test examines some fundamental aspects of a
system with little regard for the internal logical structure of the software.
White box testing of software is predicted on close examination of
procedural detail. Providing test cases that exercise specific conditions
and/or loops tests logical paths through the software.
During development, the software has to pass through a number of
stages. At each of these stages we have the probability of committing
errors. It is actually the inability of humans to communicate with
perfection that introduces a step of quality assurance, which is carried
out after software development. Testing represents the ultimate review of
specification, design and coding.
Testing is carried out with the intent of finding errors, which always
exist in software, no matter how stringent the checks may be. This step
can never show the defects, it can only show their presence.
78
4.2 TESTING
PROCEDURES
There are three testing procedures:
UNIT TESTING:
INTEGRATED TESTING:
VALIDATION TESTING: -
79
1.
2.
Login
Search &
Select
Expected
Requirements
Username should
consist of characters &
numbers.
Username should start
with characters.
Password should start
with characters & must
be exactly 6 characters
long.
Password should not
contain special symbols.
Departure & Arrival
city should be valid.
Departure & Arrival
dates should refer to
future.
Time should be in
am/pm format.
Flight should consist
of letters & digits.
80
Exceptions
Using different
date or time format
will result in errors.
3.
4.
5.
Using spaces in
first, middle or last
names will result in
error.
Use of more than
required number of
digits in telephone
number will result in
error.
If wrong payment
details are entered,
confirmation number
will not be generated.
6.
Valid confirmation
number should be
entered to proceed to
Cancellation cancellation process.
Cancellation of only
future reservation can be
made.
USER
REQUIREMENT
Using flight
number or spaces in
confirmation number
will cause an error.
FULFILLED
REQUIREMENT
82
4.4 CYCLOMATIC
COMPLEXITY
It is software metric that provides a quantitative measure of the logical
complexity of a program. The value computed for cyclomatic
complexity defines the number of independent paths in the basis set of a
program and provide us with an upper bound for the number of test that
must be conducted to ensure that all statements have been executed at
least once.
An independent path must move along at least one edge that has been
traversed before the path is defined.
Cyclomatic complexity (V(G)) can be computed in the following ways.
1. V(G) = Number of Regions.
2. V(G) = Number of edges Number of Nodes + 2.
3. V(G) = Number of Predicate Nodes +1.
Predicate nodes are the decision nodes. They are characterized by two
or more edges emerging from them.
The following steps can be applied to derive the basis set:
83
void login()
{
int correctpwd=0;
int i;
while(correctpwd==0)
{
int correct=0;
while(correct==0)
{
cout<<Enter username;
gets(username);
int flag=0;
for(i=0;i<10;i++)
{
if(username==log[i].user)
flag=1;
if(flag==1)
correct=1;
else
cout<<Invalid;
}
1
}
3
cout<<Enter password;
gets(pwd);
84
1
2
3
4
5
6
7
9
1
0
1
1
1
2
1
5
1
4
if(pwd==log[i].pwd)
correctpwd=1;
else
{
cout<<Invalid password;
correct=0;
}
1
6
1
7
}
}
1
9
85
1
8
1
2
1
9
3
4
5
6
7
8
1
0
1
1
1
2
1
3
1
4
1
6
1
5
1
7
1
8
86
1.
2.
3.
4.
Cyclomatic complexity
1. V(G) = 7.
2. V(G) = 24 -19 +2 = 7.
3. V(G) = 6 + 1 = 7.
Independent paths
P1 : 1 2 19
P2 : 1 2 3 4 5 6 7 9 10 12 13 14 15 16 18 2 ..
P3 : 1 2 3 4 5 6 7 8 9 10 12 13 14 15 16 19
2 - ..
P4 : 1 2 3 4 5 6 7 8 9 11 12 13 14 15 16 18
2 - ..
P5 : 1 2 3 4 5 6 7 8 9 11 12 13 14 15 17 18
2 - ..
P6 : 1 2 3 4 5 6 7 9 11 12 6 ..
P7 : 1 2 3 4 5 6 7 9 11 12 13 4 ..
87