Team 8: Gurgle Planet
From SoftwarePractice.org
Project Team
| Name | Student ID |
| Michael Davidson | 01062456 |
| Tommy Tsang | 10049791 |
| Luke Wyatt | 02048078 |
| Joshua Green | 01060250 |
System Overview
Purpose
Gurgle Planet is a supervisory data acquisition system designed to detect, collect, map and analyse the generation, proliferation and consumption of natural resources globally. The results of the data acquisition and analysis will be presented through a human to machine interface that can be used by policymakers in their efforts to effectively monitor and manage global resource consumption.
System Functions
* Manage and detect classes of ecosystem such as forests and agricultural zones * Manage and detect the presence of every species of plant and animal * Collect and analyse water and soil quality data * Detect and map oil reserves * Detect and map mineral deposits * Collect and analyse aircraft, wireless sensor and satellite imagery (visible, infrared and radio) data * Analyse resource consumption patterns * Collect and track waste management data
System Qualities
* Usability ("Effective" human interface / Context / Variable Information Display)
* Security
* Performance
* Reliability
* Configurability
* Availability
* Extensibility
Stakeholder Needs
Government
International
Kitheka Johnson
Department of Sustainable Development
United Nations
Kitheka has been a driving force behind pressures groups within the UN, intent on getting world leaders to undertake a more proactive role in long term sustainability management. Part of the group which played a major role in convincing the leading world powers to commit to large scale reductions of their resource consumption, Kitheka now leads a team responsible for monitoring and enforcing the agreed upon consumption levels of resources in the Oceania region.
Federal
Senator Barry Jones
Federal Minister for the Environment
At the most recent round of talks at the UN, the Kyoto Protocol to the United Nations Framework Convention on Climate Change was redrafted to drastically increase the emission reduction targets for Annex I countries. Australia, as a signatory to the treaty and a major supplier of global resources, is committed to enacting the necessary legislation to meet these targets. Senator Barry Jones, after meeting with his advisors, introduces a bill into parliament to immediately impose greater taxes on exports of natural resources and tighten emission controls and reporting requirements for Australian companies. Revenue raised will be placed into a fund to drive investment in renewable energy sources and greenhouse gas reduction/recycling technology.
State
Hon. Lisa Abrams
NSW Minister for Energy and Water Utilities
The Hon. Lisa Abrams is the Minister for Energy and Water Utilities. As the head of the Department of Energy, Utilities and Sustainability her department provides the Government and the people of New South Wales with high quality professional advice and delivery of policies, reforms and programs relating to energy and urban water use. Lisa launches an initiative with the support of the energy and water utilities, to install power-saving and water-saving equipment in every residential and business premises and promote the use of recycled water and energy derived from renewable sources. Lisa's department also regulates and monitors the state's electricity, gas and water supplies to ensure the major utilities are providing accurate information regarding their input and consumption of natural resources.
Michael Donahue
Deputy Director General of the Environment Protection & Regulation Division
NSW Department of Environment and Conservation
Michael Donahue is the Deputy Director General of the Environment Protection & Regulation Division of the NSW Department of Environment and Conservation. Michael manages the department that is responsible for licensing organisations and setting limits on their pollution loads to assist in the control, reduction and prevention of air and water pollution in NSW. He enforces the environmental law changes at a federal level by making the installation of resource monitoring equipment a mandatory condition of obtaining/renewing an environmental protection license. This forces license holders to be wholly accountable for their resource consumption and serves to make this information available to the Department for collection and monitoring.
Industry
Business
Graham Smith
Vice President of Electrocorp
Graham is the Vice President of a leading electronics manufacturer. Over the last fifty years his company has used thousands of tonnes of metals and plastics in their products and consumed a large amount of energy in the manufacturing process. Electrocorp is required to implement monitoring equipment throughout the assembly line to comply with new environmental reporting standards to maintain their manufacturing license. Graham is concerned about the initial cost of installing the new equipment and of the financial implications of how the reported data will impact his business moving forward.
Technical
Virgil Swanson
Environmental Monitoring Technical Services (EMTS)
Virgil Swanson is employed by EMTS, a contracted company that is responsible for maintaining the central data repository for the UN environmental monitoring initiative. He specialises in data integrity and quality control. Because a lot of the data in the system is gathered surreptitiously the integrity of the data must be monitored and enforced. Cases requiring investigation are logged by the system and are analysed by Virgil. He has found that poor quality data can be the result of a number of factors including equipment faults, human errors, software defects and incorrect configuration.
Public
Dr Sally Jenkins
Senior Energy Scientist at Small Energy Co
Sally is a scientist working on a project to develop more efficient technologies that allow power stations to produce low cost electricity more cleanly and reduce greenhouse gas emissions. She is currently interested in improving the method of power generation of coal, nuclear, natural gas, solar power and wind. Sally is engaging business and government for funding to support her research and development activities.
Eddie
Community Member of Greenpeace
Eddie is a keen environmentalist and community member of Greenpeace. He is concerned about the depletion of resources and strongly advocates for protection of the natural environment. Eddie uses his time to increase awareness of the issues of responsibly energy use and resource consumption in the local community.
Grant
Local Fisherman
Grant is a fisherman earning a living fishing on the river his family lives on. Poor water management and decades of industrial development further upstream have resulted in significant reduction in the water level and concerns about the levels of pollutants in the river. This has resulted in a reduction in his daily number of salable fish. Recently his concerns have led him lobby local governments to improve water quality in the area. He fears that if action is not taken soon he will be unable to make a living from the river his family has fished for generations, as the number of fish declines and the catch becomes inedible.
System Context
Market/Competitive
The unsustainable emulation of "first world" resource usage by "third world" countries has been unchecked for the last fifty years. Scientists have indicated that unless usage patterns change within the next five years the Earth may reach ecological collapse. Gurgle Planet, as one of the core systems used to change resource usage patterns, will need to be completed before this deadline. This deadline will place significant pressure on all parties involved (Constraint).
Several of the sensor and satellite suppliers have realised the importance of the project and have pledged to sell excess stock to the project for reduced prices (Enabler). Some of the less forward thinking suppliers have claimed bias and are threatening legal action as a result (Risk). Several competing firms, of dubious ethical standards, have been attracted to the project due to its sheer scale. There are concerns that they may resort to espionage and sabotage in order to gain a competitive advantage over Global Technology Solutions' system (Risk).
Organisational
The organisation will traverse the full spectrum of different domains of various sizes, sectors and physical locations around the world. Business (from Sole Proprietors to Multinational Corporations), governments (from Local to National and Global), other special interest groups and non-profit organisations and also at an individual level.
The shear size and complexity of the organisation will need to be understood and managed (Constraint). The groups with the power in the organisation, i.e. big business and high level governments want the system and can exercise their influence and resources to help drive the project (Enabler). Groups in the organisation come from all combinations of different backgrounds and will have different and competing needs and wants. These differencs need to resolved (Risk).
Technological
The UN has requisitioned several existing, in use, Low Earth Orbit and Geostationary satellites for use in the Gurgle Planet Project (Enabler). However as part of the requisition agreement the project is only allowed to use a subset of the available bandwidth which places limits on the amount of data, as well as the time when data can be transmitted, to and from satellites (Constraint).
A key requirement is that the data, in the form of reports, will be accessible from the internet (Enabler) there will be a significant burden on the database servers. There will be a need to design the system in such a way as to minimise database and application server load to handle the large amounts of traffic expected (Constraint). There are also concerns that public access to the data will introduce security concerns which is exacerbated by the need to obtain some data surreptitiously. As a result data integrity and security measures will need to exist in the system to prevent malicious users and countries from falsifying records (Risk). Frequent automated backups to distributed locations can be employed (Enabler) to ensure data can easily be rolled back to previous points if data modification is detected and to prevent data loss in case of system failure (Risk).
Policy / Government
The global resource monitoring system project currently has the support of the leading world powers. This should ensure there is adequate momentum and drive towards the implementation of the project and should result in the necessary resources and access being made available (Enabler). However, as part of a global solution, the Gurgle Planet project is likely to be tightly controlled and subject to the bureaucratic and layered systems of governance that exist at the international and national levels (Constraint). Subsequently, the amount of 'red tape' and the time required for consensus decision-making is likely to delay project activities (Risk).
While the leading world powers have offered their support, there are also likely to be countries that do not wholly support the global solution, and may be uncooperative in terms of access or provision of useful data. This will undoubtedly impact on the effectiveness of the system as a whole. (Risk).
Usage Narratives
Developers
Owen Reilly
Report Designer
Global Technology Solutions
Owen is a Report Designer for GTS whose primary job is to design and implement reports for the Gurgle Planet system for use by policy makers. As such Owen needs to have a working knowledge of the database design and the interface component used by the Gurgle Planet database. Using this raw data Owen creates a variety of reports, based on aggregate data, in an interactive format suitable for distribution to high level policy makers.
Owen is given a request to create a new report which shows the logging and re-plantation of forests over a specified time period. This report will help policymakers set limits on wood exports and usage for each region. His first step is to connect to a development database and ensure that all the requisite information exists. Upon finding that all the information exists he proceeds to use a popular report package to create the layout and interface of the report before moving onto using an existing database interface to link the data to the report. Once finished authorised policy makers will be able to access the report from the Gurgle Planet Management System.
Craig Shear
Systems Analyst
Global Technology Solutions
Craig is a systems analyst who is responsible for taking user requests and converting them into a set of unbreakable system and business rules used in the project. The majority of Craig's work is at the database level where he has to write code to enforce the rules. Part of his job is also to expose these new rules to the database interface whilst minimising changes to the interface.
Craig's latest request is to place limits on the number of megawatt hours that a country can produce using non-renewable means without purchasing carbon credits from other countries. His first step is to place binding rules in the database to ensure the net non-renewable megawatt hours can not go over a certain limit. Once completed he adds some additional database interface methods for systems to obtain the remaining number of non-renewable megawatt hours, purchase carbon credits and track hour usage.
Operators
Lt. Pete Mitchell
MQ-3 Predator II UAV Pilot
North Atlantic Treaty Organisation (NATO)
Lt. Pete Mitchell is an unmanned aerial vehicle (UAV) pilot from the Resource Reconnaissance Squadron of NATO. Based at the Incirlik Air Base in Adana, Turkey, he is charged with conducting aerial reconnaissance of oil and mineral reserves in neighbouring Syria and Iran to identify unregistered shipments or stockpiling of resources and monitor resource processing activities. He controls a MQ-3 Predator II, a medium-altitude, long-endurance UAV system, remotely via a duplex satellite link to headquarters.
His latest mission is to conduct reconnaissance patrols of Syrian energy facilities near the border with Turkey. There are concerns that a number of oil facilities are under-reporting the output of crude oil, and are stockpiling large amounts of uncounted oil barrels for shipment to the African continent. He authenticates through a secure connection to the Gurgle Planet system and is presented with a series of maps that have been assigned to his profile. The maps are a view of the energy facilities in the region that have been identified by headquarters for surveillance and have been saved in the Gurgle Planet system.
On his second patrol, Pete sights a road train leaving an energy facility. He makes a second pass and uses the telescopic camera fitted to his aerial craft to photograph the shipment. The photographs are automatically transmitted via a satellite link to headquarters and forwarded to the analysis team where a determination can be made about the shipment and whether it has been registered with the appropriate authorities.
Frederik Christensen
Danish Energy Authority
Ministry of Transport and Energy
Frederik is a data analyst for the Danish Energy Authority (DEA). The DEA carries out tasks, nationally and internationally, in relation to the production, supply and consumption of energy. This means that the Authority is responsible for the whole chain of tasks linked to the production of energy and its transportation through pipelines to the stage where oil, natural gas, heat, electricity etc. are utilised for energy services by the consumer. Frederik is responsible for reviewing the reporting data received from various companies and government departments, verifying it and triggering its upload into the global resource monitoring system.
He opens the application interface, logs into the Danish server and browses to the day's electricity consumption data that has come from the onsite monitoring equipment at the various Danish energy utilities. He uses the inbuilt trend analysis tools to produce a report allowing him to compare the day's consumption against historical data. After confirming the data is complete and consistent, he flags it for upload into the European server based at Geneva in Switzerland. Frederik then proceeds to the natural gas consumption data where trend analysis reveals a spike in consumption outside of the established limits. He drills down into the data and discovers an inconsistency in the data received from measuring equipment at a Danish Oil and Natural Gas (DONG) facility in Hørsholm. He flags the erroneous data as invalid and requiring investigation. He then flags the remaining data for upload.
Åsa Bäverstam
Integration Support Technician
Danish Oil and Natural Gas (DONG)
Åsa is an Integration Architect at Danish Oil and Natural Gas and is responsible for integrating their reporting systems with the interface provided by the global resource monitoring system. A legacy system is employed at Dong which is able to extract data into a number of primitive file formats such as text. An example input dataset is the Electricity - Distributed and Dispersed Generation file that contains fields such as number of generators, combined capacity, type of energy sources used, types of generators used and an amount of electricity generated for each type in megawatthours.
Åsa decides to export the relevant information from their reporting systems into a delimited text format which is stored on a local share. This is to provide an intermediate point for validation and review of the file output. A batch job then picks up the text file, initiates a secure connection to the Danish server, and uploads the data. A log file is produced that Åsa reviews to ensure the file has been submitted correctly.
Policy Makers
M. F. Howard
UN Global Policy Council
United Nations
Mr. Howard is a high level official employed by the United Nations and has been assigned to use the Gurgle Planet project to help manage global resources. He often attends a multitude of tele-presence conferencing with world leaders and other policy makers to work out the details of resource allocation and consumption requirements. Because of this he requires access to a variety of reports, which will be generated by the Gurgle Planet system, in order to determine adequate levels of resource usage.
In a recent tele-presence conference, with the leader of Cuba, Mr Howard needed to review resource allocation and consumption patterns in order to assess a proposal for a new electric power plant. Upon logging into the Gurgle Planet management site, and authenticating himself, he was able to access a variety of interactive reports on the resource usage patterns of Cuba. Using these reports he is able to create hypothetical usage scenarios and monitor their predicted affect on global resource patterns. He saves these scenarios as part of a new draft energy policy for Cuba which he will access later when he completes the new policy.
Kimimaro Tsugo
UN Global Policy Council
United Nations
Kimimaro Tsugo is an advisor to the United Nations assigned to a portfolio focused on the generation and distribution of minerals in the Asia-Pacific region. One of his responsibilities is to monitor and report on the generation of copper and iron for the region. In preparation for an upcoming policy meeting, he is required to review the level of copper production off Australia's north coast between Australia, Papua New Guinea and Indonesia.
Kimimaro authenticates to the Gurgle Planet system and is presented with a map of the globe. He proceeds to narrow his world view by zooming in on the Australasian region and is gradually presented with more detail about the area in view. Once the north coast of Australia and south coast of PNG and Indonesia are visibly detailed on screen, he browses through the Gurgle Planet menu and selects the Copper Production view. He is presented with an indexed view of the region with shading ranging from green to yellow. Yellow is indicative of areas of low production while green is indicative of high production. Kimimaro selects a more detailed view and is presented with the actual tonnes per day values. He notes that a number of the offshore mines near PNG have radically decreased their production and is concerned about the global impact of the decrease. He prints the maps and includes them in his file to review and present at the upcoming policy meeting.
Technicians
George El Dubya
Sensor Technician
Responsible for the configuration of wireless sensors
George El Dubya helps maintain the online configuration of the 'smart dust' wireless sensors. He does this through a remote user interface. From this interface he can monitor the status of the sensors and update the sensor configuration variables.
One of the sensors in his charge has undergone some physical maintenance. As a result, the status of sensor has been updated from 'out for maintenance' to 'ready for re-deploy'. George logs into the system and navigates to a page listing the sensors in his charge and searches for sensors requiring action. He opens up the sensor 'ready for re-deploy' and updates the configuration variables to specification. He then re-deploys the sensor, changing the status from 'ready for re-deploy' to 'deployed'. He performs a status check to ensure the sensor is working.
Steve Mansour
Systems Engineer
Responsible for maintaining system and remote access
Steve's main role is to setup new users with access to the system and modify access of current users, to specific areas of the system.
Steve logs into the system and see’s that a current user needs different access privileges to the system. The user works with the UN and has been transferred to an area which is responsible for a different class of consumers. Steve opens up the user profile and removes current access which will no longer be needed. He then adds the new access which the user will need in their new role. Steve saves the changes to the user profile and alerts the user that the changes have been made.
Quality Narratives
Security
Joseph Ramos
System Administrator
United Nations
Joseph Ramos is a System Administrator based in the UN who provides on-site administration of the Gurgle Planet system. Within his administrative capacity, Joseph controls user access to the Gurgle Planet system and monitors and maintains system logs.
Joseph receives a request from a policy maker for access to the system. Joseph reviews his credentials in the United Nations personnel database and verifies their identity to be Kimimaro Tsugo from the UN Global Policy Council. The UN policy for access to confidential information is very strict and Kimimaro's clearance is determined to be limited to reporting on the asia-pacific region. Joseph creates a user for Kimimaro and assigns the associated user profile to Kimimaro so that his access to the Gurgle Planet system matches his level of clearance.
Soon afterwards, Joseph receives an ALERT email from the Gurgle Planet system advising of a series of attempted connections that have been blocked at the firewall. Joseph reviews the firewall logs and identifies a possible port scan attempt on the server. The log information is forwarded through to the Gurgle Planet Security Unit for further investigation. Joseph also receives an email request from Kimimaro advising that his login has been locked due to multiple incorrect login attempts. This is an additional security measure to protect against brute-force attacks that may try to guess a valid users credentials. Joseph verifies Kimimaro's identity in the UN personnel database, unlocks the account and issues a new authentication key.
Performance
Lt. Pete Mitchell
MQ-3 Predator II UAV Pilot
North Atlantic Treaty Organisation (NATO)
Lt. Pete Mitchell is an unmanned aerial vehicle (UAV) pilot from the Resource Reconnaissance Squadron of NATO. Based at the Incirlik Air Base in Adana, Turkey, he is charged with conducting aerial reconnaissance of oil and mineral reserves in neighbouring Syria and Iran to identify unregistered shipments or stockpiling of resources and monitor resource processing activities. He controls a MQ-3 Predator II, a medium-altitude, long-endurance UAV system, remotely via a duplex satellite link to headquarters.
During a patrol mission, he receives a directive from headquarters that satellite imagery has identified a stockpile of unidentified resources at a nuclear plant near the border with Turkey. The UN security council has authorised aerial reconnaisance of the site in order to obtain more information about the nature of the materials as they suspect it may be used in the production of nuclear weapons. An urgent response is required in order to determine whether the security council needs to take further action. Lt. Pete marshalls is aircraft to a safe altitude over the site and takes a series of images using the telescopic camera fitted to the craft. He communicates back to headquarters that the mission has been successful and requests that they verify the results. The operator at headquarters logs in to Gurgle Planet and verifies that the imagery has already been received and will be forwarded to the UN Security Council.
M. F. Howard
UN Global Policy Council
United Nations
Mr. Howard is a high level official employed by the United Nations and has been assigned to use the Gurgle Planet project to help manage global resources. He often attends a multitude of tele-presence conferencing with world leaders and other policy makers to work out the details of resource allocation and consumption requirements. Because of this he requires access to a variety of reports, which will be generated by the Gurgle Planet system, in order to determine adequate levels of resource usage.
A meeting has been called between Mr Howard and delegates from the United States, France, Germany and Japan. He is responding to a US request for a temporary increase in their resource allocation threshold due to a tornado that has destroyed the town of Greensburg in south-central Kansas. Additional power and material resources are required to be diverted to assist in the reconstruction of the town. Mr Howard suggests that additional resources could be diverted from elsewhere in the United States. He logs into the Gurgle Planet system and through the reporting option, he requests a report on the allocation of energy resources in the USA by state. After a short wait, he is presented with the requested report which he displays to the delegates for further discussion.
Conceptual Architecture
Component Domain Level Responsibilities
Data Sources
The Data Source component is the only means of communicating with the external data sources. It balances the performance of the system by managing the flow of data into the database with security by providing a means of identifying and authenticating external entities.
Key Responsibilities:
* Identifies / authenticates the external data sources * Receives and parses the data from authenticated external data sources through to the data stores * Sends control information to the external data sources
Data Stores
The data stores components are solely responsible for the storage of subject matter data.
Key Responsibilities:
Resource Consumption Data
* Stores external data relating to resource consumption
Waste Management Data
* Stores external data relating to waste management
Water and Soil Quality Data
* Stores external data relating to water and soil quality
Sensor and Imagery Data
* Stores external imagery and other sensor data
Analysis Results
* Stores the data that is created and derived from the data analysis component
Spatialisation Data
* Stores mapping coordinates and metadata that have been manually entered * Stores mapping coordinates and metadata that have been derived from data analysis
Authentication
The Authentication component provides the security of the system from a user access perspective.
Key Responsibilities:
* Securely stores access control and user profile data * Authenticate access credentials for the user interfaces and provides the matching user profile to the various user displays
Maintenance and Monitoring
The Maintenance and Monitoring component facilitates the reliability and configurability of the system by providing feedback on the health of system components and enabling access to administer the data-centric components.
Key Responsibilities:
* Enables administration of the Authentication and Data Sources components and data stores * Provides administration and monitoring functions to an authenticated user through the Maintenance and Monitoring console * Monitors the status of the Data Sources component and data stores
Data Analysis
The Data Analysis component is the intelligence behind the interpretation of data and allows the user to apply meaning to the raw data through additional analysis and access the results.
Key Responsibilities:
* Performs processing and statistical analysis such as pattern recognition and trending on data * Reads rules and logic input from the Data Analysis User Interface for use * Generates alarms / events based on pre-defined rules-based triggers and notifies the user through the Data Analysis User Interface * Optionally stores the results of analysis in the Analysis Results component for future use
Spatialisation
The Spatialisation component adds a spatial context to the stored data by transforming the stored coordinate and metadata into a visual representation for the user.
Key Responsibilities:
* Enables entry of spatialisation data through the Spatialisation User Interface * Generates maps and spatial imagery for display on the Spatialisation User Interface * Stores spatialisation data in the Saptialisation Data component
Reporting
The Reporting component provides the capability for the user to query the subject matter data stored within the system.
Key Responsibilities:
* Allows the definition/design of reports that query the various data stores components * Stores report definitions / designs * Generates reports for display on the Reporting User Interface
Reporting User Interface
The Reporting User Interface provides a visual display to the user for Reporting data.
Key Responsibilities:
* Authenticates the user through the Authentication component * Provides the ability for the authenticated user to design reports * Displays reports generated by the Reporting component
Data Analysis User Interface
The Data Analysis User Interface provides a visual display to the user for Analysis data.
Key Responsibilities:
* Authenticates the user through the Authentication component * Provides the ability for the authenticated user to enter Analysis rules and logic * Provides the ability for the authenticated user to trigger data analysis based on defined rules and logic * Displays alarms and events generated by the Data Analysis component
Spatialisation User Interface
The Spatialisation User Interface provides a visual display to the user for Spatialisation data.
Key Responsibilities:
* Authenticates the user through the Authentication component * Provides the ability for the authenticated user to enter mapping coordinates and metadata * Displays maps and information generated by the Spatialisation component
Maintenance and Monitoring Console
The Maintenance and Monitoring Console provides a visual display to the user for system Maintenance and Monitoring.
Key Responsibilities:
* Authenticates the user through the Authentication component * Provides the ability for the authenticated user to access the Maintenance and Monitoring component * Displays the status of system components from the Maintenance and Monitoring component
Data Models
Reporting Persistence
The Reporting component is required to store report definitions that can be executed by the user. The data model demonstrates that a report definition will require at least a data source and a query to run against this data source.
Data Analysis Persistence
The Data Analysis component is required to store analysis logic that can be used to process the stored data. The data model demonstrates that analysis logic will require a data input and a set of rules to process the input. The data input requires at least a data source and a query to run against the data source. The processing element requires a function that may be mathematical or pre-defined and a set of parameters.
Authentication Persistence
The Authentication component is required to store user credentials that can be used to provide the appropriate level of access to the user. The data model demonstrates that users will be configured and assigned to profiles. The user profile will determine the level of access that the user is permitted to have.
Data Persistence
The various data storage components are required to store specific data that is received from various sources. The data model shows how the data values can be supplied in a generic format that is distinguished by a type, and can be referenced back to the source from which the data originated. An optional coordinate assigned to the data provides the spatial information for the Spatialisation component.
Use Case Maps
Reporting
The reporting use case map demonstrates the user functionality required by Developers and Policy Makers to create and view reports.
AuthenticateReportUser: This use case demonstrates how the user will authenticate themselves to the Reporting component and receive the appropriate user profile on the user interface. Upon logging in, the user enters their authentication details. If successful, they are presented with a screen that matches the access permitted in their user profile.
ViewReport: This use case demonstrates how an authenticated user can execute a query against the stored data. The user requests a report through the user interface. If their session has expired, the user is requested to enter their authentication details, otherwise the request is received by the Reporting component. The Reporting component determines the query and source of the report, executes the query against the source, and returns the report data for rendering on the user interface.
CreateReport: This use case demonstrates how an authenticated user can create a report definition to produce a report on the stored data. The user selects the create report option. If their session has expired, the user is requested to enter their authentication details, otherwise the request is received by the Reporting component. The Reporting component offers a mechanism to add queries against the various sources, while providing active feedback to the user interface for display to the user. The reporting definitions are saved in the Reporting component.
Data Analysis
The analysis use case map demonstrates the user functionality required by Developers to implement data analysis logic. It also demonstrates the lifecycle events that occur in the system independent of user interaction.
AuthenticateAnalyst: This use case demonstrates how the user will authenticate themselves to the Data Analysis component and receive the appropriate user profile on the user interface. Upon logging in, the user enters their authentication details. If successful, they are presented with a screen that matches the access permitted in their user profile.
AddAmendAnalysisLogic: This use case demonstrates how an authenticated user can add or amend analysis logic that is stored within the Data Analysis component. If their session has expired, the user is requested to enter their authentication details, otherwise the request is received by the Data Analysis component. The Data Analysis component offers a mechanism to add queries against the various sources as input into the logic function and define the logic that will be applied to calculate the output, while providing active feedback to the user interface for display to the user. The data analysis logic is saved in the Data Analysis component.
StoreRawData: This use case demonstrates how data received from external sources will be stored in the database. Data Sources is an active component that receives the data through an external interface. The data received is buffered and when the buffer is full or the data has been fully received, it is pushed to the Raw External Data Stores.
ProcessRawData: This use case demonstrates how the raw data that is received and stored in the Raw External Data Stores is then processed and stored in the Manual / Derived data stores. Data Analysis extracts the data and applies it's internal processing and logic to produce a new collection of output values. The output values are then stored in as Manual / Derived data.
ProcessDerivedData: This use case demonstrates how data that has been processed previously can undergo additional processing to further refine the results. In a similar fashion to the ProcessRawData use case map, Data Analysis extracts the data and applies it's internal processing and logic to produce a new collection of output values. These values can then be restored as Manual / Derived data.
GenerateAlarmEvent: This use case demonstrates how pre-defined logic in the Data Analysis component can trigger an alarm or event to notify the user that a threshold or criterion defined against the data has been met.
Spatialisation
The spatialisation use case map demonstrates the user functionality required by Policy Makers and Operators to view generated maps and view or enter mapping information.
AuthenticateMappingUser: This use case demonstrates how the user will authenticate themselves to the Spatialisation component and receive the appropriate user profile on the user interface. Upon logging in, the user enters their authentication details. If successful, they are presented with a screen that matches the access permitted in their user profile.
ViewLocationMap: This use case demonstrates how an authenticated user can view maps generated by the Spatialisation component. The user requests a map through the user interface. If their session has expired, the user is requested to enter their authentication details, otherwise the request is received by the Spatialisation component. The Spatialisation component retrieves the relevant coordinates from the Spatialisation data store and returns the coordinate data for rendering on the user interface.
EnterMappingData: This use case demonstrates how an authenticated user can enter mapping data through and for use by the Spatialisation component. If their session has expired, the user is requested to enter their authentication details, otherwise the request is received by the Spatialisation component. The Spatialisation component offers a mechanism to enter coordinate and metadata while providing active feedback to the user interface for display to the user. The mapping data entered is stored in the Spatialisation data store.
Administrator
The administrator use case map demonstrates the user functionality required by Technicians to manage and monitor external data sources and data persistence within the system.
AuthenticateMappingUser: This use case demonstrates how the user will authenticate themselves to the Maintenance and Monitoring component and receive the appropriate user profile on the user interface. Upon logging in, the user enters their authentication details. If successful, they are presented with a screen that matches the access permitted in their user profile.
QuerySensorStatus: This use case demonstrates how an authenticated user can view the status of external data sources on the user interface. If their session has expired, the user is requested to enter their authentication details, otherwise the request is received by the Maintenance and Monitoring component. The current status of external data sources is buffered as a result of regular polling in the Maintenance and Monitoring component. This data is returned to the user interface for display to the user.
ChangeSensorConfig: This use case demonstrates how an authenticated user would adjust a configuration value on an external data source. If their session has expired, the user is requested to enter their authentication details, otherwise the request is received by the Maintenance and Monitoring component. The Maintenance and Monitoring component offers a mechanism to amend the configuration data for external devices stored within the Data Sources component. It sends a control message and a status message regarding the configuration change is returned. This feedback is returned to the user interface for display to the user.
ChangeDataRecord: This use case demonstrates how an authenticated user would manage a data record located within the data persistence. If their session has expired, the user is requested to enter their authentication details, otherwise the request is received by the Maintenance and Monitoring component. The Maintenance and Monitoring component offers a mechanism to adjust data stored within the Data Stores. It sends a control message to the data stores and a message with results or regarding a change is returned. This feedback is returned to the user interface for display to the user.
Execution Architecture
Concurrency View
Client Application
The Client Application calls the Reporting, Spatialisation and Maintenance and Monitoring components asynchronously to ensure that the user interface remains responsive to the user at all times. The only exception is the Data Analysis component. As data analysis can potentially take a lengthy time to complete, a callback is used so that the Data Analysis component can call the Client Application to report the results when they are ready. It is expected that there will be multiple client applications accessing the system concurrently and this has been indicated in the view.
Data Analysis
Data Analysis will be actively processing data as it is received. It can also be triggered by the user and has been designated as a service for that purpose. Data Analysis can generate notifications based on pre-defined criterion that has been applied to the data. Notifications are sent asynchronously to the Notification subsystem so the Data Analysis subsystem can continue further processing if required. This ensures the notification is expedited without affecting the performance of the module. Data Analysis retrieves data from the Data Storage synchronously as it can not continue processing until it has received the data it needs.
Reporting
Reporting will be triggered by an asynchronous call from the Client Application. It will execute the requested queries against the source data in Data Storage through a synchronous call as it can not proceed without the data being returned. Once it has received the requested data, the data will be returned through the original call from the Client Application.
Spatialisation
As with the Reporting subsystem, Spatialisation will be triggered by an asynchronous call from the Client Application. It will execute a query against the Data Storage subsystem through a synchronous call as it can not proceed without the coordinate data being returned. Once it has received this data, it will be returned to the Client Application for rendering through the original call.
Notification
The Notification subsystem has been designated as a service as it will be triggered by an asynchronous call from Data Analysis. It will integrate with external notification entities in order to send the appropriate notifications.
Data Storage
Data Storage has been designated as a service as it has to respond to various calls from other subsystems. It is the primary data persistence entity for the system and is critical in nature to the system as a whole. As it is a distributed system and for performance reasons, it is viewed that there may be multiple concurrent instances of the Data Storage running. This has been reflected in the diagram.
Monitoring
Monitoring will actively monitor the Data Sources and Data Storage subsystems to retrieve their current status. It will also be notified of urgent events via a callback scheme from these subsystems. These statuses can then be returned to the Client Application when it is requested. The client makes the call through a callback scheme so urgent events can be updated to an active Client Application session without requiring further user input.
Data Sources
Data Sources will synchronously enter data into the Data Storage subsystem by buffering the data internally and sending a set of transactions in a batch. It will continue to buffer data until a positive acknowledgement is received for it to send the next update. It is viewed that Data Sources subsystems may be distributed and have multiple instances running concurrently. This has been reflected in the diagram.
Behavioural Analysis
Reporting
ViewReport: This use case demonstrates how an authenticated user can execute a query against the stored data in the form a report. The user requests a report through the user interface. The Reporting component calls Data Storage to execute the query against the data, and returns the report data for rendering on the user interface.
The Reporting component writes report definitions to the Data Storage, however, these are separate from the other forms of data. All other access to the Data Storage is read-only. As the Client Application can be replicated, there is likely to be concurrent requests to the Reporting component, however, an asynchronous call means the user interface will remain responsive while the data is being served. The call to the Data Storage is synchronous so that the Data Storage can implement the necessary controls around concurrent access to data and acknowledge when data has been queried or added successfully.
Spatialisation
ViewLocationMap: This use case demonstrates how an authenticated user can view maps generated by the Spatialisation component. The user requests a map through the user interface. The Spatialisation component retrieves the relevant coordinates from Data Storage and returns the coordinate data for rendering on the user interface.
Similarly to Reporting, Spatialisation data can be manually added in to the Data Storage, but the manually entered data is seperated from the other forms of data. All other access to the Data Storage is read-only. As the Client Application can be replicated, there is likely to be concurrent requests to the Spatialisation component, however, an asynchronous call means the user interface will remain responsive while waiting for data, and the synchronous call to Data Storage ensures that it can implement the necessary controls around the data and acknowledge when data has been queried or added successfully.
Data Sources
StoreRawData: This use case demonstrates how data received from external sources will be stored in the database. Data Sources is an active component that receives the data through an external interface. The data received is buffered and when the buffer is full or the data has been fully received, it is pushed to the Raw External Data Stores.
The Data Sources component may potentially receive data from a number of sources simultaneously, but this is buffered and processed in a sequential fashion to the Data Storage. The Data Sources component is the only one with the ability to write to the raw data tables in Data Storage. As the data is loaded in a sequential fashion, there is no significant concurrency concerns and the synchronous call from Data Sources to Data Storage ensures that an acknowledgement is received for a data load before further data is transmitted.
Data Analysis
DataAnalysisRequest: This use case demonstrates how data that is received and stored in Data Storage is sent to Data Analysis for input into it's rule-based analysis. Once the data is received and analysed, this data can either be re-stored in the database and/or a notification sent to the user. This is addressed in the DataAnalysisStoreNotify use case map.
DataAnalysisStoreNotify: As described in the DataAnalysisRequest description, this use case demonstrates how once the data has been analysed in the Data Analysis component, any number of three activities can occur. Depending on the rules, the output data of the analysis can be re-sent to the database, a notification can be sent through an external interface via the Notification component, and/or an alarm can be displayed on the Client Application for the user.
The behavioural analysis demonstrates that the Data Analysis component is one of the more active components in the system and as it is both user and rule-driven, it is also subject to a higher amount of concurrency than other user-driven components. Rules can be added in to the Data Analysis component by the user, which then has to be stored in the database. While this is occuring, the Data Analysis component also has to continue it's automated processing of raw and derived input data based on the pre-defined system logic. This processing results in the triggering of one or more other processes that interact with the Data Storage, Notification and Client Application components. The parallel processing that needs to occur and the processing load would suggest this component will need to be replicated to maintain performance. Notably, the Data Analysis component can call Notification and the Client Application asynchronously so it can simultaneously call the Data Storage component to retrieve or store data. The call to Data Storage is synchronous so it can implement the necessary controls around data concurrency and acknowledge when data has been successfully extracted or loaded.
Monitoring
MonitorSystemStatus: This use case demonstrates how the Monitoring component calls the Data Sources and Data Storage component to modify internal data (sensor configuration or data records) and how the Data Sources and Data Storage components can notify the Monitoring component of urgent events via the callback method. When an urgent event is identified, the user is notified as described in the MonitorSystemNotify use case.
MonitorSystemNotify: This use case demonstrates how the Monitoring component will notify the user in the case of an urgent event. This is conducted through a callback that was set up when the user logs in to the Monitoring console.
The behavioural analysis demonstrates that the Monitoring component is subject to concurrency in a similar manner to the Data Analysis. It can be called by the Client Application, Data Sources and Data Storage to receive user input or notification of urgent events. In turn, it calls the Data Sources and Data Storage to modify internal data or poll for their status and calls the Client Application to notify the user of urgent events. As with other user-driven components, there is also the case of multiple Client Application instances. While the component behaviour demonstrates a significant amount of concurrency that needs to be addressed, it's important to note that the Monitoring component supports Administrative functions (as defined in its responsibilities). Subsequently, it can be assumed that the accesses and load on the component will be minimal during normal operation. The interaction between the Monitoring component and Data Sources / Data Storage also reduces this concern as the number of concurrent calls will be limited to the number of instances of those respective components.
Data Storage
As identified in the use case maps, the Data Storage is the component in the system with the most concurrent concerns as it deals with simultaneous calls from all the major components in the system. For this reason, all calls to the Data Storage component (except status polling from the Monitoring component) are deemed to be synchronous to minimise the potential risk of deadlocking through concurrent loads of data. The analysis demonstrates that this component is one of the most critical in the system, which would lend itself to replication and load-balancing to maintain availability and performance.
Deployment View
Client Application
The Client Application is replicated across users machines in the form of thick clients. It is also replicated across HTTPS servers in the form of a web application. For this reason, in the deployment view, it has been represented as accessing the system through an external interface.
Authentication Server
For security and performance reasons, the authentication server will sit on its own server node. Although from a users point of view it represents a single point of failure, the critical non-user processes of the system (data input, analysis and notification) can continue to operate in the event of the Authentication Server failing. It is for this reason that the Authentication Server has not been replicated in the diagram, however, it is reasonable to assume that a system of this size and nature will allow for the appropriate redundancy measures to ensure that downtime is kept to a minimum.
Application Server
Reporting, Spatialisation and Maintenance & Monitoring will all sit on one server node. Although Maintenance & Monitoring is a real time component, the amount of processing needed will not be large enough to impact on the Reporting, and Spatialisation components. These components have been grouped together as they are all user servicing. Thus, for the same reasons as the Authentication Server, the Application Server will has not been replicated in the diagram, however the same assumptions about redundancy and downtime apply.
Analysis Server
The data analysis component will service ad-hoc user requests. It also performs live and scheduled analysis of the incoming data for the purpose of notification and reporting. It has been placed on a separate server node and replicated to ensure the continuation of application critical processing and because the load may be balanced across multiple instances for performance reasons.
Data Sources
This component represents another entry point into the system. As such security is an issue of high importance. Placing this component on a separate server node will aid in securing the entry point. This component will be receiving data from many data sources resulting in large volumes of transactions. Placing it on a separate server node will also assist performance and enable replication that reflects it's distributed nature and will provide fail-over redundancy that will ensure the availability of the service.
Database Server
The database is an off-the-shelf subsystem and will therefore be placed on its own server node. This will ensure maintenance and configuration of the environment can be performed in isolation. Because the database is a system critical component, it will be implemented with fail-over replication to ensure reliability and can be spread across multiple instances to improve performance.
Contextual Factors
The contextual factors affecting the execution architecture are likely to surround the way the system is deployed. We have demonstrated a higher priority for system-critical tasks than we have for user-critical tasks. In the face of the user base, this may be a difficult differentiation to make. Differing user priorities are likely to have an impact on the Execution Architecture approach in this regard as the user may favour the availability of their user experience over other system qualities that we have determined from our system analysis to be more critical.
The nature of the calls between components should provide a responsive user experience that also addresses the other key system quality attributes. This is supported by the behavioural analysis and demonstrated in the Concurrency and Deployment views.
Implementation Architecture
Implementation View
The implementation view of the architecture has been modelled from the concurrency and deployment views of the execution architecture. Software technologies have been selected and applied to facilitate communications and provide the functionality that is required by the system. The selection of software components is detailed in the Component Analysis section below.
Component Analysis
Java has been selected as the development language of choice with JRE 1.5 as the runtime environment. Java enables the software to run on multiple platforms. It has extensive documentation, libraries and support available and the development skillset is easily attainable. JDBC also supports numerous different database options and provides a robust interface for the data.
Client Application
The Client Application, both thick and web clients, will be developed with the Java programming language. The graphical user interface will be implemented using the Java SWT (Swing) libraries. SWT was chosen over AWT because it is implemented independently of the windowing environment, allowing the look a feel to be consistent over different platforms. It also provides functionality that will enable development processes to be more efficient.
Authentication Layer
Authentication is to be implemented at the network level using the Kerberos protocol. It allows software agents communicating over a network to verify the identity of other agents using 'tickets' and will be used to enforce user level security and manage user access to services and data. This was chosen for authentication due it's ability to abstract itself and act as an authentication layer by servicing the authentication requests and then notifying the services whether the user is authenticated or not.
Notification and Data Analysis
Notification and Data Analysis components will be implemented as separate Java processes. This is due to the availability of java libraries that will assist with the mathematical and statistical processing of the data, and the ability to integrate with external notification services that have java APIs.
Spatialisation, Reporting and Maintenance & Monitoring
Spatialisation, Reporting and Maintenance & Monitoring components will also be implemented as separate Java processes. Spatialisation rendering can be conducted by parsing the coordinate data through JSP/JSTL to KML which is the Google Earth underlying communication format. Reporting is able to use Java Reporting tools such as JasperReports or iReport, while Maintenance and Monitoring can be implemented through a simple heartbeat process.
Data Sources
The Data Sources component will also be implemented as Java processes. Java will provide the capability to receiving many different types of data and transform it into the format required by the data storage component.
Data Storage
The system will have to deal with large amounts of data and data transactions. To ensure performance and data reliability, a proven commercial database is needed. Oracle has been deemed the best candidate for the relational databases. The Data Storage component can communicate with Oracle database with the JDBC API supplied with Java. The component has been implemented as a wrapper around the database to provide more control around the communications with the database. This is to address issues of concurrency and potential problems with the components directly accessing the database via JDBC.
Contextual Factors
There are a number of contextual factors that we have identified that are likely to affect ongoing development of the Implementation Architecture.
Cost constraints are a possible limiting factor as the system components have been distributed across a number of server nodes. Depending on the size of the budget, this may limit the ability for the system to meet its system qualities.
Another factor that is likely to affect this architecture is the distributed nature of the system. The interfaces between system components may require added complexity depending on where they will be located. This may require additional firewalling or authentication to maintain the security of the communication between components.
Future Issues
Executable Prototype
1. The prototype is not of a scale that would enable the use of kerberos as proposed in the implementation architecture. Consequently, the authentication solution will be modelled on the Conceptual Architecture and is likely to use a java class to imitate the runtime behaviour of the Authentication component.
2. The Reporting and Spatialisation components in the full solution will be quite complex and subsequently, the prototype will not be fully featured. The components in the prototype will provide feedback to the user interface that will simulate the typical behaviour of the components in real-world scenarios.
Risks and Concerns
1. The loss of personnel within our team is a significant risk. One of our project team members, will be leaving mid way through the delivery of the second milestone, and this will obviously have an impact on our ability to deliver.
Architectural Design Critique
The development of an executable prototype enabled us to test various aspects of the architectural design and allowed us to identify its strengths and weaknesses. This enabled us to further revise the design so that the architectural qualities were maintained but any respective implementation difficulties were resolved.
Client Application
The design of how the Client Application module would interact with the other components was a strong aspect of the design. There was added complexity in implementing a callback from the Client Application to the Data Analysis and Monitoring components but once implemented, this proved to be an effective means for updating the UI across multiple instances. The authentication aspects of the design enhanced the security of the system which served to meet the architectural qualities identified through the narratives.
Database Server
An earlier implementation view had the Reporting, Spatialisation, and Data Analysis communicating directly with the database via JDBC. When we commenced development of the prototype, this highlighted that the design of the interaction with the database would result in duplication of code across a number of objects. There was a similar concern with how the Maintenance and Monitoring component would determine if the server was functioning and the database on that server was functioning. This resulted in a revision of our architectural design to create a Data Storage component in Java, that would serve the requests for data and uptime information. This removed the duplication of code and centralised the responsibility for data access which also enabled better control around concurrency concerns. The load on the database and amount of concurrent activity was perceived to be quite high in the architectural behavioural analysis. This proved to be the case in the prototype as well, so the need for replication and load-balancing to improve performance (as demonstrated in the deployment view) has been justified.
Application Server
The Reporting, Spatialisation and Maintenance and Monitoring components were successfully tested through the prototype. The load on these components is minimal compared to the Data Storage and Data Analysis components so their deployment on to a seperate server and the distinctions made in the architectural behavioural analysis was justified. Once the issues with access to the data were resolved, the efficiency of how these components serviced requests also increased. Spatialisation was not fully implemented in the prototype, but it mirrored the design of the Reporting component which demonstrated that the data could be retrieved from the database and presented to the UI in an efficient manner to meet the performance needs of the system from the user's perspective.
Data Analysis
The implementation of the Data Analysis component was minimal in the executable prototype, however, it was successfully able to test the main functionality of the component. In an earlier version of the execution and implementation architectures, the Data Analysis was to make a synchronous call to Data Storage to retrieve the data for analysis. In effect, the data analysis would need the data from the Data Storage component as it was received. The call was reversed to enable the Data Storage to call the Data Analysis to process newly received data. However, this prevented the Data Analysis rules and derived data from being stored in the database and the retrieval of historical data. The call was changed to a callback that was initiated from the Data Analysis end so the communication could occur bidirectionally but would be controlled by the Data Analysis component. This proved to more effectively meet the requirements of the system as data was able to be analysed as it was sourced and then processed back into the database as derived data.
Communications
The use of RMI proved to be an effective means of setting up communication between the different server processes. Callbacks were more complex to implement using this technology but once implemented, it simplified the process of calling the other servers. As the system was anticipated to be highly distributed, this proved to be a sound architectural decision from an implementation point of view.
Conclusion
Development of the executable prototype highlighted numerous aspects of the design that served to identify weaknesses in the design of the back-end components. Revision of the design enabled us to address these weaknesses and in doing so, make the system more robust, improve performance and ensure that it meets the requirements of the system that were determined through the system narratives and architectural analysis.
Instructor Comments
Reasonable set of stakeholders and narratives. Great set of contextual factors. But where are your usage narratives? (Oh, are they in the Customer Needs section?) I like this one - "Lt. Pete Mitchell"! and "Frederik Christensen" is well written.
You don't need the section entitled "Requirements". Note that "quality attributes" ARE "non-functional requirements".
Good to see you have an initial conceptual architecture diagram. Looks quite reasonable, except for the Data Repository and Human-Machine Interface components. On the Conceptual Architecture, it is better to distinguish the different grouping s of data as separate components and the different kinds of user activity as separate components to assist the analysis. Decisions about whether the data is stored in a central repository is better left to the Execution Architecture. Lian 2nd April
Milestone 1 Feedback
Excellent quality work! I am very impressed with your analysis and design work. You have interpreted the scope and function of the system in quite a formidable way. Here are some comments:
- Excellent stakeholder and usage narratives, well-informed by current, real-world conditions. I have popped a couple on the Exemplar Student Work page.
- Good choice of quality attributes for this system. Interesting approach to writing your narratives - almost like a test scenario, but somewhat off the mark. You need to tweak them to be more prescriptive in terms of measurable requirements on the security and performance aspects, and less solution-oriented. As they stand, they are a mish-mash of stakeholder concerns, architectural solutions and situations of use. Ask yourselves the question, What is the architectural response to stakeholder needs? Then make sure you separate out the needs related to quality attributes into these narratives. The architectural response is what you are designing in the three views.
- Good refinement of Conceptual Arch. Excellent final CA; good separation of concerns and very well-defined component responsibilities.
- Excellent presentation of UCMs with explanation. Don't forget to include lifecycle events next milestone.
- Excellent Execution Arch. and a deployment view, supported with thorough reasoning! Just wondering about your use of asynchronous calls. You may need to add an asynchronous call on the other end of the connection between Monitoring and Client Applic. components, for example. Great to see UCMs here as well. Although they may be more useful for reasoning about the architecture if you combine a few traces on the one diagram that may then show up possible concurrency issues.
- Good implementation architecture, predominantly Java-based. You may like to consider the technology resources available in the lab as a constraint.
Lian 27th April
