From SoftwarePractice.org

Contents 1 Team Members 2 Introduction 2.1 System Overview 2.2 System Needs 2.3 Contextual Factors 3 Stakeholder Analysis 3.1 Major Stakeholders 3.2 Stakeholder Narratives and Identification 3.3 Usage Narratives 3.3.1 Ambulance Dispatch 3.3.2 Fire 3.3.3 Police 3.3.4 Police 3.4 Quality Attributes 3.4.1 Quality Attributes Ratings 3.5 Quality Narratives 3.5.1 Performance 3.5.2 Reliability 3.5.3 Concurrency 4 Conceptual Architecture 4.1 Initial Conceptual Architecture 4.2 Elaborated Conceptual Architecture 4.3 Final Conceptual Architecture 4.4 Architectural Decisions 4.5 Prototype Results 4.5.1 Conceptual Component Analysis 4.6 Use Case Maps 4.7 Data Model 5 Inintial Executional Architecture 5.1 Initial Concurrent View 5.1.1 Component Explanation 5.1.1.1 Client Application 5.1.1.2 Vehicle Calculator 5.1.1.3 Vehicle Assignment 5.1.1.4 Reporting 5.1.1.5 Data Storage 5.1.1.6 Remote Message Handler 6 Final Execution Architecture 6.1 Updated Concurrent View 6.1.1 Improvements 6.1.2 Component Explanation 6.1.3 Client Application 6.1.4 Vehicle Calculator 6.1.5 Vehicle Assignment 6.1.6 Reporting 6.1.7 Data Storage 6.1.8 Connection Handler 6.1.9 Threaded Server 6.1.10 HTTP Server 6.1.11 External Client 6.2 Deployment Based View 7 Behavioural 7.1 Administrator 7.2 User 7.3 Manager 8 Initial Implementation Architecture 9 Final Implementation Architecture 9.1 Implementation Architecture Description 9.2 Quality Attributes 9.3 Constraints 9.4 Problems with Implementation Architecture 10 Future Milestones 11 Reflections 11.1 Design Critique / Team Reflection 11.2 Pippa Flanagan 11.3 Karan Jain 11.4 Lloyd Rangiah 11.5 David Truong 11.6 David Young

Team Members

Group members and contact info

	Email	Mobile	MSN	Student Number
Pippa Flanagan	pippaflanagan@secsme.org.au	0410345996	pippaf@hotmail.com	01041755
Karan Jain	absolutekaran@gmail.com	0406102090	formrdesi@hotmail.com	10039699
Lloyd Rangiah	lrangiah@gmail.com	0401164838	merc_thunder@hotmail.com	10048256
David Truong	david.truong@gmail.com	0402771323	cybdave@hotmail.com	10055255
David Young	nod911@optusnet.com.au	0403282868	nod911@optusnet.com.au	10041693

https://swordfish.eng.uts.edu.au/projects/sa08spr_f5/svn/

Introduction

System Overview

Reference: http://www.esta.vic.gov.au/

In an emergency event in Australia, a person will call 000 for help. This call is received by a call centre which will talk with the person in need it find out the details of the emergency. This 000 call centre person will then call the Emergency Dispatch Centre. The Emergency Dispatch Centre will then dispatch the emergency vehicles and personal to the emergency. This process as illustrated in the diagram above (Victoria Government) what is known as the emergency event sequence.

The Emergency Response System is the system that the dispatcher uses to dispatch the vehicles and personal to the event. It will handle communications between the dispatchers and the vehicles that are remote and on the road.

The main function of the system will be that of enabling automatic dispatching to be done via the computer system, enabling more time for dispatchers to take more calls. The system will take the address of the emergency and scan the locations of the vehicles closest and allocate that vehicle. It will then send a message to that vehicle to advise it has been allocated to the job. It will wait for an acceptance of the job.

A "miracle system" will be present within each Emergency Vehicle, which will provide a route to the destination for each driver. This will interface with the system used by the dispatchers, where the vehicle operator will receive a list of instructions to the emergency location. The vehicle operator will then follow these instructions to emergency location, which will be the fastest and most efficient route.

There will also be an ability to still dispatch manually due to situations where some special vehicles may need to go to certain events. Such as Police vans rather than cars.

The system also integrates an authentication process, which helps distinguish between administrative staff, dispatch staff and high level managers who require higher access levels. Statistics will be recorded on each and every vehicle, showing there whereabouts on any particular date. These will be in the form of logs, and will be produced through automation. Each log will be time stamped, and dated, so they can be sorted easily. Furthermore, logs and statistics will be collected on each Dispatch Operator to ensure they are performing their duties efficiently and correctly. Managerial staff will be able to ensure that the correct vehicles are being manually dispatched, and that the manual and automated dispatch times meet particular standards.

Some emergency vehicles which will be considered by the system include:

• Ambulance
• Fire
• Police
• Police Rescue
• Coastal Patrol
• Harbour Parol
• Traffic Patrol
• Accident Response Units
• State Emergency Services
• Police Riot Squad
• Bushfire Services

System Needs

In order to operate at maximum efficiency the system should provide a plethora of tasks to ensure full system automation and performance. These include:

• The system must operate 24 hours a day, 7 days a week
• The system must know where all vehicles are at any given point in time
• A vehicle can be added or removed from the system at any given period of time
• A vehicle will be flagged as "busy" in the system database when currently on an emergency call
• A vehicle can be temporarily suspended from the database for maintenance reasons
• The system should be able to log vehicle movements over a given period of time.
• The system shall be able to report activity from a nominated dispatch centre
• The system shall be able to report activity to a nominated region

Contextual Factors

Risk

The development of the Emergency Response Dispatch System (ERDS) must take into account risks that may occur to reduce the likelihood of the system being successful. One of the major risks of the project is having such a large number of companies as stakeholders. The risk revolves around conflict of interest, and stakeholders disagreeing on what they project entails. Another risk that should be considered is incompatibility between the different stakeholder hardware, since each stakeholder will have different hardware requirements and protocols. A change in government could also lead to potential risks, such as project cancellation due to the new premier taking a different path. The risks identified above would need a risk management plan to ensure contingency plans are in place to reduce the consequences.

Enablers

The ERDS has several enablers, which adds an enhancing effect on the system. One of which is the strict requirement to use Java as a development language. Using java has several advantages. It can firstly be ported to any system without major code modification, so the application can be used in a variety of environments. The language has been created with networking facilities in mind, so networking with external components is made easier. Java also has better memory management compared to other development languages, so the application can potentially be used on small, memory restricted environments. Other than the programming language used, the other enablers include the main emergency stakeholders who have all agreed to provide input on workplace culture and procedures, so that the team will be able to develop a better application, and support from the general public regarding the project.

Constraints

The Emergency Response Dispatch System is bounded by several constraints that will impact on the development of the system. One of the major constraints of the system is that it must be able to operate in an environment where any delay could potentially cause significant consequences. Since this system will be used by several stakeholders, the software would need to be able to interface with the different protocols used for each stakeholder. There is also pressure from the stakeholders to have this system implemented as soon as possible, reducing development time. Legalities are also another constraint that will need to be considered, such as security of people/victims being used improperly.

Stakeholder Analysis

Major Stakeholders

• Emergency Service Dispatchers
• Emergency Service Dispatch Centre Team Leaders
• Emergency Service Dispatch Managers
• Police
• Ambulance Drivers
• Firefighters
• SES
• Other Emergency Services
• Person in need
• Hospitals
• 000 Call Centres
• Government
• RTA
• Developer
• System Maintainers

Stakeholder Narratives and Identification

Emergency Service Dispatchers

Sam who has been working as an Emergency Service dispatcher for the last 2 years is on a late shift. He has just come off his smoko break and logs into his phone, as soon as he does he receives a call from Stacey at 000. Stacey tells him that there has been a fight down the pub on Drunk St and they need police and ambulance there as there has been a glassing. Sam dispatches the police and ambulance to the pub on Drunk St and thinks to himself that he could do with a nice cool beer right about now; Sam is awoken out of his daydream by the next call coming through.

Stakeholder	Emergency Service Dispatchers
Characteristics	Sam is the human starting point of the dispatch sequence. He receives calls from 000 to dispatch services to the emergency. He works in a very fast pace and stressful environment. Sam is an excellent typist. He is also a chronic smoker and enjoys a beer or two on his day off.
Nature of Interest	Sam needs a system to be able to quickly and efficiently dispatch the correct vehicles to the correct address and know that the vehicles have received the request and are on their way.
Benefits to Stakeholder	The system will make Sams job a lot easier by enabling him to input an address and type of service needed and the system will choose which vehicle to dispatch and the system will tell Sam the status of the vehicle. This takes a large amount of responsibility away from Sam and also makes his job quicker. This reduces his stress and makes him feel happier in his job

Emergency Service Dispatch Centre Team Leaders

Toby has been the Team Leader at the Emergency Service Dispatch in Burwood for the last two years. Recently he has been over hearing stories about Tom one of the dispatchers in his team. The other members would gossip and laugh about how Tom snoozes on shift and keeps his phone on busy status. Toby thought to himself he must look at Tom's call and dispatch stats to see if there was anything out of the ordinary.

Stakeholder	Emergency Service Dispatch Centre Team Leaders
Characteristics	Toby does not always have core interactivity with the system however he does need look at the statistics of the dispatchers and need to ensure everyone is using the system as it should. Toby does now how to use the system. Toby has worked his way from a dispatcher to Team leader in a year which is very fast. Toby is strict on his workers.
Nature of Interest	Toby needs a system that he can easily see the call logs and activity that a dispatcher has been doing. Toby also needs to be able to dispatch in case there is a difficult situation that has been escalated to him.
Benefits to Stakeholder	The Emergency dispatch system will interface with the phone system to be able to quickly give statistics of each dispatcher.

Emergency Service Dispatch Management

The Senior Management of the Emergency Dispatch Service are having their monthly meeting. At this meeting they need the previous months statistics of the dispatch activity of each of the 3 different dispatch centers has been. This can include information on how long it took to dispatch a service, how many were dispatched and what if any errors occurred during the dispatch process. They need this information to enable them to ensure if the service is meeting its set targets and objectives.

Stakeholder	Emergency Service Dispatch Management
Characteristics	The Senior Management is a mix of people that have come up the ranks from being a dispatcher but also there are people who have never worked at the ground level and have more of an analytical role. They constantly debate with each other on whos fault a particular stuff up was.
Nature of Interest	The Senior management need certain statistics such as average time taken for dispatching, number of dispatches areas which are in high or low demand etc to manage the dispatch system as a whole. They need to keep tabs to see if anything needs improving.
Benefits to Stakeholder	The Emergency Dispatch system will enable Managers to quickly access reports on the information they need.

Police

Constable Sarah is halfway through her shift and is already wishing she was back home in bed. She is in the patrol car on her way back to base and her in-car receiver buzzes to indicate she has been allocated a situation to attend. Constable Sarah checks the receiver and it tells her she is to attend to a complaint about a rowdy neighbor at 32 Noisy St. She accepts the job and then takes the directions that the in car unit tells her to go.

Stakeholder	Police
Characteristics	Constable Sarah has been a police officer for 2 years. She used to be dedicated very hard to the Force until she was in a gun fight 3 months ago. She is now starting to second guess her choices.
Nature of Interest	Sarah needs a way of being allocated jobs and also needs to keep in touch with her base to ensure it is known where she is at all times.
Benefits to Stakeholder	The Emergency Dispatch system can track Constable Sarah and enable her to not have to constantly check in at base. It can also enable her to be receiving jobs and complete jobs efficiently and quickly freeing up her resources to be aware of what is happening around her.

Ambulance Drivers

Dan is watching his favorite TV show and relaxing with a coffee at the Ambulance station when he hears the dispatch Unit go off. He gets up and goes to the desk and sees that 1 of the 2 Ambulances currently in base at the moment has been picked to attend a suspected heart attack a suburb away. Dan rounded up the crew and got into the Ambulance, accepted the job and proceeded to the address that the unit gave him directions to.

Stakeholder	Ambulance Drivers
Characteristics	Dan is a Happy go lucky guy that loves his job. He likes knowing he can make a difference to people. Anything to make his job easier and quicker he likes.
Nature of Interest	Ambulances need to know where they are needed and need to be allocated to a situation. Knowing how to get there quickly would be a huge benefit.
Benefits to Stakeholder	The system will enable Ambulances to be allocated to situations close to them and tell them how to get there quickly enabling them to respond and potentially save many lives.

Firefighters

Brad was going over the fire truck KX1 doing a quick check of all the equipment before the truck was officially on duty. KX1 battled a large fire last night and Brad wanted to ensure all the stock was up to date. While checking the hoses, Brad found a nick in the main house. Brad realized that the truck cannot be on duty in this state and he was going to have to take it to the Fire Fighter HQ to get a new hose. Brad went inside to the office and on the dispatch system changed KX1 status to out for maintenance.

Stakeholder	Firefighters
Characteristics	Brad has a firefighter for the last 20 years and is very proud of his unit. He is meticulous with his equipment as he has seen the outcome of badly kept equipment. Brad is a bit scared of technology and does not like change all that much.
Nature of Interest	Brad needs inform the dispatch service that the truck is out of order. Brad needs to do this quickly so he can get on with the job of getting it fixed so it can be used again so he can go out and do what he does best.
Benefits to Stakeholder	The new system will enable Brad to quickly and easily take his truck out of service. It is user friendly so people such as Brad feel confident in using it.

SES

There has been a large storm go through Sydney that has seen many people’s roofs damaged, a large number of trees that have fallen across roads and on houses and has left a few suburbs in disarray. There have been hundreds of calls for the SES to put up tarps and clear the trees. The SES only has 50 vehicles that can be dispatched. All 50 vehicles are dispatched, the dispatch system is queuing the jobs to allocate as soon as a vehicle is available that is in that command area.

Stakeholder	SES
Characteristics	The SES is an emergency service but they are called for non life threatening jobs such as fixing roofs, removing trees, doign dangerous jobs that the regular person would/should not attempt. They are made up of majority of volunteers that are on an oncall basis.
Nature of Interest	The SES are called at a high rate when there has been a large scale situation where people are in need. It can become hard to manage the volume and loose track of events.
Benefits to Stakeholder	This system can easliy allocate vehicles to jobs and keep track of who is where and ensure that jobs are not missed. It can also give the SES crew a quick way to get there which will enable them to get to more jobs faster.

Other Emergency services

The Harbor patrol has been watching in interest to see how the new emergency dispatch system has been performing for the current services that are attached to it. They are sufficiently impressed with how the system has improved the management of dispatching for the police and ambulance that they are planning to start looking into being integrated into it for the system to look after their dispatch process.

Stakeholder	Other Emergency services
Characteristics	Other Emergency services such as the Harbour Patrol also get called out to situations where people are in need or a situation needs attending to.
Nature of Interest	They need to be able to respond quickly to a request of help and need to know who is available to go and not to go.
Benefits to Stakeholder	This system can be easily adaptable with a few customisations to be used for any emergency service. It can manage the allocations, the current availability of the services, help the services get to their destination quickly and report on all this activity.

Person in Need

Huey the apprentice tradesman was acting all tough on the tools and thought he was awesome. The site supervisor kept yelling and telling Huey that the tools are dangerous and must be respected otherwise they will bite. Huey thought 'yeh right only if you are an idiot and don’t know what you are doing'. Huey was firing his mouth off while using the staple gun and stapled his thumb the bit of wood he was working on. He screamed and walked backwards onto a shovel which ended up flipping up and smacked him in the head and knocked him unconscious. The site supervisor immediately rang 000 and requested an ambulance as soon as they can. The site supervisor while concerned for Hueys' condition and the amount of paperwork he is going to have to fill out thought to himself' that'll teach the little bugger!'. Within 5 Minutes the Ambulance had arrived at the site to attend to Huey.

Stakeholder	Person in Need
Characteristics	Huey is a typical apprentice, dropped out of school at 16 and thinks he is all that. Huey actually just wants someone to be proud of him.
Nature of Interest	Huey is in need of medical attention immediately. The site first aide has limited knowledge. Huey needs an ambulance straight away.
Benefits to Stakeholder	The system has enabled an ambulance only 3 streets away to be allocated to go pick up Huey. The system enabled the ambulance to get there and to the hospital as fast as possible minimising the amount of time Huey is without the attention he needs which in turn saves his hand.

Hospitals

The ambulance arrived at the hospital within 10 minutes of picking up Huey. Sister Sue was at the door and spoke with the driver and got the run down of the injuries. Huey was wheeled into the hospital and placed in the Emergency Department. Sue checked Hueys vitals and started directing the hospital staff on how to treat him. The Ambulance drivers filled out the required paperwork and left to take the next job.

Stakeholder	Hospitals
Characteristics	Sister Sue receives patients from emergency ambulances. She is one of the best Emergency Sisters in the Hospital. She always likes it when she gets a good run down on the patient’s condition. Sue looks at Huey and thinks he looks just like her son, and thinks thank god he has stayed in school.
Nature of Interest	Sister Sue needs the patient at the hospital as quick as possible to start treatment.
Benefits to Stakeholder	The system will enable emergency patients to be picked up and arrive at hospitals in shorter time giving hospital staff more time with time critical patients. Giving Sister Sue the tmie she needs to attend to people such as Huey.

000 Call Centre

Jill working for her 3 day straight answered the next call coming in to her. On the other end of the phone she heard a little girl. The little girl said 'The house is on fire and mummy is not moving'. After Jill confirmed the address the little girls’ name, while keeping the little girl on the line Jill rang the dispatch centre in Chatswood that she knew was the metro fire centre. She gave Tom at the dispatch centre the details and requested a fire truck. Jill then rang the dispatch centre in Burwood and told Jim at the dispatch centre the situation and she requested an ambulance and police to investigate. Jill kept the little girl on the line until she could hear the Fire-fighters had arrived and were talking to the girl. Jill then told the girl to follow their instructions and she hung up.

Stakeholder	000 call centre
Characteristics	Jill is a very good worker. She has been given worker of the month the last 2 months in a row. Jill likes the fact that she is making a difference by helping people get help.
Nature of Interest	Jill needs to figure out what services need to be dispatched and she needs to co-ordinate them. She needs to ring the dispatch centre and know that they can do their job. The easier and quicker the process the better as it can enable Jill to focus more on the person in need if they are panicky or it can enable her to pick up the next call.
Benefits to Stakeholder	The system enables the Emergency dispatchers to quickly and efficiently put the information in their systems that Jill gives them. Making that quicker enables Jill to answer more 000 calls.

Government

The State Premier has come under recent scrutiny for slashing funds to the Health and services budget. He needs some good material to enhance his status. He tried to spin the media focus onto the new emergency dispatch system that was founded by his office and not only has improved response time in all of the emergency services but has saved a lot of lives in the process.

Stakeholder	Government
Characteristics	The Government is made of political people who have no idea about what is actually involved in the dispatching of Emergency systems but they know that this is a critical issue for the public as the public will have confidence and vote for them if they are seen as funding and proactively enhancing a public need.
Nature of Interest	The Government need a system to show that they are taking the needs of the people seriously. They need positive results in order to use it as a positive spin to get re-elected.
Benefits to Stakeholder	The system will not only improve the response time and management of dispatching of emergency services but it can also quickly produce reports of the statistics that can back up those claims

RTA

The RTA has closed Jones St for 3 months while upgrading and widening the road for it to be used as a semi main road. This St is regularly used by emergency services as a back way to get to the major highway. Tim who is the change manger ensures that he has arranged for a new data upload to the emergency response mapping database.

Stakeholder	RTA
Characteristics	The RTA is Government run organisation with a lot of Red Tape. They are in charge of looking after all the states roads.
Nature of Interest	The RTA need to inform the Dispatch system of changes to routes/roads etc. This
Benefits to Stakeholder	The RTA can promote the fact that they enable and help the emergency services get to their destination quickly by keeping an up to date map that the system can use. This gives them positive publicity.

Developer

Eugine has been put on a new project at his work. SystemsRus have won the contract to develop a new software intensive system to dispatch emergency services. Eugine has been made the head developer. Eugine spends the next few months researching the current system, has many meetings with the customers and stakeholders and his team. Eugine and his team come up with a system they believe will suit the purpose. He is given the go ahead to develop this. Eugine and his team spend the next 4 months developing this system in time for the deployment date in November. In December after a few niggly implementation issues, the system was hailed as a success. Eugine and his team were given a huge bonus.

Stakeholder	Developer
Characteristics	Eugine has been working for SytemsRus for the last 2 years. He thinks he is awesome but most people behind his back think he is a brown noser. Eugine has a Systems Engineering degree and has implemented 3 successful projects in his career.
Nature of Interest	Eugine needs to know all elements of the system and what needs to be developed. He needs to have a hand in all the areas of the system.
Benefits to Stakeholder	Implementing the system will give Eugine another notch in his career and potentially lead him to a huge pay rise.

System Maintainer

Barry from SystemsRus has been allocated as the system maintainer on the Emergency dispatch centre. Barry can’t believe he has been allocated onto one of Eugines great systems again. Barry swore he would not take another one that Eugine had developed as it is such a nightmare to maintain. There are shortcuts everywhere, the coding is unreadable and it seems as if the system is stuck together with sticky tape. Barry demands a pay rise for this, his boss concedes. Every time Barry does an upgrade he seems to fix numerous errors. Barry hates Eugine.

Stakeholder	System Maintainer
Characteristics	Barry is an old school tech. He has lived through the evolution of computers and watched the nature of systems changing. Barry does not like people who think big of themselves and has seen many of these type of people come and go.
Nature of Interest	Barry need to maintain the system. He would like a system that has been developed they way he thinks it should be.
Benefits to Stakeholder	The maintence of the system enables Barry to highlight Eugines defficincies and keeps him in a job.

Usage Narratives

Ambulance Dispatch

Bob
Bob has fallen over and thinks he has broken his leg. He Calls 000 to request an ambulance. Mary who is on shift at the 000 centre takes Bobs Emergency call. Mary then calls Harry working at the Emergency Dispatch System in Burwood which is the dispatch centre responsible for the Metro Ambulance service. Mary informs Harry that there is a man whose name is Bob from 23 Clumsy St has fallen over and thinks he has broken his leg needs an ambulance deployed, he is in pain but not life threatening.

Harry inputs all this information into his screen and hits deploy. Kevin who is driving back to the ambulance station after lunch hears his job notification unit buzzing. His partner checks the Unit and tells him that they are to go to 23 Clumsy St to pick up a patient called Bob who has fallen over and has a suspected broken leg. The Unit then chimes in saying Kevin needed to turn left in 200 meters into Clumsy St and proceed down Clumsy St for a further 400 meters and they will be at 23 Clumsy St.

Fire

Tom
There is a bushfire in the Blue Mountains that has been burning out of control for the last 3 days over Christmas. Tom the Fire Warden has just received a call to inform him that a Southerly has just hit and the 60K winds are leading the fire towards the back burning break line. Tom needs to know where all the firefighters are currently so he can plan how to best attack it as well as warn any trucks that are now in danger.

He asks Sam who is the IT Tech to bring up the screen to show where everyone is. Sam then navigates his way through the Emergency dispatch System to the screen to show the current position of each Rural Fire truck in that particular area.

Tom can see that Trucks BLU2 and KAT1 are in the area the fire is about to turn on, he radios those trucks and advises them to retreat. Tom can then see that KAT2, BLU1, ZIG4 and ZIG5 are all in a good position to hold position and should be able to contain it.

Police

Sergeant Jones
Sergeant Jones was following a suspected stolen Subaru WRX; upon trying to pull it over the WRX sped up.....Sergeant Jones gave chase. The WRX proceeded to overtake other cars in a dangerous manner and crossing to the other side of the road. Sergeant Jones decided the situation had become unsafe and discontinued the pursuit. 3 minutes later the WRX skidded out of control and hit a tree. The suspects accused Sergeant Jones of tapping the WRX causing the accident that resulted in their crash.

The review board requested the movements of Sergeant Jones during that time period. The Emergency Response system was used to retrieve the movement data logs of Sergeant Jones Car for that time period. The data Logs showed Sergeant Jones was 3 streets away from the crash site at the time of the crash.

Sergeant Jones was cleared of any misconduct and allowed back into field duty.

Police

Constable Mike and Kelly
Constables Mike and Kelly were cruising around Trouble St in their patrol car when they spotted something suspicious. While Constable Mike pulled over, Constable Kelly pushed a button on the in-car Unit to advise the dispatch centre they are occupied. Upon getting out of the car, the Constables realised they had come across a drug deal. Constable Kelly was able to apprehend two suspects and Constable Mike after a short run around the block was able to apprehend a third suspect. Upon getting back to the car they realised that not everyone was going to fit so they needed a Paddy Wagon.

Constable Kelly got on the radio to Sally at the Emergency dispatch centre. Sally entered the details into the system and was given the details that there were 2 Paddy wagons and 1 patrol car free in the area. Sally manually allocated paddy wagon KK1 even though Paddy Wagon TS was closer geographically it was not the right command area wagon.

Constable Trevor in paddy wagon KK1 heard his car unit buzz and accepted the job. Sally also radioed Constable Trevor to give him the details of the situation. The unit gave him directions to the address that Constables Mike and Kelly were at.

Quality Attributes

Quality Attributes Ratings

Overview of Attributes

1. Performance

• The capabilities of a machine or product - Oxford Dictionary

The Emergency Response System should have a high performance level. By this, we are primarily referring to the response time of the system, which specifies how long the dispatcher is to wait for the system to complete a series of automated tasks. It is vital that task completion is almost instantaneous, as additional computation time could differentiate between the life or death of a patient. Furthermore it is for these reasons that hardware and component selection is extremely important, which are our reasons for selecting the MySQL DBMS due to its fast response time, and reliability.

In additional scalability is another critical performance factor. Scalability takes into account how well the Emergency Response System performs under heavy loads. The system should still provide rapid response even under heavy loads, to ensure a high level of efficiency or performance from the system.

2. Reliability

• Something or someone that is reliable can be trusted or believed because they work or behave well in the way you expect - Cambridge Dictionary

The Emergency Response System needs to be highly available and reliable. When we discuss issues of reliability, we refer to system up-time, where the system needs to be functioning 24 hours a day without fail. One system failure, could mean hundreds of emergency vehicles failing to be dispatched, and hence risks the life of particular patients. Emergency vehicles operate 24 hours a day, and it is vital that the system operates in par with all these vehicles to provide an effective service. Lets say for instance that the system were only available 12 hours per day. That would mean thousands of patients or people in need are being neglected, and would increase emergency vehicle response time as operators would now have to dispatch manually. It is for these reasons, that the system MUST be highly reliable.

3. Concurrency

• Happening or existing at the same time - Cambridge Dictionary

Concurrency has close links to one of the performance aspects referred to as 'scalability'. The system needs to handle simultaneous access by multiple Dispatch Operators at any given time. If 200 operators are dispatching emergency vehicles at the same time, the system needs to be able to handle all these tasks without failing. The system will always be under heavy work load due to multiple access, and it is vital that efficiency and response times are maintained throughout these loads. Once again, and system failures could mean the difference between the life or death of a patient. Below are two graphs to depict the functioning nature of both a system that performs badly under high workload, and a system that performs well under heavy workload.

Above is a graphical representation of the response time from a system which performs badly as the number of concurrent users increase

Above is a graphical representation of the response time from a system which performs well as the number of concurrent users increase

Trade Offs

1. Security

• Having few worries or doubts about yourself and your personal relationships:

Whilst security is certainly a 'nice to have' feature with the Emergency Response System, it most certainly will never surpass the non-functional qualities of performance, reliability and concurrency. In terms of this system, Security mainly deals with ethical issues such as 'privacy' and 'confidentiality' of data stored within the system. Yes, patient information such as: name, age, gender etc are important, but the rescuing or saving of ones life surpasses every aspect of security. This is not to say that security measures will not be implemented into the system, but rather, that security aspects are not 'mission critical' in the context of the Emergency Response System.

Quality Narratives

Performance

Jodie
Jodie is sitting at her desk twiddling her thumbs waiting for an emergency call to come through on the phone. After 5 minutes, her phone rings and she is informed that someone has been stabbed at Fairfield train station, and that an ambulance is needed immediately. The 000 representative proceeds to provide Jodie with the following information:

Address: 1B Olive Street, Fairfield
Age: 55
Condition: Critical, multiple stab wounds to the chest and back
Coordinates (23,78)
Gender: Male
Name: Giorgio Armani

Jodie promptly types in this information as fast as she can, selects ambulance from the interface and promptly presses the 'dispatch' button. Jodie is greeted with an almost instantaneous acknowledgment message, informing her that an ambulance has been dispatched, and is on its way to the emergency location

Reliability

Joseph
Joseph can never seem to get out of bed in the morning and considers himself to be very much a nocturnal 'night rider'. He hates early mornings, and has destroyed his last five alarm clocks when they ring in the morning. To solve this problem, Joseph has offered to work night shifts, from midnight to 8am, instead of the standard 9am to 5pm routine. He enters work at midnight, and proceeds to find his desk and log into the system. The night is quiet, and by 3am Joseph still hasn't received a call from 000 to inform him of an emergency. Joseph thinks he has struck gold, as there are fewer emergencies at this time of night since most people are sound asleep in bed. Just before he is about to go to the vending machine to grab a Kit-kat, the phone rings and Joseph answers. Joseph is informed by the 000 operator that 5 police cars, and 3 riot squads are needed in Macquarie Fields, as there is currently a riot taking place. The operator provides the following information:

Address: 12 Riot Street, Macquarie Fields
Condition: Over 80 people rioting through the streets, lighting cars on fire, and throwing bottles and rocks
Coordinates (29,90)

Because Police cars need to be assigned manually, Joseph begins to type in the information into the system. He then selects the 5 police cars which are closest to the riots, and currently available and assigns them the task. He hits the 'dispatch' button and all 5 police cars are dispatched promptly. He then selects riot squad from the vehicle list and automatically dispatches 3 riot squad vehicles within seconds. Both acknowledgments for the police cars and riot squads are received promptly, and Joseph is satisfied with his work. He then realises that system fully operates at even the nocturnal hours of the night, such as 3am, and proceeds to the vending machine to purchase that incredibly tempting Kit-kat.

Concurrency

Salim
Salim was on his lunch break after a solid 4 hours on the phones working as a Dispatch Centre Operator. Just as he thought he would be able to devour that double whopper and fries which he had in his mind since the beginning of his shift, a tornado tore through the eastern suburbs of Sydney. Hundreds of people now require emergency assistance and the phones begin to ring furiously and constantly. The Call Centre Manager calls for all people who are currently on their lunch break to stop what they are doing, and jump on the phones, as it is now a matter of life or death.

Salim throws his whopper and fries in the bin and runs to his desk to log back into the system. After logging into the system Salim's phone rings instantly. There are currently over 500 operators using the system simultaneously as ambulance after ambulance are dispatched rapidly. Salim is informed by the 000 operator that a female is seriously injured from the tornado, and is in need of immediate assistance. The operator provides Salim with the following information:

Address: 5 Beverly Road, Bondi
Age: 51
Condition: Critical, patient has been impaled in the back by a flying bin
Coordinates (59,86)
Gender: Female
Name: Donna Versace

Salim furiously types this information into the system and selects ambulance from the vehicle list. He then proceeds to press 'dispatch', and receives an acknowledge request without delay. Salim then realises the response was extremely fast in relation to how many people are currently using the system, and smiles.

Conceptual Architecture

Initial Conceptual Architecture

Version 1.0

Version 1.1

Elaborated Conceptual Architecture

Final Conceptual Architecture

Architectural Decisions

The architecture was implemented on the basis of providing a system which functions which high level of reliability, efficiency and performance. Major stakeholders of the system, such as: Emergency Service Dispatchers, need a system that dispatches vehicles without delay, and without crashing. If delay occurs, it could lead to the death of a person in need.

To counter this, and to adhere to the needs of valuable stakeholders, a 3-tier archtectural model has been implemented. This ensures each layer is responsible for dedicated tasks, which makes data more managable witin the system. This will improve efficiency, as network traffic will be reduced, and there is less chance the system will become saturated. With a traditional 2-tier approach, there is excessive load placed on the network, due to heavy interaction between client and server. For these reasons, a 3-tier approach has been implemented for the protoype.

Furthermore, the HTTP server interacts directly with the server, so the serer can act as a central medium between the database and presentation layers. This means we don't have multiple components opening new connections to the HTTP server, thus reducing network traffic and improving efficiency of the system.

In addition, the current architectural model will be incrementally scalable, so that futre interations of the systems can be implemented. For example, if changes need to be made with the Graphical User Interfaces, the other layers are not effected. This ensured system upgrades are bost fast, and easy to do.

Initially, the group decided to trade off the non-functional quality of security. However, due to to time constraints, we decided to soley focus on 2 key non-functional qualities: Performance and Security. Security was implemented by introducing an Authentication Logic module, which retrieves a user's role from the MYSQL database, and provides them access ONLY to the applicable user interfaces.

With the current 3-tier model of the system prototype, a few constraints can arise. Firstly, the system will need to work with the different protocols associated with particular stakeholders. For example, if a HTTP server is not present, the remote client will not receive any updates in regards to a particular emergency. Also particular stakeholders may not be using the MYSQL Database Management System, in which case the current database will need to be ported over to a new DBMS.

Through thorough testing of the prototype, we have concluded that the system operates efficiently across a Local Area Network, with all connections being handled by the Central Server. This ensures data is managed effectively, and routed to the appropriate module.

Prototype Results

Conceptual Component Analysis

User Authentication View

• Displays a login screen to the user for user identification purposes
• Login data will be entered in the form of a: username, and a password which will be unique for each user. This will distinguish between access rights for general staff and higher level management

Authentication Logic

• This component will take input in the form of the user's Login details and verify these details with the database
• The users login details will be stored within the database, where the username will be matched to a corresponding password. If both details are correct, the user will be allowed access to the relevant features

Manual Vehicle Assignment

• This view will allow the user to manually dispatch police vehicles only
• The user will manually search for the closest police car, before dispatching the closest. This is because police tasks cover a wide scope, so automatic dispatch would not be reasonable
• In relation to the data model, the user will be able to view the data held within the 'Vehicle' component of the data model. The user will see: Availability, Coordinates, Suburb, VehicleID and VehicleType, which will be sufficient in allowing an operator to manually assign the closest vehicle to the emergency situation.

Log Analysis View

• This view will be used for admin staff to view dispatch call details on all staff, to ensure efficiency and proper work practices
• This information will be logged once a dispatch operator receives a call. It will log the vehicle dispatched, and also the time it took to dispatch a vehicle. This will be deduced by calculating the time difference between when the operator receives the call, to when the acknowledgment is received by the operator, informing them that the vehicle has been dispatched
• This module will also keep track of the number of vehicles dispatched per operator, to ensure that all staff are dispatching vehicles with minimal delay
• From the data model, we can see that the following information will be logged for analysis on particular operators: Date, DispatchID, Duration, NoOfVehicles, Time and VehicleID

Emergency Response View

• Is the initial / default screen emergency dispatch operators will view, when receiving a call with regards to a particular emergency
• Emergency data is entered into system using this view via external hardware such as a keyboard
• Emergency data is in the form of: Address, Age, Condition, Coordinates, Gender and Name, which can be seen from the data model of the system

Report View

• Displays a report on the status of particular vehicles
• Status will include the GPS tracking logs of the particular vehicle, and whether the vehicle is available or unavailable (due to maintenance).
• This information can be seen in the data model from the 'Vehicle' and 'Vehicle Log' components, where the following data will be stored: Date, DistanceTravelled, Location, Time and VehicleID

Admin View

• This view will provide a complete list of statistics to high end management
• It will list statistics on the number of errors which have occurred with dispatches, such as the wrong vehicle being dispatched, and will also communicate with the database to provide information on performance of different vehicles.
• High end management can use these statistics for analysis, and deduce whether the system needs improvement, and if so, devise a plan to successfully do this.
• This data can be seen in the data model, within the DispatchLog component, as: NoOfErrors.

Vehicle Calculator

• Takes emergency data as input, including: Address, Age, Condition, Coordinates, Gender and Name, which can be seen from the 'Emergency' component of the data model
• Uses emergency data to calculate the distance to the closest ambulance. A two-dimensional plane will be assumed.
• Distance will be calculated using two two-dimensional distance coordinates in order to find the shortest distance to a particular vehicle within the vicinity
• Vehicle data used for the calculation, is taken directly from the Database

Vehicle Assignment

• Takes input from the Vehicle Calculator in the form of Availability, Coordinates, Suburb, VehicleID and VehicleType which can be seen from the 'Vehicle' component of the data model
• Uses vehicle data to form a message, which is to be sent to the particular assigned vehicle.
• The selected vehicle will be alerted of the message, and the Remote Client / Magical System will provide the vehicle operator with appropriate instructions on how to reach the destination

Report Generator

• Module will access database to retrieve logged vehicle tracking data, such as: Date, DistanceTravelled, Location, Time and VehicleID, which can be seen from the VehicleID component of the data model
• Retrieved data will be prepared and organised in report format by this module, for presentation to the Report View Module

Message Handler

• Will be used to update the Database after a particular vehicle is assigned. Once the message handler receives and acknowledgment from the Remote Client / Magical System, it will then flag the vehicle as 'unavailable' in the database.
• It will also provide a response to the dispatch centre operator, informing them if the vehicle has been successfully assigned or not. The operator only receives a response once the Handler has received a response from the Remote Client / Magical System. This acknowledgment is represented as a boolean called: Ack, which can be found in the Dispatcher component of the data model

Error Report

• Error report will act as a storage module. It will keep track of all all the errors encountered within the system, and will have direct access to the main database. This will be stored as: NoOfErrors within the DispatchLog entity of the data model
• Error report will also communicate with message handler, to update the error count whenever message handler does not send an acknowledgment back to the operator

Database

• This is the central storage device which will store vehicle data including: VehicleID, VehicleType, Coordinates, Availability, Suburb and Logs. All this information can be found in the Vehicle entity of the data model
• The database is accessed by four other modules: Vehicle Calculator, Message Handler, Report Generator and the Remote Client / Magical System
• It provides the Vehicle Calculator module with the coordinates of the vehicle so a distance calculation can be performed
• It allows access of the Message Handler, to update a vehicles status
• It provides vehicle information to the Report Generator module, so a vehicle report can be produced
• It has the capabilities of directly communicating with the Remote Client / Magical System to automatically update a vehicle's status once the Remote Client / Magical System acknowledges the task
• The database is a central storage location for the majority of data held within the system, which will include data from both the Vehicle and Emergency entities which can be seen from the data model

Use Case Maps

Administrators

The administrator use case map demonstrates the user functionality required by technical personnel to troubleshoot and manually update the database.

AuthenticateAdmin: This use case shows how an administrator would log onto the system. At the User Authentication View, the administrator enters his/her details. The details are then passed to the Authentication Logic component. This component is responsible for getting the user login details from the Database, and compares it with the details entered by the user. If the user has been incorrectly identified, then the user will be notified of that error at the User Authentication View. Otherwise, the administrator will be taken to the Admin view.

ViewErrorReport: This use case shows how an administrator would view error reports after successful authentication. After successful authentication, the administrator is taken to the Admin View. From this view, the administrator is able to view error reports. The system will request data from the Error Report component, and the response will be displayed at the Admin View.

ModifyDatabase: This use case shows how an administrator would modify the database after successful authentication. After successful authentication, the administrator is taken to a Admin View. From this view, the administrator is able to make changes to the database, since the Admin View is connected directly to the Database component for modification.

Emergency Personnel

The emgergency personnel use case map demonstrates the user functionality required by dispatch operators, and fire/ambulance/police/ses staff to input emergency details, manually suspend and select a vehicle, and finding out the closest vehicle.

AuthenticateERUser: This use case shows how an emergency response personnel/data operator would log onto the system. At the User Authentication View, the emergency response personnel/data operator enters his/her details. The details are then passed to the Authentication Logic component. This component is responsible for getting the user login details from the Database, and compares it with the details entered by the user. If the user has been incorrectly identified, then the user will be notified of that error at the User Authentication View. Otherwise, the user will be taken to the Emergency Response View.

AssignVehicle: This use case shows how an emergency response personnel/data operator would manually assign a vehicle after successful authentication. After successful authentication, the emergency response personnel/data operator is taken to the Emergency Response View. From this view, the emergency response personnel/data operator is able send a request to manually assign a vehicle. The process involves the emergency response personnel/data operator to enter a vehicle they would like to select. This information will be given to the Manual Vehicle Assignment component, which will check with the Vehicle Assignment module to determine if that requested vehicle is available. The Manual Vehicle Assignment module will update the Database after successfully assigning a vehicle, and will inform the emergency response personnel/data operator of the success via the Emergency Response View.

GetClosestVehicle: This use case shows how an emergency response personnel/data operator would check for the closest vehicle after successful authentication. After successful authentication, the emergency response personnel/data operator is taken to the Emergency Response View. From this view, the emergency response personnel/data operator is able send a request to get the closest vehicle. This process involves the emergency response personnel/data operator to enter address details/location. The details are sent to the Vehicle Calculator module, which is responsible for calculating the closest vehicle. A Vehicle Assignment component will provide the Vehicle Calculator with information as to which vehicle is not assigned to a task. This information will be presented to the emergency response personnel/data operator via the Emergency Response View.

ViewCallLogs: This use case shows how an emergency response personnel/data operator would view call logs. After successful authentication, the emergency response personnel/data operator is taken to the Emergency Response View. From this view, the emergency response personnel/data operator is able send a request to view call logs. Once the user has sent the request, the system will take the user to the Log Analysis View. The Log Analysis View, other than being a presentation stereotype, is also a persistence stereotype. The Log Analysis View will fetch the call logs and display it to the user.

SuspendVehicle: This use case shows how an emergency response personnel/data operator would suspend a vehicle. After successful authentication, the emergency response personnel/data operator is taken to the Emergency Response View. To suspend a vehicle, the emergency response personnel/data operator would need to enter the vehicle ID. This ID is sent to the Manual Vehicle Assignment module. The module will then update the Database to suspend the vehicle, and will inform the emergency response personnel/data operator if the request was successful at the Emergency Response View.

Managers/Team Leaders

The managers/team leaders use case map demonstrates the user functionality required by power users to generate and view reports.

AuthenticateManager: This use case shows how a manager/team leader would log onto the system. At the User Authentication View, the manager/team leader enters his/her details. The details are then passed to the Authentication Logic component. This component is responsible for getting the user login details from the Database, and compares it with the details entered by the user. If the user has been incorrectly identified, then the user will be notified of that error at the User Authentication View. Otherwise, the user will be taken to the Report View.

ViewCallLogs: This use case shows how a manager/team leader would view call logs. After successful authentication, the manager/team leader is taken to the Report View. From this view, the manager/team leader is able send a request to view call logs. Once the user has sent the request, the system will take the user to the Log Analysis View. The Log Analysis View, other than being a presentation stereotype, is also a persistence stereotype. The Log Analysis View will fetch the call logs and display it to the user.

ViewReports: This use case shows how a manager/team leader would view reports. After successful authentication, the manager/team leader is taken to the Report View. From this view, the manager/team leader is able send a request to view reports. Once the user has sent the request, the system will call the Report Generator module. The Report Generator module will fetch data from the Database, and generate a report. The report is then displayed to the user via the Report View.

Data Model

Above: Initial Data Model

The model above shows the initial, overall representation of data within the system. The data model is presented, using the following information as its basis:

Dispatcher

• A 'Dispatcher' is an individual working within the Dispatch Centre.
• Information will be stored on every Dispatcher working within the Dispatch Centre. This information includes:

Name: The first and last names of each Dispatcher working within the Dispatch Centre

DispatchTotal: The number of vehicle dispatches made per worker within the Dispatch Centre

DispatchID: Unique ID number for each individual working within the Dispatch Centre

Ack: Acknowledgment in the form of a boolen, informing the operator whether the vehicle has been successfully dispatched or not

• 1 Dispatcher will a minimum of 1, and a maximum of many Dispatch Logs. A new log will be created each day, for each Dispatcher [1..* cardinality]

• 1 Dispatcher will dispatch a minimum of 0, and a maximum of many Vehicles [0..* cardinality]

• 1 Dispatcher will receive a minimum of 0 Emergency Calls, and a maximum of many Emergency Calls on any given day [0..* cardinality]

Vehicle

• A 'Vehicle' depicts an emergency vehicle such as: Police Cars, Fire Trucks etc
• Information will be stored on every vehicle which can be dispatched. This information includes:

Availability: This will be a boolean flag. It will be set to 1 when a vehicle is currently occupied and carrying out a task. Once the vehicle is free, it will be set to 0

Coordinates: A 2D coordinate plane will be assumed. This will be two coordinates which outline the vehicles current location. A simple distance formula can be used to calculate the distance between the vehicle itself, and the patient

Suburb: This will identify the current suburb where the vehicle is currently situated

VehicleID: This will be a unique ID given to each vehicle to distinguish between vehicles of the same type

VehicleType: This will outline the type of vehicle, such as: police, fire, medical etc

• 1 Vehicle can only be dispatched by 1 Dispatcher [1..1 cardinality]

• 1 Vehicle is dispatched to a minimum of 0 and a maximum of many Emergencies [0..* cardinality]

• 1 Vehicle has a minimum of 1 and a maximum of 1 Vehicle Logs per day. A new log will be recorded for each vehicle on a per day basis. [1..1 cardinality]

Emergency

• An Emergency is classified as and the emergency a vehicle must attend to provide help to a particular patient
• Information will be stored on every emergency received on a given day. This information includes:

Address: This is the current address of the person in need of help

Age: This is the age of the person who is in need of assistance

Condition: This is the current situation or problem, such as person being ill, cat stuck up a tree etc

Coordinates: These are the 2D coordinates of the person in need of help, which can be used to calculate the distance to the nearest Vehicle

Gender: This is the sex of the individual, which will be important if medical assistance is required

Name: This is the first and last names of the person in need of help

• 1 Emergency can only be received by a minimum of 1 Dispatchers and a maximum of 1 Dispatchers [1..1 cardinality]

• 1 Emergency can be assigned to a minimum of 0 Vehicles, and a maximum of many Vehicles [0..* cardinality]

Dispatch Log

• A dispatch log will be recorded on a per daily basis on every Dispatcher. This log will be uses for statistics analysis by high end managers.
• Multiple pieces of information will be be stored on a Dispatcher within the Dispatch Log, including:

Date: This is the date the log was taken

DispatchID: This is the ID of the Dispatcher. Each log will be sorted using the ID of the Dispatcher

Duration: This will hold the duration of calls taken throughout the day, for statistical analysis

Time: This will hold the times that each call came in throughout the 24 hour window

VehicleID: This will be the ID of the Vehicle which was dispatched. This is so statistical analysis can be conducted, on whether the correct vehicle was dispatched or not

NoOfErrors: This will keep track of the number of dispatch errors encountered per day. If the incorrect vehicle was dispatched, or a vehicle was not dispatched when it was supposed to, this attribute will be updated

NoOfVehicles: A count of the number of vehicles sent out on any given particular day. This will server as analysis data for high end management

• 1 Dispatch Log has a minimum of 0 and a maximum of 1 Dispatchers associated to it [1..1 cardinality]

Vehicle Log

• Data will be logged about all vehicles which are currently operating. This is so that analysis can be conducted on there whereabouts on a particular day.
• Numerous data will be collected about each emergency vehicle, including:

Date: This data will be date the log was taken

DistanceTravelled: This will be the total distance travelled per vehicle on a given day

Location: This will record the location of the vehicle, with regards to a timestamp

Time: This will record the time the log was or GPS reading was taken, in relation to a vehicles current location

VehicleID: This is the unique ID that identifies each vehicle, so that the logs can be filtered per vehicle ID if needed

• 1 Vehicle Log has a minimum of 0 and a maximum of many Vehicles associated to it [0..* cardinality]

Inintial Executional Architecture

Initial Concurrent View

Component Explanation

Client Application

The Client Application calls the Reporting, Vehicle Calculator and Vehicle Assignment asynchronously to ensure that the user interface remains responsive to the user at all times. As data analysis can potentially take a lengthy time to complete, a callback is used so that the Data Analysis component can call the Client Application to report the results when they are ready. It is expected that there will be multiple client applications accessing the system concurrently.

Vehicle Calculator

The Vehicle calculator takes the dispatch address and searches the database for the closest vehicle to the dispatch address. The closest vehicle information is then passed on to the Vehicle Assignment.

Vehicle Assignment

Vehicle Assignment accepts vehicle ID as inputs from either automatic assignment through the vehicle Calculator or manual assignment where the dispatch user manually selects and supplies the information for the required vehicle. Vehicle Assignment then forwards the dispatch data to the chosen vehicle.

Reporting

Reporting will be triggered by an asynchronous call from the Client Application. It will execute the requested queries against the source data in Data Storage through a synchronous call as it can not proceed without the data being returned. Once it has received the requested data, the data will be returned through the original call from the Client Application.

Data Storage

Data Storage has been designated as a service as it has to respond to various calls from other subsystems. It is the primary data persistence entity for the system and is critical in nature to the system as a whole. As it is a distributed system and for performance reasons, it is viewed that there may be multiple concurrent instances of the Data Storage running.

Remote Message Handler

The remote message handler deals with the sending and recieving of information between the Client application and the vehicle remote clients. Data is recieved and the message handler determines what is done with the inomming data. Vehicle positioning data is recieved and the message handler stores it directly in the database for future logging/reporting. Outgoing data such as dispatch information is passed through the message handler and forwarded to the respective vehicle.

Final Execution Architecture

Updated Concurrent View

Improvements

The initial concurrent view highlighted the lack of planning for concurrent process. The updated Concurrent View of the Execution architecture show the ability of the system to now effectively deal with one of the systems main quality attributes being concurrency.

Component Explanation

Client Application

The Client Application calls the Vehicle Assignment and Reporting, asynchronously to ensure that the user interface remains responsive to the user at all times. As data analysis can potentially take a lengthy time to complete, a callback is used so that the Data Analysis component can call the Client Application to report the results when they are ready. It is expected that there will be multiple client applications accessing the system concurrently.

Vehicle Calculator

The Vehicle calculator takes the dispatch address and searches the database for the closest vehicle to the dispatch address. The closest vehicle information is then passed on to the Vehicle Assignment.

Vehicle Assignment

Vehicle Assignment forwards the vehicle data that the Vehicle calculator needs to assign a vehicle automatically, such as the address and type of vehicle needed.

Reporting

Reporting will be triggered by an asynchronous call from the Client Application. It will execute the requested queries against the source data in Data Storage through a synchronous call as it can not proceed without the data being returned. Once it has received the requested data, the data will be returned through the original call from the Client Application.

Data Storage

Data Storage has been designated as a service as it has to respond to various calls from other subsystems. It is the primary data persistence entity for the system and is critical in nature to the system as a whole. As it is a distributed system and for performance reasons, it is viewed that there may be multiple concurrent instances of the Data Storage running.

Connection Handler

The Connection handler deals with concurrent objects accessing the system simultaneously. Data is received and the message handler determines what is done with the incoming data.

Threaded Server

The threaded server allows multiple sockets to be opened at the same time for concurrent processing. This allows multiple processes to be fulfilled without halting the system for any amount of time.

HTTP Server

The HTTP server allows multiple connections to be handled between the External remote clients and the threaded server. The HTTP server is polled by the browser window of the external client for new dispatch requests.

External Client

The External Clients are representation of the multiple in car communication units that the dispatch information and acceptance will be handled through. As illustrated it is a synchronous call as the job sent to the Client needs to be accepted for the process to complete. Multiple external clients can access the HTTP Server simultaneously via the connection handler.

Deployment Based View

The diagram above shows the deployment based view of the Emergency Response Dispatch System. The system uses a database server, which connects to the threaded server. The Client UI is essentially the application, and this connects directly to the server. The HTTP Server is connected both to the server and the external HTTP Remote Client Connection.

There is a backup database server which will be in almost real time sychronous with the real database to fullfill the reliability quality attribute.

These are the components that support the software architecture.

Behavioural

Below are the different behaviours of the system and their description.

Administrator

The administrator use case map demonstrates the user functionality required by technical personnel to troubleshoot and manually update the database.

AuthenticateAdmin: Administrator would log onto the system. At the User Authentication View, the administrator enters his/her details. The details are then passed to the Authentication Logic component. This component is responsible for getting the user login details from the Database, and compares it with the details entered by the user. If the user has been incorrectly identified, then the user will be notified of that error at the User Authentication View. Otherwise, the administrator will be taken to the Admin view.

ModifyDatabase: This use case shows how an administrator would modify the database after successful authentication. After successful authentication, the administrator is taken to a Admin View. From this view, the administrator is able to make changes to the database, since the Admin View is connected directly to the Database component for modification.

ViewErrorReport: This use case shows how an administrator would view error reports after successful authentication. After successful authentication, the administrator is taken to the Admin View. From this view, the administrator is able to view error reports. The system will request data from the Error Report component, and the response will be displayed at the Admin View.

User

The emgergency personnel use case map demonstrates the user functionality required by dispatch operators, and fire/ambulance/police/ses staff to input emergency details, manually suspend and select a vehicle, and finding out the closest vehicle.

AuthenticateERUser: This use case shows how an emergency response personnel/data operator would log onto the system. At the User Authentication View, the emergency response personnel/data operator enters his/her details. The details are then passed to the Authentication Logic component. This component is responsible for getting the user login details from the Database, and compares it with the details entered by the user. If the user has been incorrectly identified, then the user will be notified of that error at the User Authentication View. Otherwise, the user will be taken to the Emergency Response View.

AssignVehicle: This use case shows how an emergency response personnel/data operator would manually assign a vehicle after successful authentication. After successful authentication, the emergency response personnel/data operator is taken to the Emergency Response View. From this view, the emergency response personnel/data operator is able send a request to manually assign a vehicle. The process involves the emergency response personnel/data operator to enter a vehicle they would like to select. This information will be given to the Manual Vehicle Assignment component, which will check with the Vehicle Assignment module to determine if that requested vehicle is available. The Manual Vehicle Assignment module will update the Database after successfully assigning a vehicle, and will inform the emergency response personnel/data operator of the success via the Emergency Response View.

GetClosestVehicle: This use case shows how an emergency response personnel/data operator would check for the closest vehicle after successful authentication. After successful authentication, the emergency response personnel/data operator is taken to the Emergency Response View. From this view, the emergency response personnel/data operator is able send a request to get the closest vehicle. This process involves the emergency response personnel/data operator to enter address details/location. The details are sent to the Vehicle Calculator module, which is responsible for calculating the closest vehicle. A Vehicle Assignment component will provide the Vehicle Calculator with information as to which vehicle is not assigned to a task. This information will be presented to the emergency response personnel/data operator via the Emergency Response View.

ViewCallLogs: This use case shows how an emergency response personnel/data operator would view call logs. After successful authentication, the emergency response personnel/data operator is taken to the Emergency Response View. From this view, the emergency response personnel/data operator is able send a request to view call logs. Once the user has sent the request, the system will take the user to the Log Analysis View. The Log Analysis View, other than being a presentation stereotype, is also a persistence stereotype. The Log Analysis View will fetch the call logs and display it to the user.

SuspendVehicle: This use case shows how an emergency response personnel/data operator would suspend a vehicle. After successful authentication, the emergency response personnel/data operator is taken to the Emergency Response View. To suspend a vehicle, the emergency response personnel/data operator would need to enter the vehicle ID. This ID is sent to the Manual Vehicle Assignment module. The module will then update the Database to suspend the vehicle, and will inform the emergency response personnel/data operator if the request was successful at the Emergency Response View.

Manager

The managers/team leaders use case map demonstrates the user functionality required by power users to generate and view reports.

AuthenticateManager: This use case shows how a manager/team leader would log onto the system. At the User Authentication View, the manager/team leader enters his/her details. The details are then passed to the Authentication Logic component. This component is responsible for getting the user login details from the Database, and compares it with the details entered by the user. If the user has been incorrectly identified, then the user will be notified of that error at the User Authentication View. Otherwise, the user will be taken to the Report View.

ViewCallLogs: This use case shows how a manager/team leader would view call logs. After successful authentication, the manager/team leader is taken to the Report View. From this view, the manager/team leader is able send a request to view call logs. Once the user has sent the request, the system will take the user to the Log Analysis View. The Log Analysis View, other than being a presentation stereotype, is also a persistence stereotype. The Log Analysis View will fetch the call logs and display it to the user.

ViewReports: This use case shows how a manager/team leader would view reports. After successful authentication, the manager/team leader is taken to the Report View. From this view, the manager/team leader is able send a request to view reports. Once the user has sent the request, the system will call the Report Generator module. The Report Generator module will fetch data from the Database, and generate a report. The report is then displayed to the user via the Report View.

Initial Implementation Architecture

The architecture as depicted above represents what components are used, and their interactions with each other. The dispatch applications component has its separate routine, to ensure it doesn't affect user interfaces, and to streamline data throughput. Using Java Components and the use of MySQL allows for scalability, since the infrastructure is robust and can be upgraded as demand grows.

Java is the framework for the user interface, as Java is multi-platform, allowing for maximum userbase, and minimum coding for different platforms. MySQL is used to handle database transactions, and is open source, so its widely supported.

Final Implementation Architecture

Implementation Architecture Description

The final Implementation architecture consist of 6 major components which tie together to form the functionality of the system.

Implementation starts with a Authentication layer. This layer accepts a username and password and when prompted it searches the database to find matching entries. If matching entries are found the user is allowed access to the parts of the system that their security clearance allows them access to. Otherwise if no matching entries are found the user is not allowed access past the login screen.

We decided to use the database to store login details because it allowed many users credentials to be stored on the database as well as their security levels. It also allowed easy modification of a username and password or security level without interupting all other users login's.

Depending on the users login access rights the user is taken to one of 3 areas; A general user is taken to the dispatch screen, Admin is taken to the admin error report screen and the manager has access to the reporting screen.

The dispatch screen allows the dispatcher to enter emergency details including Name, address, phone, comments, etc. Based on the Address the 'vehicle calculator' searches the database for a local vehicle and sends a dispatch request to that vehicle. The emergency details are also stored in the database.

The 'Vehicle Communications' component utilises a HTTP server and updates a web server with the dispatch request.

The Vehicle mounted 'remote client' uses a web browser to continuously poll the web server to check for jobs. When the 'vehicle communicator' sends the job request it is displayed on the vehicles browser. All of the emergency details are displayed in the request to allow the vehicle to assess the job before accepting.

A vehicle user can accept a job by selecting accept at which point an acknowledgement is sent to the dispatch server notifying it that the dispatched user is currently on a job and not available for further dispatch until the job is completed. Likewise when the job is finished the vehicle user notifies the dispatch server that it is now available for dispatch again. An available flag in the database is raised and dropped accordingly when notifications are received from the vehicle.

The Admin user has access to the admin user interface which shows error reporting of incorrect data entry or null data, etc. These errors are stored in the database and the error reporting pulls the errors out of the database to display for the user.

The Manager User has access to the reporting interface. The reporting interface pulls dispatch logs out of the database and displays them to the manager. Vehicle status is also displayed in the report interface.

We implemented the system using MySql and Xamp due to constraints in the engineering computer lab not allowing a networked MySql install. We also used the standard widget toolkit (SWT) swing component in order to creat the Graphical user interface due to wide availability and acceptance as well as ease of use.

Quality Attributes

Performance: The architecture has been thought and developed around unprejudiced execution flow. The execution flow has a lot of interaction with the database which maintains the integrity of the system as one central hub of information to be inserted and gathered from. One of our considerations were to utilise more than one database to enhance the performance. However, the scope of the prototype was only limited.

Another action item to improve the performance was to include java packages. Creation of java packages by combining similar functionalities also optimise the performance of the system.

Reliability: functionally the system was found to be very reliable. Note that this is not a many to many relation, it is still effectively a single server managing many users in terms of various clients

Concurrency: Concurrency has close links to one of the performance aspects referred to as 'scalability'. The system will be able to handle simultaneous access by multiple Dispatch Operators at any given time. If 200 operators are dispatching emergency vehicles at the same time, the system needs to be able to handle all these tasks without failing. The system will always be under heavy work load due to multiple access, and it is vital that efficiency and response times are maintained throughout these loads. Once again, and system failures could mean the difference between the life or death of a patient.

Constraints

There were number of constrains to be considered for emergency response system. The system was carefully designed to minimise the impact of these constraints to prevent problems in future and improve maintenance.

Use of Java packages in our code to organise our file structure a little better, files collectively together based on their functionalities. We imported java packages in our project but we didn’t create any to manage the files into one directory. We believe by having done so we could have not only improved the performance but mainly helped with maintenance of the code during the run of the project. Furthermore it allows a better structural approach around the code for segregation and understanding.

Use of hierarchy within the architecture and divide the layers into GUI, Business Logic and database and Server communication If we were to use parallel servers we could have potentially costs and improving processing power, providing better responding time. Load balancing is also an important consideration, there are many off the solutions available on the market which would have been suitable for this task.

Initial hardware setup costs can be steep depending on the level of reliability required. Before investing in hardware, one of the important exercises is to have the expectations of load coming through and desired response times. Further more constraints also included limited costs for the project and development time.

Problems with Implementation Architecture

As mentioned previously one major problem with this implementation architecure is the fact that user access levels do not cascade. This means that while the basic dispatch user can dispatch jobs; a higher level admin or manager can not. This is an issue that only became apparent during our final demo.

Future Milestones

• As time goes on and we further analyse the system we continually add more and more responsibilities to the system and by now it is suffering from a mild case of requirement creep. As a group we need to decide on what requirements are paramount and which ones may be considered an 'option' so as not to overload the first build of the system.

• Unfortunately our group as a whole lack the level of Java programming skills to make the prototype section of the assignment as well designed as we would like. Neither of us currently possess the required Java skills to produce a prototype to the standard the subject requires; hence all of us are required to work extremely hard to build on our Java knowledge.

Reflections

Design Critique / Team Reflection

The current architecture utilises a 3-tier model which was used when developing the ERS system prototype. Through thorough testing, we have found that this architecture satisifes the needs of the system and operates effectively over a TCP/IP network. With the server making all decisions and routing the appropriate information, it ensures that data is managed effectively, and network traffic is reduced significantly. A system as critical as this, should not become saturated under high work load, which is why the 3-tier approach was utilised.

However, the current architecture does not allow Manager's to perform the system operations of a standard user. A better approach would have been to have a central ERView inteface, and tabs or buttons that link to additional features accessible only to those users with the required roles. This will ensure the presentation layer is neater, and caters for every user's access rights.

Furthermore, for the current design, the Vehicle Assignment class was reduced to simply store particular details about an emergency vehicle. A better approach would have been to implement some sort of coordinate sytem using a random number generator. The generator would generate a set of x and y coordinates for a particular vehicle, and perform a distance calculation with the coordinates of the emergency. This would help model real situations better, as the locations of every vehicle will be changing on a regular basis. Currently, we are assigning vehicles based on suburb, and merely selecting the first vehicle in the database from that suburb. If, a vehicle from that suburb is not available, our prototype selects a default vehicle and dispatches it. A better approach would have been to incorporate a manual dispatch module, where a dispatcher could dispatch a vehicle manually, if there are currently no vehicles residing in the emergency suburb. This would allow the dispatcher to select a vehicle from a neighbouring suburb, ensuring the emergency is attended to as soon as possible.

Overall we are satisfied with the design of the system, in the short period that we have to develop it. Whilst there are many design concepts which could be changed, the system adheres to the focal non-functional qualities of: performance, efficiency and security.

Pippa Flanagan

This subject has enabled me to appreciate the impact of design vs implementation and the importance of incremental methodologies rather than waterfall.

In milestone 1 our team felt we had a pretty sturdy system. The use case maps worked, the system looked to be feasible. Once we got into the development we realised there were a lot of issues that we could not technically develop. We then were able to go back and update our architecture to iron out the imperfections caused by lack of understanding of the system.

Due to everyone having a lack of suitable Java programming the development of the simple framework took longer than anticipated hence some system functionality was not able to be verified. This would come in the next iteration. Managing the development of the executable prototype was tricky as we did not have a solid design and we could not allocate the workload appropriately. Members ended up working on the same bit of code. This was not efficient and more time was spent on development that was first planned.

After analysing a real dispatch system we were able to model ours while taking note of the issues that the system had to try and correct them. However we had not realised that we had only set out the system functionality in our architecture, we had not taken into account how to design for our quality attributes. This is one time when the design was halted and a relook was established.

There was a fairly informal atmosphere in the team dynamics. This worked for us and against us. While the relaxed atmosphere enabled us to have a good camaraderie it also resulted in an unbalanced amount of work as some people had higher expectations than others. There was also an issue of a team member who was absent for all of milestone 1. This was a disadvantage for them in milestone 2 as they did not really understand what was going on. This made it difficult to assign work appropriately and for them to complete the work appropriately.

Overall the project has been affective in making me realise that the first design that is created may not be necessarily the right one and that there will always be improvements that can be made. If also showed me that while it is easy to design a barebones system to incorporate functionality, to actually incorporate quality attributes is another level in itself.

I am glad I have done this project as it has put the subject matter into context and enabled me to learn and explore the concepts.

Karan Jain

This subject has created awareness about the importance of architecture. 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. 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.

Having completed this assignment I will personally use Java or Eclipse for any future development and 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.

My main contribution was setting up the database and linking the classes to database. At first this proved to be very difficult as I had no experience in either MYSQL or techniques required to complete the job. I spent many late nights trying to code the task. Once it was all setup we decided to change to XAMPP from MYSQL, which was file but meant that connectors needed to be changed. Overall the task was a great initiative and included plenty of challenges for me. I am happy to have overcome those challenges and deliver.

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. However there was this pre-conceived idea that if members were not at lab, they didn’t seem to have contributed as much as members who were in labs but might not have worked on software architecture. The idea was to get the allocated task done. I would have appreciated if some of the group members communicated adequately to keep everyone in loop.

Due to unfortunate circumstances I had to leave for 3 weeks and missed milestone. For which I received no marks, but it was hard to change some group member’s thinking. They still thought I didn’t pull enough work and was left in dark many times to figure things out on my own. . However, on my return I did almost everything to get back to speed with the project and volunteered to do the database integration. I felt, working on database and integration will provide me with thorough understanding and nitty gritty of the project, which it very well did!

Overall it was a good experience and I did learn a lot about the java and eclipse, I do feel that I or we should have spent more time concentrating on the architecture as it was the subject that we were working on. But none the less good experience.

Lloyd Rangiah

My journey through this subject, has been and interesting one. When the semester first began my knowledge on the concept of architecture was limited. I had always thought to myself: Why do we need to worry about architectures, design and documentation. Why not simply start coding the system, and use ad-hoc methods to fix any issues that arose throughout the due course of the project? These questions were answered for me throughout this course, and I am extremely glad they were. I now understand the importance of a sound design, solid architecture, and a consistent data model.

Throughout the tutorials, we initiated the construction of our architecture by creating usage narratives related to specific stakeholders. This enabled us to understand the needs of the system, and how the system should react in different situations. Once we had outlined the different stakeholders concerned with the system and their usage needs, as a group we decided which non-functional qualities our system would incorporate. The decision was to focus on performance, reliability, availability and concurrency. This meant that the architecture would need to be one which ensured network traffic did not affect the performance of the system (connection saturation).

Once this stage was complete, we were ready to begin the construction of our systems architecture. I proposed a 3-tier architecture model, which would ensure that data is managed efficiently throughout the system. A 2-tier architectural model would become saturated very quickly once multiple clients joined the network. With a 3-tier architectural model, the business logic layer is responsible for making all the decisions, and only the Socket Client was responsible for making the connection to the server. Once the data is sent across the server, the Connection Handler on the server side will decrypt the data packet (in the form of a string), and perform a meaningful task. Since one connection would be made to the server only, it ensured that the server was not overloaded with connections, and system performance would not decrease dramatically under heavy load.

The development of the prototype proved to be the trickiest part of the Software Architecture course for me personally. This was because prior to undertaking this subject, I had only ever written programs using an ad-hoc approach. Developing a software application by following a design and architecture meant the system needed to be developed within the constraints of the architecture. However, once implementation began, I soon realised that our architecture needed adjustments made to it, as there were certain things we did not cater for. The distance calculation between the emergency and vehicle was initially meant to be calculated by the ‘vehicle calculations’ module. However, when developing the system, we soon realised we did not have the available time to implement a coordinate system for each vehicle and emergency. Due to these time constraints, we opted to simply assign the first vehicle available in the database from a particular suburb. Once this vehicle was assigned, the status of the vehicle would be marked as ‘unavailable’, which ensured the vehicle cannot be allocated again whilst currently attending to an emergency. This was a simple way to implement the dispatching system; however it did work effectively, and follow our particular architecture.

Moreover, once the system was developed, there were certain things we did no take into consideration which were brought up in the prototype demonstration. One of the main points we did not consider, was the design of the user interface. Our administration interface prevented managers from entering the dispatch view, where vehicles could be dispatched. This was primarily because our authentication module, retrieved a user’s role from the database, and routed them to the appropriate screen. What this meant was that a manager would never be routed to the Emergency Response View, in case they wanted to dispatch a vehicle.

To counter, this, we should have implemented a cascaded user interface. By this, I refer an interface that implements tabbing or buttons, where managers are given access to multiple screens which can be accessed through particular tabs or buttons. This would allow managers to perform the normal tasks which dispatch operators perform daily, as well as additional management tasks that only they have access to.

The major design point through the project development, was deciding on which architectural model to follow. I believe we made the right choice by choosing a 3-tier architectural model, as it certainly ensured we implemented the non-functional qualities of our system. Reliability and performance were covered purely by designing a system which utilised the 3-tier model. Furthermore, the decision to not implement the manual assignment of vehicles proved to be a key decision in the development of the project. If we opted to implement this into the system, the system may have only been partially finished by the time of the demonstration. By removing this component from the model, we were able to develop a system which followed our architecture closely, and operated efficiently and reliably.

On the other hand, we had our fair share of problems throughout the semester with particular group members. One member of the group was not present for the whole first milestone, which left the team with an excessive workload, and effectively behind schedule. Once this member returned, there was minimal contribution from them, and it was merely the remaining four group members from the first milestone who worked tirelessly to get work complete. Even though we had issues within the group, the remaining members were able to work together in an effective manner, to ensure the executable prototype was complete. It was a great overall effort from the remaining four team members, and we are pleased with the final outcome of the system. I am pleased that I can honestly say I contributed highly to the development and design of the system, and worked effectively as a team player to ensure the team stayed on track and completed all tasks by the due date.

David Truong

I truly believe this is how a subject should be run in terms of learning new material. This subject follows on the same format as Object Oriented Design where students use a Wiki throughout the semester to show their progress for each milestone.

For our first milestone, one of our team members was absent for the majority of the project. This meant that there was an increased workload for the rest of the team. However, this extra work was beneficial in terms of learning new concepts relating to software architecture. The approach to creating an architecture is very structured, and allowed me to follow the steps required to illicit requirements and gather scope on what the system was about. I was never a fan of design, and would simply jump head first into coding the solution to the problem. The activities and tutorials held throughout the semester was very helpful, and allowed me to understand how valuable narratives are when it comes to understanding what the system required, before coding.

When it came to designing the architecture, I came up with several versions for our system. This provided me a way to gauge my understanding of the system. The use case map analysis allowed me to see the deficiencies of the system, which led me to changing the architecture. Use case map analysis was performed until there weren’t anymore problems with the architecture.

In terms of what I learnt in coding the prototype of our system, I had to learn JAVA. My previous attempts at JAVA have been at the very basic level. Since I was required to use JAVA in another course (ICT Design), learning JAVA was a requirement to develop the prototype. I now have a general understanding of OO concepts in JAVA, and the efficiency in some of the functions that the language can achieve compared to other languages. The first milestone also exposed me to what JAVA sockets and threaded severs are, and how this all links with the database.

For the second milestone, I was given the task of re-evaluating the execution architecture. Using use case maps analysis, I immediately found some conflicting issues. One issue was that our system needed to be secure and have performance qualities. We had a module called “Logic Authentication” which had two functions going through. One was “AuthenticateUser”, the other was “SendERScreen”. The “AuthenticateUser” had to be secure, while the “SendERScreen” had to have very good performance, since it would mean the difference between life and death in a dispatch system. What we had to do was to split the module up so that each module could concentrate on a particular system quality.

Overall, I found the subject enjoyable. I have learnt several techniques and tools which will enable me to use in my software engineering degree. The only thing I did not enjoy was the teamwork. Teamwork is hard, difficult, unenjoyable when a team member doesnt participate to help out.

David Young

During the course of this semester I have learnt a lot about system design from this subject. I have realised that system design is not always (or shall I say never) functionally orientated and there are other important factors that contribute to the design decisions of the system.

A system should have key quality attributes that it exhibits that are important to the functionality and these quality attributes will affect the system architecture and aid in the successful operation of the system.

We made the mistake of initially looking at the system as a functionally driven system only and this caused some big gaps in the finished system and flaws in its intended operation. Towards the end of development in vain we tried to incorporate concurrency and reliability however without taking these attributes into account from the very beginning they do simply look like a last minute add on and not fully integrated into the system.

So basically we initially overlooked the whole purpose of this architecture driven project and dove in head first into the functional requirements without consideration of the greater operation, sustainability and reliability of the system.

apart from some common first time architecture mistakes we also had the usual team work issues which were raised early, of members doing a lot more work than others. This is a common problem when groups start to get larger however this also means that a smaller group is left doing more than their fair share of work.

This was only the 2nd java subject for everyone in our group so we really struggled to get the prototypes up and running however we were quite happy with our final efforts given our programming experience and extra team workload.

I learnt a hell of a lot about java sockets, databases and java GUI’s by working through this project. I hadn’t worked so in depth with them before and am happy with my personal progress in the java language throughout this semester as I feel my skills have stepped up a level from the work I have put in and the mutual help between team members for the prototype.

We tried the technique of coding parts of the project separately at home using SVN however we ran into problems with people’s code needing too much work to implement together and also our SVN repository continually played up and would not let us commit anything. Hence we resorted to full team coding sessions in which we would all get together and code our respective parts and integrate on the spot. This made integration a lot easier and a lot more productive.

I feel that our software architecture document and prototypes while not being worthy of great status were a very good effort and once we realised the architectural mistakes we had made a good effort was put in to try and rectify our earlier mistakes. Along with being disadvantaged throughout the semester with extra workload I believe a genuine effort was put in throughout the semester by rest of the team.