Guideline: Using Actor Generalization
Generalize actors when several of them can play the same role in a particular use case.
Relationships
Related Elements
Main Description

Explanation

Several actors can play the same role in a particular use case. Thus, a Teller and an Accountant, both of whom check the balance of an account, are seen as the same external entity by the use case that does the checking. The shared role is modeled as an actor, Balance Supervisor, inherited by the two original actors. This relationship is shown with actor-generalizations.

Diagram described in accompanying text.

The actors Teller and Accountant inherit all the properties of a Balance Supervisor. Thus, both these actors can act as Balance Supervisors.

A user or external system can play several roles in relation to the system under development. This means that the user or external system can correspond to several actors. To make the model clearer, you can represent the user or external system by one actor with child actors who share all the attributes of the parent. In this case the new generalized role is now associated with a use case instead of all the specialized actors. This increases the readability of the use case diagram and decreases the risk of "Actor Spaghetti" where too many communication lines make the overall diagram hard to grasp.

Pitfalls

Use actor generalization correctly by assuring that child actors have an "is-a" relationship to the parent. Just because two different actors can initiate the same use case doesn't mean that they're both the same type of actor. A common mistake is to generalize interactions that different actors have into a parent actor. Use actor generalization to represent essential qualities of the child actors, not groups of interactions.

For instance, a Bank Customer actor and a Maintenance Tech actor can both initiate the Balance Inquiry use case. So it may be tempting to generalize these two roles and create a parent actor that initiates the use case. However, these two actors have different goals and relationships with the system. A Maintenance Tech is only doing a balance inquiry as a means of testing the system. Representing them as having some identical essential qualities would be misleading.