1. Introduction
Regterschot Racing has requested us to build an API where a member of the racecrew can view the data sent by a racecar in real-time. This data needs to be converted into charts that accurately represents the data in a clear way. This means that the data should be understood by the raceteam. All graphs are placed in a dashboard that is seen by crewmembers that are logged into the application. Viewers can also see a restricted set of data. Regterschot wants this API to be deployed in a web-application. The data that is retrieved from the broker, will eventually end up in a database. The web-application needs to have a constant connection to the database, to show past data. The present data is retrieved from a broker that the team at Regterschot Racing had already made. This broker will send data to the application twenty times per second. It is important that the communication with the database and broker provides a fast and reliable way to bring data to the website. The system needs to be easily expandable, so that it may be able to add new features in the future. Because Regterschot Racing wants this application to be expandable, we need to have a clear and informational instruction on how the code works. Our project will be followed up by multiple other groups that will build upon our code. These groups might be international and therefore everything needs to be documented in English, so that they can understand how our code works.
1.1. User Classes and Characteristics
For this product, we'll realize two types of users. Firstly, there's the crewmembers, who are our main scope. A crewmember can view a race and retrieve all of its real-time and past data. Second, there's the viewers, who can only view the race with a restricted set of data that is updated real time. Viewers cannot select what kind of data they wish to see, all data that is visible for them will be visible at all time whilst watching the race.
Both types of users can log in into our web-application. A crewmember can see more options when logged in, as they can view back races and watch live races, whereas a viewer can only watch live races.
1.2. Operating Environment
Our web-application's back-end will be built in Java 17 and Maven and our front-end will be built in Angular 14.0 and Bootstrap 5.0. The application will run in Wildfly 25.0.0, which allows us to run the website locally. We will use Java Database Connection (JDBC) to establish a connection between our database and our web-application. We'll also use a Broker to establish a connection between the racecar's sensors and our application, which allows us to receive a constant stream of data. The broker will also send data to the database, so that past data can be seen as well.
1.3. Design and Implementation Constraints
The product owner has not given a lot of constraints for this project. There are still a few technical limitations that limit our options. The car's data is being sent to the database twenty times per second. Because Regterschot Racing wants a constant stream of data to the application, it is required to use TCP as a communication protocol. This data must be converted into graphs because a clear overview of all data is demanded. We will have to use Google Charts because Google Charts runs in a web-application and can update the data twenty times per second (Lijden & Kooy, 2022).
1.4. Product Functions
Summary of all the functions:
- The product must present data from the sensors of the racecar.
- The user has to be able to login to the site and choose how the data is presented.
- The product stores all the data from the sensor for future purposes.
- The crewmember is able to add, delete and update a tab.
- The crewmember can place charts in the tab that contains data from the chosen sensor.
- The viewer and crewmember can watch past and present races.
1.5. Purpose of this document
This document serves as a guideline for the multiple features and behaviors that our application will have. This document includes a list of elements that will attempt to define the intended functionality required by the customer to satisfy their different users. In addition to specifying how the system should behave, this document will also define what key performance parameters will need to be met by the system. To accomplish this, the document has been divided into multiple sections:
| Section | Function |
|---|---|
| Domain | Houses a model that displays all of the different concepts that are present within the domain. |
| Use-cases | All different actions that a user should be able to perform and the system's response to these different user actions. |
| Functional and non-functional requirements | All requirements that the system should abide by. |
2. Domain Model
This is the domain model. It represents all concepts and attributes that are present within Regterschot Racing's desire for our application. This model shows all concepts as yellow squares, with the attributes underneath the concepts they belong to. Between the squares are lines that represent the interaction between the different concepts. The arrow on the lines indicate in which way the concepts interact with each other. Next to the line, near the concepts are numbers and asterisks that represent how many interactions on concept has with another concept. The line between Tab and Graph for example shows us that every 1 tab consists of 0 or more graphs.
An explanation of all terms found in the domain model can be found below.
figure 1: Domain model
As visible in the diagram above, a user is a generalization of both crewmembers and viewers. A crewmember can perform certain actions within the domain than a viewer, therefore the user concept has been split. The crewmember and viewer do however have the same attributes as a player, so they will inherit those attributes from the user.
2.1. Glossary
| Concept | Description | |
|---|---|---|
| RegterschotRacing | The company that wants us to build an application to view data from a racecar's sensors in real-time. RegterschotRacing manages who gets to use the application and which races the application will be used at. | |
| User | The person that uses the Regterschot Racing application. A user can either be a Crewmember or a Viewer | |
| Username | The name the user will use. | |
| Password | The hashed key of the account that the user utilizes. | |
| Token | The code used to authenticate a user into one of the two user roles. | |
| Crewmember | A person who is part of the Regterschot Racing racing team that reads and analyses the real-time data from the racecar. | |
| Viewer | A person who wants to view the race but has no access to the real-time data dashboards. | |
| Race | The race where the racecar will be used. | |
| Lap | The laps that make up the race. | |
|
Dashboard |
A dashboard shows all relevant statistics and data received from the racecar. This dashboard is updated in real-time or shows data of one or more specific rounds. | |
| Racecar | The racecar that the dashboard is showing the data for. | |
| Tab | A part of the dashboard where graphs can be loaded into. | |
| Name | Name of the tab. | |
| Sensor | A device that measures or detects data the way it's used for. | |
| Data | Values of the sensor. | |
| Timestamp | Timestamp that the data uses. | |
| Graph | Shows the data produced by the sensors. | |
| Color | Color used for the data in the graph. | |
| TimeScope | Start time and end time of the graph. | |
| Raceteam | The team that participates in a race that consists of crewmembers and racers. | |
| Name | the name for the raceteam. | |
| Racecar | The car participating in the race. | |
| Brand | The brand of the car. | |
| Type | The type of racecar. For example '320 4fl E46'. | |
Table 1: Domain model glossary
3. Other functional requirements
On top of the requirements set by the different use-cases and the domain model, there's a few more requirements that we'll have to consider when developing our product. The requirements listed in the table below are all functional, meaning that our system needs these functionalities.
|
Code |
Description |
|---|---|
| FR1 | A user must be able to log in to the website to be able to either view a race or analyse the data of a specific race car. |
|
FR2 |
A crewmember must be able to view all data sent from the sensors of a race car on a dashboard to be able to analyse the race and make impactful decisions. |
| FR3 | All data sent by the sensors in a race car must be represented in any form of graph to provide an easy insight into the current race's situation. |
4. Non-functional Requirements
4.1. Performance Efficiency
|
Code |
Description |
|---|---|
| NFR1 | Responses to all user-initiated actions in the web-interface must be be rendered on our systems in less than 3 seconds. |
4.2. Security
|
Code |
Description |
|---|---|
| NFR2 | The application must be protected against SQL-injections and other safety hazards to ensure no user can hack themselves into the race's data and alter said data. |
| NFR3 | Passwords must be hashed before they are stored into the database to prevent no user account can be hacked by an outsider. |
4.3. Reliability
| Code |
Description |
|---|---|
| NFR4 | All data sent by the race car must be accurate to the last decimal stored in the database or received from the broker. This way, the analysing race crew can work with actual accurate data instead of rounded numbers. |
| NFR5 | There must be no code smells such as feature envy, shotgun surgery and tradition breaker present in the code. This is to ensure the reliability of our application in the future. |
4.4. Documentation
| Code |
Description |
|---|---|
| NFR6 | All documentation must be made in English to allow other groups that will continue our work after us to understand why we made certain choices. |
| NFR7 |
The main color used for the web-application should be #148484( |
4.5. Supportability
| Code | Description |
|---|---|
| NFR8 | All systems made by smalltalk should have an A rating on SonarQube reliability, security and maintainability, so future groups can work with our code without having to rewrite all of our code. |
| NFR9 | Our code should be tested thoroughly, with at least 80% of the lines being tested by unit-tests. This way we know our code is working and does not contain any bugs or errors. |
5. User interface sketches
5.1. Dashboard car statistics:
5.2. Login user:
6. List of Resources
Lijden, van, & Kooy. (2022, November 16). Onderzoeksverslag Visuele Dataweergave. Onderzoeken. Retrieved December 14, 2022, from https://confluenceoosevt.aimsites.nl/display/VQMSWB/Onderzoeksverslag+Visuele+Dataweergave
| User | Edits | Comments | Last Update |
|---|---|---|---|
| Jasper Kooy | 94 | 21 | 655 days ago |
| Wijnand vanZyl | 31 | 9 | 682 days ago |
| Sem Gerrits | 28 | 3 | 662 days ago |
| Thomas Droppert | 16 | 70 | 659 days ago |
| Auto Mation | 12 | 0 | 732 days ago |
| Martin van Lijden | 11 | 1 | 661 days ago |
| Bram Bakker | 2 | 1 | 659 days ago |
| Mark Giesen | 0 | 1 | 704 days ago |