Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doc/dei 249 architecture doc #132

Merged
merged 7 commits into from
Nov 21, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions docs/api/application_overview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# Application overview

The application is setup using a layered architecture (see [link](architecture.md)).

To create the application you will need to create these three components: logger, data-access layer and model builder (see [main.py](https://github.com/Deltares/D-EcoImpact/blob/main/main.py)).

```python
# configure logger and data-access layer
logger: ILogger = LoggerFactory.create_logger()
da_layer: IDataAccessLayer = DataAccessLayer(logger)
model_builder = ModelBuilder(da_layer, logger)

# create and run application
application = Application(logger, da_layer, model_builder)
application.run(path)
HiddeElzinga marked this conversation as resolved.
Show resolved Hide resolved
```

The logger provides logging functionality to the application, like reporting errors, warnings, user information and debug messages and is created using a factory pattern.
The DataAccessLayer gives the application access to the file system and allows for parsing of input and output.
The modelbuilder uses the builder pattern to create a model from a IModelData data object (created by the data-access layer).

## Running the application

After constructing the application, the application should be ready to run.
During the running of the application the following steps are executed.

![Application execution](../assets/images/Application_run.svg)

The application starts by reading the `ModelData` object from the input files via the `IDataAccessLayer`.
This gets passed to the `IModelBuilder`to convert the `ModelData` into a `IModel` that can be run.
The static `ModelRunner` will then be called to run the created `IModel` and do the real computation.

## Model run

When the `ModelRunner` `run_model` command is executed, the following steps are performed (using `RuleBasedModel` and `ICellBasedRule` as an example).

![Model execution](../assets/images/Model_run.svg)

The `ModelRunner` starts by validating the model (`RuleBasedModel` in this example).
The `RuleBasedModel` delegates the validation of the set of rules that it is composed with, calling the validate on every rule (`ICellBasedRule` in this example).
After the model is successfully validated, the initialize of the model is called. In case of the `RuleBasedModel`, this creates an instance of the `RuleProcessor` and initializes it.

The `ModelRunner` continues by calling the `execute` method on the `RuleBasedModel` that in turn calls `process_rules` on the `RuleBasedProcessor`.
This method loops over all the specified rules and executes the rules based on their type. So for example, with the `ICellBasedRule` the `RuleBasedProcessor` will loop over all the cells and call the `ICellBasedRule` execute method for every cell.

When the model execute has successfully finished with the execute step, the `finalize` method will be called on the model to clean up all resources.
HiddeElzinga marked this conversation as resolved.
Show resolved Hide resolved

## Class diagram

![Overview class diagram](../assets/images/Overview.svg)
22 changes: 22 additions & 0 deletions docs/api/architecture.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Main Architecture (Layered Application)
HiddeElzinga marked this conversation as resolved.
Show resolved Hide resolved

A layered application architecture is a design approach that organizes the components of a software system into distinct layers, each with specific responsibilities.
This separation of concerns enhances maintainability, scalability, and testability. The main layers typically include:

![Layered Architecture](../assets/images/layered-architecture.svg)

*Figure 1: A layered architecture with Business Logic, and Data Access layers.*

## 1. Business Logic Layer
The Business Logic Layer (BLL) contains the core functionality and business rules of the application.
It processes data received from the Data Access Layer and applies business rules.
This layer ensures that the business rules are consistently applied across the application.

## 2. Data Access Layer
The Data Access Layer (DAL) is responsible for interacting with the data storage system.
It provides an abstraction over the data sources, allowing the Business Logic Layer to access data without needing to know the details of the data storage.

## 3. Cross-cutting Concerns
Crosscutting concerns are aspects of the application that affect multiple layers and components (like logging).
By centralizing these concerns, the application can maintain consistency and reduce redundancy.

110 changes: 110 additions & 0 deletions docs/assets/images/Application_run.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Loading