Use Case Diagram

Behaviour diagrams------>Use case diagram

Functional View------>Use case diagram


Components of a Use Case Diagram
System: Sets the boundary of the system
Actor: A role played by a person, system, or device
Use Case: Identifies a key feature of the system. Each Use Case is named using a verb phrase that expresses a goal the system must accomplish, for example, deposit money, withdraw money, and adjust account.
Association: Identifies an interaction between actors and Use Cases.
Dependency: Identifies a communication relationship between two Use Cases.
Generalization: Defines a relationship between two actors or two Use Cases where one Use Case inherits and adds to or overrides the properties of the other.

Dependency types:
<<include>>,<<extend>>
The <<extend>> dependency stereotype says that one Use Case might need help from another Use Case. In contrast, the <<include>> dependency stereotype says that one Use Case will always call the other Use Case.
The other contrast between the two dependency stereotypes is the direction of the dependency arrow. The <<include>> dependency arrow points from the main Use Case (the one currently executing) to the one that it needs help from. The <<extend>> dependency arrow points from the extension Use Case (the one providing the extra help) to the main Use Case that it is helping.

The main point is that an include relationship is not optional, while an extend relationship is optional.

generalization is basically inheritance relationship ("is a" relationship)

Here, if the student attends college, then he has to get enrolled in the college. It is a compulsion and not optional. So that's an include dependency..
If the student attends Engineering college, then he may or may not go to the canteen, so that's optional. Therefore it is an extend dependency.
Finally, the engineering college "is a" college, so it's a pure form of inheritance, that's why its a generalization.

 Related Articles

Use Case Diagram Examples