1. Project Overview
The EPA is a U.S. federal government agency devoted to safeguarding the environment. One of the EPA's great concerns is the proliferation of cyanobacterial harmful blooms (cyanoHABs) in the nation's lakes. The following resources provide information on what cyanoHABs are and how they threaten the environment.
The TopCoder project on cyanoHABs aims to develop an algorithm that will be deployed in an Android app with mapping and data visualization capabilities. The app will inform local and federal policy makers about locations where bloom events are likely to occur, allowing them to concentrate their efforts in those areas.
2. Contest Overview
Welcome to third architecture in the series of four EPA Android App Architecture Contests. Each contest will run after the other and will be using the output of previous contest to build further. We recently concluded the development of the data management backbone for the system which will receive data from admin website. This contest will design the architecture of admin module of the system. We have a front-end prototype for admin module already in place and this contest will use that front-end to design the implementation of underlying features.
In this contest, we are looking for you to design the module architecture for admin module system of EPA Android App. We want you to use all the available information architecture in form of system architecture and application requirements specification to develop this module architecture. We will also provide access to the admin website front-end that has been already developed and which will interact with this module. There is one update required to admin website which will be done as part of this module. . Finally, we will provide recently designed data management architecture and also the corresponding assembly code if required. The admin module is responsible for uploading all data to the system, provide configuration details to back-end and display results summary from the application to the admin - details of each function is provided later.
Following is the description for each of functionality of admin module:
EPA Android App Admin Module: This module will be responsible for doing all the admin operations. This module will not be computationally intensive but will require great i/o and network performance consciousness. Please note that upload performance is the key for this module. So, please make sure to include all possible optimizations so as to make this a very efficient module.
- Please refer to Admin Use Case Diagram (page 12 in ARS) for all the use cases that needs to be implemented.
- The admin module will upload the data and store it in temporary folder. The data management module will use this data from temporary folder.
- The admin module will also interact with the back-end for sending configuration details.
- The admin module will receive prediction results and aggregate analysis results and it will be displayed in the front-end.
- We will provide you the back-end architecture (currently in review process) to provide an idea of what kind of data will be received by admin related for prediction and aggregate analysis and how it needs to be displayed. Please ask as many questions as you need for getting clear idea on this.
- Please read carefully: There is one feature which is not available in current front-end prototype. Please refer to 2.33.1 Upload Image(s) Activity > 126.96.36.199 Provide URL for bulk upload. This needs to be implemented as part of this module. The front-end will have a new text box as an option to current upload function. The admin can enter a url into this box and once the admin hits upload, the admin module will just send the url to data management module. The data management module will then fetch the data from the url. We want you to once look at data management architecture/assembly to see that this fetch from url function is properly implemented and can be synced with the current feature in admin module.3. Technology Overview
1. The Admin Website prototype is a CMS developed using Django framework 1.6.1, Python 2.7x and PIL 1.1.7.
2. We are open to use of any technology for the admin module as far as it does not limit any specific OS requirements. To match with prototype, you can use python but keep upload performance in mind. Other modules for this system are developed in Java. So, you are free to use Java also.
3. We plan to host the admin module along with the data management module on a single (same) server - ex. Amazon EC2 Server.
4. Open source software resources are welcome, but they must have third party support services available. Please ask in forum when in doubt.
5. You are allowed to use any open source DB, data storage mechanisms for storing data at various stages.
6. Please note that the developers are not allowed to use any component from TC Catalog for this contest.
4. Process Flow and Storage Considerations
- We will use two main storage modules: Temp Storage and Shared Storage.
- The admin website will put all new data in Temp store.
- The data management module will read data from this temp store and then process it. After processing completes, it moves the original data to shared store (this is not part of this module, it is already done by DMM.)
- In case admin provides url, the data management module will fetch data and put it in temp store.
Please Note: Both the process flow and storage details are just high-level suggestion from our side. Architects are welcome and encouraged to suggest and propose any changes and updates as deemed necessary in this process flow. Also, architects are allowed to use any media for data storage like DB or files, etc. Please open a discussion in forum to clarify/confirm your ideas when in doubt.
5. Resources Provided
The following resources are available for your use. You will be able to access some of them on forums after registration while others require discussion forum request for access:
1.) EPA Admin Website Prototype
2.) System Design Specification
3.) System Architecture TCUML
4.) Application Requirements Specification and Use Case TCUML
5.) Data Management Module Architecture
6.) Data Management Module Assembly
7.) Back-end Module Architecture
Please Note: In case of use case discrepancies, precedence should be considered as following: Data Management Architecture and Assembly and Back-end Architecture > ARS > System Architecture. Please follow them and if there is still confusion, please ask in forums.