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:

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

Table 1: Domain model glossary

3. Use-case Diagrams

Use-case diagrams are used to show which actors within a domain can perform what actions. The diagram contains all of the actors on the left-hand side, the system in a central box and any external actors that do not perform any user actions on the right-hand side. All actions that the actors perform are inside the central box and have a line to either crewmember or viewer to represent who can perform that specific user action.

3.1. Use case diagram

The use-case diagram for Regterschotracing looks like this, with the viewer and crewmember that were mentioned in the domain model now acting as actors that interact with our system. A viewer can watch a race and enjoy the enticing race from the comfort of their own couch. A crewmember must analyse the data from the racecar in graphs that are placed in tabs whilst watching a race, so there's two distinct user-actions that solely crewmembers can perform. Furthermore, the graphs that are used by a crewmember connect to an external actor, the broker. This is a service that can send a long stream of data to our application without requiring constant requests for fetching said data.

The <<CRUD>> and <<CRD>> indicate that this particular use-case is a collection of multiple use-case that closely relate to one another.

Figure 2: Use-case diagram

3.2. Use case diagram Tabs CRUD

The <<CRUD>> and <<CRD>> would look like the diagram below when expanded. The CRUD acronym stands for Create, Read, Update & Delete. This simple collectivization shows that an actor can interact with a certain use-case, in this case a tab. They can add new tabs, they can read the data that is present within the tabs, they can update the tab by adding new graphs or removing graphs and they can delete tabs by removing them from the view.

Figure 3: Tab <<CRUD>> use-case diagram

Figure 4: Graph <<CRD>> use-case diagram

4. Use Case Descriptions

In this chapter, all of the use-cases in the use-case diagram will be expanded and explained, adding a primary actor, potential stakeholders, a brief description, pre- and postconditions as well as a main success path and any potential alternative paths to successfully complete the use-case. Next to this overview of the use-case, an SSD or System Sequence Diagram has been added, which shows the user actions as well as the system's responses to these user actions.

4.1. View race

Fully dressed description

Table 2: View race fully dressed format.

System sequence diagram

Figure 5: System sequence diagram view race.

4.2.  View specific round(s)

Fully dressed description

Table 3: View specific round(s) fully dressed format.

System sequence diagram

Figure 6: System sequence diagram view data per round.

4.3. View Graphs

Fully dressed description

Table 4: View graphs fully dressed format.

System sequence diagram

Figure 7: System sequence diagram view graphs.

4.4. Tab CRUD

Create Tab

Fully dressed description

Table 5: Create tab fully dressed format.

System sequence diagram

Figure 8: system sequence diagram create tabs.

Update Tab

Fully dressed description

Table 6: Update tab fully dressed format.

System sequence diagram

Figure 9: System sequence diagram update tab.

Read Tab

Fully dressed description

Table 7: Read tab fully dressed format.

This use-case has no system sequence diagram, as there's nothing for the system to handle when a crewmember is continuously reading data. 

Delete Tab

Fully dressed description

Table 8: Delete tab fully dressed format.

System sequence diagram

Figure 10: System sequence diagram delete tab.

4.5. Place Graph

Fully dressed description

Table 9: Place graph fully dressed format.

System sequence diagram

Figure 10: System sequence diagram place graph

4.6. Remove Graph

Fully dressed description

Table 10: Remove graph fully dressed format.

System sequence diagram

Figure 11: System sequence diagram remove graph.

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

6. Non-functional Requirements

6.1. Performance Efficiency

6.2. Security

6.3. Reliability

6.4. Documentation

6.5. Supportability

7. User interface sketches

7.1. Dashboard car statistics:

7.2. Login user:

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