TEAM 1 - GURGLE EARTH

From SoftwarePractice.org

Team 1 - Gurgle Earth

Contents 1 Team Members 2 System Overview 2.1 Introduction 2.2 Document Purpose 2.3 System Scope 2.4 Assumptions 3 Work Plan 4 Stakeholders 4.1 Stakeholder Narratives 4.1.1 Population 4.1.2 Wildlife 4.1.3 Fly-over aircraft producers 4.1.4 Recycling companies 4.1.5 Ecologists 4.1.6 Technologists 4.1.7 Regional Scientists 4.1.8 Government 4.1.9 Oil Companies 4.1.10 Business Regulators 4.1.11 Companies 4.1.12 Garbage Collectors 4.1.13 Wireless Sensor Producers 4.1.14 Investors 4.1.15 Management 4.2 Usage Narratives 4.2.1 Company 4.2.2 Policy Makers 4.2.3 General Public 4.2.4 Scientists 5 System Context 5.1 Contextual Factors 5.2 Quality Attributes / Narratives 5.2.1 Data Integrity 5.2.1.1 Quality Narratives 5.2.2 Security 5.2.2.1 Quality Narratives 5.2.3 Usability 5.2.3.1 Quality Narratives 6 Conceptual Architecture 6.1 Initial Conceptual Architecture 6.1.1 Key Concepts 6.1.2 Initial Conceptual Architecture Components 6.1.3 Initial Conceptual Architecture Diagram 6.2 Elaborated Conceptual Architecture 6.2.1 Components Diagram 6.2.2 General Description 6.2.3 Component Responsibilities 6.2.4 Data Models 6.2.5 Use Case Maps 6.2.5.1 Scientists/Ecologists (Priority 1 Users) 6.2.5.2 Policy Makers/Government bodies (priority 2 users) 6.2.5.3 General Public (priority 3 users) 7 Execution Architecture 7.1 Initial Execution Architecture 7.1.1 Initial Execution Architecture Diagram 7.1.2 General Description 7.2 Elaborated Execution Architecture 7.2.1 Elaborated Execution Architecture Diagram 7.2.2 General Description 7.2.3 Identification of Concurrent Components 7.2.4 Use Case Maps 7.2.5 Deployment 7.3 Ongoing contextual factors 8 Implementation Architecture 8.1 Implementation Architecture Diagram 9 Considerations for future Milestones 10 Brief Description of Prototype 11 Critique 12 References 13 Instructor comments

Team Members

Name	Student Number
Hillary Guillaumin	10526820
Mahati Prabhala	02035727
Samyukta Menon	02058030
Leonard Hong	10171054

Follow the link for the summary of our meetings

Layers poster 20th May

System Overview

Introduction

Leading world powers have expressed an urgency in creating a global solution to eradicating the depletion of the world’s natural resources, after scientists have warned that the earth is ‘on the verge of a complete ecological collapse’. In order to find a solution, a tracking system is required to track the consumption, production and location of resources.

The Gurgle Earth Tracking System consists of a range of interactions with hardware (fly-over aircrafts, wireless sensors and satellites) with specified databases and human interfaces.

Document Purpose

This is the Software Architecture document for the Gurgle Earth tracking system. It aims to present the system in three major architectural forms: Conceptual architecture, execution architecture and implementation architecture. Furthermore, it identifies key stakeholders of the system, in aiding with the design of a concise, user-specific model, ideal for the implantation of the system.

System Scope

We - a group of software Architects and Developers are required to develop a system that allows the monitoring of resources on the planet. It is necessary that the system tracks not only present quantities of such resources, but also their ongoing production and consumption. Furthermore, the location of such resources must be detected and mapped out.

Although attempts will be made to collect data from the government and companies on their resource usage, accuracy will be maintained by collecting such data via fly-over aircraft, ‘smart dust’ wireless sensors and satellite imagery.

The Gurgle Earth Tracking system must track the consumption, production and location of the following resources: classes of ecosystems, every species of plant and animal, regardless of whether it is directly used in food or other production, water and soil quality, remaining oil reserves, as well as other minerals, and waste management.

Assumptions

• The wireless technology and the aerospace technology is being handled by the external producers of such hardware. Security and other non-functional requirements for that system will be handled by external embedded system developers.
• The other systems provide the data in a way that is readable by our system. The format will be specified to the embedded system developers as mentioned before.
• The system is basically a monitoring system. While its ultimate aim is to be used to increase general public awareness of the environment the monitoring system does not cater especially for the general purblic. This is because the data that is being collected will be complex and the policy makers would not want people to make un-intelligent analysis.
• There is a resource constraint in terms of time, but there is not a stringent limit on the cost of the system as it is being sponsored by governments who want this information to be as accurate as possible.
• This system is operating in a semi-ideal world where all the governments of the most countries are willing to cooperate.
• If the information is not readily available and given to the scientists / ecologists etc then this special organisation (something like the UNEP in our world) has the power to collect information by themselves.
• All the scientists form a collaborative network through the special organisation and are able to communicate with each other through other systems and mechanisms which are separate from Gurgle Earth. For example, the reports generated by the system itself will have limited content. It is up to the individual scientist to then write up a report which forms the analysis and explanation for the result reports and post it up on the inernet.

Work Plan

The Following table outlines the timeline that we aim to adhere to through the deployment of milestone 1.

Sections	Date of completion	Done
An overview of the system	5th March 2007	Yes
Stakeholder needs and expectations, captured in personas and narratives	12th March	Yes
Identification and discussion of key contextual factors	12th March 2007	Yes
Usage narratives for the various kinds of users of the system	12th March 2007	Yes
Quality narratives for TWO key quality attributes that we have chosen as most relevant for the system	12th March 2007	Yes
An initial conceptual architecture	25th March 2007	Yes
An elaborated conceptual architecture	1st April 2007	Yes
An initial execution architecture	8th April 2007	Yes
An initial implementation architecture	15th April 2007	Yes
Brief notes on anticipated issues for following milestones	15th April 2007	Yes
A user defined interface that contains buttons to simulate key runtime events identified in your architecture analysis	Design: 9th April – 13th April 2007 Code: 13th April - 20th April 2007	Yes
A service that listens for requests from the user interface process and returns a response to each	Design: 9th April – 13th April 2007 Code: 13th April - 20th April 2007	Yes

The Following table outlines the timeline that we aim to adhere to through the deployment of milestone 2.

Sections	Date of completion	Done
Complete accurate list of stakeholders and priorities	27th April 2007	Yes
Accurate stakeholder narratives	30th April 2007	Yes
Updated final conceptual architecture, including use-case maps	5th May 2007	Yes
Updated final execution architecture, including use case maps	12th May 2007	Yes
Deployment for execution architecture	15th May 2007	Yes
Complete list of Quality attributes and their related scenarios	20th May 2007	Yes
Updated final implementation architecture, including an analysis on off-the-shelf and custom-built components employed	23rd May 2007	Yes
Data View Development	Design: 5th May – 15th May 2007, Code: 16th May – 24th may 2007	Yes
Report View Development	Design: 5th May – 15th May 2007, Code: 16th May – 24th May 2007	Yes
Data Analysis View	Design: 5th May – 15th May 2007, Code: 16th May – 24th May 2007	Yes
Implementation	25th May – 29th May 2007	Yes
Critique	1st June 2007	Yes
Assignment tweaking and review	1st June – 3rd June 2007	Yes

Stakeholders

The following table contains the stakeholders we identified for the system. It is from this initial list that we were able to produce the narratives that follow. They are listed and then discussed in terms of their needs of the system. Every stakeholder has their own needs, and there is a probability that their particular needs conflict. Prioritising the stakeholders (as described below) offers a clear view of what needs the Gurgle Earth system will be primarily catering for.

Stakeholder	Priority
Scientists	1
Population	3
Policy makers	2
Technologists	4
Architects	4
Wildlife	4
Companies (to supply consumption patterns)	3
Government (Local and State)	2
Fly-over aircraft producers	4
Wireless sensor producers	4
Recycling companies	4
Garbage collectors	4
Business regulators	4
Ecologists	1
Oil Companies	3
Investors	4
Management	4

• Priority 1: This group consists of authorised users of the system who can access any part of the system. They are the only group that is able to use data captured by Gurlge Earth to not only develop reports, but also upload them onto the system. These individuals or groups are not only able to develop reports, but also graphs. They are able to view maps as well as raw data in tabular format.

• Priority 2: Includes the people that can access the system's reports, through a systems interface and is also permitted access to raw data through the Data view. They are able to use this data to generate graphs, as well as view maps locating resources. They are also able to generate reports, however these reports will not be made publicly available

• Priority 3: People who have limited access to the system. These groups interact with the system via a web interface. They are only premitted to access pre-generated reports by downloading them onto their personal computers.

• Priority 4: Refers to the stakeholders who are indirectly affected by the system, either by the data generated or by the technology used by the system. They are not immediate users of the system.

Stakeholder Narratives

The following section contains some narratives for stakeholders that were identified.

Population

Persona: Paula is the owner of Greengate, a famous tourist garden in the Mount Irvine region.

Stakeholder Narratve: As they prepare for this year’s autumn chestnut season, the residents of the Mount Irvine area are concerned about the water and soil quality of the region, due to the fact that their plantations are visited by many tourists, specially from March to April. They need to be prepared to provided fresh, quality products through the local restaurants and tasting facilities. Paula is interested in accessing the periodically updated water and soil quality reports for the sake of her plantations.

Wildlife

Persona: Julie is a zoologist environmental officer with The Colong Foundation for Wilderness.

Stakeholder Narrative: Julie is concerned about the industrial wastes that have been increasing in the surrounding area of the Blue Mountains. Therefore, she’s interested in tracking data to minimise the effects of toxins to the exposed endangered and rare species of conservation significance that reside in the forests close to Katoomba. Julie is interested in viewing periodic information, in the form of reports on waste management data and how many toxins this waste is releasing into the environment.

Fly-over aircraft producers

Persona: Rene is a mechatronics engineering working for Sencon Environmental Services.

Stakeholder Narrative: Previous to the official release of Gurgle Planet, Rene has been doing some research about the latest technology used by its company, in order to develop a weather reconnaissance instrument that could economically monitor those huge areas of the southern hemisphere where direct weather observations are rare or nonexistent. Rene is interested in knowing the scope in which Gurgle Earth will be convering in its endeavour in creating this system, so that they may consider the use of some of Sencon's fly-over vehicles. Rene at Sencon does not have direct access to the system, and thus is not an end user of it.

Recycling companies

Persona: Ryan is the spokesperson of Corporate Recycling in Sydney.

Stakeholder Narrative: Ryan is interested in the project due to the nature of its company, which focuses on waste collection and recycling of cartridges, including the production of quality recycled plastic products made from printer cartridges and toner bottles that cannot be re-used. Therefore, he needs to have access to information which shows the consumption and disposal patterns, in order to be able to design an effective collection process. Ryan is interested in gaining access to reports which shows the consumption and disposal patterns in order to be ale to design an effective collection process.

Ecologists

Persona: Dr. Emily Evans of Oxford University is an expert ecologist of her time and is an advocate for the preservation of our environment and ecosystem.

Stakeholder Narrative: While Dr. Evans is an expert ecologist, it is the first time that she will be able to analyse ecological data that is pooled from the cooperation of countries from all over the world. She is excited to use the historical reports along with up-to date trend reports to form new predictions, projections and create knowledge that will help advocate her cause on a large scale.

Technologists

Persona: Dr. Terrance Turner - a technologist, has been working as an information technological consultant for various organisations for nearly four decades. His expertise and experience in realistically implementing the various solutions to technological problems.

Stakeholder Narrative: Terrance is excited but skeptical about the prospect of trying to get various technologists from various parts of the world to interact and produce information which can be analysed and used. He understands that there will be some significant developments in trying to get the various technologies to interact. He is interested in the technology used within the system and not so much on the data or the results produced by the system.

Regional Scientists

Persona: Sigmund is a scientists from the CSIRO, who shares research with most other scientists across the globe. This group of scientists have a shared concern about the complete ecological collapse of the earth. Sigmund works in the Sydney CSIRO laboratory, and is collaboratively conducting research on Australia's resources.

Stakeholder Narrative: Sigmund would like to view historical data, which backs up their claims and solidifies their concerns. Furthermore they will use current data to formulate theories on natural resource availability in order to aid in future decision making. Sigmund, along with his collegues have the knowledge base to use scientific reasoning and materialise scientific and mathematical equations that may be used to analyse raw data. Sigmund will use his expertise, aided by the system to produce accurate reports on a vast number of variables, which will be made accessible to the public.

Government

Persona: The Government of Australia which is representative of most of the western nation governments. (i.e. it is not a third world nation where the governments operate slightly differently and tend to have different objectives to better the nation and the world.

Stakeholder Narrative: The government would like to see the data and receive evidence so that appropriate amounts of funding can be given to the implementation of such a project. ( i.e. actually starting to reduce the levels of C02 levels but passing various laws as well as funding this software project that gathers information from all around the world). It would also like to decide whether it will be strategically a good move for the country.

Furthermore, the government has been requested to input all known and available consumption data into gurgle planet system, in order to aid with the analysis of the consumption patterns. Since government authorities are not authorised direct access to the system data, it must provide all data to a scientist whome the body will be allocated to liase with to input the data into the system on its behalf.

Thus the government would be interested in accessing all analysed data and reports produced by the system. It also requires a means through which raw data may be fed into the system. Once data has been fed into the system, it may not be retrieved. Government bodies are also able to produce reports for their own reference.

Oil Companies

Persona: Orlando Ali Khan is the CEO of an Oil company in Saudi Arabia. He has a lot of political influence and power and knows how to conduct business in that region.

Stakeholder Narrative: Mr. Khan is interested to know the environmental implications of the newly collected information on the impact of Oil rigging and oild leaks on the ocean creatures as well as the conserves of the Earth. He knows that if the new world wide policies are adopted this will impact his organisation's profits in the long run.

Furthermore, he is extremely interested in finding out where the last remaining oil reserves are located. Mr Kahn requires the oil consumption and reserve detection data, both of which will significantly impact future profits. However, for security reasons, Mr Khan is restricted to accessing oil consumption reports only.

Business Regulators

Persona: ASIC is an Australian regulator for businesses that ensures that there are no disadvantaged or superiorly advantaged parties doing business. It brings ot court any partties that do not follow the rules listed in the corporations Act 2001. (The corporations Act lists all the rules that business in Australia operate under including rules on mileading conduct.)

Stakeholder Narratives: If information about each of the remaining iol reserves are known only to some, they might have an unfair advantage in terms of shares and share prices. ASIC might hence want to ensure that such information is secure and not available to everyone or then ensure that everyone is on the same footing. ASIC is thus interested in the security of the system, rather than actually deriving data from the it, meaning that it is not a direct end user of the system.

Companies

Persona: Tina is an operations manager at Tintern rubber. Tintern uses rubber to produce tires along with other rubber based products.

Stakeholder Narrative: Tina has been requested to input all Tintern company data into gurgle planet system, in order to aid with the analysis of the consumption patterns. Tina only requires a means through which she may input data into the system. Once data has been fed into the system, it may not be retrieved. Since she is not authorised direct access to the system, Tina must provide her data to a scientist whome she will be allocated to liase with to input the data into the system on her behalf.

Garbage Collectors

Persona: Tom is a garbage man that works for the Tomarch Shire council. His job is to collect garbage from his designated municipality on certain days of the week. He is also involved in some of the planning with the council members that choose appropriate places for garbage disposal.

Stakeholder Narrative: Tom would like to find out whether there will be any changes in the way waste is collected and would also like to find out more about the dumping groud that they use and its environmental effects and also perhaps provide the scientists with information based on his experience.

Wireless Sensor Producers

Persona: Jimmy is a strapping young up-coming salesman working for Xtreme technology, a company that is renowned for its vast range of sensor products.

Stakeholder Narrative: Recently, Jimmy was approached by the management at Gurgle Earth and asked about Xtreme's development of wireless sensors. Xtreme staff, including Jimmy, are particularly interested in creating and providing such sensors for Gurlgle Earth. They have no need nor interest in the outputs of the system, and are thus not end users of the it.

Investors

Persona: Ian is a funds manager working for Instanza Investment Group.

Stakeholder Narrative: Ian is interested in the future prospects of the funds that he is currently managing and is heavily leaning towrads investment in the oil industry. If he were aware of the goings ons of oil companies, and their future scenarios of oil findings, it would significantly affect his returns and returns of his prestigious clients. Ian is thus interested in the location information of the remaining oil reserves so that assumptions may be made on the price of oil as well as the share price of oil companies. However, due to security requirements made by ASIC, investors are not entitled to access such information. Thus investors and the likes are not permitted to use the system.

Management

Persona: Morris is one of the managers overlooking Gurgle Earth

Stakeholder Narrative: The effective deployment and implementation of the system is of direct relevence to Morris. Although he is not interested in obtaining or making use of actual data produced by the system, he is very much concerned that the system functions as it was intended according to user requirements and appropriate quality attributes.

Usage Narratives

Company

Persona: Tina is the managing director of GardenWeb, a web based company that collects and displays information, data and images on plants and planting conditions in Australia. This also includes soil quality data which helps determine planting requirements given the Australian climate.

Usage Narrative: Apart from its own database, Tina is interested in navigating the Gurgle Earth system, for more accurate data sourcing. Tina locates the Gurgle Earth web site (having had prior knowledge about the Gurgle Earth tool) and locates a report titled ‘Plantation Soil Requirements, amongst all others that are available. She downloads the file and reads it before her 12pm meeting with her plantation management team.

Persona: Mitchell is the production manager at ‘CleanFresh’, a company which produces cleaning detergents for every part of the house. Frequently after a days production, CleanFresh has close to 10 litres of extra detergent that was not packaged and must be disposed of. Being an extremely environmentally friendly individual, Mitchell is concerned about the effects of such waste on the surrounding environment. The CleanFresh factory is located in a salt marsh region, in which many life-forms reside.

Usage Narrative: To obtain waste data, Mitchell locates the Gurgle Earth website and browses the file site and locates a report on the effects of waste on marshland environment, amongst all the ones available, and downloads it.

Policy Makers

Persona: John Campbell, Sirus’s Minister for Agriculture, fisheries and Forestry is considering the passing of a bill stating the ban of property development in the Moubry catchment area, as well as similar such catchments around the country, as it claims to be disruptive to the forest ecosystem.

Usage Narrative: In order to pass this bill as a law, Mr Campbell requires data solidifying his concerns. Mr Campbell accesses the Gurgle Earth program and logs onto the system using the user name and password provided to him. Mr Campbell selects the option to view ecosystem data in the region of North Ireland. He uses the data provided to produce a graph of the effects of fishing on the quality of plantation in the forest, amongst other graphs generated, to analyse and use these for his bill-passing purpose. Furthermore, for his own reference, or that of his collegues, Mr Campbell produces a report on his findings and saves it onto the server.

Persona: Rita Gotswalez, Minster for Environment and Water Resources in the country of Ghanis is concerned about the drought all over the country cause by the lack of rain.

Usage Narrative: The federal and state governments in Ghanis are working together to locate new catchment areas. Furthermore, Ms Gotswalez is considering tightening laws on water usage all over the country in order to curb water wastage. Ms Gotswalez logs onto the Gurgle Earth system located on her computer and logs onto it using her user name and password that she had created when she first used the system. She selects the option to view data and maps on water resource location in the South American region. Furthermore, she creates maps using dam level data spanning over the last 20 years. For her own reference, and that of her collegues, Ms Gotswalez produces a report on her findings and saves it onto the server.

General Public

Persona: Paula is the owner of Greengate, a famous tourist garden in the Mount Irvine region.

Usage Narrative: Paula accesses Gurgle Planet website as a recommendation from the local government as a starting point to improve her plantation quality. She is a Novice in using computers and so she just types in some key words in the search engine and water and soil quality data reports that were created by a professional scientist come up. She is happy to see these reports and predictions and can use that as a starting point to manage her garden.

Persona: Peter is a school student who is taking biology and environmental science for his Higher School Certificate.

Usage Narrative: Peter needs to analyse the ecosystem in his local area for which he needs information that has been collected about the local area from an expert. This will allow him to conduct a proper analysis. He was adviced by his teacher to use Gurgle planet. He finds the website and searches for reports about his area. He successfully finds some ecological data that was compiled about a year ago. Although this reported is dated back a year, the information is professionally compiled and provides him with very useful insights into the ecosystem which he could not have received by simply surfing the internet or by reading books.

Scientists

Persona: Dr. Emily Evans of Oxford University is an expert ecologist of her time and is an advocate for the preservation of our environment and ecosystem.

Usage Narrative1: Dr. Evans wants to compile the information for her area of expertise which is wildlife and ecology for the missippi region of the USA. She logs into the system and gets the appropriate data from the database based on what the sensors have gathered over the past 6 months. She generates a graph that compares the the wildlife increase/decrease of the area and compares it to the amount of waste that is thrown into the river.

Usage Narrative 2: Dr. Evans now has to submit a report on the ecological health of the Asian Pacific region. She loggs into the system where she is able to access all the reports. She then takes the reports generated by the scientists in that region so that she is able to colate all that information and prepare a generalised report and present it to the policy makers.

Persona: Sigmund is a scientists from the CSIRO, who shares research with most other scientists across the globe. This group of scientists have a shared concern about the complete ecological collapse of the earth. Sigmund works in the Sydney CSIRO laboratory, and is collaboratively conducting research on Australia's resources.

Usage Narrative: The team of scientists collect information from different regions of Australia based on ecology or soil despositon or water levels (depending on what is necessary). The team then individually produce graphs based on their expertise. Sigmund then collects these individual reports to generate one for Australia as a whole so that the information can be easily collaborated with other countries.

Usage Narrative 2: A new soil type has been tracked by one of the sensors, and Sigmund is worried that this new emergence may have detrimental effects on the ecosystem in which it is located. Sigmund carries out background research on materials with similar properties and comes up with a mathematical formula with regards to soil granularity and how it may impact plantation. For future reference, Sigmund inputs his hypothesises equation into the analysis engine.

System Context

Contextual Factors

This section deals with several factors that have an effect on the design and construction of the computer system. Those factors include constraints, enablers and risks of the project.

• The availability of fly-over aircrafts, wireless sensors and satellite images is an enabler, since these external devices provide the information needed to analyse the resources located in a specific area. However, it’s also a constraint given that we’re relying on the quality and performance of these devices to perform our data analysis.
• The incompatibility of data received from satellite could represent a risk, given that our system relies on the fact that data would be presented in an understandable format to be classified.
• The need to maintain stored information about each classification of data (such as water and soil, ecosystem, plant and animal, and so on) is a risk, given that the system is dependent on a single source of storage to retrieve and update the current data. However, these specialized data storage is an enabler, given that it allows quicker access to a specific type of information.
• The main focus, as well as the main risk our system faces is that of security. Thus as prototypes are tweaked and as milestones build up to the final deliverable, we must ensure that proper secutiry measures are in place. There exists a major risk of security threats to the system in the form of denial of system services by overloading the system with dummy data or the entry of corrupt data which can be detrimental to the functioning of the system.

Criticality

• The project has a medium level of criticality, since the information provided by the system is used for analysis of current consumption and existence of resources. A system failure might delay the response of the stakeholder in making a decision, and some money or resources could be lost in the process. For example, the system is used by policy makers whose decisions have to be adequate and precise, in order to avoid further political problems.

Quality Attributes / Narratives

Data Integrity

Wikipedia gives three main definitions of the definition of data integrity, all of which are seen as extremely relevant to our system. 1. We need to ensure that the data is ‘whole’ or complete in order to be able to accurately draw conclusions 2. Data should be identically maintained during any sort of operation, the Gurgle Earth system, this would mean during storage and retrieval 3. Data should meet expectations of data quality i.e. "if they are fit for their intended uses in operations, decision making and planning" Data integrity works alongside with data security (as mentioned above) in that data integrity can be largely maintained through authorisation mechanisms for accessing the system. This ensures the preservation of data.

The system is designed in a way so that it does not allow the user to configure and change any of the values that are being stored. The data that enters the system is automatically filtered and deposited into the various databases from which information can be obtained but not changed. Hence, by reducing the amount of interaction between the user and the raw data, the data integrity is maintained. Within the database, add and delete rules will be used so that it prevents loss of data or corruption of data due to simultaneous access.

Quality Narratives

Rita Gotswalez, Minster for Environment and Water Resources in the country of Ghanis is concerned about the drought all over the country cause by the lack of rain. She thus requires accurate information collected by the external devices on water levels in all regions of Ghanis. She expects that all possible data is collected, and accurately so, and that no data is lost or corrupt as she attempts to retrieve it, or as it is stored in the water and soil quality database. The precision of data that Ms Gotswalez obtains is integral to the decisions that she is able to make regarding the passing of federal law.

Mitchell is the production manager at ‘CleanFresh’, a company which produces cleaning detergents for every part of the house. Since there is waste every day after production and packaging, Mitchell is concerned about the affects that this may have on the surrounding environment. Accurate data will allow Mitchell to determine precisely how his company’s waste is damaging the salt marsh region surrounding the factory. In order for Sigmund, an ecologist at the CSIRO, to be able to produce a report concerning the affects of certain chemicals into particular ecosystems, he must have access to all possible data concerning plants, animals and ecosystems. All data must be captured during transfer from the external devices into the system. Inaccurate data will lead to Sigmund making erroneous assumptions and thus producing imprecise reports. This can lead to disastrous decisions to be made by Mitchell, thus disrupting an entire life cycle network surrounding his factory area.

Security

Security for this system is a top priority and its intended purpose is described below. One aspect of trying to integrate security for this system is to incorporate levels of access through a user authentication method. This system can be thought of as having 4 levels of access.

Top level access: Here people like the scientists (from all over the world) will be able use the system to its full extent. They are able to draw any information from the databases and use it to create new information - generate reports. In future iterations they might also be the only group who will be permitted to add data to the database. They are also able to control the information that is viewable with users with last level access.

Middle Level access: Where all information is available for them to view, but they are not able to generate any reports or create new information. The group who will get access to such information are the policy makers. While the policy makers are able to have a similar level of access to the system as the scientist, they are not able to save the graphs generated into the database nor are they able to upload reports into the file server. They use information generated by the system however, in order to be able to make policies.

Lower level access:' Here only some of the reports is available to view. These are generally the reports that the scientists have set the parameters for so that they can be viewed by the users.

Special Access:' This involves access to the various components of the system to keep the system running. This level of access is only granted to the technicians and will be used to maintain the databases in case of failure. They will however not be able to view any information that is contained within the data.

Quality Narratives

Sigmund the scientist is able to access information on all the current possible locations of oil fields, but ordinary people as well as companies are not able to access this information unless Sigmund sets it so that it is viewable to the public. The policy makers are able to view and create these reports but are not able save the reports into the database. This is because policy makers might not have the expertise to come up with reports that can be referenced as a source of information.

Dr. Terrance Turner, the technologist, will be called on if the system is experiencing technical difficulties and needs some extra features that need to be added.

The other aspect of security is the various network security levels set so that when the information is being transmitted over the distributed system. This is because the system involves the collaboration of scientists from all over the world.

Security Scenarios

Security Scenario 1

Security Scenario 2

Security Scenario 3

Usability

Looking at our stakeholders, we noticed that most of them are interested in business decisions, and aren't necessarily experts in technology issues. Therefore, we believe that our user interface should be user-friendly in order to allow our users (scientists, for example) to easily access the data collected from the system and generate reports that will aid them in analysing information and making decisions. Thus we consider usability as an integral quality attribute which we must focus on (obviously with less priority than data integrity or security) when building the system.

We are required to ensure that ‘the lower-level paraphernalia of the interface become second-nature to the user.’ (Reekie, McAdam, 2006, pg 121). Navigation through the Gurgle Earth system should not require the user to have to think about what to do or how to access something. Buttons, menus, option, mouse usage should all be explicit to an extent where the user, once familiar with and has learnt the use of, can carry on with the actual task which they wish to accomplish. John Reekie (2006) outlines that the developer should ensure that there is a rich graphical design with the appropriate use of colours and labels and positioning of buttons, all of which makes the user’s job that much easier.

In order to capture useability in our system, we used the paper prototyping method in which we constructed screen shots on paper before attempting to produce them. Since usability is a vast topic on its own, we have discredited the importance of such a quality attribute slightly. We have only looked at the very high level aspects of usability in this milestone, since we are only creating a prototype. The research and implementation of further usability issues may be an idea for further milestones leading to the absolute completion of the system.

Quality Narratives

As mentioned above, the scope of our usability has been restricted to that of using the system efficiently. The ideas of learning system features (with a help option) and minimising impact of errors (using mechanisms such as undo and cancel options, and password recovery), may be some thoughts for the following milestones.

John Campbell, introduced above is Sirus’s Minister for Agriculture, fisheries and Forestry and is considering the passing of a bill stating the ban of property development in the Moubry catchment area, as well as similar such catchments around the country, as it claims to be disruptive to the forest ecosystem. Mr Campbell requires an easy, efficient way of selecting the option to view ecosystem data in the region of Northern Ireland. He needs to be able to view this data as well as be able to choose which ecosystem properties he requires to produce graphs and reports. He has absolutely no time to waste on trying to learn the system and requires it to be as self explanatory as possible.

Peter is a school student who is taking biology and environmental science for his Higher School Certificate. Peter needs to analyse the ecosystem in his local area for which he needs information that has been collected about the local area from an expert. Although he is an avid net-surfer, he has to complete his assignment on time and thus wishes to be able to locate information as readily as possible. He is sick of web sites that forward him to 20 different sites before being able to locate information that he requires, and also those which have links in any which order all over the web page. He wants to be able to view all existing reports and select one instantaneously to complete his project.

Usability Scenario

Usability Scenario 1

[do a quality scenario for general public once we know what the webpage is going to look like]

Quality scenario poster

Conceptual Architecture

Initial Conceptual Architecture

Key Concepts

Through an initial brainstorm about the key functionalities of our system, and having gone through and underlined key concepts from the system narratives, we came up with the following initial conceptual architecture concepts.

Initial Conceptual Architecture Components

Initial Conceptual Architecture Diagram

Once the system narrative was examined and the key concepts were exerted and analysed, we came up with the following initial conceptual architecture.

Initial Conceptual Architecture

The initial conceptual architecture starts off with the satellites, fly-over aircrafts and ‘smart dust’ wireless sensors which have been deemed as external interfaces to the system. These nodes provide the system with real time data (as signified by the real-time stereotype).

The human interface component allows the user to input required data parameters and these parameters, along with the raw data, make up the required data component. This component is responsible for capturing raw data, and upon executing user ‘instructions’, outputs filtered search data.

The filtered search data is the dispersed according to data type into the six database components: Store waste data, Store plant data, Store animal data, Store water and soil data, Store oil and mineral data and Store forest and agriculture data. The responsibility of these database components is to store the filtered data in order to be identified and analysed for the user.

Concurrently, the raw data captured by the external interfaces get transferred to the Data and Image Upload component. The data and image upload component captures raw data and allows it to be uploaded into the system. This along with the aforementioned database components are used for resource identification and analysis. All raw data is then stored on the Observation Data and Images database.

Observation data, which is the output of the observation data and images database, coupled with resource search and identification data, output from the database components are input into the Resource Identification and Analysis component. This component is responsible for identifying the resource requested in the search criteria and analysing its data to produce an output (in the form of a report, a graph, a map or a data table), and relaying this back to the user in the form of formatted analysed data.

All key components that were initially identified and which were considered components of the system have been integrated into the initial conceptual diagram.

Elaborated Conceptual Architecture

Through a brainstorm about the key concepts on the system narrative, we identified the following components:

• Satellite, wireless sensors, and aircrafts
• Global resources and ecosystems
• Manage data
• Customers profile (initially considered, but removed due to the fact that we'll only provide environmental information)
• Detect and record data
• Filter data according to user-defined parameters
• Analyse soil and water quality

Components Diagram

This is the first version of the conceptual architecture diagram. However, after reviewing our stakeholders' needs and evaluating our diagram, we realised some changes needed to be made, in order to simplify the diagram.

Conceptual Diagram version 1

Conceptual Diagram version 2

Conceptual Diagram version 3

Conceptual Diagram version 4

Coceptual Diagram Version 5

Final Conceptual Architecture Diagram

General Description

The final conceptual diagram above illustrates our elaborated conceptual architecture.

As can be seen, data coming in from wireless sensors, satellites and aircrafts are captured by the detect data component. This component is only responsible for capturing and expelling the data. Not for storage

Data detection then does one of two things

If the data is not recognisable in the format specified by any one of the external interfaces, for security measure, this data is transferred into the 'Store Unrecognisable Data' database. This database then expels such data from the system. This ensures that illegitimate and corrupt data do not enter the system.

All other recognisable data is sent into the Initial analysis component. This component is literally the initial analysis stage of the raw data inputted into the system. The initial analysis component has three major responsibilities, namely, data compression, data sorting and identification of data format (e.g. if it is in a .txt or .jpeg format). Ideally, the data detect and data filter could be made as one component, but the main aim of the conceptual architecture is to show the domain level functionality of the system. The initial analysis component, post analysis, sends the data into its respective storage components.

With ecosystem data, however, the system actually identifies the data type coming in, before classifying which ecosystem it belongs to. It then stores both ecosystem data along with plant and animal data, in its respective ecosystem. Thus we found no need to add a separate ‘plant and animal’ component.

Working our way up from the bottom, the select data parameter component allows the user to set data parameters in order to retrieve required data.

Just above the select data parameters component, we have the analysis engine component. This component receives the relevant data from the retrieve components and represents the second layer of analysis within the system. The analysis engine has three primary functions which are to identify trends, trending and graphing and allowing for the setting of relationship algorithms (which are done by the scientists).

All the retrieve components are solely responsible for retrieving relevant data from data storage. Again, our diagram shows functionality of the system, but in actuality, when we implement the system, the retrieve and storage components can be carried out within one component.

On the left hand side of the architecture, we have three data views.

The web interface view is the view of the system as seen by the general population. This view only allows the selection and viewing of reports that have been stored in the file storage. This is done through the Report Upload and Download component. Users are not required to log onto the system, nor are they permitted to create graphs or generate reports.

The system view is the view through which authorized individuals may access the system. The system view allows the user to select the ‘Login’ option, which then redirects them to the ‘System Management’, in which they are able to input their user name and password. The user names and passwords are compared with existing ones on the ‘authorised user data’ database and authorization is sent to the system view via the system management to access the system. Once the system management grants access to the system, the authorised user is taken directly to the data view page.

The data view a view only accessible by authorised users. This user interface presents users with three options. All authorised users are able to view tabulated data and generate reports, and very limited access (i.e. to scientists who are consultants in the design of the system) is granted to access the analysis engine, in which certain and relevant relationship algorithms are set.

Component Responsibilities

Detect Data:

The purpose of this component is to detect data coming in from the external interfaces

• DetectSatelliteData
• DetectSensorData
• DetectFlyoverData
• SendDetectData

Initial Analysis

This component accepts the detected data coming in from the external interfaces and is responsible for compressing data, sorting data and indentifying and configuring data format.

• AcceptDetectData
• SortData
• CompressData
• IdentifyConfigFormat
• SendAnalysed1Data

Store Waste Data

This component is a logical aspect of the database that refers to all data regarding wasteful resources.

• AcceptClass1Data (This is the first level of data classification)
• StoreWasteData
• StoreWasteLocation
• SendStoredData

Store Water and soil data

This component is a logical aspect of the database that refers to all the data regarding water and soil

• AcceptClass1Data
• StoreWaterSoilData
• StoreWaterLocation
• StoreSoilLocation
• SendStoredData

Identify Ecosystem and Data Type

The purpose of this component is to classify plant and animal information into its respective ecosystem.

• AcceptsClass1Data
• ClassifyanimalData
• ClassifyPlantData
• ClassifyEcosystemType
• SendCalssificationType

Store Ecosystem Data

This component is responsible for storing all incoming ecosystem data.

• AcceptClassificationType
• StoreEcosystemData
• StoreEcosystemLocation
• SendStoredData

Store Mineral Data

This component refers to all the data regarding minerals in the world.

• AcceptClass1Data
• StoreMineralData
• StoreMineralLocation
• SendStoredData

Retrieve Waste data location

The purpose of this component is to receive waste data parameters from the user and to retrieve the required data from the ‘Store Waste Data’ component. Once relevent data is retrieved, it is sent to the analysis engine for trend analysis.

• GetWasteData
• GetWasteLocation
• SendQueryResult

Retrieve water and soil data location

The purpose of this component is to receive water and soil data parameters from the user and to retrieve the required data from the ‘Store Water and soil Data’ component. Once relevent data is retrieved, it is sent to the analysis engine for trend analysis.

• GetWaterSoilData
• GetWaterSoilLocation
• SendQueryResult

Retrieve ecosystem location

The purpose of this component is to receive ecosystem data parameters from the user and to retrieve the required data from the ‘Store Ecosystem Data’ component. Once relevent data is retrieved, it is sent to the analysis engine for trend analysis.

• GetEcosystemData
• GetEcosystemLocation
• SendQueryResult

Retrieve oil and minerals location

The purpose of this component is to receive oil and mineral data parameters from the user and to retrieve the required data from the ‘Store Water and soil Data’ component. Once relevent data is retrieved, it is sent to the analysis engine for trend analysis.

• GetOilMineralData
• GetOilMineralLocation
• SendQueryResult

Analysis Engine

• AcceptInterpretDataParameter
• AcceptQueryResult
• IdentifyTrend
• ChangeRelationshipAlgo
• TrendGraph

Select data parameters

The purpose of this component is to read the set of parameters that the user of the system has requested, and expel this information out to the databases.

• ReadUserSelectLocation
• ReadUserSelectResource
• ReadUserSelectGraphGen
• SendUserParameter

User Generated Graphs

The purpose of this component is to allow users to generate graphs using parameter inputs. This graph generation is separate to the automatic generation of one in the analysis engine.

• AcceptUserSelectParameter
• GenerateGraph
• SendGraph

File Storage

The purpose of this component is to allow users to save the graphs that were generated.

• AcceptGraph
• SaveGraph
• AcceptReport
• SaveReport

System management

The purpose of this system is to receive user user-names and passwords in order to access the system. Once the Authorised User Database authorises the user, the system management then returns an authorisation grant.

• AcceptUserDetails
• ExpelUserDetail
• SendUserAuthorisation
• SendLoginError

System View This component is the intial view for authorised users to acces the system. It provides a login button.

• ProvideLoginOption
• SendUserLoginRequest

Data View

This component presents users with three options. All authorised users are able to view tabulated data and generate reports, and very limited access is granted to access the analysis engine.

• DisplayTabulatedData
• DisplayGraphs&Reports
• DisplayReports
• AllowAnalysisEngineAcess

Web Interface

This component is responsible for providing a user view for the general public who have limited access to the system. This view allows restricted individuals to examine already generated reports.

• ProvideSearchOption
• ProvideReportOption
• DownloadReport

Authorised User Data

This component is a database which stores all the user names and passwords of the system. Its responsibility is to read the incoming user names and passwords and compare them to the existing ones in the database. If such a user name and matching password exists, the component sends an authorisation approval to the system management. Otherwise, a login error is sent.

• ReadUserDetails
• CompareUserDetails
• SendAuthApproval
• SendLoginError

Report Upload/Download

The purpose of this component is to allow for the uploading and downloading of reports and graphs.

• AcceptUserRequest
• UploadReport
• DownloadReport

File Storage

This component allows for the storage of files created by scientists

• AcceptFile
• StoreFile

Data Models

The following diagrams illustrate the data models for certain connectors as well as all persistent storage within the system

File Storage Data Model

Filtered Data Data model

Raw Data Data Model

Requested Ecosystem Data Data Model

Requested/Completed Report Data Model

Requested Soil Data Data Model

Requested Waste Data Data Model

Requested Water Data Data Model

Store Soil Data Data Model

Store Waste Data Data Model

Store Water Data Model

Stored Ecosystem Data Data Model

Stored Waste Data Data Model

Stored Water Data Data Model

User Parameter Data Model

User Request Data Model

Use Case Maps

Scientists/Ecologists (Priority 1 Users)

Looking at the usage narratives and use-case map (1) below, it can be seen that scientists and ecologists are able to carry out five major activities within the system. They can:

• Log into the system through the systems view. Login goes through system management, is checked in the authorised users database and access is such granted

• Retrieve data (raw or analysed) of required parameters through the data view. Parameters are selected, the analysis engine recognises and analyses what the user is asking and retrieves data from its appropriate database.

• From data received, can then produce reports through the data view. These reports may consist of graphs, tables and/or written text. These are then stored in file storage for future reference.

• Not only download reports from file storage through data view, but also upload them onto file storage. The files which are uploaded by scientists and/or ecologists are made accessible to the general public via a web interface. Not all reports produced by scientists or ecologists, however are uploaded onto the system and are accessible to the general public.

• Are able to access the analysis engine to view, alter or formulate new mathematical relationships and formulas that are relevant to the data analysis component of the system.

Policy Makers/Government bodies (priority 2 users)

Looking at the usage narratives and use-case map (2) below, it can be seen that scientists and ecologists are able to carry out five major activities within the system. The activities carried out by the Government is similar to that of the scientists and ecologists, however for safety and data integrity reasons, their access of the system is a little more restricted. Policy makers and government bodies can:

• Log into the system through the systems view. Login goes through system management, is checked in the authorised users database and access is such granted

• Retrieve data (raw or analysed) of required parameters through the data view. Parameters are selected, the analysis engine recognises and analyses what the user is asking and retrieves data from its appropriate database.

• From data received, can then produce reports through the data view. These reports may consist of graphs, tables and/or written text. These are then stored in file storage for future reference.

• Can only download reports from file storage through data view, but are not permitted to upload these files. Files that are produced by government bodies are considered confidential information and thus the general public are prohibited from accessing it. For this reason, reports produced by the government are not allowed to be made accessible.

General Public (priority 3 users)

Upon examining the usage narratives and looking at use-case map (3), we can see that the access of general public of the system is extremely limited. The general public is only authorised to perform one activity, which is to access certain reports through a web interface. This means that an individual or group form the general public accesses the Gurgle Earth web page, and since only certain reports, which are not considered confidential and are proven to be of accurate quality, can be accessed, not user name or login is required.

(1) Use Case Map: Scientists

(2) Use Case Map: Policy Makers

(3) Use Case Map: General Public

Execution Architecture

Initial Execution Architecture

Initial Execution Architecture Diagram

Execution Architecture Diagram version 1

General Description

• As seen in the diagram, we decided to have two separate databases for the purpose of data reliability, which is one of our main quality attributes. One database handles the information processed from the sensors. The other database contains the information related to the user accounts, which allows controlling the access to the system, and therefore enables to guarantee the security, another of our quality attributes.
• The callback present at the request analyser handler refers to the acknowledgment to confirm that the information has been received correctly.
• The data received from the sensors is received in an asynchronous way, given that the system is constantly acquiring information from the wireless and aircrafts, and these don’t need to wait for a response to continue entering data into the system.
• The process to generate reports is made in a synchronous way, as they are waiting for a response from the data analyser before they can be created.
• The data acquisition and recognition is an active component which is constantly updating to receive data from the sensors; it’s repeatedly processing the information received and passing it to the correspondent storage database.

Elaborated Execution Architecture

Elaborated Execution Architecture Diagram

Final Execution Architecture

General Description

The following diagram shows the tweaked version of our execution architecture. Once development began, we realised that a few adjustments needed to be made to the original architectural design.

We decided to employ the concurrent subsystems view. This is because we made use of course-grained components within a large system. Each major unit of concurrency has a clearly defined large-scale purpose.

Our system was divided into manageable 'chunks', each of these conducting a significant amount of work. 'Chunks' are made more clearly identifiable from the deployment view following the execution architecture description.

The execution architecture starts of with the Data Acquisition component. This component is responsible for acquiring data incoming from external interfaces. There is an asynchronous connection between this component and the external interface. This is because neither of the two modules waits for a response from the other if a call is made. Both components carry on with its responsibilities as per required. The Data Acquisition component is an active component in that it periodically captures incoming data. This is carried out in the real time proportion of the system. It does not require an outside influence in order to generate activity.

The Data Acquisition Component makes an asynchronous call to the Data Filter component to filter incoming data into its appropriate categories. The Data Acquisition component carries out its responsibilities without having to wait for a response from its called component. The Data Filter Component carries out its filter task periodically (in the same time increments that the Data Acquisition component captures data) without the requirement of outside influence. Thus this component is also seen as an active one.

The Data Filter Component makes a synchronous call to the Data Library Component. It is a synchronous call because the Data Filter component is waiting for a response acknowledging that the Data Library component has appropriately and correctly received and stored the data sent. The Data Library component, as outlined above, is responsible for the storage of data received from the data filters. It is a database component, as well as a service, since it waits for the component that calls it to make a request, which it fulfils.

Looking at the top of our execution architecture, we have the System User Interface component. This component is the user interface that is used by authorised persons ( i.e. scientists and policy makers) to access the system. On the user interface, the authorised user may logon to the system, access data (already entered into the system), upload/download files and access the analysis engine for altering mathematical logic (scientists only). It is actively initiated by the user (hence a user-initiated component).

Once the user has made his/her selection on the System User Interface, this component calls the Request Analyser component to analyse which request has been made and thus which component to call next. The call from System User Interface to Request Analyser is a callback, indicating that the System User Interface asynchronously receives information (in the form of a report, data, or authorisation approval) in response to whichever request was sent from the user in the first place. It is also an acknowledgement to confirm that the information has been received correctly.

If the user requests to login, the request handler makes a call to the Account Database component. The Account Database is a database which consists of all existing user names and their passwords. The inputted user name with its accompanying password is compared against all the existing ones and authorisation is granted accordingly. The call is a callback, since the Request Handler component waits for an authorisation or rejection response from the Account Database, which is then passed back to the Systems User Interface.

If the user requests data in its raw form (from which they can request data analysis or to access the analysis engine), the Request Analyser component makes a call to the Data Analyser component to carry out such requests. The Data Analyser component is responsible for analysing the data requested by the user. The call made to the latter component is a callback, since the data requested must be returned back to the Data Analyser so that it may be returned to the user to view on the System User Interface.

If the user requests to upload/download a report, the Request Analyser makes a call to the File Server. The File Server saves and stores all files that are generated within the system. The call is a callback because the Request Analyser must wait for the information (in the form of a report) in response to its request, so that it may send it back to the user to view through the System User Interface. The File Server is a service since it waits for its calling component to make a request, which it then fulfils.

The Generate report component is responsible for producing reports at the user's request and is called by the Data Analyser component if such a request is in fact made. The call is synchronous since the calling component must wait for a response from the Generate Report Component that the report has actually been generated before it can resume other analysis tasks. The Generate Report component is a service since it waits for its calling component to make a request, which it then fulfils. Once a report has been generated, the Generate Report component makes a synchronous call to the File Server. This call is synchronous since the Generate Report component requires acknowledgement that the report has actually been stored before continuing with normal operation.

The Web Interface view is the view from which the general public can access the system. Due to our system security constraints, the only action a general public user can make is to access a restricted number of reports. The Web Interface view makes a call to the File Server when a request for accessing a report is made. This call is a callback, since the Web Interface View needs to asynchronously receive the reports in response to a report request.

As seen in the diagram, we decided to have two separate databases for the purpose of data reliability, which is one of our main quality attributes. One database handles the information processed from the sensors. The other database contains the information related to the user accounts, which allows controlling the access to the system, and therefore enables to guarantee the security, another of our quality attributes.

Identification of Concurrent Components

As can be seen, our final conceptual diagram consists of 11 concurrent components.

The web server, data library, unrecognisable data storage, account database and file server are all explicit off-the-shelf subsystems. The Data analyser and generate report components as well as request analyser are all part of application frameworks and can also be seen as off-the-shelf components.

The first thing that can be noticed is the fact that the data acquisition and recognition component is a separate component to that of the data filter. The reason we did this was because it was believed that not only was the data acquisition and recognition an extremely course grained component on its own, but also because it is a real-time component, that is, it has ‘to wait for “the real world”’ (Reekie, McAdam, 2006, pg 71). Furthermore, there is a security issue at the data acquisition and recognition component in that if this component were to receive data that it actually did not recognise, it is required to somehow dispose of it, without having it filter into the system. Thus prior to data being sieved into its appropriate storage units, it must be analysed and that which is illegitimate must be disposed of. Through the requirement of security needs, we needed to create the ‘unrecognisable data storage’ component to ‘provide barriers to intrusion’ (Reekie, McAdam. 2006. pg 70)

Although both the system user interface and the web interface are both “real world” components, and one would be inclined to put them together in one subsystem, they are seen to have completely different roles, stemming from our stringent security needs. The system user interface is a restricted interface through which only authorised personnel are entitled to access the system. The web interface, on the other hand, is a publicly available interface which can be accessed by anyone who wishes to do so. Thus it is clear that for both security and data integrity qualities to be maintained in the system, it is vital that these components are as separate as possible.

Looking at component responsibilities from the conceptual architecture as well as the general description for the execution architecture, we can see that both the Data analyser and the request analyser components are components which perform a significant amount of work. Both components have heavy responsibilities and are extremely course grained. For this reason, it is obvious why we made them concurrent components, since they are sources of concurrent activity within them. ‘The justification for this is that the overhead of concurrent scheduling is low compared to the amount of work performed’ (Reekie, McAdams, 2006, pg 71)

Use Case Maps

As can be seen, use case maps can be triggered in a response to either a user action or to the arrival of real-time data.

Two events occur in response to the arrival of user data and these are GetSample and ExpelUnrecData. The former event acquires and recognises data format type before sending it through the data filter and stores it in the data library. The latter event acquires data and data recognition is not able to identify the data format, thus for security measures, stores it in the unrecognisable data storage database before expelling the data from the system altogether. These use-case maps are outlined in Execution Use case map 1 below:

Execution Use case map 1

A number of events occur in response to a user action. These are outlined as follows:

(the first four events are on the same diagram)

• RequestLogin: When a user requests to login to the system through the System User Interface, this request gets handled by the Request Analyser, which sends the inputted user name and password to the account database for authorisation. (refer to figure)

• RequestRawData: When an authorised user requests access to raw data in the system through the System User Interface, this request is recognised by the request analyser which sends the request onto the data analyser component, which is responsible for acquiring the requested data. This data is then sent back through the request analyse to the user interface. (refer to diagram)

• RequestDataFormulaAlteration: When a scientist wishes to change or carry out maintenance on either raw data or mathematical formulas, he/she first requests access to the relevant data in the system. This request is recognised by the request analyser which sends the request to the data analyser. At this stage, the user is able to select the option to access the analysis engine through the data analyser. (same diagram as access raw data)

• RequestReport: This event has associated with it, two use case maps, since reports can be requested by either an authorised individual (i.e. a scientist or policy maker) or by an individual or group that make up the general public. The use case map generated by authorised users (illustrated in figure RequestReport a)) shows that when an authorised individual requests a report, he/she does so through the system user interface. This is due to security reasons, where there are some reports that are not able to be accessed by members of the general public, but may be by such authorised persons. This request is recognised by the request analyzer and sends the request to the file server, which sends back the requested report to the end user.

These are illustrated in Execution Use case map 2 below:

Execution Use case map 2

• RequestReportGen: When an authorised user requests access to data in the system through the System User Interface, this request is recognised by the request analyser which sends the request to the data analyser. At the data analyser stage, a consecutive trace symbol is used where the continuation of the trace to generate the report is triggered by the user entering the option to generate reports.

This is shown in Execution Use case map 3 below:

Execution Use case map 3

• RequestFileSave: When either a scientist or government body requests access to data in the system through the System User Interface, this request is recognised by the request analyser which sends the request to the data analyser. At the data analyser stage, a consecutive trace symbol is used where the continuation of the trace to generate the report is triggered by the user entering the option to generate reports. At the generate report stage, another consecutive trace symbol is used where the continuation of the trace to save a file on the filer server is triggered by the user entering the option to save the file. (refer to diagram)

This is shown in Execution Use case map 4 below:

Execution Use case map 4

• RequestReportUpload: When a scientist (and only a scientist) requests access to data in the system through the System User Interface, this request is recognised by the request analyser which sends the request to the data analyser. At the data analyser stage, a consecutive trace symbol is used where the continuation of the trace to generate the report is triggered by the user entering the option to generate reports. At the generate report stage, an and-fork trace is used where the scientist can both save the report onto the server or he can upload it and this is made visible on the web interface for access by the general public. (refer to diagram)

This is illustrated in Execution Use case map 5 below:

Execution Use case map 5

Deployment

Execution Architecture Deployment View

The diagram below illustrates the deployment of our execution architecture. As can be seen, multiple UI clients are required to access the system. The UI client is each physical node, or computer, from which the system may be accessed.

The UI client accesses the application server subsystem. This subsystem contains all the concurrent components which are carried out by the server side of the system. The Web interface component provides the web page from which users can access the system via HTTP. This component makes a synchronous call to the Report Database, on which all the reports are stored. The Data Analyser, on which reports are generated component, makes a synchronous call to the Report Database, to store these reports.

As can be seen, for our security requirement, UI clients, the computers on which this system is physically running, are able to access the Data Analyser (this means only policy makers and scientists), where the general public accessing the system via a web interface has access to the reports database only.

Below the Application Server Subsystem, we have the Data Acquisition Subsystem. This subsystem is primarily responsible for acquiring and storing data. The Data Acquisition component captures incoming data and makes a synchronous call to the Data Library to store captured data. The Application Server communicates with the Data Acquisition Subsystem by its Data Analyser Component making an asynchronous call to the Data Library.

Disk recorders are the actual physical hard drives on which all data is stored. Thus both database components make an asynchronous call to the Disk Recorders to physically store either raw data or reports generated. `

Ongoing contextual factors

Given that our system relies on the amount of information received from the sensors and aircrafts, we will be dealing with a system dependant on this data, because the functioning of the component is based on data input and its adequate processing.

We have a considerable number of services, which represents the need for a relatively large capacity of processing information if we want to achieve minimal response time. However, this might represent an issue if we don’t have enough servers to attend the requests issued from several users at the same time. Due to the expected usability of the system, we might need to simplify the process required to retrieve and display the information on screen.

The main focus, as well as the main risk our system faces is that of security. Thus as prototypes are tweaked and as milestones build up to the final deliverable, we must ensure that proper secutiry measures are in place. Looking at the execution architecture, we can see that unrecognisable data is removed from the system, thus diminishing the risk of security threats in the form of denial of service or corrupt data which can be detrimental to the functioning of the system. Furthermore, access to the system has been limited by spliting the views that are accessible by users with different priority levels with regard to system resources that may be accessed. This is shown in the execution architecture by the distinct separation of the System User Interface and the Web Interface. Even within the system view, since we want to strictly prohibit unauthorised access and since there are further priority breakdowns, users are requred to login to the system.

Implementation Architecture

Implementation Architecture Diagram

Implementation Architecture Diagram version 1

Implementation Architecture Diagram version 2

The system is composed of several Java APIs and other physical components. From the diagram, the information is transfered to the server where the JDBC (or SQL procedures) handles the information and stores it into the database (Application Data Model).

The main application component utilises a connection to the database to get the maps and information regarding the location the user has selected and displays the information on the GUI by using socket connections. The user can also write their reports using the main application and when they upload it, it saves the information to the database.

The other users can access the system from a web based (HTTP) user interface which allows them to access the reports from the file server. The Jetty API makes the connection to the server and allows the user to connect to the file server. The Dispatcher API handles the report and table templates, in which the information would be dispalyed. The Freemarker API generates a HTML report page from a template. The information is taken from the database and presented on the template web page when the user selects the completed report from the File server.

The initial concept of the Implementation Architecture described the use of a FTP server. This may still be taken into consideration as the general public may want to keep or print out the report for personal use. For the purpose of this milestone, Freemarker will display the Reports on a web page and on the next iteration of the system, we will consider ways to convert information into a PDF or a WordDoc format.

Considerations for future Milestones

• Conceptually – We need to consider whether or not there is a need to incorporate historical data as well so that the reports can be more meaningful.
• Will there be any legacy systems used?
• What about the extensibility of the system? How extensible do we want to make it and what priority are we going to give extensibility?
• Are we going to look at portability of the system?
• We need to have a look at the distributive nature of the system. We need it to be widely distributive, considering the scope at which it is accessed and utilised.
• Maintainability – Perhaps in the first iteration we have not considered maintainability to the level of detail that we should have.
• Just have a separate tag called XXEcosystem and then just tag all plant, animal and other insect data with one of the ecosystem tags. Queries will then just be able to get XX tagged data from all available plant and animal data. ( The same can be done with the location Tag where each of the data can be accompanied with the location tag and then you can find the info)
• Since we have given much importance to Usability as one of the more predominant quality attributes of the system, we may like to think of including a help tool to aid users to learn how to use system features. Furthermore, it may be an idea to have a way in which scientists can recall their steps and perhaps undo or cancel changes they have made. As it stands currently, once a change is made at each step, it is concrete. Is the system able to recognise and correct user errors?
• In terms of usability, should we think of having a password recovery mechanism?
• Are the secutiry measures taken enough? Do we need to include further firewalls to safeguard the system? Security is the pivotal quality attribute assigned to our system and thus should be examined in much greater details than has been in the first two milestones.
• If the system senses misuse, should it be able to pick up on this and withdraw usage rights from a particular user?
• Should we include a changes tracking system whereby scientists and governement bodies are able to view previous changes made by other authorised users. Should the system record modifications or attempt to access/modify data or system services? This will greatly improve security measures.
• Use of another API which converts the report data into a PDF or Word Doc format for general users to download.

Brief Description of Prototype

An authorised user of the system accesses it through the systems view. This view is the login view. It asks for the user authentication details in the form of a user name and password.

Once the user has been authenticated, he/she is taken to Data View a). This is the first page of the data view. On this page, the user is able to select data type of resource and location using the drop down menus. As the user selects these parameters, the map displays the requested data. The user can also scroll around the map using the side up and down keys, as well as zoom in using the zoom bar below the scroll keys. Once the user has input required data fields, he/she has one of two options. ‘The List of Reports’ button takes the user to a Reports page, which contains all existing reports for the data selected. If the user selects the ‘all’ option on the drop down menus, all available reports will be listed on the Reports page.

Alternatively, once the required data parameters have been entered, the user can press the ‘Use Data’ button, which takes the user to Data View b), which is the second page of the data view. This page displays, at the top, a drop down menu listing all data types for which a table is available and can be either viewed or to generate reports. Under the drop down menu, there is a list which contains names of those tables that have already been selected to view or use to generate reports. The list already contains the table for the data parameter selected in Data View a), which the user has already stated that he/she wishes to use (by pressing the Use Data button). Of the user wishes to view or use more tables, he/she simply scrolls down the drop down menu, clicks on the desired data type and presses the ‘add table’ button. This table is then added to the list. If the user wishes to remove this table form the list, the user simply highlights the table which needs to be removed and presses the ‘delete table’ button.

Once all required tables are on the list, the user has two options. They can either generate reports, or analyse the data in the tables selected.

If the user presses the ‘Generate Reports’ button, they will get take to the Reporting page. This page consists of a text box which allows the user to input any required text that he/she wishes. Below the text box, the tables that were listed on the list on Data View b) are displayed. The text inputted by the user accompanied by the tables form the reports that are viewed by others. On the Reporting page, there are two buttons giving the user an option as to what to do with the report that he/she has generated. In the case of a scientist or ecologist (priority 1 users), they are able to either save the report onto the file server or upload the report onto the web server so that it is publicly accessible. Government bodies and policy makers (priority 2 users) however are only permitted to save reports, since reports generated by such users are not made publicly accessible. The ‘Upload Report’ button is grey-scaled on a priority 2 user’s view.

If, on Data view b), the user selects the ‘Data Analysis’ button, they get taken to the Data Analysis page of the system. The data analysis page lists the tables that the user has selected and that were placed on the list on Data View b). The user is then asked to select the columns on any of the tables presented on which they wish to carry out analysis. Once the columns have been selected (highlighted), the user has three options. From the parameters selected data analysis provides current graphs, future predictions (in the form of graphs), or textual information summary on the particular data properties in question. In addition, priority 1 users are provided with the option of accessing the analysis engine. This is so that scientists and ecologists can access system data for maintenance purposes, as well as modification, addition or deletion of mathematical formulas and logic required for data analysis.

Critique

For this second milestone our prototype experienced some major improvements, so that in the end we managed to include the GUI functionality, connect it to the database and make successful queries updating the information in the tables. We were also able to include the functionality of the Freemarker in our website page. As for our GUI, basically our interface starts with the login screen, which initially was supposed to validate that the username and password were indeed a valid combination, comparing against a number of registered users stored in the database. Due to the lack of time to make these validations, the system ended up just authenticating a specific user ‘test’ with its correspondent password. If the combination was incorrect, then the user would receive and error message, and therefore wouldn’t gain access to the system. For a later milestone, besides validating the users from a database, we would also like to improve our system by allowing companies to log into the system and receive particular reports related to their business. But this will be left for a later stage.

Currently, if it was in fact a registered user trying to login, the system displays the GurglePlanet initial screen, which includes the maps of three different countries, and the resources located in a specific area. The user can then choose from the different combinations of country/resources via the drop box menus included. However, we initially tried to include the functionality of navigation across the map, as well as zooming in a specific region. This would have required some research about how to implement this, but we did not have enough time to actually implement it, which we consider a weak aspect of our prototype, because that would have been helpful to our users (refer to navigation.jpg diagram).

Navigation functionality

After selecting the specific criteria for the analysis, the user clicks on the ReportList button, which leads to the screen that displays all the available reports stored in the database. If no report is selected, then the user cannot go to the edit section of the prototype. After a selection is being made, he can either choose to edit the content or either create a new report. If he goes for the first option, he’ll get a screen that loads the information directly from the database and lets the user edit the content. The changes are then automatically reflected in the database.

If he decides to create a new report, he’ll have to select first which tables are to be included in the analysis. By clicking on the ‘Table View’ option, a screen is displayed showing the map of the selected country, the resources being analysed, and the data regarding that resource that was stored in the database. As for the design of that screen, we experienced some problems trying to alter the size of the window so that all columns would be fully displayed. But even when this doesn’t affect the functionality, is a detail that can be fixed in a later milestone so that the appearance is improved.

We also experienced some problems in fully understanding how Freemarker works, and the limitations it provides. Relating it to our prototype, we were trying to retrieve information from the tables contained in a report, in order to provide a more detailed description about the report’s content. However, we couldn’t get all the functionality in the end, due mostly to the lack of time in developing the prototype. We managed to retrieve limited information about the reports, but weren’t able to link the report description to the tables being analysed.

As for SQL problems, it was noticed that when inserting data into the database, especially user entries like the description of the analysis, SQL experienced some problems handling special characters like the apostrophe and the quoted text. This is one of our main weaknesses, as most of our ideals users are expected to write their analysis as fluent as possible, and we were aiming for a user-friendly interface. However, we were forced to leave this issue for a later milestone, as we didn’t have enough time to research about how to solve this syntax problem.

As for future plans, it would be nice to get the Data Analyser properly working, including the graph generator that was initially planned, but as we progressed we realised that it would be harder than we thought. The initial plan was to retrieve data from specific tables and then plot it so that the user could see the projection of the graph and the tendency of some resources to change during a period of time. This however, couldn’t be included in our prototype.

In the future, it would be interesting to contact wireless companies in order to implement live data capturing, and use real information about specific resources. For our prototype, however, we did research some real reports about existing resources in an area, and tried to manipulate those numbers so that it would resemble real life. In order to work with live data, we also might need to expand the code of our Server, so that it’s able to manipulate multiple events at the same time. That’s because ideally we would have users across the world, accessing the system simultaneously.

As for the maps used in the initial analysis, for our next milestone we would try to contact satellite companies who would provide us live map areas used for the analysis engine. For now we only have static images gathered from different resources, but in order for the analysis to be accurate, it needs to work on real, live data. Based on the previous arguments and the final functionality included, it can be concluded that our prototype successfully achieved the expected results planned for this milestone. It is obvious that some areas need improvement and that functionality is limited to a certain degree, but our prototype goes according to our design.

References

1. Bass. L, Clements. P, Kazman. R, Software Architecture in Practice, Addison Wesley Longman Inc, 2002

2. Clements. P, Bachmann. F, Bass. L, Garlan. D, Ivers. J, Little. R, Nord. R, Stafford. J, Documenting Software Architectures: Views and Beyond, Addison Wesley Longman Inc., 2002

3. Hofmeister. C, Nord. R, Soni, D, Applied Software Architecture, Addison Wesley Longman, Inc., Massachusetts USA, 2000

4. Clements. P, Kazman. R, Klein. M, Evaluating Software Architectures: Methods and Case Studies, Addison Wesley Longman Inc., 2002

5. Reekie. J, McAdam. R, A Software Architecture Primer, Angophora Press, Sydney Australia, 2006

6. Sactoese Nicta, Software Architect and Component Technology, http://www.cse.unsw.edu.au/~yliu/sacthome.htm

7. Understanding Software Architecture, http://www.ug.it.usyd.edu.au/~iango/home/ESA-Chapter-1.pdf

Instructor comments

Good set of stakeholders, but you need to write personas for all of them. Make sure you group the usage narratives together, so it is clear which ones they are. The label "Use Case Narratives" is incorrect. You should have a set of stakeholder narratives dealing with the concerns of stakeholder. AND a set of usage narratives, that are more detailed descriptions of different users' interactions with the system. You need to fix the link to your conceptual architecture diagram. Lian 26th March

In response to your query about your assumptions...

With the first assumption about external producers of wireless and aerospace technologies, it is reasonable to assume that there are standard protocols for data exchange (different for each transmission technology). You have shown a separate external interface for each source of data transmission, which is good. You needn't do much more than that in terms of specifying what that interface is, except in terms of exposed responsibilities on the component with the external interfaces.

Regarding assumption #2 about the users of the system, I had a look back over your stakeholders, and was wondering what happened to the "policy makers" from the original project vision. These policy makers will be different people from various governments that use the system "to find out where resources are being created and consumed". The scientists are only one of a group of people with different skills and needs who are involved in collecting and analysing some of the data.

You may want to consider different levels of user permissions to access various parts of the system. Your current model seems a bit limited. I don't think the policy makers will be liaising through the scientists. You may want to provide a separate user interface for the general public or lower level businesses/organisations that have partial access to the system, and maybe some limited report generation functionality. This could be done through a web interface, where selected data is presented, both for public awareness and information.

In terms of use-case maps, each usage narrative can contain a number of events. Each event is used to trigger a use-case map. But looking at your usage narratives, it is a little confusing. It would be clearer if you moved the usage narratives to a separate section, so that the usage narratives are not mixed in with stakeholder narratives. For example, is the technologist really a user? They are certainly stakeholders.

In your revised conceptual architecture, the presentation components have been reduced to one or two generic components, that hide the different nature of various presentation-related functionality. Showing the security needs here is fine, but think about showing explicitly the different kinds of user functions. The problem with having a generic presentation component, is that the specifics of the functional needs are lost, and thus not amenable to analysis. Lian 16th April

Milestone 1 Feedback
Overall good quality work. Here are a few comments:

• You may underestimated the scope and functionality of the system. I think it should do some automated analysis of the data, and produce patterns and trends. Your design doesn't quite cater for this kind of functionality.
• Not sure about your assumptions regarding the role of the scientists versus policy makers, however we'll leave it as is.
• Was wondering if some of the scientists may be involved in the design of the system as consultants, so that some of their analytic expertise may be captured in some computerised analysis that the system does...
• Odd use of term 'expel', perhaps 'send' or 'reject'? Not sure exactly what you mean.
• UCMs: not fully detailed - see instructions.
• With the UCM for Policy Makers, do the traces really match your explanation? There seems to be a missing trace between Data View and Generate Graphs... (ditto for the Scientists UCM).
• Otherwise Conceptual Architecture is pretty good.
• Good first attempt at Execution Architecture. Need to explain why Request Analyser is active. Need some replication, especially on Data Acquisition and Recognition component.
• Good first Implementation Architecture.
• Thoughtful discussion of issues.

Keep up the good work. Lian 24th April