Frequently, multiple actors have associations with the same use case. For example, in the ATM example, both the ATM Customer and the Bank System are associated with the Withdraw Money use case. From the use case's point of view, it is clear that there are two external entities interacting with it—these two entities play different roles toward the use case (see Figure 12.1).
If only one external user is involved in the usage, however, only one actor is to be associated with the use case. Therefore, as soon as actors overlap—that is, they model the same role toward a specific use case (or a set of use cases) they are associated with—there is need for another actor to represent this overlapping role. This is because, as you may recall from Chapter 5, “Modeling the System Environment,” the actors represent how the system perceives its surroundings. Saying that two or more actors play the same role toward a use case is precisely the same as saying that the use case perceives them as one; that is, it is impossible for the use case to see any difference between these actors (see Figure 12.2). Hence, from the use case's point of view, there is just one actor playing this role, implying that the role should be represented by one actor.
Figure 12.2. This diagram gives the impression that the Look-Up Customer use case interacts with two different actors when it is performed, which is not the case.
Generalization is used to express that an actor incorporates the role defined by another actor. This is, in fact, the only kind of relationship that exists between actors. The actor modeling the common or shared role is called the parent actor, and the one incorporating the shared role is called the child. The relationship implies that a user playing the role defined by the child actor interacts not only with those use cases that the actor itself is associated with, but also with those use cases that the parent actor is associated with (see Figure 12.3). In other words, a child actor inherits the capability to communicate with use cases its parent actor is associated with, according to the description of those use cases (see also Chapter 23, “Multiple Actors”).
Figure 12.3. Both the Clerk and the Manager can create orders, but from the use case's point of view only one actor is involved.
A parent actor is more often than not abstract, because there are usually no individuals playing that specific role; as a rule, only the roles of the children are concrete. However, there are cases in which both the parent and the children roles are concrete. This usually occurs when the actors are quite close to business roles. This is in itself no error, but calls for an extra check that this is not the only way security levels are captured in the model (see Chapter 5, “Modeling the System Environment,” Chapter 27, “Access Control,” and Chapter 44, “Mistake: Security Levels with Actors”).
Generalizations between actors should only be introduced when it is clear that two actors are overlapping—that is, they play the same role toward a specific use case or a group of use cases.
Remember that actors define how the system perceives its surroundings; they do not model the roles of the business in which the system takes part (see Chapter 5). A common mistake is to introduce an actor representing a certain business role with no association of his/her own, but equipped with generalizations to all the actors interacting with the use cases that are of interest to that particular business role. Such an actor only adds to the size of the model.