Automated Ambulance MS

AUTOMATED AMBULANCE MANAGEMENT SYSTEM 2021
JIMMA UNIVERSITY
INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS
PROGRAM OF INFORMATION TECHNOLOGY
AUTOMATED AMBULANCE MANAGEMENT SYSTEM
Group Members
Name ID Number
1. Faysel Muketar RU2553/09
2. Gutu Workeneh RU4317/09
3. Naol Geresu RU3800/09
4. Yohannes Beyene RU1115/09
Advisors
Name Signature
1. Dessalew Yohannes
2. Eskedar Ayenew
JIMMA, ETHIOPIA
IT, Jimma University Page i
This is to certify that the senior project titled “Automated Ambulance Management System”
Submitted by
Full name ID
1. Faysel Muketar…………………………….RU2553/09
2. Gutu Workeneh…………….………………RU4317/09
3. Naol Geresu ………………………….........RU3800/09
4. Yohannes Beyene…………………………..RU1115/09
To the Faculty of Computing and Informatics, Jimma Institute of technology for the partial
fulfillment of the requirement of the Degree of Bachelor Science in Information Technology, is a
record of the project done by them under my supervision. The contents of this document in full,
or in parts, have not been submitted to any other institute or university for the award of any
degree or diploma.
No. Advisor name Signature

1 Dessalew Yohannes __________
2 Eskedar Ayenew __________
Date: 21, May 2021
IT, Jimma University Page ii

Jimma University
Acknowledgement
First of all we would like to thank GOD keeping us healthy. Lots of problems have overcome
with the assistance of GOD. Without his will nothing could be done. We have taken efforts in
this project. And also thank our Advisor’s Mr. Dessalew Yohannes and Ms. Eskedar Ayenew for
all their support with this project. We have learnt a lot from them, how to work hard and getting
right results. They always has time for our questions and their comments on our thesis have been
valuable. We are also thankful to our project coordinator Mr. Zerihun Olana. In addition to this
we wish to thank our friends for supporting us in many ways. Last but not least, we are deeply
grateful to our family supported in many ways. Lastly, our thanks‟ and appreciation also go to
Department of Computer Science and Information Technology teachers in developing the project
and people who have willingly helped us out with their talents.
IT, Jimma University Page iii

ABSTRACT
Automated system is a combination of both software and hardware which is designed and
programmed to work automatically without the need of any human operator to provide inputs
and instructions for each operation. We have developed this application to address the difficulties
that of patients are facing, when a patient is trying to get an immediate medical attention and if
they need an ambulance to reach the nearby hospital by simplifying the ambulance calling
system only with one button click. Our system will be developed in both Web and Mobile
Application. The web will be controlled by users of the system like Admin, Doctors and soon.
But the Mobile Application is intended for the patients. The user can access the application and
call for an ambulance by simply touching a button, the rest of the work is done by the system
automatically. The system will take location of the user and finds the nearby ambulance and
notifies the ambulance driver. The system also calculates the distance and provides the driver
with the shortest direction to the patient based on the information’s gathered from the user. This
application will reduce the difficulties of patients getting ambulance service immediately.
IT, Jimma University Page iv

Contents
CHAPTER – ONE ..................................................................................................................................... viii
1.1. Introduction ....................................................................................................................................... 1
1.2. Background study ............................................................................................................................. 1
1.3. Problem Statement ............................................................................................................................ 2
1.4. Methodology ..................................................................................................................................... 3
1.4.1. Requirement collection Method ................................................................................................ 3
1.4.2. Requirement Modeling ............................................................................................................. 3
1.4.3. Tools ......................................................................................................................................... 4
1.4.3.1. Hardware Tools ................................................................................................................. 4
1.4.3.2. Software Tools .................................................................................................................. 5
1.5. Feasibility Study ............................................................................................................................... 5
1.5.1. Technical Feasibility ................................................................................................................. 5
1.5.2. Economic Feasibility................................................................................................................. 6
1.5.3. Operational Feasibility .............................................................................................................. 6
1.5.4. Time Feasibility ........................................................................................................................ 6
1.6. Objectives ......................................................................................................................................... 7
1.6.1. General Objective ..................................................................................................................... 7
1.6.2. Specific Objective ..................................................................................................................... 7
1.7. Limitation and Scope ........................................................................................................................ 7
1.7.1. Scope ......................................................................................................................................... 7
1.7.2. Limitation .................................................................................................................................. 7
1.8. Significance of the project ................................................................................................................ 8
1.9. Organization of the document ........................................................................................................... 8
CHAPTER – TWO ....................................................................................................................................... 9
2. ANALYSIS ........................................................................................................................................... 9
2.1. Existing system ............................................................................................................................. 9
2.1.1. Existing system description .................................................................................................. 9
2.1.2. Business rule of Existing system .......................................................................................... 9
2.2. Proposed system............................................................................................................................ 9
2.2.1. Functional Requirement ...................................................................................................... 10
2.2.2. Non-functional Requirement............................................................................................... 10
IT, Jimma University Page v

2.3. Use case Diagram ....................................................................................................................... 11

2.3.1. Use case description for Registration .................................................................................. 13
2.3.2. Use case description for Login............................................................................................ 14
2.3.3. Use case description for Add new Hospital ........................................................................ 15
2.3.4. Use case description for Add new Ambulance ................................................................... 16
2.3.5. Use case description for View status .................................................................................. 17
2.3.6. Use case description for Server response ............................................................................ 18
2.3.7. Use case description for Make request................................................................................ 19
2.3.8. Use case description for Provide Google map .................................................................... 20
2.3.9. Use case description for Notify Ambulance driver ............................................................. 21
2.4. Sequence diagram ....................................................................................................................... 22
2.4.1. Sequence diagram for registration ...................................................................................... 22
2.4.2. Sequence diagram for Login ............................................................................................... 23
2.4.3. Sequence diagram for Add new Hospital............................................................................ 24
2.4.4. Sequence diagram for Add new Ambulance ....................................................................... 25
2.4.5. Sequence diagram for view status ....................................................................................... 26
2.5. Activity diagram ......................................................................................................................... 27
2.5.1. Activity diagram for apply registration ............................................................................... 27
2.5.2. Activity diagram for Login ................................................................................................. 28
2.5.3. Activity diagram for Add new hospital............................................................................... 29
2.5.4. Activity diagram for Add new ambulance .......................................................................... 30
2.5.5. Activity diagram for view status ......................................................................................... 31
2.6. Class diagram .............................................................................................................................. 32
2.7. Interface Prototyping .................................................................................................................. 33
2.7.1. Android application............................................................................................................. 33
2.7.2. Website application ............................................................................................................. 33
CHAPTER – THREE ................................................................................................................................. 34
3. Design ................................................................................................................................................. 34
3.1. Purpose and goals of design ........................................................................................................ 34
3.2. Current system Architecture ....................................................................................................... 34
3.3. Proposed system Architecture ..................................................................................................... 35
3.4. Subsystem decomposition ........................................................................................................... 37
IT, Jimma University Page vi

3.5. Component diagram .................................................................................................................... 38

3.6. Deployment diagram ................................................................................................................... 39
3.7. Persistent Data Modeling ............................................................................................................ 40
3.8. Access control and Security ........................................................................................................ 41
IT, Jimma University Page vii

List of Figures
Figure 1 Use case diagram for Automated Ambulance Management System ............................................ 12
Figure 2 Sequence diagram for Registration............................................................................................... 22
Figure 3 Sequence diagram for Login......................................................................................................... 23
Figure 4 Sequence diagram for Add new hospital ...................................................................................... 24
Figure 5 Sequence diagram for Add new ambulance ................................................................................. 25
Figure 6 Sequence diagram for View status ............................................................................................... 26
Figure 7 Activity diagram for Registration ................................................................................................. 27
Figure 8 Activity diagram for Login ........................................................................................................... 28
Figure 9 Activity diagram for Add new hospital ........................................................................................ 29
Figure 10 Activity diagram for Add new ambulance.................................................................................. 30
Figure 11 Activity diagram for View status................................................................................................ 31
Figure 12 Class diagram for Automated Ambulance Management System ............................................... 32
Figure 13 Android application interface prototyping.................................................................................. 33
Figure 14 Website application interface prototyping .................................................................................. 33
Figure 15 software architecture of automated ambulance management system ......................................... 36
Figure 16 subsystem decomposition automated ambulance management system ...................................... 37
Figure 17 component diagram of automated ambulance management system ........................................... 38
Figure 18 deployment diagram of automated ambulance management system.......................................... 39
Figure 19 Persistent Modeling of automated ambulance management system .......................................... 40
IT, Jimma University Page viii

List of Tables
Table 1 Use case description for Registration ............................................................................................ 13
Table 2 Use case description for Login ...................................................................................................... 14
Table 3 Use case description for Add new Hospital ................................................................................... 15
Table 4 Use case description for Add new Ambulance .............................................................................. 16
Table 5 Use case description for View status ............................................................................................. 17
Table 6 Use case description for Server Response ..................................................................................... 18
Table 7 Use case description for Make request .......................................................................................... 19
Table 8 Use case description for Provide Google map ............................................................................... 20
Table 9 Use case description for Provide Google map ............................................................................... 21
Table 10 Access control and security for Automated ambulance management system ............................. 41
IT, Jimma University Page ix

CHAPTER – ONE
1.1. Introduction
We all know the importance of timely medical attention received at critical medical mishaps can
create a much better chance of saving lives, “every second counts” in such situations. Ambulance
are the first responders in emergency medical situations, especially in these trying time and
reflect the importance of timely transporting of patients to the nearest hospital/ care center.
With the advancement in technology and its easy availability, can bolster crisis responders to
give a productive reaction in less time to accomplish quick transportation of patients to the
suitable nearest hospital is imperative goal of effective administration of ambulance service.
Need for advance automated ambulance management system is never been this important and
critical as the world is facing the deadly COVID 19 pandemic which results in thousands of
death across the world due to disease contagious nature which makes efficient transportation of
patients all more critical to place affected patients to transport the nearest hospital / safe
quarantined center.
The importance of having automated ambulance management system applicable to densely

populated countries like us as streets are regularly congested and lack of planned cities
architecture which doubles the difficulty to navigate and mitigating the chances of saving lives.
Various researches demonstrate that emergency vehicle reaction time and patient mortality is
deeply correlated.
1.2. Background study

Jimma Hospital is one of the oldest public hospitals in the country. It was established in 1930
E.C by Italian invaders. Currently it is the only teaching and referral hospital in the southwestern
part of the country, providing services for approximately 15,000 inpatient, 160,000 outpatient
attendants, 11,000 emergency cases and 4500 deliveries in a year coming to the hospital from
the catchment population of about 15 million people. Cognizant of the fast growing service and
IT, Jimma University Page 1

teaching role of the hospital, the federal government considered construction of a new and level-
best 600 bedded hospital which’ will be functional soon.
It also will provide free ambulance service and pre-hospital care to the residents of the city in
Ethiopia’s Oromia region. As a regional ambulance service, its duties include attending primary
emergencies, medical response and transportation, and transfer of critically ill patients. A
separate function will be raising awareness among the community including providing first aid
training for community-based first responders.
Ambulance service helps many people for serious or life-threatening conditions. And also
provide a range of other urgent and planned health care and transport services. Ambulance group
can include a range medical staff, such as emergency care particular work and medical work.
Ambulance is equipped with a variety of emergency care equipment, such as heart defibrillators,
oxygen, intravenous drips, spinal traction splints, fire accident, car emergency and also
difference incidents. The Patient can call to the ambulance manager, if they need ambulance
services. However, ambulance manager inform to ambulance driver and sends ambulance to
incident sit.
Our project is to develop a new automated system to facilitate user request to get ambulance
service. It gives a decision automatically and makes easier way for the patient to use ambulance
services in Jimma Hospital. In this system main issues are to find availability of ambulances in
hospital, identify the location of incident places and send ambulance to the incident location
automatically. The system also used to store the patient and ambulance driver information in the
database and generates report.
1.3. Problem Statement

Emergency call received by operators takes lot of time and human efforts to accumulate all the
required information regarding the patient and location details. As the number of emergency
cases increased, handling all the information delays the reaction time of ambulance to reach to
the location.

Emergency caller usually in a state of panic and the accuracy of location is not conveyed to
operator, or caller provides location information by using landmark which can be confusing for
operator to understand. Without accurate location information, ambulance driver face difficulty
to reach the given location.
Number of requests received by emergency operator at a time could be so large that it becomes
difficult for operator to respond all of them, which results in delay in dispatching emergency
services.
1.4. Methodology
1.4.1. Requirement collection Method

There are different methods to collect information. From those the project uses the following
tools and methods to collect data from the organization.
✓ Observation (Documentation & material): use this method to get the right information
about the organization and also to understand how the existing system works.
✓ Interview: This methodology encapsulates two types of methods. These methods are
closed and open interview. So the team has selected an open interview for interviewing
the manager and employees for recognizing the existing working procedure of the
organization. So the team was able be to gather more information about the organization
and requirements.
✓ Questionnaire: - We will prepare lists of questions in hard copy about the overall the
system information such as background of the organization, the structure of the
organization, the overall activities of the organization and other fundamental questions
related to the organization.
1.4.2. Requirement Modeling

The approach we will take in designing the proposed system is the Rational Unified Process
(RUP - is an iterative software development process). The RUP methodology is based on the fact
that the system represents an organized way of gathering business requirements and building the
goal of the project. This was employed, because it is an object-oriented program development

methodology and also a framework for developing software systems. It also clearly outlines the
different roles of the individuals involved in the project, such as the project manager, business
analyst and developers. Some characteristics of Rational Unified Process include:
I. Developing iteratively: This involves developing software in repeated cycles. With each
cycle, additional features are designed and developed in the system until the system is
fully functional and ready for deployment to the customer.
II. Managing requirements: This involves explicit documentation of the user’s
requirements and keeping track of changes with respect to the requirement. It also
analyses and the impact those changes will make on the system before considering them.
III. Using component-based architectures: This involves structuring the system
architecture into components.
IV. Modeling software visually: Using graphical UML to present the software’s dynamic
and static view.
V. Quality verification: It ensures that software meets the organizational quality standards.
VI. Control over changes: It gives room for changes in the software to be managed
efficiently using a change management system and configuration management
procedures and tools.
1.4.3. Tools
1.4.3.1. Hardware Tools

It’s any physical device used in or with a machine. There are different hardware tools are used to
develop our project.
➢ Computer - used to install software’s that are necessary for our work like MS word,
visual basic and to do other tasks related to our work.
➢ Printer – for printing documentation.
➢ Network - we used twisted pair cable to get the internet access which is used us to get
many information about our project
➢ Flash disk /CD – used for the movement data from one machine to another.

1.4.3.2. Software Tools

It’s a collection of code installed on to computer’s hard drive. We also used different software
tools are used to develop this project.
➢ MS word – used to write the proposal of our project.

➢ MS power point – use to present the document in abstract form. We use it to present our
presentation in short and brief way.
➢ E-Draw – for designing UML diagram, user interface associated with the project.
➢ Microsoft SQL server – for database purpose as it is most powerful database
management system database system.
➢ Adobe Photoshop – used to edit images used in our project.
➢ Flutter - will be used to develop the UI android application
➢ Dart – the programming language we used to develop our Android Application
➢ Php – the programming language we used to develop our Web Application
➢ Symfony – the Framework we used to develop our Web Application
1.5. Feasibility Study

four aspects of feasibility study need to be considered are: -
1.5.1. Technical Feasibility

The system is developed by Object Oriented System Development architecture and technique
and also contains web application. We tried to use any methodologies at hand and developed the
system with practice. The total aggregated effort now makes the system to be technically
feasible. Since our University provides sufficient computer hardware and software facilities with
skilled staff it was an easy attempt to make the system technical feasible without any extra
efforts on hardware and software part. Also the technical issue that are involved in the system
such as the normality and strength of the user mobile device from the hardware part, the software
should work properly in the proper inputs from both its user and the software point of view
should be considered to determine the feasibility. In simple terms long range portable mobile
device and fast and efficient server is required for the better use of the application.

1.5.2. Economic Feasibility

The proposed system is not fully economically feasible, since the system uses locations and
intended for smart phones and most of our country side peoples cannot afford the luxuries of
such device it is economically not feasible, but if the hospital and the kebele agree on buying a
smart phone and distribute it for this purpose then it becomes economically feasible and it also
save the users from extra charge of money for transportation. Here, in determining benefits, there
are two cases for benefit analysis such as Tangible and Intangible and in determining cost
analysis. The following are tangible and intangible benefits that we have identified in this
project.
✓ Reduction of error
✓ Increase speed of service
✓ Improvement in management planning
1.5.3. Operational Feasibility

Is the ability to utilize, support and perform the necessary tasks of a system or program. It
includes everyone who creates, operates or uses the system. To be operationally feasible, the
system must fulfill a need required by the business.
✓ Knowledge gain by project developer

✓ Decreasing the wastage of time and effort of an individual
✓ More timely, updated and accurate service
✓ Improved productivity
✓ Improving the moral of our team
✓ Faster decision making on the team member
✓ Facilitating information processing of our team
1.5.4. Time Feasibility

Time feasibility is the most important and superior things to be considered. The period of time
considered as a resource under user control and sufficient to accomplish some work and it is an
instance or single occasion for some work. This application provides much faster and easy way
of getting ambulance service. It saves both the patients and Facility members wastage of time.

1.6. Objectives
1.6.1. General Objective

The general objective of this project is digitalizing the ambulance management system.
1.6.2. Specific Objective

• The aim to design and develop this application is to produce an effective and efficient
ambulance system.
• Change the traditional way of calling an ambulance and waiting until it comes from
wherever they are.
• Reducing an error
• Providing a fast and easy way Ambulance service
• Providing reliable and accurate information’s of the patient
1.7. Limitation and Scope
1.7.1. Scope
• Our project covers from the calling of the ambulance by the patient up to transporting to
the nearby hospital.
• Also may include sending information from the patient and preparing a patient card
before the patient arrives
• It works on android phone with android version 5.0 and more
• The map works with available API given services
• The system map requires permission of Location
• It needs internet connection
1.7.2. Limitation
• It required a device (smartphone) which should have installed android operating system.
• Global positioning system (GPS) and cellular data required continuously.
• The android application cannot run without a virtual device like Blue stack.

1.8. Significance of the project

Our proposed system will come up with many advantages for the organization by solving the
problems of the organization that we expressed above in the statement of the problem. The
propose system satisfies:-
Organization by:-
➢ Reducing the time and effort taken

➢ Keeping information’s of the users
➢ Keep track of the ambulance and drivers status
➢ Retrieve information easily from the database
➢ Tracking of patients easily
Patients by:-
➢ Getting information easily

➢ Getting fast access
➢ Getting complain service
The project development team:-
➢ Since this project is thought to be our first on our study in this campus, it will play an
enormous role in increasing our level of knowledge towards developing software for
specific application. It helps us to learn cooperatively working with teammates.
➢ Also it credits us encouragements and motivations for developing other application
specific software for future.
1.9. Organization of the document

This document has three chapters including this chapter which gives highlight about the project
we are going to develop. The second chapter is the requirement analysis where user requirements
are structured and modeled; the third chapter is about the design of the system which describes
the design of the proposed system.

CHAPTER – TWO
2. ANALYSIS
2.1. Existing system
2.1.1. Existing system description

Emergency call received by operators takes lot of time and human efforts to accumulate all the
required information regarding the patient and location details. As the number of emergency
cases increased, handling all the information delays the reaction time of ambulance to reach to
the location. Emergency caller usually in a state of panic and the accuracy of location is not
conveyed to operator, or caller provides location information by using landmark which can be
confusing for operator to understand. Without accurate location information, ambulance driver
face difficulty to reach the given location. Sheer number of calls received by emergency operator
at a given time could be so large that it becomes difficult for operator to respond all of them,
which results in delay in dispatching emergency services.
2.1.2. Business rule of Existing system

When, someone face a problem/an emergency the person always calls using (6238). The
operators which are working for 24/7, then they receives the call and take important
information’s (like Full name, Location) and sends available ambulance to that specific location.
2.2. Proposed system

Automated ambulance dispatch from the nearest available hospital or ambulance provider to the
location which reduces the response time to reach the location. This can be achieved through
registration of hospitals and ambulance fleet owners designed to provide the services to help
manage in coordination.
Allocation of ambulances is controlled by admin/ fleet manager who has all the relevant
information regarding the availability of ambulance and manage the request accordingly.

Ambulance management system’s algorithm assess the location of patient and calculate the
nearest available ambulance to be dispatched with shortest path provided to ambulance driver
with precise location using GPS coordinate plotted on Google maps along with information of
traffic situation on the road.
All the patient information are recorded and shared with the nearest allocated hospital. Receiving
hospital is well informed about the patient and got them prepared before the arrival of patient
which saves valuable time results in better chance of saving lives.
2.2.1. Functional Requirement

Functional requirements show the operation and activities the system must be able to perform.
The functional requirements of this ambulance system are:-
➢ It allows the user to make a request using a single button

➢ It allows the system Admin to check and control over all ambulance activities
➢ It allows the system to take the coordinates(Latitude and Longitude) of the user and track
it to find the location once the user request and ambulance
➢ It allows the ambulance driver to confirm that it is deployed to its allocated location
➢ It allows the System Admin to add other Hospitals and ambulances and ambulances to
the system
➢ It allows the System Admin to confirm a new registered user
➢ It allows the system to update the ambulance database log once the user requests for the
database
➢ It allows the ambulance driver to use Google maps to know the precise location of the
user
2.2.2. Non-functional Requirement

The non-functional requirements are constraints upon the system behavior or quality attributes of
as system. Consequently, the non-functional requirements this ambulance system is-
➢ Should be developed to be simple and efficient for the end users and also should be easy
to understand
➢ Shall be able to minimize the rate of errors generated by users

➢ Should perform calculations and provide feedback quickly

➢ Shall be compatible to most smartphones
➢ Should be able to upgrade without disturbance to the user
2.3. Use case Diagram

Use case diagram is a UML diagram that is used for describing user scenarios and capturing user
needs. It is used during the analysis phase to represent the external behaviors (actors, boundary
and use cases including the association in between them).
➢ Use cases are:

✓ UC-01 :- Registration
✓ UC-02 :- Login
✓ UC-03 :- Add new Hospitals
✓ UC-04 :- Add new Ambulances
✓ UC-05 :- View Status
✓ UC-06 :- Make Request
✓ UC-07 :- Provide Google map
✓ UC-08 :- Notify Ambulances driver
Actors are:
➢ System Administrator
➢ User
➢ Ambulance Driver

Figure 1 Use case diagram for Automated Ambulance Management System

2.3.1. Use case description for Registration

Use case name: Registration
ID: UC-01
Description: Be member of the system by registering to the

system
Actors: User
Pre-conditions: Have to fill necessary information’s like

personal information’s and provide a username
and password
Basic course of Action: 1. The user open the application
2. Click the register button
3. Fill in necessary information’s
4. Click the sign up button
5. The system validates and register the
user
Alternative course of action: 1.1.Unable to register
1.1.1. connection unavailable
1.1.2. form input not filled
1.1.3. username already existed
Post condition: The user can login and make requests
Table 1 Use case description for Registration

2.3.2. Use case description for Login

Use case name: Login
ID: UC-02
Description: Enter into the system by authenticating to the

system
Actors: User, System Administrator, Ambulance driver
Pre-conditions: Have to be a member, provide a valid

username and password
Basic course of Action: 1. The user open the application
2. Enter a valid username and password
3. Click the login button
4. The system checks for the username
and password
5. If, success then system login to the
system
6. Else provide with error message
Alternative course of action: 3.1.Unable to login
3.1.3. invalid username or password
Post condition: The user can make a request
Table 2 Use case description for Login

2.3.3. Use case description for Add new Hospital

Use case name: Add new Hospitals
ID: UC-03
Description: Adding new constructed hospitals around the

area to the system
Actors: System Administrator
Pre-conditions: Have to provide necessary information’s about

their Facilities, and had to be around that area
Basic course of Action: 1. The system Admin should login to the
system
2. The system Admin should fill all the
necessary information’s
3. Then admin submit the form
4. The system validates the form and
update the database
Alternative course of action: 3.1.Unable to Add
Post condition: The new added hospital will join the system
Table 3 Use case description for Add new Hospital

2.3.4. Use case description for Add new Ambulance

Use case name: Add new Ambulance
ID: UC-04
Description: Adding new coming Ambulance around the

area to the system
Pre-conditions: Have to provide necessary information’s about

their ambulance
Basic course of Action: 1. The system Admin should login to the
system
2. The system Admin should fill all the
necessary information’s
3. Then admin submits the form
4. The system validates the form and
update the database
Alternative course of action: 3.1.Unable to Add

Post condition: The new added Ambulance will join the
system
Table 4 Use case description for Add new Ambulance

2.3.5. Use case description for View status

Use case name: View status
ID: UC-05
Description: View which ambulance is in the line to be

deployed and nearest to the user, check nearest
Hospital to the user, which ambulance
deployed at what time
Pre-conditions: The ambulance and Hospital have to be

members, the user had to make a request
Basic course of Action: 1. The user make a request
2. The system respond to the request and
checks availability from the status
3. Then select the best option and send
notify the ambulance driver
4. Update the database
Alternative course of action: 3.2.Unable to view status
Post condition: The system address the user request with less
amount of time
Table 5 Use case description for View status

2.3.6. Use case description for Server response

Use case name: Server response
ID: UC-06
Description: The server respond to the user’s request and

make fast decision
Actors: System
Pre-conditions: The user had to make a request
Basic course of Action: 1. The user make a request

2. The system respond to the request and
checks availability from the status
3. The system get user Location
4. Provide Google map
5. Notify the Ambulance driver
Alternative course of action: 3.3.Unable to respond
amount of time
Table 6 Use case description for Server Response

2.3.7. Use case description for Make request

Use case name: Make request
ID: UC-07
Description: The user make a request when an emergency

happened
Actors: User
Pre-conditions: The user had to login to the system
Basic course of Action: 1. The user had to register to the system

2. The user login to the system
3. Then make a request
4. The system then respond and send back
request accepted
Alternative course of action: 3.1.Unable to make a request
3.1.2. Login to the system
amount of time
Table 7 Use case description for Make request

2.3.8. Use case description for Provide Google map

Use case name: Provide Google map
ID: UC-08
Description: The system provide the ambulance driver with

the Google map with direction
Actors: System, Ambulance driver
Pre-conditions: The system provides with the location of the

user
Basic course of Action: 1. The user login to the system
2. The user makes a request
3. When the user make a request the
system takes the location of the user
4. Then the system provides Google map
using Google API
5. And produce a direction for the
ambulance driver
Alternative course of action: 3.2.Unable to load the map
3.2.2. Location is not switched on
Post condition: The Google map produces a direction for the
ambulance driver
Table 8 Use case description for Provide Google map

2.3.9. Use case description for Notify Ambulance driver

Use case name: Notify Ambulance driver
ID: UC-09
Description: The system notifies the nearest and available

ambulance to respond to the user
Actors: System, Ambulance Driver
Pre-conditions: The ambulance driver had to login to the

system all the time
Basic course of Action: 1. The ambulance driver had to login to
the system
2. Wait a request from the user
3. The system notifies the driver
4. The driver respond to the request
5. The system provides Google map
Alternative course of action: 4.1.Unable to confirm the request
Post condition: The Google map produces a direction for the

ambulance driver
Table 9 Use case description for Provide Google map

2.4. Sequence diagram

A sequence diagram is an interaction diagram that shows how processes operate with one
another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram
shows object interactions arranged in time sequence. It depicts the objects and classes involved
in the scenario and the sequence of messages exchanged between the objects needed to carry out
the functionality of the scenario. Sequence diagrams are typically associated with use case
realization in the Logical View of the system under development. Sequence diagrams are called
event diagrams or event scenarios.
2.4.1. Sequence diagram for registration
Figure 2 Sequence diagram for Registration

2.4.2. Sequence diagram for Login
Figure 3 Sequence diagram for Login

2.4.3. Sequence diagram for Add new Hospital
Figure 4 Sequence diagram for Add new hospital

2.4.4. Sequence diagram for Add new Ambulance
Figure 5 Sequence diagram for Add new ambulance

2.4.5. Sequence diagram for view status
Figure 6 Sequence diagram for View status

2.5. Activity diagram

An activity diagram illustrates the dynamic nature of the system by modeling the flow of control
from activity to activity. An activity represents an operation on some class on the system that
results in change in state of the system. Typically, activity diagram are used to model workflow
or business process and internal operation.
2.5.1. Activity diagram for apply registration
Figure 7 Activity diagram for Registration

2.5.2. Activity diagram for Login
Figure 8 Activity diagram for Login

2.5.3. Activity diagram for Add new hospital
Figure 9 Activity diagram for Add new hospital

2.5.4. Activity diagram for Add new ambulance
Figure 10 Activity diagram for Add new ambulance

2.5.5. Activity diagram for view status
Figure 11 Activity diagram for View status

2.6. Class diagram

Class diagram provides an overview of the target system by describing the objects and classes
inside the system and the relationship between them. It represents a relevant concept from the
domain, a set of person, objects or ideas. We used class diagram to represent the structure of the
system.
The first for drawing class diagram is to identify classes. After those differentiating relationships,
associations, multiplicity, and class operations were the next step to proceed.
Figure 12 Class diagram for Automated Ambulance Management System

2.7. Interface Prototyping
2.7.1. Android application
Figure 13 Android application interface prototyping
2.7.2. Website application
Figure 14 Website application interface prototyping

CHAPTER – THREE
3. Design
3.1. Purpose and goals of design

Design goals are qualities that one system should focus on and are from non-functional
requirements or from the application domain.
Performance: This is the measure of the application’s operation under load. Criteria’s for
performance are the response-time, throughput, and space for information storage.
Availability: The system needs to be on work for 24 hours in a day and 7 days week.
Security: System provides security through authentication, authorization and data protection.
The authentication is by confirming the users. The authorization is by verifying the authenticated
user has permission to access a particular resource.
Reliability: The reliability criteria determine how much effort should be expanded in
minimizing the system crashes and their consequences.
End user: End user criteria’s are qualities that are desirable from user’s point of view like
usability, maintainability, and utility.
➢ Speeding up the response time when a user requests to get a service.

➢ Minimizing the time and effort consumed for the ambulance to respond
➢ Decrease the expense the user face when they need a transport
3.2. Current system Architecture

There is no specified architecture for the sector since data managed and handled mostly through
telephone number of the hospital.

3.3. Proposed system Architecture

The software system architecture is a high level structure of software system, the discipline of
creating such structures, and the documentation of these structures. There are many recognized
architectural patterns and styles. Among them are:-
➢ Client-server- The client-server model of computing is a distributed application

architecture that partition tasks and workloads between the provider of resource of
service, called servers and service requesters, called clients.
➢ Peer-to-peer- This architecture is a distributed application architecture that partitions
tasks and workloads between peers. Peers are equally privileged equipotent participants
in the application.
➢ Three-tier architecture - is an architecture in which the fundamental process logic, data
access, computer data storage and user interface is developed and maintained as
independent modules on separate platforms. For this application, we used the three-tier
architecture.
✓ The presentation layer (UI) occupies the top-level part and displays information
related to the service available on android application and some of Admin pages
on web application.
✓ The service/ application tier or business logic (BL) is the middle tier, which is
pull from the user interface. It performs controlling the application functionalities
by performing detailed processing.
✓ The data tier (DB) is a house for database servers where information is stored
and retrieved.

Figure 15 software architecture of automated ambulance management system

3.4. Subsystem decomposition

A subsystem is a collection of classes, operations, events and constraints that are interrelated to
provide a set of services to a system. These are a grouping of model elements that represents a
behavioral unit in a physical system. We used subsystem decomposition diagrams to express
how our system is decomposed to smaller parts or set of related operations that share a common
purpose. Subsystem decomposition results into a set of loosely dependent parts, which make up
of the system.
Figure 16 subsystem decomposition automated ambulance management system

3.5. Component diagram

Component diagram is used to model physical aspects of the system. These physical aspects are
the elements in the system like executable, libraries, document, files, forms, etc. which reside in
the nodes, so that we used component diagrams to visualize the organization and relationships
among components in our system.
Figure 17 component diagram of automated ambulance management system

3.6. Deployment diagram

Deployment diagram is a UML diagram that used for describing how the hardware components
are deployed. We used to visualize the topology of the physical components of our system where
the mentioned software component diagrams are deployed.
Figure 18 deployment diagram of automated ambulance management system

3.7. Persistent Data Modeling

We have used the entity relationship diagram to show the entities and their attributes in the
system. This helps us to generate the persistence modeling of tables.
Figure 19 Persistent Modeling of automated ambulance management system

3.8. Access control and Security

Access control and security refers access permission of each user to the different parts of the
system. In other word it specifies the privileges or authorities of actors over the system
functionalities and data. We have use username and password for authentication of different user
to login and use role to authorization purpose in order to restrict the access of each user access
after authentication.
Functionalities System Ambulance Driver User

Administrator
Register ✓ ✓ ✓
Login ✓ ✓ ✓
Add new Hospital ✓
Add new Ambulance ✓
View Status ✓
Make Request ✓
Confirm ✓
Google map ✓
Table 10 Access control and security for Automated ambulance management system

Automated Ambulance MS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Automated Ambulance MS

Uploaded by

Copyright:

Available Formats

AUTOMATED AMBULANCE MANAGEMENT SYSTEM 2021

AUTOMATED AMBULANCE MANAGEMENT SYSTEM

No. Advisor name Signature

Date: 21, May 2021

IT, Jimma University Page ii

IT, Jimma University Page iii

IT, Jimma University Page iv

IT, Jimma University Page v

2.3. Use case Diagram ....................................................................................................................... 11

IT, Jimma University Page vi

3.5. Component diagram .................................................................................................................... 38

IT, Jimma University Page vii

IT, Jimma University Page viii

IT, Jimma University Page ix

The importance of having automated ambulance management system applicable to densely

1.2. Background study

IT, Jimma University Page 1

1.3. Problem Statement

IT, Jimma University Page 2

1.4.1. Requirement collection Method

1.4.2. Requirement Modeling

IT, Jimma University Page 3

1.4.3.1. Hardware Tools

IT, Jimma University Page 4

1.4.3.2. Software Tools

➢ MS word – used to write the proposal of our project.

1.5. Feasibility Study

1.5.1. Technical Feasibility

IT, Jimma University Page 5

1.5.2. Economic Feasibility

1.5.3. Operational Feasibility

✓ Knowledge gain by project developer

1.5.4. Time Feasibility

IT, Jimma University Page 6

1.6.1. General Objective

1.6.2. Specific Objective

1.7. Limitation and Scope

IT, Jimma University Page 7

1.8. Significance of the project

➢ Reducing the time and effort taken

➢ Getting information easily

The project development team:-

1.9. Organization of the document

IT, Jimma University Page 8

2.1. Existing system

2.1.1. Existing system description

2.1.2. Business rule of Existing system

2.2. Proposed system

IT, Jimma University Page 9

2.2.1. Functional Requirement

➢ It allows the user to make a request using a single button

2.2.2. Non-functional Requirement

IT, Jimma University Page 10

➢ Should perform calculations and provide feedback quickly

2.3. Use case Diagram

➢ Use cases are:

IT, Jimma University Page 11

Figure 1 Use case diagram for Automated Ambulance Management System

IT, Jimma University Page 12

2.3.1. Use case description for Registration

Description: Be member of the system by registering to the

Pre-conditions: Have to fill necessary information’s like

Table 1 Use case description for Registration