From SoftwarePractice.org

Main V1 ERS link : http://www.softwarepractice.org/wiki/V1_Emergency_Response_System

Contents 1 Architects 1.1 Alan Whitby 1.2 Avtar Singh Kohli 1.3 Daniel Fernandez 1.4 Henry Santosa 1.5 Michael Diponio 2 Regular Meetings 3 Responsibilities/Roles 4 Contribution Logs 5 Conflict Resolution Protocol 6 Availabilities 7 Presentation Order 8 Meeting Minutes 8.1 VJ comments discussed 16/10/08 8.2 TO DO LIST FOR M2 8.3 Duties Assigned in meeting Wednesday 3/09/08 8.4 Duties Assigned as discussed in tutorial Thursday 28/08/08 9 Links 10 Milestone 2 Requirements 10.1 Elaborated Architecture 10 marks 10.2 Executable Prototype 15 marks 10.3 Laboratory demonstration 10.4 Project presentation 5 marks 11 Initial Execution Architecture 11.1 Description 11.1.1 Client 11.1.2 Server

Architects

Alan Whitby

Avtar Singh Kohli

Fourth year ICT-Software Engineering + Business Student. Interested in: Learning Design features for Simple applications which are open source & processor friendly. Currently, researching a merger of Embedded, Real time and wireless sensor networks for a variety of Applications.

Daniel Fernandez

Fourth year Software Engineering student.

Henry Santosa

4th year software engineering student

Michael Diponio

Fourth year Software Engineering and Applied Physics student. Currently working as the Remote Labs administrator and as a research assistant for a RTA project involving license plate recognition and vehicle classification.

Regular Meetings

Thursday 7pm to 9pm

Responsibilities/Roles

Contribution Logs

http://tectra.it.uts.edu.au/tectra/ A penalty exists @ 0.5 marks per week for non-Entry as mentioned in the Assignment Overview & Conduct Document

Conflict Resolution Protocol

Un-diserable /unexpected conflicts sources:

1. Non-contribution by team member
2. Conflict on design issues
3. Choosing development environment and Database
4. Quality of input and delays
5. Disagreement on component attributes

Resolution Steps:

1. Talk the issue out, if successful then continue working as normal
2. Other wise a vote happens and following are reffered to
3. Consult the subject guide - avoiding ambiguity
4. Consult with tutor for clarification
5. If above four steps fail then Consult with the Lecturer for further clarification

Availabilities

	Monday	Tuesday	Wednesday	Thursday	Friday	Saturday	Sunday
Alan		9 - 12	12-3	3-6
Avtar	9-6	9-6	9-6		9-6	9-1130AM
Daniel	--	--	--	12-2	--
Henry	9-11 & 2-6	9-12	1-6	9-12 & 3-6	9-6
Michael	9-1 & 3-6	9-3	1-6	9-1.30 & 3-6	9-1

Presentation Order

Key features / Issues - Henry
Stakeholders - Alan
Quality Attributes - Alan
Contextual Factors - Daniel
Conceptual Architecture - Henry
Use Case maps - Avtar
Execution - Michael
Implementation - Michael
Conclusion - Daniel

Meeting Minutes

VJ comments discussed 16/10/08

1. We need a Data model[information being exchanged between components & included processes & transformation of information & how it gets transferred]
2. on Quality attributes : emphasis on performance[on speed of transfer/ how many responder can be taken n so on ]..improve narrative quality
3. Scenarios need to be more concrete and act as benchmarks
4. on responsibilities[of the components] need more details ..[instead of just saying component A talks to components B]
5. Implementation view - move them around and box em

TO DO LIST FOR M2

1. Execution Architecture includes : Behavioral analysis , concurrency views & Deployment views
2. Reason for choice of components for implementation
3. Critique for whole architecture
4. in code Authentication

Duties Assigned in meeting Wednesday 3/09/08

Michal

1. code the connections
2. write the responsibilities of components
3. review the Conceptual Architecture

Alan

1. code the ERC GUI in html
2. 2 key quality narratives
3. draw use case maps/ impact maps on the conceptual Architecture

Avtar

1. Write the responsibilities of components in the Architectural view
2. code the Responder Gui
3. Write meeting minutes and update on tasks

Henry

1. Draw a final version of the conceptual architecture
2. Use case maps based on quality narratives
3. code the Database

Daniel

1. Draw some use case maps based on narratives [Append new- don't delete]
2. Do narratives : usability & scalability
3. Do the data models,runtime and life cycle events discussion for the Conceptual Architecture

Things to Remember:

1. Presentation is worth 10 marks
2. we still have to draw a Implementation Architecture
3. we would be checked[Lab-demo] on our ability to use SVN-repository and Eclipse(Please familiarize)

Duties Assigned as discussed in tutorial Thursday 28/08/08

Michal

1. Improve Overview of the System
2. Narratives: Reusability, Maintainability
3. Identification of Key contextual factors

Alan

1. Priortise the quality attributes and pick 2 key ones(suggestion Performance/reliability) (Completed)
2. Improve Quality Narratives and do usability,performance (Performance Completed)
3. Review the contextual Architecture

Avtar

1. Revise the Contextual Architecture
2. Narratives : Testability, Scalability
3. Write meeting minutes and update on tasks

Henry

1. Describe the issues on anticipated issues for following milestones
2. Use case maps based on quality narratives
3. Do narratives : Security, Configurability

Daniel

1. Stakeholdlers needs & expectations, captured in personas and narratives
2. Do narratives : Reliability and Scalability
3. check the Requirements with our progress and update milestone section for specific dates (Request)

Things to Remember:

1. Be specific with the Narrative descriptions should not be vague or generic. Should be in conformance with Requirements/textbook/lecture notes..etc.
2. Give/Specify sensible/meaningful/descriptive names which respresent a component or a feature or specific part of the system/sub-system. for e.g. instead of persistance, use HeadQuater Database.; we are using routing system not miracle system ...
3. Presentation of milestone 1 is due on September 11 and a printed version is to be submitted which should represent effort by 5 professional engineers
4. Maintain your individual Logbook as a evidence of effort and record peer rating in TECTRA to avoid 0.5 marks penelty per week

The Above discussed sections are expected to be in final shape before tuesday for further diagrams/prototype development

---

Inline Attachment Follows-----

DELETE it after you have got the narrative right

1. George has an car accident
2. George calls 000
3. George gets routed to an operator
4. George gives his location (22 blah st) to the operator, Nat
5. Nat enters the emergency code (23-hit n run) and georges locatiojn into the system
6. The system takes the address, finds all availble units and offers then to Nat
7. Nat selects a unit and tells the system to dispatch the unit
8. the Dispatch request is sent by the system to the unit
9. the unit (ambo) receives the request on their vehicle console
10. Unit confirms request and sends unit back to HQ
11. HQ logs the dispatch call along with the unit details
12. HQ System removes the dispatch request from the system

Performance Usage Scenario

1. george has an accident, went pants
2. george calls 000 at 8pm
3. routed to op
4. op takes location and emergency code
5. op enters the code and location
6. system offers units within 2 seconds
7. op picks unit
8. request is created, logged and dispatched within 10 seconds
9. unit receives request and must respond with

Reliability Scenarios

• Unit doesn't respond to dispatch request
• Not enough operators
• No available units

Links

odvLab: https://odvlab.eng.uts.edu.au/odvlab2/default/authentication/login

SVN https://swordfish.eng.uts.edu.au/projects/sa08spr_v1/svn/

Milestone 2 Requirements

Milestone 2 (30 marks) This is the final milestone, in which you deliver, at the end of the Elaboration phase, a completed Software Architecture Document and Executable Prototype. The main focus of this milestone is to design, explore and validate the execution architecture.

Elaborated Architecture 10 marks

This is the written component for this milestone. In this iteration, you are expected to have completed the execution and implementation architectures, and revised or refined the conceptual architecture and any other relevant artefacts. Specifically, you will have:

1. A complete execution architecture section. You must have at least a process view or concurrent subsystems view, and a deployment view based on it. You will also show, using use-case maps from key events, that the execution architecture is feasible and does not have any inherent performance problems.
2. A complete implementation architecture section. You will explain the structure of the implementation architecture, and provide analysis explaining your choice of off-theshelf and custom-built components.
3. Brief notes on anticipated issues for the remainder of the project.

In this milestone, you are to revise and complete the architectural design, especially in light of any prototypes you have built along the way. Please refer back to the overview of the Software Architecture Document to ensure you have not missed any elements.

Now that you have produced an Executable Prototype, include a one- to two-page critique of your architectural design. Discuss the areas in which your design was strong or weak, and how the prototype served to illuminate various aspects of the design. You may use diagrams to support your claims. You will need to justify all architectural decisions that you have made during the analysis and design. Make sure that the items and diagrams are supported with clear, explanatory text. Refer to the system context, stakeholder input, and so on, as part of your justification. 7

Executable Prototype 15 marks

This is the programming component for this milestone. You must deliver the following to meet this milestone:

1) A running system that contains the key elements of your execution architecture.

2) A user interface (non web-based) that allows exercise of key runtime events.

3) A web interface that provides the key user functions available over the web.

4) The structure of the prototype must match the execution and implementation architectures. That is, it must:

a) Use at least some of the technologies identified in the implementation architecture, and

b) Have the same concurrent subsystems as the execution architecture design.

(If your design has 18 concurrent subsystems, then so must your program. This is a powerful incentive to make your design no more complex than necessary.) For the purposes of this subject, a concurrent subsystem is a process started by a shell script; a process is started either by a shell script, by using an exec call, or by the Java Process class; a thread is a Java thread. In addition, for this milestone you need to solidify your development structure. Specifically:

1. Modify your program to use Java packages.

2. Modify the provided ant script to compile your program (if it does not already)

3. Modify the provided start-up shell script to start all of your concurrent subsystems.

Laboratory demonstration

Each team will demonstrate a working executable prototype in the lab. Each member of the team will be asked to explain the mapping between their architectural design and the executable prototype. Any student unable to do this, will be liable to receive zero for the programming component of this milestone.

Project presentation 5 marks

Each team will present to the whole class their final architectural design for this milestone. You will have 10 minutes to succinctly describe the key features and issues of your architecture, with thoughtful reference to stakeholders, contextual factors and quality attributes. You should present the three architectural views and briefly discuss how the building of the executable prototype provided insights into your architectural design.

The powerpoint presentation should include:

  1. A brief intro to your system
  2. Quality attributes and quality narratives (measurable, specific)
  3. Key architectural issues and constraints
  4. Conceptual architecture view - diagram of related components
  5. Execution architecture view - process, deployment and use-case maps.
  6. Implementation architecture view
  7. Discussion of how your architectural design decisions support your quality attributes.
  8. Any application of architectural styles/patterns (if applicable)

Peer assessment will be conducted of each team’s presentation. The assessment that each group does will, itself, be marked and will be an explicit part of the assessment criteria for each team’s total project mark.

Individual reflection Deliver an individual reflection on this project. You should describe what you learnt, and how, during the conduct of the project. In particular, focus on the overall process of creating the Software Architecture Document and the Executable Prototype. What worked or did not work, in terms of design process, techniques and teamwork? What were the major decision points during the project development? How did these impact on the resulting design? The reflection should be one to two pages (no more) in length and submitted on the Wiki, together with the Software Architecture Document.

Initial Execution Architecture

Saving this section of wiki, in case a revert is required

Description

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

Client

• Responder GUI - The Responder GUI is the graphical interface for the Responder.
• Status Messenger - This is an active component that updates the emergency service center server with the location, status and identity information of the responder at a set interval.
• Dispatch Listener - This is an active component that listens to requests from for the responder to be routed to an emergency. There are multiple instances of the dispatch listener to allow multiple requests to be interpreted and queued before a request is accepted.
• Responder identity - This is a service component which finds the identity of the responder when requested. The identity is defined as a value allowing to address the client program to send requests, therefore it is an IP address and a port in this system.
• Location Determination - This is a service component which finds the responder current physical location when requested.

Server

• Operator GUI - this component displays an interface for emergency calls to be serviced, thus it is a user-initiated component. There are multiple operator GUI instances to allow multiple operators to use the system. Interaction with the system is through a callback, where the operator GUI requests a service from another component and waits for the response (this may map to the AJAX pattern in implementation).
• Response unit details - this is a singular component containing a data store of all the response unit details. The details include their current location, status and how they can be addressed by the system (e.g. IP, port). This component is a service component, allowing asynchronous requests from using components for a responders detailed to be created, read, updated or deleted to be serviced. The current architecture defines this as a single component which may affect the scalability quality attribute, since they system is singular to one emergency service center (ESC). This means there is no hand-off mechanism to allow a responder to be reallocated to a different ESC if they stray to that ESCs region.
• Status listener - this is an active component which listens for updates of responder clients status and location. The details of the update are send to the responder unit details component to persistently store. There are multiple concurrent instances of this component to allow multiple responder clients to update their location and statuses.
• Dispatcher - this is an active component which sends the route request to a responder client and waits for confirmation. There are multiple instances of this component to service multiple emergency call requests.
• Routing system - this is a service component which finds a route between a start point and an end point (pre-existing component).
• Callout log - this is a data store service component allow all the details from an emergency call to be logged. The details include the nature of the emergency and which unit was routed to the emergency and allow a report to be collated of the usage of the ESC and the movements of response units.
• Reporter Generator - this is an active component that generates reports from the callout log and response unit details.
• Report GUI - this component displays an interface for a privileged user to view system reports as generated by the reporter component. It is user-initiated and can have multiple concurrent instances to allow multiple users to view reports.