Use case diagrams describe a set of actions system performs in collaboration with one or more external users of the system (actors).
A Use Case describes the behavior of a business system from the business user’s point of view. It describes in plain business terms how the user interacts with the system and what the system does in response. It does not determine how the system works internally, that is it does not define the implementation.
So what is relationship in use case diagram?
Use case relationships indicate the communication between an actor and a use case. Relationships can flow in both directions i.e. actor to use case and use case to actor and is represented with a solid line connecting them and sometimes with arrowhead.
There can be 5 relationship types in a use case diagram.
- Generalization of an actor
- Extend between two use cases
- Include between two use cases
- Generalization of a use case
Generalization of an Actor
Generalization is the inheritance relationship between two actors by which one actor inherits all properties and relationship of another actor. Thus, in a use case modeling, actor generalization of an actor means that one actor can inherit the role of the other actor. The child inherits all the use cases of the parent. The child has one or more use cases that are specific to that role.
In an airline system, passenger is and actor but he can be a economy class or business class. Both are passengers but with some difference in benefits like redeem miles, upgrade eligibility etc . So ‘passenger’ here is parent actor with ‘Economy passenger’ and ‘Business passenger’ as child actors.
In this relationship, an extension use case is created to extend the behavior of the extended (base) use case when exceptional circumstances are encountered. An extend relationship is used to represent an optional or exceptional behavior. It is represented by drawing dashed line with arrowhead pointing the base use case.
In an online ticket booking system, user needs to register before booking the ticket. So we have a registration use case as part of the use case diagram. Registration use case is complete on its own but it could be extended with optional ‘Get help on registration’ use case.
Include relationships describe a required (non-optional) behavior included in the base use case. It is a relationship created between a use cases (base) that “uses” the functionality of another use case (included). Generally, it is assumed that the included use case will be called every time the basic path is run.
- The base use case “uses” the included uses case
- A base use will function only when it gets information from the included use case
- It is shown by a dashed arrow with an open arrowhead from the base use case to the included use case. The arrow is labeled with keyword <<include>>
In an online shopping system, user chooses to checkout when items are added in cart. So the ‘Checkout’ will be base use case which will have mandatory use case as ‘Calculate Total’ and ‘Payment’.
Generalization of a Use Case
This is similar to the generalization of an actor. The behavior of the parent is inherited by the child. This is used when there is common behavior between two use cases and also specialized behavior specific to each use case.
In an online banking system, there might be a use case called “Pay Bills”. This can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.