Ambulance Dispatch System
[pic]
Software Design Document (Deliverable 3)
CS 6354 – Advanced Software Engineering, Section 581
Summer 2007
[pic]
The Fantastic 9
|Arturo Saracho |axs067000@utdallas.edu |11120701 |
|Denis Stetsenko |dxs067000@utdallas.edu |10829000 |
|Sarthak Dudhara |skd051000@utdallas.edu |11138921 |
|Abdullah Azzouni |ama063100@utdallas.edu |11152135 |
|Russell Smith |rss061000@utdallas.edu |11126187 |
|Anitha John |akj041000@utdallas.edu |10480080 |
|Abhishek Goyal |axg056100@utdallas.edu |11139363 |
|Nate Gardner |njg011100@utdallas.edu |10080880 |
|Sheetal Umeshkumar |sxu054000@utdallas.edu |11108292 |
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 |
Table of Contents
Purpose of this document 4
Audience 4
1. Introduction 4
1.1. Purpose of the system 4
1.2. Design goals 4
1.3. Definitions, acronyms, and abbreviations 4
1.4. References 5
1.5. Overview 5
2. Current Software Architecture 5
3. Proposed System 6
3.1. Overview 6
3.2. Subsystem Decomposition 8
3.3. Hardware/software mapping 10
3.4. Persistent data management 13
3.5. Access Control and Security 14
3.6. Global Software Control 15
3.7. Boundary Conditions 16
4. Subsystem Services 17
4.1. The User Interface (UI) Subsystem 17
4.2. The Main Subsystem 17
4.3. The Hospital Subsystem 17
4.4. The Emergency Subsystem 17
4.5. The Ambulance Subsystem 18
4.6. The Caller Subsystem 18
4.7. The Case Subsystem 18
4.8. The Database Subsystem 18
Glossary 18
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.
Introduction
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).
2 Design goals
The goal of the system is to satisfy the functional and non functional requirements as specified in the requirements specification document.
3 Definitions, acronyms, and abbreviations
|ADS |Ambulance Dispatch System |
|EMT |Emergency Medical Technician |
|GPS |Global Positioning System |
|HTML |Hyper Text Markup Language |
|SDD |Software Design Document |
|SRR |Software Requirements Specification |
|UI |User Interface |
4 References
1] Lawrence Chung, Advanced Software Engineering syllabus, CS 6354 section 581, Summer 2007.
2] Bernd Bruegge, Allen H. Dutoit, Object-Oriented Software Engineering using UML, second edition. Prentice Hall, 2003.
6 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.
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 both remove the unnecessary paper trail and allow the EMTs to focus on handling the emergency.
Proposed System
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 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.
[pic]
Figure 1 - System Birdseye View
2 Subsystem Decomposition
[pic]
Figure 2 - Subsystem Decomposition of the Ambulance Dispatch System UML Class Diagram
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.
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.
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. 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.
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.
5. The Ambulance Subsystem is responsible for all interactions 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.
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.
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.
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 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:
• 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.
[pic]
Figure 3 - Hardware Mapping
4 Persistent data management
9. 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.
10. Database Schema
[pic]
Figure 4 - Database Schema
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 |Yes |Yes |Yes |Yes |No |
|Ambulance | | | | | |
|Hospital Availability |Yes |Yes |Yes |No |No |
|Monitor Performance and |Yes |Yes |Yes |No |No |
|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.
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
o The Main Subsystem initiates the Hospital Subsystem by checking the availability and notifying of the emergency.
o 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.
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.
• 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.
Subsystem Services
1 The User Interface (UI) Subsystem
- Takes user input
- Passes user input to controlling layer (server)
- Displays system messages
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
3 The Hospital Subsystem
- Provides hospital location information
- Takes inquiries about hospital availability
- Provides hospital availability information
- Receives notification of incoming cases
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
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
6 The Caller Subsystem
- Provides emergency details
- Sends DB update requests for caller subsystem
- Provides caller address information to main subsystem
7 The Case Subsystem
- Receives details from emergency subsystem
- Sends DB update requests for case subsystem
- Receives status updates from ambulance subsystem
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 System|The main system to be built. All subsystems are controlled through this |
| |system. |
|Ambulance System |The hardware and software systems composing an ambulance unit. This includes |
| |the ambulance software part of the dispatching system. It also includes |
| |location-tracking hardware, the ambulance laptop, and the ambulance |
| |communication device (radio for example). |
|Telephone System |The city’s telecommunication system that will be used to connect emergency |
| |calls and find caller addresses. |
|Location-Tracking |A system that provides locations of objects with attached tracking devices. In|
|System |ADS case, it is a third-party satellite 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. |
|Subsystem Decomposition |
|User Interface |Part of the system responsible for taking user input and displaying system |
|Sub-system |output. |
|Main Sub-system |Part of the system responsible for overall control. It is also responsible for|
| |controlling access to user and map information. |
|Hospital |Part of the system responsible for updating and controlling access to |
|Sub-system |ADS-specific hospital-related information. |
|Emergency |Part of the system responsible for controlling access to and updating |
|Sub-system |emergency-specific details. |
|Ambulance |Part of the system responsible for controlling access to and updating |
|Sub-system |ambulance-specific details. |
|Caller Sub-system |Part of the system responsible for controlling access to and updating |
| |caller-specific information. |
|Case Sub-system |Part of the system responsible for controlling access to and updating |
| |case-specific details. |
-----------------------
Internet
Telephone System
Location-Tracking System
Dispatching System
Ambulance System
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- army dispatch form 1970 printable
- aetna ambulance coverage policy
- ohio ambulance transport
- ambulance services in ohio
- dispatch qa qc inspection sheet
- elite ambulance service cleveland ohio
- physicians ambulance service cleveland ohio
- ambulance companies columbus ohio
- baltimore county fire dispatch live
- city of henderson ambulance billing
- local ambulance service
- delivery in ambulance icd 10