...
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): | |||
Table 5: Create tab fully dressed format.
System sequence diagram
Figure 8: system sequence diagram create tabs.
...
Table 6: Update tab fully dressed format.
System sequence diagram
Figure 9: System sequence diagram update tab.
...
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.
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 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 adds 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. | |
...