Professional Documents
Culture Documents
JANUARY, 2014
SAMARA UNIVERSITY
ENGINEERING AND TECHNOLOGY COLLEGE
DEPARTMENT OF COMPUTER SCIENCE
PROJECT TITLE: ONLINE BUS TICKET RESERVATION
SYSTEM
BY
GROUP MEMBER
1. ABRHAM SORECHA
2. HABTAMU TAYE
3. KASAHUN TADELE
4. SEBHADIN NASRI
5. RAHEL AMHA
6. ZENEBE WORKU
We declare that this project is our original work and has not been presented for a degree in any
other university.
This project has been submitted for examination with my approval as university advisor.
ACKNOWLEDGEMENT
First of all we would like to express our special thanks of gratitude to our adviser Mr. Abel
Damtew for his guidance and suggestion during the project work. Next we would like to express
our thanks to our department for providing us this golden chance to work in group which help us
in our future career.
The last but not the least we would like to thanks Ms. Hirut who is Selam bus share line ticket
attendant for giving us necessary information.
ABSTRACT
The project which is the team aim to build is an online bus reservation system for Selam Bus
Line Share which is a web based application that allows customer to check availability of ticket
online at any time at any place and enable there customer to reserve a seat online without going
to the office physically. After the finishing of this project the company will get many advantages
such as it will provide a good service to their customer this will lead the company to be
profitable and it makes the data handling of the company organized. In recent year all projects
are done by using an object oriented method because of its convince to build a good and reliable
system so we choose this method for our project to be successful.
As we used object oriented system development methodology under this methodology there are
three development methodologies from those iterative system development methodology is
convenient to do our project successfully. As we are doing academic project we try to minimize
our expenditure so the total cost the project is require to complete is1200 Ethiopian birr.
The time duration the team requires to complete the project is 8 month so the team divide the
work for every month to finish on time.
Table of Contents
ACKNOWLEDGEMENT...........................................................................................................................5
ABSTRACT..............................................................................................................................................6
ACRONYMS............................................................................................................................................9
LIST OF TABLES....................................................................................................................................10
LIST OF FIGURE....................................................................................................................................11
CHAPTER ONE........................................................................................................................................1
INTRODUCTION.....................................................................................................................................1
1.1 BACKGROUND.............................................................................................................................1
1.2 STATEMENT OF PROBLEM...........................................................................................................2
1.3 LITERATURE REVIEW....................................................................................................................2
1.4 OBJECTIVE....................................................................................................................................3
1.4.1 General Objective.................................................................................................................3
1.4.2 Specific Objective..................................................................................................................3
1.5 MATERIALS AND METHODS.........................................................................................................3
1.5.1 Site of the study....................................................................................................................3
1.5.2 Method of data collection....................................................................................................4
1.5.3 System Implementation Tools..............................................................................................4
1.5.3 Tools or instrument..............................................................................................................4
1.5.4 Development methodology..................................................................................................5
1.6 SIGNIFICANCE OF PROJECT..........................................................................................................6
1.7 SCOPE AND LIMITATION..............................................................................................................6
1.8 TEAM PROFILE.............................................................................................................................7
CHAPTER TWO.......................................................................................................................................8
SYSTEM REQUIRMENT SPECIFICATION..................................................................................................8
2.1 INTRODUCTION...........................................................................................................................8
2.2 CURRENT SYSTEM........................................................................................................................8
2.2.1 Overview...............................................................................................................................8
2.2.2 Problems Of Current System.................................................................................................8
2.3 PROPOSED SYSTEM......................................................................................................................9
2.3.1 Overview...............................................................................................................................9
2.3.2 Goals Of Proposed System....................................................................................................9
2.3.3 Functional Requirements....................................................................................................10
2.3.4 Non Functional Requirements............................................................................................10
2.3.4 Constraints..........................................................................................................................11
2.3 SCENARIOS.................................................................................................................................12
2.4 SYSTEM MODELS.......................................................................................................................13
2.4.2 Use case model...................................................................................................................14
2.5.3 Object model......................................................................................................................26
2.5.4 Dynamic model...................................................................................................................30
2.5 INTERFACE INTERFACE-NAVIGATIONAL PATHS AND SCREEN MOCK-UPS.................................41
2.5.1 Passenger interface............................................................................................................41
2.5.2 Administrator interface......................................................................................................47
CHAPTER THREE..................................................................................................................................49
SYSTEM DESIGN...................................................................................................................................49
3.1 INTRODUCTION.........................................................................................................................49
3.1.1 Design Goals.......................................................................................................................49
3.2.3 End User Characteristics.....................................................................................................50
3.2 CURRENT SYSTEM ARCHITCTURE...............................................................................................50
3.3 PROPOSED SYSTEM ARCHITECTURE..........................................................................................51
3.3.1 Overview.............................................................................................................................51
3.3.2 Subsystem Decomposition..................................................................................................51
3.3.3 HARDWARE AND SOFTWARE MAPPING.............................................................................52
3.3.4 Persistent Data Management.............................................................................................52
3.3.5 Access Control And Security...............................................................................................53
3.4 SUBSYSTEM SERVICE..................................................................................................................54
REFERENCE..........................................................................................................................................55
ACRONYMS
OBTRS: Online bus ticket reservation system
HTML: Hypertext markup language
ADMIN: Administrator
Table 6: List of Actors and Use Cases associated with the new system.
Table 10: use case description for check ticket availability use case
Table 11: use case description for ticket cancelation use case
Table 12: use case description for view schedule use case
Table 13: use case description for generate report use case
Table 14: use case description for add route use case.
Table 15: use case diagram for delete route use case
Table 17: use case description for assign bus to the journey.
CHAPTER ONE
INTRODUCTION
As there are many problems face human being throughout their life it is obvious to solve many
of the problems using computers. When saying this as the computer is the modern technology
problem solver any one can solve his/her problem by developing the software that make its work
computerized. So we have prepared a project as a precondition for solving many of the problems
of Selam bus ticket System that is implemented manually. Therefore, this work that manually
performed needs to be automated to reduce the problem happened.
The project includes the background of the company and also the systems performed are
described. In addition, the conditions like the problems in the company, our objective, scope of
the project and cost are clearly specified.
Finally, the tools and techniques we will use and the schedule is summarized as possible as to
finish in the given time by using own methodologies.
1.1 BACKGROUND
Selam Bus Line Share Company was established in 1996 by Tigray Development Association
(TDA) to address the nation-wide need for public transportation. The company launched
operating reliable bus transport services with a fleet of 25 IVECO maxi-buses with initial capital
of 13.7 million birr. Selam Bus Line Share Company was legally constituted on Tir 29, 1987 E.C
with Registration No. 0014/87. Our company buses are luxurious tourist buses with a capacity of
51 seats which are equipped with Air conditioner, fridge, monitor, & safety belt so that
passengers are entertained by DVD/VCD music/film, Cake & soft drink or plastic packed
water/Juice while travelling.(http://www.selambus.com/companyprofile.html)
At present the company is rendering service from Addis to Diredawa, Harrer, Jijiga, jimma,
Bahirdar, Gondor, Dessie&Mekelle, Shire, Assosa, Arbaminch andMoyale on daily basis. The
headquarter, bus terminal and garage of Selam Bus has been established in Addis Ababa with
branch offices in all regional capitals. Buses departing from Addis Ababa to all the regional
capitals providing all necessary information and entertainment services to the satisfaction of the
passengers are expected to serve as the ambassadors of the region.
(http://www.selambus.com/companyprofile.html)
Selam bus Transportation Company uses manual system which requires a lot of resource like,
man power, stationary materials and so forth. And also the system is slow and inaccessible to
their customer.
From the point of view of customer the current system is very wasteful which require a lot of
time and money. For example if a person wants to reserve a place in the bus he must go to the
office his/her time and money are lost.
The team attempt to review different researchers which wrote about online bus ticket reservation
system so we described below:
Wee kim li in his project, which is done in 2007, define Bus Ticket Reservation System is
company online system, which enable Customer to check availability bus ticket buys bus ticket,
and pay bus ticket online. It makes the customer easy to get bus ticket online instead of queue up
to buy the bus ticket.(http://xa.yimg.com/kq/groups/27443320/1842024007/name/Bus.pdf)
Hasanhuse yinkoyun and Ayseorhan in there project which is done in June 2011 conclude that
about bus reservation system Designing a web site is making passengers convenient. Passengers
do not have to search the area when they went to travel, business. They will reach directly to
company online. Information of bus and availability of a seat of all about your business can be
reachable everywhere. Passengers find your information when they need where there is an
internet connection. In web sites, there is communication information, so if the passengers want
to quick help they can reach easily, they can go wherever they want immediately. Designing a
web site can save money on printing and postage costs for brochures, coupons, flyers, specials,
newsletters and other mailings. You do not have to write it down route, bus services, departure
date, departure time all the information can be entered on the website. The main activity of a bus
reservation system is reserving a seat for passengers who:
1.4 OBJECTIVE
Phone interview: we contact the organization and then exchange some ideas about their current
system, how it has been working and the structure of this organization. As a general, we gather
enough data in order to prepare our project.
Server side scripting: hypertext pre-processor (Php), we have select Php for server side scripting
because it has the following advantages;
Familiarity many of the language constructs are borrowed from C and Perl and in many cases
Php code is almost indistinguishable from that found in the typical C or Perl program. Php has
resource allocation machines and it can support object-oriented programming. (Kevin Tatroe,
Peter MacIntyre, and Rasmus Lerdorf, Third Edition Programming PHP, O’Reilly Media, 2013)
Although Php is compatible with wide Varity of web server we are used apache Server.
Database: Structured query language (MYSQL) rises to become one of the most popular
database servers in the world. This popularity is because of the servers speed, robustness and
flexible. MYSQL has arguable become Php most popular database counterpart.
Static webpage: hypertext mark-up language (html) is highly flexible with cascading style sheet
(CSS).
Hardware tools
Laptop or desktop
Cd
Flash disk
Software tools
The modeling method the team plan to use is unified modeling language (UML) which used to
Model the functions of the system (use case modeling), Find and identify the business objects,
organize the objects and identify the relationship between them and finally model the behavior of
the objects.
We use iterative system development methodology because of its flexibility which means
through the process of developing the system if error is occur we can back to the previous phase
and correct the problem.
In this section the team identify the scope and limitation the project so the following table shows
the scope and limitations of the project.
2.1 INTRODUCTION
System analysis involves the study of an application area to fully understand the problem being
posed. Activities are focused on developing a comprehensive knowledge of the existing system,
its strengths and weaknesses and the reasons for the need to restructure, replace, or automate the
existing system.(Stephen R.Schaca “Object-Oriented Analysis and classical software
engineering” McGraw hill publisher 6th edition)So in this chapter the team discuss about current
system, proposed system and at last system model.
2.2.1 Overview
Currently Selma Bus Share Line uses a manual ticketing system which is a passenger can reserve
ticket by going to the ticket office physically and after waiting a long queue the ticket attendant
asks question. These questions are listed below:
After the question is completely answeredthe ticket attendant gives the ticket to the passenger.
Currently company store passenger information’s inform paper file which is put in the shelf.
The details information of the passenger is traditionally paper based and maintained on
paper.
Finding out details regarding any information is very difficult because information in
paper based form.
Existing system require great amount of manual work has to be done. The amount of
manual work increases rapidly with increase in bus services.
Needs a lot of working staff and extra attention on all the records.
It is time consuming.
It is wasteful which means it require a lot of cost.
It causes data loss because there is no proper handling of data.
It is not easily accessible.
The passengers must wait for their required bus without reserving
2.3.1 Overview
The proposed system is a web based application which provides information regarding the bus
timings as per request of the user. The user enquires bus services from a particular source,
specifying the date and time and details about the available buses can be viewed in a time sorted
fashion. Also provides the facility to reserve tickets by online. If the reservation is successful, the
server will send back a reservation code to the customer.
The goal of the proposed system is to provide the organization a new system that provides all the
functionalities specified by the organization except automating payment system. The
administrator has options for adding items in to bus details, assigning bus, updating schedule and
adding route. Security features are also enhanced in the system by protecting unauthorized use of
the system through denying system service to those who don’t have user account. The goals
proposed system are listed below:
To create customers satisfaction
To provide quick access to the information
To minimize cost and time required to reserve ticket
To provide user intractable way of reservation
To provide reservation of ticket from any place and at any time
The system enables Administrator to add, update, routes and dates of bus.
The system allows passenger register to become a member of the system.
The system allows a registered user to reserve tickets online.
The system allows cancelling the reserved ticket.
The system allows checking the availability of bus in the required route easily.
The system should store all information of the passenger and every bus.
The system allow user to see bus departure and arrival of every bus.
The new system should be able to detect input syntax errors such as input of characters
where numbers are expected. The system should ignore the faults inputs and generate
error message
2.3.4 Non Functional Requirements
Non-Functional requirements describe user visible aspects of the system that are not directly
related with the functional behavior of the system. But it can support and give more quality for
the new system
The Online Selam Bus Ticket Reservation system shall be designed as a web based that has a
main user interface. Format of main screen shall be standard and flexible. The system should be
user friendly designed.
Pages shall be connected each other in a consistent way. Operations can be done with the system
shall be repeatable.
The system should provide an easy-to-use graphical interface so user can easily learn
how they use the system. So, little knowledge on how Web pages can be accessed is
required for user to use.
The system should be user friendly so that users can use it easily without confusion.
The web interface should be intuitive and easily navigable Users should be able to
understand the menu and options provided by the system
To use the system a user must first register to system and log in to the system but if unregistered
user try to reserve without having registering the system doesn’t allow the user to use the system.
The authorization mechanism of the system will block the unwanted attempts to the server and
also let the system decide on which privileges may the user have. The system has different types
of users so there are different levels of authorization.
Response time of the System should be minimum. The system should show no visible
deterioration in response time as the number of users or reservation data increases.
The system does not taking up too much space in memory to store system’s data.
The OBTRS is a web based application so anyone can use the service from any place if his/her
computer has internet connection. So the system must be able to communicate users from any
place.
2.3.4 Constraints
Supplementary specifications are constraints that should be taken into account while analyzing
and modeling the system. Here are the constraints we discovered on analysis phase:
The user must have connected to the internet to use the system.
The accuracy of the information of users is the responsibility of all users.
The new system shall permit only authorized members who have the appropriate right to
update, edit and delete the information.
Nobody should be allowed to login to the system except authorized users should have
user name and password to get into the system.
To use the new system the user must know how to use internet properly.
To access the system a system user must to be above 18 years old.
Repetitive cancelation of a reserve will lead a user to denying of accessing the system.
2.3 SCENARIOS
In section the team discuss in detail about scenarios which is a concrete, focused, informal
description of a single feature of the system from the viewpoint of a single actor. The team
identifies scenarios based on the scenario identification criteria’s. These identified scenarios
presented below:
1) Making reservation
Table 3: scenario for making reservation
Scenario name Making reservation
Participating instance Passenger
Flow of event 1. If the passenger want to make
reservation, open the OBTRS and
activate reservation function from
the system.
2. The passengers enter the departure
city and destination city and
submit the input and waits the
response.
3. The system processes the input
information and gives back the
reservation id and other important
information.
4. Passenger receive the confirmation
of his/her reservation.
2) Adding route
Table 4: scenario for adding route
Scenario name Adding route
Participating instance Administrator
Flow of event 1. If administrator want to add route
to system open system and activate
the add route function.
2. Administrator fills the required
information then submits input
information and wait the response.
3. The system processes the input
information and then gives back
the message successful addition of
route to the system.
4. Administrator receives the result.
3) Updating schedule
Table 5: scenario for updating schedule
Scenario name Updating schedule
Participating instance Ticket clerk
Flow of event 1. If the ticket clerks want to update
the schedule of the journey, open
the system and activate the update
schedule function.
2. Ticket clerk fill the required
information and then submit the
input and wait the response.
3. The system process the input
information and then gives back
the message successful addition of
route to the system.
4. Ticket clerk receive the result.
In this section we will discuss about scenarios of the system, use case modelling, object model
and dynamic model of the new system.
Table 6: List of Actors and Use Cases associated with the new system.
Administrator Log in
Generate report
Add route
Delete route
Assign bus
The
second step is to construct the use case model which graphically depicts the interaction of the
system with the external environment. The following figure specifies the use case model of the
System **
*
Register
* *
*
Update sechedule
ticket cleark
Cancel ticket *
<<extends>> Update reservation
<<Include>>
Reserve ticket
*
* <<Include>> <<Include>>
*
* *
*
<<Include>> <<Include>> Generate report
Check availability log in
Passenger of ticket *
*
<<Include>>
*
<<Include>> Add route
* *
*
* <<Include>>
<<Include>>
Cancel ticket * *
Assign bus
<<Include>>
Adminstrator
*
view schedule *
Delete route
The third step is to document each of the above use case courses of events to determine the
requirement use cases as described in the following section. So the following consecutive tables
show the use case documentation for each of the use cases that has identified in the above use
case diagram. Each table contains the use case name, the actor which initiates and interacts with
the use case, description of the use case and typical course of events that show the interaction
between the actor and the use case which enable the team to easily depict the functions of the
proposed system.
1) Register
2) Log in
3) Reserve ticket
AC3
If ticket is not available the system
does not allow reservation.
Special requirement A ticket must avilable
4) Cancel ticket
Table 10: use case description for ticket cancelation use case
Table 11:use case description for check ticket availability use case
6) View schedule
Table 12: use case description for view schedule use case
7) Generate report.
Table 13: use case description for generate report use case
8) Add route
Table 14: use case description for add route use case.
9) Delete route
Table 15: use case diagram for delete route use case
Table 17: use case description for assign bus to the journey.
Use case name Assign bus
Use case identifier UC11
Actor Administrator
Description This use case allow admin to assign bus to
the route
Pre-condition Administrator must log in to the system.
Post-condition Bus will be assign to the route.
Basic course of action 1. Admin launches the system.
2. The system displays the homepage of
the system.
3. Admin browse the assign page
4. The system displays the bus
assignation form.
5. Admin assign bus to each route and
submit to the system
6. The system displays message
successfully compilation of use case.
7. Use case end.
Alternative course of action AC1:
If the admin fills incorrect data the
system will displays the error
message and the assignation form.
1. Passenger
Table 18: data dictionary for passenger
2. Administrator
Table 19: data dictionary for journey
3. Reservation
Table 20: data dictionary for reservation
4. Route
Table 21: data dictionary for route
5. Schedule
Table 22: data dictionary for schedule
6. Bus
Table 23: data dictionary for bus
7. Account
Table 24: data dictionary for account
1 update
create 1 has
1
1
1
Adminstrator view
Account 1
1 -Username : string
-Username : String has ticket clerk
-Password : string
-Password : string -Fname : char
+Add route() -Lname : char
+create account() +delete route()
1 -Clerk id : int
-Username : string
1 -Password : string
Add/delete -office name : char
assign -Update schedule()
-Update reservation()
+Register()
* update 1
*
Route 1 1 *
-Route id : int contain Bus Schedule
-Departure city : char -No of seat : int * -Departure time : Date
-Destination city : char -Bus id : int -Arival time : Date
-Fare : int +Assign bus() -status
-Bus id : int -Departure date : Date
+add route() +Update scedule()
+delet route()
The following figure shows the high level sequence diagram of the system. The figure shows the
high level interaction of the actors with the system that specifies the work flow the system.
Passenger
Browse
Display
Invalid Store
Display
Ticket clark
Browse
Dispay
Invalid
Display
Display success
Admin
Browse
Request for log in
Display
Invalid
Display Store
Message1
Passenger
Browse
Request log in form
Display
Invalid
Display
Success
Passenger
lounch
Display
Invalid
Create
Display
In this part the team used to model the behaviors of the objects by drawing the state diagram.
The state diagram depicts the state of objects as their attributes change from one state to the other
state. So the following diagrams is state chart diagram:
Existing
Launch passenger Log in View scedule
New
passenger
Make reservation
Cancel reservation
Incorrect
Not avilable data
cancel
Figure 8: state chart diagram for passenger
access hompage
Valid entry
Invalid enry
Valid entry
successfuly reserve
access system
click submit
Valid data
schedule display
access system
Valid entry
Invalid entry
submit form
Valid entry
In this system users will communicate with it through the following user interfaces.
This interface contains some links which lead it to the concerned page, and if the passenger has
an account he/she will directly go to concerned page by entering their username and password.
PASSWORD **********
Selam Bus Received an International Quality ERA
Award for its Quality Service LOG IN
PASSWORD **********
FIRST NAME
LOG IN
LAST NAME
PASSWORD
SEX male
WOREDA
KEBELE
Submit Reset
TIME 12:00:05
ON LINE RESERVATION
Departure A.A
Destination GONDER
Date 02/12/2013
TOP DESTINATION
Submit
HAWASA
TIME 12:00:05
CANCEL RESERVATION
Reservation id
Reservation date
Submit Clear
TOP DESTINATION
HAWASA
TIME 12:00:05
Departure A.A
Destination GONDER
Submit
TOP DESTINATION
HAWASA
6)View schedule
HOME RESERVATION SCHEDULE FARE TRAVEL RULE CONTACT US LOG OUT
TIME 12:00:05
View schedule
Departure A.A
Destination GONDER
Submit
TOP DESTINATION
HAWASA
12:00:05
BUS ASSIGN
Rout id
TIME
Bus id
Submit
12:00:05
ADD ROUT
Departure A.A
TIME
Destination JIMA
Rout id
Submit Reset
3.1 INTRODUCTION
System design is the transformation of the analysis model into a system design model. In the
analysis phase the team describe the system completely from the actor point of view and serves
as the basis of communication between the client and the developers. But the analysis does not
contain information about the internal structure of the system and its hardware configuration. In
generally how the system should be realized.(Stephen R. Schema /2000) So in system design
phase the team describe in detail about the proposed system architecture, current software
architecture, design goals and at last the services of subsystem.
Performance
Response time of the System should be minimum. The system should show no visible
deterioration in response time as the number of users or reservation data increases.
The system does not taking up too much space in memory to store system’s data.
Usability
The system should provide an easy-to-use graphical interface so user can easily learn
how they use the system. So, little knowledge on how Web pages can be accessed is
required for user to use.
The system should be user friendly so that users can use it easily without confusion.
The web interface should be intuitive and easily navigable Users should be able to
understand the menu and options provided by the system
Dependence
The system should have ability to avoid service failures in the presence of mistakes.
Availability
The system should be available for any valid users at any time at any place.
The system should be available 24 hours a day, 7 days a week.
Security
Only system administer has the right to change system parameters, such as update
schedule, add and delete route.
Users need to be registered before having access to any services of the system.
Currently Selam Bus Line Share uses a manual ticket reservation system. So that the manual
system does not have any software architecture.
3.3.1 Overview
The proposed system is expected to replace the existing manual system by web based ticket
reservation which is the software architecture used for the system is Repository architecture
because subsystems access and modify data from asingle data structure which is called the
central repository. This architecture allows different user of the system access the data from
center database server.
The central repository of the proposed system is MySQL database server which is every data
related with the system is stored.
3.3.2 Subsystem Decomposition
Subsystem decompositions will help us to reduce the complexity of the system. So the team
identifies the following subsystem from the main system:
User management
Session management
Reservation
Route
Bus
Schedule
The user management subsystem control the account of the system user and session management
control and manage the period of time which the users spending using the system. The other
subsystem is Reservation which provide and control reservation and cancelation of ticket and
also uses to check the avilibilty of ticket. The route subsystem uses to control and manage
addition and deletion of route and the other subsystem is bus subsystem which uses to assign
buss to the route. The last but not the least subsystem is scedule subsystem which uses to control
and manage the schedule of the system.
Apache server
Web Browser
http
php
http
<<Database server>>
MYSQL
The system interface is built by using HTML and CSS. The validation of the system will be done
by JavaScript. The system interface which will interact with the database will be programed in
PHP and the databases will be done in MYSQL, and the web server will be run on Apache.
The administrator has been guaranteed to update schedule, generate report, add and delete
route and assign and add bus.
The ticket clerk has been guarantee to update reservation and update schedule.
The passenger has been allowed to reserve a seat, check availability of ticket, view
schedule cancel reserved ticket.
3.4 SUBSYSTEM SERVICE
As mentioned in the analysis phases the system provide different services so below are those
services which is provided by subservices listed: