SAMARA UNIVERSITY

ENGINEERING AND TECHNOLOGY COLLEGE

DEPARTMENT OF COMPUTER SCIENCE

PROJECT TITILE: ONLINE BUS TICKET RESERVATION

SYSTEM FOR SELAM BUS TRANSPORT
BY
GROUP MEMBER

1. ABRHAM SORECHA
2. HABTAMU TAYE
3. SEBHADIN NASRI
4. RAHEL AMHA
5. ZENEBE WORKU
6. KASAHUN TADELE

ADVISOR: ABEL DAMTEW

JANUARY, 2014
 SAMARA UNIVERSITY

ENGINEERING AND TECHNOLOGY COLLEGE

DEPARTMENT OF COMPUTER SCIENCE

A PROJECT SUBMITTED TO THE DEPARTMENT OF COMPUTER

SCIENCE OF SAMARA UNIVERSITY IN PARTIAL
FULFILLMENT FOR THE REQUIREMENTS FOR THE DEGREE
OF BACHELOR OF SCIENCE IN COMPUTER SCIENCE

GROUP MEMBER

1. ABRHAM SORECHA
2. HABTAMU TAYE
3. SEBHADIN NASRI
4. RAHEL AMHA
5. ZENEBE WORKU
6. KASAHUN TADELE

Name and signature of member of examining board

Name Title Signature Date

________ Chairperson _________ _______

Abel Damtew Advisor, _________ _______

________ 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

AbrhamSorecha ____________ __________

HabtumuTaye ____________ __________

SebhadinNasir ____________ __________

RahelAmha ___________ __________

ZenebeWorku ____________ __________

KasahunTadele ____________ __________

This project has been submitted for examination with my approval as university advisor.

Name Signature Date

Abel Damtew ____________ ___________

 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. kindu who is Selam bus share line
ticket attendant for giving us necessary information.

1
 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 require to complete the project is 8 month so the team divide
the work for every month to finish on time.

2
 Table of Contents
ACKNOWLEDGEMENT ...................................................................................................................... 1
ABSTRACT............................................................................................................................................ 2
ACRONYMS .......................................................................................................................................... 6
LIST OF TABLES .................................................................................................................................. 7
LIST OF FIGURE................................................................................................................................... 8
CHAPTER ONE .................................................................................................................................. viii
INTRODUCTION .................................................................................................................................. 2
1.1 BACKGROUND .......................................................................................................................... 2
1.2 STATEMENT OF PROBLEM ..................................................................................................... 3
1.3 LITERATURE REVIEW ............................................................................................................. 3
1.4 OBJECTIVE ................................................................................................................................. 4
1.4.1 General Objective ............................................................................................................. 4
1.4.2 Specific Objective ............................................................................................................. 4
1.5 MATERIALS AND METHODS .................................................................................................. 4
1.5.1 Site of the study ................................................................................................................ 5
1.5.2 Method of data collection ................................................................................................. 5
1.5.3 System Implementation Tools .......................................................................................... 5
1.5.3 Tools or instrument ........................................................................................................... 5
1.5.4 Development methodology ............................................................................................... 6
1.6 SIGNIFICANCE OF PROJECT ................................................................................................... 7
1.7 SCOPE AND LIMITATION ........................................................................................................ 8
1.8 TEAM PROFILE .......................................................................................................................... 9
CHAPTER TWO .................................................................................................................................. 10
SYSTEM REQUIRMENT SPECIFICATION ..................................................................................... 10
2.1 INTRODUCTION ...................................................................................................................... 10
2.2 CURRENT SYSTEM ................................................................................................................. 10
2.2.1 Overview ......................................................................................................................... 10
2.2.2 Problems Of Current System .......................................................................................... 11
2.3 PROPOSED SYSTEM ............................................................................................................... 11
2.3.1 Overview ......................................................................................................................... 11
2.3.2 Goals Of Proposed System ............................................................................................. 11
2.3.3 Functional Requirements ................................................................................................ 12
2.3.4 Non Functional Requirements ........................................................................................ 13
2.3.4 Constraints ...................................................................................................................... 14

3
 2.3 SCENARIOS .............................................................................................................................. 14
2.4 SYSTEM MODELS ................................................................................................................... 16
2.4.2 Use case model ............................................................................................................... 16
2.5.3 Object model ................................................................................................................... 28
2.5.4 Dynamic model ............................................................................................................... 32
2.5 INTERFACE-NAVIGATIONAL PATHS AND SCREEN MOCK-UPS.................................. 41
2.5.1 Passenger interface.......................................................................................................... 42
2.5.2 Administrator interface ................................................................................................... 48
CHAPTER THREE .............................................................................................................................. 50
SYSTEM DESIGN ............................................................................................................................... 50
3.1 INTRODUCTION ...................................................................................................................... 50
3.1.1 Design Goals ................................................................................................................... 50
3.2.3 End User Characteristics ................................................................................................. 51
3.2 CURRENT SYSTEM ARCHITCTURE .................................................................................... 52
3.3 PROPOSED SYSTEM ARCHITECTURE ................................................................................ 52
3.3.1 Overview ......................................................................................................................... 52
3.3.2 Subsystem Decomposition .............................................................................................. 52
3.3.3 HARDWARE AND SOFTWARE MAPPING .............................................................. 52
3.3.4 Persistent Data Management ........................................................................................... 54
3.3.5 Access Control And Security .......................................................................................... 54
3.4 SUBSYSTEM SERVICE ........................................................................................................... 55
CHAPTER FOUR................................................................................................................................. 56
IMPLEMENTATION AND TESTING................................................................................................ 56
4.1 IMPLEMENTATION OVERVIEW........................................................................................... 56
4.1.1 OBJECTIVES OF IMPLEMENTATION ..................................................................... 56
4.1.2 CONSTRAINT OF IMPLEMENTATION .................................................................... 56
4.1.3 TOOLS AND ENVIROMENT....................................................................................... 56
4.2 SAMPLE CODE AND DESCRIPTION .................................................................................... 57
4.3 TESTING OVERVIEW.............................................................................................................. 67
4.3.1 TEST BY SCOPE ........................................................................................................... 67
4.3.2 TEST IMPLEMENTATION(Validation testing) ........................................................... 68
CHAPTER FIVE .................................................................................................................................. 68
USER MANUAL .................................................................................................................................. 69
5.1 USER MANUAL ........................................................................................................................ 69
5.2 INSTALLATION GUIDE .......................................................................................................... 70
5.3 SYSTEM REQUIREMENT ....................................................................................................... 70

4
CHAPTER SIX ..................................................................................................................................... 70
CONCLUTION AND RECOMMENDATIO ...................................................................................... 70
6.1 CONCLUTION........................................................................................................................... 71
6.2 RECOMMENDATION .............................................................................................................. 71
REFERENCE........................................................................................................................................ 71

5
 ACRONYMS

OBTRS: Online bus ticket reservation system

HTML: Hypertext markup language

PHP: Hypertext preprocessor

CSS: Cascading style sheet

UML: Unified modeling language

HTTP: Hypertext transfer protocol

ADMIN: Administrator

UC: Use case

6
LIST OF TABLES
Table 1: Scope of the project…………………………………………………………………..8

Table 2: Team configuration………………………………………………………………..…9

Table 3: scenario for making reservation…………………………………………………….15

Table 4: scenario for adding route…………………………………………………………....15

Table 5: scenario for updating schedule……………………………………………………...16

Table 6: List of Actors and Use Cases associated with the new system………………….…17

Table 7: use case description for register use case………………………………………..…19

Table 8: use case description for log in use case…………………………………………....20

Table 9: use case description for reserve ticket use case………………………………..…..21

Table 10: use case description for check ticket availability use case………………………..22

Table 11: use case description for ticket cancelation use case……………………………….23

Table 12: use case description for view schedule use case………………….……………….24

Table 13: use case description for generate report use case………………………………….25

Table 14: use case description for add route use case…………………………….…………25

Table 15: use case diagram for delete route use case………………………………………..26

Table 16: use case of update journey information use case…………………………………27

Table 17: use case description for assign bus to the journey……………………………….28

Table 18: data dictionary for passenger………………………………………….………….28

Table 19: data dictionary for journey……………………………………………………….28

Table 20: data dictionary for reservation……………………………………………….……29

Table 21: data dictionary for route………………………………………………………..…29

Table 22: data dictionary for schedule……………………………………………………….29

Table 23: data dictionary for bus……………………………………………………………..29

7
LIST OF FIGURE
Figure 1: use case diagram………………………………………………………………18

Figure 2: class diagram………………………………………………………………….31

Figure 3: sequence diagram for log in…………………………………………………..32

Figure 4: sequence diagram to update schedule…………………………………………33

Figure 5: sequence diagram to add route………………………………………………..34

Figure 6: sequence diagram to reservation……………………………………………….35

Figure 7: state chart diagram for passenger……………………………………………….36

Figure 8: activity diagram for log in……………………………………………………….37

Figure 9: Activity diagram for reservation…………………………………………………38

Figure 10: activity diagram for view schedule……………………………………………..39

Figure 11: activity diagram for add route…………………………………………………..40

Figure 12activity diagram for update schedule…………………………………………….41

Figure 13: homepage interface……………………………………………………………..42

Figure 14: Passenger registration interface…………………………………………………43

Figure 15: reservation interface…………………………………………………………….44

Figure 16: cancel ticket interface…………………………………………………..………45

Figure 17: check ticket availability interface……………………………………………….46

Figure 18: view schedule interface…………………………………………………………47

Figure 19: add bus interface…………………………………………………………………48

Figure 20: add route interface……………………………………………………………….49

Figure 21: deployment diagram……………………………………………………………..53

8
 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. Selam Bus Line Share 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.[1](seen in 12/11/2013 at 5:30pm)

At present the company is rendering service from Addis to Diredawa, Harrer, Jijiga, jimma,
Bahirdar, Gondor, Dessie&Mekelle, Shire, Assosa, ArbaminchandMoyale 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
2
the passengers are expected to serve as the ambassadors of the region.[2] (seen in 12/11/2013
at 5:30pm)

1.2 STATEMENT OF PROBLEM

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.

1.3 LITERATURE REVIEW

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.[3]
Hasanhuseyinkoyunand Ayseorhan in there project which is done inJune 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.[3]

The main activity of a bus reservation system is reserving a seat for passengers who:

 Need a drive to the another city

 Want to make a short business/leisure trip

3
  Do not have time to go to the office
 Reserve online
Duygukandemir andHasankarpuzciin there project which is done in December 2012 online
bus ticket reservation system is a strong system that used to make reservation easier, faster
and safer which is useful to make passengers happy and do not make companies embarrassed
against customer.[4]
Most projects try to solve the problems happen that are related with manual ticket system by
making all work computerized but in our case we are not intend to make the whole system
computerized because in our case there is no money transaction which is online money
transfer.
1.4 OBJECTIVE

1.4.1 General Objective

 To develop online reservation system that will replace the manual ticketing system.

1.4.2 Specific Objective

In addition to general objective the project will also contains the following specific
Objective:-

 To design a user friendly system.

 To enable customer to reserve and cancel ticket online.
 To enable customer to see schedule online.
 To enable customer to check the availability of the ticket online.
 To enable the company to add and delete bus information.
 To enable the company to add and delete route.
 To provide anytime service if the connection is available, customer can reserve a seat
24 hour a day and 7 days a week over the internet.

1.5 MATERIALS AND METHODS

4
1.5.1 Site of the study

The system is developed for Selam Bus ShareLine Company.

1.5.2 Method of data collection

The method of Requirement gathering that is used on this project includes phone interviews
and document analysis to collect/ gather information and data of the existing system to
develop new system.

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.

Document analysis: reading the document available in the organization site.[4](seen in

12/11/2013 at 5:30pm)

1.5.3 System Implementation Tools

The tools that we have used in accomplishing the project are;

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.

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

1.5.3 Tools or instrument

5
In the process of developing the system we use different hardware tools and software tools.

Hardware tools

 Laptop or desktop
 Cd
 Flash disk

Software tools

 Macromedia Dreamweaver MX: it is web development tool that enabling users to

efficiently design develop and maintain standards-based websites and applications.
 Microsoft word 2007: it is software that we use to write our system documentation.
 Microsoft PowerPoint 2007: is software that we use for presentation purpose.
 Apache server: is a server which let us to use client computer as client and server.
 Microsoft Visio 2007: is software which we used to draw unified modeling diagram.
Such as sequence diagram.
 Edraw max: it is a software which used to draw the user interface of the system.
 Web browser: the web browser such as Mozilla, internet explorer and Google
chrome use to see our system.
 Adobe Photoshop CS4:itused to edit photo.

1.5.4 Development methodology

The team will follow Object Oriented System Development methodology (OOSD). Object
oriented methodology define system as a collection of interacting objects.

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

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

The team 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.6 SIGNIFICANCE OF PROJECT

The project is very important to the organization and company’s customer

For the company

 It increases their profit by making their expenditure less.

 It increases customer satisfactions.
 It reduces the required man power.
 It helps the company to handle customer information in an organized way.

For the customer

 It reduces the wastage of time and money.

7
1.7 SCOPE AND LIMITATION

In this section the team identify the scope and limitation the project so the following table
shows the scope and limitations of the project.

Table1: scope and limitation

In scope Out scope or limitation

- Reservation systems - Automating payment system

- Generate report - Serving customers out of the
- Show schedule concerned destination
- Show availability of ticket - Machine/man recognition method
- Cancellation of ticket - Email subscription
- Add and update schedule - Account recovery
- Add and delete bus information
- Add and delete route

8
1.8 TEAM PROFILE

In our project, we have six (6) 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 2: Team configuration

Task Name Student Name Phone number

Project manager AbrhamSorecha 0910585834
System analyst ZenebeWorku 0914465333
SebahadinNesir 0920739581
KasahunTadele 0931535405
System designer RahelAmha 0921332891
HabtamuTaye 0921007549
Programmer AbrhamSorecha 0910585834
Testing All team -

Project adviser Mr. Abel Damtew

9
 CHAPTER TWO

SYSTEM REQUIRMENT SPECIFICATION

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.[5]So in this chapter the team discuss about current system,
proposed systemand at last system model.

2.2 CURRENT SYSTEM

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:

 What is there phone number?

 Where they want to go?
 When they want go?

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.

10
2.2.2 Problems Of Current System

As we mentioned in section 1.3 the current system has several problems which is described
below:

 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 PROPOSED SYSTEM

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.

2.3.2Goals Of Proposed System

The modern computerized system is developed with the aim to overcome the drawbacks of
manual system. The proposed system has got many advantages. People from different parts
of the region can register very easily. The new system is more personalized which means a
passenger require to a user account to access the fruit of the system. We do this to secure the
system from unauthorized act of the system users.

11
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 arelisted 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

2.3.3 Functional Requirements

Functional requirements are statement of services the system should provide, how the system
should react to particular inputs and how the system should behave in particular situation.
Below is the functional requirements of the system are listed:

 The system enables Administrator toadd,update,routes and datesofbus.

 The system allowspassenger register to become a member of the system.
 The system allows a registered user to reserveticketsonline.
 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

12
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

2.3.4.1 Look and feel requirement

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.

2.3.4.2 Usability requirement

 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

2.3.4.3 Security requirement

To use the system auser 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.

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

2.3.4.5 Portability requirement

The OBTRS is a web based applicationso 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

The proposed project is supposed to have the following constraints: -

 Inconvenience (Lack of adequate information):- There were problems while

eliciting requirements because the company employees were busy by serving
customer and some of them were not willing to provide information.

 Time constraint:-The time allotted for the project was not enough to complete the
project.

 Lack of internet access

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:

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

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

2.4 SYSTEM MODELS

In this section we will discuss about scenarios of the system, use casemodelling, object model
and dynamic model of the new system.

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

Table 6: List of Actors and Use Cases associated with the new system.

16
Actor Use case

Administrator  Log in
 Generate report
 Add/ Delete/View route
 Add/Delete bus
 Register ticket clerk
 Add/Delete news
 View comment
Ticket clerk  Log in
 Add/Delete/Update schedule
 Make/Delete/View reservation
 Add/Delete driver
 View route and registered passenger
Passenger  Register
 Log in
 Reserve ticket
 Check availability of ticket
 Cancel ticket
 View schedule

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

System

Register

Add/Delete/Update
sechedule

ticket cleark
Cancel ticket

<<extends>> Make/cancel/view
reservation
<<Include>>
Make Reservation

<<Include>> <<Include>>

<<Include>> <<Include>> Generate report

Check availability log in
Passenger of ticket
<<Include>>
<<Include>> Add/delete/view
route

<<Include>>
<<Include>>
Give comment
Add/delete/view bus
<<Include>>
Adminstrator

view schedule
Register/delete
cleark

Figure 1: use case diagram

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

18
 1) Register

Table 7: use case description for register use case.

Use case name Register

Actor Passenger and ticket clerk
Description This use case allows the passenger to be a
member of the system.
Pre-condition None
Post-condition Passenger can be the member of the system
Basic course of action 1. Passenger launches the system.
2. The system displays the homepage.
3. Passenger browses system.
4. The system display register form
5. Passenger fills the form and submits
the form to the system.
6. The system check the filled
information
7. Passenger can be a member.
8. Use case end
Alternative course of action AC1: Passenger may miss to fill their form
 Error message display
 Display the registration
AC2: The system may failed to connect with
database

19
2) Log in

Table 8: use case description for log in use case.

Use case name Log in

Use case identifier UC2
Actor Administrator(admin),passenger and clerk
Description It allows the existing user to login

Pre-condition Passenger or admin or clerk must have valid

user name and password.
Post-condition Passenger logs in to the system.

Basic course of action 1. Passenger or admin or clerk launch the

system.
2. Passenger or admin or clerk browse
home page.
3. The system displays the login dialog
box.
4. Passenger or admin or clerk fills user
name and password and submits it to
the system.
5. The system checks the login
information whether it is valid.
6. Passenger or admin or clerk gets user
profile.
7. Use case ends.
Alternative course of action AC1: If the Passenger or admin or clerk enter
incorrect username and password
combination the system display error
message and the log in form display again

Special requirements  A user must have username and

password

20
3) Reserve ticket

Table 9: use case description for reserve ticket use case.

Use case name Reserve ticket

Use case identifier UC3
Actor Passenger
Description It allows the user to enter the passenger
details
Pre-condition The passenger mustlog in to the system.
Post-condition The passenger will reserves a ticket
Basic course of action 1. Passenger launches the system.
2. The system displays the homepage.
3. Passenger log in to the system.
4. Passenger browses the reservation
page.
5. The system displays the reservation
form.
6. Passenger fills the destination and
departure in the form then submits the
form.
7. The system gives back the reservation
id and journey information.
8. Use case end
Alternative course of action AC1:
 If the passenger fills incorrect
combination of departure and
destination the system displayed error
message.
AC2:
 If the passenger tries to submit
incomplete form, the system display
error message.

21
 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

Use case name Cancel ticket

Use case identifier UC4
Actor Passenger
Description It allows the passenger to cancel the reserved
ticket
Pre-condition The passenger must log in to the system.
Post-condition The reserved ticket will be cancelled.
Basic course of action 1. Passenger launches the system.
2. The system displays the homepage.
3. Passenger log in to the system.
4. Passenger browses the ticket
cancelation form.
5. The system displays the ticket
cancelation form.
6. Passenger fills the required data and
submits the form.
7. The system display confirmation of
ticket cancelation.
8. Use case end.
Alternative course of action AC1:
 If the passenger fills wrong data the
system display the error message and
gives the cancelation form again.

22
Special requirements  A passenger must reserve ticket

5) Check availability of ticket

Table 11:use case description for check ticket availability use case

Use case name Check availability of ticket

Use case identifier UC5
Actor Passenger
Description This use case allow the passenger to check if
the ticket is available
Pre-condition The passenger must log in to the system.
Post-condition Shows the availability of ticket
Basic course of action 1. Passenger launches the system.
2. The system displays the homepage.
3. Passenger access system via UC2.
4. Passenger browses the check ticket
availability page.
5. The system displays the required
page.
6. Passenger fills the required data then
submits the form.
7. The system gives the status of the
ticket.
8. Use case end.
Alternative course of action AC1:
 If passenger fills incorrect data the
system displays error message and the
check availability page.
AC2:
 If incomplete form is submitted the
system display error message and the
check availability page.

23
6) View schedule

Table 12: use case description for view schedule use case

Use case name View schedule

Use case identifier UC6
Actor Passenger
Description This use case allows the passenger to see
information related with journeys.
Pre-condition The passenger must log in to the system.
Post-condition It will show fare and time of the journeys.
Basic course of action 1. Passenger launches the system.
2. The system displays the homepage.
3. Passenger access the system via UC2.
4. Passenger browses schedule page.
5. The system displays the required
page.
6. Passenger fills the required data then
press search.
7. The system displays the information
related with the search.
8. Use case end.
Alternative course of action AC1:
 If the passenger fills incorrect data the
system displays error message and the
view information page.

24
7) Generate report.

Table 13: use case description for generate report use case

Use case name Generate report

Use case identifier UC7
Actor Administrator
Description This use case allow to generate report about
every journey
Pre-condition Administrator must log in to the system.
Post-condition It will generate report
Basic course of action 1. Administrator launches the system.
2. The system displays the homepage.
3. Administrator log in to the system.
4. Administrator browse the generate
report page.
5. The system displays the requested
page.
6. Admin generate report.
7. The system displays message
successfully compilation of use case.
8. Use case end.
Alternative course of action None

8) Add route

Table 14: use case description for add route use case.

Use case name Add route

Use case identifier UC8
Actor Administrator
Description This use case allow addition of a new route
Pre-condition Administrator must log in to the system.
Post-condition New route will be added to the database.

25
Basic course of action 1. Admin launches the system.
2. The system displays the homepage.
3. Admin log in to the system.
4. Admin browses’ the add route page
5. The system displays the requested
page.
6. Admin fills the required data then
submit the form.
7. The system displays message
successfully compilation of use case.
8. End of use case.
Alternative course of action AC1:
 If admin fill incorrect data the system
display error message and the add
route form.
Special requirements

9) Delete route

Table 15: use case diagram for delete route use case

Use case name Delete route

Use case identifier UC9
Actor Administrator
Description This use case allow route deletion
Pre-condition Administrator must log in to the system.
Post-condition Route will be deleted
Basic course of action 1. Admin launches the system.
2. The system displays the homepage.
3. Admin log in to the system.
4. Admin browses’ thedelete route page
5. The system displays the requested
page.

26
 6. Admin fills the required data then
submit the form.
7. The system displays message
successfully compilation of use case.
8. End of use case.
Alternative course of action AC1:
 If admin fill incorrect data the system
display error message and the delete
route form.

10) Update schedule

Table 16: use case of update journey information use case.

Use case name Update schedule

Use case identifier UC10
Actor Ticket clerk
Description This use case allow to update schedule
Pre-condition Administrator must log in to the system.
Post-condition Fare and time of the journey will be updated.
Basic course of action 1. Ticket clerk launches the system.
2. The system displays the homepage.
3. Admin browse the update schedule
page.
4. The system displays the requested
page.
5. Admin update the information that
supposed to be updated and submit it
to the database.
6. The system displays message
successfully compilation of use case.
7. End of use case.
Alternative course of action AC1:

27
  If admin fill incorrect data in to the
update schedule form the system will
display error message and the update
information page.

2.5.3 Object model

In this section the team discuss all about the object modeling of the system which include
identifying class which the system constitute and drawing their relationship using class
diagram.

2.5.3.1 Data dictionary

1. Passenger
Table 18: 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
Username Varchar 20 Primary Username of passenger
key
Password Varchar 20 Not null Password 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

2. Administrator
Table 19: data dictionary for journey

Field name Data type Field size Constraint Description

Username Varchar 25 Primary key username of admin
Password Varchar 15 Not null Password of admin

28
3. Reservation
Table 20: data dictionary for reservation

Field name Data type Field size Constraint Description

Departure city Char 25 Not null Starting city of the
reservation
Destination city Char 25 Not null Destination city of the
reservation
Departure Date Date/time 20 Not null Date of the journey
Reservation id Varchar 20 Primary key Reservation identity number

4. Route
Table 21: data dictionary for route

Field name Data type Field size Constraint Description

Route id Varchar 25 Primary key Route identity number
Price 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
Bus id int 10 Not null Assigned bus id

5. Schedule
Table 22: data dictionary for schedule

Field name Data type Field Constraint Description

size
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 Status of the schedule either
canceled cancel or not cancelled
Departure Date Date/time 20 Not null Departure date of the journey
Schedule id Varchar 20 Primary key Scheduleidentity number

29
6. Bus
Table 23: data dictionary for bus

Field name Data type Field size Constraint Description

No of seat Int 5 Not null No of seat of the bus
Bus id Varchar 10 Primary key Bus identity number

7. Account
Table 24: 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

30
2.5.3.2 Class diagram

Reservation
Passenger -Dearture city : char
-Age : int -Destination city : char
-city : string 1 1 -Departure date : Date
-Username : String reserve -Fname : string
-Password : string -Lname : string
+create account() 1 -Telephone : int
+reserve() +reservation counter()
+cance ticket() +reservationid counter()
+see secdule()
*
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()

Figure 2: class diagram

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

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

Sequence diagram for log in

Home page Login form Log in controler User account Databse

Passenger

Browse

Request login form

Display

Enter password and account

Log in Create

Invalid Store

Display

Figure 3: sequence diagram for log in

32
Sequence diagram for update schedule

Homepage Log in form Lgg in controler Update schedule

Ticket clark

Browse

Request log in form

Dispay

Enter the requirment

Log in

Invalid

Request for schedule update

Display

Enter the requirment

Display success

Figure 4: sequence diagram to update schedule

33
Sequence diagram for add route

Homepage Log in form Log in controler Add route Database

Admin

Browse
Request for log in

Display

Enter password and account

Log in

Invalid

Request for add route

Display

Enter the required data

Store

display successful complation message

Figure 5: sequence diagram to add route

34
Sequence diagram for Reservation

Home page Lg in form Log in controler Reservation form

Passenger

Browse
Request log in form

Display

Enter password and account

Log in

Invalid

Request for reservation

Display

Enter the requirment

Success

Figure 6: sequence diagram to reservation

35
2.5.4.2 State chart diagram

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

Registration Check avilibilty of ticket

Make reservation

Cancel reservation

Incorrect
Not avilable data

cancel

Figure 7: state chart diagram for passenger

36
2.5.4.3 Activity diagram

Activity diagramfor log in use case

launch the system

access hompage

browse log in form

access log in form

Enter password and usernam Invalid entry

Valid entry

Access the system

Figure 8: activity diagram for log in

37
Activity diagram for reservation

launch system access hompage log in access system

browse reservation form

access reservation form

Fill the required data

Invalid enry

Submit the form

if ticket is not avilable

Valid entry

successfuly reserve

Figure 9: Activity diagram for reservation

38
Activity diagram for view schedule

launch system display hompage log in

access system

browse scedule page

access scedule form

fill the required data Invalid data

click submit

Valid data

schedule display

Figure 10: activity diagram for view schedule

Activity diagram for add route

39
 launch system access hompage log in

access system

browse add route form

access the requested form

fill the form

Invalid entry

submit the form

Valid entry

add route successful

Figure 11: activity diagram for add route

Activity diagram for update schedule

40
 launch system acess homepage log in access system

browse the update form

access update form

fill required data

Invalid entry

submit form

Valid entry

successful compilation of update schedule

Figure 12: activity diagram for update schedule

2.5 INTERFACE-NAVIGATIONAL PATHS AND SCREEN MOCK-UPS

In this system users will communicate with it through the following user interfaces.

41
2.5.1 Passenger interface

1) Homepage

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.

Figure 13: homepage interface

42
2) Passenger Registration form

Figure 14: Passenger registration interface

43
3) Reservation form

Figure 15: reservation interface

44
 4) Cancel ticket

Figure 16: cancel ticket interface

45
 5) Check ticket availability

Figure 17: check ticket availability interface

46
6)View schedule

Figure 18: view schedule interface

47
2.5.2 Administrator interface

1) Add bus

Figure 19: add bus interface

48
 2) Add route

Figure 20: add routeinterface

49
 CHAPTER THREE

SYSTEM DESIGN

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

3.1.1 Design Goals

The design goals describe the qualities of the system that developers should improve. Design
goals are normally derived from the non-functional requirements of the system. So the
followings section describe the design goals of the system:

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

50
Dependence

 The system should haveability 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.

3.2.3 End User Characteristics

The passenger, who will from now on called the ‘end user’, will be presented with two
choices by the reservation system, as the first step in the interaction between them. A user can
choose one of these and his choice would be governed by whether he is a guest or a registered
user. The terms ‘registered user’ and ‘guest’ are described below.
A user who uses the system earlier would have been given a user id and a password. They
would have there personal information stored in the database referred to earlier. Such a user
is called a ‘registered user’. A registered user will be able to check the availability of tickets
as well as make a reservation by logging into the system.

A new user, on the other hand, would either have to

a) Log into the system as a guest.

b) Register himself with the system by providing personal information.
The other end user of the system is ticket clerk who has username and password, by their
password and username they log in to the system and perform their responsibility such as
updating schedule and updating reservation.

51
3.2 CURRENT SYSTEM ARCHITCTURE

Currently Selam Bus Line Share uses a manual ticket reservation system. So that the manual
systemdoes not have any software architecture.

3.3 PROPOSED SYSTEM 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.

3.3.3 HARDWARE AND SOFTWARE MAPPING

52
In this section the team discuss about the overall hardware and software organization of the
system so deployment diagram are required to show system hardware/software mapping.

3.3.3.1 Deployment Diagram

<<Web server>>
<<Client machine>>

Apache server
Web Browser

http

php

http

<<Database server>>

MYSQL

Figure 21: deployment diagram

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.

53
3.3.4 Persistent 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.

As described in the Section 2.5.3.2 the system contain eight(8) table which is stored in
MYSQL server. These tables are:

 Passenger table: a table which store passengers information.

 Account table: a table which store user account.
 Admin table: a table which contain admin information.
 Clerk: a table which contain clerk information.
 Reservation table: a table which contain reservation information.
 Route table: a table which contain information related with route.
 Bus table: a table which contain bus information.
 Schedule table: a table which store information about schedule.

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

54
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:

 Assigning bus to the route

 Updating and viewing schedule
 Add and deleting route
 Reserving and canceling of ticket

55
 CHAPTER FOUR

IMPLEMENTATION AND TESTING

4.1 IMPLEMENTATION OVERVIEW

In this chapter the team focuses on the implementation part, implementation concerned with
the type of material (Hardware and Software required), objectives of implementation, code
samples of the system, some testing techniques.

4.1.1 OBJECTIVES OF IMPLEMENTATION

The objective of systems implementation phase is to convert the final physical system
specifications into working and reliable system, document the work that has been done, and
provide help for current and future users and caretakers of the system.

4.1.2 CONSTRAINT OF IMPLEMENTATION

Constraints are situations that limits on implementing the new system. Some of the things
that limit us on developing the new system are:
 The RAM speed of the computes

 Lack of backup device

 Lack internet access

4.1.3 TOOLS AND ENVIROMENT

For the project implementation; the following Software and hardware are used.

4.1.3.1 Hardware Components

For the System implementation the following hardware are used.

 Laptop
 Desktop
 Flash disk

56
 4.1.3.2 Software Components

For the System implementation the following software are used.

 Macromedia Dreamweaver 8
 WAMPSERVER 2.1
 Web browser such as Mozilla Firefox, Internet Explorer
 Notepad++
 Microsoft Word 2010
 Microsoft Visio 2007
 Picasa

4.2 SAMPLE CODE AND DESCRIPTION

4.2.1 Algorithm design

Algorithm for authentication

Function Authentication (Username, password, type)

If password length=0

Display error message “Password required”

Return

Pass=Retrieve Password (Username)

If password! =pass

Display error message “Incorrect password”

Return

Type=Check Type (type)

If type=Administrator

Display Administrator main form

Else if type=Clerk

Display Clerk main form

57
Else if type=Passenger

Display Passenger main form

//end of the function authentication

Algorithm for checking whether the field takes only Numbers or not

Function Contain Character (string)

If string contain [a-z A- Z]

Display error message “These Field Must be a character”

Return true

Else

Return false

//End of Function contain character.

Algorithm for checking whether the field takes only Characters or not

Function contain Number(string)

If string contain[0-9]

Display error message “This string contain Numeric Value”

Return true

Else

Return false

//End of Function contains Number.

58
4.2.2 Sample Code

Index.php

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>selam bus online ticket reservation system</title>

<link rel="shortcut icon" href="image/logg.jpg" />

<link type="text/css" href="css/css.css" rel="stylesheet" />

<link type="text/css" href="css/style.css" rel="stylesheet" />

</head>

<body>

<div class="log">

<img class="tt1" src="image/logg.jpg" alt="here is logo" /><img class="tt"

src="image/greenbus.jpg"greenbus.jpg" alt="here is logo" />

</div>

<div id="nav">

<ul>

<li><a href='homephp.php' target="iframe1"><span>home</span></a></li>

<li><a href='#'><span>Reservaion</span></a>

<ul>

<li><a href='show.php' target="iframe1"><span>Make resevation</span></a></li>

59
 <li><a href='show.php' target="iframe1"><span>Cancel reservaion</span></a></li>

</ul>

</li>

<li><a href='#'><span>Schedule</span></a>

<ul>

<li><a href='show.php' target="iframe1"><span>View schedule</span></a></li>

</ul>

</li>

<li><a href='#'><span>Ticket</span></a>

<ul>

<li><a href='show.php' target="iframe1"><span>check ticket

avilibilty</span></a></li>

</ul>

</li>

<li><a href='travel.php' target="iframe1"><span>Travel rule</span></a></li>

<li><a href='show.php' target="iframe1"><span>Comment</span></a></li>

<li><a href='#'><span>Help</span></a>

<ul>

<li><a href='hreg.html' target="iframe1"><span>How to register</span></a></li>

<li><a href='hres.html' target="iframe1"><span>How to reserve</span></a></li>

</ul>

</li>

<li><a href='Register.php' target="iframe1"><span>Register</span></a></li>

60
</ul>

</div>

<div class="st">

<iframe name="iframe1" width="700px" height="800px" src="homephp.php"

scrolling="auto" frameborder="0"></iframe>

</div>

<div class="nd">

<h3 style="border-bottom:4px solid #009900;"><font style size=5>&nbsp;&nbsp;Login

Form</font></h3>

<form action="login.php" method="post" name="login_form" class="contact_form">

<table>

<tr><td align="left"><label for="username">Username:</label></td>

<td><input type="text" name="username" placeholder="Abrham21"

required /></td></tr>

<tr><td><br/></td></tr>

<tr><td align="left"><label for="Password">Password:</label>

<td><input type="password" name="password" placeholder="*****"

required /></td></tr>

<tr><td><br/></td></tr>

<tr><td align="left"><label for="User type">User Type:</label>

<td align="left">

<select name="type" required>

<option value="">Select user</option>

<option value="Adminstrator">Adminstrator</option>

61
 <option value="Cleark">Cleark</option>

<option value="Passenger">Passenger</option>

</select>

</td></tr>

<tr><td><br/></td></tr>

<tr><td><button class="submit"
type="submit">Login</button></td></tr>

<tr><td><a class="ac" href="Register.php" target="iframe1">Create

account</td></tr>

</table>

</form>

<br>

<script src="js/time.js" language="javascript" type="text/javascript"></script>

<body onLoad="yourClock()", onUnload="stopClock(); return true">

<form name="the_clock">

<table width="100%" border="0" cellpadding="0" cellspacing="0">

<tr align="left"><td>

<a>System Time:&nbsp;&nbsp<input type="text" name="the_time" size="10"

style="padding-bottom:5px;" align = "top"></a>

</td></tr>

<tr align="left"><td></td></tr>

</table>

</form>

<br /><br />

62
<h4>Calender</h4>

<script LANGUAGE="JavaScript">

monthnames = new
Array("January","Februrary","March","April","May","June","July","August","September","
October","November","Decemeber");

varlinkcount=0;

function addlink(month, day, href) {

var entry = new Array(3);

entry[0] = month;

entry[1] = day;

entry[2] = href;

this[linkcount++] = entry;

Array.prototype.addlink = addlink;

linkdays = new Array();

monthdays = new Array(12);

monthdays[0]=31;

monthdays[1]=28;

monthdays[2]=31;

monthdays[3]=30;

monthdays[4]=31;

monthdays[5]=30;

monthdays[6]=31;

63
monthdays[7]=31;

monthdays[8]=30;

monthdays[9]=31;

monthdays[10]=30;

monthdays[11]=31;

todayDate=new Date();

thisday=todayDate.getDay();

thismonth=todayDate.getMonth();

thisdate=todayDate.getDate();

thisyear=todayDate.getYear();

thisyear = thisyear % 100;

thisyear = ((thisyear< 50) ? (2000 + thisyear) : (1900 + thisyear));

if (((thisyear % 4 == 0)

&& !(thisyear % 100 == 0))

||(thisyear % 400 == 0)) monthdays[1]++;

startspaces=thisdate;

while (startspaces> 7) startspaces-=7;

startspaces = thisday - startspaces + 1;

if (startspaces< 0) startspaces+=7;

document.write("<table border=1 bgcolor=white width=350 height=300");

document.write("bordercolor=black><font color=black>");

document.write("<trbgcolor=#CCCCCC><td colspan=7><center><strong>"

+ monthnames[thismonth] + " " + thisyear

64
+ "</strong></center></font></td></tr>");

document.write("<tr>");

document.write("<td align=center>Su</td>");

document.write("<td align=center>M</td>");

document.write("<td align=center>Tu</td>");

document.write("<td align=center>W</td>");

document.write("<td align=center>Th</td>");

document.write("<td align=center>F</td>");

document.write("<td align=center>Sa</td>");

document.write("</tr>");

document.write("<tr>");

for (s=0;s<startspaces;s++) {

document.write("<td></td>");

count=1;

while (count <= monthdays[thismonth]) {

for (b = startspaces;b<7;b++) {

linktrue=false;

document.write("<td>");

for (c=0;c<linkdays.length;c++) {

if (linkdays[c] != null) {

if ((linkdays[c][0]==thismonth + 1) && (linkdays[c][1]==count)) {

document.write("<a href=\"" + linkdays[c][2] + "\">");

65
linktrue=true;

if (count==thisdate) {

document.write("<font color='FF0000'><strong>");

if (count <= monthdays[thismonth]) {

document.write(count);

else {

document.write(" ");

if (count==thisdate) {

document.write("</strong></font>");

if (linktrue)

document.write("</a>");

document.write("</td>");

count++;

document.write("</tr>");

document.write("<tr>");

66
startspaces=0;

document.write("</table></p>");

</script>

</div>

<div class="footer">

<table width="100%" border="0" cellspacing="0">

<tr><td width="80%" align="center" padding-bottom="350px" margin-

bottom="350px">Copyright &copy; Selam Bus Transport 2006</td></tr>

</table>

</div>

</div>

</body>

</html>

4.3 TESTING OVERVIEW

Testing is the process of running a system with the intention of finding errors. Testing
enhances the integrity of a system by detecting deviations in design and errors in the
system. Testing aims at detecting error-prone areas. This helps in the prevention of
errors in a system. Testing also adds value to the product by conforming to the user
requirements.

In this phase the entire software system is tested. The reference document for this process is the
requirements document, and the goal is to see whether the software meets the requirements.

4.3.1 TEST BY SCOPE

67
 4.3.1.1 Unit Testing

In computer programming, Unit testing is a procedure used to validate that individual units of
source code are working properly. So In this test the team try to test each module individually but
not integrate the whole system. It focuses verification efforts even in the smallest unit of software
design in each module. This is also known as ―Module Testing.

The testing is carried out in the programming style itself. In this testing each ,module is focused
to work satisfactorily as regard to the expected output from the module .There are some
validation checks for the fields.

4.3.1.2 Integration Testing

Integration testing (sometimes called, Integration and testing, abbreviated I&T) is the phase
of software testing in which individual software modules are combined and tested as a
group.So the team in this testing part, combined all the modules together and tested it for its
fitness with each other and with the systems functionality. If error occurs in combining them,
the module with problem will be identified and re combined.

4.3.2 TEST IMPLEMENTATION(Validation testing)

 Password checking:
When unauthorized users are try to access to the system displays an alert message “password
or user name is not correct you must check your username or password”.
 Data type validations:
Accepts only validate data .If you insert invalidate data the system display alert message
“please insert validate data “.
 Null input:
Allows the new application to accept the needed data rather than null. Else display an error
message box.

CHAPTER FIVE

68
 USER MANUAL

5.1 USER MANUAL

User manual is used to show each procedures of the system for the simplicity of performing
the an operation of the system easily. The user manual describes as the following steps only
for authenticated passenger.

 To register passenger
Step 1: launch the system
Step2: select registration menu
Step 3: fill the form
Step 4: click submit button
 To login
Step 1: launch the system
Step2: select login menu
Step 3: fill the form
Step 4: click login button
 To make reservation
Step 1: launch the system
Step2: log in to the system
Step 3: select make reservation menu
Step 4: fill the form
Step 5: click submit button
 To view schedule
Step 1: launch the system
Step2: log in to the system
Step 3: select view schedule menu
Step 4: fill the form
Step 5: click submit button

 To check avilibilty of ticket

Step 1: launch the system

69
 Step2: log in to the system
Step 3: select check ticket avilibilty menu
Step 4: fill the form
Step 5: click submit button

5.2 INSTALLATION GUIDE

Since the project is a web based System, there is no need to install it on a particular machine
rather it will be hosted on a server.

5.3 SYSTEM REQUIREMENT

Hardware software acquisition

Software
The client side application is compatible with windows family starting from Window XP.

Hardware
The system is compatible with only hardware the above operating systems are compatible
with.

CHAPTER SIX

CONCLUTION AND RECOMMENDATIO

70
6.1 CONCLUTION

This project is undertaken to develop automated system for selam bus share line. The team
has conducted a thorough business area analysis and functional workflow of the current work
environment. Analysis of the existing system was carried out. Requirements of the new
system are also documented.

Since the success and failure of any system depends on gathering the right information through
different fact-finding techniques and user involvements, the team has made the best effort to
gather requirements. After a detail review and study of the existing system, models have been
designed to reflect the new system that are supposed to solve problems.

In order to solve different problems existed, the team has propose a solution that solve the
existed problems and model the proposed system using different tools and methodologies. The
team believe the different tools and techniques has helped us a lot in capturing real user
requirements and model the right system for the users for their day to day transactions.

6.2 RECOMMENDATION

Based on the conclusion the team recommend that the company must replace the existing
system by the new automated system. Because the old fashioned manual method of working
does not computable with the todayworking conditions.Organizations have to divert their
attention on using the recent technology to be on the first line and competitive.

REFERENCE

[1] http://www.selambus.com/companyprofile.html

71
[2]http://www.selambus.com/companyprofile.html

[3]http://xa.yimg.com/kq/groups/27443320/1842024007/name/Bus.pdf

[4]http://www.selambus.com

[5] Bernd Bruegge and Allen H.Dutoit/2000

[6] Bernd Bruegge and Allen H.Dutoit/2000

72