| layout | default |
|---|---|
| title | SAD |
| nav_order | 3 |
| parent | Project management |
{: .no_toc }
{: .no_toc .text-delta }
- TOC {:toc}
This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.
This SAD describes the architecture of the Live-Poll project. It presents the class structure, the use cases and the data base schema.
| Abbrevation | Description |
|---|---|
| API | Application programming interface |
| MVC | Model View Controller |
| REST | Representational state transfer |
| SDK | Software development kit |
| SRS | Software Requirements Specification |
| UC | Use Case |
| VCS | Version Control System |
| n/a | not applicable |
The following chapters contain the architectural design, goals, constraints and data views.
In order to communicate between client and server, we follow the REST principle. How this works can be seen here:
In order to be able to develop the frontend and backend independently of one another, we decided to create a REST API with a flexible interface to communicate. This also gives us the opportunity to develop other clients in addition to the Angular app that is currently under development, such as a PowerPoint plugin. To develop the REST API we use the Spring Boot framerwork. Here you can see an overview of the Spring Boot concept:
On the client side we use Angular to develop a modern single-page client application. Here you can see an overview of the Angular concept:
Each use case is individually documented. All use cases are linked in our SRS.
This section shows an overview of the classes. Due to the lack of full Kotlin support for generating class diagrams, the diagram does not show relationships between the models, controllers or services.
This image shows the current database model for our MySQL database, connected to our Spring backend:
The marked classes have been revised with the composite design pattern.
This are the current controllers:
And this are our current services:
n/a
n/a
Database ER-Diagram:
n/a
To ensure a good code quality and to avoid bugs, each pull request is automatically checked / rated by SonarQube. Furthermore at least one review is required to merge a pull request in both of our main repositories.