1. Introduction

1.1. Overall Description

You can find the description about the project in the introduction of our system requirements specification document.
See article: SRS Introduction

1.2. Purpose of this document

The purpose of this Software Design Description is to explain and justify the design choices that we have made during this project and the development of our product. The explaination for these design choices can be given to future programmers, so that they may have an idea of why some products have been designed in a certain way. 

1.3. Definitions, acronyms, and abbreviations

table 1: detailed description of words, acronyms and abbreviations

2. Architectural Overview

This architectural overview is an overview that shows the building blocks of our project. It shows how we intend to build this project, besides that it helps the development team get a shared view.

figure 1: Architectural overview

Here you can see a description of what every building block of our project means. This makes the architectural overview better understandable.

table 2: glossary of architectural overview

3. Detailed Design Description

3.1. Deployment Diagram

figure 2: deployment diagram

3.2. Design Decisions related to Deployment Diagram

table 3: glossary of deployment diagram

3.3. 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. 

3.3.1. Class Diagram Backend  

figure 3: class diagram back-end

3.3.2. 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 clarity for the next team that wants to alter our code after us.

3.3.3. Class Diagram Front-end

figure 5: class diagram front-end

4. Sequence Diagrams

4.1. Login

4.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. 

4.1.2. Design decisions

table 4: design decision login

table 5: design decision login

4.2. View Races

4.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.

4.2.2. Design decision

table 6: design decision view races

4.3. Place Graph

4.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. 

4.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.

4.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.

4.3.4. Design decision

table 7: design decision place graph.

4.4. Graph CRD

4.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.

4.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.

4.5. Tab CRUD

4.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.

4.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.

5. Database and security

5.1. Database Design

The database design is made so every team member knows the structure of the database. It basically shows you the way we organize our data.

figure 13: 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 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 steppingstone.

5.1.1.  Database Glossary

Tablenames and formats are written in italic; Columns that contain the primary key are underlined. 

table 8: glossary database design

5.1.2. Design decisions related to the database

table 9: design decision database

table 10: design decision database

table 11: design decision database

table 12: design decision database

5.2. 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 to do. In addition to this, 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. Furthermore we have choosen to make use of prepared statements. This is done to prevent SQL injections from happening. The prevention of SQL injections is implemented because it is seen as a very high security risk.

6. List of Resources

1. Millington, S. (2022, January 12). Hashing a Password in Java. Baeldung. https://www.baeldung.com/java-password-hashing
2. Supertokens Team. (2022, March 2). Hash, salt and verify passwords - Node, Python, Go and Java. Supertokens. https://supertokens.com/blog/password-hashing-salting