Capture commonalities between actors while keeping separate roles apart.
Characteristics: Very common. Basic.
Keywords: Common role, different roles, generalization of actors, overlapping actors, several users of a use case.
The Multiple Actors: Distinct Roles pattern consists of one use case and (at least) two actors.
This pattern is used when the two actors play different roles toward the use case; that is, they interact differently with the use case.
In an alternative pattern, the two actors play the same role toward the use case. This role is represented by another actor, inherited by the actors sharing this role.
This pattern is applicable when, from the use case's point of view, there is only one external entity interacting with each instance of the use case.
When identifying use cases, we often find that two actors become associated with the same use case. Typically, this means that there are multiple external entities interested in using the system in the way modeled by this use case. However, in such situations it is important to find out whether the two actors play identical roles toward the use case or whether the roles differ. We need this information not only to understand the details of the use case, but also to define the interfaces of the system. We need to establish, from the use case's point of view, how many external instances will interact with each instance of the use case.
If two external instances are interacting with an instance of the use case and these external instances act differently, clearly two actors should be associated with the use case, and the Multiple Actors: Distinct Roles pattern is to be used.
In the telephone exchange example, two actors are associated with the
Local Calluse case (see Figure 23.1). Clearly, theCallerand theCalleeact differently from the use case's point of view. TheCallerinitiates the use case, dials the digits, and is charged for the call, whereas theCalleeis the subscriber who just answers the call. Therefore, it is correct to associate two actors with the use case.
However, if only one external entity is interacting with each instance of the use case, only one actor should be associated with the use case. Having two actors associated with the use case would give the impression that there will be two external instances interacting with each instance of the use case, which is obviously not correct. Instead, the Multiple Actors: Common Role pattern should be applied.
This situation typically occurs when people in different roles within the business use the same use case in the supporting software system. If these act differently toward the system in other contexts than this particular use case—for example, if they use different use cases—they should be modeled as different actors with generalizations to an abstract actor representing the common role. If they always play the same role toward the system, however, only the common role is relevant and the corresponding actor is instead concrete.
In the Airline ticketing example (see Figure 23.2), both a sales person and an outside agent can order tickets; that is, they can both make use of the
Order Ticketuse case. However, from the use case's point of view, there is only one external entity interacting with each instance of the use case. The salesperson and the agent will play the same role toward the use case, so the use case cannot perceive a difference between them. Therefore, there is only one actor associated with the use case. If we have already identified two actors in the model—SalespersonandAgent—because of other use cases, we must now introduce a new, abstract actor, calledClerk, and define an association between this actor and theOrder Ticketuse case. Because theSalespersonand theAgentactors are to be associated with that use case, we define a generalization from each of them to theClerkactor. In this way, both theSalespersonand theAgenthave an (inherited) association to theOrder Ticketuse case, and the use case is only associated with one actor.If
SalespersonandAgentare not needed as actors to other use cases, we just model one actor: theClerk.
This section provides two examples of use-case descriptions: Local Call (see Figure 23.1) as an example of the first pattern, and Order Ticket (see Figure 23.2) as an example of the second one. The former is associated with two actors, whereas the latter is associated with one. Obviously, the description of the Order Ticket use case does not indicate whether any actors have generalizations to the Clerk actor.
The Orthogonal Views as well as the Component Hierarchy patterns are probably useful in the first example, whereas the CRUD patterns may be relevant in the second example.
There is no analysis model for this chapter, because it is about modeling entities external to the system. However, we have three important comments to make:
Even if the use case is used by external entities of differing natures, such as a person and a machine, only one actor is associated with the use case if each use-case instance interacts with only one external entity. The difference in communication is handled by having two different boundary classes. In the example in Figure 23.3, the person will use a web page while the computer will interact through a communication protocol.
For each kind of external entity, there is one use-case realization of the use case. The differences between these use-case realizations are the boundary classes used by the different kinds of external users. However, these boundary classes will share the interfaces toward the interior of the system, such as the control classes. This interaction must be the same, even if the detailed messages sent to the external entities may be quite different.
The different kinds of external users may have different access rights to the system; that is, different levels of information and different functions of the system are available to them. However, this is no reason why we should split the use case into two or to allow two actors to play the same role toward the same use case. Instead, different access rights between the users are handled as is described in Chapter 27, “Access Control.”
