Relationships in Use Case.

Relationships in Use Case
There are often 5 relationship types during a use case diagram.
1. Association between actor and use case.
2. Actor Generalization.
3. Extend.
4. Include.
5. Use Case Generalization.

1. Association between Actor and Use Case:

This one is simple and gift in each use case diagram. There are few things to notice;
* An actor should be related to a minimum of one use case.
* An actor often related to multiple use cases.
* Multiple actors are often related to one use case.

Different ways association relationship seems in use case diagrams

Check out the utilization case diagram pointers for alternative things to contemplate once adding an actor.

2. Actor Generalization:
Generalization of an actor means one actor will inherit the role of the opposite actor. The descendant inherits all the utilization cases of the antecedent. The descendant has one or a lot of use cases that square measure specific thereto role. Let’s expand the previous use case diagram to purpose out the generalization of an actor.

A generalized actor in use case diagram

3. Extend:
Many people confuse the extend relationship in use cases, because the name implies it extends the bottom use case and adds a lot of practicality to the system. Here square measure a couple of things to contemplate once victimization the connection.
* The extending use case depends on the extended (base) use case, within the below diagram the “Calculate Bonus” use case doesn’t create a lot of sense while not the “Deposit Funds” use case.
* The extending use case is typically optional and may be triggered not absolutely, within the diagram, you’ll see that the extending use case is triggered just for deposits over ten, or once the age is over fifty five.
* The extended (base) use case should be meaning on its own, this implies it ought to be freelance and should not place confidence in the behavior of the extending use case.
Let’s expand our current example to point out the connection.

Extend relationship in use case diagrams

Although extending use case is ex gratia most of the time it’s not a demand. AN extending use case will have non-optional behavior also. This largely happens once your modeling has complicated behaviors.
For example, in an accounting, one use case could be “Add Account Ledger Entry”. This may need extending use cases “Add Tax Ledger Entry” and “Add Payment Ledger Entry”. These don’t seem to be ex gratia however relying upon the account accounting. Also, they need their own specific behavior to be shapely as a separate use case.

4. Include:
Include relationship show that the behavior of the enclosed use case is a component of the together with (base) use case. The most reason for this can be to apply common actions across multiple use cases. In some things, this can be done to alter complicated behaviors. Few things to contemplate once victimization the connection.
* The bottom use case is incomplete while not the enclosed use case.
* The enclosed use case is necessary and not ex gratia.
Lets expand our banking industry use case diagram to purpose out include relationships also.

Includes is typically accustomed model common behavior

For some any reading relating to the distinction between extend and embody relationships in use case diagrams check this Stack Overflow link.

5. Generalization of a Use Case:
This is almost like the generalization of AN actor. The behavior of the antecedent is transmitted by the descendant. This can be used when there’s common behavior between 2 use cases and conjointly specialized behavior specific to each use case.
For example, at intervals the previous banking example, there could be a use case referred to as “Pay Bills”, this could be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.