From SoftwarePractice.org

Link to our Team Project Management

Contents 1 Overview 2 Purpose 3 Responsibilities of the System 4 Scope 5 Assumptions 6 Stakeholders 6.1 Stakeholder Personas 6.1.1 Responder 6.1.2 Management 6.1.3 Operators 6.1.4 Administrators 6.1.5 Victims 6.1.6 Developers 6.2 Stakeholder Analysis 6.3 Stakeholder Ratings 6.4 Stakeholder Priority Analysis 6.5 Contextual Factors 6.5.1 Organisational 6.5.2 Technology 6.5.3 Legal and Ethical 6.5.4 Market 6.5.5 Government 7 Quality Narratives 7.1 Runtime Quality Attributes 7.1.1 Performance 7.1.1.1 User Interface Response Times 7.1.1.2 Reporting Response Times 7.1.2 Usability 7.1.2.1 Errors Made by New Users 7.1.3 Reliability 7.1.3.1 Failure of Routing System 7.1.3.2 Failure of GPS Navigation in Car 7.1.3.3 Response Unit Timeout 7.1.4 Security 7.1.4.1 User Authentication 7.1.4.2 Hijacking the System 7.2 Non-Runtime Quality Attributes 7.2.1 Maintainability 7.2.1.1 Expanding Emergency Response Unit Types 7.2.2 Testability 7.2.2.1 Testing For Bugs 7.2.3 Reusability 7.2.3.1 Implementing Alternative Location Device 7.2.4 Scalability 7.2.4.1 Large Volume of Calls, Operators and Responder Units 8 Conceptual Architecture 8.1 Evaluation of Conceptual Architecture 8.2 Discussion of Components / Responsibilities 8.2.1 Callout Log 8.2.2 Reporter 8.2.3 Reporter UI 8.2.4 Response Unit Details 8.2.5 Emergency Service Centre - Operator GUI 8.2.6 Route Dispatcher 8.2.7 Routing System 8.2.8 Status Listener 8.2.9 Dispatch Listener 8.2.10 Response Unit GUI 8.2.11 Status Messenger 8.2.12 Host Identity 8.2.13 Response Unit Location 8.3 Data models 8.4 Run-time / Life Cycle Events 8.5 Use case map 8.5.1 Use case: Emergency Call 8.5.2 Use case: Response Unit Acknowledgment 8.5.3 Use case: Response Unit Status Update 8.5.4 Use case: Generate Report 9 Execution Architecture 9.1 Concurrency View 9.1.1 Description 9.1.1.1 Client 9.1.1.2 Server 9.2 Deployment View 10 Behavioural Analysis 11 Implementation Architecture 12 Architectural Review 12.1 Key Architectural Decisions 12.2 Architectural Constraints 12.3 Critique of Architectural Design 13 Conclusion 14 Anticipated Issues 15 Definitions 16 Acronyms 17 References 18 Links 19 Appendix 19.1 Initial Execution Architecture 19.2 Database Design 19.2.1 Preliminary 19.2.2 Images from Group Discussion 19.3 Presentation Slides

Overview

The software architecture document aims to provide a high level component based design documentation. The document will outline components based on stakeholder needs, thereby giving a contextual understanding of the system and reasonings behind the system architecture. Stakeholder needs will be represented by a set of usage and quality narratives, which will be used to demonstrate the architecture.

Purpose

The purpose of the Emergency Response System (ERS) is to enhance the response time of emergency service providers and manage the presentity of emergency service units. The system will be designed so that it can suggest candidate response units to the service provider based on their location and status. A routing component which can generate a route between two endpoints has been implemented and it to be used within the project.

Responsibilities of the System

1. The system is expected to work continuously (i.e. 24/7)
2. The system must allow details of an emergency to be entered
3. The system must allow an operator to route a nominated response unit to an emergency
4. The system must cater for a wide variety of response unit types (ie. Fire, Police, Ambulance, etc.)
5. The system must know where all vehicles are at any point in time, that is track vehicle presentity in real time
6. The system must allow a vehicle to be added or removed from the system
7. The system must allow a vehicle to be suspended for maintenance or other reason
8. The system will be able to report on a given vehicles movements over a set period of time(Day, Week, Month)
9. The system must produce reports based on the presentity of the emergency service units.
10. The system should be able to report movements of a specific vehicle over a period or on a specific occasion
11. The system should be able to report activity from a nominated dispatch centre
12. The system should be able to report activity to a nominated region

Scope

The scope of the project is to deliver a prototype to prove the functionality of the software architecture. The range of functionality that must be delivered is listed in the Responsibilities of the System section above.

The project is not responsible for the creation of the Routing System nor the hardware implementation of the location determination system and tracking module.

Assumptions

1. The "magic" routing system can accept either a civic location or geodetic co-ordinates
2. The responder units will have the necessary equipment to run client side software
3. Location determination is outside of the scope of the system, this presents itself as an external interface of the system.
4. Found locations from location determination are considered to be accurate and reliable, thus do not need verification from secondary sources.

Stakeholders

Primary Stakeholders

• Responders:
  • Fire Department
  • Hospitals (Ambulance)
  • Police Departments
  • SES
  • Water Police

• Operators

• Administrators

• Victims

• Developers

Secondary Stakeholders

• Road authority - When a route is identified, traffic may be diverted/stopped and therefore signal prioritisation affected [evolved in conjunction with ERS]

• State Government - Most likely to raise capital to invest in the ERS

• IT - Maintenance - Capability to backup large data and maintain system

• Equipment Manufacturer - Possible changes to existing system and upgrades to Human-Machine Interface if it is incapable of handling new duties

Stakeholder Personas

Responder

Jimmy Wilcox is a highway patrol men of the Georgetown area command and is frequently sent to investigate vehicular incidents by the regions Emergency Call Centre. Currently the method of being dispatched to these incidents is through CB radio, where an Emergency Call Centre operator radios Jimmy to go to an incident. However, Jimmy frequently receives requests to attend to incidents when he is already attending to an incident costing him valuable time explaining his is not free to go to another incident. He is supportive of the Emergency Response System if it sets his status to busy when he is attending to another incident and will not be called again to go to another incident until the current incident is resolved.

Management

Tom Greene is the Deputy Chief of Police at the local police station. He is having a look through the statistics of his response units and is worried about the time taken to get to the scene of an incident (where an incident can be a crime or some other police community duty) and the variability of the amount of incidents units are attending to. He sees response times are quite large and a small number of units are attending to the majority of incidents. This must be improved to please the Chief. Upon hearing of plans to implement a new emergency response system, he is supportive and wants see it implemented in the hope that when it is fully operational, it will reduce these response times and make attending to incidents equitable among his response units.

Operators

Natalie Wood is an operator in a Emergency Call Centre. She receives calls for emergency and needs to be able to determine the location of the responder units near the scene of the emergency so the emergency can be attended to in the shortest possible time. Once she finds the nearest responder she needs to dispatch it and receive confirmation that is on route the notify the emergency caller that help is on the way. This must done in minimal time, as most often people's lives are at stake.

Administrators

Paul Bigge is assigned as the system administrator. He is an experienced emergency centre operator and has been given the task of compiling weekly reports on the operation of the Emergency Centre and response times of its staff and of the actual responder units themselves. Every Friday he logs into the system using his elevated credentials and is able to compile the length of all operator calls and the length of time taken for a responder unit to reach its target. He is able to print these figures as a presentable report and give it to the Emergency Centre Manager, so he can see the average performance of his centre and his employees.

Victims

George Blewett is an office worker in the CBD. He is completely unaware of the development of the new system, other than from negative reports in the media about how much the system is costing taxpayers. Naturally he is a skeptic as well, having never used any emergency service. He is under the impression that the current system is adequate. After the new system is implemented, he is involved in a freak accident which leaves him having no other option but to call 000 for help. A responder unit is despatched and arrives within 10 minutes. Unbeknownst to him, having used the old system the waiting time could well have been doubled.

Developers

Duncan Devby is the CEO of Quikenup Designs and Development. The State Government has requested designs for a new Emergency Response System and he would like for his company to win the contract. He assigns all his senior engineers on the project and eventually wins the contract to build this system, based on the company’s conceptual designs. John Cando is the most senior of the software engineers and is instrumental to the development of the system based on current designs. He is now given the task of overseeing the creation of the system and must deliver within monetary and time constraints, given that the media is already reporting on the excessive costs of the system and that the state election is due to happen within the timeframe of the project.

Stakeholder Analysis

Identity	Operator
Characteristics	Computer Literate Aware of emergency response methods and responsibilities
Nature of Interest	Dispatch vehicles to incident points Record activity on incidents Change vehicle status Improve Response Efficiency Reduced overhead in reporting
Benefits to Stakeholder	Ease of use in dispatching required help to location Recorded logs of all activities to avoid liability Reduced response time to critical emergencies

Identity	Responder
Characteristics	Can manually set status Has automated equipment for determining location (e.g GPS) Aware of emergency response procedures
Nature of Interest	Getting viable information about incident Getting valid directions to point of incidence Displaying emergency requests automatically and allow these to be accepted or declined in the emergency can be serviced
Benefits to stakeholder	Improved response time to incidents More reliable information about incident Able to update current location and status remotely and automatically

Identity	Management
Characteristics	Computer Literate Aware of emergency response methods and responsibilities Has control over the responders area of responsibility (that is where a responder patrols)
Nature of Interest	Checking the reports of responder activity for a given time period Checking the reports of activity of particular areas within his command region
Benefits to Stakeholder	Real time updating of a responders movements Traceability, integrating an operators call out logs and matching these with the responders movements Being able to determine if certain areas within the Emergency Call Centre region are unmanned or over saturated with responders

Identity	Administrators
Characteristics	Able to create issues with implementation of system due to managerial ties Requirements for monitoring activity within system Not necessarily computer literate
Nature of Interest	Need for reliable information about response times to incidents Monitor current activity in region Monitor vehicle availability in region Notification of Failures Audit logged information
Benefits to stakeholder	Able to get more information about the workload and abilities of the region's response units Easy tracking of progress of an incident Reporting on activities on different aspects of the units operating in the area

Identity	Victim
Characteristics	In need of emergency assistance Desperate for help and expects rescue in shortest possible time
Nature of Interest	Possibly for needing life saving assistance given by emergency responders Requires assistance immediately
Benefits to stakeholder	Fast dispatch of closest vehicles Most appropriate vehicle(s) are/is dispatched Logging of incident in the event of a mistake or problem with the response

Identity	Developers
Characteristics	Unaware of emergency service provider procedures/responsibilities
Nature of Interest	Want to provide the best system possible for good brand image Requirements given by requesters that they must abide by
Benefits to stakeholder	Profit made from completing the project Possible future development of the existing system if there is approval from client Expansion of client base to more people due to awareness of an excellent implementation of the ERS

Stakeholder Ratings

Stakeholder	Ability to Promote	Ability to Impede	Comments
Responders[Rescue workers]	4	3	Responders are a key component in the system and a user of the GUI Therefore they can promote and/or impede the system due to direct involvement
Management	5	4	They are the main driver of the reporting functionality and may have the most strict requirements of system performance (how accurate are the responder tracking reports) and reliability (can the system fail and make the Emergency Service providers liable to financial compensation Therefore they can promote and/or impede the system due to direct involvement and make the final decisions for the Emergency Service providers, if they choose to implement the system or stay with existing methods
Emergency Service Center Operators	4	3	Another of the key components in the system They are the main users of the primary interface and therefore may have a large role in defining whether the interface is usable or not
Administrators	5	5	High ability to impede depending on the level of the administrator They may not be directly requesting the development, but their ability to impede is high due to their responsibilities as manager of a station
Victims	0	0	Very low ability to either promote or impede, as they may not even be aware of the system They do however get a large advantage from its implementation
System Developers	2	4	Possibly have a large ability to impede due to their responsibilities in creating the system Low ability to promote the system
Roads and Traffic Authority	5	4	They support the traffic system which is frequently affected by emergency services while responders are navigating through the roads in busy times. So, they have a major stake in keeping Roads safe while a response unit is rushing to the point of incident. They can impede the system's development if system doesn't address the issues related to roads traffic regulation requirements
Local Suburban Councils	4	5	Councils highly likely to promote the system for support in services to its residents and local businesses. They have high ability to impede the system as they regulate land developments and housing in the suburbs, which means system database(maps) should be regularly updated if road blocks happen or other changes to landscape occurs.
IT maintenance	3	1	These are the guys responsible for troubleshooting the system for any malfunctioning or upgrades. They can promote the system as it creates job opportunities, yet impedance from these would be a relatively low.
Equipment Manufacturers	4	0	These guys would promote the system due to work opportunities on large scale and growth of manufacturing sector in local economy. no impedance would be expected from these sources
State Police	4	3	They would promote the system due to benefits in being provided clear information at a glance and improve efficiency. They have ability to impede system development if the system does not complement existing technology and burden them with another device to fiddle with.[may prefer radio module to a screen at times]
Network service providers	4	3	They would promote the device due increased engagement with Government and are likely to benefit from the venture by gaining reputation/recognition. They have ability to impede system if the regulators impose conditions on network services.

Stakeholder Priority Analysis

The stakeholders have been allocated 20 points each which are split across all the quality attributes. The higher the number, the higher the priority of the attribute for the stakeholder.

Identity	Availability	Modifiability	Performance	Security	Testability	Usability	Reliability	Scalability
Responder	3	0	4	2	0	3	4	4
Management	2	2	4	4	1	2	4	5
Operator	3	0	5	1	0	3	4	4
Victim	2	0	8	0	0	0	8	2
Developer	1	4	3	2	5	3	0	6
Administrator	1	1	3	4	4	1	5	4
Totals	12	7	27	13	10	12	25	23

As evident from the table, the two key attributes are Performance and Reliability, with Scalability being the third most important.

Contextual Factors

Organisational

Constraints - The system will be operational over a large number of departments which could include Police, Fire, Ambulance, State Emergency Service, Water Police, Traffic Patrol and Accident Response. Compiling data and creating a backbone between all departments could be a problem. Communication between departments could also be restricted due to inter-department protocols.

Enablers - All the mentioned departments are linked someway or another to the State Government, who would want the system to be as interoperable as possible and functioning to its full potential.

Risk - Even though all departments share a common goal, each has individual needs and wants. Each has people with vast differences in experience and creating a system to satisfy all those needs could pose a problem.

Technology

Constraints - Current technology allows for us to only use GPS as a location and tracking system. Using this technology, there are problems when used in cities and in the CBD (urban canyons) where bouncing of the signal occurs, causing erroneous locations showing up in the GPS system. Given the scope of the system (Statewide), they have no control over international needs, such as new satellites etc.

Enablers - System will need to be accessed by many users, which means there is a possibility for future revisions that could allow for remote logins of operators, depending on technology available.

Risk - Largest risk is the rate at which technology becomes obsolete. Investors will be putting a large amount of money into this system and they would like to make sure that it does not become outdated quickly.

Legal and Ethical

Constraints - The system will be dealing with a large amount of sensitive personal data. The general public does not want this information falling into the wrong hands and therefore each separate department is only on a need to know basis for this information. This could affect the performance of the system, as it would be helpful if the information were available to all parties involved. It would reduce misunderstandings and clear up confusion. Another constraint is that all log files must be kept on record for special requests like criminal investigations. This information is not likely to be shared freely and must be strongly secured.

Enablers - The fact that each event must be logged makes it easy for the manager of the centre to determine the worst and best operators. Thus, being able to act accordingly by giving good operators pay rises and firing poor performing ones, making the centre and the ERS more effective.

Risks - The ERS is a life-critical system, thus all actions must be logged to ensure the system performs correctly in case a victim is injured or died as a result of a system error. This may leave the ERS operators and developers liable for prosecution by the victim and/or their family/carers.

Market

Constraints - Having no competition after the initial contract phase could lead to the developers creating a sloppy and below par system, as they know that they are locked in and there is no one for the investors to turn to once complete.

Enablers - Initially, the contract would go to the best and most feasible design, which ensures that all companies interested in the job will provide the best plans for the development of the system.

Risks - There is not a large demand for a system like this, as each occurrence around the world would be unique and require a unique solution. Due to this, it is more likely that something could go wrong in its initial stages of operation while unknown errors and bugs are removed.

Government

Constraints - As usual with all Government departments, it is likely that they will refuse to cooperate with one another and give the developers the run around, especially if they are to see it to benefit them, which could delay development. To add to this, there are a number of government protocols, as well as data keeping and auditing which could get in the way of development.

Enablers - Seeing that the initial need for the system has come from the State Government, and that they are the biggest stakeholder in terms of monetary investment, they will ensure that the system is developed to exceed expectation.

Risks - From the Governmental perspective, this system may not work as originally intended and could be detrimental to the public's opinion of them. As a consequence, they run the risk of becoming unpopular and worst case scenario, losing at the next election.

Quality Narratives

Runtime Quality Attributes

Performance

User Interface Response Times

Roger answers a call from an irate person requesting a police officer at their house due to a fight. Roger, who already has the GUI open, enters in the address (123 Fake St, Ultimo, NSW, 2000) and enters in the code that describes the situation of domestic dispute (1015). The GUI stores the data into the database immediately after Roger has confirmed it and the system then retrieves a list of available units in the region from the database and displays them on screen in less than a second. Roger then selects the unit to be sent out (Police). The GUI then shows a map of the incident location and the available units in the area. He then selects that unit (23) and requests a dispatch of that particular unit to the location. Fred, who is in unit 23, receives the request and the information is sent to his GUI in the patrol car within 2 seconds of the ERS operator ending the sequence of selecting the units. Fred must send an acknowledgement before 10 seconds, otherwise the request will be passed to another responder. He does so within the time frame and begins driving to the incident.

Reporting Response Times

Natalie, an operator, would like to know about a certain emergency call made 2 weeks ago as she has been questioned about her ability by her manager. She has the incident ID, so she enters the incident reporting page and enters the ID (84). Within 2 seconds, the results from her search are displayed on her screen. These results include the address, GPS location, description and time stamp.

Usability

Errors Made by New Users

Natalie, the new operator, is on her first shift after going through the training procedures and manual of the system. She receives her first phone call. George is on the other end and is calling because he has noticed that there is large amount of smoke coming from the bushland down the road from his house. Natalie begins to start a dispatch request and asks for his details. She enters them in the form on the dispatch screen and immediately tries to progress to the next screen to dispatch. She is told by the system that she has forgotten to select an available unit to dispatch. She then selects a unit (Fire) and progresses to the next screen, the unit acknowledges positively to the request and the route to the point of incidence is displayed on the unit's display.

Reliability

Failure of Routing System

George is at home asleep at 4am in the morning when he hears the sound of his front door opening downstairs. Without hesitation, he rings 000 and gets routed to an operator. He quickly states that there is an intruder in his house and gives the address of the house (123 Fake St) to the operator Natalie. Natalie attempts to enter the incident and location into the system but soon finds out that the routing system has gone down and is unable to return any results. Fortunately she can still see the location of available units and can locate the street manually using the Operator GUI. She determines the closest available unit herself and manually sends a request by clicking on the unit. Tom, who is the police officer on the graveyard shift, sees the request and answers it immediately. Natalie can then guide Tom to the location over CB radio, using her own determined shortest route from the map on the Operator GUI. While she is talking to Tom, she is unable to answer any incoming calls, thus reducing the effectiveness of the emergency centre. Tom eventually makes it to the scene of the crime in progress and his sirens are able to scare off the thief before he made it upstairs to a confrontation with George.

Failure of GPS Navigation in Car

Brett is a police officer on duty and is just arriving at the Police Station. He receives a request on his machine about a riot taking place outside 123 Fake St. Reluctantly, he acknowledges the request and is immediately on his way, following the directions on the screen as he is unfamiliar with that district. Without warning, the machine shuts down and he is unable to restart it. Thinking quickly he uses his CB radio to ask for some directions from any other police officers who are also on the way to the point of incidence, and also notifies the emergency centre that he has lost communication with the ERS. Natalie, who is a free operator, picks up the call for help from Brett and is able to pull up his emergency details and guide him using the map on screen, communicating via CB radio. Brett eventually arrives on scene and controls the situation before it gets out of hand.

Response Unit Timeout

Fred takes a call from an irate citizen and needs to dispatch a police unit to their location. He selects unit 5 to respond and after he has sent a request for dispatch to the unit he is taken to the confirmation page. After 10 seconds he can see that unit 5 has not acknowledged the request that he sent out. He assumes that unit 5 must be unable to respond to the situation for an unknown reason, and decides to request to dispatch an alternative unit. He selects the option 'Dispatch Additional Units' and selects unit 17 to send to the incident. He proceeds to the confirmation page and sees that unit 17 has acknowledged the request.

Security

User Authentication

Natalie the new ERS operator tries to use an ERS terminal for the first time. The system is currently on standby mode and Natalie moves the mouse to wake the system up. The system is not currently logged in and displays a login dialog, prompting her to enter her username and password. As part of her induction Natalie was given a username and password and she enters these to the system. The system detects that Natalie is a new user and prompts her to change her password. Natalie enters a password that she is comfortable with and is logged into the system. She now sees the ERS GUI that she is familiar with in her training and can begin answering emergency calls.

Hijacking the System

Hugh Davis is a computer literate career criminal. He plans to steal money from a local bank and thinks he can buy himself some time in the robbery by fooling the Emergency Response System to think he is the closet police responder. He hopes he will be routed to the robbery instead of an actual police unit, thus increasing his getaway time as he hopes that by the time someone realises that no police unit has been sent to the robbery he will be long gone. He has a stolen copy of the responder program and tries to authenticate himself with the Emergency Response System entering a random identification token. The system recognises the identification token is not valid and refuses to accept the status and location of the stolen responder program. Thus integrity of the system is maintained with only valid responders updating their status and location and being routed to incidents.

Non-Runtime Quality Attributes

Maintainability

Expanding Emergency Response Unit Types

Previously the Georgian Emergency Service region delegated medical emergencies to the fire department. The Georgian region has decided to implement a dedicated ambulance service to deal with medical emergencies and Peter the administrator needs to update the Emergency Response System to contain a new class of responder. He knows the responder class information mapping is kept in the database. He connects to the database and creates an new 'Ambulance' class in the responder table and maps the medical emergency codes to request an 'Ambulance' class responder. Next time Bridgette the call centre operator requests a responder for a medical emergency code, an ambulance is dispatched to the emergency, not a fire engine.

Testability

Testing For Bugs

Peter is the system administrator of the ERS. He has received a number of complaints from the operators that the system locks up at a certain point when dispatching units. Peter logs into the system and enables debug mode, which allows the system to print on screen and log all events and processes that are going on behind the GUI. He soon finds out that there is a system IO error occurring at that point, and can refer this to the developers as a bug which needs to be fixed.

Reusability

Implementing Alternative Location Device

The Waverley Emergency Service region has seen the example of the Georgian Emergency Service region which uses the Emergency Response System and want to implement the same system in their service region. The Waverley region has made a significant investment into uplink time difference to arrival (U-TDOA) location determination for each of their responder units. This system is incompatible with the GPS system used by Georgia but hope most of the responder client code can be reused and integrated with their location determination system. They find the responder client has a well defined interface for location determination and can integrate their U-TDOA system with the Emergency Response System, thus implement the system will minimal effort.

Scalability

Large Volume of Calls, Operators and Responder Units

Peter is the manager at the Emergency Call Centre on duty on New Year's Eve. Suddenly, violence erupts on Sydney Harbour where a big group of hooligans have started throwing beer bottles at the spectators who have come to watch the midnight fireworks. There are 510 operators on floor which get tied up with the calls from people on the Harbour. While Peter is busy creating service requests, 170 additional calls after the first 510 are queued up and logs indicate that calls from within the city for rescue services are being made. Peter can either decide to refer these extra calls to a nearby region or let the operators take care of successive calls from the queue, in a first in first out manner, once they are done with the previous calls. He opts for the latter. Each call requires a dispatch of an emergency unit. There are 150 police units and 110 ambulances within the CBD, all of which are ready to receive requests for dispatch. All the operators on the floor are able to request the use of these units simultaneously until each and every one has been dispatched, as some events require both police and ambulance. After this, subsequent calls can be relayed to the nearest region centre, or be placed in a queue of responders, in a first in first out basis. This is up to the operator's digression and will depend on the urgency of the call. Despite the large volumes of calls, operators and responders, it should not affect system performance.

Conceptual Architecture

Initial Conceptual Architecture

Elaborated Conceptual Architecture

Server-side view

Client-side view

Evaluation of Conceptual Architecture

The conceptual architecture shows the Emergency Response System in terms of blocks that perform domain level responsibilities. Key points of the above shown conceptual architecture which impact the desired quality attributes (performance, reliability and scalability) are:

• Multiplicity is shown for the Emergency Service Centre - Operator GUI. This is to allow the system to scale to multiple operators. That is to have multiple instances of the operator interface to allow the system to cater for multiple operators at the Emergency Service Centre. The same rationale is used for the Report GUI, to allow multiple people to concurrently view system reports.
• There is only one Callout Log and Response Unit Details databases. This negatively impacts reliability as their are single points of failure in the system. The trade-off discussed was with performance and scalability, where having multiple databases and synchronising these would negatively affected these two quality attributes.
• There is multiplicity shown in the Server-Side view for the response unit so the system can scale to multiple responding units.
• The Status Messenger component in the responder (client-side) is used to update the Emergency Service Centre (ESC, server-side) with its current status and location so they system can reliably determine which units are ready to be routed. Performance is not degraded because units with temporally stale statuses are not contacted by system from emergency dispatches.
• For reliability, dispatches are handled in a two part process:
  
  - The dispatch request is sent from the ESC to the responder.
  - As soon as the responder receives the request an acknowledgement is sent to the ESC to notify the ESC the responder is active.
  
  This quickly notifies the operator (time is dependent on network) on the status of the dispatch and if no acknowledgement is received a dispatch can be sent to a different unit. Performance of the system is not degraded by the system waiting for responders replying to an emergency dispatch (i.e. accepting or rejecting requests). The sytem is more usable as the operator gets quick feedback on the state of dispatches.
• Modifiability of the system is increased by having external interfaces for responder location and host identity, as these will not be consistent for different responder types. For example a police vehicular unit would most likely use GPS for location determination, while a transit officer would use cellular location because GPS would not be effective in subways.

Discussion of Components / Responsibilities

Callout Log

The Callout Log is where the details of every incident is stored. It provides information on which units were dispatched, who dispatched them and any other special information.

Responsibility	Description
Store information	The callout log must accept information passed to it from the operator UI to store.
Supply Information	The callout log supplies information to the 'Reporter' component to allow it to generate reports.

Reporter

The Reporter is designed to take information from the callout log and responder unit details databases, correlate the related fields and provide it to the user in the form of useful reports. For example the displaying all the emergency dispatches for a set region.

Responsibility	Description
Accept information	The reporter must accept information from both the Response Unit Details and Callout Log and form the reports the user requests using the data
Provide reports	The reporter must use the information that it acquires from the user to retrieve matching information from the database and generate the applicable report that the user requested. It must then pass this report to the UI.

Reporter UI

The Reporter UI takes the semantic information generated by the reporter component and applies presentation styles and templates to display it to user.

Responsibility	Description
Accept Request	The reporter must accept a request from the user and pass this request onto the reporter
Display report	The UI must apply styles to the report to display it from the information received from the reporter. Different styles include lists, tables or graphs.

Response Unit Details

Response Unit Details is where the data of each response unit is stored. It contains availability and locations of vehicles, and must provide this information the the Operator and the Report User.

Responsibility	Description
Request Data	The Response Unit Details component must accept a reqeust from the UI and obtain the relevant information from the database
Return Data	The Response Unit Details component must relay the available unit information back to the UI

Emergency Service Centre - Operator GUI

This is the Operators main view of the system. It allows them to initiate incident dispatches, record details of an incident and show the unit's acknowledgement of a dispatch.

Responsibility	Description
Create Incident	The UI must accept the input of the user and create an incident based on this data. This means accepting and storing address details, names, and actions taken in the database.
Show Units	The UI displays all available Responder units whose status is 'Ready' (ie. available to take a call) and are nearest to point of Incident.
Begin Dispatch	The UI captures the Operator's finalised requests for response units, which is sent to the Route Dispatcher interface for Transmission.
Display Acknowledgement	The UI must display the vehicles acceptance of an incident callout

Route Dispatcher

The Route Dispatcher is the main contact between both UI's. It accepts incident location details, provides these to the Routing System, and then passes the final route to the Dispatch Listener.

Responsibility	Description
Request Route	The Route Dispachter sents response units ID to be processed by Routing System for a current GPS location and formulation of shortest feasible path to the incident location. The format is defined in the data model.
Dispatch Unit	The Route Dispatcher processes (compiles a data packet with location, route and incident description) the request made by the operator to be transmitted to the selected response unit. The format is defined in the data model.

Routing System

The Routing System is an existing component which must accept inputs from the Route Dispatcher and return it the final route.

Responsibility	Description
Accept Route Request	The routing system processes a request with the response unit's current GPS location and the point of incident location. It then compares this with its valid GPS locations to acknowledge valid inputs.
Provide Route	The Routing System works out the shortest possible route to the incident location from its GPS maps & smart algorithmic technique, then outputs a series of navigation steps to the dispatcher in plain text.

Status Listener

The Status Listener waits for a status update from a response vehicle. It then stores the details in the Response Unit Details data storage.

Responsibility	Description
Accept Status Change	The Status Listener must accept any responder status change. The information is received using a custom format as defined in the data models. Verifies for known status: Ready/Not-Ready/on-Route/At-Station/Busy
Store Status	The Status Listener sends a request packet (to persistent data in response unit details) with changes/updates to the response unit's change in either GPS location or Personnel's status. The status update is performed every time the response unit status changes. This status is sent as a query that can be executed by the database.

Dispatch Listener

The Dispatch Listener waits for a dispatch request from the Route Dispatcher, and then passes the information on to the Resposne Unit UI.

Responsibility	Description
Accept Dispatch Information	The dispatch listener listens on a port for transmitted requests and verfies incoming request packets from the Route Dispatacher. It then translates the Data packet into its component parts of navigation steps and description of incident.
Pass Dispatch Information	Formats the Data packet into navigation steps and description about incident. The formatted data is then passed to the reponse unit's GUI for display of requests.

Response Unit GUI

The Response Unit GUI is the main window for the Responder to the system. It displays dispatch requests to the user, as well as accepts status changes of the vehicle and passes them to the Status Messenger.

Responsibility	Description
Display Dispatch Description	The GUI displays - options to the Response unit on status, Incident Information, Navigation Steps to incident and Accept/Deny option on received dispatches.
Acknowledge/Deny Dispatch	Captures Responders' Selection of Acceptance/Denial of Request and sends a simple acknowledgement to Dispatch Listener which communicates the message via route Dispatcher to be displayed on Operator GUI
Change Vehicle Status	The user must be able to change his vehicle status, and the UI must then pass this change onto the Status Messenger

Status Messenger

The Status Messenger accepts inputs from the UI, Response Unit Location and Host Identity components and passes them to the Status Listener to be stored in the database.

Responsibility	Description
Accept Input - Real Time Status Monitoring	Status Messenger Compiles current GPS location, Responder Personnel's status and Status Messenger's (IP) into a data packet to be transmitted to Status Listener.
Send Vehicle Status	The status packet compiled is transmitted(sent) to the status Listener periodically or when requested or on update of status by Response unit.

Host Identity

The Host Identity is simply to provide the IP of the vehicle to the Status Messenger.

Responsibility	Description
Provide Contact Address	The Host Identity must provide the vehicle's contact address to the Status Messenger (IP)

Response Unit Location

The Response Unit Location is an interface between the GPS device and the Status Messenger.

Responsibility	Description
Accept Input	Periodically Reads GPS Location(coordinates/street address) from Device on Response unit and forms a status packet to be sent to status messenger.
Provide Vehicle Location	Maintains a current GPS Location to be sent when requested by status messenger

Data models

The ERS is very sequential in its behaviour and one communication link is preceded by another. Therefore the data model is first presented part by part and a final combined data model is shown to give a better understanding of how and what data flows through the system.

This data model shows the interaction between the Operator GUI component and the Database. This branch of communication starts from an emergency, it is up to the human operator using the Operator GUI to determine the location and responderType (e.g. ambulance, fire trucks, etc.) to send. The operator would send a query to the database for responders of a certain type and location, the database processes this query and returns the AvailableResponders.

This data model shows the interaction between the Operator GUI component and the RouteDispatcher. This branch of communication begins once an operator knows the responder identity and location to send the request to. The information contained in RouteRequest is required to determine a unique responder and a route for that responder to get to the point of incident. Thus the operator creates an information packet that is sent to the RouteDispatcher. The behaviour of the route dispatcher is expanded on the next data model.

This data model shows the interaction between the RouteDispatcher and the RoutingSystem. This branch of communication begins once a RouteDispatcher has received a RouteRequest; the RouteRequest is stripped of the responderIdentity and incidentDescription. Thus two endpoints are sent to the RoutingSystem, and it will return a route between those two points (the responder location and incident location). The responderIdentity and incidentDescription is stored and is used to send the DispatchRequest described in the next data model.

This data model shows the interaction between the RouteDispatcher component and the Responder. After retrieving the route from the RoutingSystem the RouteDispatcher simply transmits the route and the description of the incident to the Responder. The dispatcher knows the address of the responder to send to due to the responderIdentity which it received from the Operator GUI. It is up to the user on the Responder GUI to acknowledge this dispatch, change his status and perform whatever duty is required by the dispatch.

This data model shows the interaction associated with the responderStatus. The ResponderStatus is the presentity of a responder, i.e. it describes the location, identity and status of the responder. These information are generated by the ResponderGUI, hardware and a GPS unit. The information is collated into a ResponderStatus packet and is sent to the Database to be segregated and saved.

The data model shows the interaction of different components in the system.

The data model shows the persistent storage of the data generated by the system.

Run-time / Life Cycle Events

Use case map

The following use-case maps displays a typical use of the ERS, along with the use-case map is a set of narratives to give a stakeholder's view of the system and how it all fits together.

Use case: Emergency Call

George - Victim

George has just been involved in a car accident where the drive of the other vehicle has driven off illegally. He places a call to 000 that gets routed to an operator. He requests that an ambulance be dispatched to his location and provides the street address as to where he is located (123 Four St.).

Natalie - Operator

Natalie is an operator at the 000 call center. She receives a call from a victim named George who requires an ambulance to his location (123 Four St.). She takes the persons location down and enters it into the system, along with the type of vehicle requested (ambulance). The program then shows her a map with the location of the incident, as well as the nearest available ambulances that are able to take the call. She chooses the most appropriate responder to attend to the situation, and the program calculates the best route to use for the vehicle to arrive at the scene. The program sends this information to the responder so that they can begin the journey to the scene. Natalie waits for an acknowledgement from the ambulance driver, to ensure that the route has been received and that a unit is en-route.

This map shows the path through the conceptual architechture to point out missing components or responsibilities. The operator enters the details about victim's location on the Operator GUI and expects a list of responders available to be shown on a geographical map. The routing system supplies the route to the victim's location. The route dispatcher transmits the selected route to the selected responder's dispatch listener. The responder sees a request on the GUI to Accept/Deny the service request.

Observations: If simultaneous calls are made to the same responder queing supports the reliability. Also, making different components handle dispatching and listening requests enforces reliability and performance by appropriate synchronization.

Use case: Response Unit Acknowledgment

Fred - Responder

Fred is an ambulance driver, who has just been called to the scene of an accident. On his in car UI (User Interface), he receives a map of the incident location as well as a list of directions as to how to get there. He accepts the emergency and sends an acknowledgment to headquarters.

This map shows acceptence of a call by responder to a victim location and updating the database for change of responder status. The confirmation is sent out to operator(in database) and dispatch queue gets terminated.

Observation: Seperate databases enfor reliability and allow for better performance.

Use case: Response Unit Status Update

Fred - Responder

After sending the acknowledgment to headquarters, Fred changes his status to 'en-route'. Meanwhile the system uses GPS to continually update his location to HQ so they make track his movements if necessary. He travels to the scene and attends and when he arrives he switches his status to 'attending incident'. Once he has completed the call, he changes his status from 'attending incident' to 'available' through the UI inside his ambulance. He can now go back to his patrol and wait for another call.

Use case: Generate Report

Peter - Administrator

The victim of a crime has made a formal complaint to the fire department regarding the sloppy nature of the call he made to request a fire truck. He is not happy with the time it took for the truck to reach his location, and so a formal investigation must be made. Peter, an administrator logs onto the system and searches up the specific incident that the victim was involved in. The UI displays all events that happened regarding that call-out, including a log of the exact time that any event occurred. These events include the initial receiving of the call, followed by the vehicle being dispatched, as well as whatever status changes the driver made. This shows the administrator exactly what events occurred and the exact time stamp of when they occurred, and can decide on whether or not any mis-handling of the event has occurred.

Joey - Administrator

Joey is an administrator at a fire station in an inner city suburb. He needs to pull up reports as to the efficiency of his crew. He starts with a region based report, finding out all of the call-outs that occurred in his region. He then checks this against all of the call-outs that came from his station. Seeing the discrepancy, he then moves onto a vehicle based report to find a list of all incidents that the vehicles attended to. With this information, he can tell which vehicles have made a sub-average amount of call-outs and try to rectify the problem via whatever means is necessary.

Execution Architecture

Concurrency View

Description

The execution architecture shows the system in terms of its runtime structure. The concurrency view explores the system in terms of processes and threads. The following section lists each of these components and describes them in terms of how they map to execution view stereotypes. Note: a further division is made of the 'system' into client and server, where client is run by the responder (multiple) and server is the emergency service center (singular).

Client

• Responder GUI - The Responder GUI is the graphical interface for the Responder. The GUI displays dispatch information and may be used to update the status of the Responder. The GUI can send an integer, which denotes a certain status, to the Status component. It can also receive a dispatch package which contains a picture to the area of incidence and a description of the incident. Both of these pieces of information will be extracted from the package and displayed in a Frame and a list box respectively.

• Status - This is an active component that updates the Emergency Service Centre (ESC) with the location, status and identity information of the responder at a set interval. The location and identity are updated by an external GPS and hardware module and the status is updated by the Responder GUI operator. This information is encapsulated into an XML schema and forwarded to the Status listener on the ESC.

Conceptually the Status component integrates the functions of Host Identity, Response Unit Location, Status Messenger. The three components receive updates from an external source (i.e. the operator, a GPS unit or Responder hardware). Thus, from a concurrent perspective the components could be integrated to a single component which concatenates these information and forwards it to the Status Listener.

• Dispatch Listener - This is an active component that listens to requests from the ESC for the responder to be routed to an emergency. There are multiple instances of the dispatch listener to allow multiple requests to be interpreted and queued before a request is accepted. The dispatch listener checks the integrity of the received dispatch and if the packet appears intact it forwards it to the Responder GUI.

Server

• Web Interface - this component displays an interface for emergency calls to be serviced and reports to be generated, thus it is a user-initiated component. The Web Interface communicates in http and serves jsp pages. Clients may use the Report page to send SQL queries to the database, the database response is formatted and displayed on the jsp pages. The Operator page similarly sends SQL queries and formats the input, but may also send out a dispatch request. A dispatch request contains 4 information: a target responder, location of said responder, destination of said responder and a description of the dispatch.

Conceptually the Operator and Reporter GUI has been integrated as they both function from the same server.

• Database Logic - this component manages database interaction with the GUIs. This component is a service component, allowing asynchronous requests from the GUIs. The component communicates asynchronously to the Database component, this allows the component to continually service other requests as the Database read/write take place.

Conceptually the Database Logic component is a combination of Callout Log, Response Unit Details and Responder. All three components perform either entry or retrieval of data from the database. Thus, from a concurrent perspective the components could be integrated to a single service which communicates to the database.

• Database - this component is a data store service, which store past and present responder and incident data. The database receives SQL queries from the database logic component and performs database storage and retrieval. The current architecture defines this as a single component which may affect the scalability quality attribute, since they system is singular to one ESC.

Conceptually the Database component performs the persistent storage of the Callout Log and Response Unit Details.

• Status listener - this is an active component which listens for updates of responder clients status and location. The details of the update are send to the database logic component to persistently store. There are multiple concurrent instances of this component to allow multiple responder clients to update their location and statuses. The status listener takes in a status package, which contains three pieces of information: current status of a responder, location of responder in GPS coordinates and identity information of the responder (IP and port). This information is segregated and queries are made to the Database to save the information.

• Dispatcher - this is an active component takes in a dispatch request. It segregates the information and sends the routing system the position of the responder and its destination. The Dispatcher waits for the routing system, and receives a route (image). The route and dispatch request is forwarded to the target responder. There are multiple instances of this component to service multiple emergency call requests.

• Routing system - this is a service component which finds a route between a start point and an end point (pre-existing component).

Deployment View

Behavioural Analysis

Performance - The architecture aims to provide performance by providing a balanced execution flow. That is components are not overburdened with too many responsibilities. However the execution architecture shows that most of the use cases are dependent on the database. One possible solution is to re factor the database into multiple databases, this will delegate responsibilities more evenly through several databases. However, for the prototype development of the system, the system will maintain a single database.

Reliability - Functionally the system is reliable because an ESC server may serve many clients (Responders). This means if a client is to fall over, there may be other responders which can take its place. However, if the server itself were to fall then the whole system will collapse. A solution to this problem would be multiplicity, that is redundant copies of the database and server is made. So that if the server were to fail then there would be backup systems ready to take its place. Note that this is not a many to many relation, it is still effectively a single server managing many clients. However there are now backup servers which can take over the server if it does fail.

Scalability - Due to the server based architecture of the system, the architecture can support as many operators as long as the hardware permits. That is, a station equipped with a web browser can communicate with the ESC server enabling many operators to use the system. Since the clients also communicates in a similar manner, the system may also support many responders. Ultimately the bottle neck in terms of scalability is the database. Many of our use cases require reading or writing into the database. That is if the database is put under enough stress so that performance is severely debilitated scalability also fails as the system would perform too slowly.

Implementation Architecture

ImplementationArch.jpg

Components

• Apache Tomcat - this is an implementation of Java Servlet and Java Server Pages (JSP). It runs as an application and receives requests through a socket interface and marshals HTTP requests to a servlet instance.
• Servlet - An instance of this is created per request and the HTTP GET and POST map to the doPost and doGet servlet API methods.
• Java Server Pages - contains the Operator GUI interface and is generated dynamically from the JSP templates and the scriplets they contain (Java code that gets run during each call of the JSP page.)
• XML Parsers - parses the XML stream into an object.
• HSQLDB - a relational database written in Java.
• Swing GUI - a client program presenting an graphical user interface with the Swing widget set.

Component Selection Reasonings

• The ERS is implemented in java because it is a stakeholder requirement.
• Components such as the Swing GUI is selected because the software engineers are familiar with it.
• HSQLDB is interchangeable with other SQL databases such as MySQL or SQLite, however due to the Java centric development, HSQLDB (a Java based SQLDB) was chosen.
• Java Server Pages allow application components to communicate using a familiar web browser. This aids usability as operators can easily use a web browser to use the system. It also improves configurability as the pages could be edited and modified as necessary, without affecting the application components.
• The ERS system may need to modify it's communication protocol, for example, stakeholders may want to add more information regarding vehicle status. An XML Parser is used as it provides the system with a robust and configurable communication protocol.

Architectural Review

Key Architectural Decisions

Major architectural decisions for the Emergency Response System were:

• Only one Emergency Service Centre (ESC, the server component) was to be developed so there would be no need to synchronise databases across different database servers. The complexity of this would impede the performance of the system because multiple data sources would not need to be queried, however this would have increased reliability because it would remove a single point of failure of the system (i.e. if the database goes down, the system goes down).

• The communication mechanism for communication between the ESC and the responder clients was to be XML over HTTP. This is a generic technology that is independent of implementation technology and access network. Technologies such as Remote Method Invocation (RMI) were rejected because it constrains the system to Java, which limits scalability because the system would not work on embedded devices.

• It was discussed at which time to make the response unit unavailable at dispatch time. The two options were to set the status as busy as soon as a dispatch was initiated or to set the status as busy at the time the responder accepted the dispatch request. The later option was chosen to increase the performance of the system. The rationale was the responders could all be set as busy even if they were not on-route to a request, thus under utilised.

• The system should provide notification to the operator at regular intervals. This resulted in dispatches being a two step process so the operator was immediately notified the responder received the message, then an acceptance they system would provide another message saying the dispatch was either accepted or declined. This increased the reliability of the system because the operator could receive quick notification a responder did not acknowledge a message, so they could attempt to dispatch a different unit.

Architectural Constraints

In producing and testing the executable prototype, several constraints that our architecture gave became readily apparent. Firstly, there has been minimal consideration of large scale redundancy on the server side. At the moment, the entire system runs off a single database and server for the operator interface. In order for this design to be considered as a practical solution to any emergency operating system environment, we would need to make alterations to the way a client contacts the server to allow for either a distributed load across multiple servers, or alternatively have a backup system that can be activated within seconds that is an exact duplicate of the original server. This way, if there is any problems detected with the system as a whole, we can revert to the backup database and server and there would be minimal if any impact on the system as a whole.

Critique of Architectural Design

The following critiques the architectural design in relation to the three main desired quality attributes:

• Reliability
  • The system has a signal point of failure in the application server and database. This is not desirable for reliability since if either of these components fails the system as a whole fails.
  • The ESC and responder communication messages are always acknowledged so no messages are lost, thus if no acknowledgements are received the message is considered to have failed.
  • The ESC checks if the responder has updated its status within a certain space of time. If the responder does not update its status within this time, it will be set as unavailable.

• Performance
  • The ESC receives status updates from the responders so stale responders are disabled, thus the system will not attempt to dispatch stale units.
  • The ESC and responder communication messages are always acknowledged so this quickly provides notification to the operator on the status of the dispatch.

• Scalability
  • The client queues all requests from the operator, thus all dispatches are received on the responder side, regardless of the number of simultaneous dispatches. This allows the system to scale to multiple operators using the ESC.

Conclusion

Our final architectural design for the ERS system provides a sound basis for an ERS system, however there needs to be further development and refactoring of the design to account for our key quality attributes.

The Operator GUI provides an effective way of dispatching a single unit to a call, however needs to be improved to allow for a single incident requiring many units, as well as many units refusing the request and requiring the dispatcher to alter the requests for vehicles.

The responder side of the program has no major architectural flaws, in that it queues all incoming requests from the operator so that no requests are lost, as well as doing consistent polling to the database to update its current location and status.

Anticipated Issues

• Reliability of the database and application server. These are the single points of failure of the system.
• Creation of the XML protocols between the ESC and responder that have the fidelity of sending all the required information while not being bloated to reduce performance.
• Synchronizing the client queue so no two dispatches are accepted or no dispatch is ignored.
• Ability of the chosen application server and database to handle to load of multiple responder units and using operators.

Definitions

• Point of incident: a location of interest in context of the ERS
• Responder: a user type of the ERS, typically an emergency service unit
• Operator: a user type of the ERS, an intermediate between victim and system, and, ERS and responder.
• Presentity (presence entity): Provides presence information consisting of status and address to a presence service.

Acronyms

• ERS: Emergency Response System
• ESC: Emergency Service Centre
• GPS: Global positioning System
• GUI: Graphical User Interface
• POI: Point of Incidence

References

1. Reekie, J. and McAdam, R. 2006, A Software Architecture Primer, Angophora Press, Sydney.
2. Day, M. Rosenberg, J, and Sugano, H. 2000, A Model for Presence and Instant Messaging, Internet Engineering Task Force, viewed 9th September 2008, <http://tools.ietf.org/html/rfc2778>

Links

• Apache Tomcat - http://tomcat.apache.org/whoweare.html
• Hibernate - http://www.hibernate.org/
• HSQLDB - http://hsqldb.org/

Appendix

Initial Execution Architecture

Database Design

Preliminary

Images from Group Discussion

Presentation Slides