1. Introduction
1.1. Overall Description
You can find the description about the project in the introduction of our system requirements specification document.
See article: SRS Introduction
1.2. Purpose of this document
The purpose of this Software Design Description is to explain and justify the design choices that we have made during this project and the development of our product. The explaination for these design choices can be given to future programmers, so that they may have an idea of why some products have been designed in a certain way.
1.3. Definitions, acronyms, and abbreviations
|
Term |
Description |
|---|---|
| API | Application Programming Interface, a piece of software with a distinct function, for example being a link between a database and a front-end application. |
| Gauge chart | A data visualization type used to display a single value of data in a quantitative way. |
table 1: detailed description of words, acronyms and abbreviations
2. Architectural Overview
This architectural overview is an overview that shows the building blocks of our project. It shows how we intend to build this project, besides that it helps the development team get a shared view.
figure 1: Architectural overview
Here you can see a description of what every building block of our project means. This makes the architectural overview better understandable.
| DNS | The DNS also known as Domain Name System is Regterschot's website. |
|---|---|
| User Browser | Browser that's used by a user to access the website. |
| CDN | Content Delivery Network is a service that distributes user requests to increase performance. |
| Load Balancer | Load balancer is a REST-API that is used to distribute incoming traffic across virtual machines. |
| Webapp Servers | This is the web application that we are making as the group Smalltalk. |
| Database | The database is the place where we store our data. |
| View Dashboards | To view a dashboard is an end goal so the user can see the relevant graphs. |
| Broker | The broker is used to receive live data from the sensors on the race car |
| Services | Services are the dependencies that our web application uses. |
table 2: glossary of architectural overview
3. Detailed Design Description
3.1. Deployment Diagram
figure 2: deployment diagram
3.2. Design Decisions related to Deployment Diagram
| BrokerServer | A brokerserver is a server on which one or more brokers reside. In our case this will be just one broker which sends the data from the racecar to our website. The brokerservice will allow us to create large data-streams, sending data from one point to another. This way we can show dynamic graphs on the website with the actual data without using a database. This way the data will be arriving on the website much quicker, which definitely is important in our case. We connect to the broker over a websocket connection directly in the front end code. This way it will be as fast and reliable as possible. It will go through the least amount of code and layers that is possible. |
|---|---|
| DatabaseServer | The database will contain all data that is not required to be updated to show real-time data. This will thus include all sensor-data of past races, as well as all data required for logging in and creating race-views. The database system we use is MySQL, because of its accessibility and relative ease to use. MySQL runs on a databaseServer, that is connected to the Java Application API with the use of a JDBC (Java Database Connectivity) Database Connection. |
| ApplicationServer | The ApplicationServer will contain the API itself. This API will use Jakarta EE and Wildfly 25.0, which allows us to run an API with ease in a web environment. Using the REST API, this Java Application will connect to a webserver and deploy its .war artifact there. |
| Webserver | The webserver is the link between user and API. That is the part of our API that the user can interact with. This webserver could also be described as a simple website. |
|
User PC |
The user PC is the eventual device on which the API and webpage will run. This is the user end of our application. |
table 3: glossary of deployment diagram
3.3. Class Diagram
We made three different class diagrams to make the visual side of our program more understandable. The first one is for all our back-end code. The second one shows our data access object and data transfer object diagram and the last one is our front-end class diagram.
3.3.1. Class Diagram Backend
figure 3: class diagram back-end
3.3.2. Class Diagram DAO-DTO-generalisation
figure 4: class diagram DAO and DTO
For every resource we have made, there's a few extra classes that we have generalised here. The DTO classes are being used to model the data in a single format for easier use, this way we only need to edit data in one place. In the DAO classes we put all the logic that is needed to get the data from the database. Here we will process the data from a query result into the DTO and pass it back to the services. This way we create a layer pattern in our application which gives better readability and clarity for the next team that wants to alter our code after us.
3.3.3. Class Diagram Front-end
figure 5: class diagram front-end
4. List of Resources
- Millington, S. (2022, January 12). Hashing a Password in Java. Baeldung. https://www.baeldung.com/java-password-hashing
- Supertokens Team. (2022, March 2). Hash, salt and verify passwords - Node, Python, Go and Java. Supertokens. https://supertokens.com/blog/password-hashing-salting
| User | Edits | Comments | Last Update |
|---|---|---|---|
| Sem Gerrits | 81 | 5 | 658 days ago |
| Jasper Kooy | 54 | 10 | 655 days ago |
| Wijnand vanZyl | 31 | 4 | 655 days ago |
| Thomas Droppert | 27 | 57 | 659 days ago |
| Martin van Lijden | 20 | 7 | 661 days ago |
| Auto Mation | 12 | 0 | 732 days ago |
| Bram Bakker | 7 | 0 | 658 days ago |