Team 4: Gurgle Earth
From SoftwarePractice.org
Introduction
Gurgle Earth is a system designed to globally keep track of the Earth's diminishing resources in the year 2045. As resource consumption has left the Earth near breaking point, it has been established that there is a need to locate and pinpoint existing natural resources and keep track of their management and usage.
Document Overview
This document describes the architecture of the Gurgle Earth system. It has been divided into the following sections:
The overall system analysis is used to inform the development of a system architecture in the following sections. It includes things such as the system narrative, usage narratives and user personas, and quality narratives.
A domain level view of the system that summarises the key conceptual components that the proposed system should include.
A view of the system that attempts to identify high and low level runtime functions of the system that will be running simultaneously and to differentiate these functions as concurrent components that interact with each other.
A developer's perspective of the system that divides the system into its build time components to develop patterns for component reuse and show how third party frameworks and internal libraries are utilised by the various parts of the system. It also shows a runtime model of the system that gives us a perspective of how the system communicates outside and inside of itself.
A summary of some issues we expect engineers and developers to face in the subsequent milestones.
A critique of the Architectural Design, outlining the pros and cons of choosing this design, and the extent to which the executable prototype adheres to the design.
Comments
I'm (carmstrong) currently posting all my comments and rationale for doing things at discussion page. Not sure what other people want to do but I think here is fine.
Layers poster 20th May
Instructor comments
Good start. Regarding stakeholders and narratives, make sure you write short and snappy persona descriptions for each stakeholder. Give each persona a name. Make them come to life. The narratives written by Saurabh are good examples of this. Stakeholder narratives are not necessarily the same as "usage" narratives (as not all stakeholders will be "using" the system). Lian 12th March
"A conceptual architecture provides a view of the system that tries to encapusulate a user model or user perspective of the system." Be careful - the conceptual architecture addresses domain-level functionality, of which use-related functionality is one part. Good to see your initial conceptual architecture is up. Lian 26th March
Great analysis work so far. Just wondering about a couple of components... 1. The Image Comparator - what happens to the results of its automatic processing, do they get passed back to the user, alarmed, stored back into a persistent data component? 2. The Data Acquisition System - prefer not to use the term "system", subsystem if anything. One word of caution about lumping all the external data sources into this one component are that they may have very different needs - different forms of data, tranmission rates and protocols, security requirements, etc. It makes it easier to identify and analyse these differences if you split the component in some way. The use case maps may help answer some of these questions. Lian 2nd April
Milestone 1 Feedback
Excellent work. Very thoughtfully structured Wiki including evolution of design work. Here are some specific comments:
- Stakeholder and usage narratives are very well done. You have shown a high level of understanding, interpretation and probing of the problem domain and scope of the system.
- Good choice of quality attributes for this system. Interesting scenarios. Although the performance narratives are too solution-oriented, instead of prescribing desired requirements with related measures.
- CA: Great work. Nice separation of concerns and use of tiers.
- UCMs: Take care to label all the events on the trace, and the crossings of components. You have presented a reasonable set of UCMs with clear explanations, however the outcomes of using this technique are not stated. Did you make any changes as a result of these UCMs? Ah, I see the extensive work done in your history section. However, this particular example exposes a missing conection... with the AutomaticDataUpload event, there is no direct connection between Satellite and Databases. Also, the next diagram shows the Satellite data going to the Photography and Image Data component. Is there an inconsistency here? Or perhaps it just needs clearer explanation.
- Missing lifecycle events and UCMs
- EA: Excellent so far. Nice explanation of needs and solution through UCMs. I like the rationale for the choice of Application Server.
- IA: Good first cut. Have you considered any OTS servers? You may need to consider the constraints of the lab resources here.
