A REPORT ON

ONLINE BUS RESERVATION SYSTEM

 Table of Contents

3.UML DIAGRAMS FOR BUS RESERVATION SYSTEM...................................................................................6

1. INTRODUCTION
1.1A Brief Introduction to UML
The Unified Modeling Language (UML) is the industry-standard language for specifying,
visualizing, constructing, and documenting the artifacts of software systems, as well as other non
software systems. UML simplifies the complex process of software design, making a "blueprint"
for construction, and is now the standard notation for software architecture. UML provides both
the structural views and behavioral views of the system. A set of diagrams with different
graphical elements is the core part as well as the most expressive presentation in UML. The
UML includes nine kinds of diagrams, for the sake of grasp the most representative aspects of
the design of elevator system, in this paper only following UML diagrams are used and analyzed:

Use Case diagram shows a set of use cases and actors (a special kind of class) and their
relationships. Use case diagrams address the static use case view of a system, these diagrams are
important in organizing and modeling the behaviors of a system.

Class diagram shows a set of classes, interfaces, and collaborations and their relationships.
Class diagrams are the most common diagrams used in modeling object-oriented systems. Class
diagrams address the static design view of a system.

Sequence diagram is an interaction diagram. Interaction diagrams address the dynamic view of
a system, besides sequence diagram, the other interaction diagram in UML is the Collaboration
diagram. Sequence diagram emphasizes the time ordering of messages between objects in the
system, while collaboration diagram emphasizes the structural organization of the objects that
send and receive messages. Sequence diagrams and collaboration diagrams are isomorphic, and
can be transformed from one into the other. Since either of them contributes to the same extend
of understanding of our system, while sequence diagrams give more ideas of time, which is
essential for real time systems, only the sequence diagrams are given in this report.

State chart diagram shows a state machine, consisting of states, transitions, events and
activities. State chart diagrams address the dynamic view of a system. State chart diagrams are
especially important in modeling the behavior of an interface, class, or collaboration and
emphasize the event-ordered behavior of an object, which is especially useful in modeling
reactive systems.

The rest four kinds of UML diagrams are:

Object diagram, showing a set of objects and their relationships;
Activity diagram, a special kind of State chart diagram showing the flow from activity to
activity within a system;
Component diagram, showing the organizations and dependencies among a set of components;
and
Deployment diagram showing the configuration of run-time processing nodes and the
components that live on them.

2. SOFTWARE SPECIFICATION REQUIREMENTS

The Online Bus Reservation system facilitates the user to view the bus schedules, enquire
about the bus details, availability of seats and many more. The major functionality of system
is to allow the user to book and cancel the bus tickets as per user requirements.
Major features provided by the system are:

Bus Enquiry
The system allows the user or member to perform bus enquiry including bus scheduling,
seats availability status, fare details, etc.

User Registration
It allows the user to register in order to be a member of the system. User is then granted
privileges to book or cancel tickets.

Bus Ticket Reservation

The system allows the member to book the tickets as per his/her requirements. The
member is prompt to enter the passenger details. The member then receives the unique
PNR No.

Bus Ticket Cancellation

 The functionality is used by the member to cancel an existing reservation made by the
member earlier.

2.1 Functional Model

Context Level Diagram for Bus Reservation System

Level 1 DFD Diagram for Bus Reservation System

Level 2 DFD Diagram for Bus Reservation System

3. UML Diagrams for BUS RESERVATION SYSTEM
1. 3.1 Use case diagram
The Use Case diagram models the user’s expectation for using the system. The people
and systems that interact with the system are called the actors. The features of the system
that the actors use are called the use cases. Some use cases interact with other use cases.
Use case is a way to capture system functionality and requirement in UML.
The use case diagrams consists of named pieces of functionality(Use cases), the persons
or the things invoking the functionality(Actors) and possibly the elements responsible for
implementing the use cases(Subjects).
The goal of the use case is to identify all the features that the users of the system expects
the system to support, but it does not reveal any details about the implementations of
these features.

Use case diagrams depict:

• Use cases. A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
 • Actors. An actor is a person, organization, or external system that plays a role in one or
more interactions with your system. Actors are drawn as stick figures.
• Associations. Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved with an
interaction described by a use case. Associations are modeled as lines connecting use
cases and actors to one another, with an optional arrowhead on one end of the line. The
arrowhead is often used to indicating the direction of the initial invocation of the
relationship or to indicate the primary actor within the use case.
• System boundary boxes (optional). We can draw a rectangle around the use cases,
called the system boundary box, to indicate the scope of your system. Anything within
the box represents functionality that is in scope and anything outside the box is not.
• Packages (optional). Packages are UML constructs that enable you to organize model
elements (such as use cases) into groups. Packages are depicted as file folders and can be
used on any of the UML diagrams, including both use case diagrams and class diagrams.

Use case diagrams are valuable because:

• They identify the user’s expectation of the system.
• They identify the specific features of the system.
• Identify shared behavior among system features.
• Provide a simple and easy way to visualize the requirements.

Use Case Diagram

 <<uses>>

Login

Validation

Check Availability

Booking Pass details

<<extend>>
Passenger
Seat Selection Window
verification() <<extend>>

Non Window

<<extend>>
Payment

<<extend>>

Cheque

Credit card

Cancellation <<include>>

<<include>>

Payment Deduction

Cancel receipt generated

3.1.1 Use Case Description
Actors:
1. Passenger
Use cases:
1. Login
2. Check Availability
3. Booking Pass details
4. Seat Selection
5. Window
6. Non Window
7. Payment
8. Cheque
9. Credit card
10. Cancellation
11. Cancel Receipt Generated
12. Payment Deduction
13. Validation

Description:
1. Login: It allows the existing user to login.
2. Check Availability: It verifies the user login against the password.
3. Booking Pass details: It allows the user to enter the passenger details.
4. Seat Selection: It allows the user to select the passenger seat.
5. Window: It allows the user to select the window seat.
6. Non Window: It allows the user to select the non window seat.
7. Payment: It allows the user to make the payment according to the selected mode.
8. Cheque: It allows the user to make the payment.
9. Credit card: It allows the user to make the payment by credit card.
10. Cancellation: It allows the user to make cancellation.
11. Cancel Receipt Generated: It allows the user to cancel the receipt generated
according to the cancellations made.
 12. Payment Deduction: Calculates the refundable amount and the amount to be
deducted.
13. Validation: Allows updation to be done.

3.1.2 Use case Table:

Use case ID 1
Use case name Seat selection
Actor Online Passenger
Pre-condition Login into the system
Post-condition select seat
Flow of events

Use case ID 2
Use case name Window Seat
Actor Online Passenger
Pre-condition Seat selection
Post-condition select window seat
Flow of events

Use case ID 3
Use case name Non Window Seat
Actor Online Passenger
Pre-condition Seat selection
Post-condition Select non window seat
Flow of events

Use case ID 4
Use case name Select credit card
Actor Online Passenger
Pre-condition Purchase ticket
Post-condition Add credit card details
Flow of events

Use case ID 5
Use case name Select Cheque
Actor Online Passenger
Pre-condition Purchase ticket
Post-condition
Flow of events

Use case ID 6
Use case name Select Cancellation
Actor
Pre-condition Enter details
Post-condition Payment deduction and cancel receipt generated
Flow of events

Use case ID 7
Use case name Booking pass details
Actor Online Passenger
Pre-condition Enter details of passenger
Post-condition Details stored
Flow of events

3.2 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 modeling focuses on the execution and flow of the system, rather than how it is
implemented. They are applicable to any type of behavioral modeling. Activity diagrams
captures activities that are made up of smaller actions. When used for software modeling
activities typically represents a behavior invoked as a result of a method call.
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 don’t 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.

3.2.1 Activity Diagram

 Ticket Enquiry

Registered Passenger?

No Register

Yes

Login Details Get Pass_Id

Book Tickets?

Yes Tickets Available Yes Seat Selection Make Payment

Fill Booking
Form
No

No
Cancellation
Reciept
Generation

No

Yes

Fill Cancellation
Form

Valid

No Cannot Cancel

Yes

Cancel Ticket

Update
Database

Generate
Reciept

Logout

4 UML INTERACTION DIAGRAM (Sequence And Collaboration

Diagram)
Interaction Diagrams
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.
4.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.
The sequence diagram is used primarily to show the interactions between objects in the
sequential order that those interactions occur. Much like the class diagram, developers typically
think sequence diagrams were meant exclusively for them. However, an organization's business
staff can find sequence diagrams useful to communicate how the business currently works by
showing how various business objects interact. Besides documenting an organization's current
affairs, a business-level sequence diagram can be used as a requirements document to
communicate requirements for a future system implementation. During the requirements phase
of a project, analysts can take use cases to the next level by providing a more formal level of
refinement. When that occurs, use cases are often refined into one or more sequence diagrams.

Sequence Diagrams are valuable because:

They have a narrow focus that helps us to see the specific questions, commands and data
communicated during the execution of a specific task.
They explicitly identify the communication required to fulfill an interaction. They help us to
identify the interfaces required by the classes.
They identify the objects that take part in the interaction. They help us to validate the features of
a class.
They identify the data passed as part of the interaction.

UML Interaction Diagram (Sequence Diagram)

 : System Database
: Passenger

Enquiry Details
GetDetails

Return Status

Availability Details

4.1.1 Sequence Diagram to check Availability

: Passenger System Database

Login Details
Username & Password

Retrieve Member Details

Provide Access

4.1.2 Sequence Diagram for Login

 System Database
: Passenger
New User Request

Registration Form

Submit Registration Form

Verifying Registration Details

Succesful Update

Successful Registration

4.1.3 Sequence Diagram for Reservation

System Database
: Passenger
New User Request

Registration Form

Submit Registration Form

Verifying Registration Details

Succesful Update

Successful Registration

4.1.4 Sequence Diagram for Passenger Registration

 System Database : Payment
: Passenger
PNR no
Retrieve Details

Return Details

Reservation Details

Request For Cancellation

Release Tickets

Payment Deduction

Update Succesful

Cancellation Reciept Generated

Cancellation Reciept Provided

4.1.5 Sequence Diagram for Cancellation

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

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

Elements of a Collaboration diagram

A Collaboration diagram consists of the following elements:

Element and its description Symbol

Object: The objects interacting with each other in the system.

Depicted by a rectangle with the name of the object in it, preceded by
a colon and underlined.

Relation/Association: A link connecting the associated objects.

Qualifiers can be placed on either end of the association to depict
cardinality.

Messages: An arrow pointing from the commencing object to the

destination object shows the interaction between the objects. The
number represents the order/sequence of this interaction.

UML Interaction Diagram (Collaboration Diagram)

 1: Enquiry Details
: System

4: Availability Details
: Passenger
2: GetDetails
3: Return Status

Database

4.2.1 Collaboration Diagram to check Availability

2: Username & Password Database :
1: Login Details System

System :
System 3: Retrieve Member Details
4: Provide Access

: Passenger

4.2.2 Collaboration Diagram for Login

: System

1: Enter Booking Details

3: Check Amount
7: Enter Reservation Details
10: Update Payment
9: Make Payment

5: Payment Details
13: Payment Reciept Generated
6: Provide Booking Form
8: Request For Payment
14: Payment reciept
15: PNR Details
2: Provide Reservation Details Payment :
11: Update Database Payment
: Passenger

4: Availability Status
12: PNR Generated

Database :
Booking

4.2.3 Collaboration Diagram for Reservation

 1: PNR no
System
5: Request For Cancellation

7: Payment Deduction
4: Reservation Details
10: Cancellation Reciept Provided
: Passenger
9: Cancellation Reciept Generated
: Payment
3: Return Details
8: Update Succesful

2: Retrieve Details
6: Release Tickets

Database

4.2.4 Collaboration Diagram for Cancellation

1: New User Request

3: Submit Registration Form
System

2: Registration Form
: Passenger 6: Successful Registration
4: Verifying Registration Details

5: Succesful Update

Database :
Passenger

4.2.5 Collaboration Diagram for Passenger Registration

 5.STATE TRANSITION DIAGRAM

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:
Filled circle, pointing to the initial state
Hollow circle containing a smaller filled circle, indicating the final state (if any)
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
Arrow, denoting transition.
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:

Identify the specific responses of an object to everything that can happen to the object.
Identifies what events an object will and will not respond.
Validate the data needed to define the state of the object and the attributes affected by the
change.
Helps in finding the internal effects of behavior that can not be seen using interaction based
diagrams.
State Chart Diagram

Enquiry() Enquiry PassReg( name,add,telno,dob ) Registration Login

PNRGen( passid,booking_details )

Booking PayRecieptGen( pnr ) Payment

5.1 State Chart Diagram for Ticket Reservation

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:
Classes
Interfaces
Collaborations
Dependency, generalization, and association relationships
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.
 Booking Cancellation
PNRNo : Integer PNRNo : Integer
Pass_Id : Integer Pass_Id : Integer
No_tickets : Integer No_tickets : Integer
Seat_No : Integer System Seat_no : Integer
1 1
Destination : String Cancel_date : Date
Book_date : Date 1 1 login() Amount : Double
Journey_date : Date
1
Amount : Double TicketCancel()
PayDeduct()
PNRGen() 1 CancelRecGen()
Payment
* *
Pass_Id : Integer
Amount : Integer
Paymode : String
Credit_No : Integer
Cheque_No : Integer
Pay_date : Date

PayReceiptGen()
1

1 1 1
Passenger
Pass_Id : Integer
Pass_name : String
Pass_add : Variant
Pass_tel : Integer
Pass_birth : Date

Enquiry()
PassReg()
PassIdGen()

6.1 Class Diagram for Bus Reservation System

7.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:
Model the real software in the implementation environment.
They bring forward configuration issues through the dependency relationships.
They provide an accurate picture of existing systems prior to making changes or enhancements.
Component Diagram :Data base server contains all the database tables.

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

MYSQL

7.1 Component Diagram for Bus Reservation System

8.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 models the mapping of software pieces of a system to the
hardware that is going to execute it. Software elements are typically manifested using artifacts
and are mapped to the hardware called nodes.
Deployment diagrams are valuable because:
• They model the hardware platform for a system.
• Identify hardware capabilities that affects performance planning and software
configuration.
•
Deployment Diagram

<<SERVER>>
<<WEB BROWSER>> WEB SERVER
CLIENT COMPUTER
<<HTTP>>
TCP/IP

<<JDBC>>

<<MYSQL>>
DATABASE SERVER
TCP/IP

8.1 Deployment Diagram for Bus Reservation System