Use-case
...
Diagrams
Use-case diagrams are used to show which actors within a domain can perform what actions. The diagram
...
Use case diagram 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.
...
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.
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
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
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.
View race
Fully dressed description
| Primary Actor: CrewmemberUser. | |
| Stakeholders & Interests:Viewers | |
Brief Description: A crewmember or a viewer wants to look at racedata or wants to view detailed information of a raceAn actor wants to see a list of old races so he can choose one to watch back. | |
| Preconditions: A crewmember or viewer The actor has logged in into to the web applicationwebsite. | |
| Postconditions: A crewmember or viewer can now view and interact with the race and/or the racecar's dataThere is a list of all the races that happened. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
| A crewmember or viewer wants the watch the race 1. The user goes to the race-overview page. | 2. The system will redirect the viewer or crewmember to a new page.3. The system will load up the new page, where the crewmember or viewer can see a new, empty tabget all the races from the database and show them on the page. |
| Extensions (alternative flow): | |
Table 2:
...
...
View race fully dressed format.
System sequence diagram
Figure 5: System sequence diagram view race.
View specific round(s)
Fully dressed description
| Primary Actor: Crewmember. | |
| Stakeholders & Interests: | |
Brief Description: A crewmember wants to view the data of a specific round during the current race, to analyse that specific round and see if there's anything wrong with the car or the driver. | |
| Preconditions: The crewmember has logged in on the website and is watching a race. | |
| Postconditions: The crewemember crewmember can now view the data of one or more specific rounds. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. A crewmember is going to analyse analyses the data of a specific round. 3. The crewmember inserts the desired rounds to view. | 2. The system will ask requests the crewmember to insert which the range of rounds the user wants they want to view. 4. The system creates a new tab with only the desired rounds as data that can be viewed. |
| Extensions (alternative flow): | |
Table 3:
...
...
View specific round(s) fully dressed format.
System sequence diagram
Figure 6: System sequence diagram view data per round.
View Graphs
Fully dressed description
| Primary Actor: Crewmember. | |
| Stakeholders & Interests: | |
Brief Description: A crewmember wants to look at race data or wants to see a list of old races so he can choose one to watch backview detailed information of a race. | |
| Preconditions: The A crewmember has logged in on the websiteto the web application and has selected a race. | |
| Postconditions: There is a list of all the races that happenedA crewmember can now view and interact with the race and/or the race car's data. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. A crewmember is going to watch a race backCrewmember reads data from a graph. | 2. The system will get all the races from the database and show them on the pageprovides the graph with newly received data. |
| Extensions (alternative flow): | |
Table 4: View graphs fully dressed format.
System sequence diagram
Figure 7: System sequence diagram view graphs.
Tab CRUD
Create Tab
Fully dressed description
Create Tab
| Primary Actor: Crewmember. | |
| Stakeholders & Interests: | |
Brief Description: A crewmember wants to create a new tab. | |
Preconditions: A crewmember has logged in intoto the web application .and is on the dashboard page of a race | |
| Postconditions: The crewmember can see its their new created tab. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. The crewmember wants to create creates a new tab.
4. The crewmember confirms the given input. |
54. System validates if supplied tab name is correct. 65. System adds the new tab. |
| Extensions (alternative flow): | |
Table 5: Create tab fully dressed format.
System sequence diagram
Figure 8: system sequence diagram create tabs.
Update Tab
Fully dressed description
| Primary Actor: Crewmember. | |
| Stakeholders & Interests: | |
Brief Description: A crewmember wants to update an existing tab. | |
| Preconditions: A crewmember has logged in into to the web application and the crewmember needs to have a tab | |
| Postconditions: The crewmember can see its their updated tab. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. The crewmember wants to update updates a tab.
|
54. System validates if the supplied tab name is correct. 65. System updates the tab name. |
| Extensions (alternative flow): | |
Table 6: Update tab fully dressed format.
System sequence diagram
Figure 9: System sequence diagram update tab.
Read Tab
Fully dressed description
| Primary Actor: Crewmember. | |
| Stakeholders & Interests: | |
Brief Description: A crewmember wants to read an exisiting existing tab. | |
| Preconditions: A crewmember has logged in into to the web application and the crewmember needs to have a tab. | |
| Postconditions: The crewmember can see its their tab. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. The crewmember wants read its reads a tab. |
|
| Extensions (alternative flow): | |
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
| Primary Actor: Crewmember. | |
| Stakeholders & Interests: | |
Brief Description: A crewmember wants to delete an existing tab. | |
| Preconditions: A crewmember has logged in into to the web application and the crewmember needs to have a tab. | |
| Postconditions: The crewmember has deleted its their tab. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. The crewmember wants to delete deletes a tab.
|
4. System deletes the tab. |
| Extensions (alternative flow): | |
Table 8: Delete tab fully dressed format.
System sequence diagram
Figure 10: System sequence diagram delete tab.
Place Graph
Fully dressed description
| Primary Actor: Crewmember. | |
| Stakeholders & Interests: | |
Brief Description: A crewmember wants to view the data from the sensors in a graph, to do this they place their desired graph in their tab. | |
| Preconditions: A crewmember has logged in into to the web application and has at least one tab. | |
| Postconditions: The crewmember can see the newly placed graphs. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. The crewmember is going to add a new graph to his tabheads to the list of all available sensors that have graphs. 3. The crewmember selects the desired sensor to add a graph fromfor.
|
|
| Extensions (alternative flow): | |
2a. There are no sensors available in the database. 4a. There are no graphs available that are linked with the shown sensors. | |
Table 9: Place graph fully dressed format.
System sequence diagram
Figure 10: System sequence diagram place graph
Remove Graph
Fully dressed description
| Primary Actor: Crewmember. | |
| Stakeholders & Interests: | |
Brief Description: A crewmember wants to delete a graph from a tab because he doesn't need it anymore. | |
| Preconditions: A crewmember has logged in into to the web application and selected a tab to remove a graph from. | |
| Postconditions: The crewmember has successfully removed the a graph from his tab. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. The crewmember removes the a graph he doesn't want. | 2. System removes the graph from the selected tab. |
| Extensions (alternative flow): | |
Table 10: Remove graph fully dressed format.
System sequence diagram
Figure 11: System sequence diagram remove graph.