Ambulance Dispatch System (CAD

System)

System Design Document

Faisal Azizullah
Brandon Bass
Ali Hashi
Sonali Jejurkar (Team Lead for del-3)

Sirisha Koneru
Ananthapriya Mummineni (Team Lead for del-2)
Shveta Mupparapu (Team Lead for del-1)
Vidya Perumal
Group URL: http://www.ace6354.com/adv_soft_engg.aspx
Revision History:

Version Revision Description Author

Date
1.0 06/23/2007 Initial Draft with template & section 1 Sonali Jejurkar
1.1 06/29/2007 Section 1 refinement Sonali Jejurkar
1.2 06/30/2007 Initial draft with all the sections and Sonali Jejurkar
necessary UML diagrams
1.3 07/01/2001 Typo in section 3.5 is fixed Vidya Perumal
1.4 07/01/2007 Paragraph 2 in section 1.5 should be Brandon Bass
describing the dispatcher interface
1. Introduction
1.1 Purpose of the system
The emergency ambulance dispatch system or Computer Aided Dispatch System (CAD)
is a web based application that efficiently receives a phone call from 911 services,
records the details of an emergency incident including location, finds the next available
ambulance and dispatches the ambulance within 3 minutes.
As referenced in the Requirements Analysis Document (RAD) that we submitted as a
deliverable 1 and 2, the system throws an exception if the ambulance is not dispatched
within 11 minutes range after receiving the phone call from the 911 operator.

1.2 Design goals

Identifying design goals is the key step of Design phase in SDLC. In the light of non-
functional requirements addressed in the earlier phases we agreed to develop CAD
considering following design objectives.
1. Reliability: For 99.9% times LTS will provide accurate map for the incident
location and should give correct directions to CAD. Once Dispatcher receives
correct information from LTS, it can guide the driver of the ambulance
accordingly.
2. Usability: The Dispatcher interface will be very user friendly and system
designers will create all the necessary user manuals for easy use of the system.
3. Performance: CAD will be designed to achieve one minute of response time to
locate nearest ambulance from the nearest location after submitting location
details.
4. Supportability: The system can be extended to identify the nearest hospital from
the incident location in the 2nd stage of system development. Also after the go-
live of the 1st stage of CAD there will be a team of 5 members to provide the
required technical support.
5. Implementation: Since the CAD system will be developed using JAVA and
Rational Rose the system designers will have the constraint of having technical
experts in this area.
6. Interface: The CAD system interacts with LTS for getting driving directions to
the location. Therefore CAD will be compatible with LTS
7. Packaging: CAD is packaged into WAR file.
8. Legal: CAD will be compliant as far as the licenses for the soft wares it uses are
concerned.

1.3 Definitions, acronyms, and abbreviations

1. CAD (Computer Aided Dispatcher): This is the name given to the software
system under consideration.
2. Caller: Is the person who calls the 911 service and asks for an ambulance
3. Operator: Is the person who attends the phone call at 911 services
 4. Dispatcher: Is the person who receives the phone call from operator, enters
incident information into CAD system, and processes the necessary details for
dispatching the ambulance
5. LTS (Location Tracking System): Is the independent software component that
accepts caller phone number from CAD and provides location details to CAD. This
is a mapping system.
6. System Administrator: Is the person who manages all types of user accounts
using CAD and maintains their access privileges.
7. Driver: Is the person who is driving the ambulance.
8. SDLC: Software Development Life Cycle

1.4 References
Problem Statement: http://utdallas.edu/~chung/CS6354/Project.doc
Architecture Specification: http://wwwbruegge.informatik.tu-
muenchen.de/twiki/bin/view/OOSE/SystemDesignDocumentTemplate
Object-Oriented Software Engineering - Using UML, Patterns, and Java 2nd Edition
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design
and the Unified Process, 2nd ed., C. Larman

1.5 System Overview

CAD systems goal is to provide fastest ambulance service to the victims of any
emergency incidents. To achieve this goal the system is decomposed into Operator
Interface, Dispatcher Interface (CAD) and LTS Interface. For implementation purpose
Operator Interface and LTS interface are beyond the scope of this project. The CAD
system assumes the input from Operator Interface, processes it, sends the callers phone
number to LTS Interface, and receives the location details from LTS.

The Dispatcher Interface is used by a 911 ambulance dispatcher that stores all the
information provided by the caller. This information includes address of the incident,
number of people injured, number of ambulances required and type of emergency. After
processing this information an appropriate incident report is created by this system and
sent to the Dispatcher system as an input. The CAD system under consideration is built
assuming validated report of an incident exists and is provided to CAD as an input.
The CAD system is designed to locate the available ambulances near the incident
location and dispatch them as per the requirement with the help of LTS. We assume that
LTS provides incident location and this will be used by CAD, in conjunction with CADs
internal maps, to derive driving directions. LTS is a highly sophisticated navigation
system that provides location details by accepting callers phone number as an input. If
the caller is located outside the reach of LTS signals then some additional details about
incident are expected.

All three interfaces are closely interlinked and with validated inputs to the system
interfaces an attempt is made to dispatch the ambulance within 3 minutes range.
2. Current software architecture
Since this project is based on Greenfield engineering we will discuss current architecture
of the similar system called MyTrip discussed in course text book. Using this application
a driver can plan a trip from a home computer by contacting a trip-planning service on
the Web. The trip is saved for later retrieval on the server. The trip-planning supports
more than one driver like our CAD system supports more than one caller.
The system is decomposed into 2 subsystems namely RoutingSubsystem and
PlanningSubsystem. The PlanningSubsystem is responsible for constructing a Trip
connecting a sequence of Destinations. The PlanningSubsystem is also responsible for
responding to replan requests RoutingSubsystem.
The RoutingSubsystem is responsible downloading a Trip from the PlanningService and
executing it by giving Directions to the driver based on its location. This initial
subsystem decomposition and interaction between subsystems resembles to CADs
subsystem and their interfaces.

3. Proposed software architecture

3.1 Overview
This section will mainly address various software components of CAD system. An
Operator Interface and LTS Interface are beyond the scope of this course project. The
CAD system under consideration is initially decomposed into 2 subsystems called
Dispatcher Interface and Ambulance Interface that heavily interact with an external
database called Incident Management System.
Incident Management System is a central database storing all the details about an incident
entered via Dispatcher Interface and all the vehicle details entered via Ambulance
Interface. Both these interfaces independently access the central repository and keep
track of all the incidents that might be used for generating reports.
3.2 Subsystem decomposition
As mentioned above, the two main parts of the CAD subsystem: the Dispatch
information organization part of the system which is responsible to record the details of
the incident and via Dispatcher Interface and the Ambulance organization part, in which
vehicle details are managed.
For the Dispatch information part, a three-tier architectural style in which a Dispatcher
client subsystem provides a front end for users to initiate all Dispatch related use cases
(e.g., Enter Caller Information, Track Caller Location, Dispatch Ambulance, Monitor
Ambulance) The CADServer subsystem is responsible for access control and
concurrency control, and delegates to nested subsystems for the application logic. The
bottom tier is realized by the Incident Management system responsible for storing any
persistent objects.
For the Ambulance Organization part, client server architecture may not be sufficient for
synchronous ambulances in which the action of one ambulance can trigger events for
other ambulances within a relatively short time. For simulating synchronous behavior
and achieving the goal of responsiveness, we select a peer-to-peer architecture in which
Ambulance Interface subsystem provides the interface and AmbulancePeer maintains the
state of the ambulances currently on the road and serving the victims.
Following package diagrams make this subsystem decomposition more clear.

Dispatcher Interface.
DispatcherClient

Application Logic

Ambulance
DispatcherServer Management

User
Management

Location
Management
Notification

Incident Management Storage

Incident
Storage
 AmbulanceFrontEndPeer
LTS

AmbulancePeer Incidence
Management

3.3 Hardware/software mapping

CAD is inherently a distributed system, as users sit in front of different machines,
possibly from several different locations. However, we distinguish only between two
types of nodes: the UserMachine to provide a Dispatcher user interface and the
ServerMachines to run the application logic and storage and, more generally, to provide
the CAD services. CADClient and the AmbulanceFrontEndPeer run on the
UserMachine. In an installation of CAD with few Dispatchers, all other subsystems can
be collocated onto a single ServerMachine. However, to ensure scalability we identify an
additional subsystem dedicated to send Ambulance status to the browser and assign the
StatusServer, the AmbulancePeer, the IncidenceManagement and the CADServer
subsystems to different processes that can run on different ServerMachines.
For the realization of the dispatcher organization part of CAD, we select J2EE
framework. J2EE is a collection of interfaces and standards developed by Sun
Microsystems and community efforts for developing portable web-based information
systems in Java. The advantage of this standard is that it is implemented by several open-
source and commercial products, thus enabling a Dispatcher to trade off scale. (e.g.,
number of ambulances, number of ambulance drivers) for set-up costs (e.g., licensing and
run-time costs). Also, in their simplest form, open source components of this framework
are easy to install and require little prior administration knowledge.
Consequently, the CADClient is a Web browser and the CADServer and the other
dispatcher organization subsystems are accessed through a Web server. To realize the
CADServer and related subsystems, we select JAVA Servlets and JAVA Server Pages
(JSP), components of J2EE, as the main technology for implementing the boundary
objects. Servlets are classes that are located on the ServerMachine, process and respond
to requests from a Web browser by generating an HTML page. We use JSPs to realize
the boundary and control objects of CAD. JSPs in turn invoke methods on entity objects
and storage objects, which are also, realized using JAVA foundation classes. In the
following diagram the components on the left side reside on client machine and the
components on the right side reside on the server machine.
 :CADServer
:CADClient

:IncidentManagem
AmbulanceFron ent
tEndPeer

:StatusServer

AmbulancePeer

3.4 Persistent data management

CAD deals with 2 sets of objects that must be stored. The first set includes the objects
that are created and accessed by the dispatcher organization subsystems and that need to
be persistent to track the progress of dispatcher processes. The second set includes the
objects that are created and accessed by the AmbulancePeer and the
AmbulanceFrontEndPeer during dispatch process and are used to track the status of
ambulances while on the road.
The first set of objects is well defined and will probably not change much during the
lifetime of CAD. The second set of objects are specific to each Ambulance are defined
by the Ambulance developers. All these objects are managed by Incident Management
System.
The initial prototype of CAD will use flat files to store persistent objects and will
minimize operating costs in the early phases of development.

3.5 Access control and security

The CAD is a multi-user system, different actors are allowed to view different sets of
objects and invoke different types of operations on them. The System Administrator can
create users and maintain their accounts. The Ambulance Station can create instances of
new vehicles and manages them. Also it can view ambulance status. Note that most of
the access control information is already stated in the use case model

3.6 Global software control

We have already stated above in hardware/software mapping section that the WebServer
waits for requests from WebBrowser. Upon the receipt of a request, the WebServer
processes it and dispatches it to the appropriate servlet or JSP, thus resulting in an event-
based control flow. The Web Server allocates a new thread for each request, allowing the
parallel handling of requests. This results in a more responsive system by enabling the
WebServer to respond to individual WebBrowser requests before other requests have
been completely processed, and can increase throughput by enabling the processing of
one request while another is waiting for the database to respond.

3.7 Boundary conditions

In this section we review design decisions and identify additional boundary use cases.
CAD is created with the installation of the system. Vehicle instances to be tracked are
created and destroyed as the ambulances are being dispatched. So following are the
additional uses cases while reviewing persistent objects.
InstallCAD: The Administrator installs CAD, gives an instance name and selects a
persistent storage subsystem and configures resource parameters (e.g., maximum number
of concurrent ambulances to be dispatched and tracked, file path for storage)
ManageAmbulances: The actor Ambulance Station adds or removes an ambulance,
including custom code for AmbulancePeer and AmbulanceFrontEndPeer. The list of
ambulances is updated for the next time an actor enters new vehicle.
ConvertPersistentStorage: When the CADServer is down, the Administrator can
convert the persistent storage from a flat file storage to a database storage or vice a versa.
StartCADServer: The Administrator starts the CADServer. If the server was not
cleanly shut down, this use case invokes the Check Data Integrity usecase that handles
this exceptional behavior.
CheckDataIntegrity: CAD checks the integrity of the persistent data. For file-based
storage, this may include checking if the last logged transactions were saved on the disk.
For database storage, this may include invoking tools providing by the database system to
re-index the tables.