So far you have learned that use cases and actors are related to each other in the sense that actors execute the use cases. This relationship is shown using association. In the next video, you will see that even the use cases can be related to each other.
In the previous video, you learnt about the include relationship between use cases. In an include relationship, the arrow starts from the including use case and points towards the included use case. Before an actor can execute the including use case, they have to first execute the included use case.
When we implement use cases, in most of the cases, it so happens that one use case includes another use case. Let's see an example. A pay supplier is a use case which would be used or invoked by an admin. When an admin tries to pay a supplier, he happens to view the invoice as well. Here, although during development or implementation phase, view invoice can be implemented separately and pay supplier can be implemented separately, but we represent this as pay supplier includes view invoice. Reason being an admin cannot pay a supplier without viewing the invoice, this does not mean that the view invoice use case cannot be used independently. A supplier in this case can view the invoice independently without having to use a paid supplier. Similarly, the admin can also opt to just view the invoice, but whenever an admin is trying to pay the supplier, he inherently views the invoice as well. This kind of dependency we represent in a use case diagram using include. When one use case includes another use case, it's represented using an arrow which starts from the use case which includes another use case with a dotted arrow which ends at the included use case with a text saying include within two angular brackets.
Use cases often include other use cases
Example: "Pay Supplier" use case includes "View Invoice" use case
View Invoice and Pay Supplier can be implemented separately, but they are related
Admin cannot pay supplier without viewing the invoice
View Invoice can be used independently by a supplier
Admin can view invoice without paying supplier, but when paying supplier, admin inherently views the invoice as well
Use case diagram uses "include" to represent this kind of dependency
Arrow starts from the use case including another use case, with a dotted arrow ending at the included use case, and "include" within two angular brackets written on the arrow.
"Extend" is another relationship in use case diagrams, where one use case may add additional functionality to another use case.
So now you know that the different use cases can be related to each other via an include relationship. In the next video, you will learn about the another relationship that can exist between different use cases.
In the previous video, you learnt about the extend relationship between use cases. In an extend relationship, the arrow starts from the extending use case and points towards the extended use case. Before an actor can execute the extended use case, they may or may not first execute the extending use case.
In the next video, you will see how to draw an include relationship and an extend relationship between different use cases.
In this segment you learned about the Include and Extend relationship. These relationships are used to connect different use cases.