Use cases are text that describes a software system's behavior as it responds to requests from system users, known as actors. An actor is the role for someone or something that interacts with the system and can be a person, organization, or an external system.
Just like with classes in a class diagram, generalizations can be done on actors. Actor generalization is a relationship between actors in which one actor (descendant) inherits the role and properties from another actor (ancestor).
For example, if our domain had different types of managers, such as an HR Manager and a Customer Service Manager, they may both inherit from a Manager ancestor actor:
Actor generalization is graphically represented in the same way that generalization is with classes. It is done with a hollow triangle on the part of the connecting line that is closest to the ancestor actor.
Use cases are something that the system does or something that happens to the system. Use cases should be easy to read and are usually brief. Actors have goals and use cases describe ways to carry out those goals by using the software system.
A use case diagram is a graphic representation of a use case, the relevant actors, and their relationships. It details the actors and how they interact with the software system. Use case diagrams allow people to understand the scope of the software system and the functionality that will be provided to actors. They can be useful for traceability in that we can verify that a software system is meeting its functional requirements.
In a use case diagram, actors are typically represented by a stick figure with the name of the actor's role appearing underneath it. Use cases are graphically represented with a horizontally shaped oval. The name of the use case appears inside the oval:
Lines are used to show associations between actors and use cases. Use case diagrams can describe context by showing the system's scope. A system boundary box can be used to present what is part of the system and what is external to it:
In the preceding diagram, there are three actors, all of which are external to the Online Order System. The Customer actor is a person but the Identity Provider and Payment Processor actors are external systems.
There are four use cases shown in this simplified example. The Customer is associated with all of them but the Identity Provider is only involved with the Login use case and the Payment Processor is only associated with the Checkout use case.