Experiment No.

-1
AIM : Prepare a SRS document in line with the IEEE recommended standards.

AIRLINE RESERVATION SYSTEM

1.0 PROBLEM DEFINITION

Ticket reservation system for airlines has to be developed. The
system developed should contain the following features
1. The system should contain the following features
2. Search for information about the flight by means of flight number and destination
3. While displaying information about the flight it has to provide availability of seats.
4. While reserving tickets the system obtain following information from the user
Passenger Name, Sex, Age, Address.
Credit Card Number, Bank Name.
Flight number, Flight name, Date of Journey and number of tickets to be booked.
5. Based on the availability of tickets, the ticket has to be issued. The ticket issued
should contain the following information –ticket number, flight no, flight name,
date of journey, number of passengers, sex, age and departure time.
6. Cancellation of booked tickets should be available.

2.0 SRS DOCUMENT FOR AIRLINE RESERVATION SYSTEM

2.1 INTRODUCTION
2.1.1 Purpose
2.1.1.1 The purpose of this SRS is to describe the requirements involved in
developing a Airline Reservation system (ARS).
2.1.1.2 The intended audience is any person who wants to reserve or
cancel tickets or to check the availability of Airline tickets
2.1.2 Scope

2.1.2.1 The product is titled Airline Reservation system (ARS).

2.1.2.2 The product will perform the following tasks
2.1.2.2.1 The software that is being developed can be used to check the
availability of the flight tickets for the specified flight, destination and
date of journey
2.1.2.2.2 If the tickets are available to the users needs and specification, then the
software provide a facility to book the tickets.
2.1.2.2.3 If the passengers wants to cancel the tickets, he can use the
cancellation module of the Airline Reservation System.
2.1.3 Definitions, Acronyms and Abbreviations
2.1.3.1 ARS: Airline Reservation System.
2.1.4 References
2.1.4.1 IEEE standard 830-1998 recommended practice for Software
Requirements Specifications-Description.

2.1.5 Overview
2.1.5.1 The SRS contains an analysis of the requirements necessary to help easy
design.
2.1.5.2 The overall description provides interface requirements for the Airline
Reservation system, product perspective, hardware interfaces software
interfaces,, communication interface, memory constraints, product
functions, user characteristics and other constraints.
 2.1.5.3 Succeeding pages illustrate the characteristics of typical naïve users
accessing the system along with legal and functional constraints enforced
that affect Airline Reservation system in any fashion.

2.2 THE OVERALL DESCRIPTION

2.2.1 Product perspective
2.2.1.1 Hardware interfaces
2.2.1.1.1 Hard disk: The database connectivity requires a hardware configuration with a fast
database system running on high rpm hard-disk permitting complete data
redundancy and back-up systems to support the primary goal of reliability.
2.2.1.1.2 The system must interface with the standard output device, keyboard and mouse to
interact with this software.
2.2.1.2 Software interfaces
2.2.1.2.1 Back End: MS Access 2007
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.1.3 Operations
2.2.1.3.1 The user mode enables the end-users to do the end user operations like checking the
availability, reserving and cancelling of flight tickets.
2.2.2 Product Functions
2.2.2.1 Viewing Flight Details
The user must have the access up-to-date information about the flights including
2.2.2.1.1Flight number
2.2.2.1.2 Flight Name
2.2.2.1.3 Flight route(Start and Destination stations)
2.2.2.1.4 Flight timings
2.2.2.1.5 Seat availability.
2.2.2.2 Reserving Tickets
The user must be able to reserve tickets after selecting
2.2.2.2.1Flight number
2.2.2.2.2 Flight Route
2.2.2.3 Cancelling Tickets
The user must be able to cancel tickets that he has earlier reserved by quoting the ticket number,
credit card number and bank name.
2.2.3 User characteristics
2.2.3.1 The intended users of this software need not have specific knowledge as to what is the
internal operation of the system. Thus the end user is at a high level of
abstraction that allows easier, faster operation and reduces the knowledge
requirement of end user
2.2.3.2 The Product is absolutely user friendly, so the intended users can be the naïve users.
2.2.3.3 The product does not expect the user to possess any technical background. Any person
who knows to use the mouse and the keyboard can successfully use this
product.
2.2.4 Constraints
At the time of reservation, each user is provided a unique ticket number that must be used for further
operation like cancellation. Hence the user is required to remember or store this number
2.3 SPECIFIC REQUIREMENTS
2.3.1 Logical Database Requirements
2.3.1.1 The system should contain databases that include all necessary information for the
product to function according to the requirements. These include relations such as
flight details, reservation details, and cancellation details.
2.3.1.2 The user details refer to the information such as flight number and name, start and
destination stations, seat availability.
2.3.1.3 Reservation details refer to personal information that is obtained from the user
2.3.1.4 At the time of reservation, the passenger is provided a unique ticket no that could be
 used at the time of cancellation.
2.3.1.5 While displaying any information about the flight it has to provide the following
information
Flight no and name
Availability of seats for the particular flight
The flight timing
The passenger personal details should be obtained for reserving the tickets.

2.4 FRONT – END DESCRIPTION

The front-end for the Airline Reservation system (ARS) is designed using Microsoft
Visual Basic 6.0. The front-end contains a user- friendly interface. The first form contains a
welcome screen that provides an option for the user to select one of the following
Enquiry
Reservation
Booking details
Cancellation
In the Enquiry form the user can get details of the flight by means of either flight name
destination or date 0of journey. In the reservation form, there can book details by entering the
personal details. The ticket is displayed with details about the flight name and number, number
of passengers, ticket number, sex and age. The cancellation form helps the user to cancel a
ticket, which he had booked earlier.

2.5 BACK – END DESCRIPTION

The Airline Reservation system consists of two tables. One contains the flight details
such as the flight name, flight number, destination, date of journey and seats available in each
class that is referred to during enquiry. The other table has the passenger details such as name,
age, sex, credit card number, and bank name. This table is referred to at the time of reservation
or cancellation.

2.6 DATA STRUCTURES

2.6.1. FLIGHT DETAILS

FIELD NAME TYPE CONSTRAINTS
ROUTE_NAME TEXT NOT NULL
FLIGHT_NO NUMBER NOT NULL
SEATS_AVAIL NUMBER
JOURNEY_DATE DATE/TIME
DEP_TIME DATE/TIME
ARR_TIME DATE/TIME
COST NUMBER
2.6.2. PASSENGER DETAILS

FIELD NAME TYPE CONSTRAINTS

TICKET_NO AUTONUMBER NOT NULL
NAME TEXT NOT NULL
GENDER TEXT
ADDRESS TEXT
CC_NO NUMBER NOT NULL
BANK_NAME TEXT
NO_OF_TICKETS NUMBER

2.7 DATA FLOW DIAGRAM

3.0 TESTING:

FORM NAME INPUT EXPECTE ACTUAL STATUS

D OUTPUT OUTPUT
MAIN MENU FORM Menu Required Required Pass
Option Form must form was
be displayed displayed.
TICKET Flight route Flight seats Flight seats Pass
AVAILABILITY or Flight availability availability
FORM name must be are
displayed displayed.
RESERVATION Personal Ticket must Ticket was Pass
FORM details were be booked booked and
entered. and database database was
updated. updated.
CANCELLATION Ticket Ticket must Ticket was Pass
FORM number was be cancelled cancelled
entered. and database and database
must be was
updated. updated..
4.0 SAMPLE FORMS
5.0 RESULT
Thus the online Airline Reservations System was implemented using the specified front end
and backend tools.

8
 Experiment No.-2
AIM: Draw the use case diagram and specify the role of each of the actors. Also state the
precondition,post condition and function of each use case.

CASE Tool: StarUML

Use_Case Diagram:
The book bank use cases are:
1. book_issue

2. book_return

3. book_order

4. book_entry

5. search book_details

Actors Involved:
1. Student
2. Librarian
3. Vendor

Usecase Name : Search Book_Details

The librarian initiates this use case when any member returns or request the book and
checking if thebook is available.
Precondition: The librarian should enter all Book details.
Normal Flow: Build message for librarian who search the book.
Post Condition: Send message to respective member who reserved the book.

9
Usecase Name : Book_ Issue
Initiated by librarian when any member wants to borrow the desired book. If the book is
available,the book is issued.
Precondition: Member should be valid member of library.
Normal Flow: Selected book will be issued to the member.

Alternative Flow: If book is not available then reserved book use case should be initiate.
PostCondition: Update the catalogue.

Usecase Name : Book_Order

Initiated by librarian when the requested book is not available in the library at that moment.
The bookis reserved for the future and issued to the person when it is available.
Precondition: Initiated only when book is not available.
Normal Flow: It reserved the book if requested.
Post Condition : Mention the entry in catalogue for reservation.

Usecase Name : Book_Return

Invoked by the librarian when a member returns the book.
Precondition: Member should be valid member of library.
Normal Flow: Librarian enters book id and system checks for return date of the book. Alternative
Flow: System checks for return date and if it returned late fine message will be displayed.
Post Condition: Check the status of reservation.

Usecase Name : Book_Entry

The purchase book use-case when new books invoke it or magazines are added to the library.
Precondition: Not available or more copies are required.
Normal Flow: Enter bookid,author information, publication information, purchased
date, prize andnumber of copies.

Post Condition: Update the information in catalogue.

10
11
Figure 1. Usecase diagram for Book Bank System

12
 Experiment No.-3
AIM: Draw the ER Diagram

ER Diagram

ER Model is represented by means of an ER diagram. Any object, for example, entities,

attributes of an entity, relationship sets, and attributes of relationship sets, can be represented
with the help of an ER diagram.

Entity
Entities are represented by means of rectangles. Rectangles are named with the entity set
they represent.

Attributes

Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle). If the
attributes are composite, they are further divided in a tree like structure. Every node is then
connected to its attribute.

Composite attributes are represented by ellipses that are connected with an ellipse.

Multivalued attributes are depicted by double ellipse.

Derived attributes are depicted by dashed ellipse.

Binary Relationship and Cardinality

A relationship where two entities are participating is called a binary relationship. Cardinality
is the number of instance of an entity from a relation that can be associated with the relation.

One-to-one − When only one instance of an entity is associated with the relationship,
it is marked as '1:1'. The following image reflects that only one instance of each entity
should be associated with the relationship. It depicts one-to-one relationship.

One-to-many − When more than one instance of an entity is associated with a

relationship, it is marked as '1:N'. The following image reflects that only one instance

13
 of entity on the left and more than one instance of an entity on the right can be
associated with the relationship. It depicts one-to-many relationship.
Many-to-one − When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.

Many-to-many − The following image reflects that more than one instance of an entity
on the left and more than one instance of an entity on the right can be associated with
the relationship. It depicts many-to-many relationship.

Participation Constraints

Total Participation − Each entity is involved in the relationship. Total participation is

represented by double lines.

Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.

14
15
16
17
 Experiment No.-4
AIM: Draw the activity diagram.

Activity Diagram

Activity diagrams are mainly used as a flow chart consists of activities performed by the
system. But activity diagram are not exactly a flow chart as they have some additional
capabilities. These additional capabilities include branching, parallel flow, swimlane etc.

Before drawing an activity diagram we must have a clear understanding about the elements
used in activity diagram. The main element of an activity diagram is the activity itself. An
activity is a function performed by the system. After identifying the activities we need to
understand how they are associated with constraints and conditions.

The following is an example of an activity diagram for order management system. In the
diagram four activities are identified which are associated with conditions. One important
point should be clearly understood that an activity diagram cannot be exactly matched with
the code. The activity diagram is made to understand the flow of activities and mainly used
by the business users.

The following diagram is drawn with the four main activities:

Send order by the customer

Receipt of the order

Confirm order

Dispatch order

After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.

18
19
20
 Experiment No.-5
AIM : Identify the classes. Classify them as weak and strong classes and draw the class
diagram.

Class Diagram

The class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing and documenting different aspects of a
system but also for constructing executable code of the software application.

The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modelling of object oriented
systems because they are the only UML diagrams which can be mapped directly with object
oriented languages.

The class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. It is also known as a structural diagram.

Class diagram is basically a graphical representation of the static view of the system and
represents different aspects of the application. So a collection of class diagrams represent the
whole system.

Now the following diagram is an example of an Order System of an application. So it describes

a particular aspect of the entire application.

First of all Order and Customer are identified as the two elements of the system and
they have a one to many relationship because a customer can have multiple orders.

We would keep Order class is an abstract class and it has two concrete classes
(inheritance relationship) SpecialOrder and NormalOrder.

The two inherited classes have all the properties as the Order class. In addition they
have additional functions like dispatch () and receive ().

21
So the following class diagram has been drawn considering all the points mentioned above:

22
23
 Experiment No.-6
AIM : Draw the sequence diagram for any two scenarios.

Sequence Diagram

The Sequence Diagram models the collaboration of objects based on a time sequence. It shows
how the objects interact with others in a particular scenario of a use case. With the advanced
visual modeling capability, you can create complex sequence diagram in few clicks. Besides,
Visual Paradigm can generate sequence diagram from the flow of events which you have
defined in the use case description.

24
ATM System

25
 Experiment No.-7
AIM : Draw the collaboration diagram.

Collaboration Diagram

Collaboration diagrams (interaction diagrams) illustrate the relationship and interaction

between software objects. They require use cases, system operation contracts, and domain
model to already exist. The collaboration diagram illustrates messages being sent between
classes and objects (instances). A diagram is created for each system operation that relates to
the current development cycle (iteration).

When creating collaboration diagrams, patterns are used to justify relationships. Patterns are
best principles for assigning responsibilities to objects and are described further in the section
on patterns. There are two main types of patterns used for assigning responsibilities which are
evaluative patterns and driving patterns.

Each system operation initiates a collaboration diagram. Therefore, there is a collaboration

diagram for every system operation. An example diagram for purchasing a bus ticket.

26
27
 Experiment No.-8

AIM: Draw the state chart diagram.

State Chart Diagram

A Statechart diagram describes a state machine. Now to clarify it state machine can be defined
as a machine which defines different states of an object and these states are controlled by
external or internal events.

hey define different states of an object during its lifetime. And these states are changed by
events. So Statechart diagrams are useful to model reactive systems. Reactive systems can be
defined as a system that responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered.
So the most important purpose of Statechart diagram is to model life time of an object from
creation to termination.

Statechart diagrams are also used for forward and reverse engineering of a system. But the
main purpose is to model reactive system.

The following is an example of a Statechart diagram where the state of Orderobject is

analyzed.

The first state is an idle state from where the process starts. The next states are arrived for
events like send request, confirm request, and dispatch order. These events are responsible
for state changes of order object.

During the life cycle of an object (here order object) it goes through the following states and
there may be some abnormal exists also. This abnormal exit may occur due to some problem
in the system. When the entire life cycle is complete it is considered as the complete
transaction as mentioned below.

28
The initial and final state of an object is also shown below.

29
 Experiment No.-9
AIM : Draw the component diagram.

Component Diagram

Component diagrams are different in terms of nature and behaviour. Component diagrams are
used to model physical aspects of a system. Component diagram is a special kind of diagram
in UML. The purpose is also different from all other diagrams discussed so far. It does not
describe the functionality of the system but it describes the components used to make those
functionalities. They can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment.

The following is a component diagram for order management system. Here the artifacts are
files. So the diagram shows the files in the application and their relationships. In actual the
component diagram also contains dlls, libraries, folders etc.

In the following diagram four files are identified and their relationships are produced.
Component diagram cannot be matched directly with other UML diagrams discussed so far.
Because it is drawn for completely different purpose.

30
So the following component diagram has been drawn considering all the points mentioned
above:

31
 Experiment No.-10
AIM: Draw the deployment diagram

Deployment Diagram

The name Deployment itself describes the purpose of the diagram. Deployment diagrams are
used for describing the hardware components where software components are deployed.
Component diagrams and deployment diagrams are closely related.

Component diagrams are used to describe the components and deployment diagrams shows
how they are deployed in hardware.

The following deployment diagram is a sample to give an idea of the deployment view of
order management system. Here we have shown nodes as:

Monitor

Modem

Caching server

Server

32
33
 Experiment No.-11
AIM: Draw the Data Flow Diagram.

DFD

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an

information system. DFDs can also be used for the visualization of data processing (structured
design). On a DFD, data items flow from an external data source or an internal data store to an
internal data store or an external data sink, via an internal process.

A DFD provides no information about the timing or ordering of processes, or about whether
processes will operate in sequence or in parallel. It is therefore quite different from a flowchart,
which shows the flow of control through an algorithm, allowing a reader to determine what
operations will be performed, in what order, and under what circumstances, but not what kinds
of data will be input to and output from the system, nor where the data will come from and go
to, nor where the data will be stored (all of which are shown on a DFD).

It is common practice to draw a context-level data flow diagram first, which shows the
interaction between the system and external agents which act as data sources and data sinks.
On the context diagram (also known as the Level 0 DFD) the system's interactions with the
outside world are modeled purely in terms of data flows across the system boundary. The
context diagram shows the entire system as a single process, and gives no clues as to its internal
organization.

This context-level DFD is next "exploded", to produce a Level 1 DFD that shows some of the
detail of the system being modeled. The Level 1 DFD shows how the system is divided into
sub-systems (processes), each of which deals with one or more of the data flows to or from an
external agent, and which together provide all of the functionality of the system as a whole.

34
Context Diagram

35
Level-1 DFD

36
37
Level-2 DFD of Login

38
Level-2 DFD of User account
Maintenance

Level-2 DFD of Student information management

39
Level-2 DFD of Subject information management

40