...
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 |
3. Crewmember specifies race1. Crewmember reads data from a graph. | 2. The system will ask crewmember what race it wants to watch.3. The system gets the Graphs and data from specified raceprovides the graph with newly received data. |
| Extensions (alternative flow): | |
...
| Primary Actor: Crewmember. | |||
| Stakeholders & Interests: | |||
Brief Description: A crewmember wants to create a new tab. | |||
Preconditions: A crewmember has logged in to the web application and is on the dashboard page of a race | |||
| Postconditions: The crewmember can see their new created tab. | |||
| Main success scenario (basic flow): | |||
| Actor Action | System Responsibility | ||
1. The crewmember creates a new tab.
|
4. System validates if supplied tab name is correct. 5. System adds the new tab. | ||
| Extensions (alternative flow): | 3a [Crewmember supplies a starting round and ending round]|||
Table 5: Create tab fully dressed format.
System sequence diagram
Figure 8: system sequence diagram create tabs.
...