You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 80 Next »

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.

Use case diagram

The use-case diagram for Regterschotracing looks like this, with the viewr and crewmember that were mentioned in the domain model now acting as actors that interact with our system. A view can watch a race and enjoy the enticing race from the comfort of their own couch. A crewmember has to 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 servie 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.

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


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: Crewmember, viewer
Stakeholders & Interests: 

Brief Description: An actor wants to see a list of old races so he can choose one to watch back.

Preconditions: The actor has logged in to the website.
Postconditions: There is a list of all the races that happened.
Main success scenario (basic flow):
Actor ActionSystem Responsibility

1. The crewmember or viewer goes to the race-overview page.


2. The system will get all the races from the database and show them on the page.


Extensions (alternative flow):


System sequence diagram

 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 crewmember can now view the data of one or more specific rounds.
Main success scenario (basic flow):
Actor ActionSystem Responsibility

1. A crewmember analyses the data of a specific round.

3. The crewmember inserts the desired rounds to view.

2. The system will ask the crewmember to insert which range of rounds the user wants to view.

4. The system creates a new tab with only the desired rounds as data that can be viewed.

Extensions (alternative flow):


System sequence diagram

View Graphs

Fully dressed description

Primary Actor: Crewmember
Stakeholders & Interests

Brief Description: A crewmember wants to look at racedata or wants to view detailed information of a race.

Preconditions: A crewmember has logged in to the web application
Postconditions: A crewmember can now view and interact with the race and/or the racecar's data.
Main success scenario (basic flow):
Actor ActionSystem Responsibility
  1. A crewmember wants to watch a race

  3. Crewmember specifies race.

2. The system will ask crewmember what race it wants to watch.

3. The system gets the Graphs and data from specified race.


Extensions (alternative flow):


System sequence diagram

Tab CRUD

Create Tab

Fully dressed description

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 ActionSystem Responsibility

1. The crewmember creates a new tab


3. The crewmember supplies the system with a tab name.



2. System asks for a tab name.


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]



4. System validates if supplied information is correct.

5. System adds the new tab which starts and ends with the supplied rounds

System sequence diagram


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 to the web application and the crewmember needs to have a tab
Postconditions: The crewmember can see their updated tab
Main success scenario (basic flow): 
Actor ActionSystem Responsibility

1. The crewmember updates a tab


3. The crewmember supplies the system with a tab name.



2. System asks for a new tab name


4. System validates if the supplied tab name is correct.

5. System updates the tab name.

Extensions (alternative flow):




System sequence diagram


Read Tab

Fully dressed description

Primary Actor: Crewmember
Stakeholders & Interests: 

Brief Description: A crewmember wants to read an existing tab

Preconditions: A crewmember has logged in to the web application and the crewmember needs to have a tab
Postconditions: The crewmember can see their tab
Main success scenario (basic flow): 
Actor ActionSystem Responsibility

1. The crewmember reads a tab.



2. System shows details of given tab

Extensions (alternative flow):





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 to the web application and the crewmember needs to have a tab
Postconditions: The crewmember has deleted their tab.
Main success scenario (basic flow): 
Actor ActionSystem Responsibility

1. The crewmember deletes a tab.


3. The crewmember confirms deletion.



2. System asks for a confirmation

4. System deletes the tab.

Extensions (alternative flow):




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
Postconditions: The crewmember can see the newly placed graphs.
Main success scenario (basic flow): 
Actor ActionSystem Responsibility

1. The crewmember adds a new graph to his tab.


3. The crewmember selects the desired sensor to add a graph from.


5. The crewmember selects the desired type of graph to add to the tab


2. System shows all sensors to choose a graph from.


4. System shows all graphs that are included in the current selection.


6. System adds the graph to the tab.

Extensions (alternative flow):

2a. There are no sensors available in the database.
      end of usecase.

4a. There are no graphs available that are linked with the shown sensors.
      end of usecase.

System sequence diagram

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 to the web application and selected a tab to remove a graph from.
Postconditions: The crewmember has successfully removed a graph from his tab.
Main success scenario (basic flow): 
Actor ActionSystem Responsibility

1. The crewmember removes a graph.


2. System removes the graph from the selected tab.

Extensions (alternative flow):


System sequence diagram

  • No labels