1. Sequence Diagrams
1.1. Login
1.1.1. Sequence diagram login
figure 5: 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.
1.1.2. Design decisions
|
Decision |
Description |
|---|---|
|
Problem/Issue |
The passwords can be seen by anyone who has access to the database. This is a huge security risk. |
| Decision | Using Argon2, we can hash the passwords of users, so a hashed password is stored in the database. This prevents hackers from seeing someone else's password. |
| Alternatives | SHA-512, MD5, PBKDF2, BCrypt, and SCrypt (Millington, 2022) |
| Arguments | From a comment in Baeldung (Millington, 2022). Argon2 being suggested. Going to the Supertokens website (Supertokens Team, 2022), There is a tool that detects how safely a password is. Supertokens also recommended to use this hashing tool in march 2022, which is quite recent. It uses more resources from your computer, but it makes a stronger password from it. Regterschot Racing required minimum security, that also includes a hashed password. |
table 4: design decision login
|
Decision |
Description |
|---|---|
|
Problem/Issue |
LoginService contains both the logic and sends the response |
| Decision | Make a new class loginResource which is responsible for only sending the response |
| Alternatives | Make a god class |
| Arguments | If one class has to many responsibilities it doesn't obey the SOLID principle (BMC, 2022) |
table 5: design decision login
1.2. View Races
1.2.1. Sequence diagram view races
figure 6: 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 RaceService, because the resource is not allowed to have any logic in it. The RaceService decides the flow, that is why he is the controller. The RaceService delegates this to the raceDAO because getting the data from the database is not the responsibility of the service. 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 on the layer pattern.
1.2.2. Design decision
|
Decision |
Description |
|---|---|
|
Problem/Issue |
The name of the race car is not stored in the database because this is not necessary at the moment |
| Decision | In the constructor of RaceDTO the car gets the value "BMW 320 4fl E46" assigned |
| Alternatives | Store it in the database, leave it empty |
| Arguments |
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 race car. |
table 6: design decision view races
1.3. Place Graph
1.3.1. Sequence diagram show sensor
figure 7: sequence diagram show sensor.
When a crewmember opens a tab, the front-end makes a call to the back-end. It sends a call to SensorWithGraphResource. The SensorWithGraphResource instantly gives it to the SensorService. That is because the SensorWithGraphResource should not contain any logic. The SensorService however is able to make send the call to the SensorWithGraphDAO. The SensorWithGraphDAO creates two DTO's. This is because the DAO uses them to send the data from the database to the resource.
1.3.2. 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 will instantly show the types of graphs linked to the sensor. This is something that happens on the front-end, that's why we decided it's unnecessary.
1.3.3. Sequence diagram select graph
figure 8: sequence diagram select graph.
The crewmember triggers a call on the front-end. 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.
1.3.4. Design decision
|
Decision |
Description |
|---|---|
|
Problem/Issue |
There is no graph linked to a sensor. |
| Decision | There won't be an available graphs to add to a tab. |
| Alternatives | Give every sensor a normal table (for example), so there is always a graph available. |
| Arguments |
Not every sensor has data that fits in a normal table. |
table 7: design decision place graph.
1.4. Graph CRD
1.4.1. Sequence diagram deleteGraph
figure 9: sequence diagram delete 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 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.
|
Decision |
Description |
|---|---|
|
Problem/Issue |
graph and tab ID are not the same in the front and backend |
| Decision | We use the ID from the front-end to get the right ID for the backend |
| Alternatives | Use the ID from the database in the front-end |
| Arguments |
Making them the same would break a lot of functionalities. We didn't have enough time so this was our only option to keep the functionalities. |
1.4.2. Sequence diagram addGraph
figure 10: sequence diagram add graph.
The crewmember adds a graph on the webpage. The front-end makes 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 on the layer pattern.
1.5. Tab CRUD
1.5.1. Delete Tab
figure 11: sequence diagram delete tab.
The crewmember makes a call in the front end to the back-end. The TabResource receives this call and gives it instantly to the service, this is because the resource should only send something back and should not have any logic in the class. The TabService is able to make a call towards the TabDAO who can create the query to delete the tab. The service is used for this because it decides the flow of the deleting of the tab. The TabDAO sends the query to the database which deletes the tab from the storage.
1.5.2. Create tab
figure 12: sequence diagram create tab.
The crewmember makes a call in the front end to the back-end. The TabResource receives this call and sends it to the service, since the resource should only send something back and should not contain any logic. Tabresource does however receive a username from the clearToken method. This needs to happen, because the service should only delegate the function to the DAO and to successfully add a tab, a username is required to see where the tab needs to be added. The TabDAO makes a call to the database to execute the update with a query and parameters set up in de class. This call eventually creates the tab in the database.