If some task is performed as part of several use cases, then we can extract this task as a separate use case that is included by other use cases. This can simplify scenarios.
An included use case is like a helper subroutine that is called by other higher level functions.
Included use cases are usually included by multiple use cases.
Included use cases usually don't have actor associations.
While control is explicitly transferred from a use case to an included use case, control is implicitly transferred from a use case to one of its extensions.
There are several examples from programming:
Throwing and catching exceptions
Calling a polymorphic function
The advantage is that use case extensions can be replaced without modifying the extended use case.
If we think of scenarios as use case instances, then use case A generalizes use case B if every B scenario is also an A scenario.
For example, there might be several ways to handle requests for large amounts of cash: notify manager or call security. Any notify manager scenario is a handle large request scenario.
Note that if A generalizes B, then B inherits all of the attributes of A. For example, B inherits the priority of A. B also inherits the actor associations of B.
With this in mind, we can simplify use case diagrams by introducing the notion of an abstract use case. An abstract use case (shown with an italicized name) has no scenarios. All of the scenarios are instances of specializations.
For example: