Iteration 2: Design
Team Noname plans to provide Barrios Technology with a web application that gives users access to predictive modeling and forecasts based on past ISS consumables data. The application's interface will allow users to update past consumables data and view a dashboard that includes analysis of past outcomes and future predictions.
- Interactive dashboard that will include:
- A high-level overview of all current analyses and predictions
- The ability to upload updated datasets for adjusted analyses and predictions
- Detailed views of usage analysis, resupply predictions, and a detailed flight plan
- REST API that will include:
- Controller-based routing that will:
- Accept requests from the browser client
- Use request parameters to call methods on analysis and prediction models
- Coordinate data persistence through services or repositories
- Respond with either structured JSON data or a hypermedia representation of the data's state
- Models that will operate on data provided by the controller via a service or repository
- Services/repositories whose only responsibility will be to provide an interface to the persistence infrastructure
- Controller-based routing that will:
- Database that will provide the ability to:
- Store, update and retrieve user-provided datasets
- Store, update and retrieve prediction and analysis results
- Ability to choose from multiple analysis methods
- Upload Barrios user data
- Retrieve stored user data
- View accuracy analysis, forecasting, and optimization with graphical charts
- Retrieve and view past analyses
- Manage users and user roles
The Barrios analytics application will follow a server/client model with a Hypermedia/REST API (i.e., server endpoints respond with HTML fragments rather than JSON. This approach should simplify the client development by restricting the application state to the server. More advanced, "single-page application" style interactivity will be achieved by using HTMX.
The server will be implemented using the emmett framework. Emmett is an HTTP server framework written in Python that will allow the team to organize the code in whatever form necessary without the need to adhere to a framework's choice of architecture. While this may require some additional code, we hope that the effort saved by reducing front-end complexity can be devoted to crafting the server architecture.
The server's architecture will be modeled following a mixed approach that follows aspects of model-view-controller (MVC) and some aspects of a layered approach. The controllers will be the outer or topmost layer, which will respond to HTTP messages sent to various routes as required by UI functionality. Those controllers will call methods on services to coordinate data persistence/retrieval from repositories and instantiation of and communication with models.
Models will either represent optimized, forecast, or analysis data or act as the implementation of various analytics methods. Finally, at the infrastructure level, repositories will act as interfaces to databases — implementations of which will serve to communicate with their specific database drivers — allowing the developers to accommodate different database engines, depending on the client's needs or the current needs of the development process.
Pandas, Dask, and Numpy will be used to explore, analyze and clean user data and to extract the necessary values for analysis. Services may also use these libraries to transform persisted data for modeling functions.
Domain classes are the base components of the system. Most of them, for example, User and File, represent application data and have no methods. Some, such as the Analyzer classes, only exist to run analyses of a specific type and generate various Analysis classes. The Result class represents an operation's outcome and will assist in consistent error handling across the application.
Both Analysis and Analyzer classes are interfaces to be realized by the implementations shown in the diagram.
Service classes, such as controllers, services, and repositories, will be implemented using basic dependency injection. As such, their relationships are modeled as dependencies.
