Detailed Design Description
Deployment Diagram
Design Decisions related to Deployment Diagram
| BrokerServer | The brokerserver will run with a brokerservice on it. This brokerservice will allow us to create large data-streams. This will in turn allow us to create dynamic graphs on our webpage without having to consult a database twenty times a second. This brokerservice is connected via a broker connection to the Java application API. |
|---|---|
| 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 it's 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 and 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 be run. This is the user end of our application. |
Class Diagram
We made three different class diagrams to make the visual side of our program better understandable. The first one is for all our back-end code, seconde one is our data acces object and data transfer object diagram and the last one is our front-end class diagram.
Class Diagram Backend
Class Diagram DAO-DTO-generalisation
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 clearity for the next team that wants to alter our code after us.
Class Diagram Frontend
With this design class diagram you can see the interactions happening between different classes of our program. The loginService makes sure it knows everything that has to do with logging in. The resource sends the requests to the controller and recieves data back from the controller.
The resource classes makes uses of the Response interface. This needs to happen, so that the user knows what went wrong.