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 logincontroller 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.
Database Design
This is the database setup we will use for the RegterschotRacing API. A full description of every tables usage and datatypes can be found below. All green boxes will be made by Smalltalk in order to provide a sound foundation to build an API on. The red boxes could be implemented for future expansions, but they are out of our current scope. These have been placed here as an example to provide future developers with a stepping stone.
Database Glossary
Tablenames and formats are written in italic; Columns that contain the primary key are underlined.
| Table | Column | Datatype | Null / Not Null | Comments |
|---|---|---|---|---|
| Graph | This table contains all data that is required to show a graph. It contains the sensor it is displaying the data for, and the type of graph it is. | |||
| GraphID | int | Not null | This is the unique identifier of the graph. | |
| SensorID | int | Not null | The unique identifier of the sensor that the graph is displaying the data of. | |
| Race | This table contains all information relevant to a race. | |||
| RaceID | int | Not null | The unique identifier of the race. | |
| NumberOfLaps | int | Not null | The number of rounds that the race possesses. | |
| RaceName | varchar(255) | Not null | The name of the race. | |
| Date | DATETIME | Not null | The date of the start of the race. | |
| Sensor | This table functions as collection of all sensors. | |||
| SensorID | int | Not null | The unique identifier of the sensor. | |
| SensorName | varchar(255) | Not null | The name of the sensor. | |
| Type | varchar(255) | Not null | The type of graph, can be anything from the following:
| |
Tab | This table contains all information that is relevant to a Tab. | |||
| TabID | int | Not null | The unique identifier of the tab. | |
| TabName | varchar(255) | Not null | The name of the tab. The name is set when creating a new tab in the frontend web-application. | |
| RaceID | int | Not null | The unique identifier of the race that the tab belongs to. | |
| UserID | int | Not null | The unique identifier of the user that the tab belongs to. | |
| User | This table handles all user data and other data relevant to have users that can interact with the application. | |||
| UserID | int | Not null | The unique identifier of the user. | |
| Username | varchar(255) | Not null | The unique name of a user that will be on display in the frontend web-application. | |
| Password | varchar(255) | Not null | The hashed password of the user that is needed when logging in into the web-application. | |
Design decisions related to the database
Decision 1 | Description |
|---|---|
Problem/Issue | Throwing all of the different sensors and their data into one big table will quickly create a very clumped and hard-to-read table. |
| Decision | Create a different table for every sensor and add a new table that contains all sensor IDs. |
| Alternatives | - |
| Arguments | By dividing data over multiple tables, query time can be shortened significantly and keeps all of our tables in line with the normalization principle. |
| Decision 2 | Description |
|---|---|
| Problem/issue | A driver is only driving a couple of rounds in a race, which will create quite a confusing table if thrown into a single race tables. |
| Decision | Divide the different datatypes into multiple tables: a rounds table, a race table and a driver table. Create a linking table that links all of these three tables together. |
| Alternatives | - |
| Arguments | By dividing the table into a multitude of different tables, there's three distinct tables that are in line with the normalization principle. |
| Decision 3 | Description |
|---|---|
| Problem/issue | When adding a new graph to a tab the system must know what type of graph must be drawn for that sensor. |
| Decision | We decided to add the graph type to the sensor in the sensor table. |
| Alternatives |
|
| Arguments | Currently every sensor will have one specific type of graph. Later this could be changed to a user having to make a choice. Using the code we have currently and using this database design this change has less impact compared to the alternative. Beisdes the change having less of an impact we can also make the adding process smoother since a user wouldn't have to choose from all the possible graphs but only from the graphs that make sense for this sensor. Lastly we are able to make some query's faster and more compact this way. |
Security decisions
Regterschot indicated we do not have to worry too much about security yet, as they want to have a functional web application first. Therefore we are only implementing security measures for very high security risk scenarios.. Because of this we have chosen to hash the password, we do this because we are legally obliged tot do. In addition to this, we have chosen to use a Json Web Token. We do this to ensure that unwanted people can not make calls to the API and only retrieve the data through the Web application.