From SoftwarePractice.org

Contents 1 Team Guidelines 1.1 Team Members 1.2 Allocation of Roles 1.2.1 Milestone 1 1.2.2 Milestone 2 1.3 Schedule of Meeting Dates 1.3.1 Milestone 1 1.3.2 Milestone 2 1.4 Modes of Communication 1.5 Conflict Resolution 1.6 Protocols for using Wiki 1.7 Protocols for using the Source Repository 2 System Overview 3 Scope 4 Purpose of System 5 Stakeholder Analysis 5.1 Emergency Services 5.2 Public Citizens 5.3 Emergency “000” Call Centre 5.4 Roads and Traffic Authority (R.T.A) 5.5 N.S.W State Government 5.6 Insurance/Legal 5.7 Hospitals 5.8 Unions and Industry Organisations 5.9 Software Developers 5.10 IT Support 5.11 Project Managers 5.12 Media 6 Stakeholder Rating Assessment 7 Contextual Factors 7.1 Market / Competitive 7.2 Social 7.3 Organisational 7.4 Technological 7.5 Political / Legal 8 Customer Needs 8.1 Usage Narratives 8.2 Quality Attributes Assessment 8.3 Quality Attributes 9 Inception of Conceptual Model (Initial Attempts) 9.1 Version 1 Conceptual Model 9.1.1 Domain Responsibilities 9.1.1.1 Emergency Despatch System 9.1.1.2 Call Centre Operator 9.1.1.3 Fire Fighter Interface 9.1.1.4 Incident Data 9.1.1.5 Overall Comment on Version 1 9.1.2 Conceptual Model Version 2 9.2 Domain responsibilities 9.2.1 Vehicle Tracking 9.2.2 GPS Interface 9.3 Version 3 Model 9.3.1 Version 3 Conceptual Model 9.3.2 Domain Level Responsibilities 9.3.3 Login Server 9.3.4 User Roles 9.3.5 Incident Recording 9.3.6 Vehicle Selection 9.3.7 Report Generator 9.3.8 Region 9.3.9 Despatch Centre 10 Conceptual Architecure 10.1 Conceptual Model 10.2 Data View 10.3 Updated Data View 10.4 Behaviour 10.4.1 Use Case Maps 10.5 Implementation 10.6 Component choices 10.7 Constraints 11 Execution Architecture 11.1 Structure 11.1.1 Concurrency 11.1.2 Deployment View 11.2 Behaviour 11.2.1 Use Case Maps 11.3 Implementation 11.4 Constraints 12 Implementation Architecture 12.1 Structure 12.1.1 Implementation Diagram 12.1.2 Component Relationships 12.2 Behaviour 12.2.1 Sequence Diagram 12.3 Implementation 12.4 Component choices 12.5 Constraints 13 Development Issues 13.1 Multitasking 13.2 Technology 13.3 Multi-development 13.4 User interface 13.5 Miracle System 14 Key Architectural Decisions 15 Critique of Architectural Design 15.1 Framework 15.2 Layers 15.3 Reliability 15.4 Security 15.5 Performance 15.6 Final critique 16 Reflections 17 Instructor comments

Team Guidelines

Team Members

Peter Ebeid - 10435966

Trevor Russell - 10454041

Ara Stamboulian - 10032338

Damir Trako - 01041274

Chris Zaharia - 10424380

Chris White - 10308144

Allocation of Roles

Milestone 1

Role	Description	Member Responsible
Team Guidelines	Outline role allocations, scheduling of meeting dates, modes of communication, conflict resolution, protocols for using wiki and source repository	Chris Z
Set up google groups	Set up google groups page for the project	Chris W
Team Meetings	Document team meetings	Damir
Logging	Log contributions of each members' work	Team
Setup Wiki	Set up the wiki for the documentation of the project	Chris Z
Wiki Documentation	Placing of all components of project on the wiki	Team
Develop base prototype	Develope the basic fundamental coding of the prototype including simple button GUI, socket handler connecting to multi threaded server.	Trevor
Enhance Prototype	Enhance prototype to meet all requirements of case study	Team
System Overview	Describe an overview of the system	Chris Z, Ara
Scope	Develop scope of system	Ara
Stakeholder Analysis	Outline of all stakeholders involved	Team
Stakeholders	Describe stakeholder emergency services	Team, Damir
Stakeholders	Describe stakeholders - NSW State Government, Insurance/Legal, Hospitals	Peter
Stakeholders	Describe stakeholders - GPS, Software Developers	Chris Z
Stakeholders	Describe stakeholders - IT Support, Unions and Industry Organisations	Damir
Stakeholders	Describe stakeholders - Public Citizens, Emergency Call Centres	Trevor
Stakeholders	Describe stakeholders - Emergency 000, RTA	Chris W
Stakeholders	Describe stakeholders - media, NSW ambulance service, NSW Police, project manager, software developer.	Damir
Stakeholders	Elaborate on media stakeholder	Trevor
Stakeholders	Overview of all Stakeholders	Damir
Research	Research on standards for document layout and qualities from IEEE to assist in presentation and use of standards.	Ara
Narratives	Develope narratives for Citizens, Emergency 000 Call Centre, GPS, IT Support	Chris Z
Contextual Factors	Describe contextual factors of system	Chris Z
Data Models	Develop diagrams of the data view and comments describing them.	Ara
Narratives	Develop client narratives for normal usage, hotline amendment, state change from active to offline, state change from active to idle in transit, addition and removal of vehicles, system statistics	Ara
Narratives	Develop client narratives for incident logging and reporting. Develop attribute narrative on reliability.	Chris Z
Narratives	Develop several narratives on different stakeholders	Chris W
Narratives	Develop narratives including for ICT, reliability from a hardware/network/electrical aspect of system such as redundancy	Trevor
Conceptual Diagram	Develop a diagram of the conceptual architecture	Ara
Improve Conceptual Diagram	Improve conceptual diagram from further discussion with members and modifying the original to show new changes.	Team, Ara
Use Case Maps Diagrams	Develop use case map diagrams for the main normal use of system and the reporting scenario	Chris Z
Use Case Maps Diagrams	Develop use case map diagrams for tracking emergency vehicles, maintenance update and improving use cases for incident reporting and management reporting.	Peter
Use Case Maps Diagrams	Develop use case map diagrams for the case of a vehicle breakdown entroute to attneding an incident and the response of ERDS in relation to dispatching another vehicle.	Ara
Concurrency Diagram	Develop concurrency diagram for the execution architecture, add comments and description of concurrency	Peter
Components and Responsibilities	Discuss components and responsibilities.	Ara
Sequence Diagrams	Develop sequence diagrams for the normal use and reporting activities of the system. Add comments and descriptions of the sequence diagrams	Chris Z
Quality Attributes	Display in diagram stakeholders and their quality attributes with allocation of qualities for system	Ara
Non Functional Requirements	Describe non-functional requirements based on stakeholder input for availability, security, system responsiveness, scalability and system longevity	Ara
Stakeholder Rating Assessment	Develop stakeholder rating assessment with the ability to promote or impede for each stakeholder including comments	Ara
Implementation Diagram	Develop implementation diagram for the implementation architecture	Chris W, Damir, Trevor
Conclusion and Review	Outline and describe conclusion of report and review on processes with plans to improve for the next milestone
Report Maintenance	Maintain report including fixing grammatical and spelling errors in reports as they arrise. Check for errors in diagrams and other representations.	Trevor
Development Issues	Discuss anticpated development challenges and how the team plans to approach them	Peter
Tutorial Presentation	Develop power point presentation for team presentation in tutorial	Peter

Milestone 2

Role	Description	Member Responsible
Context	Describe an updated analysis of context of the system	Chris Z
Stakeholder concerns	Describe an updated analysis of the stakeholder concerns of the system	Damir T
Quality Attributes Table	Update quality attribute assessment table as per lecture notes.	Ara
Quality Attributes	Update quality attributes discussion, narratives and targets	Ara
Conception(conceptual)	Initial attemps of modelling conceptual components and their domain level responsibilities by following textbook technique	Ara
Structure (conceptual)	Complete the descriptions and models of the structure of the conceptual architectural view	Ara
Structure (implementation)	Complete the descriptions and models of the structure of the implementation architectural view	Chris Z
Implementation	Describe the implementation details of the architectural views	Chris Z
Constraints	Describe the constraints of the architectural views	Chris Z
Concurrent Diagram	Update a model of the concurrent subsystems view	Chris Z
Deployment View	Update the deployment view model of the system	Chris Z
Execution Use Case Maps	Develop use case maps for the execution architecure, with reasoning of use cases validating or revealing deficiencies in architecture	Chris Z
Mapping of conceptual components	Model and description of the mapping of conceptual components to the application and instrastructure components of the system	Chris Z
Sequential Diagrams	Update the sequential diagrams depicting the behaviour of the implementation architecture	Peter E
Choice of components of Implementation Architecture	Justify reason for choice of custom and of the shelf components for implementation diagram	Chris W
Key Architectural Decisions	With reference to the system context, stakeholder input, constraints and results of prototypes	Trevor
Critique of Architectural Design	Critique evaluation of architectural design in light of the executable prototype. Describe if strong or weak, and how prototype illuminated various aspects of design.	Chris W
Database Architecture	Update database structure to include modification made to database design.	Peter E
Report	Edit report grammar and syntax.	Ara
Report	Referencing of sources	Damir T
Reflection	Reflection of project in 1-2 pages	Group

---

Schedule of Meeting Dates

Milestone 1

Date	Description	Outcomes
7/8	First meeting, create team and allocate initial roles. Discuss case study and stakeholders, discover and outline stakeholders and a few benefits and interests.	Create Team Allocated Roles Stakeholder Outline Stakeholder - Emergency Services
14/8	Set SVN repositories for all members, learn and develop skills in programming with sockets and java to develop prototype	SVN Repositories Learn/enhance socket and java programming skills
21/8	Discuss possible narratives to create for the stakeholders and clients. Plan and discuss components of the conceptual architecture	Narratives Outline Conceptual Architecture Plan
28/8	Discuss and develop a rough plan for the concurrency diagram of the system. Discuss components needed for the deployment view for the project	Concurrency Diagram Draft Deployment View Plan
4/9	Develop implementation diagram. Evaluate current state of prototype and discuss improvements and plan to complete it in time using all team members contribution	Implementation Diagram Plan Final Prototype
11/9	Present project to peers, submit final wiki document in print form in lecture.	Presentation Performed Submit Final Report

 

Milestone 2

Date	Description	Outcomes
9/10	Discuss and plan structure of the database and system, to develop the executable prototype	Database Structure System Structure
16/10	Discuss and allocated components left of the system to develop until deadline, including the business logic, database completion, interface completion and all other parts.	Business Logic Prototype Completion Plan
23/10	Discuss allocation of tasks for documentation of milestone 2, and creating unfinalised use case maps for the execution architecture.	Allocate Documentation Tasks Execution Use Case Maps
30/10	Discuss allocation of final tasks to be complete by deadline. Planned and developed mapping of conceptual components for implementation architecture and initial discussion of the of the shelf and custom components used for the architecture	Allocation final tasks Implementation Architecture
6/10	Present final milestone 2 report to peers for review. Submit final report of finished documentation	Presentation Performed Submit Final Report

 

---

Modes of Communication

The modes of communication we have chosen for this project include:

1. Google Groups - We have created a Google Group for our project which allows each member to broadcast messages of communication to the entire group for all members to see. Group members will update others on which tasks they have started or completed, along with other discussions including the adding or modification of tasks. The group will also allow members to submit draft copies of documents they work on for others to modify, especially files that cannot be uploaded on the wiki such as source visio and word files.

2. Wiki - A wiki will be developed that will contain drafts and finally the final copy of the report for the milestone. The wiki will also allow members to post comments on progress and how decisions have bought the shown outcomes, along with temporary notes for others to read that can describe improvements required in sections or other important notes.

3. In person - The entire group will meet every week to discuss and complete tasks in person. This will allow members to all contribute equally in the decision making and important factors chosen for different tasks.

Conflict Resolution

Conflicts will be resolved as they arise, where conflicts are categorised as the following: - disagreements between members on certain issues - lack of participation by a member

In the case of conflicts occuring, the following process will be followed in order where the issue will progress to the next step if the current step did not solve the conflict.

1. Discussion between team members - Members will all discuss all aspects that brought rise to the conflict, with members trying to reason with those that are taking part in the conflict. A vote will be passed to make clear decision on an issure if the conflict is relating to a difference of opinions amongst members.

2. Case escalation to tutor - Members will bring the case forward to the tutor which may try to reason with the conflict and develop a solution. In agreement with the tutor, the case may be escalated to the next step if conflict still exists.

3. Case escalation to subject coordinator - Case will be brought before the subject coordinator on terms of their acceptance of participation. Conflict must be solved at this level.

Protocols for using Wiki

The following protocols will be adhered by members in use of the wiki:

1. Member must not change the work of another member unless notification is made to the previous member and a copy of the previous members contribution is kept in back up.

2. Member must not defile the wiki in any way, includingbut not limited to: the deletion of appropriate material and the placing innappropriate content on the wiki.

3. Member must not place copyright or plagiarised material on the wiki without proper permission. Referencing and copyright material per subsection must be kept to a minimal.

4. Member must post their final work on the wiki.

5. Member must only post their work on this wiki, no other existing or newly created wiki can contain the work relevant to the team's project.

The breaking of any of these rules will be met with disciplinary action outlined in the conflict resolution section.

Protocols for using the Source Repository

The following protocols will be adhered by members in use of the svn source repository:

1. All code must be checked into the /src directory, no code may exist in any other directories.

2. Members must first notify the group of any large changes they are making to existing code prior to logging their code back in.

3. All code checked in must contain a descriptive message of the changes that have been made.

4. No member may check in code that they have plaguarised from anywhere, all code must be their own work.

5. All code that is checked in must include descriptive, informed comments.

6. In the event of a clash the members involved will endeavour to solve the problem through communication, and then notify the group of why this occured so we may prevent it occuring in future.

The breaking of any of these rules will be met with disciplinary action outlined in the conflict resolution section.

---

System Overview

As population growth has reached unprecedented levels, so has the amount of emergency assistance that is required. Current emergency units are unable to meet with the rise in emergency assistance demands, and so our company has been contracted to develop a system to better assist all emergency services in despatching of units and optimised route efficiency.

The State of N.S.W. is motivated to act based on recent negative publicity regarding poor emergency response and through the assistance of the development of the Global Positioning System (GPS) in tracking vehicles, it is investigating the feasibility of launching a new Emergency Response Dispatch System (ERDS). The new system will become a comprehensive dispatch system for all of the state’s emergency services. It is expected that ERDS will be able to provide the most efficient way of assigning the closest vehicle to an incident as well as providing routing information. The initial stage will be on a metropolitan scale, followed by an expansion to state wide scale. The system may, with the co-operation of other states and territories, be implemented across all of Australia. The great advantage of this schema is that in cases where natural disasters are declared, the cross state dispatch, based upon the definition of proximity areas, becomes inherent to the system.

---

Scope

The system is designed to facilitate the dispatch of vehicles to incidents. It is not intended to replace the normal departmental control over its fleet, in fact ERDS works in cooperation with it. It is envisaged that each vehicle will be fitted with a GPS set, and will rely on its radio link to transmit its instantaneous position to its service. The emergency service then forwards this information, though its link, to ERDS for the dispatch system to keep track of individual vehicles. The emergency dispatch system has the responsibility of making the decision of which vehicle is to be assigned an incident. This decision is then to be relayed to the concerned emergency service. It becomes the responsibility of the service to forward the assignment to the vehicle involved (in the majority of cases via its radio link) and exercise its control over it. Similarly if any vehicle is taken out of service, for re-supplying or maintenance, it becomes the responsibility of the concerned emergency service to receive the message from its fleet, and notify ERDS of the changed status of availability of the vehicle.

The system relys on the "Routing Miracle System" for finding the most efficient route between two end points. It also provides a metric (e.g. estimated time of arrival) as a means of comparing two alternative selections. ERDS will make use of these two outputs of the Miracle System in determining which emergnecy vehicle to dispatch.

---

Purpose of System

ENTER TEXT HERE

---

Stakeholder Analysis

Emergency Services

Overview

NSW Police Service

The NSW Police service is one of the largest police organisations in the western world with over 16,000 employees and 13,000 serving police officers. The Commissioner of Police is the operational head of the police service. The Commissioner reports directly to the Minister for Police who is an elected representative of the people of NSW.

The NSW Police Service has more than 2,900 motor vehicles, a fleet of almost 70 water craft including 11 ocean going boats and three helicopters.

http://www.police.nsw.gov.au/

NSW Ambulance Service

According to its website, the Ambulance Service of New South Wales is an integral and dynamic part of the New South Wales health system and one of the largest ambulance services in the world. The service is committed to providing high quality clinical care and health related transport services to over 6.7 million people in NSW, distributed across an area of 801,600 square kilometres.

The NSW Ambulance Service boasts to have over 800 Ambulance Vehicles and over 300 support vehicles. These vehicles fulfil the following roles;

• Emergency
• Non-Emergency Transport
• Aero medical Transfers
• Patient Transport

http://www.ambulance.nsw.gov.au/

NSW Fire Brigades

The NSW Fire Brigades is the NSW government agency responsible for managing fire emergencies in the major cities, metropolitan areas and towns across rural and regional NSW. The NSW Fire Brigdes also protect the State from hazardous material incidents and by extension of this capability, the consequences of terrorism. The NSW Fire Brigades support other government agencies during and after bushfires, storms, floods, landslides, building collapses, earthquakes and other emergency situations.

The Fire Brigade consists of a network of 338 fire stations across the State and a fleet of 882 vehicles.

http://www.nswfb.nsw.gov.au/

State Emergency Services

The State Emergency Service is an emergency and rescue service dedicated to assisting the community. It is made up almost entirely of volunteers, with 232 Units located throughout New South Wales. The Units comprise of more than 10,000 volunteer members.

The major responsibilities of the SES are for flood and storm operations. However, the SES also provides the majority of general rescue effort in the rural parts of the state. This includes road accident rescue, vertical rescue, bush search and rescue, evidence searches (both metropolitan and rural) and other forms of specialist rescue that may be required due to local threats. The Service's also support the full-time emergency services during major disasters.

http://www.ses.nsw.gov.au/

Characteristics

• Law and order
• Mobile
• Dedicated
• Responsive
• Professional/Educated
• Scalable
• Structured
• Result driven
• Ethical
• Dedicated
• Shift-work
• 24 hour / 7 days operational
• Government regulated
• Public servants
• Tax payer funded
• Heavily scrutinised / Public opinion
• High risk
• Public Status
• Essential Services
• Society depends on them

Interests

• Reliable
• Effective
• Increased responsiveness
• Reduced risk
• Even distribution / greater utilisation of resources
• Make job easier, rather than harder
• Cost effective
• Positive public opinion
• Efficiency

Benefits

• Better public opinion
• Reduced risk
• Increased coverage
• Benefit the community; Save lives, decrease crime
• Positive drive and influence in the community
• Less public/media scrutiny
• Efficiency
• Reduced Cost
• Greater transparency especially between emergency services

Public Citizens

Overview

The Public Citizens are all the men, women and children who live and reside in NSW at any given time. They are individuals who form an opinion, which encompass their beliefs and attitudes. They come form all levels of society, irrespective of educations, wealth and public standing.

The Public Citizens of NSW place their trust in the Emergency Services in their times of need. However, they remain sceptical at the effectiveness of the NSW government and the funding of Emergency Services. The Public Citizens and their opinion are easily influenced and manipulated by the media at any specific period of time.

The Emergency Services are funded from the coffers of the NSW Government, who raises their revenue through taxes of the NSW Public Citizens. As such, this gives the public a sense of owenership of the Emergency Services and want them to be as effective and benefitial to society as possible.

Characteristics

• Require assistance
• Poor communicators in emergencies/unable to communicate at all
• Prone to calling about insignificant matters (Suspicion -> call police, stomach ache -> call ambulance)
• Resistant to assistance
• Willing to assist (passer bys making the call)
• Language barriers
• Hazardous/dangerous to emergency services
• Often the cause of emergencies
• Dissatisfied with current response times

Interests

• Preservation of self/others in a timely fashion
• Sense of security in supporting services
• Better understanding of their needs
• The correct service as quick as possible
• Advice prior to arrival of emergency services

Benefits

• Improved response times saving their lives
• Improved standing/recognition of Emergency Services by citizens
• Improved opinion, less hesitation to call in actual emergency

Emergency “000” Call Centre

Overview

The Emergency "000" Call Centre is a free NATIONAL emergency hotline service to contact the Police, Ambulance or Fire Services in case of urgent time critical, life threatening situations or other emergencies. All "000" calls are answered by an Emergency Operator who then connects the caller to the relevant Emergency Service. The call centres are staffed country-wide, 24 hours a day with highly trained and skilled Emergency Operators, who will ask relevant questions, and arrange an appropriate response from the closest units, or from other services (e.g. Police, Ambulance or Fire Service).

Characteristics

• Shift-workers
• Operating 24 hours a day
• Trained (in taking emotional, time critical calls)
• Depends on external information (routes, emergency services, capacity, utilisation)
• Critical

Interests

• Efficient
• Reliable
• Better then current system
• current and fast access to information
• Informed about emergency services operations
• Effective
• Improved working conditions
• More useful to callers

Benefits

• More useful to callers
• More efficient ways to work
• Work is more effective
• They can do their work reliably

Roads and Traffic Authority (R.T.A)

Overview

According to its website www.rta.nsw.gov.au, the RTA is the NSW State Government agency responsible for:

• Improving road safety.
• Testing and licensing drivers and registering and inspecting vehicles.
• Managing the road network to achieve consistent travel times.

The RTA also provides financial assistance to local councils to manage 18,474 kilometres of Regional Roads and also provides some funding and support to the 144,750 kilometres of council-managed local access roads which are funded by local ratepayers and federal road assistance grants.

http://www.rta.nsw.gov.au/

Characteristics

• Structured
• Regulated
• Regulating
• Heavily scrutinised/ Public opinion
• Law enforcement
• Law and order
• Holds crucial roads information
• Government controlled
• Could stop a project

Interests

• Reliable
• Safe
• Certified / Follows regulations
• Better then current system
• Public Image / Opinion

Benefits

• Improve road safety
• Public Image / Opinion
• Better handling of road access
• Supports the community
• Has a better purpose for captured information about road usage

N.S.W State Government

Overview

The N.S.W. State Government is formed by the party which wins the most number of seats in the NSW Parliament lower house. The last Election was held in NSW in 2007, and was won by the Australian Labor Party headed by the now former premier Mr. Morris Iemma. After much negative media publicity, and ineffective governance Premier Morris Iemma resigned from the leadership of the NSW Parliamentary Labor Party, and was replaced by the new premier Nathan Rees. The minister responsible for the Emergency Services in NSW is Mr. Tony Kelly (Minister for Industrial Relations, Minister for Emergency Services, and Minister for Lands)

http://www.directory.nsw.gov.au/index.asp

Characteristics

• Large organisation
• Resource rich
• Source of capital for RTA projects
• Multi-department
• Highly structured
• Politically motivated
• Can make or break projects

Interests

• Good publicity
• Satisfaction of Citizens
• Success in office
• Improving public facilities
• Encouraging business growth within state
• Saving money
• Efficient use of capital and resources

Benefits

• Source of funds for project
• Capacity to market the project to the public
• Ability to acquire foreign technology and expertise through its relationships with federal/foreign governments
• Ability to allocate the support of other departments

Insurance/Legal

Overview

The Insurance/Legal Industry's main interest would be the protection of all parties involved in the system. The legal representatives would be considering the legal implications of the system and its structure and looking at minimising any ligitation at any stage of the project implementation. The insurance component will look to cover all parties involved in the system, and its implementation.

Characteristics

• Expert on subject matter
• Highly organized
• Client oriented
• Expensive to utilise

Interests

• Protection of clients against financial threats
• Accuracy of information
• Consultation before taking action that may lead to legal action
• Preventing litigation against client from being successful.
• Minimizing insurance claims.

Benefits

• Covers vital contingencies
• Protection against possible disruption to project

Hospitals

Overview

The Hospitals in NSW are run by the NSW Department of Health. Hospitals in NSW are scattered around all metropolitan areas and rural areas. The Hospitals are funded by the NSW and Federal government. However, in recent years both state and federal government have come under great public and media scrutiny for not funding NSW hospitals, with patient care being compromised, especially with limited number of beds available, and hospitals unable to cope with patient intake and staff shortages in terms of nursing and doctors. Regional Hospitals have so far been the most to suffer, with the lack of funding and services.

Characteristics

• Geographically scattered
• Dependent on information sharing
• Range in facilities and capabilities
• Have a range of expertise
• Patient oriented
• Work extensively with other emergency services
• Critical public infrastructure
• Funding competitive
• Rely on different information systems for record maintenance and operation of equipment

Interests

• Maintaining emergency capacity
• Improving patient wellbeing
• Maintaining sustainable patient turnover
• Maintenance of patient records
• Maintaining of communications with emergency dispatch
• Improving cooperation with other medical services
• Improving funding

Benefits

• Provides public with vital medical services (emergency)
• Provides government with medical research
• Provides public with rehabilitation facilities for improvement of lifestyle

Unions and Industry Organisations

Overview

The unions and industry organisations are dedicated to protecting and fighting for the rights of workers blue and white collar and representing their interests including wages/salaries and conditions, safety in the workplace and securing entitlements. Australia has many different unions and industry organisations for specific industries. Union membership is not compulsory anywhere in Australia.

Characteristics

• High membership organisations
• Protective of members interests
• Different sectors have different bodies
• Proactive in trying to achieve best outcome for members in terms of money, employment conditions
• Politically; they swing very much to the left
• Tries to exert political influence through sheer volume of numbers
• Prone to protests/strikes, when they don’t get their way
• Like to be involved in all stages of any new development
• Safety and conditions is a top priority
• Can be resistant to change
• Ethical and moral

Interests

• Best outcome for their members
• Exert and gain influence
• Fight for the best working conditions for current and future employees
• Keep their members happy
• Increase the role of the union within all sectors of employment
• OH&S
• Good salary packages for all their members

Benefits

• Unions can be instrumental in pushing productivity if all their members are happy
• They can bring other industries on board
• They can be a good educational instrument in bringing onboard current union members to different changes in an industry which may result in employee resistance (Only if the union agrees to the change)

Penalties

• Can be pushy if they don’t get their way – prone to protest and strikes
• Can impede on minimising the cost of labour.
• Very bureaucratic, and they like to have their say in all stages of the workforce
• Tend to have a very US against the employer viewpoint
• Can resist change if doesn’t suite the union/industry body

Software Developers

Overview

Being a software developer is more then just delivering code, it's just one part of the job. A developer is a team player, who contributes to the success of the project. They work in a team, share knowledge and most importantly work towards helping the customer get the product they want and need. Below are some of the characteristics of a software developer in an ideal situation. However, there are developers that can be good at programming, but can be a bad developer. This is all dependant on their current skills and adaptability to new methods/technologies.

Characteristics

• Excellent programmers, usually good at more then one programming language
• Ability to assess a problem and recommend solution
• Good understanding of project management and development/software life cycle process
• Understanding of Capability Maturity Model Integration methodology
• Effective team player
• Good at sharing knowledge
• Accountable and motivated
• Can be good, bad or average at programming
• Good developers are very expensive and hard to find
• A good programmer may not always be a good developer depending on their current skills and adaptability to new methods and technologies

Interests

• Delivering good quality work / code
• Maximising their income
• Helping the team work to deadline
• Career advancement and progression

Benefits

• Will follow instructions
• Usually get on with their work with minimum disruption
• Good programmers, will allow for the project to run on time
• Good programmers, will lead to clean and effective software in line with the project deliverables

IT Support

Overview

The primary aim of the IT Support is to maintain and restore normal service to all users as quickly as possible. IT Support is a vitally important part of an organisation's IT department and is the single point of contact for IT users on a day-by-day basis. The IT Support logs all incidents and service requests, usually using specialist software tools to log and manage all such events. The IT support is staffed by people with knowledge of the hardware and software being supported, backed with a strong knowledge database.

Characteristics

• 1st level, 2nd level, 3rd level support
• Responsive
• Highly Technical
• Quality support
• Proactive
• Excellent communication
• Different teams within I.T. – Call Centre, Network, LAN, Hardware etc…
• In-house Provider, Shared Services Unit, External Provider
• Process driven / Process Owner
• Documentation
• Knowledge Base Library
• High level of incidents
• Security
• Service Level Agreement driven
• Continual Service Improvement
• Shift towards ITIL compliance – I.T. Infrastructure Library v.3

Interests

• Stable system
• Well documented system / service portfolio
• System is properly tested
• System is easily maintained
• Capacity for support
• Flexible Service Level agreements
• Well resourced
• Properly funded – budget
• State of the art technology
• Low level of risk

Benefits

• Continual stream of income
• Government funded project – well funded
• Good community exposure
• Funding for more employees
• Resolve problems as they arise

Project Managers

Overview

The role of the project manager is to ensure the delivery of projects or strategic programs of work, typically in the hundreds of thousands of dollars to millions, and the successful transition into production. They are responsible for;

• Ensuring the delivery of projects to meet user/business expectations and according to Divisional Project Management methodology and standards.
• Effective monitoring and control of Project milestones, budget, scope, change and deliverables to meet the project success criteria.
• Providing timely and accurate information to the Program Manager, Project Sponsor, and relevant stakeholders on progress, risks and actions to enable effective decision making.

Characteristics

• Manages all other Stakeholders
• Deadline driven
• Excellent relationship management skills
• Structured work ethic
• Good at managing people, vendors and budgets
• Analytical
• Well educated
• Sound knowledge of Architecture and Lifecycle Methodologies
• Attention to detail / big picture
• Work well in teams

Interests

• Staying within budget
• Meeting project deadlines
• Making sure that they are in control of the project at all times.
• Successful delivery of project
• Time is money

Benefits

• Essential for the implementation of a project architecture and design
• Able to coach and transfer knowledge to all involved in the project
• Great at solving problems and adapting to change within a project

Media

Overview

The media is out there to report on how their tax payer funded services are functioning and also to report on the wonderful employees of the Emergency Services which save so many lives and help our community in so many ways.

The media sometimes paints a really positive picture of the Emergency Services and often a highly critical one. It all depends on current public opinion and what will attract more ratings.

With the NSW State Government under continued media and public scrutiny, the media is out there to highlighting any inefficiency of the State Emergency Services and how these inefficiencies are putting the public at risk, as the NSW Government continues to under fund these services and their staff are working exhaustingly long hours under pressure.

With continuing restructures of the services, demands for higher pay, and complaints about the emergency response times, the media is likely to continue to keep a close watch on all the Emergency services.

Some key media players in NSW are: CH 7, 9, 10, ABC, SBS, The Sydney Morning Herald, The Daily Telegraph, The AM radio stations 2UE, 2GB, Radio National, and somewhat the FM stations. The Internet Media largely affiliated with the Television Networks etc.

Characteristics

• Questionable ethics
• Wide reach over a variety of mediums
• Ratings/readership driven
• Prone to bias, manipulation and sensationalism
• Relied on as providers of news and current events

Interests

• Improving profit
• Increasing ratings/readership
• Key media personalities are often focused on advancing their own careers
• Being the first to break a story
• Increasing public opinion of the service they provide

Benefits

• Better public relations stories focused on the positives of people saved by the new system

Stakeholder Rating Assessment

The developers have deduced the ability of different stakeholders to either promote or impede the project on a scale from 0 to 5, where 0 means little ability to have an impact on project and 5 means a strong ability.

Stakeholder	Promote	Impede	Comment
Emergency Service	3	3	Emergency services have a significant say and impact on the project
Public Citizens	0	2	The general public has little impact on the promotion of the project, but can pose a small impeding effect
Emergency "000" Call Centre	3	3	Call service operators have a significant impact in both promoting and impeding. They may be apprehensive towards the introduction of change, but willing to accept a new system that improves their work
RTA	1	3	RTA has no significant impact nor interest in promoting the project but can pose a serious threat in opposing it
NSW Government	5	5	The single most influential stakeholder and financier of the project. Can completely block project if it doubts the efficiency or the withstanding of public scrutiny. It can also promote it if convinced of its merits.
Hospitals	4	0	A stakeholder that can promote the project based on public health best interest. No significant ability to impede.
IT Support	1	4	A stakeholder that is not particularly keen nor has the ability to promote the project, but can seriously impede
Unions	0	3	Stakeholder that has no influence in promoting project, but can pose impeding effect if union members feel insecure
Software Developers	2	5	The developing team has a limited promotional effect, but can pose serious counter productive impact if system significantly exceeds budget and deadlines.
Project Manager	5	5	A very signifacnt stakeholder in both promoting or impeding project. Needs to have long term objectives met by the project.
Media	2	3	Limited promotional impact on project, but can have significant negative publicity effect and impede project.
Insurance / Legal	0	5	No promotional impact, but can pose serious and blocking impact on project.

---

Contextual Factors

Contextual factors compromise of risks, constraints and enablers of different aspects for the projects environment. These contexts shape the state of the system within the environment, outlining current and future opportunities, threats and limitations that need to be factored in when developing the system.

Market / Competitive

Enabler - The need for the current emergency services market to constantly improve infrastructures to save more lives has bought forward the need for capable software development companies to develop such systems that greatly improve efficiency and save time in performing such services. The need for a dispatch system for the NSW government specifically has bought the opportunity for the software developer to undertake this project.

Risk - The introduction of the system may cause new competitors to arise within the market, providing the same system with improved functionality or decreased price, causing the software developing company to possibly lose its contract with the Emergency Services Centre. This will cause loss of revenue and profits to the company.

Social

Enabler - The system will increase the number of lives saved, giving a positive image of the system to society.

Enabler - Media coverage of the system can increase awareness of the system, increasing reputation and also awareness to other potential clients, emergency units in other cities or countries, which will increase revenue and profits to the organisation.

Risk - Media coverage could expose problems of the system to the public, which can cause the public to complain to the government and force the system to not be used, losing business for the company.

Organisational

Enabler - Reputation for the software development company will increase as their product has contributed positively to society as well as assisting emergency units in performing their jobs more efficiently and effectively.

Enabler - The team on the project have members with a high range of skills and expertise, with members knowledge ranging from database, to website and enterprise application development, to socket programming, with a strong knowledge in java programming by all members. Along with the continual knowledge gained in architecture design from attending university lectures on this subject, the team can continually learn quickly and use their skills in synergy to develop the solution successfully.

Constraint - Due to the organisation having just been formed, and the ERDS system the first project conducted by the team, the company does not have much experience in handling such projects alone, with a small team of participants that also have not much skill in programming and expertise in architectural planning.

Risk - Since the organisation has little experience in completing projects, there is a higher risk that the final developed system would contain more problems then if developed by a higher experience company, with more architectural mistakes possible and in the end would have a higher percentage of the solution not achieving its requirements at all, or with problems.

Technological

Constraint - The systems development is limited by the availability of up to date mapping software for the calculation of quickest routes, the coverage and run time of the satellite providing the GPS signal for the system, the transmission of calculated coordinates back to the central system and the power of computer systems to process as many route calculations at once.

Enabler - The GPS system is readily available to send vehicle coordinates for tracking, allowing for instant and efficient processing to allow the other functions of the system such as proximate calculating of routes and dispatching of closest available vehicles determined from the incident locations.

Risk - With using such new technology comes the added risk of failure and compromisation from security threats, which can cause the system to lose efficiency or even be damaged. The system needs to rely on 3rd party systems such as the GPS receiver, which is not in actual control of the organisation and thus there will be risks taken in using the service, from unreliable GPS coordinates to even non-availability.

Political / Legal

Risk - If the system fails to work at certain times, to the extent that it costs a person their life or damage to property, this could bring rise to lawsuits against the developer company.

Constraints - Laws on privacy at current or from changes in the future may to impede certain functions of the system, such as new privacy laws not allowing coverage of private citizens and property through the GPS system, and cause the system to shut down permanently or spend costs in developing a new system with different methods.

Comments

Since the first milestone was complete and the final prototype has been developed, the following changes were added to give a more complete outline of the contextual factors:

- Market enabler - the need for saving more lives and more efficient and time sensitive emergency dispatch services has given the organisation an opportunity to develop such a product.

- Technological enabler of the GPS system was recommended through consultation, and explanation was added for this.

- Technological risk added that covers problems that may occur with the system itself or 3rd party systems in use such as the GPS receiver.

- Organisational enabler, constraint and risk were added to cover more realistic problems and facts currently for the organisation, including the risks from inexperience, skill constraints but also the constant training and wide diversity of skills in developing such a solution.

- Legal constraint, changed the impeding example to a better one that is more valid to the system's function.

---

Customer Needs

The needs of customers is a very important issue to keep in mind for the development of this system. Customers are after all the end users of the system and their needs must be met as objectives of this system for it to be a success. Customer needs can best be elaborated with the use of usage and quality narratives of real situations that may occur. This section describes the relevant narratives for the customer's needs.

Usage Narratives

1. Citizen

Sam has just suffered a heart attack while jogging accross the Harbour Bridge. Jessica just passes by Sam as she witnesses Sam falling to the ground unconcious. She panics and calls up emergency assistance. Due to her shock she is unable to speak loud enough for the emergency operator on the other line to hear, but in due time the operator is able to lock onto the call through their tracking system and immediately dispatches an emergency unit to the location. Thanks to the new emergency dispatch system, the emergency vehicle finds the fastest route to Sam and brings him to the hospital. Doctors just barely saved his life, demonstrating that if the new system was not in place, Sam may not have recovered as well as in this scenario.

2. Emergency Call Centre

Robert is an emergency call operator at the local Emergency Call Centre. He receives calls on emergencies where he communicates with the caller to find out information on the type of emergency and the location of where it has occured. The caller is telling Robert that their house is on fire and gives Robert the address of the incident. Robert logs the data onto the computer system, and immediately calls the closest fire fighting unit from the location of incidence. Robert also sends them the directions of the fastest route calculated by the new emergency dispatch system and sends this electronically to the person in charge at the fire unit.

4. IT Support

Lila is an IT support staff for the Emergency Dispatch System. She has been thoroughly trained to understand the entire new system, and to solve any possible problems as they arise. She receives calls from the emergency centre operators that are having difficulty using the system, or that want to provide feedback or problems within the system. Lila listens to all the information provided, and uses her knowledge to provide a solution to the callers problems or record feedback/problems as she logs the process and outcome onto her computer.

5. ICT Infrastructure and Hardware

Thomas was hired by the government to assist in the setup of the new facility to house the servers that support the Emergency Despatch system. He understands the critical nature of this system and the fact lives will depend on its success. He knows that in setting up the system he will have to be careful in both the physical and theoretical layout to ensure maximum efficiency, reliability, performance and security. This includes outsourcing concerns relating to constant power supply and network topology to specialist technicians to ensure the job is completed successfully.

Following the completion of the setup, Thomas sets about testing the facility. During this testing a faulty power supply in one of the servers gives way, however before the early warning smoke detection system can activate, the system detects a loss in power and immediately switches into recovery mode, as the backup server seamlessly takes its place.

6. Normal Usage Case

Joanne notices smoke coming out of her neighbour’s property. She goes out to investigate and confirms it to be on fire. She tries to find out if anyone is trapped inside. Indeed she can hear some screams and coughing but can not get past the front door. In a desperate condition, she rings the emergency department and the operator enquires on the number of people that might be trapped. The operator then decides that it will be appropriate to dispatch one ambulance vehicle and one fire brigade unit to attend to this emergency.

7. Hotline Amendment

The police are called out late at night to a brawl in a pub. Upon arrival they hear a gunshot. Quickly they get engaged and get the situation under control, but a person is already injured. So they call the hotline of the dispatch centre to get an ambulance to attend to the injured quickly.

8. State Change from Active to Offline

John and Sarah are two ambulance officers. They are on their way to an emergency when John notices something wrong with the car. The engine temperature gauge indicates above normal condition, but John decides to continue. Unfortunately the engine starts to boil and stops not too far away. Sarah quickly turns to the in-car terminal and changes the unit status from “Active” to “Offline”. This event triggers the emergency dispatch system to be notified of the change. Having an incident now unattended, the system searches available nearby vehicles again and assigns another ambulance unit for it. In the mean time Sarah communicates with her supervisor over the radio, advising him of the breakdown and has him arrange the maintenance crew come to their assistance.

9. State Change from Active to Idle in Transit

Tom and Jeff are ambulance officers that had just dropped a patient off at hospital. Tom changed the unit status from “Active” to “Idle” on the in-car terminal. This notified the emergency dispatch system of the change. A few minutes later an incident is logged where Tom and Jeff are in the immediate vicinity. The dispatch system aware of their status as “Idle” correctly assigns the new incident to them.

10. Addition and Removal of Vehicles

The police service has decided to replace ten of its aging vehicles with new ones. The new arrivals have to be fitted with all the police standard equipment and radio. Up to the stage when all these modifications are done the dispatch system is unaware of the existence of the new vehicles. When the modifications are complete the police service, through their dispatch system terminal, adds these new arrivals to the “Available Matrix” with the status “Offline”. Only when the vehicles are appropriately manned that their status is changed to “Idle” and thus ready to attend to emergencies. By the same token the older vehicles have their status changed to “Offline” thus ensuring no new incidents are assigned to them, and any current assignments are transferred. Consequently they are removed from the “Available Matrix”. This ensures that the dispatch system no longer keeps track of the retired vehicles, freeing up searching time. The system still holds records of those vehicles in the history database which can be queried for statistical purposes.

11. System Statistics

There is a growing feeling in the State Emergency Service headquarters that travel distances covered by the vehicles stationed in the Berowra dispatch centre exceed the national average substantially, and that a considerable percentage of these are not active duty kilometers. A request is made to the Emergency Response System to report all travel activities from the nominated dispatch centre and match it against the state average, excluding the nominated centre, for the last quarter. The report indicates that travel distances of the nominated centre agree with the state average, and that the only disagreement is on the idle travel distance which stands at 16.8% in comparison with state average of 13.4%. This is readily explained as the overhead in maintenance travel because the centre is the furthest away from any workshop. Thus the statistics presented by the Emergency Response Dispatch System dispels any wrongdoing on the nominated centre side.

12. Incident Logging

Drake is a call centre operator for the emergency centre. He receives a call all of a sudden, listening to a pleading woman who has injured her leg just now. Firstly Drake asks the woman for her name and description of current location, which he types up in the logging software on his computer. He finds out that she was hit by a falling stack of bricks from a construction yard just outside George Street in Sydney. Drake places the address of the incident into the system, and confirms the incident to be processed by the system so that the emergency dispatch system can find the closest available ambulance trucks within the incidents location radius.

13. Reporting

Gerald, the manager in charge of the emergency centre, requires to view reports on the emergency dispatch system within the last month to evaluate and compare the current month’s performance to previous months. He has to make sure the system works perfectly and that all incidents are solved at the highest efficiency and effectiveness possible. Gerald logs into the system and generates several reports, including vehicle movements in total for certain periods in the month, individual vehicle movements, activities from nominated dispatch centres and activities to nominated regions. Gerald can now use methods such as standard deviations and covariance to compare criterias such as distance travelled by all vehicles and certain vehicles per incident for this month and last month to determine if the dispatch system has travelled the least distances to their incident locations.

14. Maintenance Crew - Scheduled

Joseph is a ambulance mechanic working for the Parramatta ambulance dispatch centre. It is his responsibility to ensure that all ambulances are in working order and to minimise the chance of breakdowns. Joseph comes into work and looks at his scheduled maintenances for the day. He begins verifying that the ambulance is in the Parramatta ambulance parking lot. He then uses the in-car unit changes the vehicle status to off-line for maintenance. He is then assured that this ambulance will not be dispatched to an emergency while undergoing maintenance. Joseph completes all maintenance work for this vehicle just before lunch and makes the vehicle on-line ready to be dispatched to any emergency.

15. Maintenance Crew - Breakdown

Sally an experienced mechanic in Blacktown received a call at 11am informing her that a fire engine on-route to an large house fire had broken down. This fire engine was Blacktowns largest fire engine and Sally knew that it would be critical to have the vehicle fixed to assist in this fire

Sally promptly arrived to where the fire engine had stopped and preformed emergency temporary repairs to the vehicle. Sally changed the in-car unit status to online and the drivers of the fire engine thanked her as the system on-board navigated them to join with their colleagues in putting out the house fire.

---

Quality Attributes Assessment

Stakeholders were given 10 points to allocate which qualities they wanted to see most within our product. The following table shows this allocation:

Quality Attributes	Total	Emergency Service	"000" Call Centre	NSW Governamnt	General Public	IT Support	Project Manager	RTA	Hospitals	Unions	Software Developers	Media	Insurance / Legal
Performance	19	3	2	1	3	1	1	2	2	1	1	2	0
Usability	12	2	3	1	0	0	1	0	0	3	1	1	0
Reliability	23	3	4	1	3	1	1	2	3	1	1	3	0
Security	38	1	1	2	4	2	2	3	3	5	1	4	10
Maintainability	7	0	0	1	0	1	1	0	2	0	2	0	0
Testability	3	0	0	1	0	0	1	0	0	0	1	0	0
Reusability	3	0	0	1	0	0	1	0	0	0	1	0	0
Configurability	6	0	0	1	0	3	1	0	0	0	1	0	0
Scalability	9	1	0	1	0	2	1	3	0	0	1	0	0

---

Quality Attributes

1. Availability

Target Availablility 100%

• Power Reliability

Reliability of the system is also governed by the uptime of the servers that control the system, of which power is a key determinant. Paul is a power technician assigned to the setup and ongoing maintenance and monitoring of these servers. The system must be operational 100% of the time to ensure maximum reliability, and when he was planning the system he took this into consideration. Paul fitted all servers with redundant non interruptible power supplies to ensure that they remained operational during any minor power outages or surges. As a secondary level he built in redundant power generators that run on diesel fuel to supply power to the servers in the event of a long power shortage. Enough fuel is carried on site to support 7 days without mains power, however Paul still did not feel this was sufficient, and has also established contracts with fuel suppliers that include urgent replenishment clauses. Paul has wired power monitoring into the security system so that he is notified the instant there are any unforseen changes. He is confident he will achieve his KPI of 100% uptime for the Emergency Despatch System through these initiatives.

• Network Reliability

The complex system of servers that supports the Emergency Despatch system communicates through a complex intranet and the Internet. Reliability of these Network connections from user consoles to the main servers and vice versa, directly relate to the reliability of the Emergency Despatch System. Gary is a Network technician assigned to ensure multiple levels of redundancy in this system so that is will never falter. He has achieved this through the establishment of links to not just one, but many different internet backbones from the main server farm. With this level of redundancy, if one link becomes inactive, consoles will still be able to achieve connectivity through routing around via the many other 1 gigabit and 100 megabit links that service the network.

It is a requirement of the system to be available 24/7 (i.e. No down time). To address this requirement the designers have decided to implement the system on identical hardware (preferrably on different physical location to minimize the risk of location related accidents) running in synchronism. Only one of them shall be in active operation and the other on hot standby. Should the standby system sense communicatation failure on the active system side, or instructed (e.g. as a U.P.S. notification of power failure) to take over active duty it shall do so, and the other system will be put on standby. This arrangment also accomodates the instances of harware failure or software upgrades.

The database servers are designed to be commercially available ones (in our case MySQL due to availability in the laboratory) which can be arranged in redundant arrays. The designers have determined for reliability, data integrity and proccessing speed requirements that the database servers and ERDS servers be allocated different hardware to run on (although strictly speaking they can be run on same machine). The recovery of database servers from crashes and data consistency is relyed on the third party database software.

The systems shall run on Uninterruptable Power Supply (U.P.S.), so that in the case of power failure there will be no abrupt loss of functioning, but a signal will be sent to the standby unit to take over active operation.

2. Security

Target No breach of security

Management has required that all data should be kept secure from outside interference, both eavesdropping or altering. The designers have decided that all system login's have to be authenticated and assigned privildges according to the role of each user. These privildges will be assigned by the system administrator. Moreover, they have decided that all connections, to remote servers or emergency services shall be encrypted. The only exception is the HTTP server connection to the general public, which does not require authentication nor encryption as it carries no critical data and available for viewing purposes only.

To improve security the system also employs Hot Failover Firewalls; two firewalls that work in unison and can be switched immediately in the event of a malfunction in one.

3. System Performance

Target Perfromance : 2 seconds system initial response from user initiated action

The designers have agreed that the database needs to be regularly archived, so that non-current data is stored as history files. This will lead to having the search and tracking functionality work with minimum latency, while retreiving tracking information function normally. It is proposed to have regular archiving routine performed either daily or weekly.

The designers also propose the Tracking system to record values for location of each vehicle at regular intervals, in this case, two minutes. An additional proposition is to record only values if they differ from that last ones. The reasoning behind this is that if two or more consecutive location values are identical then the vehicle can be regarded as stationary and a single record representative of the value. Utilising these data minimization methods will lead to a compact database for the tracking system, improving data search times, without a detrimental effect on the quality of tracking.

4. Scalability

Target System scalable area wise from NSW to nation wide , and scailable in number of vehicles , despatch centres , regions , emergency services.'

The system with the proposed architectural design is readily scalable. The number of emergency services, regions, dispatch centres, vehicles and their availability is easly updated in the database and thus become available to ERDS to consider and deal with. Also the extensibility to a nationwide system is similarly feasable by a simple expansion of the underlying database.

5. System Longevity

The proposed system architecture takes into account future updates and accomodates for unforseen requirements. The reliance on database for data persistence ensures the compatability of current components with a future updated version of underlying database. Utilizing table views is considered as a vital aid towards this goal. The same reasoning can be equally applied to an expanded set of requiremtns. The underlying architecture will continue to support the currently defined set of data, meanwhile any expanded functionality will coexist with an expanded set.

---

Inception of Conceptual Model (Initial Attempts)

In this topic we present the initial attempts in identifying conceptual model components based on the quality usage narratives.

• Robert is an emergency call operator at the local Emergency Call Centre. He receives calls on emergencies where he communicates with the caller to find out information on the type of emergency and the location of where it has occured. The caller is telling Robert that their house is on fire and gives Robert the address of the incident. Robert logs the data onto the computer system, and immediately calls the closest fire fighting unit from the location of incidence. Robert also sends them the directions of the fastest route calculated by the new emergency dispatch system and sends this electronically to the person in charge at the fire unit.

Candidate Component	Comment
Emergency Call Operator	A user, needs an interface to system.
Emergency Call Centre	A collection of previous components.
Information of Emergency	Not a component itself, but inferes the need of data storage elements
Emergency Address	Redundant, as this is contained in previous item.
Location	Redundant, the information contained in item Information of Emergency
Fire Fighting Unit	Another user of the system, will need an interface.
Fastest Route	An interface component for miracle system.
Emergency Despatch System	The system we are creating.

Version 1 Conceptual Model

Domain Responsibilities

Emergency Despatch System

• Interface with Call Centre Operator
• Interface with Fire Fighter Unit
• Interface with Miracle System
• Communicate with Incident Database
• Make Despatch Processing and decesion

Note: This component is overloaded with responsibilities. It has to communicate with all interfaces also with database, in addition to despatch processing. In conclusion it emerges as a "Blob" and in further revision its responsibilities should be cut down to clear related operations.

Call Centre Operator

• Provide a system interface to call centre operator

Fire Fighter Interface

• Provide Emergency System Interface to Emergency Despatch System

Note: It is desirable to eliminate the constraint for this component to be for a single emergency service interface, and have it as an interface to any emergency service, including "Police" , "Ambulance" , "Fire Fighters" , "State Emergency Response" etc.

Incident Data

• Persistant Storage (database) for incident information

Note: Lacks details about what information to store and data operations and interfaces.

Overall Comment on Version 1

This version is rather crude. It represnts a first step in capturing some of the system components such as user, operator , emergency service, miracle system interface and data storage and processing, but it centralises all repsonibilitiles to one main component which is a drawback.

• John and Sarah are two ambulance officers. They are on their way to an emergency when John notices something wrong with the car. The engine temperature gauge indicates above normal condition, but John decides to continue. Unfortunately the engine starts to boil and stops not too far away. Sarah quickly turns to the in-car terminal and changes the unit status from “Active” to “Offline”. This event triggers the emergency dispatch system to be notified of the change. Having an incident now unattended, the system searches available nearby vehicles again and assigns another ambulance unit for it. In the mean time Sarah communicates with her supervisor over the radio, advising him of the breakdown and has him arrange the maintenance crew come to their assistance.

Candidate Component	Comment
Ambulance Offciers	A system user, included as part of the Emergency Service Interface.
In car terminal	As previous item, included in Emergency Service Interface.
Vehicle Status	Data, not a component itself but implies the existance of fields of status describing vehicles in database
Emergency Despatch System	The system we are creating.
Nearby Vehicles	Piece of data, not component itself, but implies the existance of tracking of vehicles in locations at all times.

Conceptual Model Version 2

Domain responsibilities

The components are all listed in the previous version in addition to two new elements.

Vehicle Tracking

• A database component that keeps track of location of all services vehciles at all times.
• The database also includes field about the status of a vehicle whether it be despatches, active or offline
• A realtime property has been atteched to this component to emphasise that the database should be in realtime synchronism with the actual vehicles on the road so that the despatch system will not use outdated data

GPS Interface

• An interface to a GPS system in each vehicle, so as to continusouly communicate with Emregnecy Despatch System Vehicle Tracking sub-system and update it.

Version 3 Model

• Gerald, the manager in charge of the emergency centre, requires to view reports on the emergency dispatch system within the last month to evaluate and compare the current month’s performance to previous months. He has to make sure the system works perfectly and that all incidents are solved at the highest efficiency and effectiveness possible. Gerald logs into the system and generates several reports, including vehicle movements in total for certain periods in the month, individual vehicle movements, activities from nominated dispatch centres and activities to nominated regions. Gerald can now use methods such as standard deviations and covariance to compare criterias such as distance travelled by all vehicles and certain vehicles per incident for this month and last month to determine if the dispatch system has travelled the least distances to their incident locations.

Candidate Component	Comment
The Manager	A new system user, will need an interface to support him/her.
Report	Data to be stored in system databse.
Last Month	Period of activity for report, probably redundant information
Logs into	The system should support logging of different users.
Generate reports	Process of reteival of data from database.
Vehicle movements	Data retreival from Vehicle Tracking database
Region	New data, implies the division of emergency services into regions in database.
Despatch Centre	Another piece of data, which implies the further division of regions into despatch centres.

Version 3 Conceptual Model

Domain Level Responsibilities

Login Server

• A new component in this version. It was introduced due to security reasons and to facilitate the login process for different kinds of users.
• Communicate with User Role database components to retreive user crudentials. Users are only allowed to perform tasks within their predetermined set of operations. Example, a call centre operator is inhibited from running reports on system

User Roles

• Keep data about users, validation data and allowable operation for roles

Incident Recording

• The Emergency System "Blob" of previous version is broken down, so that any new incident is recorded into database via this component
• It receives it's flow from the server, and hands over flow to Vehicle selection Component

Vehicle Selection

• A components to receive incidnet data, check vehicle tracking and find the closest set of available vehicles
• Communicates with Miracle System to make a decision (upon mircale system input) which vehicle to despatch based on the proximity and best suited route
• Communicates decesion to Emergency Service through the designated interface

Report Generator

• Receives report requests from Management Users (through login server), queries databases of vehicle tracking , regions, despatch centres and forwards response to management UI.

Region

• A database of division of emergency services into regions.

Despatch Centre

• A further division of regions into despatch centres
• Facilitates the report running for individual region and despatch centre

---

Conceptual Architecure

Conceptual Model

The following outlines the conceptual model of the proposed system and the domain level responsibilities for each component.

Discussion

The key issues that this architecture attempts to address are that of

• Reliability (100%)
• Performance (2 seconds initial response to user action)
• Scalability (in terms of number of vehicle, Despatch centre, Region, Emergency Service and area from NSW to nation wide)
• Security

A key decesion is to have the system as distributed one. This design allows for mulitple instances of both user interfaces and login servers. The component Broker plays an important role in both acheiving high reliability and performance. Its responibility lies in keeping track of every Long In server available on the system and its current load. The load of a server is defined as the number of open connections to user UI's. By continuous interrogation of the server instances the Broker keeps track of their availability and load. When a new user UI want to establish a connection it first seeks the address of the LoginServer from the Broker. The broker provides the IP address in such a way as to balance out the load evenly between the servers. This helps achive two of the critical targets namely reliability and performance. The high reliability is acheived by the dynamic nature of server instances creation / destruction. If an instance of a server crashes, the broker by its continuous polling will know of this fact and as a result redirect new connections away from it. The performance target is also acheived by balancing out the traffic load among the servers. If a particular server becoms heavily loaded (defined here by the number of connections it is currently serving) and hence its performance degrades, the broker in assigning new server connections will divert away from this busy server to less congested ones. It remains the responibility of system administrator to monitor system performance as a whole and start new server instances if need be to acheive performance and reliability targets. The broker itself is distributed service, for there may be a number of brokers on the system and each User UI instance keeps a table of brokers (in hierarchical order in a similar way to DNS servers having primary, secondary , tertiary etc) and searches through the list till it finds the first one.

Another key design decesion is to have the persistant data storage provided by off-the-shelf SQL Database server (in the design MySQL is designtated although in prototyping HSQLDB was used so as to avoid installation of software onto the lab machines). The database server is envisaged to be replicated synchronised distributed environemnt. Scalibility is acheived by the scalibility of the underlying database, tables of vehicles location can easily be extendible. Data persistence and integrity is relyant on the database server for acheivment. This whole system of Emergency Despatch Response System can be viewed as a database storage / processing application. The essence of the system is in the integrity of the database. Instances of User UI, Servers and Brokers can be created, destroyed or even crash but as long as the data in the database is consistent the system is functional.

Security is addressed by a two tier system. The first is that instances of User UI and Login Servers share authentication tokens. The server checks the token in every transaction , and if invalid the request is ignored. This way any unauthorised access is denied. The second level is provided by the need to know policy. Two tables are kept and qureied in database, one for users and the second for roles. Each user is assigned a role which specifies which priviliges it has. Upon login process the server queries the database and matches the user name with passowrd. If login successful the role token is stored and for any subsequent transaction is checked for clearance.

Real Time attribute is assigned for time critical components of the system, namely the ones interacting with the GPS and vehicle tracking sub-systems. The GPS position update is carried out in cycles (field testing required but a priliminary optimised values would be every 20 seconds). The data in the databse needs to be updated by the time the next GPS update comes through or else vehicle tracking data will be lost. So assigning real time components with target data processing deadline inline with GPS update cylce is reasonable.

Other quality attributes like Usability are inherent in the design of user interfaces to be user friendly.

Component Domain Level Responsibilities

Broker

• Keep track (IP address and load) of Login Server insatnces
• Provide Incident UI and Management UI requests for Login Server address

Login Server

• Process all system login requests
• Identify Users through user ID
• Match user ID with their defined roles and access rights
• Forward User requests and system response

Incident UI

• Present user with interface for entering incident details, with auto display of locations where possible
• Present vehicle dispatch information

End User (Public) / Call Centre Operator - (User Interface)

• Provide system interface for call centre operators on the phone with call reporter (general public)
• Provide vehicle dispatch information

Emergency Service Hotline - (User Interface)

• A preferred user interface designated for emergency service hotline
• Can perform incident reporting
• Can query vehicle - incident dispatch information

HTTP Connection - (User Interface)

• A web based incident query interface
• Can query recorded incident and vehicle response

Management UI - (User Interface)

• System Interface for management queries
• Provide system query results

Incident Recording

• Process complex task of incident recording in concerned databse tables (incident, user)

Proximity Finder

• Searches for idle selected emergency vehicles in increasing radii of 5 Km from incident
• Queries the Routing Miracle System for route and metric (estimated time of arrival) for each available selected vehicle
• Forwards results to Dispatch Vehicle

Dispatch Vehicle

• Makes a decision based on proximity Finder and Routing Miracle System metrics on which vehicle to dispatch
• Record Dispatch details in dtatbase Incident_vehicle_Matrix table
• Forward emergency service involved with dispatch information

Track Processing

• Receives GPS location data for each vehicle from emergency services
• Filters individual vehicle data
• Updates Tracking Table database

Report Processing

• Queries requested database tables for information
• Presents results to management UI

Emergency Service - (external Interface)

• Interface to Emergency Service Vehicle Availability status update

To Emergency Service - (external Interface)

• Interface for relaying dispatch information to involved service to forward to vehicle

Vehicle Availability Matrix - (Data Component)

• Table indicating state for each vehicle (idle, offline, dispatched)

An emergency vehicle is represented in ERDS as being in one of three states. This indicates to the system whether is available for dispatch of an incident, actively responding to an incident or simply offline and can not be assigined any jobs due to maintenance, breakdown , resupply or any other reason. The following state diagram represents these states and the transition path between them.

Offline State

This state is the one when a vehicle is excluded from search and dispatch activities. This state is reached through the emergency service by which the vehicle is operated. It is the emergency service that takes a vehicle offline, and when cleared, to put it back online or "Idle" state. The reasons for being offline may include breakdowns, maintenance and resupply.

Idle

This state is when a vehicle is ready, either be it stationary is disptach centre or in transistion after dropping off patient at hospital, to receive another dispatch order.

Dispatched

This state is when a vehicle is dispatched an incident. It encompases the states when the vehicle is in transition to, or attending the incident. A link is provided so that if brokendown in transit, that a vehicle may make a state transition to "Offline"

User Role - (Data Component)

• Table containing user ID and privileges
• Updated by system administrator

Tracking - (Data Component)

• Table keeping track of location of individual vehicle

Vehicle - (Data Component)

• Table for vehicle identification data
• Information used for vehicle tracking, availability, and management reporting purpose

Dispatch Centre - (Data Component)

• Table for relating vehicles to dispatch centers
• Used for reporting purposes

Region - (Data Component)

• Defining the breakdown of emergency services to regions
• Used for reporting purposes

Incident - (Data Component)

• Table keeping track of incident, location, users and vehicles involved

---

Data View

The following is the proposed data model to capture the most relevant data to the operation of the system. Also a visualisation of the Miracle System is given, though it is considered to be outside the scope of ERDS.

Visualization of Miracle Routing System

Comments

An incident is linked with at least one user (member of public), either involved in it or reporting it. The incident is logged by an operator in the call centre (receiving the call of a user), then he/she decides how many and type of emergency vehicles to be dispatched.

Any operator can later change the number and type of emergency vehicles dispatched. An emergency service is divided into regions and each region consists of dispatch centers. The vehicles are housed in individual dispatch centre. This division is made to facilitate the later requirements of assignment in relation to searches of activity from a nominated dispatch centre or region.

Each vehicle is manned by at least one staff member of the emergency service. Tracking is the essence of the database that relates vehicles with date and time of day to their locations. The visualisation of Miracle Routing System is not a part of given assignment (as it is stated that we are to assume to having a “miracle system that will deduce and provide route between two end points”. It is only depicted to help facilitate the visualisation of the entirety of the database.

Updated Data View

The new data modle reflect the changes made to the database model throughout the development life of the project, and also the actual implementation of the database in HSQL.

---

Behaviour

Use Case Maps

Incident Logging Use Case

The above use case map demonstrates how the ‘Normal Case Usage’ narrative is performed through the actual system.

1. The victim Joanne reports the incident to the emergency call centre. The operator responds and determines from the caller that there has been a fire in her neighbourhood. The operator logs onto the dispatch system.

2. The operator connects to the dispatch console, the console automatically recognises the operator and provides him her with the incident reporting interface.

3. The operator records all the details of the incident and the user into the system. The user details are recorded on the user database. The incident details are recorded on the database.

4. The system checks for all available ambulance and fire brigade vehicles within the area of the incident.

5. The proximity finder receives information from the GPS tracking of the location of the closest fire and ambulance vehicles and processes the path to follow to arrive to destination of the closest vehicles.

6. The closest ambulance and fire vehicles are dispatched and sent to the location of the incident.

---

Management Report Use Case

The above use case map demonstrates how the ‘Reporting’ narrative is performed through the actual system.

1. The manager, Gerald, logs into the system. The system authenticates the manager and provides him with the relevant management interface.

2. The manager prompts the system to generate reports regarding the use of emergency vehicles in dispatch centers and regions.

3. Gerald queries the reporting generation system with the required information.

4. The system retrieves appropriate data from the tracking, vehicle, dispatch centre and region databases and processes the data to produce all required reports for the manager.

5. The system proceeds to display reports of results using the retrieved data for the manager to assist in his decision making.

---

Vehicle Tracking Use Case

The above use case map demonstrates how the ‘vehicle tracking’ narrative is performed through the actual system.

1. Senior Sergeant Mike, the manager of the police station needs to find the location of one of his units. He queries the Vehicle matrix server.

2. The matrix server queries the availability of the vehicle. In his case, the status is “attending to incident”.

3. If Mike needs more details about what incident the vehicle is tending to, he queries further into the system, prompting the system to connect Mike directly to the unit in question.

---

Vehicle Tracking Use Case

The above use case map demonstrates how the ‘maintenance' narrative is performed through the actual system.

Anna has just completed maintenance on one of the ambulances in her workshop. The ambulance is sent back to the center. She needs to update the system to make the vehicle available.

1. Using the vehicle finder system, she updates the vehicle status.

2. The update is passed applied to the vehicle availability matrix.

---

Dispatched Vehicle Breakdown Use Case

The above use case demonstrates the sequence of components involved when a vehicle attending an incident breaks down.

• The vehicle informs it service of the breakdown
• The service updates the state of the vehicle in the availibility matrix
• This triggers an event to ERDS to check whether the vehicle was in dispatched state.
• The proximiy finder, availablity matrix, miracel system, vehicle tracking and dispatch vehicle components get involved in selecting another vehicle to attend the emergency

---

Implementation

In implementing the conceptual architecture, it needs to be certain that the model covers all required domain-level responsibilities, with all components linked to related components that require communication amongst each other. The component's functions will be determined from the user requirements as observed and documented beforehand, with key components in this case obtained from the usage and attribute narratives described previously. The external interfaces will need to be linked to all components that will need access to such hardware interfaces where required.

Through analysis of the narratives, it was determined that the key components to be used will need to perform the following functions: - log in a user into the system, with different permissions available. Users will include the operator that records incidents, administrator of the system and managers seeking reports. These users will need to access the system from the office or remotely if required, through either an application or web interface. - Key components of the system would perform the functions of recording incidents, finding available vehicles, determining the closest vehicles to a location and despatching these vehicles. The system will also need to generate reports for the managers and administrators. - Some key components will need to link to external interfaces, such as the GPS service that obtains coordinates for vehicles, a system that determines the quickest route for vehicles to a location, and querying to and from emergency service centres to allow communication of availability and dispatching commands for the system. -Certain components will need to record, retrieve and/or query databases to perform functions such as recording incidents, and retrieving data for report generation and displaying.

The use case diagrams were used as benchmarks in creating all the required components, connections, external interfaces and data banks as their basing on the user requirements directly demonstrate what is needed in the architecture. Observing all the use cases, every single component was used at least once, and if an extra component was required to implement an important user requirement, it was added in the architecture. The reporting components were especially improved several times to add more data banks that was required to generate appropriate reports, including the addition of the tracking data bank to store a history of vehicle locations as required by the managers.

Component choices

The system has several of the shelf components that are used as sub-components to the system in each layer of the architecture. Sockets and serialisation components have been used from the java component library. The project is more reliable, robust, secure and higher performance than if they were developed out of the java primitives for the project.

It is possible and well documented to develop a custom XML serialiser which is more versatile but for the purposes of the dispatch system the built-in binary serialiser converted to a binary hex stream was suitable for transmission of objects. The limitation of this is that the transmitted data could not be automatically upgraded to a new version of the type it represents. This was not a concern as the data transmitted would not be recorded or replayed on a system with a different object model.

The database system HSQL used as an off the shelf component. It is possible to develop a custom database engine but this was outside of the scope of the system and it is not feasible to develop an equivalent quality database system.

The primary factor used to demine if an existing component was used or if a custom built component would be used was the availability, suitability and scalability of the component.

The cross-server messaging component is available as an existing off the shelf component but the cost and suitability compelled the team to develop one in house for the project.

---

Constraints

The architecture is limited to just the current known requirements, with no definitive knowledge yet of what technologies will be used to actually develop the solution into a real-world product. It is also unknown how the external intefaces will truly function due to their control by other parties, with their constraints not yet known until the system is actually developed.

The architecture will need to be designed in mind of the time constraints, thus not all the desired requirements of the stakeholders can be met. The main example is the Emergency Services requirement for a highly scalable system, but through the stakeholder rating was beaten in votes by several other quality requirements including availability and public transparency, thus the architecture was designed with higher availability in mind through the feature of accessing on the HTTP protocol over developing higher scalability.

Also due to time constraints, only the most important use cases were developed to demonstrate the behaviour of the system. These included cases for dispatching vehicles, reporting and vehicle management. These cases though did cover all the constraints of the system, they may not have covered every single possible use of the system such as retrieving all possible custom report types.

---

Execution Architecture

Structure

Concurrency

The concurrent activities, which are activities occuring at the same time within the system, are demonstrated within the above diagram. We observe the following events in the concurrency view:

Components

UI Operator

• Interface for the users to perform incident recording and dispatching on the system.
• Synchronously allows many users to access the system at a time for multiple simulatanous incident reporting, with callback communication to display feedback to user for necessary acknowledgement of their actions.
• Activity is user initiated for the operator to perform incident functions on the system.

UI Management

• Interface for the manager to obtain reports from the system.
• Synchronously allows many managers to access the system at once to obtain reports, with callback communication to display the report results to the user.
• Activity is user initiated for the manager to perform reporting functions in the system.

Broker

• Brokers the communication between the user interfaces and the incident reporting system.
• Uses callbacks to send and retrieve information as an active activity for authorising users into the system, sending and retrieval of commands.

Operator System

• Performs authentication of the various users including operators, managers and administrators.
• Distributes callbacks to the incident recording, tracking and reporting systems. For incident recording the operator system sends data depicting a new incident then receives feedback of the success of the recording. For the tracking system, the tracking and dispatch details are sent to the operator to confirm of the locating and despatching of available vehicles. The reporting system queries the database for desired reports input into the operator system, and results of the report sent back to the operator system.
• Activity is service based as it runs in response to the UI Operator or UI Management when an incident or reporting activity needs to take place.

Incident Recording

• Receives new incident details from user and synchronously updates the data onto the database.
• Confirmation of success of incident recording into database is sent back in a callback to the user.
• Activity is an active thread and immediately records incident details as it receives.

Incident Database

• Stores incident details of an incident including data on incident and users involved in the incident.
• Data is stored upon requests from the incident recording component.

Tracking System

• Asynchronously receives initiation from the incident recording database to find available vehicles through the GPS system and determine the best vehicles to dispatch to the incident using the miracle system.
• Activity is active and continuously receives tracking information on all vehicles in the system and their statuses, with dispatch information sent asynchronously to the despatch system as it requires.

Reporting System

• Sends queries to the database for report generation and receives results through callback to be sent back to the operator console when requested.
• Activity actively receives report requests and sends detailed results to the operating system for users.

Tracking Database

• Stores tracking details of vehicles including statuses of vehicles at present time, and timestamps of the location of all vehicles at different points in time.
• Data is received constantly in synchronisation from the tracking system as vehicle details are determined, and the activity is a service that initiates on requests from the tracking system to store data.

Dispatch System

• Receives call to despatch required vehicles, with feedback sent back to the tracking system of the success in dispatching.
• Asynchronously sends vehicle dispatch data to the vehicle dispatch relay to perform the actual dispatching in real life.
• Activity initiates as a service from requests from the tracking system of when vehicles need to dispatch.

Usage

• The operator is accessing the operator system synchronously to send incident data in complete packages. Callbacks will occur after every confirmation of the system including the incident being recorded successfully along with confirmation of tracking and despatch successes.
• The system will be accessing both the logging and tracking system asynchronously to save time as the system searches for available vehicles within an area while the incident is recorded at the same time.
• The tracking system will continuously receive data feed from the GPS, emergency centre data and the miracle system so that the appropriate vehicles are found to be ready for dispatching in the most timely manner. All vehicle availability data will be backed up to the database after the appropriate vehicles are allocated, in synchronous mode due to the need to update database entries one at a time.
• The dispatch system will immediately despatch all vehicles as they are approved for the most efficient attending of incidences.

Reporting

• Managers access the reporting system synchronously to request reports of which results will be returned to them through callback.
• The reporting system will retrieve data from the tracking database for processing and generation of reports with results requested.

We have decided to use concurrency due to two main factors. One main factor is performance enhancing due to the existence of the incidence and tracking databases, slow devices that must be waited upon for each write, but can be read asynchronously such as in the case of retrieving data from tracking database into the reporting system on requests.

Another factor is that of scalability where there are a number of different systems in different locations that need to be accessed simultaneously for efficient processing such as when the system both records incidences and performs tracking and vehicle allocating tasks. Another task is with the need to retrieve data such as through GPS asynchronously as the system needs to continually obtain this data to track incident and vehicle locations for the miracle system which also must process this data at the same time to find the best vehicles for dispatch.

Comments

After the first milestone, the concurrency processes were reevaluated and the diagram modified to contain the truer state of the executional prototype in development. Also descriptions of the components and their purpose has been added for better understanding of the concurrency by the reader. The changes include: - The operator system will be accessible by both the operator and manager, as it was determined more efficient to just use one interface for access then repeat for two. The system instead authenticates both types of users for the same interface and limits access to what they are authorised to use. - The incident recording, tracking and reporting systems all now send callbacks instead of just asynchronous calls, to provide the operating system feedback of process success to finally inform the users. - The dispatch system also now provides a callback to the tracking system to confirm despatching of required vehicles, so the user is also informed of this important information.

Deployment View

The deployment view demonstrates the mapping of the software elements of the system onto the hardware elements. The concurrent subsystems of the EDS are presented on an overlay with the physical view of the system.

The decision has been made with the team to split the processes of the system under 3 main server types:

• web server for presentation to client. This encompasses the web interface which allows users of the system to interact with the system through the web protocol.
• application server for storage of application systems and their processing. The main systems including the despatch, tracking and reporting systems are placed on this server.
• database server for storage of all the databases in the system. Both databases to be used in the system will be placed on this type of server as seperation of data and applications is essential for the system to be highly scalable.

The tracking server is also displayed in a subsystem view, showing how the different aspects of this system interact to track and find available vehicles for despatching. The retrieving of data from the database to assist track and vehicle checking is also demonstrated, along with the other system of reporting and login servers also obtaining data seperately from this database. This further demonstrates how the relational database is highly scalable by being accessible by many different systems.

Comments

After completion of the milestone 1 and the prototype, looking back at this deployment view correctly shows how the executable was deployed as our original plan here intended. Firstly the web server was successfully deployed as a seperate access point to the UI Client executable but both accessed the application server processes identically to create incidents, build reports and vehicle maintenance functions.

The executable contained all the application server components as above in built as java beans, including the tracking server's subsystem itself. The database had it's own running server that communicated with the applications, which could be deployed immediately through the batch executable created for the database service and the database for the ERDS that is imported into the service.

---

Behaviour

Use Case Maps

Incident Logging

The above use case map demonstrates how the ‘Incident Logging' use case is performed as depicted by the 'Normal Use Case' narrative.

1. The operator receives a call of a new incident from the caller Vivian regarding a fire in the neighbourhood, and accesses the terminal to record the details

2. The operator logs into the operating component and inputs all details of the incident in the incident interface, including the required fire brigade and ambulance vehicles to dispatch to the incident. The operator then confirms the incident to be created.

3. The incident recording component updates the incident details to the incident database, followed by sending the required vehicle data to the tracking component.

4. The tracking component determines the location of the required available ambulance and fire brigade vehicles closest to the incident location, followed by updating the vehicles statuses in the tracking database to despatched.

5. The available vehicles are sent to the dispatch system for actual dispatch of the vehicles, and confirmation is returned back to the operating component so that the operator can confirm to Vivian that the incident has been attended to successfully.

Following the path in this use case, it can be observed that feebacks sent through callbacks validate the architecture at steps 4 and 5, where the system performs the tracking and dispatching tasks and sends feedback to the user on confirmation. The asynchronous movements from the incident recording to the tracking and finally to the dispatch component also validate the architecture's concurrent flow from processes required to create an incident and dispatch vehicles in order. Also the synchronous access to the appropriate databases for incident recording and trackign components demonstrate the system's need to update and query the databases for data for the success of the incident creations. The executable prototype was able to perform all the sequences above correctly, as the components initiated in the above order whilst recording onto the online database successfully.

No deficiencies were observed in the case as the user was able to successfully create the incident with all the components interacting with each other.

---

Management Report

The above use case map demonstrates how the ‘Management Report' use case is performed as depicted by the 'Reporting' narrative.

1. The manager Gerald accesses the system through his management UI terminal to obtain reports on the use of emergency vehicles in dispatch centers and regions.

2. Gerald has accessed the operating component and navigates to the reporting component through the reporting function in the operating component.

3. Gerald queries the reporting database to retrieve the information he requires

4. The reporting component retrieves from the database the data for the report, generates his in the reporting system and then sends the final report back to the UI to display to Gerald and assist him in his decision making.

The above use case demonstrating the manager retrieving a report correctly fit in with the architecture where the reporting system was able to query and retrieve data from the tracking database in callback and also itself callback the details back to the manager. The manager is also able to send the report information needed to the operating system component and receive the results through the callback to his UI as allowed by the concurrency architecture view.

There is a deficiency though where the reporting function has to pass through the operating system to actually access the reporting system. The team argued that implementing this would thus require less resources in development as both operator and manager's would access the same system at the start, where they would also authorise themself using the same login. This though creates a small unnecessary increase in process requirement, with an extra concurrent component, that could have been dropped to save processing power. The operating system component and reporting system component do interact properly with each other, as they are connected with a callback on the reporting component to receive requests and send data on results actively back to the manager.

---

Vehicle Tracking

The above use case map demonstrates how the ‘Vehicle Tracking' use case is performed as depicted by the 'Vehicle Tracking' narrative.

1. Senior Sergeant Mike, manager of the police station, queries the tracking component to obtain the location of one of his units. The GPS tracker will constantly be retrieving coordinates for the vehicles part of Mike's police station, with the status of these vehicles stored in the database.

2. The tracking component queries the tracking database to retrieve the current status of the vehicle desired for Mike.

3. The tracking database obtains the status of the vehicle and transmits the data back to the tracking component which informs Mike of the unit's status in question.

This use case validates the tracking system components' ability to actively retrieve coordinate details of vehicles constantly to update them directly into the database synchronously. This allows Mike to be able to query the tracking component to retrieve the status of the vehicle he wanted to know.

The system though does not give a direct UI for outside people to access the system completely, but due to the tracking system component being a process accessible in isolation for its active GPS recording and updating into the tracking database, it is accessible still but with difficulty and this demonstrates a deficiency in the architecture. The tracking feature can still be performed by the operator or administrator directly through the operating system with no deficiencies in the architecture as demonstrated also by the executable prototype.

---

Vehicle Status Change

The above use case map demonstrates how the ‘Vehicle Status Change' use case is performed as depicted by the 'Maintenance Crew - Breakdown' narrative.

1. Sally arrives at the broken down fire truck and after doing repairs, changed the status of the vehicle to online so that it is now available for incidents once again.

2. The tracking component of the system retrieved the call saying that the fire truck is online and sent this updated data to the tracking database.

3. The tracking database recorded the new status of the fire truck.

The use case validates the architecture's comprehension in receiving data updates from the emergency services directly, from where Sally updates the fire truck's status to online, with the update immediately placed in the tracking database in sync from the tracking component. The tracking system component can actively receive any update, such as Sally's, for vehicles and immediately update these to the database while performing other functions such as receiving GPS coordinates, without pausing the system. This demonstrates a strong point on how the concurrency of the processes alow the many functions of the system to be performed at optimal rate, whether it is tracking vehicles, creating incidents or despatching vehicles among other processes.

No deficiencies were observed as the user was able to successfully update the status of a vehicle through the executable prototype with the components and their concurrency based on this architecture.

---

Implementation

In implementing the execution architecture, the components in the conceptual architecture need to be represented as units of concurrent activities. These activities are time related and may need to run at the same time as others for the final ERDS system to work at it's most efficient state possible while executing.

In creating high performance, the system needs to always have the latest vehicle coordinates ready for dispatch and thus the tracking system component specifically needs to be an active component that continuously retrieves coordinates async from the GPS service. This is best demonstrated in the needs of the users in the incident creating (1) and vehicle tracking (2) use cases where vehicles need to be located on demand with their statuses for simple locating of vehicles to dispatching available vehicles required. The databases for the incident storage and tracking storage would only need to have data stored and retrieved when needed and thus need to be accessed as requests with the communication performed synchronously as locking is required for eliminating data duplicacy. The executable prototype demonstrated this as the hsql database would store and retrieve data based on sql statements when requested by the components, such as the incident system component to store incident details.

The scalability of the architecture was also kept in mind when implementing the executable architecture, with the seperation of the components as seperate processes. The incident recording component would handle incident related details which is recording new incidents, followed by processing in the tracking component to locate the best vehicles to dispatch in the despatch component. This requirement as presented in the incident creating use case shows the seperation of componenets in an architectural view but with the proper interaction needed to create incidents and dispatch vehicles. The executable prototype demonstrated this in real time as the various componenets were seperated in the business logic layer with serialised communications sent between the component and the server for seperate processing in the required order.

Regarding maintenability, the components will be placed seperately in the final software. This will ensure that one component can be maintained seperately from the others for when upgrades or fixes need to occur. The executable prototype demonstrates this well as the various components such as incident creating and tracking are placed in seperate classes but located in the same package for business logic on the system for categorising that differentiates from other different types of classes such as user interfaces placed in client package or server services placed in the server package. Thus locating components for maintenance purposes are logical to do, with maintenance itself more simple due to the low coupling of the components.

---

Constraints

As observed from the use case maps, accessing the system with the inbuild ERDS interface is limited to just the operator, administrator and managers with authority to use the system. Outside users such as vehicle drivers, as shown in use case for vehicle maintenance, and emergency service stakeholders, such as the seargent wanting to locate his unit, will be sending message commands from outside the system to perform vehicle status and location updates or retrievals. Due to time constraints and priority of requirements, a better implementation of outside access with proper authorization can be implemented in future iterations of the architecture. Authorised users of the system internally can still access the ERDS system externally though through the HTTP interface which partially reduces the constraint of outside access.

The architecture has a small execution problem that may occur in rea-time, where the vehicle sent for dispatch may have its status changed to unavailable in the short time it has it's status changed in the database to when it is marked for dispatch, i.e. communication from the tracking system component to the dispatch component. Due to the very small time taken for the system to process between these events of changing the status in the database then enacting it in real life, it is a very unprobable event but still a constraint concern that may need to be addressed in future updating of the architecture.

---

Implementation Architecture

Structure

Implementation Diagram

Comments
The application has been divided into the following three tiers:

• Presentation tier
  This includes both a web presentation service (http) and an object model that allows java user interfaces to be connected via TCP sockets. It will rely on the underliying layers to provide functionality and security
• Business logic
  The application tier controls the flow of information throughout the system and to and from the presentation layer. The roles provider is referenced in this layer to provide roles and user permissioning uniformly independent of the user interface.
• Data abstraction layer
  The data will be provided by MySQL and will be connected to the business layer via a network transparent data access layer. The data access layer will abstract the scalability and concurrency issues that the solution requires for the performance and robustness requirements.

External interfaces in implementation
The system has the following three external software/hardware systems that are interfaced with

• GPS tracking data will be provided by the emergency services GPS tracking network to the “Vehicle Tracker” network interface. This will allow vehicle GPS location updates to be received from any secured connection to the application.
• The miracle system will be restricted to a strict interface so that the system can be substituted in the future and to allow concurrent use of multiple miracle systems by different vendors to provide the highest level of reliability and robustness
• Relaying dispatch data to vehicles will be handed off to an external software and hardware system to provide the wireless data broadcasting.

---

Component Relationships

This diagram shows the mapping of the conceptual components to the application and infrastructure components of the implementation architecture.

The conceptual components are based from the components of the conceptual architecture, with this diagram demonstrating the linking of the components that has helped plan and develop the final implementation architecture for the project.

---

Behaviour

Sequence Diagram

Normal Usage

The above sequence diagram demonstrates how the operator will dispatch vehicles depending on the incident reported by a caller.

The caller first initiates a call, which if there are available lines, will be answered by the operator available. The caller will then be requested to provide their details and information on the incident of which the operator will create a new event in the system. The event will then be logged into the system, where the incident location and type of emergency will be extracted to determine which type of vehicle will be needed for dispatch to this incident.

The system will check for the vehicles of the relevant class and determine their availability within the incident's proximity. The system will then send the tracking system the incident location and available vehicles to calculate which of the available vehicles will have the fastest routes to the incident and return this data back to the dispatch system which will dispatch the vehicle or vehicles. A confirmation of the dispatch will be sent to the operator who will confirm this with the caller, the caller's acknowledgement signifies that the incident has been attended and acknowledged by the relevant parties.

Reporting

The above sequence diagram demonstrates how the user will retrieve the following two reports:

1. A Report on all vehicle movements for all time segments for all days of the current month.

2. A report of all activities of the region of Sydney.

The diagram shows how the user will first log into the system for authentication and then, if successful, they will view a list of reports they may generate. After the user choses a report, the system will generate the specific report using the relevant data from the database. In the case of the first report, the database will retrieve all vehicle movement distances of every day in the current month, which will then be formatted into the newly generated report for the user to view.

The second report will also follow the same process, with a request to generate a report containing retrieved data from the database depicting the activities of the region Sydney. The report will then be sent to the user's screen to be displayed.

The user will subsequently log out of the system to ensure that the system will be safe from unauthorised access in the future.

Management Reporting as was implemented in the ERDS system

---

Implementation

In implementing the implementation diagram, application components supported by infrastructure components needs to represent the conceptual components in the conceptual architecture. These components will focus on the build-time structure of the system, with technologies required and build-time configurations.

The databases that store the tracking and incident details need to be put in a database server that will meet the requirements of access through SQL queries and running live as the system runs. HSQLDB is the appropriate database service chosen due to its compatibility with java code used in the system and it's ease of starting and running live on the system. It needs to be accessible through the network by the application components and the network protocol was chosen to do this. It's use is demonstrated in the executable prototype which runs the hsqldb service and updates it with the ERDS database through a batch file at the start of the system, with connection to it done through the data access layer of the ERDS. The different components such as tracking and reporting use SQL queries to retrieve and store data in the database so the requirements can be met by the user.

The HTTP interface to the system would be required, which will allow the user to access through HTTP the ERDS server to perform the same functions as through the executable operating console within the system. The java applet will perform this function, allowing a simple to reuse interface, reused from the operating console, due to the common use of java code and will save time from use of repeating code whilst providing the HTTP access requirement for the stakeholders.

Application and infrastucture components communicate through an interface that ensures which services are provided and what uses the component can perform. The various components such as the incident reporting and vehicle availability use interfaces as outlined in the implementation diagram, and demonstrated in the executable prototype where interfaces are coded to communicate only what is needed between componenents such as where the incident reporting component will send confirmation data of dispatch to the operator console or web interface.

---

Component choices

---

Constraints

A constraint is located in the web presentation layer regarding the java applet service that interfaces the end user with the system through HTTP. There is only one server at the moment, and as the ERDS system obtains more users such as operators and managers, there will be too much processing required by the applet if the users access the system at once through HTTP. This can cause HTTP access errors and slowdowns for users. Adding more applet servers with load balancing would remove this constraint but was not a high priority in the current context, but as the system expands to more users that access through HTTP then the architecture can be updated to allow more simultaneous connections.

---

Development Issues

Multitasking

It became evident in planning that the system is required to be scalable with regards to number of concurrent incident reporting, management reporting and maintenance updating activities. To solve this issue we plan on creating a multi-thread server capable of performing different tasks simultaneously.

Technology

The emergency dispatch system spans over a number of servers, databases and locations. As a result, the system is required to be developed in a platform-portable language. We decided to develop this system in Java, in Eclipse environment.

Multi-development

The development team will be composed of database, server and application developers. In order to maintain continuity and synchronisation of effort, the team will use subversion to share and update system files.

User interface

The user interface will vary depending on the terminal. For the incident reporting terminal, the team will strive to make the user interface as simple as possible, minimising the number of objects on screen and using logical layout. The users will be able to fill in an incident report accurately, with ease whether they are beginner or advanced users.

Miracle System

As shown data models, the function of the miracle system is provide the proximity finder component of the system with the estimated time of travel for each option presented to it. The development team will treat this variable data as given, using randomly generated figures in the place of an actual path finder system.

---

Key Architectural Decisions

Many of the key architectural decisions were based on identifying the needs of stakeholders, who in turn cast their votes to determine the main quality attributes that the system should adhere to. The main focus was on the attributes of security, performance and reliability.

Security

To ensure that security of the system was maintained in regards to data access, each user has a password and role stored in the secure database. This is checked by an authentication manager during the login process, with the correct role assigned and only the options available to that user displayed. At this time an authentication token is assigned to the user (with timeout set) which is displayed by the user every time they make a request, to prevent fraudulent transactions. Also on every new transaction the user’s role is confirmed against the database to ensure that they have permission to the requested area, and have not inserted their own client into the architecture of our system.

The layered approach to the design is also a fundamental security feature as all data accessing is done server side. The user must post requests, which the server interprets and responds to accordingly. The user never directly interacts with the database, ensuring the integrity of the data is maintained.

Performance and Reliability

A key decision made to assist with both performance and reliability was the broker service. This provides a distributed system that is scaleable, as it can grow exponentially with the addition of new servers. As each server starts up it registers itself with the broker. When a client is loaded it first connects to the broker, who then provides the IP of the server the client should connect to. The broker is able to determine this through distance to the server as well as load experienced by each of the servers. This increases performance of the system as the broker is responsible for evenly distributing the share of connections across the network.

In terms of reliability, should the broker detect a server goes down, it can then redirect the clients from that server to other servers in the network to balance the load.

A layered approach to the design was also selected to improve performance. Both the client and server adopt a tiered approach to data access, display and processing that leaves each layer independent of those around it.

A central database was selected as the system can inherit the redundancy features it provides to ensure reliability of the stored data. Mirroring options and backup plans can be implemented in the future to extend this reliability.

Useability

A java web applet that works similarly to the java console is employed to provide universal access to the system, no matter where the user is. This ensures the user is able to access the system in familiar ways, whether is be web access or console access, without the need to understand a new set of protocols governing how the system is run. As the web access is not limited to management reporting, but also includes incident logging, this provides the facility to allow operators to log in from home to work to provide employment opportunities to people suffering from a disability.

---

Critique of Architectural Design

Analysis of the key stakeholders for the dispatch system identified the following key quality attributes: reliability, performance and security. The architecture has been designed with these attributes in mind. The final architecture has been successful in delivering these qualities attributes.

The dispatch system has been divided into three separate areas but share a common architectural framework.

• Client
• Server
• Data storage

Framework

There is an underlying messaging framework that is used by both the client and the server. This framework allows messages to be delivered across a TCP/IP network with delivery notification. Bi-directional synchronous and asynchronies cross-server messaging has been developed at the core of the framework to allow the dispatch application to be built upon its robustness, reliability and scalability.

The architectural decision to first develop a core framework to build the application on top of has lead to a higher quality product according to the key quality attributes discussions below.

Several examples in the code by the team members responsible for the framework development allowed the rest of the development team to interface and use the framework the way it was intended and designed to be used.

Layers

There was an architectural decision to develop the software using distinct layers each with its own well defined responsibilities. The layers above and below did not have to understand the layers surrounding it. This dramatically decreased code complexity. An example of this is the messaging layer did not have to have any knowledge of the network topology and transmission technology used. The transmission and connection layer did not need to have any knowledge of the construction or meaning of the data to be transmitted.

The highest layer in the system was the business logics layer which relied on every service provided by the lower layers and on the framework services provided to all layers. The business logic had simplified access to complex synchronous cross-server messaging system. This allowed business logic code to make a single blocking call to the messaging service to send a message to another server on the network and wait for its reply. The business logic code would get a response from the server or a timeout error is returned to the calling code.

There were also asynchronous cross-server messaging options which allow messages to be delivered similar to email where it is known that there will be either no response or a delayed response and the sender should continue on with other tasks until the response is automatically delivered to the server.

Reliability

Reliability has been addressed in several key areas of the architecture. It was first developed in the framework services where not only connection reliability was critical but also that the delivery and ability to verify the data transmitted and received was valid. This was done though the Java built-in socket services, built-in serialisation services, strongly typed and strict documented object inheritance requirements.

A broker service built very easily and with minimal effort. It was built on the shared connection layers and framework services to increase reliability and scalability of the application. The broker service monitored server load and connection states using the existing messaging system and would instruct clients which server to connect to. The architecture developed to-date at that time strongly promoted reliability and allowed the services offered to the clients to be improved without having any architectural changes. Reliability was increased as now many servers could be provided to the client. If a server is removed from the network (planned or unplanned) it is automatically de-registered on the broker service and clients are not longer instructed to connect to it. When clients are disconnected from their server for any reason they will always go back to the broker service for further instructions.

The reliability of the broker services has been modelled on the successful architecture of the internet. Hot stand-by servers with duplicated MACs or load balanced low TTL DNS servers (round-robin based on server load) could be setup with no changes required to the broker service software which allows the severs to operate with high-availability which would be measured against the strict SLA that the stakeholders would provide.

Message delivery was a critical part of the reliability. It allowed for guaranteed eventual delivery of messages, message timeouts, synchronous waits for responses or asynchronous delivery, successful delivery reports and failed delivery reports. The messaging system was designed in such a way that the user could connect to any of the servers in the network and have all messages destined for them to be received regardless of the servers the user has used to connect in the past.

The key architectural features that directly promoted reliability were messaging services, broker services, multi-point failure tolerance and reliable operation under scaled deployments.

The architecture developed for the dispatch system is highly reliable from an architectural point of view

Security

Security was demanded by the stakeholders because of the sensitive nature of the dispatching and of the privacy laws and concerns of users.

Security was implemented in the layered architecture in the protocol layer and was serviced by the authorisation framework service. Although the authorisation was provided as a service to all layers in the system only the protocol service used it. The protocol layer operated as a gatekeeper for requests to the higher layers such as the business logic layer where it would not be needed to understand or enforce permissioning or security for requests.

The protocol layer would check that the sender is valid, its security token is valid and issued from the server they are currently connected to and that the token has not expired. Once it is determined that the token is valid it then checks that the token has the access roles associated to it that allow the received request to be further processed.

The client software restricts which operations are enabled and visible to the user depending on the allowable roles provided to it by the login response that the client receives during login procedure with the server. This is the first level of security. The server protocol layer is the final security checkpoint for all requests from clients. It will cope with manipulated clients that send requests for operations they are not permitted to perform and deny them before they are further processed by the server.

Security has been developed at the core of the system and is interrogated at multiple points. The security implemented follows a recognised standard for implementing a secure role based open communication system. The architecture is highly secure and will satisfy stakeholder requirements for a secure system architecture and implementation.

Performance

Performance is required from stakeholders as the system will have many connections from many sources over a wide geographical region. The architectural design has incorporated performance as part of its key design qualities. The architecture has been designed around multiple servers connecting to a single database server. Each server will be fully responsible for maintaining connections and their states. The database will be a commercial system. The system currently used is HSQL but when deployed for the NSW government it will be changed to an enterprise quality database system such as Oracle or Microsoft SQL. The only change required to the dispatch system is a single class called DataConnector which is solely responsible for connecting to the database server. No changes to the system are required if only the database connection strings are changed. The java database connectors would be changed to the vendor supplied native database connectors for improved performance but this change would be restricted to a single class called DataConnector.

The database server will be highly scalable and highly available. Oracle and Microsoft SQL have been proven performers in the industry for high performance enterprise data environments. The software architecture for the dispatch system is designed for multi server communication without any inherent performance restrictions caused by the chosen architectural design. The performance of the system is architecturally sound and will scale with the database systems used.

Final critique

The architecture has been designed to meet the primary quality attributes: reliability, performance and security. The architecture has met these requirements as shown above.

Reflections

Chris Zaharia

This project has taught me how to apply my newly acquired knowledge in software architecture into developing the architecture and prototype of the set system along with a team to create a successful solution for dispatching vehicles. We’ve participated in many meetings which has helped myself to individually contribute to set tasks for our software architecture document, such as thinking up of stakeholder details for the system at the start, contextual factors along with modeling with Visio the execution models that we all discussed and determined among other tasks.

At certain points we especially had to think as a group to come up with solutions such as when we had to design the conceptual architecture, several of us presented our own versions firstly and we discussed and used the best parts to develop a final version we believed would work best, and this was one of the major decision points we had. The end result shows this as the execution prototype worked greatly using our architecture we planned beforehand, and met the requirements as set out by our narratives we all has a hand in creating.

In developing the execution prototype we did have some problems at the start where some members did not have the skills others did and at first did not understand how to do certain coding. I myself did not know about java beans and socket communications, but I was allocated to do tasks related to this which did not work so well for me. We as a team though communicated very well with each other, as I received advice and help from other members more experienced and was in the end able to understand how to apply the architecture and develop the business logic for the prototype.

In developing the implementation architecture, it was important we chose the appropriate technologies for our components and using our collected knowledge in java and database programming, we determined to use eclipse with subversion to update the prototype as a team, and use the hsqldb database we were taught in our software architecture lab for a very compatible java database service for our program. Our member in charge of the interface made a great java application based and http java applet based interfaces by using his technical skill and reuse of code, which I was able to contribute on my part too in designing the actual interface for the GPS console that retrieved vehicle coordinates for the vehicles. Our end prototype result shows all our processes worked successfully with each other using the technologies we chose, with the database communicating with the programmed services, which communicated with the interfaces correctly whilst both achieving our stakeholders goals whilst adhering to our designed architecture views.

In conclusion, I believe I have learned great skills that have improved both my knowledge and experience in developing real-life relevant architectures that will allow me to develop even better solutions the next time I am a part of such a project.

Trevor Russell

I feel that I learned a lot about the entire software development process because of this subject. In every other subject that related to development we only every focused on one part of a system, databases in database development, classes in object orientated design, single process applications in Embedded C. Until now no subject had approached the development from an architectural view, and shown the importance of setting up the entire system and how it interacts both internally and with external interfaces.

Our design process at first to get the architecture started was a bit hap-hazard as there was multiple suggestions, however at least it gave a foundation with which to build on. However as the execution prototype was based on this architecture it was important that we got it sorted out correctly. It was also interesting to note that the use of existing architectures was recommended, it wasn’t just a case of go out there and make one yourself, in most situations to use of tried and tested designs was the way to go. Our decision to go with the broker service came from this philosophy.

Technologies for the components, such as the database, as well as some of the code choices were derived from the assignment requirements, but also what we learned in class and felt most comfortable with – often when we made decisions it was to cater to what we saw as our strengths.

In the development of the document, teamwork was necessary to help bring it all together, but seamless integration of each of the parts was not required. This however was a requirement of the prototype, as each member took various parts of the application which we then had to fold back together. The SVN repository helped enormously here, however our clever divisions (based on the architecture) allowed a fairly easy integration. The separated parts: the interface, network protocols, database, GPS unit, business logic, all integrated almost seamlessly, with their correct function being attributed to the strength of our architecture and the way in which members cooperated and shared knowledge. This really highlighted the importance of a solid architectural foundation in a large project to me, but also the need for communication in teams.

This subject has shown me how to approach the design of larger systems with the perspective of all the components and how they relate and function in realtime, a perspective which I will take with me into all future projects.

Chris White

The project was an interesting project that required a high level of team collaboration and communication. Before this assignment I have never written any significant code in java or in an open source IDE.

Having completed this assignment I will personally not use Java or Eclipse for any future development but I will include it in my list of skills. Java was a simple language to adopt coming from a C# Visual Studio background. I found it interesting to see firsthand the variations in the philosophy applied to the OO nature of the two languages.

Architecture has played an important but informal role in the work I do. Reliability and maintainability have always been key quality attributes required for my work. This subject has helped me to formalise this relationship of desired qualities and the initial architectural decisions.

In previous work done such as an ISP reseller billing system there were unrealistic time constraints and I developed the system without any formal architecture considerations. It was not until release two that I was able to apply architecturally sound communication and transaction models. By this time the code had become closer to a “blob” than would be considered acceptable for a financial system. This has been fixed with a tasks framework and a transactional model used to govern data manipulations.

For this assignment we built the framework and architectural layers before the business logic was coded. This forced all business logic to remain just that business logic not cluttered with the mechanics and plumbing of the software environment. This clear separation of communication and message processing allowed the team to work on separate sections of the project concurrently. The project had very high code re-use and allowed software such as a GPS simulator to be created with minimal additional code.

This project can be adapted to almost any multi-server communications project with only a rewrite of the business logic classes and the protocol specification files. This emphasises the quality of the architecture and OO principles used during the design.

The team functioned well together but it was difficult to communicate the work needed to be done for each deliverable. The team coped and completed the assignment successfully.

If I were to re-do this or a similar assignment in the future I would invest more time in team meetings to formalise what everyone’s responsibilities were for each deliverable and to help create a formal communication mechanism between team members to help ensure that information got to the right person in time. We did not have a problem with communication only that it would have been more efficient and organised.

Ara Stamboulian

The process of thinking about software development in the context of architecture has broadened the horizon for me. It no longer is the putting together of commands or attention to syntax to getting a piece of software work. It takes the process beyond that to how the pieces of software work together with other off-the-shelf packages to achieve the performance and other non-functional requirements. Having the different stakeholders identified and their versatile needs, expectations and impact assessed broadened this thinking dimension. The non_functional requirements of Reliability , Performance, Security, Maintainability etc, take a new perspective in light of what the users and stakeholders of the system want.

As with any design process making decisions mean making tradeoffs. In our initial design we envisaged MySQL database package to be used in our implementation ( our initial implementation design has clear indication to that), but upon implementing the executable prototype a change has been introduced to Hsqldb for reasons of simplicity and laboratory computer usage. This minor change did not affect the design main features though, it is in effect just a small modification in the prototype which can be easily extended in production version into MySQL or even Oracle or any other database management system. The architecture is made to be modular, so the only parts that are affected by change of DBMS (database management system) is only restricted to the parts that talk directly to it, namely DataAccess package. Even within that package two access levels are defined, the low level DBMS connection and high level interface to the system's other components. The effect of change will only be restricted to the low level data access, with the rest of the package left intact.

The process of writing the executable has affected our understanding of both the system and route to the user requirements. As an example, initially not much attention was given to the process of Login. When we later discussed the process in more detail it was suggested that users have to divided into roles and that each role will only have a certain privileges. This has its links in the security requirement, to implement system access on need to know basis. This definition of the roles has affected the design is a way so as to add tables in the database to contain user information and password (for validation) and roles to define what privileges each role has.

Another track of thinking led our team to design a way for acheiving high reliability and improve performance. Initially it was envisaged that the system will be comprised of many userUI instances and a single LoginServer. This design had the drawback that in the case of the LoginServer failure the whole system will be inoperational. The solution was to has several instances of the LoginServer running simultaniously, which presented another challenge that is how would the UserUI components locate the LoginServer. The solution for that was to have a new component called "Broker" which monitors the LoginServer instances, where (IP-address) they are and how busy( as the number of connections each currently have to UserUI's). The UserUI instances would connect to the Borker to find out which LoginServer to connect to. The broker in this fashion will be able to divert away from both down or congested servers. This latest design can provide reliability that approaches 100% also and increased performance of the system. But the design as it is can not be totally independent of human intervention. System administrator is still required to monitor how the system as a whole running. If performance is degraded due to high traffic then decision is to be made to increase the number of server instances available. Also the administrator should keep track of Brokers, so as not to have the system running with a single instance of them.

The above mentioned process of coming up with a design, only to find new ways to implement or better achieve targets strikes me as the process of iteration and elaboration.

I am left with a positive impression of the team we worked in. Everyone was committed to the team and demonstrated hard work. The team also exploited well the diversity of its members directing individuals to do the parts they excell at. This made the assignments (with time constraint in a strong sense) achievable.

I have to mention though few points that I see as shortcomings, though of no fault of individuals, but as a result of the extreme time constraint. Had we had better chance to define and standardise interfaces between different parts of the software, some duplication and redundant of code implementation could have been avoided. To give an example, I was involved in the low and high level database access classes. It was decided by the team to have a package dedicated for data access (modular coding practice) which would: a) connect to the instance of database (so that a change in database server will only impact this component). b) provide the other classes of the code with any queries from the database, as a high level access. Simultaneous the server and ui parts were being developed. Control classes were introduced to carry over command requests and response data. Had we had more chance to work out the fine details of the data classes, some effort for reconciliation could have been saved.

But overall both the team workings and the subject enlightenment of the wider view in software development had been an eye opening experience to me, and I am left with a very positive impression.

Peter Ebeid

This project has taught me the importance of collaboration is system design. Without clear understanding of system architecture from team members it would be difficult to implement the system. To come up with good system architecture, the team needs to evaluate the context of the system, the stakeholder analysis. Once we have a clear picture of who the stake holders are and what their most important concerns are, we can them come to terms with our contextual factors.

The contextual factors go along way in determining how we are going to approach system development and hence what its architecture is. For our system, we decided to implement a layered architecture where the system is made up from console interface, business logic, network and data. The network layer in particular was important because it held the key to both the security and the scalability of the system. The use of the broker in the network layer allowed the system to expand and to include multiple hosts and clients.

The database was also important in that it had to be accessible from multiple points and secure that it didn’t allow anyone to access it. To resolve this issue, we came up with a connection protocol that restricted communication to the database. Any queries or entries were made through that connection interface alone. That way only authorised access gets through.

The development phase was challenging in that team members had different ideas on how the system was to be written. Understanding of our architecture proved illusive for some of the team members. Technical proficiency was also a problem, as a few of the member, such as me were never exposed to network protocols or database handling in Java. The labs proved to be less than adequate, as we were left to ourselves to work through the lab material with no assistance available on many occasions.

Teamwork proved difficult at first; however, once we began to communicate via email and Google groups, we were able to inform each other of our progress. Conflict with in the team did not exist. Any problems we had were worked through. I found that my work ethics let the team down on several occasions. I enjoyed working with the team.

The lectures proved very valuable in learning about software architecture. The lecturers were able to clearly express their understanding of the architecture to us. This helped me in the development stage to make decisions about how the architectural design and the importance of adhering to it in implementing our system.

Damir Trako

Having limited software programming abilities, and taking this subject on as an elective, I have to say that I to say that I found this subject personally very challenging but at the same time very enjoyable, and thought provoking.

My knowledge of programming especially java, still remains limited. This subject has mostly thought me that Software Architecture is not just about putting a program together. It is about taking a wholistic approach in the design and implementation of a whole system and making it work as one.

Personally, I was fortunate to be in a group with such brilliant and capable individuals. Without belonging to this group I would have struggled immensely to get greater grasp of the subject.

Although having limited programing ability. I did thoroughly enjoy putting together the Stakeholder Analysis and establishing the diferent architectual needs of the stakeholders. This allowed me to understand that one cannot design a system without taking into consideration all different view points and requirements of everyone involved.

The lectures were not boring, but were very well structured and I felt like each week I was coming out of them having learnt something new. The only real issue with the subject I had was the labs, as I felt they were not structured or guided well enough, and half the time we had no understanding of what we were expected to do.

Working full time in a large IT environment, I feel that this subject has given me such a greated understanding of all the different systems, structures and processes we have going on at work. ---

Instructor comments

Good start on narratives. But I am wondering if the one about Google maps is prematurely committing to the use of Google maps in the solution. Or are you suggesting that Google is one of the stakeholders in the project? 28th Aug Lian