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
<Provide a UML deployment diagram showing all physical and virtual nodes used in the system. The diagram must also contain all deployment artifacts used in the system, for instance JAR or WAR files, or web artifacts.>
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
<Do not really name the section “Sub-System A”, use a name that describes the responsibility of the sub-system, instead. Provide a section for each sub-system. These sections are iteratively added and refined during the sprints. Examples of sub-systems include Persistent Storage, Business Tier, Web Application, Webservice API. The sub-sections below may be extended if you think this is useful for describing the software design. The sub-sections below are only required for object-oriented sub-systems. Use other means to describe non-OO sub-systems (for instance Javascript modules).>
Design Class Diagram
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.
<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 Diagramsm
<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.>
Activity and State Diagrams
<This section is optional. If useful, provide activity and/or state diagrams to describe complex work flows and system state transitions>
Design decisions made for the sub-system
<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
Sequence diagram
The LoginResource returns the response to the user. The LoginResource needs to get the name of the user, so it may check if the login is correct and that it knows who the create token is for. If LoginResource doesn't know the username, then duplicate code will be created in the LoginController. The response changes if the verification proces is not correct. This creates an 403 response back to the resource and will throw an exception in the code. If it is correct, then it will execute createToken and getUserWithUsername. The userDAO needs to create a LoginRequestDTO class, so that it may store the data from the database in the code. This data is then added in an array called users, that gets called back to LoginController. In createToken there is a new create message being send to LoginResponseDTO. This happens, so that the response back to the user contains a token and a username.
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
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.
Design Sub-System B (and so on)
…
Database Design
This is the database setup we will use for the RegterschotRacing API. A ful ldescription 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 two red boxes could be future expansions that are out of our current scope. These have been placed here as an example to provide future developers with a stepping stone. These expansions would allow for the creation of 'Raceteams', which could give the API the functionality to be used by other raceteams, each with their own crew and cars. The sensors have been tied to the racecar, as all sensors should be in a racecar.
Database Glossary
Tablenames and formats are written in italic; Columns that contain the primary key are underlined.
| Table | Column | Datatype | Null / Not Null | Comments |
|---|---|---|---|---|
| Driver | This table is responsible for a driver's data. This can be expanded further with a date of birth, length, age or something else. | |||
| DriverID | int | Not null | This is a unique identifier for a driver, with which a driver can be tied to races and rounds. | |
| DriverName | varchar(255) | Not null | The name of the driver in the format lastname, firstname. | |
| DriverRaces | This table links the driver to the driven rounds within a race. | |||
| RaceID | int | Not null | This is the unique identifier of the race. | |
| DriverID | int | Not null | This is the unique identifier of the driver. | |
| RoundID | int | Not null | This is the unique identifier of the round. | |
| Graphs | This table contains all data that is required to show a graph. It contains the sensor it is displaying the data for, and the type of graph it is. | |||
| GraphID | int | Not null | This is the unique identifier of the graph. | |
| Type | varchar(255) | Not null | The type of graph, can be anything from the following:
| |
| SensorID | int | Not null | The unique identifier of the sensor that the graph is displaying the data of. | |
| Race | This table contains all information relevant to a race. | |||
| RaceID | int | Not null | The unique identifier of the race. | |
| NumberOfRounds | int | Not null | The number of rounds that the race encompasses. | |
| RaceName | varchar(255) | Not null | The name of the race. | |
| Rounds | This table contains all information that is needed to define a round. | |||
| RoundsID | int | Not null | The unique identifier of the race. | |
| RaceID | int | Not null | The unique identifier of the race that the round belongs to. | |
| TimestampBegin | DATETIME | Not null | The starting time of the round. | |
| TimestampEnd | DATETIME | Not null | The ending time of the round. | |
| Sensors | This table functions as collection of all sensors. | |||
| SensorID | int | Not null | The unique identifier of the sensor. | |
| SensorName | varchar(255) | Not null | The name of the sensor. | |
| TabGraphs | This table couples all graphs to a specific tab. | |||
| TabID | int | Not null | The unique identifier of the tab. | |
| GraphID | int | Not null | The unique identifier of the graph. | |
Tabs | This table contains all information that is relevant to a Tab. | |||
| TabID | int | Not null | The unique identifier of the tab. | |
| TabName | varchar(255) | Not null | The name of the tab. The name is set when creating a new tab in the frontend web-application. | |
| RaceID | int | Not null | The unique identifier of the race that the tab belongs to. | |
| User | This table handles all user data and other data relevant to have users that can interact with the application. | |||
| UserID | int | Not null | The unique identifier of the user. | |
| Username | varchar(255) | Not null | The unique name of a user that will be on display in the frontend web-application. | |
| Password | varchar(255) | Not null | The hashed password of the user that is needed when logging in into the web-application. | |
| UserTabs | This table is responsible for tying all tabs that have been created by a user. | |||
| UserID | int | Not null | The unique identifier of the user. | |
| TabID | int | Not null | The unique identifier of the tab. | |
| WheelspeedSensor | This table can be used for any future sensor that is added to the car. This table will need to be copied and its unique third row should be edited to accomodate the right datatype and name for this new sensor. | |||
| WheelspeedSensorID | int | Not null | The unique identifier of the specific sensor. | |
| Timestamp | DATETIME | Null | The timestamp when the specific piece of data was received from the sensor. | |
| RPM (data) | float | Null | This field contains the spcific data that a sensor sends to this database. For this specific sensor, that data is received as RPM. When a new sensor is added to the API, a new table, just like this one should be created where only the data field should be edited. | |
Design decisions related to the database
<Describe all design decisions made along the database. This could include the choice of the database management system, the use of certain triggers or stored procedures, special indexes and so on.>
hier moeten nog dingen bij als triggers en uitleg over de keys
Decision 1 | Description |
|---|---|
Problem/Issue | Throwing all of the different sensors and their data into one big table will quickly create a very clumped and hard-to-read table. |
| Decision | Create a different table for every sensor and add a new table that contains all sensor IDs. |
| Alternatives | - |
| Arguments | By dividing data over multiple tables, query time can be shortened significantly and keeps all of our tables in line with the Single Responsibility principle. |
| Decision 2 | Description |
|---|---|
| Problem/issue | A driver is only driving a couple of rounds in a race, which will create quite a confusing table if thrown into a single race tables. |
| Decision | 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. |
| Alternatives | - |
| Arguments | By dividing the table into a multitude of different tables, there's three distinct tables that are in line with the Single Responsibility principle. |