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.
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 may 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.
|