PROJECT REPORT

ON THE
AIRLINE
RESERVATION
SYSTEM

SUBMITTED TO: PREPARED BY: -

Mrs. Swati Kathuria

Sufyan Haroon
Roll No
228
Akansha Aggarwal
Roll No 232
Bsc(H)Comp.Sc.(IVsem B)

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

inspiration that we have been able to accomplish the task of completing

this project.
We express our sincere thanks to our project mentor MRS. SWATI
KATHURA for their invaluable guidance and frequent suggestions
during the course of the project. Their suggestions helped us to maintain
a good quality of work. We express our deep gratitude to them.
Our special cordial thanks to Computer Science Department, KESHAV
MAHAVIDALYA, DELHI for its earnest efforts and guidance
throughout out project work.
We also thank our lab assistants MISS POOJA CHAWLA and MRS.
RACHNA MEHTA allowing us to work in lab as need and for their
readiness to help us in all our difficulties.

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

Name: Sufyan Haroon

Name: Akansha Aggarwal

Signature of project guide

Name: MRS. SWATI KATHURIA

Designation: Lecturer

TABLE OF CONTENT
Page number

I Software Requirement Document

1. Introduction
1.1 Objective

6-35
7-11
8

1.2 Scope

1.3 Definition And Acronyms

10

1.4 Overview
2. Overall Description

11
12-19

2.1 Product Perspective

4

13-14

2.2 Production Functions

15-16

2.3 User Characteristics

17

2.4 Principle Actors

17

2.5 General Constraints

18

2.6 Assumptions And Dependencies

18

3. Functional Requirements

19-34

3.1 Use cases & Screen Dumps

20-33

3.2 Performance Requirements

34

3.3 Design Constraints

35-36

3.4 Hardware Requirements

37

3.5 Software Requirements

38

3.6 Other Requirements

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

2.2 Data Modeling

47-48

2.2.1 Data Objects &

Their relationships

49

2.2.2 Data Objects & Their attributes 51-52

2.2.3 Data Dictionary

53-63

2.2.4 Entity Relationship Diagram

64

3. Architectural Design

65-72

3.1 Introduction

66

3.2 Data Flow Diagrams (DFDs)

67-71

3.3 Partitioning

72

4. Testing

73-83

4.1 Objective

74-75

4.2 Testing Procedures

76

4.3 Test Plans

77-79

4.4 Cyclomatic Complexity

80-83

SOFTWARE
REQUIREMENT
SPECIFICATION

1. INTRODUCTION

1.1 OBJECTIVE
8

The origin of most software systems is in the need of a client, who

either wants to automate the existing manual system or desires a new
software system. The software system is itself created by the developer.
Finally, the end user will use the completed system. Thus, there are three
major parties interested in a new system: the client, the user, and the
developer. Somehow the requirements for the system that will satisfy the
needs of the clients and the concerns of the users have to be
communicated to the developer. The problem is that the client doesnt
usually design the software or the software development process and the
developer does not understand the clients problem and the application
area. This causes a communication gap between the parties involved in
the development of the project.
The basic purpose of Software Requirement Specification (SRS) is
to bridge this communication gap. SRS is the medium through which the
clients and the users needs are accurately specified; indeed SRS forms
the basis of software development.
Another important purpose of developing an SRS is helping the
clients understanding their own needs. An SRS establishes the basis for
agreement between the client and the supplier on what the software
product will do.
An SRS provides a reference for validation of the final product.
A high quality SRS is a prerequisite to high quality software and it also
reduces the development cost.

1.2 SCOPE
9

"Airline Reservation System is an attempt to simulate the basic

concepts of an online Reservation system. The system enables to
perform the following functions:
SEARCH FOR FLIGHTS
BOOKING OF A SELECTED FLIGHT
PAYMENT
CANCELLATION

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

1.3 DEFINTIONS AND

ACRONYMS
1. DFD :- Data Flow Diagram
2. ERD :- Entity Relationship Diagram
3. SRS :- Software Requirements Specification
4. STD :- State Transition Diagram

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

Hence the airline reservation system is proposed with the following

PRODUCTION PERSPECTIVE:
The computerization of the reservation system will reduce a lot
of paperwork and hence the load on the airline administrative
staff.
The machine performs all calculations. Hence chances of error
are nil.
The passenger, reservation, cancellation list can easily be
retrieved and any required addition, deletion or updation can be
performed.
The system provides for user-ID validation, hence unauthorized
access is prevented.

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

Selection : This function allows a particular flight to be selected

: This function allows the booking agent to search for

flights that are available between the two travel cities, namely the
"Departure city" and "Arrival city" as desired by the traveller. The
system initially prompts the agent for the departure and arrival city,
the date of departure, preferred time slot and the number of
passengers. It then displays a list of flights available with different
airlines between the designated cities on the specified date and
time.

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 :

: It asks for the details of all the

passengers supposed to travel including name, address, telephone
number and e-mail id.
It asks the agent to enter the various credit card
details of the person making the reservation.
1.
2.
3.
4.
5.

Credit card type

Credit card number
CVC number of the card
Expiration date of the card
The name on the card

Cancellation :

The system also allows the passenger to cancel

an existing reservation. This function registers the information
regarding a passenger who has requested for a cancellation of
his/her ticket. It includes entries pertaining to the Flight No.,
Confirmation No., Name, Date of Journey, Fare deducted.

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.

2.4 PRINCIPLE ACTORS

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

 Booking Agents will be having a valid user name an password

to access the software

The software needs booking agent to have complete knowledge

of airline reservation system.

Software is dependent on access to internet.

3. FUNCTIONAL
REQUIREMENTS

20

3.1 USE CASES &

SCREEN DUMPS
USE CASES
1.
Use case ID: - A user/agent wishes to login to the system.
Primary actor: - User/Booking agent.
Pre-condition: - Usernames and passwords must be available
beforehand.

Success End condition: - The main options screen is displayed.

Failed end condition: - User has entered incorrect username or
password or both.

Main success scenario description

1. Select the Log In option from the desktop.
21

2. The following screen is displayed

3. Enter the username and password in the respective input fields.

4. Click the Log In button.
5. The main options screen is displayed.

Scenario extension description

4.a.1 Click the Cancel option.
4.a.2 Desktop screen is displayed
4.b.1 Entered username or password or both are incorrect.

22

4.b.2 System asks to input again correctly, maximum up to 3 times, after

which the system is blocked.

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.

Main success scenario description

1. Select the Reservation option from the main options screen
2. following screen is displayed

23

3. Enter all the information in appropriate input fields

4. Click the Search button
5. A list of all flights that match the given requirements is displayed

Scenario extension description

4.a.1 Select the Cancel button
4.a.2 Main options screen is displayed.
4.b.1 All necessary fields are not displayed.
4.b.2 The input fields are displayed from step2 with the input data and a
note stating that certain required data is missing.

24

3.
Use case ID: - Selecting a flight.
Goal In context: - An agent wishes to select a particular flight from
the list displayed.

Primary actor: - Booking agent.

Pre-condition:- Actor has successfully navigated to the search
results.

Success end condition: - All the selected flight and fair details are
presented.

Failed end condition: - No flight and fair details are presented.

Main success scenario description
1. Select the Search option from the Search the flights screen.
2. Following screen is displayed

25

3. Select the desired flight.

4. Click the Continue button.
5. All the flight and fare details are shown as below.

Scenario extension description

4.a.1 Select the Cancel button
4.a.2 Search results are displayed

26

4.
Use case ID: - Traveller information
Goal in context: - An agent wishes to enter the personal details of
the passenger.

Primary actor: - Booking agent

Pre-condition:- Actor has successfully navigated to the review
details.

Success end condition: - Payment screen is displayed.

Failed end condition: - Payment options screen is not displayed.
Main scenario screen description
1. Select the Continue link form the review screen
2. Following screen is displayed

27

28

3. Enter all the details of each passenger in appropriate input fields.

4. Click the Submit button.
5. Payment options screen is displayed.

Scenario extension description

4.a.1 All necessary fields are not completed
4.a.2 Input fields are displayed from step2 with the input data and a note
stating that certain required data is missing or invalid.
4.b.1 Select the Cancel button.
4.b.2 Review details are displayed.

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.

Main scenario screen description

1. Click the Submit button from the travellers screen
2. Following screen is displayed

30

3. Enter the credit card type, number, etc. in respective fields.

4. Click the Submit button.
5. The message Reservation Successfully made is displayed.

Scenario extension description

4.a.1 All necessary fields are not completed.
4.a.2 Input fields are displayed from step2 with the input data and a note
stating that certain required data is missing or invalid.
4.b.1 Select the Cancel button.
4.b.2 Review details are displayed.

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

2. Actor has successfully navigated to main

option screen.
condition: - The selected reservation has been

cancelled.

Failed end condition: - The selected reservation has not been

cancelled.

Main scenario screen description

1. Select Cancellation from the main options screen.
2. Following screen is displayed.

32

3. Enter the confirmation number and click Submit button.

4. Following screen is displayed which shows the details

33

5. Click the Process cancellation button.

6. The message Reservation successfully cancelled is displayed.

Scenario Extension Description

3.a.1 Click the Cancel button.
3.a.2 Main options screen is displayed.
5.a.1 Click the Cancel button.
5.a.2 Main options screen is displayed.
.
5.b.1 Actor may enter wrong confirmation number.
5.b.2 The message Invalid confirmation number is displayed.

34

3.2 PERFORMANCE
REQUIREMENTS

User friendliness: - The system is easy to learn and

understand. A native user can also use the system effectively,
without any difficulty.

User Satisfaction: - The system is such that it stands up to

the user expectations.

Response Time: - The response of all the operation is good.

This has been made possible by careful programming.

Error Handling: - Response to user errors and undesired

situations has been taken care of to ensure that the system operates
without halting.

Safety and Robustness: - The system is able to avoid or

tackle disastrous action. In other words, it should be foul proof.
The system safeguards against undesired events, without human
intervention.

Portable: - The software should not be architecture specific. It

should be easily transferable to other platforms if needed.

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.

Standard Compliance: - This specifies the requirements

for the standards the system must follow. The standards may
include the report format and accounting properties.

Hardware Limitations :- The software may have to

operate on some existing or predetermined hardware, thus
imposing restrictions on the design. Hardware limitations can
include the types of machines to be used, operating system
available on the system, languages supported and limits on primary
and secondary storage.

Reliability and Fault Tolerance: - Fault tolerance

requirements can place a major constraint on how the system is to
be designed. Fault tolerance requirements often make the system
more complex and expensive. Requirements about system behavior
in the face of certain kinds of faults are specified. Recovery
requirements are often an integral part here, detailing what the
system should do I some failure occurs to ensure certain properties.
36

Reliability requirements are very important for critical

applications.

Security: - Security requirements are particularly significant in

defense systems and database systems. They place restrictions on
the use of certain commands, control access to data, provide
different kinds of access requirements for different people, require
the use of passwords and cryptography techniques and maintain a
log of activities in the system.

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.

Minimum Hardware Requirements

Processor Pentium III
Hard disk drive 40 GB
RAM 1.28 MB
Cache 512 kb

Preferred Hardware Requirements

Processor Pentium IV
Hard disk drive 80 GB
RAM 256 MB
Cache 512 kb

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

 The data design transforms the information domain model created

during analysis into the data structures that will be required to
implement the software.
The architectural design defines the relationship b/w major structural
elements of the s/w 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 ca be applied.
The interface design describes how the s/w communicates within
itself, with systems that interoperate with it, and with humans who
use it.
The component level design transforms structural elements of the s/w
architecture into a procedural description of s/w components.

47

DATA MODELLING
DATA MODELLING answers a set of specific questions that are
relevant to any data processing application. It tells

Primary data objects to be processed

Composition of such data object
Attributes describing each data object
Relationships b/w each data object and other objects.

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.

2.2.1 DATA OBJECTS

AND THEIR
RELATIONSHIPS

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

2.2.2 DATA OBJECTS

AND THEIR
ATTRIBUTES
51

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:-

A passenger boards a flight from the

source of the journey

Description:- A passenger boards a flight from the source

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:-

A flight follows the route to reach the

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:-

Passenger needs the ticket to travel.

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:-

Provides all the necessary information

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:-

Used by customer to make the

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

Where used / how used:-

Makes the reservation or cancellation

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

Where used / how used:Description:-

Planned by the customer/passenger.

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

Where used / how used:-

A customer pays fare to make a

reservation final.

Description:S.No

Field name Data type

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

3.2 DATA FLOW

DIAGRAMS
LEVEL 0 DFD
AGENT

TICKET

AIRLINES
RESERVATION
SYSTEM

ADMINISTRATOR

CUSTOMER

70

LEVEL1 DFD
AGENT

LOGIN DETAILS

RESERVATION DATABASE

LOGIN

RESERVATION

ADMINISTRATOR

CANCELLATION

TICKET

FLIGHT

71

CUSTOMER

LEVEL 2 DFD - LOGIN

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

AIRLINE RESERVATION SYSTEM

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:

SYSTEM TESTING: - System testing is the testing of the

- This is the testing of an individual

module and is usually carried out to ensure the validity of a
particular module.
NOTE: It makes use of white box testing technique.
- Integrated testing is the
testing of the system modules. This is done to identify errors,
which relate to the interaction of different module, which cannot be
found by unit testing but only through an interactive testing.
NOTE: It makes use of black box testing technique.

system against its initial objectives. It is done either in a simulated

environment or in a live environment.

VALIDATION TESTING: -

Validation testing is the

testing where requirement established as part of software

79

requirement analysis are validated against the software that has

been constructed.
NOTE: It makes use of black box testing technique.

4.3 TEST PLANS

S.No Test case

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 spaces may

result in error.
Username &
password in different
case will not be
acceptable.

Using different
date or time format
will result in errors.

 Only one of the

scheduled flights should
be selected at a time.

3.

4.

5.

First, middle, and last

names should be no
more than 20 characters.
Telephone number
Travellers should consist of valid
Information STD code of the area.
E-mail Id should
follow standard format.
Pin code should be of
exactly 6 digits.
Card type should be
Master, Visa or
American Express.
Card number should
be 14, 15 or 16 digits.
Payment
Card number should
either begin with 4, 5 or
3.
Expiration date should
be valid.
Confirmation Confirmation Number
should be automatically
generated.
Confirmation Number
should consist of flight
number & digits.
Tickets should contain
all the relevant
information.
81

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.

Entering card with

leading digit other
than 3, 4 or 5 will not
be acceptable.
Expired card will
not be accepted.

If wrong payment
details are entered,
confirmation number
will not be generated.

 Each ticket should

bear a unique number.

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

1. All the necessary fields

should be set up to search
for flights.

Submit button on search

screen doesnt proceed further
2. All the field entries should until all fields are filled in
correctly.
follow the indicated
format.

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

1. Using the design or code as foundation, draw a corresponding flow

graph.
2. Determine the cyclomatic complexity of the resultant flow graph.
3. Determine the basis set of linearly independent paths.
4. Prepare test cases that will force execution of each path in the basis
set.

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.

Number of Nodes = 19.

Number of edges. = 24.
Number of Predicate Nodes = 6.
Number of Regions = 7.

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