Relationships and Generalisations
A system, its actors and use cases, generally do not operate in isolation. One use case might influence another use case; one actor’s actions can be a subset of another actor’s. This is where relationships (not the relationship between Bella and Edward) and generalisations (not how all Taylor Swift songs are generally the same) come in.
Relationship between Actors and Use Cases
A Use Case is useless if no one uses it. An Actor does not find much value in a system if they cannot do anything.
The relationship between an Actor and Use Case essentially shows what each actor can do. This relationship is indicated as a line between the Actor and Use Case.
Multiple actors can also perform the same use case too.
An Administrator can create a new module and import students from the university’s biographic database. A student can view their marks.
This diagram shows this basic association between the actors and use cases. Importantly, you can see that the Administrator actor interacts with the “Import Students” use case which will in turn interact with the “Biographic Database” actor.
Generalisation between Actors
It will often happen that a set of actions that can be performed by one actor can also be performed by another. Instead of associating multiple actors with the same use case, you can just generalise. Generalisation is shown using an arrow with a clear arrowhead.
From this generalisation, you can say that everything Actor A can do can also be done by Actor B, or Actor B can do everything that Actor A can. However, not everything done by Actor B can be done by Actor A.
All functions performed by an assistant can also be performed by a lecturer. An administrator can perform functions, except those of a student.
Here we see this generalisation. There is an arrow going from Administrator to Lecturer, because administrators can perform all actions lecturers can. There is also an arrow going from Lecturer to Assistant, because lecturers can perform all actions that assistants can. This in turn means that administrators can also perform all actions that an assistant can.
Take note that there is no generalisation from Student. A student’s role differs completely from those of administrators, lecturers and assistants.
The Biographical Database actor does not feature here, as this is an actor that is acted upon.
Include Relationship between Use Cases
There are times where one use case, a use case that is completely independent, is a common action for other use cases. This is then indicated with an «include» relationship. This relationship is shown using a dashed line with an open arrow head pointing to the common (included) use case with the text “«include»” above it. You can see this in here where Use Case A includes Use Case B.
A physical world example would be a car. If you want to change your engine’s battery or check your oil, in both cases you first need to open the bonnet. Let us also quickly revel at the fact that I used a car metaphor…
Now you may be wondering, with which use case does the actor associate? It can be all three, since you can open your bonnet and not do anything. However, if you want to change your battery or check your oil, you need to open the bonnet too.
There might exist cases where a use case can be included, but is not directly associated with an actor.
When using «include», the included use case will always be included.
A lecturer can view an individual student’s marks. Once viewed, they can then make changes to this student’s marks. When a student’s marks are updated, the student is alerted.
Here you can see that the lecturer has the option to view marks and update marks of an individual student. However, when updating the marks for this student, they have to view them first. Once the marks of a student have been updated, the student is alerted.
Extend Relationship between Use Cases
Where an «include» means that a use case will always include another, there are times where this is not the case. For this, you can use the «extend» relationship. This relationship is also shown using a dashed line with an open arrow head pointing to the use case from which the use case is extended with the text “«extend»” above it. You can see this where Use Case A is extended by the functionality of Use Case B (therefor Use Case A includes Use Case B).
Simply put, the «extend» is an “optional” «include». To use another automotive example: You can check your oil, but it might not always be the case that you need to refill the oil.
So, the association is to “Check Oil”, and if you find the oil level is too low, you “Refill Oil”.
An «extend» relationship is an “optional include”.
You can also have multiple extends from one use case. For instance, if you refill your oil, you can need to choose which grade of oil you want to use, as shown in here. (Those numbers are grades/types of oil. I had to Google that…)
In case the extension is not very clear, you can also show the condition behind the choice. This is shown using Extension Points. The extension point is a separate compartment within your Use Case, with the actual use case on top, and the extension point on the bottom, as shown in here.
So, let us take this to our oil example…
The extension point now clearly indicates the condition (type of oil) that will be used to determine which extended use case (“Refill 5W-20” or “Refill 10W-30”) to use, if required.
You do not need to show extension points, however it does make your diagram a little clearer.
An administrator can import students to the system. This can be done by uploading a list, or by drawing the information from the Biographical Database.
This figure shows that when importing students, the “Import Students” can either extended by the “Import from List” use case or the “Import from biographic database” use case. The latter use case then interacts with the Biographic Database actor.
Generalisation between Use Cases
A use case can also be a more specific instance of another use case. This generalisation is similar to that of actor generalisation.
Generalisation is shown using an arrow with a clear arrowhead,.
Using our car example, once again, we will this time fill our tyres. The process of filling a tyre is basically the same every time: you need to unscrew the cap and then insert the pump. However, the difference comes in whether you fill it with Nitrogen (N) or Oxygen (O2).
