Skip to content

Overall Architecture and Class Diagrams

Jump to bottom
Gabriel Dubois edited this page Nov 9, 2024 · 12 revisions

Show us the layers in your system and your domain classes. You can also include individual class diagrams in your stories on GitHub Put in your highlevel arch diagram (ie the major components)

For all existing arch diagrams, please only describe changes in your arch

Software Architecture Proposition

Abstract

The proposed wildfire visualization platform will be built using a Frontend-Backend split architecture to provide scalable and real-time data visualization for climate and data scientists. The frontend (MVC) will be developed using Angular with open-source mapping tools (TBD) to display interactive maps and visualize data. The backend will be developed using Spring Boot with a TBD database for local data storage. This enables the integration of various data sources such as wildfire, meteorological, and geographic data.

The software architecture outlined in this document is a proposed solution and is currently under review by the stakeholders. The details, including the tech stack and architecture, will be finalized after further clarifications.

1. Introduction

This report outlines the proposed software architecture for the wildfire visualization platform project. The system aims to visualize historical wildfire data, with plans to integrate multiple datasets for future simulations and communication protocols across jurisdictions. This platform will be built using a Frontend-Backend split architecture that follows the MVC (Model-View-Controller) pattern for the frontend and REST API architecture for the backend.

Architecture Overview

The following diagram provides a visual representation of the system's overall architecture, showcasing the interaction between the Presentation Layer, Business Layer, and Data Layer. This architecture follows a standard n-tier approach, with each layer having distinct responsibilities and interacting through well-defined interfaces.

  • Presentation Layer: Responsible for rendering the UI and handling user interactions.
  • Business Layer: Manages business logic, data processing, and services.
  • Data Layer: Stores and provides access to geospatial and application data.

Below is the architecture diagram that illustrates these layers and the flow of data between them:

image

2. Application Workflow Diagrams

The following diagrams represent the key workflows of the wildfire visualization platform. These flowcharts outline how the application is launched, the process of checking configurations, and the steps involved in loading the application with datasets for visualization. Understanding these workflows helps provide clarity on the sequence of operations and the system's behavior during critical functions.

  1. Launch Application: Illustrates the process of initializing and starting the application.
  1. Application Configuration Check: Describes how the system checks its configurations to ensure all necessary settings are in place before proceeding.
  1. Dataset Configuration Check: Explains the process of validating the dataset configurations for visualization.
  1. Load Application: Details how the application loads datasets and prepares the interface for user interaction.

3. Domain Model Diagram

4. Key Architecture Components

4.1 Frontend-Backend Interaction

The frontend (built with Angular) will communicate with the backend (Spring Boot) via RESTful APIs. The frontend will send HTTP requests to the backend to retrieve or process data, and the backend will return data in JSON format.

Example Interaction Flow:

  1. The user selects a region on the interactive map and requests wildfire data for a specific time period.
  2. The frontend sends a GET request to the backend’s /api/wildfires endpoint with necessary parameters (e.g., region, date).
  3. The backend processes the request by querying the local database and, if necessary, merging the results with external API data (e.g., weather data).
  4. The backend returns the processed data in JSON format.
  5. The frontend renders the data on the map, displaying wildfire events, weather conditions, and other relevant information.

4.2 Key Frontend Components:

  • Map Component: Displays interactive maps with wildfire and weather data.
  • Data Visualization Component: Renders graphs, charts, and filters for analyzing the data.
  • User Interaction Component: Allows users to filter and interact with the data (e.g., zoom, filter by time).

4.3 Key Backend Components:

  • Controller Layer: Defines the API endpoints (e.g., /api/wildfires, /api/weather).
  • Service Layer: Implements business logic, including data fusion, processing, and validation.
  • Repository Layer: Manages database queries and local data storage.

4.4 Domain Diagram:

image

5. Data Flow

Data Fusion

The backend will be responsible for merging multiple datasets (wildfire, geographic, meteorological) into a coherent dataset for visualization.

Caching and Performance Optimization

To improve performance, the backend will implement caching mechanisms to store frequently accessed data, reducing the load on external APIs.

6. Future Considerations

This architecture is flexible to future enhancements, including:

  • Simulation of Wildfire Data: For training and predictive modeling.
  • Communication Protocols: To integrate with emergency response teams and government jurisdictions.

7. Conclusion

This software architecture proposition provides a robust, scalable, and maintainable foundation for building the wildfire visualization platform. By leveraging modern frameworks like Angular and Spring Boot, combined with best practices in CI/CD and containerization, the platform will meet current visualization needs and be adaptable to future features.

Note: Class diagrams and other specific components will be added soon, once the final work package is received from the stakeholders.

Clone this wiki locally