...
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 has to 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>> would look like the diagram below when expanded. The CRUD acronym stands for Create, Read, Update & Delete. This simple collectivisation 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.
...
| Primary Actor: Crewmember. | |
| Stakeholders & Interests | |
Brief Description: A crewmember wants to look at racedata race data or wants to view detailed information of a race. | |
| Preconditions: A crewmember has logged in to the web application and has selected a race. | |
| Postconditions: A crewmember can now view and interact with the race and/or the racecarrace car's data. | |
| Main success scenario (basic flow): | |
| Actor Action | System Responsibility |
1. Crewmember reads data from a graph. | 2. The system provides the graph with newly received data. |
| Extensions (alternative flow): | |
...