Software Design Document (Deliverable 3)
CS 6354 – Advanced Software Engineering, Section 581
Summer 2007
TThhee FFaannttaassttiicc 99
Arturo Saracho
Denis Stetsenko
Sarthak Dudhara
Abdullah Azzouni
Russell Smith
Anitha John
Abhishek Goyal
Nate Gardner
Sheetal Umeshkumar
© The Fantastic 9®
axs067000@utdallas.edu
dxs067000@utdallas.edu
skd051000@utdallas.edu
ama063100@utdallas.edu
rss061000@utdallas.edu
akj041000@utdallas.edu
axg056100@utdallas.edu
njg011100@utdallas.edu
sxu054000@utdallas.edu
11120701
10829000
11138921
11152135
11126187
10480080
11139363
10080880
11108292
http://www.utdallas.edu/~dxs067000/cs6354
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
Revision History
Version
Date
Comments
Author
1.0
6/26/2007
Initial Version -- Template
A. Azzouni
1.1
7/1/2007
Consolidated Version
A. Azzouni
-2-
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
Table of Contents
PURPOSE OF THIS DOCUMENT ............................................................................................................ 4
AUDIENCE ................................................................................................................................................... 4
1.
INTRODUCTION............................................................................................................................... 4
1.1.
1.2.
1.3.
1.4.
1.5.
PURPOSE OF THE SYSTEM ............................................................................................................. 4
DESIGN GOALS ............................................................................................................................. 4
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS .......................................................................... 4
REFERENCES ................................................................................................................................ 5
OVERVIEW ................................................................................................................................... 5
2.
CURRENT SOFTWARE ARCHITECTURE.................................................................................. 5
3.
PROPOSED SYSTEM ....................................................................................................................... 6
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
4.
OVERVIEW ................................................................................................................................... 6
SUBSYSTEM DECOMPOSITION ...................................................................................................... 8
HARDWARE/SOFTWARE MAPPING................................................................................................10
PERSISTENT DATA MANAGEMENT ...............................................................................................13
ACCESS CONTROL AND SECURITY ..............................................................................................14
GLOBAL SOFTWARE CONTROL....................................................................................................15
BOUNDARY CONDITIONS.............................................................................................................16
SUBSYSTEM SERVICES ................................................................................................................17
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
THE USER INTERFACE (UI) SUBSYSTEM......................................................................................17
THE MAIN SUBSYSTEM ...............................................................................................................17
THE HOSPITAL SUBSYSTEM ........................................................................................................17
THE EMERGENCY SUBSYSTEM ....................................................................................................17
THE AMBULANCE SUBSYSTEM ....................................................................................................18
THE CALLER SUBSYSTEM ...........................................................................................................18
THE CASE SUBSYSTEM ................................................................................................................18
THE DATABASE SUBSYSTEM .......................................................................................................18
GLOSSARY .................................................................................................................................................18
-3-
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
Purpose of this document
System design is documented in the System Design Document (SDD). It
describes design goals set by the project, subsystem decomposition (with UML
class diagrams), hardware/software mapping (with UML deployment diagrams),
data management, access control, control flow mechanisms, and boundary
conditions. The SDD is used to define interfaces between teams of developers
and serve as a reference when architecture-level decisions need to be revisited.
Audience
The audience for the SDD includes the project management, the system
architects (i.e., the developers who participate in the system design), and the
developers who design and implement each subsystem.
1. Introduction
1.1. Purpose of the system
The system is designed to implement a solution to an application domain
which consists of an ambulance dispatch system. This will be achieved
by delivering a software system that will interact with the corresponding
actors, such as a caller that dials 911, a dispatcher that handles the call
and dispatches ambulances, the ambulances, a relative looking for
information about a patient, and an emergency room. The system will be
an online based software system that can be accessed from any
computer with a connection to the internet.
The solution implemented will allow better control of an
emergency situation by properly tracking the case from the moment the
call is placed until the patient is delivered to an emergency room, by
providing the means necessary for the dispatcher and the ambulances to
communicate with each other to exchange the necessary information and
by providing the electronic resources needed to complete all tasks
required, such as finding an address, locating the nearest available
ambulance and providing case status to a third party (relative).
1.2. Design goals
The goal of the system is to satisfy the functional and non functional
requirements as specified in the requirements specification document.
1.3. Definitions, acronyms, and abbreviations
ADS
EMT
GPS
Ambulance Dispatch System
Emergency Medical Technician
Global Positioning System
-4-
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
HTML
SDD
SRR
UI
Hyper Text Markup Language
Software Design Document
Software Requirements Specification
User Interface
1.4. References
[1] Lawrence Chung, Advanced Software Engineering syllabus, CS 6354
section 581, Summer 2007. http://www.utdallas.edu/~chung/CS6354
[2] Bernd Bruegge, Allen H. Dutoit, Object-Oriented Software
Engineering using UML, second edition. Prentice Hall, 2003.
http://wwwbruegge.in.tum.de/OOSE
1.5. Overview
The purpose of this design document is to provide the design models and
methodologies that are developed and used to satisfy the requirements.
This document presents detailed diagrams that represent the functionality
of the system from the system's point of view to provide the necessary
interfaces to the users.
2. Current Software Architecture
Currently there is no software architecture for the ambulance dispatch
system. The current system is a phone a paper based system that is outdated
and unorganized. When the dispatcher receives an emergency call s/he then
radios to an ambulance to see if they are available to take the emergency. If
they are not available then s/he must continue to track down an ambulance
that is available. Once finding an available ambulance the dispatcher then
communicates to the EMT the location of the emergency and status of the
injured parties. This information is recorded by hand by the non-driving EMT.
Once finished at the scene the EMT must then radio near by hospitals to
ensure that the hospital can accommodate their patient. Once dropping the
patient off at the hospital, the EMT must then notify the dispatcher of the final
details of the patient's condition and other pertinent information about the
case. The dispatcher records this information by hand and then files the
necessary paperwork.
This current system leaves a paper trail that is difficult to follow later if
necessary. In addition, precious time is lost as the dispatcher attempts to
locate available ambulances and hospitals. The lost time could ultimately be
the difference between life and death for the patients. Our new software
architecture will address these issues by allowing the dispatcher to always
have available a real time list of available ambulances and hospitals. Our
software architecture will also electronically send all necessary information to
the ambulance along with a GPS map of the emergency location. This will
-5-
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
both remove the unnecessary paper trail and allow the EMTs to focus on
handling the emergency.
3. Proposed System
3.1. Overview
The ADS system in general will consist of 4 major parts: a phone system,
a dispatching system, a location-tracking system, and an ambulance
system. The combination of these 4 components will realize the full
potential of the ADS system.
The phone system will connect emergency callers through to ADS
dispatchers. The call first will be received by an operator. If the operator
identifies the call as a medical emergency, the call will be put through to
the system dispatchers. The city’s phone system is already in place. An
interface between ADS and the telecommunication network will need to
be built. The phone system will provide the physical address of the caller
if available, especially when calling from a land-line phone. In case of cell
phones, the caller area will be provided using the location of the
communication tower the call is routed through.
The dispatching system is the main part of ADS. The whole system is
controlled through this component. It tracks all ambulances on duty.
Hospitals in the coverage area are also monitored. Communication
between dispatchers and ambulances and between dispatchers and
hospitals is initiated through the dispatching system. This system is
detailed in the following sections.
The location-tracking system is an external (third-party) system that has
the capability to locate objects using satellite system. Each ambulance
will be equipped with a tracking device. The tracking system will provide
ADS with real-time information about each ambulance’s location. An
interface between ADS and this system will have to be built.
The ambulance system is installed in each ambulance. An ambulance will
have a tracking device installed as described in the location-tracking
system. Each ambulance will also have an online terminal. A terminal
consists of a laptop computer connected to the internet using a
broadband card. These devices will be comfortably installed in the vehicle
such that the driver and paramedic response is not hindered.
Communication between the dispatching system and the ambulance
system will be through the internet. A dispatching message will show on
the paramedic workstation once an emergency has been assigned to the
ambulance. The dispatcher can call the ambulance driver or paramedic
using the phone or some sort of a walkie-talkie device. This alternative
communication method is especially important in case of communication
-6-
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
failure through the internet.
The following diagram shows a general overview of the whole system.
The location-tracking system, telephone system, and internet are already
existing systems that ADS will interface with.
Location-Tracking
System
Ambulance
System
Telephone
System
Internet
Dispatching
System
Figure 1 - System Birdseye View
-7-
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
3.2. Subsystem Decomposition
Figure 2 - Subsystem Decomposition of the Ambulance Dispatch System UML Class Diagram
-8-
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
For better readability, we do not show the attributes and operations of the
classes. The object model of the RAD provides the classes in more detail.
3.2.1. The User Interface (UI) Subsystem is responsible for all
interaction between the users (Dispatchers, Managers, and
Administrators) and patient relatives. The UI is decomposed into a
set of HTML pages loaded and displayed in a web-browser (Microsoft
Internet Explorer, Netscape, etc). All entry of data, modification of
data, and deletion of data will be handled directly through the UI.
3.2.2. The Main Subsystem is responsible for all interactions between
the UI Subsystem and the Hospital Subsystem, Emergency
Subsystem and Ambulance Subsystem. The Main Subsystem is also
responsible for interactions between the Main Controller class and
the Map, User, Log and Report classes that make up the Main
Subsystem. The Main Subsystem is also responsible for the
interactions between the Map, User, Log, Report and Main Controller
classes/objects to the Database Subsystem. Each class, Main
Controller, Log, User, Report and Map is responsible for utilizing the
appropriate and necessary methods within the Database class to
insert, read, update and delete all corresponding data from
within each of the classes themselves.
3.2.3. The Hospital Subsystem is responsible for all interactions
involving Hospitals. All interactions with any Hospital will be handled
through and by the Hospital List class, except for Database
access, from within the Hospital Subsystem. The Hospital
Subsystem is also responsible for the interactions between the
Hospital List and Hospital classes/objects to the Database
Subsystem. Both the Hospital List and Hospital class will each be
responsible for utilizing the appropriate and necessary methods
within the Database class to insert, read, update and delete all
corresponding data from within each of the classes themselves.
3.2.4. The Emergency Subsystem is responsible for all interactions
involving Emergencies. All interactions with any Emergency will be
handled through and by the Emergency List class, except Database
access, from within the Emergency Subsystem. The Emergency
Subsystem is also responsible for the interactions between the
Emergency List and Emergency classes/objects to the Database
Subsystem. Both the Emergency List and Emergency classes will
each be responsible utilizing the appropriate and necessary methods
within the Database class to insert, read, update and delete all
corresponding data from within each of the classes themselves.
3.2.5. The Ambulance Subsystem is responsible for all interactions
-9-
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
involving Ambulances. All interactions with any Ambulance will be
handled through and by the Ambulance List class, except for
Database access, from within the Ambulance Subsystem. The
Ambulance Subsystem is also responsible for the interactions
between the Ambulance List and Ambulance classes/objects to the
Database Subsystem. Both the Ambulance List and Ambulance
classes will each be responsible utilizing the appropriate and
necessary methods within the Database class to insert, read, update
and delete all corresponding data from within each of the classes
themselves.
3.2.6. The Caller Subsystem is responsible for all interactions involving
Callers. All interactions with any Caller will be handled through and by
the Caller List class, except Database access, from within the Caller
Subsystem. The Caller Subsystem is also responsible for the
interactions between the Caller List and Caller classes/objects to the
Database Subsystem. Both the Caller List and Caller classes will
each be responsible for utilizing the appropriate and necessary
methods within the Database class to insert, read, update and delete
all corresponding data from within each of the classes themselves.
3.2.7. The Case Subsystem is responsible for all interactions involving
Cases. All interactions with any Case will be handled through and by
the Case List class, except Database access, from within the Case
Subsystem. The Case Subsystem is also responsible for the
interactions between the Case List and Case classes/objects to the
Database Subsystem. Both the Case List and Case classes will each
be responsible for utilizing the appropriate and necessary methods
within the Database class to insert, read, update and delete all
corresponding data from within each of the classes themselves.
3.2.8. The Database Subsystem is responsible for all insertion, reading,
updating and deletion of all data by all classes within the Main,
Hospital, Emergency, Ambulance, Caller, and Case Subsystems. No
data will be accessed in any way except through and by the
Database Subsystem. Each class from within the Subsystems
described above are responsible for inserting, updating and modifying
their own data by utilizing the corresponding methods belonging to
the Database Class within the Database Subsystem.
3.3. Hardware/software mapping
The diagram shown below depicts the outline of the deployment scheme
for the Ambulance Dispatch System.
The following components make up the Ambulance Dispatch System:
- 10 -
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®





Dispatcher's Workstation
o Phone Answering Device
o Web Browser
o Communication Device (for communication with ambulance)
Relative's Computer
o Web Browser
ADS Server
o Tomcat Application Server
o Third Party GPS Mapping Software
Ambulances
o Wireless Enabled Communication Module
o Third Party GPS Mapping Software
Database Server
o mySQL Database
The Dispatcher's Computer and Relative's Computer communicate with
the ADS server via HTTP/HTTPS protocol using the Browser in their
respective computers. The ADS Server has a Tomcat Application Server
running on a particular port listening for requests from the Dispatcher's as
well as the Relative's computer. The ADS server also has a third-party
GPS mapping software to interface with the cl. It also communicates with
the Emergencies Database Server using the JDBC API for connecting an
application with the mySQL database. The Ambulance also communicates
with the ADS server using the Wi-Fi internet. It also has the third-party
GPS mapping software installed in it to track its real-time location.
- 11 -
Figure 3 - Hardware Mapping
© The Fantastic 9®
http://www.utdallas.edu/~dxs067000/cs6354
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
3.4. Persistent data management
3.4.1. Introduction
Ambulance Dispatch system will largely depend on a relational
database to perform day-to-day operations and storing log data.
Data will be stored in a mySQL 5.0 DBMS and manipulated through
the Database Subsystem, which will ensure data integrity and
consistency. Database Subsystem will contain all necessary SQL
queries that will be accessible by the rest of the Subsystems.
Database will be hosted on Emergencies Database Server and will
be accessible 24/7 via a local area network. Database shall be able
to process up to 86,400,000 queries per day (up to 1,000 queries
per second) with the average query length of 5Kb.
The data stored in the database will include:







Emergencies
Cases
Ambulances
Hospitals
Callers
Patients
ADS Users and Groups
The database will be backed up on a daily basis to ensure data
security.
- 13 -
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
3.4.2. Database Schema
Figure 4 - Database Schema
3.5. Access Control and Security
The Access control Matrix for the Ambulance Dispatch System is as
follows:
Administrator
Dispatcher
Manager
Ambulance/Driver
Relative
Logging In
Yes
Yes
Yes
Yes
No
User Settings
Yes
Yes
Yes
Yes
No
Data Entry
Yes
Yes
Yes
No
No
Ambulance
Allocation
Yes
Yes
Yes
No
No
Communication
with the
Ambulance
Yes
Yes
Yes
Yes
No
Hospital
Availability
Yes
Yes
Yes
No
No
Monitor
Performance and
Yes
Yes
Yes
No
No
- 14 -
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
position
Monitor Display
Yes
Yes
Yes
No
No
Monitoring
Complete
Yes
Yes
Yes
Yes
No
Information
logging
Yes
No
Yes
No
No
Emergency
Transfer/Sharing
Yes
Yes
Yes
No
No
Logging Out
Yes
Yes
Yes
Yes
No
Reporting
Yes
No
Yes
No
No
Track Case
Yes
Yes
Yes
Yes
Yes
Security:
o Authentication mechanism: LDAP will be used for authenticating
the user login.
o Encryption: SSL will be used for data encryption that will be sent
over the internet.
o Database Security: Varying level of access control will be provided
to different users of the system to maintain the database security.
Access control will be differentiated based on the access privilege
provided to each user for each table. Admin user will have update
privileges on all the tables.
3.6. Global Software Control
The ADS architecture is to have an explicit, decentralized software
control. The system's dynamic control is distributed among different
controllers such that each object delegates some responsibility to other
objects. The request initiations are event-driven:
o The dispatcher initiates the UI Subsystem by logging into the
system.
o The ADS Main Subsystem is initiated when an emergency call is
routed to the dispatcher.
o The Main Subsystem initiates the Emergency Subsystem by
activating an emergency.
o The Emergency Subsystem initiates the Caller Subsystem by
gathering information from the caller.
o The Emergency Subsystem initiates the Case Subsystem by
logging the case.
o The Main Subsystem initiates the Ambulance Subsystem by
forwarding the emergency location and dispatching ambulance(s)
to the case site
- 15 -
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
o
o
The Main Subsystem initiates the Hospital Subsystem by checking
the availability and notifying of the emergency.
The Database Subsystem can be initiated at any point by all
Subsystems except the UI Subsystem. Any request
(add/update/delete/retrieve) to the repository initiates the Database
Subsystem. The system stores its contents in the database
between executions. When the application is run again, it retrieves
the contents from the previous execution. Any change in the
contents during this execution updates the database.
3.7. Boundary Conditions
Startup:
go to system URL and login
Shut Down: click log out and close browser
Error Conditions:
 Logging in:
o Username or password field can are blank.
o Username is not a 5 digit decimal number.
o Password is not 8 characters long.
o Password and username don’t match.
o Username is wrong or does not exist.
o The welcome screen does not appear after logging in.

User settings
o User is unable to change certain settings or changes don’t
reflect.
o Between the time of editing and updating, the system crashes.

Data Entry
o The system fails when the dispatcher is entering information.

Caller Address location
o Caller address could not be identified automatically.
o The call gets disconnected while talking to the caller.
o All lines are busy.
o The caller has no idea where he is calling from.

Ambulance Location
o The nearest ambulances are not reachable due to some
technical failure.
o There are no available ambulances.

Communication with the ambulance
o The communication line with the ambulance fails.
o There is a major traffic jam in one or many routes.
o The ambulance runs out of gas.
- 16 -
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®

Hospital availability
o There are no available beds in any of the(3) hospitals .

Monitor display
o The system crashes or the back up also crashes.
o The system hangs up.

Monitoring complete
o Emergency resolved does not take the dispatcher back to the
home screen (the system can hang or crash).

Emergency Transfer/Sharing
o Dispatcher unable to transfer the caller to another agent.

Relative searching for a case
o Search criteria do not return any results.

Logging out
o Dispatcher unable to logout.
4. Subsystem Services
4.1. The User Interface (UI) Subsystem
- Takes user input
- Passes user input to controlling layer (server)
- Displays system messages
4.2. The Main Subsystem
- Receives user queries through the UI subsystem
- Sends system responses to the UI subsystem
- Handles emergency creation and management
- Sends emergency information to ambulance subsystem
- Sends DB update requests for the User and Map objects to DB subsystem
4.3. The Hospital Subsystem
- Provides hospital location information
- Takes inquiries about hospital availability
- Provides hospital availability information
- Receives notification of incoming cases
4.4. The Emergency Subsystem
- Sends emergency details to main subsystem
- Receives details from caller subsystem
- Handles case management
- Sends DB update requests for emergency objects
- 17 -
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
4.5. The Ambulance Subsystem
- Updates case status
- Provides information about ambulance current location
- Receives case information from main subsystem
- Sends DB update requests for ambulance subsystem
4.6. The Caller Subsystem
- Provides emergency details
- Sends DB update requests for caller subsystem
- Provides caller address information to main subsystem
4.7. The Case Subsystem
- Receives details from emergency subsystem
- Sends DB update requests for case subsystem
- Receives status updates from ambulance subsystem
4.8. The Database Subsystem
- Receive update requests from different subsystems
- Sends object information to different requesting controllers
Glossary
ADS
Ambulance Dispatch System
Database
Data storage system
EMT
Emergency Medical Technician
GPS
Global Positioning System
HTML
Hyper Text Markup Language
mySQL
Relational Database Management System
SDD
Software Design Document
SRR
Software Requirements Specification
UI
User Interface
Proposed System Overview
Dispatching The main system to be built. All subsystems are
System
controlled through this system.
Ambulance
The hardware and software systems composing an
System
ambulance unit. This includes the ambulance software
part of the dispatching system. It also includes locationtracking hardware, the ambulance laptop, and the
ambulance communication device (radio for example).
Telephone
The city’s telecommunication system that will be used to
System
connect emergency calls and find caller addresses.
LocationA system that provides locations of objects with attached
Tracking
tracking devices. In ADS case, it is a third-party satellite
System
system that ADS will have an interface to in order to
provide real-time ambulance location information.
Ambulances will have an attached tracking device that
will be used by this tracking system.
- 18 -
CS 6354 –Summer 2007
ADS+ - An Ambulance Dispatch System
© The Fantastic 9 ®
Subsystem Decomposition
User
Part of the system responsible for taking user input and
Interface
displaying system output.
Sub-system
Main Sub- Part of the system responsible for overall control. It is
system
also responsible for controlling access to user and map
information.
Hospital
Part of the system responsible for updating and
Sub-system controlling access to ADS-specific hospital-related
information.
Emergency Part of the system responsible for controlling access to
Sub-system and updating emergency-specific details.
Ambulance
Part of the system responsible for controlling access to
Sub-system and updating ambulance-specific details.
Caller Sub- Part of the system responsible for controlling access to
system
and updating caller-specific information.
Case Sub- Part of the system responsible for controlling access to
system
and updating case-specific details.
- 19 -