From SoftwarePractice.org

Contents 1 Emergency Response System Documentation 1.1 Project And Team Management 1.2 Introduction 1.3 Purpose 1.4 Stakeholders 1.4.1 Stakeholder Identification 1.4.2 Stakeholder Rating 1.4.3 Stakeholder Analysis 1.5 Contextual Factors 1.5.1 Economical 1.5.2 Marketable 1.5.3 Organisational 1.5.4 Political 1.5.5 Schedule 1.5.6 Social 1.5.7 Technological 1.6 Usage Narratives 1.7 Quality Narratives 1.8 Architecture style 1.9 Conceptual Architecture 1.9.1 Responsibilities 1.9.2 Use Case Map 1.10 Execution Architecture 1.10.1 Concurrent View 1.10.2 Deployment View 1.11 Issues of Execution Architecture 1.12 Implementation Architecture 1.12.1 Off The Shelf Tools 1.13 Data Models 1.14 Data Responsibilities 1.15 Team Reflection 1.16 Acronyms 1.17 Presentation

Emergency Response System Documentation

Project And Team Management

All team information and management can be accessed here.

The link above is also the location of our individual logbooks, and reflections (also under our logs). SteveM 12:15, 6 November 2008 (GMT)

Introduction

Project Narratives:

Intended to be used by emergency service providers to help them decide which unit to despatch and which route to take to attend to the emergency most efficiently.

You can assume that the system has a "miracle" system that will deduce and provide a route between two end points. Your responsibility is to provide the system that can maintain a geographic database of some sort and can despatch and track emergency vehicles.

• The emergency vehicles can be ambulance, fire, police, police rescue, coastal and harbour patrol, traffic patrol, accident response uits, State Emergency Services (SES), bushfire services and any other you can think of.
• The system must operate 24*7.
• The system must know where all vehicles are at any time.
• A vehicle may be added or removed from the system.
• A vehicle can be suspended for maintenance or other reason.
• The system should be able to report on vehicle movements over a given period - day, week, month.
• The system should be able to report movements of a specific vehicle over a period or on a special occasion.
• The system should be able to report activity from a nominated despatch centre.
• The system should be able to report activity to a nominated region.

Purpose

The main purpose of the Emergency Response System (ERS) is to improve the response time of emergency response providers as well as enhance their ability to get to an emergency scene as quickly as possible. The Emergency Response System will be designed to provide the emergency response providers with the most efficient route between two end points depending on their location and status. The ERS will be able to maintain a geographic database which will be able to despatch and track emergency vehicles. The system is expected to operate 24*7and be able to produce reports based on:

• Emergency Vehicle Movements
• Activity from a nominated despatch centre
• Activity to a nominated region.

Stakeholders

Stakeholder Identification

• Citizens/Residents/Victims
• Emergency Phone Operators/Despatchers
• Emergency Vehicles
  • Ambulance
  • Fire Brigade
  • Police
  • Police Rescue
  • Coastal Patrol
  • Harbour Patrol
  • Traffic Patrol
  • Accident Response Units
  • State Emergency Services
  • Bushfire Services
• State Government
• Software Developers
• IT Support
• System Designers
• Management
• Police Investigators

Stakeholder Rating

Stakeholder	Promote	Impede	Description
Citzens and victims	1	0	Victims and citizens are usually not aware of the ERMS so they have low ability to impede the system. Citizens may be able to slightly promote the system if they have benefited from its implementation.
Emergency Phone Operators	4	4	Operators are significant stakeholders for this system. Since operators are directly involved in the use of the GUI of the system they will be able to promote and/or impede.
Emergency Vehicles/Dispatchers	3	4	Emergency Vehicles/Dispatchers are significant stakeholders for this system. Since Emergency Vehicles/Dispatchers are directly involved in the use of the system they will be able to promote and/or impede.
State Government	3	5	The State Government will be both interested in promoting a successful ERMS and impeding it if they feel there is any concern with its release. They are significant stakeholders in the system.
Software Developers	2	4	Software Developers are vital stakeholders as it is their responsibility to code/create the ERMS. They have a high ability to impede, but little ability to promote the system.
IT Support	4	1	IT Support are directly involved in the maintenance and technical support of the system. Therefore they are able to promote the system depending on how efficient and effective it is.
System Designers	2	4	System Designers are key stakeholders as it is their responsibility to design the ERMS. They have a high ability to impede but little in the promotion of the system.
Management	4	5	Management may not be directly involved during the development of the ERMS, however they still have a high ability to promote and/or impede the ERMS. They may not be directly requesting the development, but their ability to impede is high due to their responsibilities as manager of a station.

Stakeholder Analysis

Identity	Citizens and Victims
Characteristics	Emergency assistance needed Prompt response critical
Nature of Interest	Need some form of emergency assistance in the shortest period of time.
Benefits to the Stakeholder	Immediate dispatch of emergency vehicles. Appropriate vehicle for particular case can be quickly determined.

Identity	Emergency Phone Operators
Characteristics	Computer literate Knowledgeable about emergency response methods and their responsibilities
Nature of Interest	Locate the nearest and most convenient emergency dispatch vehicle. Get in contact with the emergency vehicle and advise of the shortest/fastest route to the case scene. Continuously update the emergency vehicle status in the system for real time information.
Benefits to the Stakeholder	Ease of use of ERMS to effectively locate and dispatch emergency vehicles. Effectively record and log all activities. Immediate response time.

Identity	Emergency Vehicles/Dispatchers
Characteristics	Computer literate Knowledgeable about emergency response methods and their responsibilities Knowledge of their chosen field.
Nature of Interest	Receive sufficient information about the emergency (such as location and importance). Receiving correct directions to the incident.
Benefits to the Stakeholder	Improved response times. Receive more information about the incident. Having the ability to easily manual update the status of the incident.

Identity	State Government
Characteristics	Political body. Large amount of media scrutiny on this stakeholder.
Nature of Interest	Helping to ensure the safety of the NSW citizens Auditing of emergency services
Benefits to the Stakeholder	Providing a safer state for all citizens. A well implemented system will look favourably on the Government's public portfolio.

Identity	Software Developers
Characteristics	Computer literate. Technically knowledgeable.
Nature of Interest	Ability to improve the system and ensure best systems are developed. All requirements given in the software specification are met. Possibility of future evolution and expansion of ERMS.
Benefits to the Stakeholder	Adds completed ERMS system to portfolio. Profit from working on project.

Identity	IT Support
Characteristics	Computer literate Highly knowledgeable about the nature of the ERMS system. Background knowledge of all emergency procedures of the former system.
Nature of Interest	Knowledge of how to implement ERMS system in order to carry out their role of IT Support.
Benefits to the Stakeholder	Gain profit from supporting and maintaining the ERMS. Increasing technical knowledge from experience working in an IT emergency support role.

Identity	System Designers
Characteristics	Computer literate Highly technical
Nature of Interest	Ensuring best possible system is designed. Ensuring all items on software specification are addressed. Ensuring the system is easy to use and learn.
Benefits to the Stakeholder	Profits made on completion of system. Adding the ERMS design to their portfolios Possible future expansion of the ERMS system.

Identity	Management
Characteristics	Not necessarily computer literate. Likely to have worked in a high pressure management role previously. Ability to manage others well, and maintain a complex implemented system (ERMS). Ability to maintain system documentation.
Nature of Interest	Ability to audit in various ways the effectiveness of the ERMS.
Benefits to the Stakeholder	Track any current case(audio calls), and review past cases.

Distribute 10 points to each stakeholder to rank their importance toward each of the system features:

Stakeholder	Reliability	Modifiability	Performance	Testability	Security	Usability
Citizens	5	0	5	0	0	0
Emergency Phone Operators	3	2	1	0	2	2
Emergency Vehicles/Dispatchers	3	0	4	0	1	2
State Government	2	0	2	0	6	0
Software Developers	1	2	1	3	2	1
IT Support	3	1	2	0	2	2
System Designers	1	2	1	2	2	2
Management	2	0	5	0	3	0
Totals	20	7	21	5	18	9

The three main quality attributes of our system are Performance, Reliability and Security.

Contextual Factors

Economical

Enablers - the State Government, with significant interest in and support for this system, has provided a large amount of funding to assist implementation of the ERMS. They are key contributors to ensuring the system is completed and implemented.

Constraints - given the large-scale nature of the ERMS and involvement of many stakeholders, the budget for this project exceeds the funding received from the government. As a result, there must be a tradeoff between reliability and performance of the system, as each component of these will have an associated cost.

Risk - if the system doesn't meet expected levels of efficiency, funding may be ceased or greatly reduced as well as profits not being made. This will mean that the budget must be used as efficiently as possible in order to develop the system. For this to occur, a great deal of time and effort must be spent in the design phase.

Marketable

Enablers - as the system has potential to positively impact a large geographic area, widespread promotion will result, with the opportunity to further broaden awareness and implementation. This system should be marketed with a emphasis on community benefit and keeping civilians as safe as possible in order to boost others' interest in the system.

Constraints - demand for the ERMS and similar systems may lead to various competitors, which will in-turn lead to a decreased marketing stance.

Risk - possibility of less than adequate improvement in emergency response, deeming the ERMS unnecessary given the associated expenses. This would give the system a negative image and see marketing become much less effective.

Organisational

Constraints - the large size of the system and many stakeholders involved mean business considerations and concerns are very high. With the increase in stakeholders, there is inevitably an increase in stakeholder requirements, which means the system must be implemented in a way that is highly reliable, maintainable, modifiable and scalable.

Risk - workers affected by the ERMS such as emergency response dispatchers, IT Support teams, etc may be unwilling to learn the new system. As a result there will be little or no improvement in having the system in place if it does not meet expected performance measures.

Political

Enablers - the State Government is strongly supporting the ERMS due to the potential for increased public safety. With media concerns circulating political issues such as public safety, there is a high tendency for the Government to provide as much support as possible to this measure of the system.

Risk - Legal issues may arise due to the nature of enhanced personell monitoring and vehicle tracking. This will force the system to suffer in terms of performance and reliability, which can have detrimental effects to it overall implementation.

Schedule

Enablers - the ERMS is scheduled to be implemented mid next year. Initial objectives are being met according to deadline which is a positive sign of things to come. Given the architectural approach to system design and development of a prototype to test quality attributes that may be otherwise difficult to determine, there is confidence that the system will meet its deadline.

Constraints - the large number of organisations and stakeholders involved make it difficult to foresee problems that could arise and delay the implementation. Such issues could be change requests of increased scalability, or more demand on reliability and performance without additional budgeting.

Risk - the ERMS may not be sufficiently tested by all stakeholder perspectives in time for the delivery deadline. This is a risk that would primarily be brought on as a result of the above constraint, where additional features or modifications to the system would cause it to delay the scheduled release.

Social

Enablers - the public are in acceptance of the ERMS given its benefits to society and public safety. There is an overwhelming dependence on technology in today's society and this system, which may have been seen in the past as putting too much trust in software, is much more widely accepted as it reduces the risk of human error.

Risk - less than optimal performance of the ERMS may make the public feel it is unnecessary, or even unsafe. There may be a general demand for improvement that simply cannot be achieved or a reversion to the old system.

Technological

Enablers - recent advances in GPS technology make the ERMS readily available and efficient. The "miracle" system will provide all necessary route and tracking information, which in the past could not be achieved. Other than this, the ERMS is merely a system of commonly implemented software such as databases, http servers, etc.

Constraints - large amounts of information will be processed which makes real-time updating difficult to achieve. This is difficult to overcome and will be evident in all technological systems whereby the constraints of the system as a whole is a result of the constraints of the technology used.

Risk - the mission critical nature of the system is susceptible to failure with power outages, delays in processing, software bugs, natural disasters or other such causes of mass hysteria. This will inevitably affect the performance of the system, which is intrinsically tied to available technology.

Usage Narratives

These are short narratives pertaining to the actual use of the emergency response system.

Collapsed Cleaner:

When arriving early to work one day, Terrance finds the cleaner has collapsed to the floor. He immediately calls 000 emergency and is directed to an ERMS phone operator. He gives the operator the information related to the case who promptly fills out the New Task Form on the Operator Interface and submits new task to the ERMS system. The ERMS system then process' the new task and allocates the nearest available and relevant emergency responder to the task. Meanwhile Jack, a paramedic recieves a new tasking on his vehicle ERMS console and promptly acknowledges reciept of the task. While advising Terrance as to how to deal with the situation, the ERMS phone operator is told that the incident has been logged via the ERMS operator interface, and that an ambulance is 4 minutes away. Terrance is then asked to stay with the cleaner until the paramedics arrive.

Domestic Dispute:

Three hours after starting the night shift at 10:00PM, William Oh an ERMS phone operator, receives a distress call from a lady from Blacktown. After finding out that she has been violently abused by her husband, and is fearful of further attacks, William logs the call for them into the system via the New Task Form on the Operator Interface, and then instructs the caller what actions to take as per the requirement for a domestic dispute. Meanwhile Sgt. Gomez is currently on patrol in a neighbouring suburb when he recieves a tasking to investigate a domestic dispute. He promptly acknowledges the tasking and proceeds to the address as marked on the ERMS vehicle interface in his police car.

Vehicle Maintainance:

During his working day, Raymond Jackson receives an email with the details of the decommissioning of two obsolete fire trucks, and the scheduled maintenance of three ambulances. He approves their removal / suspension from the system, and forwards the email to William Oh to action. William Oh logs into the Administrator Interface and removes the two trucks from the system, and suspends the three ambulances.The ERMS System now omits these vehicles from being allocated taskings and ignores their GPS update data.

Old Firmware:

During her shift, Sara Irvine logs into the Administrator Interface and audits all of the system vehicles over the past day, week, and month, in order to ensure that the system has been working properly over each time period. She finds that one vehicle has not been responding promptly, and upon investigation, finds that the unit's receiver has old firmware causing syncing problems. She logs then actions this.

Problematic Personnel:

During an audit, Sara Irvine notices that a police vehicle is not responding swiftly to calls. She queries the database of that specific vehicle's movement, and finds that it is often located at Westfield Parramatta shopping centre. She logs this with the police to ensure that it is proper behavior for that vehicle. The police find that it is unsanctioned visiting on duty, and the officer in question is counseled. The system is helping to identify problematic personnel.

Poor System Training:

Due to increasing pressure from the shadow minister's, Borris Flemming emails the ERMS management over the performance of the Redfern despatch centre, and its poor response times. After querying the system for the logs of Redfern despatch, Raymond Jackson discovers that there is a definite lag between receiving the call, and dispatching the required vehicle. After further investigation, the cause of this is found to be poor system training, and a refresher course is organised. After the training is completed, Raymond emails the Premier allaying his concerns.

Reinforcements:

Due to a major crash being called in, and the huge resource requirement for the scene of the collision, William Oh queries surrounding districts and allocates spare emergency response vehicles from each one, sending Fire, Ambulance and Police forces to the scene of the call.

Terrorist Attack:

Terrorists have hijacked commercial passenger jet airliners and crashed them into the Twin Towers of the World Trade Centre in New York. Given the high population density of New York and the extent of the casualties. ERMS management is able to quickly scale the ERMS to additional servers to compensate with extra load conditions, and improve reliability of the system. Furthermore ERMS management is able to call in extra ERMS phone operators to do double shifts and overtime to handle the spike in demand.

Quality Narratives

These are short narratives pertaining to the system's main qualities/attributes.

Performance:

The system must be updated in real-time in order for the locations of each vehicle to be accurate enough for a correct dispatch.

While patrolling the M4 Motorway, Police Constable Sally Carey detects a car traveling at 30km/h over the speed limit. When she pursues, the driver panics and swerves across the shoulder and crashes into a tree on the road side.

Sally calls Emergency Dispatch for further police support, and paramedic support. William Oh, the operator for her call checks the system, and assigns the current closest geographic units to her case, which he has found in the real-time geographic database. The units swiftly arrive at the scene of the horrific collision.

In this example, the system must perform in real time, as Sally needs reinforcements quickly to help close part of the road off, and more obviously, needs the assistance of paramedics on the scene. In a situation like this, the ERMS must be almost transparent, acting as efficiently as possible.

Reliability:

The system must be extremely reliable, as during any downtime lives will be put into jeopardy.

Due to excessive heat, an unprecedented number of citizens are using their air conditioners. This causes a huge unexpected drain of electricity, and many circuits of the ERMS system experience a brown out. Due to their fail-safe system, rather than run on incorrect power levels, an emergency petrol generator is started to provide the lack in power.

Sara Irvine receives an automated email from the fail-safe system outlining the use of the petrol generator. Sara checks all of the system to ensure it is correctly running. She finds that the system is lagging somewhat, and she phones each dispatch centre and tells them to manually start the generators. The system becomes fully functional again. Sara logs the non-automatic start of the generators into the error system for the IT team along with the Software Developers to check.

In this example, the system must overcome an external power shortage. This must also be taken into consideration when purchasing different hardware, as an uninterruptable power source is essential in anything that is mission critical, where lives are most likely to be at stake.

Security:

The system must be highly secure, as this is a system often dealing with life and death situations, it is imperative that no external force can gain access to any of the system resources.

During the tasking of a fire emergency, William Oh discovers that all of the emergency services have been tasked with emergency cases. Despite the seemingly heavy load, William knows that the emergency phone operators have not been extremely busy. He calls Sara Irvine to discuss the problem.

After reviewing the logfiles, Sara realises that the tasking of all of the vehicles has been done by someone who has hacked into the system. She immediately escalates the problem, and they must pull the system offline and revert to the previous inefficient system.

There is an immediate audit on the system security, and a more thorough encryption and user authentication schema is developed for the ERMS.

In this example, we can see the importance of the security layer. In our ERMS, we have developed a layered protocol where character encoding is an important step in our building of PDUs (protocol data units). A log is maintained of IPs, and user information and passwords are sent along with every transaction of the ERMS server to ensure that only validated users have access to the servers and through them, the database.

Architecture style

According to our functional needs, quality arrtibutes and contextual factors we came with N- tier architecture style in client server model. Basically ERS architecture divided in three layers those are web tier, Business tier and Data tier.

Web Tier: In ERS web tier is presentation layer which is responsible for all ERS displaying user interface and driving that interface using business tier classes and objects.

Business Tier: Business tier contains the business rule, data manipulation and may more functions.

Data Tier: Data tier is the database or the source of the data itself.

Conceptual Architecture

Architectural Views

Diagram represents the basic architecture of Emergency Response system.

v2 Conceptual Architecture

In this diagram, the key parts of the system have been distinguished. The server is the key module in having the system functional and reliable, so it has been constructed in this manner so as to be horizontally scaleable, that is, operate in parallel with other servers. This can also be replicated with the database. By nature, in this system there will always be multiple users interacting simultaneously, thus the user interfaces are all implemented with multiplicity in mind as well.

v1 Conceptual Architecture

Responsibilities

Operator Interface:

• Analyse and correctly judge the type of help required by emergency reporter
• Provide the Main Server with the specific data related to individual emergencies in a timely and accurate manner

Vehicle Interface:

• Periodically update the Main Server with a emergency response vehicles current location
• Provide an interface for emergence responders to acknowledge assigned tasks.
• Provide an interface that updates the emergency responder vehicle drivers as to best route to take, to get to the emergency location.

Administration:

• Provide an interface to change emergency reponse management system parameters such as adding update vehicles and generating reports.

Main Server:

• Analyse incoming packets for validity
• Process incoming packets add/retrieve data to/from the database.

Web Interface:

• Provide an interface to send, recieve and respond to HTTP packets
• Validate level 1 and level 2 layer packet

Data Handler

• Validate and process packets at layer 3

Add/Update Logs:

• Add and Update Logs by accessing the SQL Database

Update Vehicle Location:

• Update the current location data for a particular vehicle by accessing the SQL Database

Generate Reports

• Retrieve Report Data from SQL Database

Add/Update Vehicles

• Add and/or Update Emergency Response Vehicles that the ERMS tracks.

SQL Database

• ensure that data is saved in a managable way such that data integrity, data security and performance is maintained.

Use Case Map

Initial use case map. Has been revised since further tutorials, and has evolved into the following use case maps, which are now based upon specific usage narratives:

Domestic Dispute: Three hours after starting the night shift at 10:00PM, William Oh an ERMS phone operator, receives a distress call from a lady from Blacktown. After finding out that she has been violently abused by her husband, and is fearful of further attacks, William logs the call for them into the system via the New Task Form on the Operator Interface, and then instructs the caller what actions to take as per the requirement for a domestic dispute. Meanwhile Sgt. Gomez is currently on patrol in a neighbouring suburb when he recieves a tasking to investigate a domestic dispute. He promptly acknowledges the tasking and proceeds to the address as marked on the ERMS vehicle interface in his police car. Reinforcements: Due to a major crash being called in, and the huge resource requirement for the scene of the collision, William Oh queries surrounding districts and allocates spare emergency response vehicles from each one, sending Fire, Ambulance and Police forces to the scene of the call.

Operator Use Case Diagram Vehicle Use Case Diagram Both Diagrams above represent concurrent processes however for the sake of clarity they have been split into two different diagrams.

Vehicle Maintainance: During his working day, Raymond Jackson receives an email with the details of the decommissioning of two obsolete fire trucks, and the scheduled maintenance of three ambulances. He approves their removal / suspension from the system, and forwards the email to William Oh to action. William Oh logs into the Administrator Interface and removes the two trucks from the system, and suspends the three ambulances.The ERMS System now omits these vehicles from being allocated taskings and ignores their GPS update data.

Administrator Use Case Diagram

Execution Architecture

The execution architecture determines largely the realtime and performance behavior of a EMRS system.

Two diffrent views of Execution Architecture.

1. Concurrent View

2. Deployment View

Concurrent View

Future consideration of contextual factors:

The major influence that contextual factors will have on the implementation and execution is in regard to the technological aspect of the system. Given that the ERMS cannot suffer any down time, key areas where this may occur need to be addressed. Such areas of this architecture are the HTTP server, database and mapping module. In order to reduce the possibility of any of these failing, measures must be taken to ensure multiple databases are kept, preferably in different physical locations. There must be a backup HTTP server available in case the primary route is compromised, as well as secondary updates of the mapping module in case the key link suffers any delays.

With such additions to the implementation architecture, various associated contextual factors will be affected. Economically, increased costs will be required to account for the additional dedicated servers and routes. Organizationally, more staff will be required to monitor the status of each component of the system and act accordingly if any such components fail. From a scheduling perspective, more time will be needed to ensure efficient implementation and testing of the backup components and mission critical mechanisms of the system.

Deployment View

Given diagram shows the deployment architecture view of ERS.

Deployment Architecture - An ideal representation of the ERMS implemented in the real world

The ERS deployment view represents the allocation of concurrent components to the physical components. Given diagram shows that deployment view divided in to web tier, application tier and data tier. In deployment view during allocation of software elements to the hardware elements our major concerns were functional needs, quality attribute needs and the various contextual factors.

A firewall layer exists between the web and application tier and the network bridge between between the application and data tier where our Database resides, there is no real threat or harm that can be made to the database from open ports of the web. Even though from this view of the system, there is not any great impact on speed or performance, its clear that data safety is well establish.

Issues of Execution Architecture

• If the current location of vehicle isn't updated within a certain time period, the information doesn't remain real time anymore and cant be used by the operator/client to ascertain the location without doubt.




• If multiple services are dispatched by the system then it is likely to decrease the speed of the server and put additional load on the mapping system and database.

Implementation Architecture

Server Implementation

Client Implementation

Vehicle Implementation

Off The Shelf Tools

We believe that there are several tools that are highly beneficial to the implementation of the Emergency Response Management System. These are as follows:

• Database:
  • We have chosen to use Microsoft SQL Server 2005 for our implementation of the database for our system.
• Miracle System:
  • The possibility of the purchase of a ready made route finder 'miracle system' is one possible solution for the devising of most efficient routes between two given GPS locations.
  • Google maps is a tool similar to what the requirements of this system require, the developers of this system might wish to approach them in the use of some of these services in the EMRS. This still may not be a feasible solution as Google may not wish to pursue this line.
• GPS tool:
  • All vehicles in the EMRS service will require some form of GPS device to constantly send the vehicles current location so that the database is always current. Furthermore a software - hardware abstraction layer for this device would be required for the actual transmission of the coordinates to the ERMS servers.

Data Models

Data Responsibilities

As the database is relational, there are primary and foreign keys identified that not only makes relevant logical associations within the model, but also help search/ retrieve for data from the system with key values like IDs.

Thats the basis for various related tables to exist apart from the significant tables such as Vehicle, User, Dispatch. Below is the description of the tables with their responsibilities.

Tables User, UserType, Log are related such that they assist USER fucntionalities

UserType

• Primary Key: UserType_id

Stores the various types of users that are capable of accessing the system data. Such as Admin, Managers, Operators etc

User

• Primary Key: User_id
• Foreign Key: UserType_id

Stores the details regarding individual users of the system and also associates with UserType.

Log

• Primary Key: Log_id
• Foreign Key: User_Login

Maintains a record of the user actions for an event/ admin task.

As dispatching a Vehicle is actioned after an "Event" occurs, Tables Vehicle, Event and the associated Tables are related by their Primary Keys.

VehicleType

• Primary Key: VehicleType_id

Stores the various TYPES of Vehicles that exist in the Emergency Response Services. Example Fire Brigade, Ambulance etc

Vehicle

• Primary Key: Vehicle_id

Stores the information of a particular vehicle such as registration number Also, contains the real time location in terms of lattitude and longitude.

Event

• Primary Key: Event_id

Stores all the information regarding event description, type of service required , address to resond to the caller needs efficiently.

Tables below are related to DISPATCH which keeps track of the dispatching of a vehicles from centres. Table State simply represents the heirarchy that exists in the administration of the EMRS. Every dispatch centre belongs to a particular State and is uniquely identified by the DispatchCentre_Id.

DispatchCentre

• Primary Key: DispatchCentre_Id
• Foreign Key: State_id

Stores information relating to the Dispatch Centre

Dispatcher

• Primary Key:Dispatcher_id

Stores information regarding the person Incharge of Dispatching vehicle from Dispatch Centre

Dispatch

• Primary Key: Dispatch_id

Stores details of dispatch and the arrival of every dispatch taken place from the Centre.

DispatchLog

• Primary Key:DispatchLog_id
• Foreign Key:Dispatch_id

Maintains a record of the dispatched action in terms of date-time, location of vehicle.

Team Reflection

We found this subject to be quite different to any of the other subjects we had completed in previous semesters. We found that Software Architecture (SA) offered a unique approach and application to designing systems. One subject that assisted us with this one was Object Oriented Design (OOD), where we learnt to consider stakeholders of the system and develop use cases and usage scenarios. Although this helped with a portion of the fundamental aspects of SA, it was a completely different and new approach to the design and consideration of conceptual, execution and implementation architecture.

Use of subversion was not new to us, since OOD had used this, as well as Eclipse, previously. We found subversion to be a particularly good way of keeping track of what code has been written and by who, as well as when changes have been made. This was useful in tracking errors and allocating coding tasks.

Milestone 1 was challenging because it was such a different way of thinking about the system. New diagrams had to be learnt and understood, and then applied to the prototype. Coding in java had been done previously in other software based subjects but not to the extent this project required. For this reason we still needed a lot of research and greater understanding of the implementation concepts. We found the feedback for Milestone 1 relatively clear and concise, and were therefore able to make any necessary improvements for Milestone 2.

Uploading project documentation to the wiki had also been done previously in OOD, so we were relatively familiar with this process, and found it an effective method of keeping track of what had been worked on.

We found the text book useful in gaining further understanding of architectural concepts and design learned in the lectures and tutorials. Found Vijay, our tutor, quite helpful when we had problems understanding anything that could not determined from the lectures and textbook.

We found that our group worked well together in assigning and completing tasks. There was no conflict within our group and this made it much easier to communicate with each other.

Overall we found this subject rewarding as it allowed us to look at software and systems in a completely new way. By the end of the subject our understanding of software architecture was very well formed and we will undoubtedly be able to use this knowledge in other aspects of university and work.

Acronyms

• ERS: Emergency Response System
• GUI: Graphical User Interface

Presentation

Media: V3-presentation-M1-31278-48433-S08.ppt

Our team has been unable to upload the presentation to the wiki, so we have placed it in our base project folder on the svn. SteveM 12:59, 11 September 2008 (GMT)