DEBRE MARKOS UNIVERSITY

BURIE CAMPUS
DEPARTEMENT OF COMPUTER SCIENCE

PROJECT TITLE: DEBRE MARKOS UNIVERSITY VEHICLE

MANAGEMENT SYSTEM

GROUP:-1

NAME ID

1. KIDANEMARIYAM FRESBHAT --------------------- DMU1403803

2. ROBEL YISEHAK---------------------------------------- DMU1404143
3. EYASU ABEBE ------------------------------------------- DMU1406005
4. KALEAB GETNET---------------------------------------DMU1403763
5. HAYMANOT TILAHUN--------------------------------- DMU1403698

College of Computing, Department of Computer Science

Debre Markos University, Burie, Ethiopia
SUBMITTED TO: Temesgen

DATE OF SUBMISSION:20/11/2016 E.C

List of Acronym

1. BR = Business Rule
2. CSS = Cascading Style Sheet
3. HTML = Hypertext Mark-up Language
4. Info = information
5. PHP = Hyper Text Preprocessor
7. UC = Use Case
8. UI = User Interface
9. UML = Unified Modeling Language

I
Acknowledgment
First of all, we would like to thank our Lord, who gives us patience, health, wisdom and ability.
Secondly, we thank some of the employees of DMU for giving us every information on their
current system. Finally we thank our teacher Mr.Temesgen for his patience and guidance.

Contents

II
List of Acronym...............................................................................................................................I

Acknowledgment............................................................................................................................II

CHAPTER ONE..............................................................................................................................1

1. Introduction..................................................................................................................................1

1.1 Background of The Organization..............................................................................................1

1.2 Background of the Project.........................................................................................................1

1.3 Motivation..................................................................................................................................3

1.4 Statement of Problem................................................................................................................3

1.5 Objective of The Project............................................................................................................3

1.5.1 General objective.............................................................................................................3

1.5.2 Specific objective............................................................................................................3

1.6 Scope of the Project and Limitation..........................................................................................4

1.6.1 Scope...............................................................................................................................4

1.6.2 Limitation of the project..................................................................................................5

1.7 Application of Results...............................................................................................................5

1.7.1 Beneficiaries of the project..............................................................................................5

1.7.2 Significance of project.....................................................................................................5

1.8 Methodology..............................................................................................................................6

1.8.1 Data gathering methodology...........................................................................................6

1.8.2 Development tools...........................................................................................................7

1.9 Developmental Approach..........................................................................................................7

1.10 Feasibility Study......................................................................................................................8

1.10.1 Economic feasibility......................................................................................................8

1.10.2 Technical feasibility......................................................................................................8

III
 1.10.3 Time feasibility..............................................................................................................8

1.10.4 Operational feasibility...................................................................................................9

1.10.5. Schedule feasibility......................................................................................................9

1.11 Annexes...................................................................................................................................9

1.11.1 Project time schedule plan.............................................................................................9

CHAPTER TWO...........................................................................................................................11

2. System Analysis.........................................................................................................................11

2.1. Overview of existing system..................................................................................................11

2.1.2 Users of the existing system..........................................................................................11

2.2 Proposed system......................................................................................................................12

2.3 System Requirement Specification..........................................................................................13

2.3.1 Functional requirements................................................................................................13

2.3.2. Non- functional requirements.......................................................................................14

2.3.3. Paper Document in the Existing System......................................................................15

2.3.4. Business rules...............................................................................................................17

2.3.5. Change cases................................................................................................................17

2.4 System Requirement Analysis.................................................................................................17

2.4.1 Actors and use case identification.................................................................................17

2.5 Essential use-case diagram......................................................................................................19

2.5.1 Use case identification...................................................................................................19

2.5.2. System Use Case..........................................................................................................19

2.5.3 Essential use-case documentation.................................................................................20

2.6 Sequence Diagram...................................................................................................................36

2.7 Activity Diagram.....................................................................................................................41

CHAPTER THREE.......................................................................................................................44

IV
3. System Design...........................................................................................................................44

3.1. Design of class diagram..........................................................................................................44

3.2 User Interface Design..............................................................................................................49

CHAPTER FOUR.........................................................................................................................50

4. Implementation..........................................................................................................................50

4.1 Programing Language Used....................................................................................................50

4.2 Algorithm Used for Log In......................................................................................................50

4.3 Sample Codes..........................................................................................................................50

CHAPTER FIVE...........................................................................................................................58

5. Testing and Deployment............................................................................................................58

5.1 Deployment Diagram...............................................................................................................59

CHAPTER SIX..............................................................................................................................61

6. Conclusion and Recommendations............................................................................................61

6.1 Conclusion...............................................................................................................................61

6.2 Recommendation.....................................................................................................................61

References………………………………………………………………………………………………... 62

V
List of Figures
Figure 2.1 Work flow of proposed system....................................................................................12
Figure 2.2: gate pass paper document in the existing system........................................................15
Figure 2.1: requisition form paper document in the existing system.............................................. .
Figure 2.4 use case diagram...........................................................................................................20
Figure 2.5: Sequence diagram for create account..........................................................................37
Figure 2.6: Sequence diagram for login........................................................................................37
Figure 2.7: Sequence diagram for register vehicle........................................................................38
Figure 2.8: Sequence diagram for view vehicle information........................................................39
Figure 2.9 Sequence diagram for logout........................................................................................40
Figure 2.10: Activity diagram for Login.......................................................................................41
Figure 2.11: Activity diagram for create account..........................................................................42
Figure 2.12: Activity diagram for register vehicle........................................................................43
Figure 3.1 Class diagram...............................................................................................................45
Figure 3.2 Home page....................................................................................................................49
Figure 3.3 login as page.....................................................................................................................
Figure 3.4 first manager page............................................................................................................
Figure 5.1 Deployment diagram....................................................................................................60

VI
List of Tables

Table 1.1Time schedule plan...........................................................................................................9

Table 1.2 Budget plan....................................................................................................................10
Table 1.3 Cost Related to Software...............................................................................................10
Table 2.1: Actors Table.................................................................................................................18
Table 2.2: Use case description of login........................................................................................22
Table 2.3: Use case description of create account.........................................................................22
Table 2.4: Use case description of view route information...........................................................23
Table 2.5: Use case description of update account........................................................................24
Table 2.6: Use case description of delete account.........................................................................25
Table 2.7: Use case description of view vehicle information........................................................26
Table 2.8: Use case description of register vehicles......................................................................27
Table 2.9: Use case description of assign vehicle.........................................................................27
Table 2.10: Use case description of check fuel balance................................................................28
Table 2.11: Use case description of request maintenance.............................................................30
Table 2.12: Use case description of request services....................................................................31
Table 2.13: Use case description of generate report......................................................................32
Table 2.14: Use case description of view maintenance request....................................................33
Table 2.15: Use case description of submit comments..................................................................34
Table 2.16: Use case description of view comments.....................................................................35
Table 2.17: Use case description of logout....................................................................................35
Table 3.1: Description of Assign vehicle class..............................................................................46
Table 3.2: table of Assign vehicle method....................................................................................46
Table 3.3: description of comment class.......................................................................................46
Table 3.4: description of comment method...................................................................................47

VII
Table 3.5: description of vehicle registration class.......................................................................47
Table 3.6: vehicle registration method..........................................................................................47
Table 3.7: driver class....................................................................................................................47
Table 3.8: driver method................................................................................................................48
Table 3.9: Send report class...........................................................................................................48
Table 3.10: Send report method.....................................................................................................48
Table 5.1 Unit testing....................................................................................................................58
Table 5.2. Integrated testing..........................................................................................................58
Table 5.3 System testing................................................................................................................59

VIII
CHAPTER ONE

1. Introduction
Online vehicle management system is a system which concerned with how vehicles could be

managed and controlled in digital based way by the employees of the organization. Currently, the

vehicle gives service use manual way of information gathering and documenting, no reliable

communication between different workers, as well as there is lack of security, difficult to

coordinate, and to identify the owner of the vehicle.

This project will intend to advocate for the need of organizations to change the manual system to
automated vehicle management system.

Automated systems make it possible to have a better accuracy, to increase the quality of the
work, to reduce the time it takes, to minimize cost, to keep the security and organization of data
in most advantageous condition, to make data transfer easier and also make it possible to save
and back up all transactions in case of vehicle management to keep the data in a centralized way
which is available to all the users simultaneously.

1.1 Background of the Organization

Debremarkos University is a prominent higher education institution located in the town of
Debremarkos, in the Amhara region of Ethiopia. Established in [2007], the university has a rich
history of providing quality education, conducting research, and contributing to the socio-
economic development of the region and the country as a whole.

The university offers a wide range of undergraduate, postgraduate, and vocational programs
across various disciplines, including agriculture, engineering, social sciences, natural sciences,
health sciences, business, and humanities. With a strong emphasis on academic excellence,
innovation, and community engagement, Debremarkos University has become a hub for
intellectual growth, knowledge creation, and skill development among its students and faculty
members.

1
Debremarkos University is committed to promoting a culture of learning, critical thinking, and
ethical leadership among its students. The university's academic programs are designed to equip
graduates with the knowledge, skills, and values needed to excel in their chosen fields and
contribute meaningfully to society. Through its research activities, Debremarkos University
seeks to address pressing challenges facing the region and the country through innovative
solutions and evidence-based interventions.

In addition to its academic offerings, Debremarkos University is actively involved in community

outreach initiatives, partnerships with industry stakeholders, and collaborations with other
educational institutions both locally and internationally. These engagements enable the
university to foster a spirit of collaboration, exchange of ideas, and mutual learning for the
benefit of its students, faculty, and the broader community.

As a leading institution of higher learning in the region, Debremarkos University is dedicated to

upholding the highest standards of academic integrity, professionalism, and inclusivity. The
university strives to create a conducive learning environment that nurtures creativity, diversity,
and respect for different perspectives, ensuring that all members of the university community can
thrive and achieve their full potential.

Overall, Debremarkos University stands as a beacon of knowledge, innovation, and excellence in

higher education in Ethiopia. With its commitment to academic excellence, research innovation,
and community service, the university continues to make significant contributions to the
development of individuals, communities, and society at large.

1.2 Background of the Project

The vehicle management system will be designed to provide real-time tracking of vehicles,
maintenance scheduling, fuel consumption monitoring, and cost analysis. By implementing this
system, Debremarkos University seeks to optimize the utilization of its vehicles, reduce
operational costs, and ensure the safety and reliability of its transportation services. It replaces all
the paper work. It keeps records of all vehicles that are under the organization also, given to the

2
co-workers, generally the project mange those performance in order to maximize the benefit of
the doubt from the existing system.

1.3 Motivation
This project is dedicated to: -

 Provide compressive set of features to enhance the operational limit.

 Evaluate their performance in different scenarios.

 Suggest modifications for greater efficiency.

 Model the existing manual Debre Markos University vehicle management system.

1.4 Statement of Problem

In the current vehicle management system, information exchange and service control are process
in manual way. There are various problems that vehicle management system faces due to the file
manual handling of its daily activity.

 Not sequenced flow of information during retrieve.

 It’s a time-consuming process to assign vehicles and to generate required reports.
 Difficulty to get the required detailed information about specific vehicle.
 Employees and customer couldn’t get high satisfaction.
 There is no effective coordination between various employers.
 Reports are not generated on time.

1.5 Objective of the Project

1.5.1 General objective
The main objective of this project is to develop online Vehicle Management System for Debre
Markos University

1.5.2 Specific objective

The specific objectives of the project, which will be done in order to achieve the general
objective are.

3
  Study the existing system and find out the problem.
 Design the new system that can overcome the problem of the current system.
 Selecting the best alternative solution
 Identifying alternative solution.
 Understand functional and non-functional requirements of the system.
 Design and modeling of the system.
 Implementing the system in efficient way.
 Design user interface for easy navigation and obtained of required information from
the database.
 Testing the system.

1.6 Scope of the Project and Limitation

1.6.1 Scope
Project scope is a detailed outline of all aspects of a project, including all related activities,
resources, timelines, and deliverables, as well as the project’s boundaries.

The proposed system performs the following functions:

 Generate and send reports: It allows manager generating report for the tasks performed
and if there is any difficult problem.
 Vehicle maintenances: Vehicles should be maintained when they are damaged or based
on schedule so, the driver can request maintenance.
 Vehicle registration: Allow the Manager to register vehicle.
 Manage user account: Manager create, activate & deactivate account for users and can
update their account.
 Make service: -the system supports the actors of the system (i.e., staff and drivers) can
ask a service to their trip work.
 Assign vehicle: -the proposed system of the project is supporting the manager to assign
vehicles for the specific reserved road trip.

4
  Assign drivers: -the proposed system of the project is supporting the manager to assign
drivers and notify them.
 Create, update, activate and deactivate user account: - the system admin can create,
update, activate and deactivate user account.
 Postpone schedule: - the manager can postpone the requested schedule.
 Request vehicle maintenance: - the driver can request maintenance for his/her vehicle.
 Approve/cancel maintenance request: - the mechanic can approve/cancel the driver
request based on technical and personal capability.

1.6.2 Limitation of the project

At the end of this project the new functionality in each module will be able to solve many of the
problems in the existing system But, even the proposed system will perform most of the
activities the system will not connected to other branches of the organization, doesn't include fuel
recharging system for the drivers, only English reader and writer literate's users can perform on
this system, doesn't include guard sector who received a command to let the vehicle exit from the
office, not functional in perform detecting current location of vehicles, sensing coming car and
arriving car as these functions require sensor and GPS technology and due to lack of time and
resource.

1.7 Application of Results

1.7.1 Beneficiaries of the project

There are different bodies that will be benefited from this system. The main beneficiaries of this
system include:
 For the Organization: -the organization gets benefit from this project because they can
solve the problems that exist in the service easily. And it will improve the overall
efficiency of the coworkers who was facing the problems.

5
  For customer: - since the system reduces the time consumed during schedule work trip
to give field maintenance services for the customer the customer are also will be the
beneficial from this system.

1.7.2 Significance of project

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

For the organization
 It increases their profit by making their expenditure less.
 It increases customer satisfactions.
 It reduces the required manpower.
 High coordination between various employers.
 To have good authentication and security.
 To make easy and fast report generate
 Easy to process requests.
 Easy to manage historical data in secure manner.
 Minimizes cost of operations and the work load.
 Avoiding improper resource consumption and data loss.
 To make easy vehicle assignation.
 Easy to get the required detailed information about specific vehicle.
For the customer
 It reduces the wastage of time and money.
 Reduce energy.

1.8 Methodology
The method of Requirement gathering that is used on this project includes Interview,
Observation and document analysis to collect/ gather information and data of the existing system
to develop new system.

1.8.1 Data gathering methodology

6
  Interview: - we contact the representative of 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.
 Observation: we look and examine how the workers are doing their work so that we
would understand the existing system. We observe the actual work in scheduling staff
of the organization to gather additional data (i.e. manual scheduling system) being
done by the organization and consolidated with what was obtained through
observation.
 Random drawing of ideas (Brainstorming): - Ideas that were generated from group
members are the starting point of this project and continued to the main base in order
to finish the project and to make the system more effective.
 Document analysis: reading the document available in the organization and by
visiting the organization.

1.8.2 Development tools

Hardware tools

 Desktop computer(laptop)
 Storage device: hard disk & Flash disk
 Internet cable
 Internet network
 Pen
 Paper
 Printer
 Digital camera
Software tools

 MS-word 2007,2010 & 2013,

 PHP, html, my-SQL database
 Operating system:-windows 7, windows 8 & windows 10
 Microsoft PowerPoint
 Adobe Photoshop cs4

7
  Notepad++
 Browser: - Opera & Chrome

1.9 Developmental Approach

There are many developmental approaches: -

 Waterfall (linear)
 Prototype (iterative)
 Evolution (incremental)
 Spiral
Among this developmental approach we select Prototype (iterative) because: -
 Potential defects are spotted and dealt with early.
 Progress is easily measured.
 Testing is facilitated by the modules being relatively small.
 An operational product is delivered with every iteration.

1.10 Feasibility Study

1.10.1 Economic feasibility

It refers to the benefits or outcomes we are deriving from the product compared to the total Cost
we are spending for developing the product. The system that we are going to develop is
economically feasible. For instance, the proposed system to develop will decrease a lot of money
that is consumed to buy stationery materials such as paper, pencil, pen, labors and so on. It also
reduces the cost to replacing the lost data. It also have intangible benefit like giving better and
effective service, increase communication speed, satisfying the personnel and improve
employees’ moral, creates better personnel-organization relationships.

1.10.2 Technical feasibility

This system has been developed using PHP as front end and MYSQL as back end. A project
possible to use many front and back end, but we selected PHP and MYSQL because we are
familiar with them and since it's easy to use.

1.10.3 Time feasibility

To ensure our system is being feasible in time constraints if:

8
  Giving immediate responses to the users.
 Minimize the response time of the tasks required.
 The system is less time consuming.

1.10.4 Operational feasibility

It is a measure of how well a proposed system solves the problems. Our software will be used
effectively. It is also possible to maintain and support after it has been developed and the system
will result in workforce reduction which means it has high operational feasibility so the usability
increases.

1.10.5. Schedule feasibility

Schedule feasibility determines whether the proposed system will be completed on the given
schedule or not. Whatever the scarcity of time given for the project, by the internal motivation
and potential of the team members of the project, we surely expect as the project will be
completed on time so the system is schedule feasible.

1.11 Annexes

1.11.1 Project time schedule plan

Activities JUNE'10 JUNE'15 JUNE'1 JUNE JUNE JULY'

9 '23 '27 20
DAY DAY DAY DAY DAY week
1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 1 2 3
0 1 2 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1 Proposal and
Presentation
2 System Analysis
3 Presentation
4 System design
5 Implementation
and coding
6 Testing
7 Presentation
8 Post
Implementation

9
 9 Project
submission date

Table 1.1Time schedule plan

No Hard Ware Items Quantity Price(birr) Total price

1 Desktop computer(laptop) 3 16500 49500

2 Hard disk 2 4000 8000
3 Internet cable 100 m 10 1000
4 Internet network 8gb 50 400
5 Pen 1 packet 515 515
6 Paper 1 packet 500 500
7 Printer 1 26500 26500
8 Digital camera 2 34600 69200
9 Flash disk 4(16gb) 300 1200
Total 156,815 birr

Table 1.2 Budget plan

No Software Cost(birr)
1 Browser 15
2 WAMP 15
3 Operating system 50
4 Microsoft 20
5 Adobe Photoshop 15
6 Notepad++ 10
TOTAL 125 birr

Table 1.3 Cost Related to Software

Total cost for the Project= 156,940 birr

10
CHAPTER TWO
2. System Analysis
This chapter covers introduction of the existing system, role of the existing system, and major
functions/activities of the proposed system. This chapter also covers practices to be preserved
from the existing system, proposed solution of the existing system that address problems of the
existing system and requirements of the proposed system.

2.1. Overview of existing system

Currently DMU Vehicle Management system uses paper-based documentation or manual
system approach to record and report its file. There are activities and tasks that can be taking
care off by the staff members, driver and technician like:
 Report preparation: -Report can be prepared in the form of paper documentation.
 Document collection: -document can be collect from the prepared report according to
their function and submitted time to allocated place (it may be shelf).
 Order driver: -based on the request service the manager order the driver by giving the
word command or written command.
 Order technician: -The manager orders the mechanics by looking the car that need
repair and maintain service for proper function.
 Request maintenance: - The mechanic Evaluate the requester question forward
evaluated question to manager.
 Assign car: -when the service requested, the manager arranges and assign the car to
provide service orally.
 The staff request the car service to manager for his/her trip work.
 The messenger circulates the forms and documented report from one office to
another.

2.1.2 Users of the existing system

The followings are players/actors in the existing system:

 Manager: The listed below are the duties of the manager.

 Order driver
 Give commands for mechanics according to their task.

11
  Register the car
 Calculate fuel balance
 Prepare exit permission
 Driver: The duty of drivers are listed below
 Drive
 Check the vehicle regularly

2.2 Proposed system

In basis of understanding the current manual system and identifying all the problems occurred
during over all activities of the existing system, the project team has decided to design an
automated web-based system model as solution. Since the client server model fully flagged
online at any time, it will solve the problem and limitation of the current manual system for
DMU.
 The administer manages all works related to the system like creating and deleting
manager, driver, staff and mechanics account and register employee.
 The Vehicle manager in the system can register vehicle, update vehicle record, view
vehicles information, manage request, assign vehicle (i.e., the system give commands and
response for the drivers, mechanics and staff).
 The one who drives the car, in this system the driver views notification and request
maintenance record for the mechanic and can submit comment to the manager.
 Mechanics view maintenance request and can approve or reject the request and send
notification to the requestor

Figure 2.1 Work flow of proposed system

12
2.3 System Requirement Specification
2.3.1 Functional requirements
The functional requirements of the system describe the necessary functions for which the system
is expected to fulfill. The system describes a single and well defines goal of digitalized system

for vehicle management system, and the steps involved to reach this goal. A function is
described as a set of inputs, the behavior and output. The requirements specified are helpful to
clearly understand the scope and the objective of the system, and consequently this will be
helpful for designing the system effectively. The proposed system meets the following
functionalities.

The system shall allow:

 Account management:
 Create account
 Update account
 Activate/Deactivate account
 Registration
 Register vehicle
 View information
 View notification
 View maintenance request
 View registered vehicles
 Request service.
 Request maintenance.
 Request transport service.
 Approve request
 Send notification.
 Give exit permission
 Assign vehicle
 Generate report

13
 2.3.2. Non- functional requirements
Non-functional requirements that specify criteria’s that can be used to judge the technical
operation of a system, rather than specific characters. This should be opposing with that of
functional requirement that define specific behavior.
In General, non-functional requirement
 Security:
 Authentication and authorization: deal with identifying a user and what a
user is allowed to do respectively.
 Session: once the user’s logout from the system then the session do not enable
to return to the previous page
 The information provider by the user should be authentic which protect the
system from external attack and spamming.
 Performance:
 The response time for loading and processing a given task is very fast and triggered by
a single click.
 The system should provide the services in considerable time interval.
 Reliability:
 Increase reliability of the system by removing commonly made errors and
feeding correct inputs for processes.
 Provides to the user correct information.
 The system notifies users to correct the input data when they enter wrong
inputs.
 The system will be able to meet specified objectives as well as the expectations
of the customer.
 Usability: User interface will be user friendly, so user can familiar to the system and easy
to use.

 Availability
 The system would be available for access with connected network and power
source.
 Portability

14
  The system run on every version of web browser.

2.3.3 Paper Document in the Existing System

There are different forms and reports used by the DMU for various purposes.

Figure 2.2: gate pass paper document in the existing system

15
16
Figure 2.1: requisition form paper document in the existing system

2.3.4. Business rules

It is the collection of rules and regulations of the vehicle management system that tells the users
follow the activities.

 Rule 1: Users of the system must have proper user name and password in order to
login the system.
 Rule 2: The manager should check the fuel balance of the car while the car travelled.
 Rule 3: The manager must generate report in case of some conditions occur.
 Rule 4: Vehicles should be maintained when they are damaged or based on schedule
maintenance report.
 Rule 5: The manager should approve the request of the staff.
 Rule 6: manager assigned the vehicle and automatically sends notification for driver
and requester staff.

2.3.5. Change cases

 Likely future changes (update) to either the system, in terms of its capabilities and
properties are computable with the new version.
 The system will promote related international rules and regulations.
 Used to describe new potential requirement for a system or modification to
existing requirements.

17
2.4 System Requirement Analysis
2.4.1 Actors and use case identification

Each type of external entities with which the system must interact is represented by an actor.
Actors may represent roles played by human users, external hardware, or other subjects.

Action Admin Manager Driver Staff Mechanic

Request service 

Manage request 

Assign vehicle 

Manage account 

Register vehicle 

Submit comment  

View comment 

Check fuel balance 

Update account 

Maintenance request


View maintenance request 

Create user account 

View route of information: 

18
 Generate report 

Give exit permission 

Send report 

View response  

Table 2.1: Actors Table

2.5 Essential use-case diagram

2.5.1 Use case identification
Each Use Case describes the functionality to be built in the proposed system, which can include
another Use Case's functionality or extend another Use Case with its own behavior.
The most important and basic use cases of this system are the following: -

 Login
 Create account
 Delete account
 Update account
 Check fuel balance
 Register vehicle
 View vehicle Information
 Generate report
 View route information
 Submit comment
 View comment
 Logout

2.5.2. System Use Case

A use case describes a sequence of actions that provide a measurable value to an actor. In other
words, it shows a way in which a real world actor interacts with the system. In order to identify

19
use cases the team examined the needs of users, the main tasks of users, what users inform the
system and what the system informs users.

20
Figure 2.4 use case diagram

2.5.3 Essential use-case documentation

Use case description includes use case Id, use case name, particular actors, descriptions of the
use case, preconditions, basic course of action (actor action and system response), post
conditions, flow of event and whatever which is important in modeling the system.

21
Use case name Login

UC ID UC 1

Actor Administrator, Manager, driver, officer, passenger, staff and mechanics

Precondition They must have user account, user name and password.

Basic course of User action System response

action

1.Users click on login button 2. The system displays the

3.User insert user name and password login form.
4. User click login button. 5. System checks the
6. The system displays the appropriate user's name and
user page. password.
7. Use case ends.

Alternative course of 5.1. If username and password is not validating, the system display
action login fail and return to basic course action 3.

Post condition The authenticated user gets the appropriate page.

22
Table 2.2: Use case description of login

Use case name: Manage account

Use case ID: UC-ID2

Actor: Administrator

Description Administrator creates account for deriver, officer, mechanics, manager,

passenger
and staff.
Pre-condition: Administrator open and login into the system

User action System response

1. Administrator select
Basic course of action create user account link.
3. Administrator enters user 2.System display creates
information. Account form.
4. Administrator click submit 5. System checks user information.
button. 6. System creates successfully user account.
7. Use case end

Alternative 5.1. The system display error messages that the input values are incorrect
course of return to step 3.
Action
Post-condition: User account is created.

23
Table 2.3: Use case description of create account

Use Case Name View route information

Use case ID: UC-ID3

Actor Passenger
Description The User should view the route information.
Preconditions The user must be registered and login into the system

Post conditions The route information details must added into the database

User action System action

Normal Course 1. User opens the 2. The system wills the documented
of documented page information.
Events: of route 3. The system display route
information. information .
4. Use case end.

Alternative A4: if there is no route information the system displays "no route
Courses: information yet! ".

Table 2.4: Use case description of view route information

24
 Use case name: Update account

Use case ID: UC 4

Actor: Manager, driver, officer, staff, passenger , and mechanics

Description Manager, driver, officer, passenger and staff update their account

Pre-condition: User open and login into the system

User Action System Response

Basic course of action
1. User select update user account link.
3. The user inserts account type, user name2. System display updates
, password, and other user information. account form.
4.User click update button 5. System checks the new
6. The systems save the new account account information with the
to the existing database. existing account in database.
7.Use case end

Alternative course 5.1. The system display error messages that the input values are
of Action incorrect.
Post-condition: Account is updated

Table 2.5: Use case description of update account

25
 Use case name: Delete account

Use case ID: UC 5

Actor: Administrator

Description It allows the Administrator to delete user account from the system.
Pre-condition: The Administrator activates and login in to the system

User action System

Basic course of action response

1. Administrator Select deactivate

account link.
3. Administrator select users and 2.System displays
click deactivate button. Deactivate user
5. Administrator click yes button. account information.
4.System display
7.Use case end recommend page.
6.Systems deactivate
user account

Alternative course of 5.1. If Administrator click no button, then system back into basic
Action course of action 3.
Post-condition: Account is deactivated.

Table 2.6: Use case description of delete account

26
 Use case name: View Vehicles info.
Use case ID: UC 6
Actor: Manager
Description It allows manager to see the detail information of the vehicles.
Pre-condition: Manager open and login into the system.
User action System response
Basic course of action 1. Manager click on view 2. The system displays the detail
vehicle Information link. information of all registered
3. Use case end vehicle information.

Post-condition: The managers get vehicle information.

Table 2.7: Use case description of view vehicle information

Use case name: Register vehicle

Use case ID: UC 7
Actor: Manager
Description Allow the Manager to register vehicle.
Pre-condition: The manager activates the system and login to the system.
User action System response
Basic course of action 1. The manager Selects the register 2.The system will display
vehicle link. the vehicle registration form.
3. The manager fills the required fields. 5.The system checks the
4. Manager click submit button. input data.
7. Use case ends. 6.The system displays
the successful notification

Alternative course of 5.1. The system displays incorrect entered data message and return
Action to path 3
Post-condition: The vehicle is registered.

27
Table 2.8: Use case description of register vehicles

Use case name: Assign vehicle.

Use case ID: UC 8

Actor: Manager

Description It allows the manager to assign car for the requested service

Pre-condition: Manager open and login into the system

User Action system response

Basic course of action
1. The manager click assign 2. System display assign vehicle
vehicle link. page.
3.Manager selects and inserts 5. System validates selected and
required data inserted data.
4.The manager click assign 6. System assigned the vehicle
button. and automatically sends
notification for driver and
7. Use case ends. requester office.

Alternative course The

of system displays error message incorrect entered data message
Action and return to path 3
Post-condition: Vehicle will be assigned.

Table 2.9: Use case description of assign vehicle

28
 Use case name: Calculate fuel balance

Use case ID: UC 9

Actor: Manager

Description The fuel balance form takes and compares two reading of current
entry and the previous saved reading and produces fuel balance data.
Pre-condition: Manager must get information of vehicles status.
User action System response
Basic course of action 1. Manager enters username and 2. System checks the
password. validity of username and
4. Manager enters input value. password and then checks
6. The system save the difference for authentication and
and store the status of fuel. authorization.
7. Use case ends. 3.System display fuel
balance page
5. System checks the
validity the input data.
.

Alternative course of Action

2.1 If the user name and password is not validated and verified then
the system responds error message and return.
5.1 If the input is invalid or incorrect the system displays “invalid
input” message and return.
Post-condition: The fuel balance will be calculated.

Table 2.10: Use case description of check fuel balance

29
 Use case name: Request maintenance

Use case ID: UC 11

Actor: Driver

Description A driver formulate request to repair vehicle. The request describes briefly
the vehicle problem.
Pre-condition: Driver is registered.

User action System response

Basic course of action1The driver click request 2.System display vehicle
maintenance link. maintenance form
3. Driver enters information related 4.System checks validity of the
to the maintenance request for information
the vehicle. 5.System stores the data in the
database.
6.Use case ends.

Alternative course 4.1.

of If the data is invalid or incorrect the system displays “invalid input”
Action message.
Post-condition: Maintenance record will be created.

Table 2.11: Use case description of request maintenance

30
 Use case name: Request vehicle service
Use case ID: UC 12
Actor: Officer and staff
Description It allows the staff (i.e. employee under officer) request service to
officer and the officer directly request vehicle service to manager.
Pre-condition: Officer and staff enter user name and password.

1. Officer and staff enter user name and 2. System checks the
Basic course of action password. validity of username and
3. The officer and staff click the request password and then checks
service button. for authentication and
5.Officer and staff fill required vehicle authorization.
information on displayed form. 4. The system displays
6. User clicks send request button. request service form.
8. Use case ends. 7.System checks validity
of the information
8. The system displays
sent message
acknowledgement.

Alternative course of Action

2.1. If the user name and password is not validated and verified then
the system responds error message and return.
7.1 If the data is invalid or incorrect the system displays “invalid
input” message.
Post-condition: The request is sent.

Table 2.12: Use case description of request services

31
Use case name: Generate report
Use case ID: UC 13
Actor: Manager
Description It allows administrator and manager generating report for the tasks
performed and if there is any difficult problem.
Pre-condition: The admin and manager open the system and login to the system
User action System response
1. The user must log to his/her 3. The system displays the
Basic course of action page options (criteria).
2. The user select generate 5. System check selected
report link. criteria by the user.
4. The user selects the criteria 6. The system displays the
from the given options and clicks information to the user.
on Display button.
7. the user can print it out.
8. Use case ends.
Alternative course5.1.
of The system displays error message as invalid selection.
Action
Post-condition: The report will be generated.

32
Table 2.13: Use case description of generate report

Use case name: View maintenance request

Use case ID: UC 14

Actor: Mechanic

Description This use case describes viewing maintenance request to repair the
vehicle.
Pre-condition: The mechanics open the system and login to the system

User action System response

1. User enters username and 2. System checks the
Basic course of action
password. validity and then
4. Mechanic click approve button. authentication and
6.Users click ok button authorization of username
and password.

33
 3. System display viewing
8. Use case ends. maintenance request page.
5. System display
recommended page.
7. System automatically
updates the vehicle
condition and sends
response to driver.

Alternative course 2.1.

of If the username and password is not validated and verified, system
Action displays error message
7.1. If user click cancel button, the system not update and send .
Post-condition: The Vehicle’s problem will be viewed.

Table 2.14: Use case description of view maintenance request

Use case name: Submit Comment

Use case ID: UC 15
Actor: Driver
Description The driver and officer can give comment or feedback to manager.
Pre-condition: Driver and officer must have valid Email address.
User action System response
Basic course of action1. The driver and officer initiates to give
3. The system displays the form.
comment. 5. The system validates the entered
2. The driver and officer click on information.
the
comment link. 6. The system display as your

34
 4. The driver and officer insert all comments
the has been been sent.
required fields.
7. Use case ends.

Alternative course 5.1.

of The system display error message and give a chance to retype.
Action
Post-condition: The driver and officer sends comment to the manager.

Table 2.15: Use case description of submit comments

Use case name: View Comment

Use case ID: UC 16
Actor: Manager
Description It allows manager to see the comments that are submitted from the driver.
Pre-condition: Manager must have a full privilege to read the comments.
User action System response
Basic course of action 1. User log to his/her page. 3. The system reorders the
2. User clicks on view comment link. comments according to the time of
4. User starts to view the comments. delivery.
5.Use case ends

Post-condition: The managers view the submitted comments.

Table 2.16: Use case description of view comments

35
 Use case name: Logout
Use case ID: UC 17
Actor: Admin, manger, driver, mechanic, passenger, officer and staff

Description The user logouts when he/she wants to

back home page or exit from the system
Pre-condition: Users finish their activities.
User action System response
Basic course of action 1. User clicks the log out 2.The system
button responds to the
4.Use case ends requested action.
3.System returns
the users to the
login page.
Post condition User logs out or sign out.

Table 2.17: Use case description of logout

2.6 Sequence Diagram

A sequence diagram shows object interactions arranged in time sequence. It is dynamic model of
use cases, showing the interaction among classes during a specified time period. A sequence
modeling in our system is used to formalize the behavior of the system and to visualize the
communication among objects. It helped us to identify additional objects and participate in the
use case. This phase of the document ties uses cases with objects and shows the behavior of a use
case is distributed among its participating objects.

36
Figure 2.5: Sequence diagram for create account

37
Figure 2.6: Sequence diagram for login

38
Figure 2.7: Sequence diagram for register vehicle

39
Figure 2.8: Sequence diagram for view vehicle information

40
Figure 2.9 Sequence diagram for logout

41
2.7 Activity Diagram

Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is basically a flow chart to represent the flow form one activity to
another activity. The activity can be described as an operation of the system. So, the control flow
is drawn from one operation to another. This flow can be sequential, branched or concurrent.
Activity diagrams deals with all type of flow control by using different elements like fork, join
etc.

The purposes of activity diagram can be described as:

 Draw the activity flow of a system.

 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.

Figure 2.10: Activity diagram for Login

42
Figure 2.11: Activity diagram for create account

43
Figure 2.12: Activity diagram for register vehicle

44
CHAPTER THREE
3. System Design
3.1. Design of class diagram
The class diagram is a static model. It represents the static view of an application. Class diagram
is not only used for visualizing, describing and documenting different aspects of a system but
also for constructing executable code of the software application. The class diagram shows a
collection of classes, interfaces, associations, collaborations and constraints.

The class diagram is the main building block of object oriented modeling. It shows the static
structure of the system in terms of classes and objects, their internal structure, and the
relationships in which they participate. Classes are abstractions that specify the attributes and
behavior of a set of objects. Objects are entities that encapsulate state and behavior. It also used
for both for general conceptual modeling of the systematic of the application, and for detailed
modeling translating the models into programming code. Class diagram represents a detailed
view of a single use case, shows the classes that participate in the use case, and documents the
relationship among the classes.
In the diagram, classes are represented with boxes which contain three parts:

 The top part contains the name of the class. It is printed in bold and centered.
 The middle part contains the attributes of the class. They are left-aligned.
 The bottom part contains the methods the class can execute. They are also left-aligned

The below figure shows the class diagram of the system:

45
Figure 3.1 Class diagram

46
 Attribute Purpose Type
User-id To identify the user Varchar (20)
Full Represents the name of the Varchar (15)
Name user
Starts Represent where the vehicle Varchar (15)
departure
Arrival Represents the destination Varchar (15)
place of the vehicles
Times Represents when it reaches Varchar (15)
from starts to arrival
Reason It describes for what purpose Varchar (15)
it goes

Table 3.1: Description of Assign vehicle class

Method Purpose

assign vehicle () Used to assign vehicle

send notification () Used to send notification for users

Table 3.2: table of Assign vehicle method

Attribute Purpose Type

Name Represent lame of the user Varchar (45)
email Represent the address of the user Varchar (25)
message Represent the idea of the sender Varchar (250)
Date Describes the date Varchar (45)

Table 3.3: description of comment class

47
 Method Purpose

submit comment () Used to send comment

view comment () To view comment

Table 3.4: description of comment method

Attribute Purpose Type

model Used to describe the model of the car Varchar (20)
Plate no Used to identify the car from the other car Varchar (30)
Owner Used to owner of the car varchar (18)
Capacity Used to describe the speed of car varchar (23)
Production date Used to when it is made varchar (30)
insurance Used to help the owner of car during emergency varchar (30)

Table 3.5: description of vehicle registration class

Method Purpose
register car () Used to register car
View vehicle info () Used to view vehicle info

Table 3.6: vehicle registration method

Attribute Purpose type

Name Describes the driver's name Varchar (30)
User-id Used to identify the driver Varchar (15)
Sex Tells the gender of the driver Varchar (8)
Phone no Used to know the phone no Varchar (20)
Username Identify the username of the driver Varchar (30)

Password Used to login and access the system Varchar (80)

Table 3.7: driver class

48
 Method Purpose
submit comment () Used to send comment
send report () Used to send report

Maintenance request() Used to ask maintenance request while

vehicle damaged

Emergencyreport() Used to send emergency conditions

Table 3.8: driver method

Attribute Purpose Type

Full name Describes the sender name Varchar (30)
Plate no which identifies where the vehicle varchar (30)
was registered

Date This identifies when the report sent. Varchar (45)

Table 3.9: Send report class

Methods Purpose

Update User status Used to update the user status

Update vehicle status Used to update the vehicle status

Table 3.10: Send report method

49
3.2 User Interface Design

Figure 3.2 Home page

50
Figure 3.2login page

CHAPTER FOUR
4. Implementation
4.1 Programing Language Used

 We use MYSQL database for storage of data.

 We used php for communication with the server

4.2 Algorithm Used for Log In

Login (Username, password): - that pass/checks three arguments for login function.
 If length of username and password==0: - Check that Zero length is not allowed. Display
error message “username and password cannot be empty”. Stay in the same page and the

51
 actor fills the form after he or she knows the field is required. The system retrieves
username and password which the actor submits.
 If username! =username or password! =password or status! =active: - Authentications for
the right actor. Display error message “Invalid username or password or your account is
deactivated”.
 If his/her account detail is correct access the required page.

4.3 Sample Codes

<?php
/* Attempt MySQL server connection. Assuming you are running MySQL
server with default setting (user 'root' with no password) */
$conn = mysqli_connect("localhost", "root", "");

// Check connection
if($conn === false){
die("ERROR: Could not connect. " . mysqli_connect_error());
}
echo "Connect Successfully " ;
?>

Robel, [7/26/2024 8:29 PM]

<?php
// Database connection parameters
$servername = "localhost";
$username = "root"; // default username for WAMP
$password = ""; // default password for WAMP
$dbname = "project";

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);

52
// Check connection
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}

// SQL to create table

$sql = "CREATE TABLE IF NOT EXISTS users (
id INT AUTO_INCREMENT PRIMARY KEY,
email VARCHAR(255) NOT NULL,
username VARCHAR(255) NOT NULL,
password VARCHAR(255) NOT NULL,
role VARCHAR(50) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)";

// Execute query
if ($conn->query($sql) === TRUE) {
echo "Table 'users' created successfully";
} else {
echo "Error creating table: " . $conn->error;
}

// Close connection
$conn->close();
?>

Robel, [7/26/2024 8:29 PM]

<?php
/* Attempt MySQL server connection. Assuming you are running MySQL
server with default setting (user 'root' with no password) */

53
$conn = mysqli_connect("localhost", "root", "");

// Check connection
if($conn === false){
die("ERROR: Could not connect. " . mysqli_connect_error());
}
echo "Connect Successfully " ;
//create database
$db="create database project";
if(mysqli_query($conn,$db))
{
echo "database created Successfully";
}
else
{
echo "canot create database $db".mysqli_error();
}
?>

Robel, [7/26/2024 8:29 PM]

<?php
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

// Database connection parameters

$servername = "localhost";
$username = "root"; // default username for WAMP
$password = ""; // default password for WAMP
$dbname = "project";

54
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);

// Check connection
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}

// Check if the form is submitted

if ($_SERVER["REQUEST_METHOD"] == "POST") {
// Get the form data
$email = $_POST['email'];
$username = $_POST['username'];
$password = $_POST['password'];

// Prepare and bind

$sql = "SELECT * FROM users WHERE email = ? AND username = ?";
$stmt = $conn->prepare($sql);
$stmt->bind_param("ss", $email, $username);

if ($stmt->execute()) {
$result = $stmt->get_result();

if ($result->num_rows > 0) {
$user = $result->fetch_assoc();

// Verify the password

if (password_verify($password, $user['password'])) {
// Redirect based on user role
switch ($user['role']) {
case 'mechanic':

55
 header("Location: mechanicalside.html");
break;
case 'manager':
header("Location: managerside.html");
break;
case 'driver':
header("Location: driverside.html");
break;
default:
// Redirect to a default page if role is not recognized
header("Location: default.html");
break;
}
} else {
echo "Invalid password.";
}
} else {
echo "No user found with the given email and username.";
}
} else {
echo "Error: " . $stmt->error;
}

$stmt->close();
}

$conn->close();
?>

Robel, [7/26/2024 8:29 PM]

<?php

56
// Database connection parameters
$servername = "localhost";
$username = "root"; // default username for WAMP
$password = ""; // default password for WAMP
$dbname = "project";

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);

// Check connection
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}

// Check if the form is submitted

if ($_SERVER["REQUEST_METHOD"] == "POST") {
// Get the form data
$email = $_POST['email'];
$username = $_POST['username'];
$password = password_hash($_POST['password'], PASSWORD_DEFAULT); // Hash the
password
$role = $_POST['role'];

// Insert the data into the database

$sql = "INSERT INTO users (email, username, password, role) VALUES (?, ?, ?, ?)";
$stmt = $conn->prepare($sql);
$stmt->bind_param("ssss", $email, $username, $password, $role);

if ($stmt->execute()) {
// Redirect based on user role
switch ($role) {

57
 case 'mechanic':
header("Location: mechanicalside.html");
break;
case 'manager':
header("Location: managerside.html");
break;
case 'driver':
header("Location: driverside.html");
break;
default:
// Redirect to a default page if role is not recognized
header("Location: default.html");
break;
}
} else {
echo "Error: " . $sql . "<br>" . $conn->error;
}

$stmt->close();
}

$conn->close();
?>

58
CHAPTER FIVE
5. Testing and Deployment
Testing is a trial experience in which the deliverables of the project are checked with acceptable
Standards in the project. We used unit testing, system testing to test the correctness of each
Module and the compiled program.
Tested Form Test Case Expected Result
Display a message when user
validate user name and
didn’t fill user name or password
Login Form password entry as an input
and also when there is user name
from each end users
or password error.
Display a message when user left
some text fields, radio buttons,
controlling the proper combo boxes or date and time
All other forms
insertion of data unfilled and
insert improper data in to the form
try to save.

59
 Table 5.1 Unit testing.

 Integrated testing: - all the modules will be combined 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 recombined.

Tested Form Test Case Expected Result

Check the correctness of the
Display administrator or
Login Form form to be displayed after
system members menu
login is succeeded
check proper display of Display the selected form
Administrator menu selected options to be from the administrator form
accessed as menu
check whether the report The selected report will be
Report from
will be generated or not displayed
check the navigation The form required Will be
All forms
functionality displayed

Table 5.2. Integrated testing

 System testing: - the team member to performs over all functional testing by
checking whether it meets the required target or not. Here the system is partially
functional and reached its requirement.

Tested from Test case Expected result Actual result

To validate the proper ser will be authenticated
functionality of login To authenticate and if user is authorized
Login form
by inserting username user enter to the system else
and password confirm invalidity
If the requested record exist
To validate the
display the result else if it
Search from functionality Search result
doesn’t exist display the
of search form
message about the status
Report from To validate the To generate generate the requested

60
 report if the request is valid,
functionality if request is invalid display
report
of report form message box that describes
the invalidity
To provide
To validate the The form is presented and
the function
All forms functionality the required function can
required by the
of each form operated using the form
form
Table 5.3 System testing

5.1 Deployment Diagram

Deployment diagram is used to show the hard ware of the system, the software that is installed in
the hard ware and also the middleware that used to connect the machines to one and another. It
also shows how the software and the hard ware component work together.

61
Figure 5.1 Deployment diagram

62
CHAPTER SIX
6. Conclusion and Recommendations
6.1 Conclusion
As the scope of this project described we developed the vehicle management system for RESCO
by making it more reliable and efficient. The system would register vehicles and perform
additional task that would be performed by the system.
So, the system would: -
 Minimize the time required to perform task
 Minimize the work load of employees
 Increase customer satisfaction
This document use the object oriented technology called UML (unified modeling language) that
enable the user to understand the software easily.
We finally concluded that this vehicle management system would be benefited by the system
developed, and accept it cheerfully. During working on this project, we members of the team had
learned a lot.

6.2 Recommendation
The system that we have developed involves online based vehicle management system for
RESCO. We recommend the following features need to be included in any further revision and
extension attempt.
 May used the android or mobile based application.
 Use uninterruptible power supply (UPS) if electric power is not available.
 Integrate with the traffics system.
 Adding the chatting system.
 Include GPS.
 They done all system in organization are automated
 Update this system to android based system or integrate with android and PHP.
Therefore, others who are interested to develop a new system on vehicle management system for
bus station or other related systems can get some initial idea about the system. By focusing on
the limitation and functional areas of the system they can also develop a better vehicle
management system that automates all files managed in vehicles management office.

63
References
[1]

Jeffery A.Hoffer, Joey F.George. Modern systems analysis and design. (2005).
[2] Jeffery L.Whitten, Lonnie. Systems analysis and design methods (2004 G.C).

[3] Bahrami, Ali. Object oriented systems development . (1999 G.C).

[4] Object Oriented and the UML.2nd rev. Ed England: The Cambridge University Press.

[5] Bahrami, Ali. Object oriented systems development . (1999G.C).

[6] A. Dennis, System Analysis And Design, Don Fowley, (2012G.C).

[7] [Online]. Available: http://www.google.com

[8] [Online]. Available: www.umanitoba.ca/afs/MRAC/feasibility.

[9] [Online]. Available: https://www.uml-diagrams.org/. (Accessed 21, 2019).

64
Submitted by
Student Signature Date
1.KIDANEMARIYAM FRESBHAT__________________________________
2.ROBEL YISEHAK______________________________________________
3.EYASU ABEBE_________________________________________________
4.KALEAB GETNET_____________________________________________
5. HAYMANOT TILAHUN_________________________________________

ETHIOPIA
DATE OF SUBMISSION 21/11/2016 E.C

65