Detailed Design Description
Deployment Diagram
figure 2: deployment diagram
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
Class Diagram
Class Diagram Backend
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.
Class Diagram Backend
figure 3: class diagram back-end
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. <insert uitleg dao en dto>
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.
Sequence diagram login
The LoginResource should only send requests to the controller and should return only one response, because the class is a resource class. The LoginController class is a controller and provides a link between the resource and the data classes. It sends the necessary methods to the other classes, so that LoginResource may not become a God class. The controller also returns the response to the LoginResource.
Design decisions
...
Decision
...
Description
...
Problem/Issue
...
Decision
...
Description
...
Problem/Issue
...
View data per round
Sequence diagram view data per round
The crewmember interacts with the ModalComponent to create a new tab. In this component, the crewmember fills in the desired rounds that they want to see data from. The system will then add the new tab with the specified rounds to the application.
View Races
Sequence diagram view races
The crewmember goes to the rewatch race page where the front-end does a call to the back-end. This activates the getAllRaces method in the RaceResource. The resource is only responsible for returning the response so it gets delegated to the RaceController. The RaceController delegates this to the raceDAO because getting the data from the database is not the responsibility of the controller. In the RaceDAO a database connection is established to get all the data from the database. The benefit of this structure is that you can easily swap the classes which results in low cohesion and high coupling. This structure is based of the the layer pattern.
Design decision
...
Decision
...
Description
...
Problem/Issue
...
The BMW is the only car they intend to use in the near future so it's not necessary to make a new table for racecar.
Place Graph
Sequence diagram add graph
When a crewmember opens the a tab, the front-end does a call to the back-end. It calls a method to SensorWithGraphResource. This is the controller of the SensorWithGraphDAO that gets the data which is needed for displaying graphs on the front-end. The SensorWithGraphDAO creates two DTO's. This is because the DAO uses them to send the data from the database to the resource.
Sequence diagram select sensor
We decided that making a sequence diagram is not needed for this user action to the system. The sensors will get loaded in when someone navigates to the website after which the crewmember will click on the desired sensor to view a graph from. After the user clicks on the sensor, it wil instantly show the types of graph linked to the sensor. This is something that happens on the front-end, thats why we decided its unnecessary.
Sequence diagram select graph
The crewmember interacts with the front-end by clicking on the desired graph type. This will call a method to create the graph on the sidebar component. This is because the sidebar component is the controller. The SidebarComponent will interact with GlobalComponent because the SidebarComponent is the information expert. GlobalComponent knows what is in the user's tabArray, which is why the push method on that array is called.
Design decision
...
Decision
...
Description
...
Problem/Issue
...
Not every sensor has data that fits in a normal table.
Delete Graph
sequence diagram graph
The crewmember deletes a graph on the webpage. the front-end does a call to the back-end. The resource is only responsible for returning the response so it gets delegated to GraphResource. The GraphService delegates this to the GraphDAO because getting the data from the database is not the responsibility of the controller. In the GraphDAO the graph gets deleted from the database. The benefit of this structure is that you can easily swap the classes which results in low cohesion and high coupling. This structure is based of the the layer pattern.
Tab CRUD
Delete Tab
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.
...
The type of graph, can be anything from the following:
- linechart
- barchart
- piechart
- scatterchart
- columnchart
- areachart
- donutchart
- table
- gaugechart
...
The unique identifier of the race.
...
Tab
...
Design decisions related to the database
...
Decision 1
...
Description
...
Problem/Issue
...
. 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.
Class Diagram Front-end
figure 5: class diagram front-end
...
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.
...
Security decisions
Regterschot indicated at the beginning of the project that for security we only do the much needed security. Because of this we have chosen to hash the password, we do this because it is legally required and otherwise high fines can come from it.
In addition, we have chosen to use a Json Web Token. We do this to ensure that unwanted people cannot make calls to the API and only retrieve the data through the Web application.