A Unified Modeling Language

Documentation for Bus Reservation System

Table of Contents

1. INTORDUCTION................................................................................................................................31.1 A BRIEF INTRODUCTION TO UML...........................................................................................32. SCOPE OF WORK..............................................................................................................................42.1 AUDIENCE......................................................................................................................................42.2 ORGANIZATION............................................................................................................................4

3. SOFTWARE SPECIFICATION REQUIREMENT...........................................................................4

3.1 FUNCTIONAL MODELS............................................................................................................5-6

4. UML DIAGRAMS FOR BUS RESERVATION SYSTEM................................................................5

4.1 USE CASE DIAGRAM...................................................................................................................74.1.1 USE CASE DESCRIPTION........................................................................................................84.1.2 USE CASE TABLE................................................................................................................9-104.2 ACTIVITY DIAGRAM.................................................................................................................114.2.1 ACTIVITY DIAGRAM.................................................................................................................12

6. SEQUENCE DIAGRAMS...................................................................................................................13

6.1 SEQUENCE DIAGRAM...........................................................................................................146.1.1 SEQUENCE DIAGRAM FOR CHECK AVAILABILITY......................................................146.1.2 SEQUENCE DIAGRAM FOR LOGIN.....................................................................................146.1.3 SEQUENCE DIAGRAM FOR RESERVATION......................................................................156.1.4 SEQUENCE DIAGRAM FOR PASSENGER REGISTRATION............................................156.1.5 SEQUENCE DIAGRAM FOR CANCELLATION...........ERROR! BOOKMARK NOT DEFINED.6.2 COLLABORATION DIAGRAM.........................................................................................16-176.2.1 COLLABORATION DIAGRAM FOR CHECK AVAILABILITY.........................................186.2.2 COLLABORATION DIAGRAM FOR LOGIN........................................................................206.2.3 COLLABORATION DIAGRAM FOR RESERVATION........................................................206.2.4 COLLABORATION DIAGRAM FOR PASSENGER REGISTRATION...............................216.2.5 COLLABORATION DIAGRAM FOR CANCELLATION.....................................................21

7. STATE TRANSITION DIAGRAMS.................................................................................................22

7.1 STATE TRANSITION DIAGRAM FOR TICKET RESERVATION......................................23

8. CLASS DIAGRAMS............................................................................................................................22

8.1 CLASS DIAGRAM FOR BUS RESERVATION SYSTEM....................................................23

9. COMPONENT DIAGRAMS..............................................................................................................24

9.1 COMPONENT DIAGRAM FOR BUS RESERVATION SYSTEM........................................24

10. DEPLOYMENT DIAGRAMS............................................................................................................25

10.1 DEPLOYMENT DIAGRAM FOR BUS RESERVATION SYSTEM......................................25

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. SCOPE

1. Audience :

Customers, Administrators.

2. Organization :

ONLINE BUS RESERVATION SYSTEM

3. 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.

3.1 Functional Model

Fig 3.1 Context Level Diagram for Bus Reservation System

Fig 3.2 Level 1 DFD Diagram for Bus Reservation System

Fig 3.3 Level 2 DFD Diagram for Bus Reservation System

4. UML Diagrams for BUS RESERVATION SYSTEM

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.

4.1 Use Case Diagram

Cheque

Credit card

Payment Deduction

Cancel receipt generated

Booking Pass details

Payment

<<extend>>

<<extend>>

Cancellation <<include>>

<<include>>

Check Availability

Login

Seat Selection

Passenger

verification()

Window

<<extend>>

Validation

<<uses>>

Non Window

<<extend>>

4.2 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.

4.3 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

5. 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.

5.1 Activity Diagram

Ticket Enquiry

Login Details

Registered Passenger?

Yes

RegisterNo

Get Pass_Id

Fill Booking Form

Seat Selection

Book Tickets?

Yes Make Payment

Reciept Generation

Cancellation

No

Fill Cancellation Form

Yes

Cancel Ticket

Update Database

Cannot Cancel

No

Valid

Yes

No

Generate Reciept

Logout

Tickets Available Yes

No

6. 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.

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.

6.1 UML Interaction Diagram (Sequence Diagram)

: Passenger : System Database

Enquiry Details

Availability Details

GetDetails

Return Status

Fig 6.1.1 Sequence Diagram to check Availability

: Passenger System Database

Login Details

Username & Password

Retrieve Member Details

Provide Access

Fig 6.1.2 Sequence Diagram for Login

: PassengerSystem Database

New User Request

Registration Form

Submit Registration Form

Verifying Registration Details

Succesful Update

Successful Registration

Fig 6.1.3 Sequence Diagram for Reservation

: PassengerSystem Database

New User Request

Registration Form

Submit Registration Form

Verifying Registration Details

Succesful Update

Successful Registration

Fig 6.1.4 Sequence Diagram for Passenger Registration

: PassengerSystem Database : Payment

PNR no

Release Tickets

Payment Deduction

Cancellation Reciept Generated

Cancellation Reciept Provided

Retrieve Details

Return Details

Reservation Details

Request For Cancellation

Update Succesful

Fig 6.1.5 Sequence Diagram for Cancellation

6.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)

: Passenger

: System

Database

1: Enquiry Details

4: Availability Details

2: GetDetails

3: Return Status

Fig 6.2.1 Collaboration Diagram to check Availability

Fig 6.2.2 Collaboration Diagram for Login

: Passenger

: System

Database : Booking

Payment : Payment

1: Enter Booking Details7: Enter Reservation Details

9: Make Payment

6: Provide Booking Form8: Request For Payment

14: Payment reciept15: PNR Details

2: Provide Reservation Details11: Update Database

4: Availability Status12: PNR Generated

3: Check Amount10: Update Payment

5: Payment Details13: Payment Reciept Generated

: Passenger

System :

System

Database : System1: Login Details

4: Provide Access

2: Username & Password

3: Retrieve Member Details

Fig 6.2.3 Collaboration Diagram for Reservation

: Passenger

System

Database

: Payment

1: PNR no5: Request For Cancellation

10: Cancellation Reciept Provided4: Reservation Details

6: Release Tickets2: Retrieve Details

3: Return Details8: Update Succesful

7: Payment Deduction

9: Cancellation Reciept Generated

Fig 6.2.4 Collaboration Diagram for Cancellation

: Passenger

System

Database : Passenger

1: New User Request3: Submit Registration Form

2: Registration Form6: Successful Registration

4: Verifying Registration Details

5: Succesful Update

Fig 6.2.5 Collaboration Diagram for Passenger Registration

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

7.1 State Chart Diagram

EnquiryEnquiry() RegistrationPassReg( name,add,telno,dob ) Login

Booking PaymentPayRecieptGen( pnr )

PNRGen( passid,booking_details )

Fig 7.1 State Chart Diagram for Ticket Reservation

8. 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.

8.1 CLASS DIAGRAM

PassengerPass_Id : IntegerPass_name : StringPass_add : VariantPass_tel : IntegerPass_birth : Date

Enquiry()PassReg()PassIdGen()

CancellationPNRNo : IntegerPass_Id : IntegerNo_tickets : IntegerSeat_no : IntegerCancel_date : DateAmount : Double

TicketCancel()PayDeduct()CancelRecGen()

*

1

*

1

PaymentPass_Id : IntegerAmount : IntegerPaymode : StringCredit_No : IntegerCheque_No : IntegerPay_date : Date

PayReceiptGen()

1

1

1

1

BookingPNRNo : IntegerPass_Id : IntegerNo_tickets : IntegerSeat_No : IntegerDestination : StringBook_date : DateJourney_date : DateAmount : Double

PNRGen()

1

*

1

*

System

login()

11 11

11

11

1111

Fig 8.1 Class Diagram for Bus Reservation System

9. 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.

9.1Component Diagram :Data base server contains all the database tables.

WEB BROWSER

<<GUI>>BUS RESERVATION SYSTEM

<<INFRASTRUCTURE>>

MYSQL

Fig 9.1 Component Diagram for Bus Reservation System

10.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.

10.1Deployment Diagram

CLIENT COMPUTER<<WEB BROWSER>> WEB SERVER

<<SERVER>>

DATABASE SERVER<<MYSQL>>

TCP/IP

<<JDBC>>

TCP/IP

<<HTTP>>

Fig 10.1 Deployment Diagram for Bus Reservation System