allucanget/calminer-docs
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initialize project documentation

Browse Source 
Add architecture documentation and functional requirements for Calminer project

- Created Building Block View (05_building_block_view.md) detailing system architecture and component interactions.
- Developed Runtime View (06_runtime_view.md) outlining key user scenarios and interactions within the system.
- Established Deployment View (07_deployment_view.md) describing the infrastructure and mapping of building blocks to deployment components.
- Added README.md for architecture documentation structure.
- Introduced functional requirements (FR-001 to FR-010) covering scenario management, data import/export, reporting, user management, and collaboration features.
- Included templates for documenting requirements to ensure consistency across the project.
This commit is contained in:
zwitschi
2025-11-08 19:49:07 +01:00
commit ad56c3c610
23 changed files with 2203 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

346
architecture/06_runtime_view.md Normal file
View File

@@ -0,0 +1,346 @@
# Runtime View
## Table of Contents
- [Runtime View](#runtime-view)
- [Table of Contents](#table-of-contents)
- [Login Process](#login-process)
- [Project Creation](#project-creation)
- [Mining Method Selection](#mining-method-selection)
- [Scenario Creation](#scenario-creation)
- [Default Business Scenario](#default-business-scenario)
- [Parameter Configuration](#parameter-configuration)
- [Basic Accounting Setup](#basic-accounting-setup)
- [Currency Setup](#currency-setup)
- [Report Generation](#report-generation)
- [User Management](#user-management)
<!--
The runtime view describes concrete behavior and interactions of the system's building blocks in form of scenarios from the following areas:
- important use cases or features: how do building blocks execute them?
- interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?
- operation and administration: launch, start-up, stop
- error and exception scenarios
Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their _architectural relevance_. It is _not_ important to describe a large number of scenarios. You should rather document a representative selection.
_Motivation:_ You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).
_Form:_ There are many notations for describing scenarios, e.g. numbered list of steps (in natural language), activity diagrams or flow charts, sequence diagrams, BPMN or EPCs (event process chains), state machines, ...
## Runtime Scenario 1
- _<insert runtime diagram or textual description of the scenario>_
- _<insert description of the notable aspects of the interactions between the building block instances depicted in this diagram.>_
-->
## Login Process
1. The user navigates to the login page.
2. The user enters their credentials (username and password).
3. The API Layer receives the login request and forwards it to the Authentication Service in the Service Layer.
4. The Authentication Service validates the credentials against the user data stored in the Database System via the Data Access Layer.
5. If the credentials are valid, the Authentication Service generates a session token and sends it back to the API Layer.
6. The API Layer returns the session token to the user, granting access to the system.
```mermaid
sequenceDiagram
autonumber
participant U as User
participant API as API Layer
participant AS as Authentication Service
participant DB as Database System
U->>API: Submit login credentials
API->>AS: Forward credentials
AS->>DB: Validate credentials
DB-->>AS: Return validation result
alt Valid Credentials
AS->>API: Generate session token
API->>U: Return session token
else Invalid Credentials
AS->>API: Return error message
API->>U: Return error message
end
```
## Project Creation
### Mining Method Selection
1. The user selects the option to create a new project.
2. The API Layer presents the user with a list of available mining methods.
3. The user selects a mining method from the list.
4. The API Layer forwards the selection to the Service Layer.
5. The Service Layer retrieves the details of the selected mining method from the Data Access Layer.
6. The Data Access Layer queries the Database System for the mining method information.
7. The Database System returns the mining method details to the Data Access Layer.
8. The Data Access Layer sends the mining method details back to the Service Layer.
9. The Service Layer returns the mining method details to the API Layer.
10. The API Layer displays the mining method details to the user for confirmation.
```mermaid
sequenceDiagram
autonumber
participant U as User
participant API as API Layer
participant S as Service Layer
participant D as Data Access Layer
U->>API: Select mining method
API->>S: Forward selection
S->>D: Retrieve available methods
D-->>S: Return methods
S-->>API: Return methods
API->>U: Display methods
U->>API: Confirm selection
API->>S: Forward confirmation
S->>D: Store selected method
D-->>S: Acknowledge storage
```
## Scenario Creation
### Default Business Scenario
1. The user selects the option to create a default business scenario.
2. The API Layer receives the request and forwards it to the Service Layer.
3. The Service Layer initiates the creation of a default scenario in the Data Access Layer.
4. The Data Access Layer creates the default scenario in the Database System.
5. The Database System acknowledges the creation of the scenario to the Data Access Layer.
6. The Data Access Layer confirms the scenario creation to the Service Layer.
7. The Service Layer notifies the API Layer of the successful scenario creation.
8. The API Layer informs the user that the default business scenario has been successfully created.
```mermaid
sequenceDiagram
autonumber
participant U as User
participant API as API Layer
participant S as Service Layer
participant D as Data Access Layer
U->>API: Request default scenario creation
API->>S: Forward request
S->>D: Create default scenario
D-->>S: Acknowledge creation
S-->>API: Confirm scenario creation
API->>U: Notify user of successful creation
```
## Parameter Configuration
1. The user navigates to the parameter configuration section.
2. The API Layer retrieves the current configuration parameters from the Service Layer.
3. The Service Layer requests the parameters from the Data Access Layer.
4. The Data Access Layer queries the Database System for the configuration parameters.
5. The Database System returns the configuration parameters to the Data Access Layer.
6. The Data Access Layer sends the parameters back to the Service Layer.
7. The Service Layer forwards the parameters to the API Layer.
8. The API Layer displays the current configuration parameters to the user.
9. The user modifies the desired parameters and submits the changes.
10. The API Layer forwards the updated parameters to the Service Layer.
11. The Service Layer updates the parameters in the Data Access Layer.
12. The Data Access Layer saves the updated parameters in the Database System.
13. The Database System acknowledges the update to the Data Access Layer.
14. The Data Access Layer confirms the update to the Service Layer.
15. The Service Layer notifies the API Layer of the successful parameter update.
16. The API Layer informs the user that the parameters have been successfully updated.
```mermaid
sequenceDiagram
autonumber
participant U as User
participant API as API Layer
participant S as Service Layer
participant D as Data Access Layer
participant DB as Database System
U->>API: Request current parameters
API->>S: Forward request
S->>D: Retrieve parameters
D->>DB: Query parameters
DB-->>D: Return parameters
D-->>S: Send parameters
S-->>API: Forward parameters
API->>U: Display parameters
U->>API: Submit updated parameters
API->>S: Forward updates
S->>D: Update parameters
D->>DB: Save updated parameters
DB-->>D: Acknowledge update
D-->>S: Confirm update
S-->>API: Notify successful update
API->>U: Inform user of success
```
## Basic Accounting Setup
1. The user accesses the basic accounting setup section.
2. The API Layer retrieves the current accounting settings from the Service Layer.
3. The Service Layer requests the settings from the Data Access Layer.
4. The Data Access Layer queries the Database System for the accounting settings.
5. The Database System returns the accounting settings to the Data Access Layer.
6. The Data Access Layer sends the settings back to the Service Layer.
7. The Service Layer forwards the settings to the API Layer.
8. The API Layer displays the current accounting settings to the user.
9. The user modifies the accounting settings and submits the changes.
10. The API Layer forwards the updated settings to the Service Layer.
11. The Service Layer updates the settings in the Data Access Layer.
12. The Data Access Layer saves the updated settings in the Database System.
13. The Database System acknowledges the update to the Data Access Layer.
14. The Data Access Layer confirms the update to the Service Layer.
15. The Service Layer notifies the API Layer of the successful accounting settings update.
16. The API Layer informs the user that the accounting settings have been successfully updated.
```mermaid
sequenceDiagram
autonumber
participant U as User
participant API as API Layer
participant S as Service Layer
participant D as Data Access Layer
participant DB as Database System
U->>API: Request current accounting settings
API->>S: Forward request
S->>D: Retrieve settings
D->>DB: Query settings
DB-->>D: Return settings
D-->>S: Send settings
S-->>API: Forward settings
API->>U: Display settings
U->>API: Submit updated settings
API->>S: Forward updates
S->>D: Update settings
D->>DB: Save updated settings
DB-->>D: Acknowledge update
D-->>S: Confirm update
S-->>API: Notify successful update
API->>U: Inform user of success
```
## Currency Setup
1. The user navigates to the currency setup section.
2. The API Layer retrieves the current currency settings from the Service Layer.
3. The Service Layer requests the settings from the Data Access Layer.
4. The Data Access Layer queries the Database System for the currency settings.
5. The Database System returns the currency settings to the Data Access Layer.
6. The Data Access Layer sends the settings back to the Service Layer.
7. The Service Layer forwards the settings to the API Layer.
8. The API Layer displays the current currency settings to the user.
9. The user modifies the currency settings and submits the changes.
10. The API Layer forwards the updated settings to the Service Layer.
11. The Service Layer updates the settings in the Data Access Layer.
12. The Data Access Layer saves the updated settings in the Database System.
13. The Database System acknowledges the update to the Data Access Layer.
14. The Data Access Layer confirms the update to the Service Layer.
15. The Service Layer notifies the API Layer of the successful currency settings update.
16. The API Layer informs the user that the currency settings have been successfully updated.
```mermaid
sequenceDiagram
autonumber
participant U as User
participant API as API Layer
participant S as Service Layer
participant D as Data Access Layer
participant DB as Database System
U->>API: Request current currency settings
API->>S: Forward request
S->>D: Retrieve settings
D->>DB: Query settings
DB-->>D: Return settings
D-->>S: Send settings
S-->>API: Forward settings
API->>U: Display settings
U->>API: Submit updated settings
API->>S: Forward updates
S->>D: Update settings
D->>DB: Save updated settings
DB-->>D: Acknowledge update
D-->>S: Confirm update
S-->>API: Notify successful update
API->>U: Inform user of success
```
## Report Generation
1. The user selects the option to generate a report.
2. The API Layer receives the report generation request and forwards it to the Reporting Module in the Service Layer.
3. The Reporting Module retrieves the necessary data from the Data Access Layer.
4. The Data Access Layer queries the Database System for the required data.
5. The Database System returns the data to the Data Access Layer.
6. The Data Access Layer sends the data back to the Reporting Module.
7. The Reporting Module processes the data and generates the report.
8. The Reporting Module returns the generated report to the API Layer.
9. The API Layer delivers the report to the user for download or viewing.
```mermaid
sequenceDiagram
autonumber
participant U as User
participant API as API Layer
participant S as Service Layer
participant D as Data Access Layer
participant DB as Database System
U->>API: Request report generation
API->>S: Forward request
S->>D: Retrieve data for report
D->>DB: Query data
DB-->>D: Return data
D-->>S: Send data
S-->>API: Forward data
API->>U: Display report
```
## User Management
1. The user navigates to the user management section.
2. The API Layer retrieves the list of users from the Service Layer.
3. The Service Layer requests the user list from the Data Access Layer.
4. The Data Access Layer queries the Database System for the user information.
5. The Database System returns the user information to the Data Access Layer.
6. The Data Access Layer sends the user information back to the Service Layer.
7. The Service Layer forwards the user information to the API Layer.
8. The API Layer displays the list of users to the administrator.
9. The administrator can add, modify, or delete users as needed.
10. The API Layer forwards any user management actions to the Service Layer.
11. The Service Layer processes the actions in the Data Access Layer.
12. The Data Access Layer updates the user information in the Database System.
13. The Database System acknowledges the updates to the Data Access Layer.
14. The Data Access Layer confirms the updates to the Service Layer.
15. The Service Layer notifies the API Layer of the successful user management actions.
16. The API Layer informs the administrator of the successful user management operations.
```mermaid
sequenceDiagram
autonumber
participant U as User
participant API as API Layer
participant S as Service Layer
participant D as Data Access Layer
participant DB as Database System
U->>API: Request user information
API->>S: Forward request
S->>D: Retrieve user data
D->>DB: Query user data
DB-->>D: Return user data
D-->>S: Send user data
S-->>API: Forward user data
API->>U: Display user information
U->>API: Submit user management actions
API->>S: Forward actions
S->>D: Process user management actions
D->>DB: Update user information
DB-->>D: Acknowledge updates
D-->>S: Confirm updates
S-->>API: Notify successful actions
API->>U: Inform user of success
```