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
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 BackendBackend
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. 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 clarity for the next team that wants to alter our code after us.
Class Diagram
...
Front-end
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 return the response, since it's a resource and should apply the Single Responsibility rule. The loginService is an information expert, since it knows and keeps all the information from the classes. The userDAO sends a call to the database, which happens in the selectQuery method.
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 show sensor
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 knows everything about GlobalComponent. 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.
Graph CRD
sequence diagram deletegraph
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 GraphService. The GraphService delegates this to the GraphDAO because deleting the data from the database is not the responsibility of the service. 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.
Sequence diagram addGraph
The crewmember adds 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 GraphService. The GraphService delegates this to the GraphDAO because adding the data to the database is not the responsibility of the service. In the GraphDAO the graph gets added to 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 unique identifier of the race.
...
The type of graph, can be anything from the following:
- linechart
- barchart
- piechart
- scatterchart
- columnchart
- areachart
- donutchart
- table
- gaugechart
...
Tab
...
Design decisions related to the database
...
Decision 1
...
Description
...
Problem/Issue
...
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.
...
We decided to add the graph type to the sensor in the sensor table.
...
- Saving the graph type in the graph table and letting a user choose from all options when adding a new graph.
...
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.figure 5: class diagram front-end