This chapter examines the other parts of a use-case model—that is, the actors of the system and the associations between the actors and the use cases. An actor models a role that is played by a user of the system when utilizing the system—that is, when the user interacts with use cases (see Figure 5.1). Because the actors are played by the users of the system, all the actors appear outside the system being modeled. As we are modeling the system, the role of an actor is defined from the system's point of view—the actors model how the system perceives its environment.
Figure 5.1. A system perceives its users as playing different roles toward the system. All persons who withdraw money using an ATM act as ATM Customers toward the ATM, whereas one user category of a Sales Management System is represented by an actor called Sales Manager.
Everyone who is using the system is playing a role defined by an actor. An actor can be played both by humans and by machines, like robots and other computer systems. What is important is that the human or the machine is using the services of the modeled system. An actor can interact with several use cases, which means that an individual playing the role defined by the actor uses the system in the way that is modeled by these use cases.
Sometimes a use case in its turn needs to interact with someone outside the system, a person or a machine or so on to complete its task. This someone is also outside the system and is therefore modeled as an actor. It can either be the actor who initiated the use case or another external user. These latter external users are also actors to the system. They may not have been identified at the beginning of the development process, but were added later when the details of the use cases were described and it became clear that a use case must interact with other external users.
One actor can interact with several use cases. This means that a user will interact with instances of one or several of the use cases associated with that actor. Similarly, one use case can interact with one or several actors, which implies that several users are participating in the performance of the use case. For example, two actors will participate in the use case Local Call: the Caller and the Callee. This example makes it obvious that an actor does not model a user; it models a role played by a user. As a user of a telephone exchange, Jenny will initiate as well as receive calls. When initiating a call Jenny will play the role of a Caller, and she will act as a Callee when receiving a call.
An actor has a name, which is a noun phrase in singular form and usually contains several words. The name should describe the role the actor plays from the system's point of view; that is, when naming an actor, one should move oneself inside the system and describe the role the user is playing. In this way, new kinds of users can be introduced in this role without having to rename the actor.
Actors for whom the system is built are called primary actors. These are most likely to be identified when the use-case modeling starts. Secondary actors are the external users who use the system so that the primary actors can have their tasks performed. In the ATM example, the ATM Customer is a primary actor, whereas the Bank and the Maintenance Person are secondary actors; they interact with the ATM so that the ATM Customer can use it and perform his or her tasks. Another example is the Clerk of the ticketing system, where the Clerk is a primary actor, and the Airline Company and the Operator are secondary actors.
It is important to understand that an actor models a user from the system's perspective, and not a role in the business where the system is used. Otherwise, you will sooner or later get into trouble when defining what a use case interacts with and how many users will participate in the performance of a use case. Consider a warehouse example. In the business where the system is used, there are, among others, managers and salespersons. Therefore, we have two business roles: Manager and Salesperson. In the example, both managers and salespersons expedite orders that customers want to place. Therefore, from the business roles' perspective, both of them are performing the Order Item use case. However, let us now move over to the system's perspective. How many users participate in the performance of the Order Item use case? From this perspective, there is only one, namely the user entering the order information. Therefore, there is only one actor, called Clerk, interacting with the Order Item use case (see Figure 5.2). The use case receives the order information from the Clerk, creates the order, and prints it to the Clerk. From the system's perspective, it is of no consequence whether it interacts with a manager or a salesperson. If we were to model the business roles as actors, we would end up with two actors interacting with the Order Item use case, which is clearly not true. Remember that the actors model the users from the system's perspective, not from the business' perspective.
Figure 5.2. Persons acting as Managers or Salespersons in the business act as Clerks toward the Order Item use case.
Consider another implication of the fact that actors are defined from the system's, or the use case's, point of view: As an actor models a role played by an entity external to the system utilizing a use case, anyone outside the system utilizing that use case will play the role defined by the actor; that is, it can be a person as well as another system. Therefore, we do not introduce one “person actor” and one “system actor” playing the same role toward the use case, because the use case interacts only with one actor (see Chapter 23, “Multiple Actors”). If different sequences of actions are to be performed depending on whether the user is a person or a system, there should probably be two use cases, possibly interacting with different actors. However, if the sequences of actions are the same regardless of who the user is, there is only one use case and hence only one actor.
At a concrete level, it is likely that the actual messages sent between the system and the external user differ depending on whether the user is a person or a machine. This is not visible at the use-case level, however. Instead, such information is captured in the realization of the use case, where different boundary classes—responsible for transforming messages between user and system (see Chapter 15, “Mapping Use Cases onto Classes”)—are used for the different kinds of users (see Figure 5.3).
Figure 5.3. One use case can have multiple use-case realizations depending on the external entity playing the role of the actor. Details of the diagram are explained in Chapter 15.
A grave error, although quite common, is using actors to model security levels defined for the users. The problem with using the actors to express the security levels is that no security checks will be performed by the system with this kind of model. All checks that must be performed by the system must be included in the use cases. As we know, actors model how the users of the system are perceived by the system. Anyone performing a use case associated with an actor will therefore be regarded by the system as an instance of that actor, regardless of whether the person or machine is allowed to use this use case or not.
Of course, it is not wrong in itself to have actors that correspond to security levels—in some cases this may even make it easier for user representatives to understand the model—as long as it is clear that this does not add any constraints on security checks in the system. This must still be expressed in the use cases! For a more thorough description of the problem and what a correct model would look like, see Chapter 27, “Access Control.”
Obviously, the error in capturing security requirements by attaching them to actors is just a special case of a general pitfall: No requirements on the system can be captured by actors! The actors represent the outside of the system; hence, they do not pose any constraints on how the use cases inside the system are implemented. Anything that the system must fulfill must be expressed in the use cases.
That an actor and a use case can and will interact with each other is expressed by means of an association between the two. However, this association does not state what they communicate, when they communicate, or how they communicate. As with the associations between classes, the multiplicity of the association states how many instances of the use case one instance of the actor (one user playing the role defined by the actor) may simultaneously communicate with, and vice versa. Similarly, the navigability of an association between an actor and a use case describes who initiates any type of communication between the two. Usually, the association is navigable in both directions. These detailed specifications of the associations are often omitted in the use-case models, but if needed, they can be defined (see Figure 5.4).
Figure 5.4. One ATM Customer will communicate with one instance of the Withdraw Money use case at a time, and each instance of the Withdraw Money use case will communicate with one ATM Customer and one Bank System. Note that the Bank System may be contacted by several instances of Withdraw Money at the same time.
In some cases, it might be informative to explicitly describe how the use case and its actors interact with each other. This can be done using ordinary UML sequence diagrams, for example.
Draw a sequence diagram with the actors and use case as participants—that is, as columns in the diagram—and then add arrows between the columns representing the interaction between the actors and the use case (see Figure 5.5). Note that this diagram does not describe the use case; it describes how the use case is used by its environment (the actors). More precisely, the sequence diagram describes (a part of) the business use case that is partly automated by the system.
