AMBULANCE DISPATCH SYSTEM
PROJECT PHASE 2: DESIGN SPECIFICATION DOCUMENT
Honors Software Engineering
CS 3354.002
Dr. Lawrence Chung
14 March 2006
Ryan Kelly • rjk042000 @ utdallas.edu
Scott Moore • sdm035000 @ utdallas.edu
Jonathan Sanborn • jms039100 @ utdallas.edu
TABLE OF CONTENTS
PROJECT OVERVIEW 3
1. Overview 3
2. Data Flow Analysis 4
SYSTEM ARCHITECTURE 5
3. Architecture Style 5
4. Network Architecture 5
5. Component Analysis 6
COMPONENT DESIGN 7
6. City Simulation 7
7. Map Controller 8
8. Allocator 9
9. Exception Monitoring 10
10. Logging 10
11. Operator Terminal 11
12. Supervisor Terminal 14
DETAILED UML DIAGRAMS 16
13. City Simulation 16
14. Map Controller 18
15. Allocator 19
16. Exception Monitoring 20
17. Logging 21
18. Message 22
19. Dispatch Server 22
20. Full UML Diagram 23
2
PROJECT OVERVIEW
1. Overview
1a. Background
The Ambulance Dispatch Company (ADC) uses a manual process to dispatch ambulances. Operators receive
calls from patients, recording the necessary information on paper forms. Using a map on the wall, the
operators attempt to efficiently dispatch ambulances, as best they see fit.
New government regulations require that ambulances must be dispatched within three minutes of receiving a
call, and arrive on the scene within 14 minutes. ADC does not currently meet these requirements, and needs a
software system developed to streamline the ambulance dispatch process. Management at ADC also views this
as an opportunity to reduce costs.
1b. Project goals
The Ambulance Dispatch System is being developed to streamline the ambulance dispatch process for the
Ambulance Dispatch Company, allowing them to meet government speed of response standards. In addition,
the system will improve the reliability of the current system by reducing dispatches caused by multiple calls, and
by logging call information and dispatches.
The system shall allow the Ambulance Dispatch Company to meet government regulations, which specify that
from the time a call is received:
1) An ambulance must be dispatched within three minutes, and
2) An ambulance must arrive at the call location within fourteen minutes.
The system shall detect possible duplicate calls, alerting operators, who will determine whether the call should
be ignored. Ambulances should never arrive to find multiple crews dispatched, unless this was intended by the
operators.
The system shall log all call and dispatch information, allowing operators to manually dispatch calls in the event
of a system malfunction. In addition, these logs shall be evaluated to determine regulation compliance.
3
2. Data Flow Analysis
2a. Data Flow Diagram
4
2b. Data Flow Analysis
To divide the system into components along logical breaks, we analyzed the data flow of the desired system.
We developed the diagram by acting out the use cases defined in Project Phase 1: Requirements Specification.
We found that the processes and data stores could be encapsulated efficiently in seven modules: a city
simulation, a controller for the simulation, an ambulance allocator, a logger, an exception monitor, a operator
terminal, and a supervisor terminal. By separating these components, we can create a modular design with
relatively low coupling.
SYSTEM ARCHITECTURE
3. Architecture Style
3a. Layered Architecture
The system shall be implemented using a layered architecture. A layered architecture simplifies each component
of the system, allowing each component to focus on a single task. In addition to simplifying develop, this
allows the system to meet several non-functional requirements: reliability, robustness, scalability, and
maintainability.
3b. Model-Controller-View
More specifically, the Model-Controller-View design pattern will be implemented. MCV is appropriate because
the project can easily be decomposed into the three layers. The project centers on a representation of the city,
its ambulances, and incidents. These will form the model at the core of the system. The allocation process is
effectively modeled as a controller component, providing abstraction above the model and processing user
input. Finally, the terminals act as little more than shells for the system. Their lightweight requirements make
them perfect for implementation as a View.
4. Network Architecture
4a. Network Overview
As specified in the project requirements, the user terminals will interact with the system over a computer
network. To facilitate this communication, we have developed a network abstraction layer to make network
communication invisible to the other modules. The terminals will run as if interacting with the system directly.
Each component requiring a network interface will provide a server to which clients can connect. These clients
will serve as local instances of the components, exposing all necessary methods on the client machine. When a
message call is received, it will be sent via TCP/IP to the server, decoded, and the response will be returned.
5
5. Component Analysis
5a. Overview
5b. City Simulation
The city simulation will hold a representation of the city’s map, the collection of ambulances, and the collection
of incidents.
5c. Map Controller
The map controller will manage the city simulation, allowing for information retrieval, and determining the
shortest distance between two points.
5d. Allocator
The allocator allocates ambulances and inputs new incidents to the map controller.
5d. Exception Monitor
The exception monitor polls the map controller for incomplete incidents and handles duplicates generated by
the allocator.
6
5d. Logging
The logging component logs activity and events as reported by the other components.
5e. Operator Terminal
The operator terminal is the operator’s interface with the system. It submits incidents to the allocator, responds
to selection requests, and submits ambulance position and incident status reports to the map controller.
5f. Supervisor Terminal
The supervisor terminal is the supervisor’s interface with the system. It submits manual allocations to the
allocator, responds to exceptions, and updates map and ambulance fleet information in the Map Controller.
COMPONENT DESIGN
6. Dispatch Server
6a. Component Design Rationale
The Dispatch Server initializes all servers and gets everything running. It is necessary to meet the functional
requirements of the system.
6b. Class Diagram
7. City Simulation
7a. Component Design Rationale
The City Simulation component serves as the data repository of the Ambulance Dispatch System. By
centralizing data in this component, synchronization can be easily managed. The dispatch system must keep
track of ambulances and incidents, and be able to estimate time of arrival for ambulances.
To do this, the system must store some kind of internal map. Our system will store this map as a list of
vertexes and edges, where vertexes are intersections and edges are streets between them. Address ranges will be
attached to edges, as addresses are located on streets in real life. Edges will contain a method to determine if a
particular address is on the street which will return the closest vertex. This allows the system to provide
reasonable close approximations of address location for the path-finding algorithm, without requiring that
addresses be explicitly located on the map. The edges will also be assigned path costs, which can either be time
or distance measures.
7
In addition to the map, the city simulation will keep track of ambulances and incidents. Each will have an
address element, allowing it to be located on the map, along with other information to facilitate allocation.
They will also include description information for the use of operators and supervisors.
7b. Class Diagram
8. Map Controller
8a. Component Design Rationale
The Map Controller component serves as an interface to the city simulation both from the other server
components and the client components.
To the clients, the Map Controller will provide copies of the ambulance and incidents stored in the system. It
will also provide methods for modifying the ambulance fleet and map.
The purpose of the Map Client class is to provide a transparent interface to the client systems, allowing simple
method calls to interact with the server model.
The map controller will also calculate the shortest path between locations on the map. Dijkstra’s Shortest Path
Algorithm will be used to implement the getClosestAmbulances() method.
For quick lookup, MapController will store ambulances, incidents, and connections in HashMaps.
8
8b. Class Diagram
9. Allocator
9a. Component Design Rationale
The Allocator component takes input from the operators about incident details and location. Using that
information, the Allocator gathers data from the Map Controller to determine which ambulances might be best
to dispatch and sends that information to the Operator.
The Allocator will also perform a check to see if the new incident’s location matches the location of a previous
incident. If a match is found, the Allocator passes the information to the Exception Monitoring component to
handle.
9b. Class Diagram
9
10. Exception Monitoring
10a. Component Design Rationale
The Exception Monitoring centralizes exception messages by allowing other components in the server to pass
messages to it. When it receives an exception message, it will then pass it to a supervisor. The primary reason
for this capability was to shift coupling across the network to coupling across the components which increases
reliability and maintainability.
The Exception Monitoring component also periodically checks active incidents with the Map Controller to
ensure that time restraints have not been exceeded. In the case that an incident has exceeded its time restraint,
the Exception Monitoring component will generate an exception and send it to a supervisor.
Any exceptions generated or received are passed to the Logging component to record in the log.
10b. Class Diagram
11. Logging
11a. Component Design Rationale
The Logging component serves to centralize access to the system log. The Logging component will handle
messages from other server components and write the information it receives into a text file.
The text file the Logging component generates is accessible to supervisors outside of the program allowing the
information to be available for troubleshooting the system if there is a problem that is preventing the normal
operation of the system.
The log file also contains all of the incident and dispatch records for reference.
The logger also keeps track of statistical information including total number of calls logged, average assignment
and completion time, as well as the total number of exceptions logged.
10
11b. Class Diagram
12. Operator Terminal
12a. Component Design Rationale
Design goals for the Operator terminal were primarily simplicity and ease of use. Because of these
nonfunctional requirements, the operator GUI is minimalist with a simple tabbed design. The purpose of the
operator GUI is to get information into the system as quickly and efficiently as possible and it will be easy for
the operators to do so using the GUI as designed.
11
12b. User Interface Design
12
13
13. Supervisor Terminal
13a. Component Design Rationale
The supervisor terminal needs to perform three simple functions: handle duplicates and cases where
ambulances take longer than the allowed amount of time to arrive or be dispatched (known as warnings in the
GUI), perform manual allocations, and retrieve statistics about the dispatch system. With these functional
requirements in mind, the supervisor GUI was designed to be as simple to use as the operator GUI with tabs
allowing access to information quickly to allow the supervisor to make their life or death decisions as efficiently
as possible. (Fulfilling the nonfunctional requirements as well)
13b. User Interface Design
14
15
DETAILED UML DIAGRAMS
14. City Simulation
Map Incident
- ArrayList vertices - int IDnumber
- ArrayList edges - Date timeStamp
+ getVertex(Address) : Vertex - Date ExceptionTimeStamp
+ getVertices() : ArrayList - String handlerName // Last person
//to work with incident
+ getEdge(Address) : Edge
- Address location
+ getEdges() : ArrayList
- IncidentDescriptor description
+ addVertex(Vertex) + getIDnumber() : int
+ addEdge(Edge) + getHandlerName() : String
+ deleteVertex(Vertex) + getLocation() : Address
+ deleteEdge(Edge) + getDescription() : IncidentDescription
+ getTimeStamp() : Date
+ getExceptionTimeStamp() : Date
Ambulance
+ setHandlerName(String name)
- int ambulanceNumber
+ setLocation(Address)
- Address location
+ setExceptionTimeStamp(Date)
- int incidentID
- int available
+ getAmbulanceNumber() : int IncidentDescriptor
+ getLocation() : Address
- Arraylist Ambulances
+ getIncident() : Incident
- String callerName
+ isAvailable() : boolean
- String notes
- String phoneNumber
+ setLocation(Address)
- String SSN
+ setIncident(Incident)
+ setAvailable(boolean) + getAmbulances() : Arraylist
+ getCallerName() : String
+ getNotes() : String
+ getPhoneNumber() : String
+ getSSN() : String
+ setNumberOfAmbulances(int)
+ setCallerName(String)
+ setNotes(String)
+ setPhoneNumber(String)
+ setSSN(String)
+ appendNotes(String)
16
Vertex
- ArrayList edges
+ getEdges() : ArrayList
+ addEdge(Edge)
+ deleteEdge(Edge)
Edge
- Vertex lowerBoundVertex
- Vertex upperBoundVertex
- String streetName
- int lowerAddressBound
- int upperAddressBound
- int cost
+ getVertices() : ArrayList
+ getLowerBoundVertex() : Vertex
+ getUpperBoundVertex(): Vertex
+ getStreetName() : String
+ getLowerAddressBound() : int
+ getUpperAddressBound() : int
+ getCost() : int
+ setLowerBoundVertex(Vertex)
+ setUpperBoundVertex(Vertex)
+ setStreetName(String)
+ setLowerAddressBound(int)
+ setUpperAddressBound(int)
+ setCost(int)
+ contains(Address) : Vertex closest
Address
- String streetName
- int address
- int suite
+ getStreetName() : String
+ getAddress() : int
+ getSuite() : int
17
15. Map Controller
MapController MapClient
- Map map
- HashMap ambulances
+ getAmbulances() : ArrayList
- HashMap incidents
+ getIncidents() : ArrayList
- HashMap connections
+ getAmbulance(int ID) : Ambulance
+ getAmbulances() : ArrayList + getIncident(int ID) : Incident
+ getIncidents() : ArrayList
+ getAmbulance(int ID) : Ambulance + addAmbulance(Ambulance)
+ getIncident(int ID) : Incident + deleteAmbulance(Ambulance)
+ updateAmbulance(Ambulance)
+ addAmbulance(Ambulance)
+ deleteAmbulance(Ambulance) + addIncident(Incident)
+ updateAmbulance(Ambulance) + deleteIncident(Incident)
+ updateIncident(Incident)
+ addIncident(Incident)
+ deleteIncident(Incident) + insertStreet(Address begin, Address end,
int cost)
+ updateIncident(Incident)
+ removeStreet(Address begin, Address end)
+ insertStreet(Address begin, Address end,
int cost) + getClosestAmbulances(int number, Address)
: ArrayList
+ removeStreet(Address begin, Address end)
+ getAvailableAmbulances():
ArrayList
+ getClosestAmbulances(int number, Address)
: ArrayList
+ getAssignedAmbulances(Incident) :
+ getAvailableAmbulances(): ArrayList
ArrayList
+ getAssignedAmbulances(Incident) :
ArrayList MapHandler
+ run()
+ unpack(Message)
18
16. Allocator
AllocatorServer
- MapController map
- ExceptionMonitorServer ems
- ConnectionManager connManager
+ AllocatorServer(MapController map,
ExceptionMonitorServer ems)
+ newHandler(Socket)
- checkDuplicates()
+ getAmbulanceChoices(Incident i) :
ArrayList
+ allocateAmbulances(ArrayList,
Incident)
AllocatorClient
- Socket socket
- ObjectInputStream ois
- ObjectOutputStream oos
+ getAmbulanceChoices(Incident) :
ArrayList
+ allocateAmbulances( Ambulance,
Incident i)
AllocatorHandler
- Socket socket
- ObjectInputStream ois
- ObjectOutputStream oos
- AllocatorServer alloc
+ run()
+ unpack(Message)
ConnectionManager
- Server server
+ run() // listens and tells the
server to make handlers
19
17. Exception Monitor
ExceptionManagerServer DuplicateException
- MapController map - int incidentID
- ArrayList connections - int originalIncidentID
- ArrayList Incidents
+ getIncidentID() : int
- ConnectionManager connManager
+ getOriginalIncidentID() : int
+ run() // Scans for exceptions
+ newConnection(Socket)
- throwTimeExpiredException(Incident)
+ throwDuplicateException(Incident i,
Incident i2)
+ throwException(DispatchException e)
ExceptionManagerClient
- GUI supervisor GUI
+ run()
ConnectionManager
- Server server
+ run() // listens and makes
handlers
DispatchException
TimeExpiredException
- int IncidentID
+ getIncidentID() : int
20
18. Logging
LogServer
- File logFile
- ConnectionManger manager
+ logNewIncident(Incident)
+ logIncidentCompletion(Incident)
+ logException(Incident, String)
+ logAllocation(Incident, Ambulance)
+ logDuplicate(Incident, Incident)
+ getTotalCalls() : int
+ getAverageAssignTime() : long
+ getAverageArriveTime() : long
+ getNumberOfTimeExceptions() : int
+ getNumberOfDuplicateExceptions() : int
+ getIncident(int incidentID) : Incident
LogClient
- Socket socket
- ObjectInputStream ois
- ObjectOutputStream oos
+ getTotalCalls()
+ getAverageAssignTime()
+ getAverageArriveTime()
+ getNumberOfTimeExceptions()
+ getNumberOfDuplicateExceptions()
+ getIncident(int incidentID)
LogHandler
- Socket socket
- ObjectInputStream ois
- ObjectOutputStream oos
- LogServer logger
+ run()
+ unpack(Message message)
21
19. Message
Message
+ int command
+ ArrayList parameters
+ GET_AMBULANCE_CHOICES int
+ ALLOCATE_AMBULANCES int
+ GET_INCIDENT_LOG
+ GET_AMBULANCE_LOG
+ GET_LOG_BY_DATE
+ GET_LOG_FILE
… all commands that need to be sent
+ Message(int command)
+ Message(int command, ArrayList
params)
+ addParameter(Object param)
20. Dispatch Server
DispatchServer
+ main() // Init servers
21. Full UML Diagram
23