Online Ticket Reservation and Bus Placem

Online Ticket Reservation And Bus placement System 2018
MIZAN
MIZAN-TEPI UNIVERSITY
Online ticket reservation and bus placement system for tepi bus
station
A Senior Project Documentation Submitted to Mizan tepi University in Partial
Fulfillments of the Requirement for the Degree of
Bachelor of Science in computer science.

Prepared By:
NAME ID
1 Amsal Gezu SCIR / 039/07
2 Hana Damota SCIR/ 160/07
3 Melkam Alemu SCIR/211/07
4 Muluken Semaw SCIR/ 240/07
JANUARY, 2018
Mizan-Tepi University
School of Computing and Informatics
Department of Computer Science
Online ticket reservation and bus placement
Submitted by:
1. Amsal Gezu SCIR/039/07
2. Hana Damota SCIR/160/07
3. Melkam Alemu SCIR/211/07
4. Muluken Semaw SCIR/240/07

Name and signature of member of examining board
Name Title Signature Date
________ Chairperson _____ _______
Emenet zewdu Adviso _______ _______
________ Examiner, _______ _______
Examiner, __________ ___________
DECLARATION
We declare that this project is our original work and has not been presented for a degree in any
other university.
Name Signature Date
Amsal Gezu _______ _______
Hana Damota _______ _______
Melkam Alemu _______ ______
Muluken Semaw _______ _______
This project has been submitted for examination with my approval as university advisor.
Name Signature Date
Emenet ____________ ____________
MTU,C S Page i
Contents
CHAPTER ONE ........................................................................................................................................... 1
BACKGROUND OF THE PROJECT .......................................................................................................... 1
1.1 Introduction ............................................................................................................................................. 1
1.2 Background of the Organization ............................................................................................................. 1
1.2.1 Vision of MTU ................................................................................................................................. 1
1.2.2 Mission of MTU .............................................................................................................................. 1
1.3 Problem of the statement......................................................................................................................... 1
1.4 Team composition ................................................................................................................................... 2
Task name ............................................................................................................................................. 2
Group member ...................................................................................................................................... 2
Project manager .................................................................................................................................... 2
System Requirement and specification (SRS) ...................................................................................... 2
Amisal ................................................................................................................................................... 2
Analysis and Design ............................................................................................................................. 2
Mullen ................................................................................................................................................... 2
Implementation and Testing.................................................................................................................. 2
Hana ...................................................................................................................................................... 2
1.5 Objective of the Project .......................................................................................................................... 3
1.5.1General Objective ............................................................................................................................. 3
1. 5.2 Specific Objective ........................................................................................................................... 3
 Gathering required information for proposed system by using interview, observation, and
document analysis. ................................................................................................................................ 3
1.6 Feasibility Analysis ............................................................................................................................. 3
1.6.1 Operational feasibility ...................................................................................................................... 4
1.6.2 Technical feasibility ......................................................................................................................... 4
1.6.3 Economic feasibility ........................................................................................................................ 4
1.6.4 Behavioral/Political feasibility ......................................................................................................... 6
1.6.5 Schedule Feasibility ......................................................................................................................... 7
1.7 Scope of the project ................................................................................................................................ 7
MTU,C S Page ii
1.8 Significance of the project ...................................................................................................................... 7

1.9 Target beneficiaries of the system .......................................................................................................... 8
1.10 Methodology for the project ................................................................................................................. 8
1.11 Development Tools ............................................................................................................................... 9
1.11.1Development methodology ............................................................................................................. 9
1.12 limitation of the project ....................................................................................................................... 10
CHAPTER TWO ........................................................................................................................................ 11
DESCRIPTION OF THE EXISTING SYSTEM ........................................................................................ 11
2.1 Introduction of Existing System ........................................................................................................... 11
2.2 Players in the existing system ............................................................................................................... 12
2.3 Major functions in the existing system ................................................................................................. 12
2.4 Business rules........................................................................................................................................ 12
2.5 Report generated in the existing system ............................................................................................... 13
2.6 Forms and other documents of the existing systems ............................................................................. 13
2.7 Bottlenecks of the existing system ........................................................................................................ 13
2.7.1Performance: ................................................................................................................................... 13
2.7.2 Input and Output ............................................................................................................................ 13
2.7.3 Control and Security ...................................................................................................................... 13
2.7.4 Efficiency ....................................................................................................................................... 14
2.8 Proposed solution .................................................................................................................................. 14
2.10 Requirements of proposed system ...................................................................................................... 15
2.10.1 Functional Requirements ............................................................................................................. 15
2.10.2 Non Functional Requirements ..................................................................................................... 15
CHAPTER THREE .................................................................................................................................... 18
SYSTEM ANALYSIS ................................................................................................................................ 18
3.1 System models ...................................................................................................................................... 18
3.1.2 Use case model .............................................................................................................................. 18
3.1.2Use Case Description ...................................................................................................................... 20
3.1.3Object model ....................................................................................................................................... 36
3.1.3.1Data Dictionary ................................................................................................................................ 36
MTU,C S Page iii

3.1.4.2Analysis level Class Diagram (Conceptual Modeling) .................................................................... 39

3.2 Dynamic model ..................................................................................................................................... 40
3.2.1Sequence Diagram .............................................................................................................................. 40
3.2.4User interface (navigational paths and screen mock-ups) ................................................................... 52
User interface .......................................................................................................................................... 52
CHAPTER FOUR................................................................................................................................... 57
SYSTEM DESIGN ................................................................................................................................. 57
4.1Introduction ............................................................................................................................................ 57
4.1.1Purpose of the system ..................................................................................................................... 57
4.2 Current software architecture ................................................................................................................ 57
4.3 Proposed software architecture ............................................................................................................. 58
4.3.1Overview ......................................................................................................................................... 58
4.3.2Subsystem decomposition ............................................................................................................... 58
4.3.3Hardware/software mapping ........................................................................................................... 59
4.3.4Persistent data management ............................................................................................................ 60
4.3.5 Access control and security............................................................................................................ 61
4.4 Subsystem services ............................................................................................................................... 61
REFERENCES ........................................................................................................................................... 63
List of table
Table 1 team composition ............................................................................................................................ 2

Table 2 communication plan ......................................................................................................................... 3
Table 3 materials cost for existing system .................................................................................................... 5
Table 4 materials cost for proposed system ................................................................................................. 5
Table 5 total cost of the project ..................................................................................................................... 6
MTU,C S Page iv
Table 6 use case description for login ......................................................................................................... 20

Table 7: use case description for reservation .............................................................................................. 20
Table 8 Use Case Description for view available bus ................................................................. 22
Table 9 Use Case Description for cancel ticket ......................................................................................... 24
Table 10 use Case Description for payment ............................................................................................... 25
Table 11 Use Case Description for view reservation ................................................................................. 26
Table 12 Use Case Description for create account ..................................................................................... 27
Table 13 use Case Description for view comment...................................................................................... 28
Table 14 Use Case Description for add bus ............................................................................................... 29
Table 15 Use Case Description for placement ............................................................................................ 30
Table 16 Use Case Description for post info ............................................................................................. 31
Table 17 Use Case Description for delete route........................................................................................ 32
Table 18 Use Case Description for view report .......................................................................................... 33
Table 19 Use Case Description for send complain ..................................................................................... 34
Table 20 Use Case Description for generate report .................................................................................... 35
Table 21 data dictionary for passenger ....................................................................................................... 36
Table 22 data dictionary for journey ........................................................................................................... 36
Table 23 data dictionary for reservation ..................................................................................................... 37
Table 24 data dictionary for route ............................................................................................................... 37
Table 25 data dictionary for schedule ......................................................................................................... 38
Table 26 data dictionary for bus ................................................................................................................. 38
Table 27 data dictionary for account........................................................................................................... 38
Figure 1 use case diagram ............................................................................................................ 19

Figure 2 Class Diagram ................................................................................................................ 39
Figure 3 Sequence diagram for log in ........................................................................................... 41
Figure 4 Sequence diagram for cancel ticket. ............................................................................... 42
Figure 5 sequence diagram for add bus. ....................................................................................... 43
Figure 6 sequence diagram for view available bus. ..................................................................... 44
MTU,C S Page v
Figure 7 sequence diagram for view placement .......................................................................... 45

Figure 8 sequence diagram for create account. ............................................................................ 46
Figure 9 sequence diagram for cancel request. ............................................................................. 47
Figure 10 sequence diagram for cancel request ............................................................................ 48
Figure 11 activity diagram for login ............................................................................................. 49
Figure 12 activity diagram for placement ..................................................................................... 50
Figure 13 activity diagram for add bus. ....................................................................................... 51
Figure 14 software and hardware mapping ................................................................................... 60
Figure 15 component diagram ...................................................................................................... 62
Figure 16 deployment diagram ..................................................................................................... 63
MTU,C S Page vi
List of Acronyms
API------------------------Application Programming Interface.
DBMS---------------------Database Management System
MYSQL-------------------My structural Query Language
MTU------------------------Mizan Tepi University
OBTRST------------------- Online Bus Ticket Reservation System for Tepi Bus Station
OOA-------------------------Object Oriented Analysis
OOD-------------------------Object Oriented Design
PIECES--------------------Performance Information Economics Control Efficiency Service.
PHP---------------------------Hypertext Preprocessor
SMS--------------------------Short Message Service
SRS---------------------------System Requirement Specifications
UI-----------------------------User Interface
UML--------------------------Unified Modeling Language
MTU,C S Page vii

Acknowledgment
First of all we would like to express our special thanks to our adviser Ms. Emenet Zewdu for her
guidance and suggestion during the project work. Next we would like to express our thanks to
our friends for their help. At the last we would thanks to Tepi bus station employers for their
help during data collection that are important for our system.
MTU,C S Page viii

CHAPTER ONE
BACKGROUND OF THE PROJECT
1.1 Introduction
Transportation has become essential in our day to day life. In Ethiopia, transportation provides
the connecting link between dwelling units and work opportunities especially in the urban areas
as much more of urban travel is tickly to be work trips shopping, entertainment, travel to and
from school sand variety of other reasons for making trips depend on transportation to make
corresponding land uses accessible to land dwellers. Public transportation provides people with
mobility and access to employment, community resources, medical care, and recreational
opportunities in their communities. But, nowadays the use of transportation is service provider
in Tepi is called Enset bus service enterprise it provide regular services on different routes
located on different direction around tepi. Tepi bus station gives transportation services for
peoples it was established in 1989 E.C. with small number of bus and employees in the SNNPR.
Currently they have a number of buses and the number of employees has also increased, but still
the service is not fast because they work on a manual system.
1.2 Background of the Organization
1.2.1 Vision of MTU
Tepi bus station enables to give efficient transportation services for users
1.2.2 Mission of MTU
Tepi bus station has a mission of supporting people by tacking the insistent problems by utilizing
Custer satisfaction and assuring quality education.
1.3 Problem of the statement
In tepi bus station, manual system requires a lot of resource like, man power, paper, pen and so
forth. In this system, a loss of data might be occurred. For example, passenger may loss his or
her ticket also technical problems may occur. Drivers waste much time to view their schedule
from the notice board after placement. Therefore, the existing system service is not satisfying the
customers need and most of the placement information is kept in a file. Therefore, it is quite hard
MTU, C S Page 1
for them to search the placement information when needed. 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 ticket he must go to the office his/her time and money are lost. As we
have mentioned earlier the existing system has so many problems that are obstacle to perform the
work effectively and accurately. To avoid all these problems and make the working process more
accurate develop automated and ease web based application which can be accessed anywhere
any time.
1.4 Team composition
In our project, we have four (4) members where each of us has specified work and also the
project is supervised by one of our members. The following are the types of tasks and as well as
the responsibility each of us can have.
Table 1 team composition
Task name Group member

Melkam
Project manager
System Requirement and specification (SRS) Amisal
Analysis and Design Mullen
Implementation and Testing Hana
Communication plan
While we are working on our project, we use the following techniques in order to meet one
another and then exchange our suggestions or ideas. Those techniques are listed in the following
MTU, C S Page 2
Table 2 communication plan
Number Technical
1. Mobile phone
2. Email
3. Schedule(Time table)
1.5 Objective of the Project

1.5.1General Objective
The general objective of this project is to develop online ticket reservation and bus placement
system for Tepi bus station.
1. 5.2 Specific Objective
In order to achieve the main objective, we have the following specific objectives:-
 Identify the problems of the existing system
 Gathering required information for proposed system by using interview, observation,
and document analysis.
 To analysis the existing business process of ticketing and reservation and route
assignment system
 To design and model the architecture for the proposed system,
 To implement the new developed system and increase the customer satisfaction
 To test system.
1.6 Feasibility Analysis
Feasibility study is essential to evaluate the cost and benefits of the new system. Need of the
feasibility study:
 It determines the potential of the existing system.

 It used to determine/finds out the problem of the existing system.
MTU, C S Page 3
 To determine all goals of the new system.

 It finds all possible solutions of the problems of the existing system.
1.6.1 Operational feasibility
The system to be developed will provide accurate, active, secured service and decreases labor of
workers and also it is not limited to particular groups or body. And also it is plat form
independent.
1.6.2 Technical feasibility
We are going to develop the system that is not complex to use it. That mean our system should
be easier for the user to use it. The system should also operate correctly. Our system will be
technically feasible. The proposed platform has sufficient capacity for future needs. They are
available for development and representation of the web site. The solution is technical feasible in
this feasible we test whether the website can be developed using existing technology or not. It is
planned to implement the proposed system usually php, MySQL server, micro media, dream
weaver. It is evident that necessary hardware and software.
1.6.3 Economic feasibility
The system to be developed is economically feasible and the benefit is reducing the cost. Since
this project will computerize the existing system, the reduction of cost for materials used in
manual operation becomes beneficiary to the organizations.
Tangible benefits:
 Reduces unnecessary wastage of materials like paper, pen, and human power.
 Reduced time consumption.
 Reduce economic consumption.
MTU, C S Page 4
Table 3 materials cost for existing system
Materials cost for existing system
Item Quantity per year Unit price/salary Total price/salary per

year
Papers 300 packet 80 birr 24,000 birr
Pen 20 packet 40 800 birr
Labor cost 14 labor 1000 168,00 birr
Total materials cost 192,800 birr
Table 4 materials cost for proposed system
Materials cost for new system
Item Quantity per year Unit price/salary Total price/salary per

year
Labor cost 6 person 1000 6000 birr
Papers 3 packet 80 birr 240 birr
Pen 2 packet 40 80 birr
Computer 4 8000 32,000birr
Total materials cost 38,320 birr
MTU, C S Page 5
Difference between before and after deployment money required for payment.
Cos reduction for materials=192,800=38,320 birr=154,480 birr.
Intangible benefit:
 Get better and effective service.
 More reliable.
 Timely processing.
 Increases user satisfaction.
1.6.4 Behavioral/Political feasibility
Behavioral/Legal Feasibility Our proposed system behaviorally feasible cannot cause any harm
in the environments. The project would be beneficial because it satisfies the objectives of the
passenger. The system was developed user friendly and improves the working environment. Our
system is free from any political and environments difficulty.
To complete our project starting down from the beginning up to the end, the total costs we have
paid was listed in the following table.
Table 5 total cost of the project
No Items Price(in birr) Quantity
1 Paper 80.00 2
2 CD 10.00 2
3 Pen 7.00 2
4 Transportation 50.00 All members(4)
5 Call phone 25.00 1times
7 Binding 14.00 2
Total 8 906.00 10
MTU, C S Page 6
1.6.5 Schedule Feasibility

The project is intended to be with in fixed time interval. Unless and otherwise we may fall in
difficulty in cost estimation and as well as we may fall in the financial problem. To overcome
such problems we fixed the time interval in which we should finish the development of the
whole time among different section of project
1.7 Scope of the project
The functionality of our project is to give Reservation systems, Ticketing system, Customer
service system, Building web application for the users, Security in the form of account, password
and permission and bus placement system.
A person should be able to:
 Able to choose the seats and Seat reservation.
 Withdraw reservation.
 A message should be sent to the concerned person about the confirmation of the ticket to
the specified system.
 The system should automatically show the schedule for the corresponding seat and
amount of money needs to be pay for selected seats.
 Assigning bus to journey.
 Provides payment with simulation
 The system is functional only for register bus and passengers to regular place.
 Process of the placement based on the policy of the Tepi bus station
1.8 Significance of the project
The online ticket reservation and bus placement system and allocation system is highly reliable,
easy, fast and consistent and will play a crucial role for reliable service for passenger and
organization.
For the organization:
 It increases their profit by making their expenditure less.
 It increases customer satisfactions.
 It reduces the required man power.
 Increased speed of activity
MTU, C S Page 7
 To make placement tasks simple and efficient in every aspects

 It helps the organization to handle customer information in an organized way.
For the customer:
 It reduces the wastage of money.
 Get more timely information.
 It will save time that can be spent during view schedule and ticket reserve.
1.9 Target beneficiaries of the system
Beneficiaries of the Project it is very important to Tepi bus station passenger, MTU Tepi campus
student and all passengers. Besides that, this concept can be used by others bus company so that
to do their own system to solve their passenger problem. The profit for the bus station will be
increased because the online system will attract more passengers and no need to hire many staffs
at the counter to sell bus ticket because ticket can be sold efficiency online so that bus station is
beneficiary.
1.10 Methodology for the project
We gather information by using the following methods:-
Direct observation:
At the time we have gone there, we have visited that organization by moving here and there by
which techniques this organization use to succeed its function.
Document analysis:
To get more information about the ticket reservation and how to assign bus to journey we refer
documents that enable the team to get more information in order to understand about problems
and business rules of the existing system.
Interview:
As an interview, we have contacted the manager of that organization and then exchanged some
ideas of this system how it have been working and the structure of this organization have in its
implementation also the aim of they have to change the current or manual system to an online
system. As a general, we gathered so many data in order to prepare our project by interviewing
them.
MTU, C S Page 8
1.11 Development Tools

Hardware Consideration:
Our system will use the following hardware devices while on implementation and after
implementation. These hardware devices includes:-
 Flash
 DVD/CD
 Computers
Software Consideration:
The proposed system will be available by using the following software devices:-
1. MS word: document tools
2. Edraw Max 6.0: use to make UML diagrams.
3. Ms power point: presentation
4. Xampp: to connect our data base
5. Notepad++: for writing the script.
6. Front end: - Internet programming language html (for client side).
7. For server side script: php
8. Back end: - MYSQL database.
9. Adobe Photoshop: for editing various pictures and to prepare logos etc.
1.11.1Development methodology
The team will follow Object Oriented System Development methodology (OOSD). Object
oriented methodology define system as a collection of interacting objects.
We choose object oriented development design because of:-
 These techniques have a reusability feature.
 These techniques provide greater opportunities for users to participate in the
development process.
 This increases flexibility.
 This also improved quality.
 These techniques are latest, powerful, easy and highly in use by now.
 Increase domain and design reuse.
MTU, C S Page 9
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.
1.12 limitation of the project
The passengers can reserve ticket only if the internet connection is available and banks does not
give privileges create accounts as we want does not serve passers out of destination
MTU, C S Page 10
CHAPTER TWO
DESCRIPTION OF THE EXISTING SYSTEM
2.1 Introduction of Existing System
Currently in Tepi bus station uses a manual ticketing system which is a passenger can reserve
ticket by going to the ticket office physically and by finding ticket clicker and drivers can see the
schedule by asking the manager or by reading on the notice board. Tepi bus station currently
serves 49 routes that connect different parts of the city using 85 operational buses. The number
of passengers shows high variability during each periods of time that requires fluctuation of
number of assigned buses in each route. But, the enterprise uses a fixed number of buses
scheduled per route in its operation throughout the day. This resulted in, the fact that, some buses
move empty while others are overcrowded, which subsequently result in poor performance on
bus utilization, number of trips and service quality. Generally system exists in Tepi town is
manual which encounter the following situation:
 In existing system, there are various problems like keeping records of items, seats
available, prices of per/seat and fixing bill generation on each bill.
 Usually the first seat of tickets is reserved for their relatives.
 If number of passengers is increased some tickets are reserved and sell by increased
amount.
 In order to buy the ticket, we have to go to the bus station and this make passenger
waste his /her time, waste budget, etc.…
 Passenger need to pay cash when they buy bus ticket and sometimes needs to queue up
long time to get the bus ticket.
 Passenger has to go to the counter to buy bus ticket or ask for the bus schedule.
 When passengers go to the bus station he /she may face different social problems like
getting conflict with robust or thief's.
 Existing system is totally on book and those a great amount of manual work has to be
done. The amount of manual work increases exponentially with increase in services.
MTU, C S Page 11
2.2 Players in the existing system

Some of players in the existing system are: -
 Passengers
 Managers
 Employers
 Receptionist (Ticket sellers)
 bus enterprises
 Bus scheduler
2.3 Major functions in the existing system
The station needs some information from the passenger bus owners. Those are passenger first
name, last name, start place (by default it is known) and the place where the passenger wants to
go (destination place), and they fill the rent on the form as well as they take the price and the bus
plate number, serial number type and drivers and driver assistance. The passenger and bus
owners’ replies answer to those questions at the bus station.The Process After the form is
completely answered, the ticket receptionist prepare the ticket for the passenger. Currently
station store passenger information’s in paper file which is put on the shelf. As an output the
passenger receives the ticket bus owner receive authorization paper
2.4 Business rules
The system has the following written business rules:
Passengers can cancel ticket but 15% must reduce, If passengers have child (<6 years old) that go
with them, they will not pay the price for their child and the child can’t get a sit.
Passenger must keep his ticket and must be arrived on time on bus station and also should have an ID
(identification card).The manager must fill the correct scheduling of the bus route with features
like start destination, and end destinations, must managing the traveling time and bus schedules.
The first reached bus can get first access (first come bus first served).and in the proposed system
Passengers must give right answer for filling form, Passenger must have bank account number and
also Passengers must have enough money and no reservation before two day.
MTU, C S Page 12
2.5 Report generated in the existing system

Current system of bus placement, buying bus ticket and bus reservation services is manual. The
system asks the responsible workers to provide report. As we have observed and also interview
the system managements the report generating mechanism is manual that is any kind of report is
written on paper by system workers and then it will be transformed for the manager once in
week, month and year. Those forms used to generate reports in the current system are listed as
follows.
1. Daily report.
2. Weekly report.
3. Monthly report.
2.6 Forms and other documents of the existing systems
There is a sample forms and other document journey ticket, placement form paper, report
generated paper adding of user and adding of bus at last page of our documentation up to
appendix.
2.7 Bottlenecks of the existing system
The PIECES framework developed by James Wither be is used here as a means to classify
problems. PIECES stand for Performance Information Economics Control Efficiency Service.
2.7.1Performance:
Since the existing system is manual, it takes long response time. For example, when one
passenger need to reserve bus and to pay money he/she must appear physically in the place and it
takes long time
2.7.2 Input and Output
Input: List of the passenger does not contain their full information on the papers. Receive the
incorrect/redundant passenger list. They fill incorrect name and the specific time.
Output: They show the starting time, but not the ending time for the passenger.
2.7.3 Control and Security
In the existing system, it is difficult to control the system because there is no privilege in data
accessing. Here the necessary reports may not generate at exact time so it may occur security
MTU, C S Page 13
violence. The system shouldn’t provide sufficient protection for access and manipulation of the
records associated with the system. So, it is not easily protected and used properly the resource.
 Control over the data is too difficult and it takes long time.
 Input data is not adequately edited.
 Redundantly stored data is inconsistent/unreliable in different files.
2.7.4 Efficiency
In manual operation, most of the activities are prone to wastage of resources like papers, man
power, time etc. to produce the corresponding outputs. This makes the current system inefficient
while utilizing resources. There should be a mechanism that reduce wastage ofresources and that
make the system to be efficient. As a result, the new system will reduce wastage of resources and
make it efficient.
2.8 Proposed solution
The new system is targeted to address the problem of the current system and to support
additional manipulations or features. Our proposed system will overcome the problems being
faced by the manual management system. The newly proposed system is web based system that
the users can access the web page and can get different services from this website of online bus
placement and ticket reservation (OBPTR) system.
The system requires very low system resources and will work in almost all configurations. It has
got following features:
1. Passenger can buy ticket over the Internet, 24 hours a day, 7 days a week, and the bus
ticket cannot be lost, stolen or left behind.
2. Passenger can check the availability of the bus ticket and availability of seat before
they buy bus ticket.
3. drivers can view placement without asking the manager or read on the notice board
4. Ensure data accuracy.
5. Records are efficiently maintained by DBMS which provides security
6. Any person across the country, having Internet can access this service.
7. Minimum time need for the various processing.
8. Better Service.
MTU, C S Page 14
9. Minimum time required.

10. This would help the corporation prepare and organize its schedules more efficiently
on the basis of traffic demand.
2.10 Requirements of proposed system
2.10.1 Functional Requirements
We have the following functional requirements:
 The system shall allow manager assign bus to journey.
 The system enables Administrator to create account for clerk and manager.
 The system enables to clerk generate report.
 The system allows passengers to reserve tickets online.
 The system allows enabling the drivers to view the route for appropriate bus.
 The system allows cancelling the reserved ticket.
 The system allows make payment and gives tickets for reserved passengers.
 The system enables user to see bus departure and arrival of every bus.
The details of the buses and seats available are to be maintained and can be
updated regularly (of course only by the admin)
 Also first the user needed to login first in order to perform the booking
actions
 The system allows manager/staff view comment.
 The system allows passengers to view available ticket and seat.
 Style and Formatting, with having to edit any PHP code
2.10.2 Non Functional Requirements
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.
Reliability:
MTU, C S Page 15
It can send message, receive message and attach file data or information which is retrieved from
the system is accurate (required) in deserved time.
Performance:
Performance requirements define acceptable response times for system functionality. Response
time of the Bus Reservation System should be few second most of the time. Response time refers
to the waiting time while the system accesses, queries and retrieves the information from the
databases. The load time for passenger interface shall take no longer than few seconds. The login
information shall be verified within less seconds. Response time of the system will not take long
time, almost in a few seconds. The system works 24 hours per day 7 days in a week. The
passengers’ information must save in the database in few minute after the end of registration.
Performance requirement:
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.
Interface:
Our system describes the logical characteristics of each interface between the system and the
users.
This may include any graphical user interface(GUI) standards or product family style guides,
screen layout constraints, standard buttons and functions that will appear on every screen, error
message display standards, and so on. So our system does these all functions in easy and efficient
way. In other words the system is user interactive
Security and Access permissions:
Only system administer has the right to change system parameters, such as time change, adding
new bus and others. The system should be secure and Users need to be authenticated before
having access to any personal data.
Error handling:
The system will check user inputs to the system to handle error. It handles and show error by
displaying the error message when the user enters invalid input.
Maintainability:
MTU, C S Page 16
Should be easily maintainable, easy to upgrade and make adjustments as it is known, every
system needs to be maintained and modified, so we will try to make the code easily readable and
write the comment along with necessary to the codes.
Security: This is vital in the design and expectation of any system. It should contain mechanism
to protect the integrity and avoid changes or access by unauthorized users.
Consideration of the security of the system has a great advantage for this system, because the
database should be secured from the unauthorized users. Only authorized user can get access to
the database. To prevent from the unauthorized user, the user should have their username and
password that help them to login to the system. Additionally, the users should have to take care
of their own username and password. They should have to keep in a secret manner
Backup and Recovery:
Backup and recovery requirement: The process of backing up refers to the copying and archiving
of computer data by using removable storage media such as Disk, CD-R and CD-RW so it may
be used to restore the original data after a data loss event is performed by our system.
Resources:
The main non-functional resource is: - Server in back end and operating system in the
application of the system. In the other case one of the most and available resource is internet
access.
MTU, C S Page 17
CHAPTER THREE
SYSTEM ANALYSIS
3.1 System models
The designer’s goal is to produce a model or representation of an entity that will later be built.
Beginning, once system requirement have been specified and analyzed, system design is the first
of the three technical activities such as: - design, code and test that is required to build and verify
software. Thes importance can be stated with a single word “Quality”. Design is the place where
quality is fostered in software development. In this chapter we are introduce system workflow,
activity diagram, sequence diagram and class diagram.
3.1.2 Use case model
The use case modeling first step is to identify Actors and use cases associated with the system.
The following table specifies the actors and use cases that a group member have identified with
in the proposed new system.
Actor identification:
In the use cases an actor interacts with the system to perform a piece of meaningful work that
helps them to achieve a goal and has access to define their overall role in the system and the
scope of their action. Depending on the above explanation actors in this system are the
following:
Passenger: someone who reserve online bus ticket.
Driver: someone who deliver passengers
Administrator: the one who manages and maintains computer systems, software and who can
Setup access right for other users.
Manager: a user who manage the system.
Driver assistances a person who checks whether the passenger reserve ticket or not as well
as person who generate reports and manage passengers.
clerk: - someone who is responsible for managing reservation and the maintenance of the web
site content such as adding/removing information about the company
MTU, C S Page 18
Use case diagram
use case diagram for tepi bus placement & on line ticket reservation system
update
generate Extend reservation
create account
report
Extendmanage route
delete account
cancel ticket
Extend
delete bus manage
account
Extend
add new bus
Extend manage bus
clerk admin
Extend
update bus
view comment check availability
of seat
add new routeExtend
view reservation
payment
delete route Extend
Extend
cancel ticket
Association
Extend request
done placement update route
reserve seat passing

manager er
post info
login view available
bus
view report update bus

Association schedule
Association check passenger
ticket
Extend
driver view placement
driver
assistan
logout t
send complain
Figure 1 use case diagram
MTU, C S Page 19
3.1.2Use Case Description

Table 6 use case description for login
Use case name Login
Use case id U1
Actor Admin, manager, clerk.
Description Login is authenticating admin, manager to grant privilege.
Precondition There must be login form.
Basic cores Actor action System response

action
Step1: open home page Step3: display login form
Step2: click login button. Step5: checks user name and password
Step4: enter user name and password Step6: users login to the user page
Step7: use case ends
Alternative 5.1 if the user enters wrong user name and password back to step4
cores of action
5.2 The use case continues to Step6.
Post condition The admin, manager and clerk login the system and use.
Table 7: use case description for reservation
MTU, C S Page 20
Actor Passenger
Use case id U2
Use case Ticket reservation

name
Description It allows reserving seat.
Pre- Must have available seat

condition

action
Step1: open home page. Step3: The system display

reservation form.
Step2: click ticket reserve seat
link. Step6: The system validates the
information.
Step4: passengers fill departure &
Step7: The system display ticket
destination.
available seat and reservation
Step5: click search button. form.
Step8: passengers fill form. Step10: The systems verify

information.
Step9: click submit.
Step11: The system assign seat
and
Send message.
MTU, C S Page 21
Step12: The use case ends
Alternative
cores of 6.1 If the information is invalid back to step4.
action
6.2. The use case continues to step7.
10.1 If the passenger fill wrong information return step 8.
10.2 The use case continues to step11.
Post- The passenger will reserve a ticket.

condition
Table 8 Use Case Description for view available bus
Actor Passenger
Use case id U3
Use case name View available bus.
Description This use case allows the passenger to see available bus to journeys.
Pre-condition Must have available bus form.
Action
Step 1: Passengers open home page Step 3: the system display view
available bus form.
Step2: click view available bus link.
Step 6: The system validates the
Step 4: Passenger fills the required data.
information.
MTU, C S Page 22
Step5: click search. Step 7: The system displays available

bus with the required route.
Step8:Use case end
Alternative Step6.1 if the information is incorrect returns step4.

cores of action Step6.2 The use case continues Step6 of the basic course of action.
Post-condition It will show available bus and fare ,time of the journeys
MTU, C S Page 23
Table 9 Use Case Description for cancel ticket
Actor Clerk
Use case id U4
Use case Cancel ticket.

name
Description this use case allows cancel reservation ticket
Pre-condition Passenger must send cancel ticket request.

action
Step1: open home page. step3: The system displays reserved ticket list.
Step2: click cancel ticket Step7: The system validates

link.
Information.
Step4: select ticket.
Step8: The system makes free seats and send
Step5: Select free button successfully Cancelled message
Step6: click submits. Step9: The use case ends
Alternative Step 7.1If the user information is invalid return tostep4.

cores of action
Step7.2 The use case continues Step8 of the basic course of action.
Post-condition The selected reservation has been cancelled and updating the database
information.
MTU, C S Page 24
Table 10 use Case Description for payment
Actor Passenger.
Use case id U5
Use case name Passenger
description This use case allows passengers to pay for reserve seat.
Pre-condition Passengers should have enough money on their account.

action
Step1: open home page. Step3: The system displays payment
page.
Step2: the passengers click payment
link. Step6: validates the information
Step4: The passenger enters Step 7 the system makes payment

process
Necessary information.
Step8: The system reserve ticket and
Step5: click submit.
send message
Step9: The use case ends
Alternative 6.1 If the input information is invalid return to step4.

cores of action 6.2 The use case continues Step7of the basic course of action.
Post-condition The passenger must have been logout from the system.
MTU, C S Page 25
Table 11 Use Case Description for view reservation
Actor Clerk
Use case id U6
Use case name view reservation
Description Use case allows to view reservation
Pre-condition Clerk must login to the system.

action
Step1 : clerk login to the system Step3: The System display view
reservation form.
Step2: click view reservation link.
Step6: the system validates information.
Step4: Passenger fills the required data
Step7: The system displays the
Step5:press search
information related with the search.
Step8: use case end.
Alternative Step5.1 if The input information invalid return to step6.

cores of action
Step5.2 The use case continues Step7 of the basic course of action.
Post-condition Reservations have been view.
MTU, C S Page 26
Table 12 Use Case Description for create account
Use case name Crete account
Use case id U7
Actor Admin.
Description This use case allows administrator to create account for clerk, manager.
Pre-condition Admin must login to the system.
Action Step1: login to the system. Step3: The system display mange
account list
step2: click manage account link.
Step5 The system display create
Step4 The administrator select create
account form
account list
Step9: The system check validity.
Step6: The administrator fills the
Step10: The system store information in
necessary information in the
the database.
Displayed form to create account.
Step11: use case ends
Step7: click submit button
Step8: displays successfully created
message to the admin
Alternative 8.1if the information is invalid then return step6

cores of action
8.2 The use case continues Step9 of the basic course of action
MTU, C S Page 27
Table 13 use Case Description for view commen t
Actor Manager and clerk.
Use case id U8
Use case name View comment.
Description This use case allows to view comment.
Pre-condition The Manager and clerk must have login.

action
Step1: The clerk login to the system. Step3: the system display comment
list.
Step2: The clerk click view comment
link. Step6: The system displays the
comment.
Step4: the clerk selects report.
Step5: press ok.
Alternative
cores of action
Post-condition The clerk & manager must have been logout.
MTU, C S Page 28
Table 14 Use Case Description for add bus
Actor Admin.
Use case id U8
Use case name Add bus.
Description This use case allows addition of a new bus.
Pre-condition The bus full fills criteria.

action
Step1: login. Step3: The system displays the list.
Step2: click manage bus link. Step5: the system display form.
Step4: Admin select add bus list. Step8: validate the information
Step6: Admin fills the required data. Step9: The system displays message
successfully added.
Step7: click submits.
Step10: end use case.
Alternative
cores of action Step8.1.If the input information is invalid return to step8.
Step8.2 The use case continues Step3of the basic course of action
Post-condition New bus have been added and store to the database.
MTU, C S Page 29
Table 15 Use Case Description for placement
Use case name Placement.
Use case id U9
Actor Manager.
Description Manager assigns buss to route.
Pre-condition Must have login the system.

action
Step1: login to the system. Step3: display form
step2: click placement link. Step6: check validity.
Step4: manager fills the necessary Step7: The system assign buss to route
information. and send successful message
Step5: click submit button Step8: use case ends
Alternative 6.1 if the information is invalid then return to step4.

cores of action
6.2 The use case continues Step7of the basic course of action
MTU, C S Page 30
Table 16 Use Case Description for post info
Actor Manager.
Use case id U10
Use case name Post info.
Description This use case allow to post info.
Pre-condition The manager must have info.

action
Step1: The manager login to the system. Step3: The system displays the required
form.
Step2: The manager clicks post info
link. Step7: The system post info and
displays message successfully posted.
Step4: Admin fills the news.
Step5: submit to the form.
Alternative
cores of action
Post-condition The information haven been posted and.
MTU, C S Page 31
Table 17 Use Case Description for delete route
Actor Admin.
Use case id U11
Use case name Delete route
Description This use case allow deletion of existing route.
Pre-condition The route must have been available.
Basic cores of Actor action System response
Action Step1: login. Step3: The system displays the list
Step2: click manage delete route link Step5: The system displays the
Step4: select delete route. Exiting routes.
Step6: Admin select route Step7: validates information.
Step7: click delete button Step8: The system displays message

successfully deleted.
Step9: end use case.
Alternative Step 7.1.If the input information is invalid return to step4.

cores of action
Step7.2 The use case continues Step8 of the basic course of action
Post-condition existing route haven been deleted
MTU, C S Page 32
Table 18 Use Case Description for view report
Actor Manager.
Use case id U12
Use case name View report.
Description This use case allows to view report.
Pre-condition The manager must have login to the system.

action
Step1: The manager login to the system. Step3: the system display report list.
Step2: The manager click view report Step6: The system displays the report.
link.
Step4: the manager selects report.
Step5: press ok.
Alternative
cores of action
Post-condition The must have been logout.
MTU, C S Page 33
Table 19 Use Case Description for send complain
Actor Driver.
Use case id U13
Use case name Send complain.
Description This use case allow to post info.
Pre-condition The driver must have complain.

action
Step1: open home page Step3: The system displays the required
form.
Step2: The driver click send complain
link. Step7: The system send complain and
displays message successfully send.
Step4: Admin fills the news.
Step5: submit to the form.
Alternative
cores of action
Post-condition The complaint haven been send.
MTU, C S Page 34
Table 20 Use Case Description for generate report
Actor Clerk.
Use case id U14
Use case name Generate Report
Description Allows generate report
Pre-condition Clerk must have been login

action
Step3: Then system displays generate
report form
step1: the login to the system.
Step6: The report is stored in database
Step2: click generate report link.
and is also display
Step4: clerk enters the generated
report. Step7: report is successfully display.
Step5: Clerk and manager click submit Step8: The use case ends
button
Alternative
cores of action
Post-condition The report has been generated
MTU, C S Page 35
3.1.3Object model
In this section the group discuss all about the object modeling of the system which include
identifying class which the system constitutes and drawing their relationship using class diagram.
3.1.3.1Data Dictionary
1. Passenger
Table 21 data dictionary for passenger
Field name Data type Field size Constraint Description
Fname Char 25 Not null The first name of passenger
Lname Char 25 Not null The last name of passenger
Phone Number Int 20 Not null Mobile or home phone number of

the passenger
Address Char 30 Not null Address of the passenger
Age Date/time - Not null Date of birth of the passenger
Sex Char 6 Not null Sex of the passenger
Table 22 data dictionary for journey
Username Varchar 25 Primary key username of admin
Password Varchar 15 Not null Password of admin
MTU, C S Page 36
Table 23 data dictionary for reservation
Departure city Char 25 Not null Starting city of the reservation
Reservation amount Int 4 Not null No reservation
No of ticket Int 5 Not null No of ticket allocated for

reservation
Destination city Char 25 Not null Destination city of the

reservation
Departure Date Date/time 20 Not null Date of the journey
Fare Currency 10 Not null Price of the reservation
Reservation id Varchar 20 Primary key Reservation identity number
Table 24 data dictionary for route
Route id Varchar 25 Primary key Route identity number
Fare Currency 10 Not null Price of the route
Departure City Char 25 Not null Starting city of the route
Destination City Char 25 Not null Destination city of the route
MTU, C S Page 37
Table 25 data dictionary for schedule
Departure Time Date/time 20 Not null Departure time of the journey
Arrival Time Date/time 20 Not null Arrival time of the journey
Status Canceled/not - Not null Time table

canceled
Departure Date Date/time 20 Not null Departure date of the journey
Schedule id Varchar 20 Primary key Schedule identity number
Table 26 data dictionary for bus
No of seat Int 5 Not null No of seat of the bus
Plate number Varchar 10 Primary key Bus identity number
Table 27 data dictionary for account
Filed name Data type Field size Constraint Description
Username Varchar 25 Not null Username of ticket clerk and passenger
Password Varchar 25 Not null password of ticket clerk and passenger
MTU, C S Page 38
3.1.4.2Analysis level Class Diagram (Conceptual Modeling)

search
view
1 1
Passenger
1 Resrve Reservation journey

-pass phone:int
email: varchar
1
1
-journey date:varchar
-reservation-time:int 1 -journey time:int
+select()
1 pay -reservation-date-:date -from journey
+view available bus()
-reservation amount :int -to journey
send +get ticket()
-seat number
+display duration date()

+display duration time()
Cancel ticket +cancel()
request +reserve()
+get insert info()
- name:varchar
1
-res id:int
seat number:int
Payment
+set() Cancel ticket -cost amount:varchar

-res id:int
-account number:int
-cancel ticket date:varchar
-date:varchar
-cancel ticket time:int Schedule
-time:varchar
-res id:int
-payment amount -date:varchar
-cancel ticket
amount:double -time:int
view -bus plate:int
+pay deduct() -source city
+cancel reservation() +get cost amount() -des city
+get cancel ticket() -add()
+update()
Name +view()
cancel
update
1 update
1 1
Clark Admin
-Position:varchar 1
Account
-branch:varchar +Position:varchar
+view reservation 1 mange
1 1
+generate report() has 1
+update reservation() +mange account()
+update payment() +create() * +mange bus()
+cancel reservation() +delete() +mange route()
+view request
get branch()
1 *
Generate
1
Report has
mange
-title:text 1
Route
-content:text 1
-date:varchar Manger
-time:varchar -distance:varchar Seat
-departure city:enum
view
+mange account() 1 Assign to -destination city:enum -seat number:int
+get report title() +do placement() Bus +get seat number()
+assign bus to +assign to()
journey() +get distance()
-name:varchar
+update schedule()
-plate number;int 1
+view report()
-serial number:int
+post news() Assign
-number of seat:int
1 Link -level:varchar
plecement
user Account
-Assigned -time:int
Assigned -
-user name:varchar +assign() date:varchar
-password:varchar +get plate number() -source
1
-destination
+get user name()
-plate number:int
+get password()
person +get assigned
date()
-fname:varchar
-lname:varchar
-age:int
-sex:char
-phone:int
Driver 1
+get phone() -status
-drive licensee
+get drive licensee()
Figure 2 Class Diagram
MTU, C S Page 39
3.2 Dynamic model

Dynamic model is represented by sequence diagram, state chart diagram and activity diagram so
in the preceding section we briefly discuss about these diagrams.
3.2.1Sequence Diagram
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.
MTU, C S Page 40
Figure 3 Sequence diagram for log in
MTU, C S Page 41
Figure 4 Sequence diagram for cancel ticket.
MTU, C S Page 42
manage bus
Admin page add bus form controller Database
<<UI>>
Admin
login
click manage
bus link
display list
select add list
display form
fill form
click submit validation check
invalid
store
successfully
added
Figure 5 sequence diagram for add bus.
MTU, C S Page 43
view available bus

home page form controller Database
passing
er open
click view
available bus
link
Display form
fill form
click submit
validate
check
invalid
not exist
Display form
Figure 6 sequence diagram for view available bus.
MTU, C S Page 44
view placement
home page form controller Database
driver
login
click view
placement link
Display form
fill form
click submit
validation
check
invalid
not exist
Display
pacement
Figure 7 sequence diagram for view placement
MTU, C S Page 45
Figure 8 sequence diagram for create account.
MTU, C S Page 46
Figure 9 sequence diagram for cancel request.
MTU, C S Page 47
Figure 10 sequence diagram for cancel request
MTU, C S Page 48
Figure 11 activity diagram for login
MTU, C S Page 49
Start
Placement
Page
Fill form
incorrect
correct
Successfully
assigned
End
Figure 12 activity diagram for placement
MTU, C S Page 50
Start
Admin Page
Fill form
incorrect
correct
Successfully
added
End
Figure 13 activity diagram for add bus.
State chart modeling depicts the various states that an object may be in and the transition
between those states. A state represents the stages in the behavior pattern of an object and, like
UML activity diagram; it is possible to have initial states and final states.[Ambler, 2001]
MTU, C S Page 51
In our system there are some complex classes whose state chart are depict in bellow figure.
3.2.4User interface (navigational paths and screen mock-ups)

User interface
User interface design is the specification of the interaction between the system users and a
system. The process involves input mechanism design, output mechanism design, and navigation
mechanism.
 Navigation mechanism is part of user interface that takes the user form one part of the
system to the other user system. That includes menus or links, buttons, icons, dialog
boxes etc.
 Input design is about designing a form and its controls for GUI system.
 Output design is about designing reports like detailed, summarized, exceptional, graph,
chart, text document report and extra. This system some of the interface for user are the
following:
MTU, C S Page 52
On line ticket reservation & bus

placement system for tepi bus station
HOME RESERVATION SCHEDULE FARE TRAVEL RULE Available bus CONTACT US
USER NAME
PASSWORD **********
Tepi bus station is give transportation for
Many people . LOG IN
It established in 1989
TIME 12:00:05
2010 mizan tepi university
Figure 14: homepage interface
MTU, C S Page 53

HOME RESERVATION SCHEDULE FARE TRAVEL RULE CONTACT US LOG OUT
TIME 12:00:05
ON LINE RESERVATION
Departure tepi
Destination masha
Date 02/6/2010
Submit
2010 mizan tepi university
Figure 16: reservation interface
MTU, C S Page 54
1) Cancel ticket

TIME 12:00:05
CANCEL RESERVATION
Reservation id
Reservation date
Submit Clear
mm
2 Yfg2010
Figure 17: cancel ticket interface
MTU, C S Page 55
Online ticket reservation & bus

TIME 12:00:05
View schedule
Departure tepi
Destination mizan
Submit
2010 mizan Tepi University
Figure 19: view schedule interface
MTU, C S Page 56
CHAPTER FOUR
SYSTEM DESIGN
4.1Introduction
This project is designed in a manner that solves the problems of the organization by minimizing
the workload that appears on the employees, because of the existing system is manual system.
It provides more efficient, reliable and time saving system. In this project the team will design:
 How the project is designed
 What are tasks done under the whole project
 The different modules and their way of functioning are described here.
Generally the project will be designed by addressing all of the above criteria of project design. It
is designed to simplify functions of the manual system and it is capable of doing large amount of
works in short period of time with more accuracy and reliability.
This design system is to involve converting the description of the proposed system into logical
and then physical design specification.
4.1.1Purpose of the system
The purpose of this document is to provide an overview as to how to actually build the proposed
system and to obtain the information needed to derive the actual implementation of our system.
During the last phase we, the team has extensively worked on the system analysis to understand
what will be built. In many ways, this is a continuation of that work, only here we draw the
system closer towards implementation.
4.2 Current software architecture
Currently Tepi bus station uses a manual ticket reservation system. So that the manual system
does not have any software architecture
MTU, C S Page 57
4.3 Proposed software architecture

4.3.1Overview
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 a single 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.
4.3.2Subsystem 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 Subsystem
The user management subsystem controls the account of the system user.
The user here is a staff of bus station that would be allowed to use the system whose
authorization properties would determine his/her type of access. This subsystem will allow for;
 Addition of new users
 Removal of users
 Changing users passwords
Bus management system
this manages the bus schedule and fare details for each service. This subsystem allows for the
following;
 Schedule and number of buses assigned to a route.
 Modification of bus fare.
Route Management Subsystem
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.
Schedule Management Subsystem
Schedule subsystem which uses to control and manage the schedule of the system.
MTU, C S Page 58
Session management Session management control and manage the period of time which the
users spending using the system.
Account management subsystem

This subsystem is responsible for managing user account. It provides function for add user
account, updating user account, Administrator is the only actor who can communicate with this
sub system. This sub system uses login service of user account management sub system for
authenticating the administrator and also uses the storage sub system for storing account’s
information.
The operations provided by this sub system are:
 Login ()
 Create account()
 delete account ()
 Update account ()
Reservation Management System
Which provide and control reservation and cancelation of ticket and also uses to check the
availability of ticket. The automated system allows the traveler to use the OBPTRS to make
reservations and enquiries. It performs the following functions;
 Receives reservation request and send tickets for passengers.

 Changes passengers’ reservations request and updates account.
 Show available tickets and seat to passengers.
Database management subsystem

This subsystem is responsible for managing all the relevant information’s stored in the database
4.3.3Hardware/software mapping
The system will run in different machines, on the client machine, on the application server and
on the database server. The user interface will be implemented on client machine and send the
user’s requests. Application server will be dedicated to process the client requests .And on the
MTU, C S Page 59
database server WAMP Server will be installed and integrated with each subsystem which is
responsible for maintaining data manipulation operations.
Figure 14 software and hardware mapping
4.3.4Persistent data management

In this section the team describes how the persistent data stored by the system and the data
management infrastructure required for it. The system will use the MYSQL database server for
storing data. This will allow the database to be easily integrated with and accessed by the rest of
the system. The database will retain passenger information (name, password etc.), and also retain
configuration data such as authorized administrator. Each of these items will be store in a
separate table. The tables are:
 Passenger table: a table which store passenger’s information.
 Account table: a table which store user account.
 Admin table: a table which contain admin information.
 Ticket clerk: a table which contain clerk information.
MTU, C S Page 60
 Reservation table: a table which contain reservation information.

 Route table: a table which contains information related with route.
 Bus table: a table which contain bus information.
 Schedule table: a table which store information about schedule.
The purpose of this section is to show the mapping of the objects/classes of the system in to the
corresponding relational database tables.
4.3.5 Access control and security
Many levels of security protect sensitive documents and files from unauthorized viewers. Each
user has a security access level and each document has a sensitivity level. Depending upon the
access level of the user, they will see only the list of documents that is appropriate for their
security access level. Generally, all users have their own user names and passwords to control
security access levels and document sensitivity level.
The system accessed by different account levels:
 The administrator has been guaranteed to manage bus and route, generate report.
 manager has been guaranteed to assign bus to journey, placement and update schedule
 The ticket clerk has been guaranteed to update reservation and update payment states.
 The passenger has been allowed to reserve a seat, check availability of ticket, view
schedule, and cancel reserved ticket.
 The driver assistance has been guaranteed to check availability of ticket
4.4 Subsystem services
As mentioned in the analysis phases the system provide different services so below are those
services which is provided by subservices listed:
 Assigning bus to the route
 Updating and viewing schedule
 Add and deleting route
 Reserving and canceling of ticket
MTU, C S Page 61
4.5Component Diagram
reserve
payment
cancel ticket
request
passenger
set
schedule
clerk account
persistence
Include
report
manger
login
comment
admin
bus
route tepi bus

station DB
driver
view
placement
Figure 15 component diagram
MTU, C S Page 62
4.6Deployment Diagram
The deployment diagram shows how the software components, processes, and objects are
deployed into the physical architecture of the system. It shows the configuration of the hardware
units (e.g. Computers, communication devices, etc.) and how the software components are
distributed across the units. The deployment diagram for our project is presented below.
<internet>
client Mysql server
wab
browser,Internet,explor database:Mysql server
e
ticket form
persistence
online
ticketreservat
ion &bus online
plalcment ticketreserv
placementt
ation &bus
plalcment
DB
Figure 16 deployment diagram
REFERENCES
1. [Ambler 2001] the object primer second edition (Scott W. Amber)
2. System Analysis and Design Methods (in Analysis and Design Phase)
3. Object Oriented System Analysis and Design (OOSAD)
MTU, C S Page 63
4. Reservation System Using Unified Modeling Language. International Journal of Scientific

knowledge Available at:
5 http://www.ijsk.org/uploads/3/1/1/7/3117743/v3i103_information_technology.pdf Accessed
13th December 2014
MTU, C S Page 64

Online Ticket Reservation and Bus Placem

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Ticket Reservation and Bus Placem

Uploaded by

Copyright:

Available Formats

Online Ticket Reservation And Bus placement System 2018

Bachelor of Science in computer science.

1 Amsal Gezu SCIR / 039/07

2 Hana Damota SCIR/ 160/07

3 Melkam Alemu SCIR/211/07

4 Muluken Semaw SCIR/ 240/07

School of Computing and Informatics

Department of Computer Science

Online ticket reservation and bus placement

1. Amsal Gezu SCIR/039/07

2. Hana Damota SCIR/160/07

3. Melkam Alemu SCIR/211/07

4. Muluken Semaw SCIR/240/07

Name and signature of member of examining board

Name Title Signature Date

________ Chairperson _____ _______

Emenet zewdu Adviso _______ _______

________ Examiner, _______ _______

Examiner, __________ ___________

Name Signature Date

Amsal Gezu _______ _______

Hana Damota _______ _______

Melkam Alemu _______ ______

Muluken Semaw _______ _______

Name Signature Date

Emenet ____________ ____________

1.8 Significance of the project ...................................................................................................................... 7

MTU,C S Page iii

3.1.4.2Analysis level Class Diagram (Conceptual Modeling) .................................................................... 39

Table 1 team composition ............................................................................................................................ 2

Table 6 use case description for login ......................................................................................................... 20

Figure 1 use case diagram ............................................................................................................ 19

Figure 7 sequence diagram for view placement .......................................................................... 45

DBMS---------------------Database Management System

MYSQL-------------------My structural Query Language

MTU------------------------Mizan Tepi University

OOA-------------------------Object Oriented Analysis

OOD-------------------------Object Oriented Design

PIECES--------------------Performance Information Economics Control Efficiency Service.

SMS--------------------------Short Message Service

SRS---------------------------System Requirement Specifications

UML--------------------------Unified Modeling Language

MTU,C S Page vii

MTU,C S Page viii

Table 1 team composition

Task name Group member

System Requirement and specification (SRS) Amisal

Analysis and Design Mullen

Implementation and Testing Hana

Table 2 communication plan

1.5 Objective of the Project

 It determines the potential of the existing system.

 To determine all goals of the new system.

Table 3 materials cost for existing system

Materials cost for existing system

Item Quantity per year Unit price/salary Total price/salary per

Papers 300 packet 80 birr 24,000 birr

Pen 20 packet 40 800 birr

Labor cost 14 labor 1000 168,00 birr

Total materials cost 192,800 birr

Table 4 materials cost for proposed system

Materials cost for new system

Item Quantity per year Unit price/salary Total price/salary per

Labor cost 6 person 1000 6000 birr

______ Chairperson _ _____

Emenet zewdu Adviso _ _

____ Examiner, _ _____

Examiner, _

Amsal Gezu _ _

Hana Damota _ _

Melkam Alemu _

Muluken Semaw _ _

Emenet