Unified Modeling Language Documentation For

Airlines Reservation System

UML Project Report,

MCA 4th Semester.

Prepared By:

Mahesh Godse (216).

Subhash Vanjale (255).
Rahul Lavate (261).
 Table of Contents
1. SCOPE 3
1.1 AUDIENCE 3
1.2 ORGANIZATION 3
2. SYSTEM REQUIREMENTS SPECIFICATION 4
3. ACTIVTY DIAGRAM 5
3.1 ACTIVITY DIAGRAM FOR AIRLINES RESERVATION SYSTEM 6
4. USE CASE DIAGRAM 7
4.1 USE CASE DIAGRAM FOR AIRLINES RESERVATION SYSTEM 8
4.2 USE CASE DIAGRAM FOR USER REGISTRATION 8
4.3 USE CASE DIAGRAM FOR MEMBER LOGIN 9
4.4 USE CASE DIAGRAM FOR FLIGHT RESERVATION 9
4.5 USE CASE DIAGRAM FOR FLIGHT CANCELLATION 10
4.6 USE CASE DIAGRAM FOR AIRLINE ADMINISTRATION 10
5. UML INTERACTION DIAGRAMS 11
5.1 SEQUENCE DIAGRAMS 11
5.1.1 SEQUENCE DIAGRAM FOR USER REGISTRATION 12
5.1.2 SEQUENCE DIAGRAM FOR MEMBER LOGIN 12
5.1.3 SEQUENCE DIAGRAM FOR FLIGHT RESERVATION 13
5.1.4 SEQUENCE DIAGRAM FOR FLIGHT CANCELLATION 14
5.1.5 SEQUENCE DIAGRAM FOR AIRLINE ADMINISTRATION 15
5.2 COLLABORATION DIAGRAMS 16
5.2.1 COLLABORATION DIAGRAM FOR USER REGISTRATION 16
5.2.2 COLLABORATION DIAGRAM FOR MEMBER LOGIN 17
5.2.3 COLLABORATION DIAGRAM FOR FLIGHT RESERVATION 17
5.2.4 COLLABORATION DIAGRAM FOR FLIGHT CANCELLATION 18
5.2.5 COLLABORATION DIAGRAM FOR AIRLINE ADMINISTRATION 18
6. CLASS DIAGRAM 19
6.1 CLASS DIAGRAM FOR AIRLINES RESERVATION SYSTEM 20
7. STATE TRANSITION DIAGRAM 21
7.1 STATE TRANSITION DIAGRAM FOR AIRLINES RESERVATION SYSTEM 22

8. COMPONENT DIAGRAM 23
8.1 COMPONENT DIAGRAM FOR AIRLINES RESERVATION SYSTEM 23
9. DEPLOYMENT DIAGRAM 24
9.1 DEPLOYMENT DIAGRAM FOR AIRLINES RESERVATION SYSTEM 24
1. Scope :
1.1 Audience :
The intended users are the customers and the administrators who use the Airlines
Reservation System.

1.2 Organization :
This document describes the Airlines Reservation System requirements in terms of
system requirement, executive summary and analysis and design diagrams.
The scope of this project work is to draw and describe the UML diagrams for the
application Airlines Reservation System.
2. Software Requirement Specification:

System Abstract
The Airlines Reservation system facilitates the user to view the flight schedules, inquire about
the flight details, availability of seats and many more.
The major functionality of system is to allow the user to book and cancels the flights as per user
requirements.
It also provides the administrator or manager to modify existing flights or to introduce new
flights in the schedule.

Major features provided by the system are:

Flight Enquiry
The system allows the user or member to perform flight inquiry including flight scheduling,
seats availability status, fare details, etc.

User Registration
It allows the user to register in order to be a member of the organization. User is then granted
a privilege to book or cancels flights.

Flight Reservation
The system allows the member to book the flights as per his/her requirements. The member
is prompt to enter the passenger details and credit card details. The member then receives the
unique PNR No. and E-ticket.
Flight Cancellation
The functionality is used by the member to cancel an existing reservation made by the
member earlier.

Administration
The administration module of the system allows the admin/manager to manage the flight
scheduling. It provides the admin /manger to modify or change the existing flights or to
introduce a new flights. Apart from scheduling it also allow the admin/manager to generate
report of daily or weekly transactions based on requirements.
3. Activity Diagram:
Activity diagram models the logic from workflow to use cases to methods. It borrows most
of the notations from the flowchart but has added the concept of concurrency to support
many modern applications. The arrow traces the flow from beginning to end through decision
and loops, while identifying each logic steps in the process.
Activity diagrams are typically used for business process modeling, for modeling the logic
captured by a single use case or usage scenario, or for modeling the detailed logic of a
business rule. Although UML activity diagrams could potentially model the internal logic of
a complex operation it would be far better to simply rewrite the operation so that it is simple
enough that you dont require an activity diagram. In many ways UML activity diagrams are
the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured
development.
The easiest way to visualize an Activity diagram is to think of a flowchart of a code. The
flowchart is used to depict the business logic flow and the events that cause decisions and
actions in the code to take place.
Activity diagrams represent the business and operational workflows of a system. An Activity
diagram is a dynamic diagram that shows the activity and the event that causes the object to
be in the particular state.
So, what is the importance of an Activity diagram, as opposed to a State diagram? A State
diagram shows the different states an object is in during the lifecycle of its existence in the
system, and the transitions in the states of the objects. These transitions depict the activities
causing these transitions, shown by arrows.
An Activity diagram talks more about these transitions and activities causing the changes in
the object states.
Activity diagrams are useful because:

1. They represent the logic required to implement system behaviors.

2. They are simple enough to learn quickly.
3. Represents the logic at any level the design needs, from system workflow to
individual method implementation.
Fig: 3. Activity Diagram for Airlines Reservation System
4. USE CASE DIAGRAM :

Use case diagrams are helpful in three areas.

Determining features (requirements). New use cases often generate new requirements as
the system is analyzed and the design takes shape.
Communicating with clients. Their notational simplicity makes use case diagrams a good
way for developers to communicate with clients.
Generating test cases. The collection of Diagrams for a use case may suggest a suite of test
cases for those Diagrams.

The various use-case Diagrams for the system are as shown in below diagram.

Actor in Use-Case Diagram:

User - User in the system enquiry about flight details and register to become a member
and make reservation and cancellation.
Member - Member within the system make reservation to book flight or perform cancellation
and print ticket.
Admin - Admin/manager generates report and update the flight schedule.

Use-case in the system:

Registration - Allow user to register to create an account so user can make reservation and
cancellation.
Enquiry - Allow user to enquire about seat availability status, flight schedule and fare
details.
Login - Allow member to login to access the account.
Reservation - Member make reservation by entering flight details, passenger details to book
ticket.
Cancellation - Member make cancellation by updating passenger details or reservation
details.
Print Ticket - Allow member to print ticket presenting details about journey.
Credit Card Processing - Credit card processor process the transaction provided by the credit
card holder.
Credit Card Validation - Allow credit card processor to validate the credit card details.
Edit Flight Details - Allow admin/manager to update the flight details.
Report Generation - Allow admin to generate report based on requirements.
Fig: 4.1 Use Case Diagram for Airlines Reservation System

Fig: 4.2 Use Case Diagram for User Registration

 Fig: 4.3 Use Case Diagram for Member Login

Fig: 4.4 Use Case Diagram for Flight Reservation

 Fig: 4.5 Use Case Diagram for Flight Cancellation

Fig: 4.6 Use Case Diagram for Airline Administration

5. UML Interaction Diagram (Sequence And Collaboration Diagram) .
Interaction diagrams describe the communication between objects to accomplish some task
such as placing an order. In UML the two types of interaction diagrams are sequence diagram
and collaboration diagram. These diagrams model the dynamic aspects of the system.

5.1 Sequence Diagrams

Sequence diagram is one kind of interaction diagrams, which shows an interaction among a
set of objects and their relationships. The purpose of the Sequence diagram is to document
the sequence of messages among objects in a time based view. The scope of a typical
sequence diagram includes all the message interactions for a single use case.
Sequence Diagrams are valuable because:

1. They have a narrow focus that helps us to see the specific questions, commands and
data communicated during the execution of a specific task.
2. They explicitly identify the communication required to fulfill an interaction. They
help us to identify the interfaces required by the classes.
3. They identify the objects that take part in the interaction. They help us to validate the
features of a class.
4. They identify the data passed as part of the interaction.
Fig.5.1 Sequence Diagram for User Registeration

Fig.5.2 Sequence Diagram for Member Login

Fig.5.3 Sequence Diagram for Flight Reservation
Fig.5.4 Sequence Diagram for Flight Cancellation
Fig.5.5 Sequence Diagram for Airline Administration
5.2 Collaboration Diagrams

Collaboration diagram is very similar to a Sequence diagram in the purpose it achieves; in

other words, it shows the dynamic interaction of the objects in a system. A distinguishing
feature of a Collaboration diagram is that it shows the objects and their association with other
objects in the system apart from how they interact with each other. The association between
objects is not represented in a Sequence diagram.
A Collaboration diagram is easily represented by modeling objects in a system and
representing the associations between the objects as links. The interaction between the
objects is denoted by arrows. To identify the sequence of invocation of these objects, a
number is placed next to each of these arrows.

Collaboration diagrams are valuable because:

1. Shows the structural requirement for completing a task. They identify the objects that
participate in an interaction.
2. Shows the interface requirement for a particular class.
3. Identify the data that is passed as a part of the interaction.

Fig.5.6 Collaboration Diagram for User Registration

 Fig.5.7 Collaboration Diagram for Member Login

Fig.5.8 Collaboration Diagram for Flight Reservation

 Fig.5.9 Collaboration Diagram for Flight Cancellation

Fig.5.10 Collaboration Diagram for Airline Administration

6. Class Diagram

Class diagram, one of the most commonly used diagrams in object-oriented system, models
the static design view for a system. The static view mainly supports the functional
requirements of a system the services the system should provide to the end users. We will
see from our practical experience that lots of fun comes out when modeling out system with
class diagrams.

A class diagram shows a set of classes, interfaces, and collaborations and their relationships.
Class diagrams involve global system description, such as the system architecture, and detail
aspects such as the attributes and operations within a class as well. The most common
contents of a class diagram are:

1. Classes
2. Interfaces
3. Collaborations
4. Dependency, generalization, and association relationships
5. Notes and constraints

The class diagram models the definition of resources of the system. The class diagram is the
source for code generation and the target for reverse engineering.

A class diagram is valuable because:

1. It defines the essential resources of a system.

2. It defines the structure and behavior of the system.
3. It shows the association, aggregation, dependency, inheritance and relationship.
4. It shows the multiplicity and navigation indicators.
Fig 6. Class diagram for Airlines Reservation System
7. State Transition Diagrams

The state transition diagram represents a single object. It shows how external factors cause
changes in the object over its lifetime. It captures the behavior of a software system. They
provide an excellent way of modeling communications that occurs with external entities via a
protocol or event.

State diagrams are used to give an abstract description of the behavior of a system. This
behavior is analyzed and represented in series of events that could occur in one or more
possible states. Hereby "each diagram usually represents objects of a single class and tracks
the different states of its objects through the system".

The following are the basic notational elements that can be used to make up a diagram:

1. Filled circle, pointing to the initial state

2. Hollow circle containing a smaller filled circle, indicating the final state (if any)
3. Rounded rectangle, denoting a state. Top of the rectangle contains a name of the state.
Can contain a horizontal line in the middle, below which the activities that are done in
that state are indicated
4. Arrow, denoting transition.
5. Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line
entering and x>1 lines leaving. These denote join/fork, respectively.

State Transition diagrams are valuable because:

1. Identify the specific responses of an object to everything that can happen to the
object.
2. Identifies what events an object will and will not respond.
3. Validate the data needed to define the state of the object and the attributes affected by
the change.
4. Helps in finding the internal effects of behavior that can not be seen using interaction
based diagrams.
Fig7. State transition diagram for Airlines Reservation System.
8. Component Diagram :
The component diagram represents pieces of software in the implementation environment. It
models the implementation view of the software. We can use component to represent source
code, XML or any piece of software. When using large software system it is common to
break the software in to manageable subsystems. In UML component classifier represents
this. A component is a replaceable, executable piece of larger system whose implementation
details are hidden. The functionality provided by a component is specified by a set of
provided interfaces that the component realizes. In addition to providing interfaces, a
component may require interfaces in order to perform. These are called required interfaces.
Components are designed to be reused.

Component diagram are valuable because they:

1. Model the real software in the implementation environment.
2. They bring forward configuration issues through the dependency relationships.
3. They provide an accurate picture of existing systems prior to making changes or
enhancements.

<<GUI>> <<INFRASTRUCTURE>>
WEB FLIGHT RESERVATION
BROWSER SYSTEM

MYSQL

Fig 8. Component diagram for Airlines Reservation System.

 9. Deployment Diagram :
The deployment diagram models the hardware of the implementing environment. Each node
on a deployment diagram typically represents the type of hardware such as disk drive, a
client PC, a server or a processor. A node may also represent a human being or organizational
unit. Nodes are like classes. They represent a type of device, not a specific device, and the
features of each device. Like classes they are related using association that explains how the
nodes may be connected.
Deployment diagrams are valuable because:
1. They model the hardware platform for a system.
2. Identify hardware capabilities that affects performance planning and software
configuration.

Deployment diagram for Airlines Reservation System.

1. The Airlines reservation system will be deployed in the web server.
2. The client computer will access the software deployed at the server using web
browser.
3. The data will be accessed through the database server.

Fig 9. Deployment diagram for Airlines Reservation System.