Detailed Design Description
<This section contains detailed design documentation of all software components. The content of this section grows iteratively during the sprints. At the end of each sprint, the diagrams shown need to be consistent.>
Deployment Diagram
...
Design Decisions related to deployment
<Describe all design decisions manifested in the deployment diagram. For instance the choice of operating systems, protocols, distribution of components over sub-systems and the like.>
Design Sub-System Login
...
Design Class Diagram
With this design class diagram you can see the interactions happening between different classes of our program.
...
The resource classes makes uses of the Response interface. This needs to happen, so that the user knows what went wrong.
<Object-oriented sub-systems should be described using a class diagram. If classes or interfaces are used across sub-systems, make sure you mention this in the description of the class diagrams. If your system entails layers, make sure you indicate this in the class diagram, e.g. by means of packages. For each class diagram, make sure you also mention the deployment artifact (from the deployment diagram) it is part of.>
...
Sequence Diagram
<Provide sequence diagrams for major object interactions within the sub-system. It is ok if sequence diagrams cross sub-system boundaries. Make sure you explain this in the description of the diagram. Sequence diagrams must be consistent with the class diagrams described above. Also, if sequence diagrams cover interaction with users, make sure the diagrams are consistent with SDDs you may have documented as part of the SRS.>
...
<Describe all design decisions made for the sub-system. Provide at least decision descriptions for all frameworks, libraries and other technologies used. Other decisions may be related to software patterns, system-structure, adapted principles or the like.>
Login
Login class diagram
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 | 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 that a hashed password is stored in the database. This prevents hackers from seeing someone elses password. |
| Alternatives | SHA-512, MD5, PBKDF2, BCrypt, and SCrypt (Millington, 2022) |
| Arguments | From a comment in Baeldung (Millington, 2022), I saw Argon2 being suggested. Going to the Supertokens website (Supertokens Team, 2022), I found a tool that detects how safely a password is. With that Supertokens also recommended to use this hashing tool this march, 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. |
Decision | Description |
|---|---|
Problem/Issue | Logincontroller contains both the logic and sends the response |
| Decision | Make a new class loginResource wich 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) |
View
...
data per round
Sequence diagram view data per round
The choice has been made to have a method create all required data-objects. These objects contain all data required to show data in a graph. The GenerateGraphData method will first create a new WheelspeedDTO (Data Transfer Object) and WheelspeedDAO (Data Access Object). These objects are then filled with the data that is retrieved from the createGraph method. Next, the objects are sent over to the frontend in JSON-format.
By sending data to the front-end this way, we can ensure expandability in the future. The contents of this diagram can be copied easily, which will make implementations of new graphs a lot easier.
...
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 name of the racecar is not stored in the database because this is not necessary at the moment |
| Decision | In the constructor of RaceDTO the car get's 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 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 SensorWithGraphDAO is the creator of them. SD 2 Select
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.SD 3 Select
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 sidebar component will interact with GlobalComponent because he is the information expert. GlobalComponent knows how the current tabArray of the user. that is why the push method on that array is called.
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 good enough data for 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. This activates the getAllRaces method in the RaceResource. 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 to delete the graph in 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.
Tabs CRUD
During the development for the user tabs we got into an argument on how we were going to display the tabs a user can have. We came to the conclusion that it would be easier if we were to store the tabs in the database. This way the crewmembers don't have to recreate the tabs every time they would login. Also, this way every crewmember could design their dashboard the way they find easy to read.
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.
...