Selam Bus Ticket Reservation System

ONLINE SELAM BUS TICKET RESERVATION SYSTEM 2015/16
WOLLO UNIVERSITY
KOMBOLCHA INSTITUTE OF TECHNOLOGY
COLLEGE OF INFORMATICS
DEPARTMET OF INFORMATION TECHNOLOGY
FINAL YEAR PROJECT
TITLE:-SELAMBUS TICKET RESERVATION SYSTEM
Group Name ID
1. Sisay Mengie…………………………1678/05
2. Surafel Tsegaye………………………1680/05
3. Tsegaye Kediru……………………...1689/05
4. Nejat Ahemed………………………..1664/05
5. Atsedemariyam Zenaw………………1694/05
Advisor Name:-Salihadin S (MSC)
Submitted date 6/20/2016
Kombolcha Ethiopia.
DEPARTMENT OF INFORMATION TECHNOLOGY Page - 1 -

ACKNOWLEDGMENT
We would like to thanks to our advisor Salihadin S (MSC) is an instructor in wollo university
kombolcha institute of technology to give guidance and to motivate to achieve this project. We
would also thanks to the Selam Bus Line Share Company (Selam Bus Line S.C) office in the
dessie town to give information how the current system works and how the passenger reserve
ticket in the current system and also give information about the background of the company.
We would like to extend our thanks for our friends, our classmates and family for their support
and encouragement to achieve the project.
DEPARTMENT OF INFORMATION TECHNOLOGY Page i

ABSTRACT
The purpose of this project to develop online ticket reservation system that provides services like
promotion Selam bus ticket reservation . Properly designed user interface is can standardize the
input and output mechanism allowing users to easily use the entire system.
In addition the system has necessary security to manipulate the information in the database. As a
whole this system is believed to solve the problems of the selam bus ticket reservation and
addressing information to the passenger.
DEPARTMENT OF INFORMATION TECHNOLOGY Page ii

ABBREVIATIONS
Acronyms Description:-
HTML: Hypertext Markup Language
CSS: Cascading Style Sheet
SQL: Structured Query Language
MYSQL:Multiuser Structured Query Language
PHP:- PHP Hypertext Preprocessor
SNMP:- Simple Network Management Protocol
HTTP: Hypertext Transfer Protocol
MS: Microsoft
Admin: Administrator
Pass: Passenger
Info: Information
UC: Use case
UI: User interface
CRC: Class Responsibility Collaborator
SBLSC:Selam bus line share company
Uname:user name
Rpassword:Retype password
Dname :Driver name
DEPARTMENT OF INFORMATION TECHNOLOGY Page iii

Table of Contents
CHAPTER ONE ............................................................................................................................. 1
1. Introduction ................................................................................................................................. 1
1.1 Background ............................................................................................................................... 1
1.2 Statement of the problem .......................................................................................................... 2
1.3 Objective ................................................................................................................................... 3
1.3.1General Objective ................................................................................................................... 3
1.3.2 Specific Objective .................................................................................................................. 3
1.4 Methodology ............................................................................................................................. 3
1.4.1 System Analysis and Design .................................................................................................. 3
1.4.2 Method of data collection ...................................................................................................... 4
1.5 Feasibility Study ....................................................................................................................... 4
1.5.1 Economic Feasibility ............................................................................................................. 4
1.5.2 Technical Feasibility .............................................................................................................. 5
1.5.3 Operational feasibility............................................................................................................ 5
1.5.4 Political feasibility ................................................................................................................. 5
1.6 Project Scope and Limitation .................................................................................................... 6
1.6.1 Scope of project ................................................................................................................... 6
1.6.2 Limitation of the Project ...................................................................................................... 6
1.7 Significance of the project ...................................................................................................... 7
1.8 Tools ......................................................................................................................................... 7
1.8.1 System Implementation Tools ............................................................................................... 7
1.8.2 Hard ware tools:-.................................................................................................................... 8
1.8.3 Software tools:- ...................................................................................................................... 8
1.9 Project cost ................................................................................................................................ 8
1.9.1 Hardware cost:- ...................................................................................................................... 8
1.9.2 Software cost:- ....................................................................................................................... 9
2 Time schedule:- .......................................................................................................................... 10
CHAPTER TWO .......................................................................................................................... 11
DEPARTMENT OF INFORMATION TECHNOLOGY Page iv

SYSTEM ANALYSIS .................................................................................................................. 11
2.1 Introduction ............................................................................................................................. 11
2.2 Existing System ...................................................................................................................... 11
2.2.1 over view of existing system................................................................................................ 11
2.2.2 Problems Of existing system ............................................................................................... 12
2.3 Supplementary Requirements ................................................................................................. 12
2.3.1 Business Rules ..................................................................................................................... 12
2.3.2 Constraints ........................................................................................................................... 13
2.4 New System ............................................................................................................................ 13
2.4.1 Functional requirement ........................................................................................................ 13
2.4.2 Non Functional requirement ................................................................................................ 14
2.5 Use Case Model ...................................................................................................................... 15
2.5.1 Use case diagram for the new system .................................................................................. 15
2.5.2 Description for each use case ............................................................................................... 17
2.5.3 Login .................................................................................................................................... 17
2.5.4 Register ................................................................................................................................ 18
2.5.5 Reserve ticket ....................................................................................................................... 19
2.5.6 View Schedule ..................................................................................................................... 20
2.5.7 Cancel Reservation .............................................................................................................. 21
2.5.8 Generate Report ................................................................................................................... 22
2.5.9 Update Reservation .............................................................................................................. 23
2.5.10 Print ticket .......................................................................................................................... 24
2.5.11 Assign Bus ......................................................................................................................... 25
2.5.12 Create account .................................................................................................................... 26
2.5.13 View report ........................................................................................................................ 27
2.5.14 View feedback ................................................................................................................... 28
2.5.15 View Passenger information .............................................................................................. 29
2.5.16 update account .................................................................................................................. 30
2.5.17 Delete account .................................................................................................................... 31
2.5.18 Logout ................................................................................................................................ 32
2.5.19 Post Notice ........................................................................................................................ 33
DEPARTMENT OF INFORMATION TECHNOLOGY Page v
2.5.20 Add schedule ..................................................................................................................... 34
2.5.21 View Notice ...................................................................................................................... 35
2.5.22 Send message .................................................................................................................... 36
2.5.23 View message ................................................................................................................... 37
2.6 Domain modeling using (CRC) .............................................................................................. 37
2.7 Sequence Diagram .................................................................................................................. 40
2.8 Activity diagram ..................................................................................................................... 53
2.9 Class diagram .......................................................................................................................... 64
2.10 User interface flow diagram.................................................................................................. 65
CHAPTER THREE ...................................................................................................................... 66
3. System Design .......................................................................................................................... 66
3.1 Introduction ............................................................................................................................. 66
3.2 Design Goals and Objectives .................................................................................................. 66
3.3 Class Modeling diagram ......................................................................................................... 67
3.4 Current software archecture .................................................................................................... 68
3.5 Proposed software archecture ................................................................................................. 68
3.5.1 Subsystem Decomposition .................................................................................................. 69
3.5.2 Component Modeling ......................................................................................................... 71
3.5.3 Deployment modeling ......................................................................................................... 72
3.5.4 Persistence Modeling for object oriented database .............................................................. 73
3.5.5 Access Control and Security ................................................................................................ 75
3.5.6 Boundary conditions and Exception Handling ................................................................... 76
3.5.6.1 Boundary Conditions ........................................................................................................ 76
3.5.6.2 Exception Handling .......................................................................................................... 76
3.5.7 User Interface design ........................................................................................................... 77
CHAPTER FOUR ......................................................................................................................... 82
System Implementation and Testing ............................................................................................. 82
4. 1 System Implementation ......................................................................................................... 82
4.1.1 Coding .................................................................................................................................. 82
4.2 Testing..................................................................................................................................... 89
4.2.1 Unit testing .......................................................................................................................... 89
DEPARTMENT OF INFORMATION TECHNOLOGY Page vi
4.2.2 Integration testing ................................................................................................................ 92
4.2.3 Acceptance testing ............................................................................................................... 92
4.2.4 System testing ...................................................................................................................... 92
CHAPTER FIVE ......................................................................................................................... 93
Conclusion and Recommendation ................................................................................................ 93
5.1 Conclusion .............................................................................................................................. 93
5.2 Recommendation .................................................................................................................... 93
5.3 References ............................................................................................................................... 93
Annex1: sample interviewed questions ........................................................................................ 94
Annex2: sample interviewed questions ........................................................................................ 94
Annex3 .......................................................................................................................................... 94
List of tables
Table 1 shows hardware cost .......................................................................................................... 9

Table 2 shows software cost ........................................................................................................... 9
Table 3 shows time table............................................................................................................... 10
Table 4 List of actors and use case ............................................................................................... 15
Table 4.1 which shows use case description about login use case ............................................... 17
Table 4.2 which shows use case description about Register use case .......................................... 18
Table 4.3.Which shows use case description about reserve ticket use case. ................................ 19
Table 4.4 which shows about use case description about view schedule use case ....................... 20
Table 4.5 which shows about use case description about Cancel reservation use case ................ 21
Table 4.6 use case description about Generate Report use case ................................................... 22
Table 4.7 which shows that use case description about update reservation use case. .................. 23
Table 4.8 shows Use case description for print ticket use case .................................................... 24
Table 4.9 which shows use case description about assign bus use case ....................................... 25
Table 4.10 which shows about use case description about create account use case ..................... 26
Table 4.11 which shows use case description about view report use case ................................... 27
Table 4.12 which shows use case description about view feedback............................................. 28
Table 4.13 which shows use case description about view passenger information ....................... 29
Table 4.14 shows use case description about update account use case ........................................ 30
Table 4.15 shows use case description about check ticket use case ............................................. 31
Table 4.16 which shows use case description about logout use case ........................................... 32
Table 4.17 which shows use case description about notice .......................................................... 33
Table 4.18 which shows use case description about add schedule ............................................... 34
DEPARTMENT OF INFORMATION TECHNOLOGY Page vii

Table 4.19 which shows use case description about notice .......................................................... 35
Table 4.20 which shows use case description about send message .............................................. 36
Table 4.21 which shows use case description about view message ............................................. 37
Table 5 structure of CRC .............................................................................................................. 38
Table 5.1 shows that class responsibility for Admin actor ........................................................... 38
Table 5.2 show the class responsibility of passenger ................................................................... 38
Table 5.3 shows the class responsibility of manager .................................................................... 39
Table 5.4 shows the class responsibility of clerk .......................................................................... 40
Table 6 access control and security .............................................................................................. 75
Table 7 Test case for login ........................................................................................................... 90
Table 8 Test case for reservation ................................................................................................. 91
List of figures
Fig 1 use case diagram .................................................................................................................. 16

Fig 1.1 Sequence Diagram for login ............................................................................................. 41
Fig 1.2 Sequence Diagram for register ......................................................................................... 41
Fig 1.3 Sequence Diagram for reserve ticket ................................................................................ 43
Fig 1.4 Sequence Diagram for cancel reservation ........................................................................ 41
Fig 1.5 Sequence Diagram for update reservation ........................................................................ 41
Fig 1.6 Sequence Diagram for Generate report ............................................................................ 41
Fig 1.7 Sequence Diagram for Print ticket.................................................................................... 47
Fig 1.8 Sequence Diagram for View pass info ............................................................................. 48
Fig 1.9 Sequence Diagram for View feedback ............................................................................. 41
Fig 1.10 Sequence Diagram forAssign bus................................................................................... 50
Fig 1.11 Sequence Diagram for Create account ........................................................................... 51
Fig 1.12 Sequence Diagram for Delete account ........................................................................... 52
Fig 1.13 Activity diagram for Login ............................................................................................. 53
Fig 1.14 Activity diagram for Register ......................................................................................... 54
Fig 1.15 Activity diagram for Reserve ticket................................................................................ 55
Fig 1.16 Activity diagram for Cancel reservation ........................................................................ 56
Fig 1.17 Activity diagram for Create account .............................................................................. 57
Fig 1.18 Activity diagram for Delete account ............................................................................. 58
Fig 1.19 Activity diagram for View passenger information ......................................................... 59
Fig 1.20 Activity diagram for View feedback .............................................................................. 60
Fig 1.21 Activity diagram Update reservation .............................................................................. 61
Fig 1.22 Activity diagram logout .................................................................................................. 62
DEPARTMENT OF INFORMATION TECHNOLOGY Page viii

Fig 1.23activity diagram for add schedule .................................................................................... 63
Fig 1.24 Class diagram ................................................................................................................. 64
Fig 1.25 User interface flow diagram ........................................................................................... 65
Fig 1.26 class modeling diagram .................................................................................................. 67
Fig 1.27 Software archecture ........................................................................................................ 68
Fig 1.28 subsystem documentation ............................................................................................... 70
Fig 1.29 Component modeling ..................................................................................................... 71
Fig 1.30 Deployment modeling .................................................................................................... 72
Fig 1.31 mapping .......................................................................................................................... 74
Fig 1.32 Home page UI................................................................................................................ 77
Fig 1.33 login UI .......................................................................................................................... 78
Fig 1.34 Register UI ...................................................................................................................... 78
Fig 1.35 Reservation UI ................................................................................................................ 80
DEPARTMENT OF INFORMATION TECHNOLOGY Page ix

CHAPTER ONE
1. Introduction
The project is concerned on online Selam Bus Line Share Company (Selam Bus Line S.C) ticket
reservation system. As human being there are many problems face 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 solve any one can develop 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 Line Share Company (Selam Bus Line S.C) 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 (Selam Bus Line S.C) is one of the largest long distance cover
transportation company in Ethiopia. It was found by the Tigray Development Association in the
1988 E.C with initial capital of 43,900,000.00Birr. Its main objective is to address the national
wide need for public for transportation. In the current time Selam Bus Line Share Company
(Selam Bus Line S.C) provides service to more than 17 cities in Ethiopia. At present the cities
that the company is departure service from Addis Abeba to Diredawa, Harar, Jigjiga, Jimma,
Bahirdar,Gondor,Dessie,Mekelle,Shire,Assosa,Arbaminch,Hawasa,D/Markos,Welidya,Nekemit,
balerobe on daily basis. The headquarter, bus terminal and garage of Selam Bus Line Share
Company (Selam Bus Line S.C) has been established in Addis Ababa with branch offices in all
regional capitals. Selam Bus Line Share Company (Selam Bus Line S.C) to satisfy the need of
the passenger it can give a service for the passenger , such as 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]
DEPARTMENT OF INFORMATION TECHNOLOGY Page 1

1.2 Statement of the problem
Selam Bus Line Share Company (Selam Bus Line S.C) currently uses a manual system. Due to
this cause, the company has several problems that negatively affect the reliability, performance,
efficiency and effectiveness of day to day activities.
Manual system: The existing system is very time consuming and inefficient to the customer.
This system is more prone to errors and sometimes the approach to various problems is
unstructured.
Some of the major problems are:-
 Inconsistent data and poor time management.

 Requires stationary materials and also the system are slow.
 Inefficient to their customer.
 It takes a lot of time and cause many errors.
To solve the above problem, the reservation system has helps the customer to enquire in
order to get the latest update on schedule, the availability of ticket in a particular bus at
particular date, helps him to reserve a ticket and cancel a reserved ticket.

1.3 Objective
The general and specific objectives are mentioned in the following.
1.3.1General Objective
To develop online ticket reservation system of Selam Bus Line Share Company (Selam Bus Line
S.C) that will replace the manual ticket reservation system.
1.3.2 Specific Objective

In general the specific objective of our project is:-
 To enable the user to interact or introduce with the new

technology.
 Studying and analyzing the existing system.
 Review and identifying the problems of the current system.
 Collect data and analyze the system requirements.
 Design the proposed system for the overall view of the structure
implement the system.
 Design a user Interface for the proposed system.
 Finally testing the system to overcome the system function.
1.4 Methodology
1.4.1 System Analysis and Design

In the system analysis and design phase of our project we should use the object oriented
approach that examines requirements from the perspective of the class and objects found in the
problem domain. The reasons that we use the object oriented approach are:[2]
 We can reuse methods for avoiding redundancy.
 Modification of the object implementation is easy.
 Direct manipulation of architectural components is possible because several object
oriented programming languages exist.
 Understanding of the structure is easy because object oriented modeling represents real
world entities

 This increases flexibility.
 This also improved quality
1.4.2 Method of data collection

The method of Requirement gathering that is used on this project includes interviews and
document analysis to collect or gather information and data of the existing system to develop
new system.
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.
Document analysis: reading the document available in the organization site. [3]
Observation: - To understand directly how the existing system works currently, we have used
observation. We observed customer interaction.
1.5 Feasibility Study
1.5.1 Economic Feasibility
The purpose of this project is that generating good services for the customers and at the same
time minimizing the cost and time taken by the service.
Tangible Benefits
The system minimizes the work load of the employees.
Intangible Benefits
 Easily access customer information throughout the Selam Bus Line Share
Company (Selam Bus Line S.C).
 Increased flexibility.
 Increase speed of activity.

1.5.2 Technical Feasibility
It can be include assessment of knowing our possible target hardware, software and operating
environment to be used as well as a system size, complexity and the individual experience with
similar system.
1.5.3 Operational feasibility

This project is solve the problems found within the manual Selam Bus Line Share Company
(Selam Bus Line S.C)ticket reservation system .In order to solve this problem the system uses
different mechanism for passenger and Manager. The result is that translating the manual Selam
Bus Line Share Company (Selam Bus Line S.C) ticket reservation system to online which is
interactive to use, easy, cost effective and time saving for both passenger and manager.
1.5.4 Political feasibility

The system to be developed is not conflict with any government directives, because it gives
services for the passenger effectively and efficiently. This project system will avoid conflict
between the company and government because of both of them are beneficiaries. So the
government is profitable and the system will be politically feasible. Therefore, the system is free
from any legal and contractual risks.

1.6 Project Scope and Limitation
1.6.1 Scope of project

The scope of our project is to develop online ticket reservation system for Selam Bus Line Share
Company (Selam Bus Line S.C) that avoid the problem which occur in the manual system
The new system can perform the following activities:-
 To provide an easy option for the passenger who is willing to reserve ticket online.
 To generate report.
 Show schedule.
 Assigning bus to journey.
 To update and cancel the reservation date if the passenger want.
Generally our project is performed the above mentioned tasks.
1.6.2 Limitation of the Project

The limitations of new system that can’t perform in our project are the following:-
 Automating payment system.
 Serving passenger out of the concerned destination.
 Email subscription.
 Maintenance system.

1.7 Significance of the project
The manual system has different problem so our project that develop is very important to the
Selam Bus Line Share Company (Selam Bus Line S.C) and passenger.
For the Selam Bus Line Share Company (Selam Bus Line S.C):-
 It increases their profit by making their expenditure less.

 It increases passenger satisfactions.
 It helps the company to handle passenger‘s information in an organized way.
 Provides consistent and correct report.
 Reduce loss of documents.
For the Passenger:-
 It reduces the wastage of time and money.

 It helps the customer to know the schedule.
1.8 Tools
1.8.1 System Implementation Tools

Php:- is mainly focused on server-side scripting. PHP can be used on all major
operating systems.
 Php has also support for most for

 The web servers today.
 Php it support for wide range of database.
 PHP also has support for talking to other services using protocols such
as Simple Network Management Protocol (SNMP), Hypertext Transfer
Protocol( HTTP).[4]

1.8.2 Hard ware tools:-
 Laptop or disk top
 Flash disk(8GB)
 A4 size paper
 Pen
 Pencil
1.8.3 Software tools:-

 MS word 2010: for the purpose of writing documentation.
 Apache server: is a server which let us to use client computer as client and
server.
 Microsoft PowerPoint 2010: is software that we use for presentation purpose.
 Adobe Photoshop (CS4):- it used to edit photo.
 MySQL database;- for Data base Server purpose
 HTML, CSSModal , JAVA SCRIPT: -for writing Script languages.
 Web browser: the web browser such as Mozilla, internet explorer and Google
chrome use to see our system.
 Edrawmax version 7.9:-for diagrams like use case, sequence diagrams, class
diagrams, deployment diagrams.
1.9 Project cost
1.9.1 Hardware cost:-

Table 1 shows hardware cost:-
No Material Amount Price per Total price

unit
1 A4 size paper 2 Dozen 100Birr 200 Birr
2 Pen 5 4 Birr 20 Birr
3 Flash disk 1 150 Birr 150 Birr
4 For Print 100sheet 1 Birr 100 Birr
5 CD 2 8 Birr 16 Birr
6 Computer 1 1000 Birr 1000
Total 1486 Birr
1.9.2 Software cost:-

Table 2 shows software cost:-
No Material Price per unit

1 Microsoft office 2010 Free
2 Apache Wamp server Free
3 Notepad, Notepad++ Free
Total 00.00 Birr

2 Time schedule:-
Table 3 shows time table:-
Time table
Activities Nov 14- Nov 28- Feb 30 March 29 May 30 Jun 22
Nov 25 Jan 26 -Mar 28 -May 25 - June 10 -Jun 28
Project Proposal
Requirement
Analysis
Design
Implementation &
Coding
Testing
project Defense

CHAPTER TWO
SYSTEM ANALYSIS
2.1 Introduction
This chapter deals with analyzing the general work flow of the existing system. And the
activities that we performed in the project these include the use case diagram, use case
description for each use case, class responsibility collaborator, sequence diagram, activity
diagram and class diagram of the system. There will also be description of the functional and
non-functional requirements of our new system performed.
2.2 Existing System
2.2.1 over view of existing system

The main purpose of studying the existing system is to develop a new system which efficiently
performs activities than current one and understanding existing problems.
Currently Selam Bus Line Share Company (Selam Bus Line S.C) follows manual based to
provide service to its passengers. In existing system passenger need to go to selam bus office
their own to reserve a ticket. The clerk asks some questions for the passenger:-
What is your full name?
What is your phone number?
When they want go?
Where they want go?
After these questions are completely answered the clerk gives the ticket to the passenger.

2.2.2 Problems Of existing system
As we described in chapter one Currently Selam Bus Line Share Company (Selam Bus Line S.C)
have some problem among those problems the following are the major lists:-
 It is time consuming.
 It causes data loss because there is no proper handling of data.
 It is not easily accessible.
 Information in paper based form.
 Requires stationary materials.
 It is difficult to integrate various information’s to generate the report.

 The passenger cannot easily acquire information about the schedule.
2.3 Supplementary Requirements
2.3.1 Business Rules

Business rule are the guidelines that a company and passenger follow to perform their tasks to
be assigned. The following business rules are investigated within Selam Bus Line Share
Company (Selam Bus Line S.C):-
 Make sure that the date, time and your name written correctly. This ticket should be
submitted when requested.
 You need to show up identification card when you come to buy.
 Customers should not hold materials like liquids, harmful properties, untaxed materials
and electronics which is not allowed by the Company.
 If you lost your ticket you can travel by paying the full amount and it will be refunded
when the first ticket is found within 15 days.
 Passenger wants to postpone the trip day he or she announce before 24 hours.
 If you cancel your trip before 24 Hrs of your departure time and you don’t show up on
the departure time, there will be deduction of 50% from the total amount paid within 15
days. [2]

2.3.2 Constraints
To develop online Selam bus ticket reservation system we have been facing some problems.
Some of the problems are:-
 There is Shortage of time to complete project within the given time.

 Resources like electric power and internet connections are not consistently
available.
 There is over load of examination and other projects.
 There is lack of reference books to do this project.
2.4 New System

The new proposed system is aimed to solve the problems in current system by creating on
line system that helps the company and passenger.
Generally the requirement of the new system can be viewed as:-
 Functional and
 Non Functional requirement
2.4.1 Functional requirement

The Functional requirement is concerned with actual performance of the system that is going to
be developed. Functional requirements describe the functionality or service provided by the
new system.
 The system allow clerk can generating report for the Selam Bus Line Share
Company (Selam Bus Line S.C).
 The system provide to modify system user can delete, update and insert the
required information.
 The system has a function that allow passenger to view the schedule.
 The system allows registered user to reserve tickets online.
 The system allows passenger can give a feedback about Selam Bus Line Share
Company (Selam Bus Line S.C).This helps to improve the service and
performance of Selam Bus Line Share Company (Selam Bus Line S.C).
 The system allows clerk postpone the date of journey.
 Passenger can reserve ticket by choosing the available seat.

2.4.2 Non Functional requirement
Non-functional requirement describe invisible aspects of the system that are not directly
related to the system. Unlike functional requirement the non-functional requirement deals
with additional quality of the system such as:- Quality Issue, security Issue, Error
handling.
 Quality Issue
Information in database should be as much as possible correct and updated in as the user
want.
 Security Issue
This system provides an access to an authorized user by giving account for each and every
special function.
 Error Handling
Our system handles the errors in a very efficient manner.

2.5 Use Case Model
The use case model that identify actors and use case associated with the system.
The following table shows that the list of actor and list of use case that we performed with the
new system.
Table 4 List of actors and use case
Actor Use case
Admin  Log in
 Create account
 Update account
 Delete account
Clerk  Log in
 Generate report
 View passenger information
 Print ticket
 Cancel reservation
 Update Reservation
 View message
 Send message
Manager  Login
 Assign Bus
 View Report
 View feedback
 View message
 Send message
 Add schedule
 Post notice.
Passenger
 View notice
 Register
 Login
 View Schedule
 Reserve ticket
 Send message
 View message
2.5.1 Use case diagram for the new system

A use case diagram is a diagram that shows the relationships among actors and use cases within
a system. They provide the simplified and graphical representation of what the system must
actually do.

System use case diagram

View notice
Rigister
Create account
View schedule
Update account
pass <<include>> <<include>>
Reserveticket Delete account admin
<<include>>
View message <<include>>
Add schedule
<<include>> <<include>>
Send message <<include>>
<<include>>
<<include>> Assign bus
Login
<<include>>
View report
Update <<include>>
<<include>> manage
reservation
<<include>> <<extend>> View feedback r
<<include>>
Generate <<include>>
report <<include>> Post notice
clerk <<include>>
View pass info Logout <<include>> View message
<<include>>
Print ticket
Send message
Cancel
reservation
Fig 1 use case diagram

2.5.2 Description for each use case
After we draw the use case diagram we describe each of the above use case what they perform in
the system. The following tables show the use case description for each of the use cases that has
been described in the above.
2.5.3 Login
Table 4.1 which shows use case description about login use case
Use case name Log in
Identifier UC1
Actor System user

Description This describes how users enter into the system.
Pre-condition System user must have correct username and password.

Post condition System user must login into the system.
Basic course of action 1. System user can easily open the home page.
2. The system displays the login form.
3. System user can full fill the correct requirement data.
4. The System check user name and password whether it’s
correct or not.
5. The System display provides information.
6. Use case End.
Alternative course of action Alternative course of action 4:-

 If System user is not filled correctly, display ‘Error’
message and go to Step3.

2.5.4 Register
Table 4.2 which shows use case description about Register use case
Use case name Register
Identifier UC2
Actor Passenger.
Description The passenger can register himself.
Pre-condition None
Post condition The database store information of passenger.
Basic course of 1. System user can easily open the home page.
action 2. The system display passenger registration form.
3.The System user can full fill the correct requirement
data and click create account button.
4. The system check validation of data.
5. The system display successfully registered.
6. Use case end.
Alternative course of Alternative course of action 4:-

action  If System user is not filled correctly, display
‘Error’ message and go to Step3.

2.5.5 Reserve ticket
Table 4.3.Which shows use case description about reserve ticket use case.
Use case name Reserve ticket
Identifier UC3
Actor Passenger.
Description The system allows the user to reserve online.
Pre-condition The system user login into the system .
Post condition The user reserve and stored to the database.
Basic course of action 1. The System user can easily open the home page.
2. The system user login into the system.
3.The System display the schedule form.
4. The system user view the schedule .
5. The System user clicks the bus id button.
6.The system display the reservation form.
7. The system user select the seat no and full fill the information.
8.The system check validation of data
9.The system user successfully reserved seat.
10. Use case End.
Alternative course of alternative course of action 8:-
action  If System user is not filled correctly, display ‘Error’
message and go to Step 7.

2.5.6 View Schedule
Table 4.4 which shows about use case description about view schedule use case
Use case name View schedule

Identifier UC4
Actor Passenger.
Description The user allows viewing the schedule detail.

Pre-condition The system user login into the system.
Post condition View the schedule.

Basic course of action 1. The System user can easily open the home
page.
2 System user login into the system.
3. The System user click view schedule page.
4.The system display view schedule form.
5.System user view the schedule.
6. Use case End.

2.5.7 Cancel Reservation
Table 4.5 which shows about use case description about Cancel reservation use case
Use case name Cancel reservation
Identifier UC 5
Actor Clerk .
Discretion The system allow user to cancel the reserveation..
Post-condition The reservation will be canceled
Basic course of action 1. The System user can easily open the home page
2. The system user login into the system..
3. The system user click view information page.
4. The system display passenger information table.
5. The system user fill seat number and click search button.
6. The System check user valid data whether it’s correct or
not.
7. The system displays successful cancel.
8. Use case End.
action
 If System user is not filled correctly, display ‘Error’
message and go to Step5.

2.5.8 Generate Report
Table 4.6 use case description about Generate Report use case
Use case Generate Report
Identifier UC6
Actor Clerk.
Description System user generates daily report.
Pre-condition The System user login into the system.
Post condition System user generates daily report.
2.The system user login into the system.
3.The System user click generate report button.
4.The system display generate report form.
5.The system user full fill the correct data.
6. Use case End.

2.5.9 Update Reservation
Table 4.7 which shows that use case description about update reservation use case.
Use case name Update reservation
Identifier UC7
Actor Clerk .
Description The system allows User update reservation for the users.
Post condition The system will display the information is updated successful
message.
Basic course of action 1. The System user can easily open the home page
2. The system user login into the system..
3. The system user click view information page.
4. The system display passenger information table.
5. The system user fill seat number and click search button.
6. The System check user valid data whether it’s correct or
not.
7. The system displays successful update.
8. Use case End.

action If System user is not filled correctly, display ‘Error’ message and
go to Step5.

2.5.10 Print ticket
Table 4.8 shows Use case description for print ticket use case
Use case name Print ticket
Identifier UC8
Actor Clerk.
Description The clerk print the passenger ticket.
Post condition Passenger take ticket.
3.The System user click view information page.
4. The System displays the reserved passenger list.
5. The System user checks the seat number.
6. The system user prints ticket.
7. Use case End.

2.5.11 Assign Bus
Table 4.9 which shows use case description about assign bus use case
Use case name Assign bus
Identifier UC9
Actor Manager.
Description The system users allow assign bus to the requested service.
Pre-condition The system user login in to the system.
Post condition The bus will be assign for the journey.
3.The System user click assigns bus page.
4. The system displays assign bus form.
5. The system user full fill correct requriment data.
6.The System check user valid data whether it’s correct or
not.
7. Use case End.

action If System user is not filled correctly, display ‘Error’ message
and go to Step5.

2.5.12 Create account
Table 4.10 which shows about use case description about create account use case
Use case name Create account
Identifier UC10
Actor Admin.
Description The system user creates new account to the user.
Post-condition Account creates.
2.The system user login into the system.
3.The system user click create account page.
4. The system display the account form.
5. The system user can full fill the correct requirement data
about users.
6. The System check user valid data whether it’s correct or not..
7. The System user create account..
8. Use case end.
Alternative course of action alternative course of action 6:-

If System user is not filled correctly, display ‘Error’ message
and go to Step5.

2.5.13 View report
Table 4.11 which shows use case description about view report use case
Use case name View report
Identifier UC11
Actor Manager.
Description View the report that was done daily.
Post-condition View report.
Basic course of 1. The System user can easily open the home page.
action 2. The system user login into the system.
3.The System user Click view report button.
4. The system display view report form.
5. The system user can full fill the correct requirement data.
6. The System check required data whether it’s correct or not.
7. The system user can easily see the report sends from the clerk.
8. Use case End.
Alternative course alternative course of action 6:-

of action If System user is not filled correctly, display ‘Error’ message and
go to Step5.

2.5.14 View feedback
Table 4.12 which shows use case description about view feedback
Use case name View feedback
Identifier UC12
Actor Manager.
Description The system user will view feedback sent from users.
Post-condition The system user can view the feedback that sent from user.
2. The System user click View feedback button.
3. The system display View feedback form.
4. The system user selects feedback that store on the database.
5. The system user can see the feedback that sent from user.
6. Use case End.

2.5.15 View Passenger information
Table 4.13 which shows use case description about view passenger information
Use case name View passenger information
Identifier UC13
Actor Clerk.
Description The system allow clerk to view the passenger

information.
Pre-condition The user login in to the system.
Post-condition The system will display all the passenger information.
Basic course of action 1. The System user can easily open the home
page.
3. The System user Click View passenger
information button.
4. The system display View passenger information
form.
5. The system user fill passenger seat number.
6. The system user click search button.
7. The system display passenger information.
8. The system user view information.
9. Use case End.
action If System user is not filled correctly, display
‘Error’ message and go to Step5.

2.5.16 update account
Table 4.14 shows use case description about update account use case
Use case name Update account
Identifier UC14
Actor Admin.
Description The system user can update the account for Clerk, manager.
Post condition The account will be updated.
Basic course of action 1.The System user can easily open the home page.
2.The system user login into the system
3. The System user click update account button.
4. The System display update account form.
5.The System user can full fill the correct requirement data.
6. The System check validation of data whether it’s correct or not.
7. The system can update the account successfully
8. Use case End.

go to Step5.

2.5.17 Delete account
Table 4.15 shows use case description about check ticket use case
Use case name Delete account
Identifier UC15
Actor Admin.
Description The system users can delete the account into system.
Post condition The system user delete the account.
Basic course of action 1.The System user can easily open the home page.
2.The system user login into the system
3. The System user click delete account button.
4. The System display delete account form.
5.The System user can full fill the correct requirement data.
6. The System check user valid data whether it’s correct or not.
7. The system display successfully delete.
8. Use case End.

go to Step5.

2.5.18 Logout
Table 4.16 which shows use case description about logout use case
Use case name Logout
Identifier UC16
Actor System user
Description Users logout from the system when finishes their task.
Pre-condition The user must have user account and finish their task.
Post-condition The system is close
Basic course of action 1. The user closes all opened file.

2. The user click on logout button.
3. The system is close.
4. Use case ends.

2.5.19 Post Notice
Table 4.17 which shows use case description about notice
Use case name Post notice
Identifier UC17
Actor Manager
Description The system user post the notification.
Pre-condition The system user login into the system
Post-condition The system user post the notification
Basic course of action 1. The system user can open the home page.
2. The system user login into the system
3. The system user click the notice button.
4. The system display the notice form.
5. The system user post the notice.
6. Use case ends.

2.5.20 Add schedule
Table 4.18 which shows use case description about add schedule
Use case name Add schedule
Identifier UC18
Actor Manager
Description The system user add the schedule.
Post-condition The system user add schedule
3. The system user click add schedule page.
4. The system display add schedule form.
5. The System user can full fill the correct
requirement data.
6. The system user add schedule.
7. Use case ends.

2.5.21 View Notice
Table 4.19 which shows use case description about notice
Use case name View notice
Identifier UC19
Actor Passenger
Description The passenger view the notice.
Pre-condition There must be notice from the manager
Post-condition The manager post the notice.
Basic course of action 1. The system user can open the home page..
2. The system user click notice page.
3. The system display the view notice form..
4. Use case ends.

2.5.22 Send message
Table 4.20 which shows use case description about send message
Use case name Send message
Identifier UC20
Actor Passenger ,Clerk,Manager.
Description System user send message to the available user..
Post-condition System user view message.
3. The system user click message page.
4. The system display the message form.
5. The system user write message and then click
send.
6. Use case ends.

2.5.23 View message
Table 4.21 which shows use case description about view message
Use case name View message
Identifier UC21
Actor Passenger ,Clerk,Manager
Description System user view message that sent from available user.
Pre-condition None
Post-condition System user view message
3. The system user click message page.
4. The system display message form.
5. The system user click inbox and view the
message.
6. Use case ends.
.
2.6 Domain modeling using (CRC)

A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that
have been divided into three sections. This is class name, responsibility and collaborator. Class
represents a collection of similar objects a responsibility is something that a class knows or does
and collaborator is another class that a class interacts with to fulfill its responsibility [3]

Table 5 structure of CRC
Class name
Collaborator
Responsibility
Table 5.1 shows that class responsibility for Admin actor

Admin<<Actor>>
User name Clerk

Password
Id Manager
Create account
Update account
Delete account
Table 5.2 show the class responsibility of passenger
Passenger<<Actor>>
Frist name Clerk
Last name
Id
Seat number
Register
Reserve ticket
View schedule
View post
Send message
View message

Table 5.3 shows the class responsibility of manager
Manager <<Actor>>
User name Clerk
Password
Assign bus
View feed back
View report
Post notice
Add schedule
Send message
View message

Table 5.4 shows the class responsibility of clerk
Clerk<<Actor>>
User name
Password Passenger
Id Admin
Manager
Generate report
Print ticket
View pass information
Cancel reservation
Update reservation
Send message
View message
2.7 Sequence Diagram

Sequence diagram is used to show the sequence of actions, interaction of an object with the
Actor’s and time frames of the system. [5]

Login Login
Home Login form <<Database>>
<<Link>> <<controller>>
User
1:open() 2:click()
3:dispaly form()
5:Login() 6:Verify()
4:Enter
password
&username()
7:Try again()
8:continue()
9:Successfully
login ()
Fig 1.1 Sequence Diagram for login

Register Register Register

Home <<Database>>
<<form>> <<Link>> <<controller>>
pass
1:Open()
2:Click()
3:Display form
()
6:Verify()
4:Fill register
form()
5:Create
account()
8:Register()
7:Try again()
9:Successfully
register()
Fig 1.2 Sequence Diagram for register

Home Schedule Schedule <<Database>>

Schedule form
<<Link>> <<Controller>>
pass 1:open() 2:Click()
3:Display form()
6:Verify()
4:Click busid()
5:fill form()
7:Try aging() 8:save()
9:Successfully
reserve()
Fig 1.3 Sequence Diagram for reserve ticket

View pass View information View information
Home <<Database>>
information form <<link>> <<controller>>
2:Click()
Clerk 1:Open()
3:Display form()
6: Verify()
4:Enter Seat
Number() 5:Click search()
9: Verify()
7:Try again() 8:Continue()
11:click on 10:Display
Delete information()
<<button>>()
12: successfully
deleted
Fig 1.4 Sequence Diagram for cancel reservation

View pass View information View information
Home <<Database>>
information form <<link>> <<controller>>
2:Click()
Clerk 1:Open()
3:Display form()
6: Verify()
4:Enter Seat
Number() 5:Click search()
9: Verify()
8:Continue()
7:Try again()
10:Display
information()
11:click on Edit
<<button>>()
12:Continue()
13: successfully
update()
Fig 1.5 Sequence Diagram for update reservation

Generate Generate Generate report

Home <<Database>>
report form report <<Link>> <<Controller>>
Clerk
1:Open() 2:Click()
3:Display
generate report
form()
5:Click add
report() 6:Verify
4:Fill form()
7:Try again()
8:continue()
9:Successfully
add ()
Fig 1.6 Sequence Diagram for Generate report

Print ticket Print ticket Print ticket

Home <<Database>>
form <<Link>> <<Controller>>
Clerk 2:Click()
1:open()
3:Display form()
6:Verify()
5:Click search()
8:Print()
4:Fill seat no()
7:Try again()
9: Successfully
print()
Fig 1.7 Sequence Diagram for Print ticket

View pass info View info View info

Home <<Database>>
Clerk
1:open() 2:Click()
3:Displ ay form()
6:Verify()
4:Fill seat no()
5:Click search()
7:Try aging() 8:Search()
9:Successfull y
view ()
Fig 1.8 Sequence Diagram for View pass info

View Report View Report View Report

Home <<Database>>
Manage
r 2:Click()
1:Open()
3:Display form()
6:Verify()
5:Click search()
4:Fill the data()
8:Continue()
7:Try again()
9:Display report
Fig 1.9 Sequence Diagram for View report

Assign bus Assign bus Assign bus
Home <<Database>>
manager
2:Click()
1:open()
3:Display form() 6:Verify()

5: Click add()
4:Fill the form()

7:Try again()
9:Store()
10:Sucessfully
assign()
Fig 1.10 Sequence Diagram for Assign bus

Create account Create account Create account

Home <<Database>>
Admin
2:click()
1:open()
3:Display form()
6:Verify()
5:Click Create()
4:Fill the form
()
8:continue()
7:Try again()
9:successfully
create()
Fig 1.11 Sequence Diagram for Create account

Delete account Delete account Delete account

Home <<Database>>
2:Click()
Admin
1:Open()
3:Display form()
4:Fill the form()

5:Click delete 6:Verify
button()
8:Continue()
7:Try again
9:Successfully
display()
Fig 1.12 Sequence Diagram for Delete account

2.8 Activity diagram
An Activity diagram is similar to a flowchart to represent the flow from one activity to another
activity.
Login
Systemuser
Click Login
page
Enter username
and password
Login Canecl
valid
invalid
Fig 1.13 Activity diagram for Login

Register
Click Register
page
Display
Register form
Fill form
invalid
valid
Successfully
Register
Fig 1.14 Activity diagram for Register

Reserve ticket
Login into page
Click schedule form
Display the
form
Fill form
invalid
Cancel
Valid
Successfully
reserve
Logout
Fig 1.15 Activity diagram for Reserve ticket

Cancel
reservation
Login into page
Click view pass form
Display form
Fill search form
invalid
Cancel
valid
Cancel reservation Logout

successful
Fig 1.16 Activity diagram for Cancel reservation

Create
account
Login into page
Click create account

form
Display the
form
Fill form
invalid
Cancel
Valid
Successfully create
Logout
Fig 1.17 Activity diagram for Create account

Delete account
Login into page
Click delete account

form
Display the
form
Fill form
invalid
Cancel
Valid
Successfully delete
Logout
Fig 1.18 Activity diagram for Delete account

View pass
information
Login into page
Click view form
Fill seat no
Click search
invalid
Cancel
Valid
Successfully view
Logout
Fig 1.19 Activity diagram for View passenger information

View feedback
Login to
manager page
Click view
feedback page
Cancel
View feedback Logout
Fig 1.20 Activity diagram for View feedback

Update
reservation
Login into page
Click view form
Display form
Fill search form
invalid
Cancel
Valid
Successfully update
Logout
Fig 1.21 Activity diagram Update reservation

Logout
System user
login
Cancel
Click logout
link
Display home
page
Fig 1.22 Activity diagram logout

Add schedule
Login into page
Click schedule form
Display form
fill data
invalid
Cancel
Valid
Successfully added
Logout
Fig 1.23activity diagram for add schedule

2.9 Class diagram
Class diagram is static model that shows the classes and the relationships among classes that
remain constant over the time. Class is the main building block of class diagram, which stores
and manages information in the system. In the phase of conceptual class modeling we just create
or classes ad their interrelationship among the class.
Bus
*
schedule Manager assign
1
add seat no:varchar
* bus id:varchar
bus id :int 1 uname:varchar Feedback
dname:varchar password:varchar view
date:date
departure id:int 1
* id:int
city:varchar
- assign bus
* ():varchar 1
- view feedback
1
():varchar
1
create account
post Notice Admin
view
give feedback
*
*
date:date 1
1 bus id: 1 name:varchar
* password:varchar
Passenger id:int
create account - create account
1
reserve ():varchar
uname:string Ticket
-delete account
password:string 1 ():varchar
id:int name:varchar *
departurecity: print 1
- view schedule varchar *
():varchar
- reserve arrival city: Clerk
varchar 1 manage account
():varchar
*
view pass info user
*
uname:varchar 1
password:varchar
id:int has account
Account
- generate report 1
1 ():varchar uname:varchar
-view pass info password:varchar
():varchar
Fig 1.24 Class diagram

2.10 User interface flow diagram
HOME
Reserve
ticket
LOGIN
Send
message
PASSENGE
ADMIN MANAGE View
R
R CLERK schedule
Update Delete Create

account account account View Assign View
report bus feedback Update Cancel
Print View pass View Generate
reservatio reservatio
ticket info message report
n n
Fig 1.25 User interface flow diagram

CHAPTER THREE
3. System Design
3.1 Introduction
System design is to involve converting the description of the proposed system into logical and
then physical design specification. System design is the first part to get the solution domain in a
software development. This chapter focuses on transforming the analysis model into the design
model that describes non-functional requirements and constraints described in the problem
statement and requirement analysis sections discussed earlier.
The purpose of designing is to show the direction how the system is built and to obtain clear and
enough information needed to drive the actual implementation of the system. It is based on
understanding the model the software built on. The objectives of design are to model the system
with high quality. Implementing of high quality system depend on the nature of design created
by the designer. If one wants to change the system after it has been put in to operation depends
on the quality of the system design. So if the system is design effectively, it will be easy to make
changes to it.
3.2 Design Goals and Objectives

The objectives of design are to model the system with high quality. The design goals are
derived from non-functional requirements that means non-functional requirement is the
description of the feature characteristics and attribute of the system as well as any constraints
that may limit the boundary of the proposed solution. And also to manage complexity by
dividing the system into smaller, manageable pieces and to increase the system.
The following are design goal:-
 Performance: - The system can respond fast with high throughput, i.e. it should
perform the task quickly as possible.
 Cost:- The system can be developed with minimum cost possible.
 Efficiency:- the system doing something well and thoroughly without waste of
money and time.

 Flexibility :- the system able to change new condition or situation.
 Security: the system can be secured, i.e. not allow unauthorized users to access the
system.
 Reliability:- the system can be reliable.
3.3 Class Modeling diagram

A type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, operations (or methods), and the relationships among the
classes.The class diagram with its corresponding objects will be present in the following
diagram.
Bus
*
schedule Manager assign
1
add seat no:varchar
* bus id:varchar
bus id :int 1 uname:varchar Feedback
dname:varchar password:varchar view
date:date
departure id:int 1
* id:int
city:varchar
- assign bus
* ():varchar 1
- view feedback
1
():varchar
1
create account
post Notice Admin
view
give feedback
*
*
date:date 1
1 bus id: 1 name:varchar
* password:varchar
Passenger id:int
create account - create account
1
reserve ():varchar
uname:string Ticket
-delete account
password:string 1 ():varchar
id:int name:varchar *
departurecity: print 1
- view schedule varchar *
():varchar
- reserve arrival city: Clerk
varchar 1 manage account
():varchar
*
view pass info user
*
uname:varchar 1
password:varchar
id:int has account
Account
- generate report 1
1 ():varchar uname:varchar
-view pass info password:varchar
():varchar
Fig 1.26 class modeling diagram

3.4 Current software archecture
As we described in the chapter one the current system cannot have any software
archecture.Because the current system uses manual way of ticket reservation.
3.5 Proposed software archecture

The system that we develop is an online application so the system run by choosing any browser
and the user can access easily. We selected the client server architecture where the user access
selam bus website from the server having MYSQL server for maintaining information about
registered passenger, update reservation, print ticket and generate report so all are performed in
the system. Member users can reserve a site as they want and they can modify the date of the
reservation and cancel the reservation.
Client
Internet
Web Server
Fig 1.27 software archecture

3.5.1 Subsystem Decomposition
Subsystem diagram shows the service it provides or it accepts from other subsystems, and the
coupling and the coherence between them. So we identify the following subsystem from the
main system.
 View schedule subsystem

 Register subsystem
 Reservation subsystem
 Print ticket subsystem
 Generate report subsystem
 Assign bus subsystem
 View report subsystem
 View feedback subsystem
 Create account subsystem
 View pass information subsystem

«System»
Selam bus ticket
reservation
«Sub system» «Sub system» «Sub system» «Sub system»

passenger manager admin clerk
«component» «component» «component» «component»

view schedule view report create account generate report
«component» «component» «component»

«component»
register update account view pass info
assign bus
«Sub system»
reserve seat «component» «component»
«component» print ticket
view feedback
delete account
«Sub system»
update
reservation
«component»
announce notice
«Sub system»
cancel
reservation
Fig 1.28 subsystem documentation

3.5.2 Component Modeling
Component diagrams are used to visualize the physical components in a system. It also show
how the physical components of a system are organized.
View
Passeng schedule
er
Register
Reserve
ticket
Clerk Print ticket

Security
login
Generate
report
Assign bus
Manager
View
Feedback Persista
nce
Add
schedule
Create
Admin account «Database»
Delete
account
Fig 1.29 component modeling

3.5.3 Deployment modeling

Deployment modeling is used to show the hardware of the system, the software that is installed
in the hardware and also shows how the software and the hardware components work together.
Customer Application
Computer Server Database
HTTP MYSQL Server
Register
Web Reserve
browser
Print
ticket
Generate
Report SBLSC
DB
Create
account
Mozila
fire fox
Assign
bus
View
report
View
Schedule
View
feedback
Fig 1.30 deployment modeling

3.5.4 Persistence Modeling for object oriented database
Persistent information management deals with how the persistent data (file, database, etc) are
stored and managed and it outlives a single execution of the system. Information related selam
bus line share company system view schedule, register, reserve ticket and print ticket and assign
bus information produced and other related information are persistent data and hence stored on a
selam bus company database system. This allows all the programs that operate on the SBLSC
data to do consistently.

Manager Manager
<<Table>>
Fname;varchar
Fname:varchar
Lname:varchar
Lname:varchar
Username:varchar
Username:varchar
password:varchar
password:varchar
Clerk Clerk
<<Table>>
id:int
id:int<<PK>>
Fname:varchar
Fname:varchar
Lname:varchar
Lname:varchar
uname:varchar
uname:varchar
password:varchar
password:varchar
Passenger Passenger
<<Table>>
id:int
id:int<<PK>>
Fname:varchar
Fname:varchar
Lname:varchar
Lname:varchar
uname:varchar
uname:varchar
password:varchar
password:varchar
Busid:int
Busid:int
Admin Admin
<<Table>>
Fname:varchar Fname:varchar
Lname:varchar Lname:varchar
password:varchar password:varchar
Fig 1.31 mapping

3.5.5 Access Control and Security
In the systems, different actors have access to different functionality and data. According to the
new system there are the passenger, manager ,admin and clerk have different privilege to do the
operation.
Table 6 access control and security

Actors Privilege/permission to do
Passenger  Login
 View the schedule
 Register
 Reserve ticket
 Post notice
Clerk  Login
 Generate report
 View pass information
 Print ticket
 Update reservation
 Delete reservation
Manager  Login
 Assign bus
 View comment
 View feedback
 View notice
Admin  Login
 Create account
 Delete account
 Update account

3.5.6 Boundary conditions and Exception Handling
3.5.6.1 Boundary Conditions

The new system has its own boundaries related to give and get services. To do on the System
Administrator initiates the web server using the appropriate administrator account that enables
him/her to create and delete account. The administrator also does the necessary update and
change on the system database . Any user initiates the system to get a connection with the web
server using his/her web browser available on the client side. As a result, the home page will be
displayed as a boundary object to provide different services and access the pages available there.
Based on the functionality the user is interested, there are a number of boundary objects found in
the system , so as to facilitate the connection between the user, manager and administrator tasks.
The System has Client–Server architecture and allows a remote access.
Client slide
 It gives the URL (Uniform Resource Locator) address of the web site.
 The user should be legitimate and having an account provided by the system.
 The user communicates the different links/pages using the homepage.
Server Side
 The server side should be registered on the local or any other service provider.
 Have Internet connection and database driven-website for remote access.
 It automatically save the changes and take backups.
 The user communicates the different links/pages using the homepage.
3.5.6.2 Exception Handling

Exception handling is a mechanism in which a program construct is used to consistently intercept
and handle the error occurred during application execution.
The following are some of them:-
 System will display error message if user tried to access using wrong or
invalid account by checking against the account table.
 The system display error messages when the user enter invalid inputs.

3.5.7 User Interface design
User interface design is the overall process of designing how a user will be able to interact with a
system.
The goal of user interface design is to make the user's interaction as simple and efficient as
possible, in terms of accomplishing user goals.
Fig 1.32 Home page UI

Fig 1.33 login UI

Fig
Fig 1.34 Registration UI

Fig 1.35 Reservation UI

Fig 1.36 View passenger information UI

CHAPTER FOUR
System Implementation and Testing
4. 1 System Implementation
Implementation is the phase where objectives of physical operations of the system turned into
reality i.e. real working model. The process of converting as new system into an operational one
is known as system implementation. This includes all those activities that take place to convert
from an old system to a new system.
4.1.1 Coding
First phase of implementation is coding. Coding is the process whereby the physical design
specification created by the designers is turned in to working computer code by the programmer.
Modern language that used is Hypertext Preprocessor(PHP).
The code is made simple in such a way that another programmer can easily understand and work
on that in future.
 Sample code for login
<?php
session_start();
session_destroy();
$user = "";
$pass = "";
if ($_SERVER['REQUEST_METHOD'] == 'POST'){
include 'sql.php';
$user = $_POST['username'];
$pass = $_POST['password'];
//unwanted HTML (scripting attacks)
$user = html special chars($user);
$pass = html special chars($pass);
$SQL = "SELECT * FROM employe";

$result = mysql_query($SQL);
while ($db_field = mysql_fetch_assoc($result)) {
$a = $db_field['username'];
$b = $db_field['password'];
$pos = $db_field['position'];
if(($user ==$a) AND ($pass ==$b)){
if($pos == "clerk")
session_start();
$_SESSION['username'] = $user;
$_SESSION['Clerk_page'] = "log";

mysql_close($db_handle);
header("Location: Clerk_page.php");
break;
}
else{
echo"Check username and/or password.<a href=Clerk_form.php><b>Try

again</b></a>";
}
}
?>
 Sample code for reservation
<script type="text/javascript">
function validation_for_signup() {
var check_Room_Type = /^[\w\.]+@[a-zA-Z_]+?\.[a-zA-Z\.]$/;
var check_priceeb = /^[09]{2}[0-9]{8}$/;
var check_priceus = /^[09]{2}[0-9]{8}$/;
if(document.signup.Room_Type.value=="") {
alert("Please enter Room_Type");
document.signup.Room_Type.focus();
return false;
}
else if(check_Room_Type.test(document.signup.Room_Type.value) == false) {
alert('Please enter the correct format for user name,user name only text!');
document.signup.Room_Type.focus(); return false;
}
if(document.signup.Room_Type.value=="") {
alert("please enter Room_Type"); document.signup.Room_Type.focus();
return false;
}
else if(check_email.test(document.signup.Room_Type.value) == false) {
alert('Please enter a correct Room_Type again!');
document.signup.Room_Type.focus();
return false;
} if(document.signup.password.value=='') {
alert("Please enter Password.");
document.signup.password.focus();
return false;
}
else if(document.signup.password.value.length<6) {
alert("Password is too short.");

return false;
}
if(document.signup.passconf.value=='') {
alert("Please enter confirm Password.");
document.signup.passconf.focus();
return false;
}
else if(document.signup.password.value!=document.signup.passconf.value) {
alert("Password does not match.");
return false;
} if(document.signup.firstname.value=="") {
alert("please enter firstname");
document.signup.firstname.focus();
return false;
} else if(check_name.test(document.signup.firstname.value) == false) {
alert('Please enter the correct format for first name,first name only text!');
document.signup.firstname.focus();
return false; } if(document.signup.lastname.value=="") {
alert("Please enter lastname");
document.signup.lastname.focus();
return false;
}
else if(check_name.test(document.signup.lastname.value) == false) {
alert('Please enter the correct format for last name,last name only text!');
document.signup.lastname.focus();
return false; }
if(document.signup.priceus.value=="") {
alert("Please enter priceus ");
document.signup.priceus.focus();
return false;
}
else if(check_priceus.test(document.signup.priceus.value) == false) {
alert('Invalid priceus ,Please Try Again!');
document.signup.priceus.focus();
return false; }
} </script>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
function ValidateAlpha(evt)
{
var keyCode = (evt.which) ? evt.which : evt.keyCode
if ((keyCode < 65 || keyCode > 90) && (keyCode < 97 || keyCode > 123) && keyCode
!= 32 && keyCode != 8 && keyCode != 9)
{

alert(" Only letters are allowed! ")
return false;
}}
function isNumberKey(evt)
{
var charCode = (evt.which) ? evt.which : event.keyCode
if (charCode > 31 && (charCode < 48 || charCode > 57)){
alert("Only number is allwed!")
return false;
}
if(document.bform.phone.value=="")
{
alert("please enter phone number");
document.bform.phone.value="";
document.bform.phone.focus();
return false;
}
var str=document.bform.phone.value;
var valid="0123456789+";
for(i=0;i<str.length;i++)
{
if(valid.indexOf(str.charAt(i))==-1)
{
alert("please insert phone number only number");
document.bform.phone.value="";
return false;
}
}
if(str.length!=10)
{
alert("please enter phone number 10 digit.");
return false;
}
if (str.charAt(0)!="0")
{
alert("phone number should be start with 0");
return false;
}
if (str.charAt(1)!="9")
{

alert("phone number should be start with 09");
return false;
}
</script>
<html>
<style>
#example1 {
background-color: green;
padding: 30px;
background:#00ffff;
width: 850px;
padding: 25px;
border: 25px solid navy;
margin: 25px;
}
</style>
<body>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<?php
//<input type="image" src="img_submit.gif" alt="Submit" width="48" height="48">
$pest=0;
INCLUDE "connection.php";
session_start();
$busid=$_GET['id'];
$SQL = "SELECT * FROM `seat` where Busid='$busid' order by seatNo asc;";
$result = mysql_query($SQL) or die(mysql_error());
?>
<table>
<?php
$seatCount=0;
while ($db_field = mysql_fetch_array($result)) { //SELECT * FROM `seat` where Busid='5'
order by seatNo asc
?>

<?php if($seatCount==0) echo "<tr>"?>
<td
style="background-color:
<?php
if($db_field['status']=="oc")
echo "red";
else
echo "green";?>;"
>
<?php echo $db_field['seatNo']; ?>
<img src="image/reserve.png" width="100" height="50"/>
</td>
<?php
if(isset($_POST[$db_field['seatNo']]))
{
$pest=$db_field['seatNo'];
$res=mysql_query("update `seat` set status='oc' where seatNo='$pest';");
}
?>
</td>
<?php if($seatCount==3) echo "</tr>"; $seatCount=0; $seatCount++;//echo
$db_field['seatNo']; ?>
<?php
}
?>
</table>
<div class="modal-body">
<form method="post" action="add.php?busid=<?php echo

$busid; ?>" enctype="multipart/form-data">
<table class="table1">
<tr>
<td><label style="color:#3a87ad; font-
size:18px;" >Bus Id</label></td>

<td><input type="text" name="Busno"

placeholder="<?php echo $busid; ?>" <?php echo "disabled"; ?> /></td>
</tr>
<tr>
size:18px;">FirstName</label></td>
<td><input type="text" name="fname"

placeholder="FirstName" onKeyPress="return ValidateAlpha(event)"required /></td>
</tr>
<tr>
size:18px;">LastName</label></td>
<td><input type="text" name="lname"

placeholder="LastName" onKeyPress="return ValidateAlpha(event)"required /></td>
</tr>
<tr>
size:18px;">Seat No</label></td>
<td><input type="text" name="Seat"

placeholder="Seat No"onKeyPress="return isNumberKey(event)" required/></td>
</tr>
</table>
<div class="modal-footer">

<button type="submit" name="Submit" class="btn btn-
primary">Add</button><br></br><br></br>
</div>
<div id="example1">
<img src="image/bus1.jpg" alt="Nice car" style="width:20%" alt="ሰሰሰሰ ሰሰ ሰሰሰ ሰሰሰ
ሰሰ"> <img style="margin-left: 20px;border:0px dotted brown;border-top-right-radius:
20px;width: 40%;border-top-left-radius: 20px;width: 100px;"src="image/dove.gif"/>
<p>ሰሰሰሰ ሰሰ ሰሰሰ ሰሰሰ ሰሰ</p>
<h2>Further Information</h2>
<p>When the color is red the set number is reserverd.</p>
<p>When the color is green the set number is not reserverd.</p>
<p>If the passenger can’t pay within 4 hours after he or she reserved the reserved seat is
canceled and replace by others.</p>

<p>You need to show up identification card when you come to buy the ticket.</p>
<img src="image/logo1.png" alt="Selam Bus" style="width:10%">


<p>Remember to set your clocks ahead this weekend so that you don't miss your bus!</p>
<img style="margin-right: 20px;max-width: 264px;
max-height: 148px;"src="image/bus3.png"/>
<p>ሰሰሰሰሰሰሰ ሰሰሰሰ ሰሰሰሰሰ ሰሰሰሰሰሰሰሰሰሰ!!!</p>
</div>
</body>
</html>
4.2 Testing
Final phase of implementation is testing.Testing is a process to show the correctness of the
program. Testing is checking of the system workability in an attempt to discover errors and
avoiding such errors from the system. In this the team members tested the entire system as a
whole with all forms, code, modules. In this we tested all the functionalities in the System.
4.2.1 Unit testing

Unit testing is every module of the System is separately tested. It is often done by the
programmer to test that the unit he or she has implemented is producing expected output against
given input.

Table 7 Test case for login
Test login
Test Case ID = SBLSC login Test Case
Unit to Test = Authentication of login system user
Assumptions = Login into appropriate page
Test Data = User Name(empty , invalid user name, valid username)
Password (empty ,invalid password, valid password)
Steps to be Executed Data Expected Results
Empty Username and password and

Empty “please enter user name and
Click Login button
password”
Enter invalid User name, password “invalid user name and password
and Click Login button Invalid username, password
please try again ”
Enter valid username ,empty

Valid username
Password and Click Login button “please enter the password”
Enter valid password ,empty user

Valid password
name and Click Login button “Please Enter user name”
Enter valid Username and Password “Login in to approprate page”

Valid username, password
then Click Login button

Table 8 Test case for reservation
Test Reservation
Test Case ID = SBLSC reservation Test Case.
Unit to Test = Authentication system user to reserve ticket.
Assumptions = reserve ticket in the selam bus.
Test Data = seat number(empty ,valid)
Name (empty,valid )
Steps to be Executed Data Expected Results
Empty seat no and name and Click

Empty
add button “please enter seat no and name”
Enter invalid seat no, name and Click

add button Empty “invalid seat no and name please
try again ”
Enter valid name ,empty seat no and

Valid name
Click add button “please enter the seat no”
Enter valid seat no and name then The passenger is successfully

click add button All fields fulfill with valid data reserve.

4.2.2 Integration testing
Integration testing is the activity of software testing in which individual software modules are
combined and tested as a group. It occurs after unit testing and before acceptance testing.
4.2.3 Acceptance testing
Acceptance testing is the process of testing system it accepted if the user of the system is
satisfied. In this perspective acceptance testing is widely used to prove that system performs as
per the requirements. In acceptance testing the customers provides the input data to validate the
system operation.
4.2.4 System testing
It is the final step of testing process. In this the team members tests the entire system as a whole
with all forms, code, modules. This form of testing is popularly known as Black Box testing or
System tests. In this the team members tests all the functionalities in the System. All errors in the
forms, functions, modules are tested.

CHAPTER FIVE
Conclusion and Recommendation
5.1 Conclusion
As we described in the chapter one proposal phase the current selam bus line share company uses
manual way ticket reservation system .Due to this the current system has different problem
related with reservation.So the system we developed in the selam bus line share company change
in to the computerized way of ticket reservation. Ingenerally the system can solve the problems
which occur in the current system.it reduce the human error and it can increase efficiency.
5.2 Recommendation
we recommended that Selam bus line share company should use this system wisely to solve its
problems and the online Payment in this project is conceptual or ideal but not function real
online payment. Because, it needs linking with the banking system. This is not implemented in
this stage of our project development.so, researchers who are willing to conduct project in this
area needs to be think about online payment by forming contact with bank system.
5.3 References
[1]https://en.wikipedia.org/wiki/Selam_Bus_Line_Share_Companywww.selambus.com
[2]https://en.wikipedia.org/wiki/Selam_Bus_Line_Share_Company
[3]Scott W.Ambler The Object Primer Second Edition
[4] https://en.wikipedia.org/wiki/PHP
[5] Scott W.Ambler The Object Primer Second Edition

Annex1: sample interviewed questions
Questions asked during requirement gathering using interview are:-
A. What are the business rules you use currently?

B. How does your current system work?
C. How you make relationship with the passenger?
D. What are the procedures or steps when passenger get service of the Office?
E. What are the problems that you face when the passenger use the existed system?
Annex2: sample interviewed questions
Annex3: Sample code
<?php
session_start();
session_destroy();
$user = "";
$pass = "";
if ($_SERVER['REQUEST_METHOD'] == 'POST'){
include 'sql.php';
$user = $_POST['username'];
$pass = $_POST['password'];
//unwanted HTML (scripting attacks)
$user = html special chars($user);
$pass = html special chars($pass);
$SQL = "SELECT * FROM employe";

$result = mysql_query($SQL);
while ($db_field = mysql_fetch_assoc($result)) {
$a = $db_field['username'];
$b = $db_field['password'];
$pos = $db_field['position'];
if(($user ==$a) AND ($pass ==$b)){
if($pos == "clerk")
session_start();

$_SESSION['username'] = $user;
$_SESSION['Clerk_page'] = "log";
mysql_close($db_handle);
header("Location: Clerk_page.php");
break;
}
else{
echo"Check username and/or password.<a href=Clerk_form.php><b>Try

again</b></a>";
}
}
?>

Selam Bus Ticket Reservation System

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Selam Bus Ticket Reservation System

Caricato da

Copyright:

Formati disponibili

ONLINE SELAM BUS TICKET RESERVATION SYSTEM 2015/16

KOMBOLCHA INSTITUTE OF TECHNOLOGY

DEPARTMET OF INFORMATION TECHNOLOGY

FINAL YEAR PROJECT

TITLE:-SELAMBUS TICKET RESERVATION SYSTEM

Advisor Name:-Salihadin S (MSC)

Submitted date 6/20/2016

DEPARTMENT OF INFORMATION TECHNOLOGY Page - 1 -

DEPARTMENT OF INFORMATION TECHNOLOGY Page i

DEPARTMENT OF INFORMATION TECHNOLOGY Page ii

HTML: Hypertext Markup Language

CSS: Cascading Style Sheet

SQL: Structured Query Language

MYSQL:Multiuser Structured Query Language

PHP:- PHP Hypertext Preprocessor

SNMP:- Simple Network Management Protocol

HTTP: Hypertext Transfer Protocol

UC: Use case

UI: User interface

CRC: Class Responsibility Collaborator

SBLSC:Selam bus line share company

Dname :Driver name

DEPARTMENT OF INFORMATION TECHNOLOGY Page iii

DEPARTMENT OF INFORMATION TECHNOLOGY Page iv

Table 1 shows hardware cost .......................................................................................................... 9

DEPARTMENT OF INFORMATION TECHNOLOGY Page vii

Fig 1 use case diagram .................................................................................................................. 16

DEPARTMENT OF INFORMATION TECHNOLOGY Page viii

DEPARTMENT OF INFORMATION TECHNOLOGY Page ix

DEPARTMENT OF INFORMATION TECHNOLOGY Page 1

Some of the major problems are:-

 Inconsistent data and poor time management.

DEPARTMENT OF INFORMATION TECHNOLOGY Page 2

1.3.2 Specific Objective

 To enable the user to interact or introduce with the new

1.4.1 System Analysis and Design

DEPARTMENT OF INFORMATION TECHNOLOGY Page 3

1.4.2 Method of data collection

1.5 Feasibility Study

1.5.1 Economic Feasibility

The system minimizes the work load of the employees.

DEPARTMENT OF INFORMATION TECHNOLOGY Page 4

1.5.3 Operational feasibility

1.5.4 Political feasibility

DEPARTMENT OF INFORMATION TECHNOLOGY Page 5

1.6.1 Scope of project

The new system can perform the following activities:-

Generally our project is performed the above mentioned tasks.

1.6.2 Limitation of the Project

DEPARTMENT OF INFORMATION TECHNOLOGY Page 6

 It increases their profit by making their expenditure less.

For the Passenger:-

 It reduces the wastage of time and money.

1.8.1 System Implementation Tools

 Php has also support for most for

DEPARTMENT OF INFORMATION TECHNOLOGY Page 7

1.8.3 Software tools:-

1.9 Project cost

1.9.1 Hardware cost:-

DEPARTMENT OF INFORMATION TECHNOLOGY Page 8

No Material Amount Price per Total price

Total 1486 Birr

1.9.2 Software cost:-

No Material Price per unit