Chapter 1. Actors

The modern approach to software engineering is to build models of the real world in a given problem domain. However, a software system is much more than a set of cooperating objects or code modules. The value of a software system lies in its behavior. This behavior often manifests itself in the interaction with entities (such as users and other software systems) outside the system. The system perceives the interaction between it and these external entities as events that it must acknowledge in some way.

When an event occurs that causes interactions between a software system and its environment, entities in the environment are involved in the interaction. Some of the entities initiate the event, others interact with the system as a result of the event. In use case modeling, these entities are known as actors. Actors help us to find use cases by helping us to understand what interactions will occur in a system. This chapter describes these external entities. Throughout this chapter, we use descriptive graphics to represent actors; we return to the use of standard UML notation for actors in the next chapter.

What Is an Actor?

An actor is an entity that interacts with the system for the purpose of completing an event [Jacobson 1992]. Examples of actors include a bank customer submitting a loan application to a bank and a travel agent determining seat availability using the World Wide Web to access a reservation system (Figure 1-1).

Figure 1-1. Interactions between systems and actors in the environment

Actors aren’t necessarily human users of the system. They can be other systems, external organizations, external devices, and other external entities that interact with the system—anything external that interacts with the system (Figure 1-2).

Figure 1-2. Examples of actors

When an actor is human, it is a role played by a user interacting with the system. An actor is not a single individual or a specific entity. For example, an actor is modeled by the concept of customer, not by Jane Smith the customer (Figure 1-3).

Figure 1-3. Actors are roles

Just as an actor can model many people or instances of the role, an individual person can play more than one role: bank manager Jane Smith can also be a customer of the bank. Specifically, an actor can be thought of as a tangible external entity that has some interaction with system and that plays a role. There are some exceptions to these guidelines. When there is a specific physical entity, such as an existing inventory system or temperature sensor that is known to have interactions with the system, that entity can be explicitly modeled as an actor.

Why Define Actors?

The roles actors play provide perspectives on why the use case is needed and on its outcome. For example, the reason a particular actor initiates a use case is almost always a major factor in why the use case is needed in the first place. The actor’s role in the environment and the unique behaviors and system responsibilities will provide stong influences on the use case. Subtle differences in the role an actor plays can produce variations in the use case interactions. For example, determining that a loan processing system needs to respond to both business and individual customers identifies the need to model unique use cases on the specific needs of both business and individuals.

By focusing on the actors, you can concentrate on how the system will be used instead of how it will be built or implemented. Focusing on the actors helps to refine and further define the boundaries of the system. Actors also determine the completeness of the system requirements. That is, given a role, you can ask, “What other system interactions will this role require?” Finally, the actors can be a factor in deciding whether to have complete and independent subsystems and/or increments that deliver business value (Figure 1-4).

Figure 1-4. Influence of actor roles on system behavior

Defining the actors helps to identify potential users that need to be involved in the use case modeling effort. For example, when modeling the interactions between a customer service representative and a telephone customer care system, it is very important to understand the customer service representative’s perspectives, needs, and desires. Without knowing whom to talk to concerning the behavior specific to a use case, how can we understand system requirements? Identifying the actors explicitly helps to direct us to the individuals we need to engage in the modeling effort. It also helps to direct us to the individuals who will need to validate the behaviors defined in the use cases (such as users and customers). Even if the requirements are “already specified,” many questions will need to be answered as the details of the system unfold.

How to Find the Actors

When performing use case modeling, review the following sources of information for potential actors of the system.

• Existing context diagrams and other models that describe the boundary of the system with its environment. Look for external entities that have interactions with the system.

• The stakeholder analysis that determines which group of people will interact with (champion, develop, use) the system (discussed in more detail in Chapter 6).

• Written specifications and other project documentation, such as memos about meetings with users, help to identify users who may be potential actors.

• Minutes of requirements workshops and joint application development (JAD) sessions. Participants in these sessions may be important because the roles that they represent in the organization may interact with the system.

• Training guides and user manuals for current processes and systems. These guides and manuals are often directed at roles representing potential actors.

When looking for actors, ask the following questions:

• Who or what initiates events with the system?

• Who or what interacts with the system to help the system respond to an event?

• Are there any reporting interfaces?

• Are there any system administrative interfaces?

• Will the system need to interact with any existing legacy systems?

• Are any actors already defined for the system?

• Are there any other hardware or software devices that interact with the system that should be modeled during analysis?

• If an event occurs in the system, does an external entity need to be informed of this event? Does the system need to ask an external entity a question to help it perform a task?

Since an actor is any entity that interacts with the system, it is helpful to understand, within a specific use case, how the actor interacts with the system. Does the actor initiate the event, or does the actor’s interaction involve helping the system respond to the event? Identifying how the actors interact helps to organize the actors and clarify the interactions and interfaces defined in the use case. Actors can participate in the use case in different ways. One actor can expect measurable value from the use case, while another is involved only to “help” the system provide the measurable value. Different requirements are associated with each kind of actor.

Primary and Secondary Actor Types

A use case is not limited to a single actor; any number of actors may be participating in the case. However, a use case exists to provide value to at least one actor. The actors that participate in a use case themselves have different roles and responsibilities to play: some will receive value, others will provide a service, others will help trigger or initiate the use case.

Ivar Jacobson [1992] has categorized actors into two types: primary and secondary. A primary actor is a user who will obtain value from the system. The needs of the primary actors drive the behaviors or functionality represented in the use case. If their needs or roles change, significant modification to the system will have to occur.

As an example, imagine that a loan processing system is in use by internal bank employees. A new Web-based loan application system is being considered for business reasons. While we may be able to adapt certain business rules from the original system, we cannot just slap a Web-based interface on the existing system. Bank employees will have different system privileges than external loan applicants. Access to other loan information is generally available to members of the loan department but not to the Web applicants. Usability requirements are also different. Loan department employees can take classes on how to use the system. The Web applicant must be able to navigate the system with no training at all.

We recommend that you start with primary actors when developing use cases. When identifying primary actors, consider the following questions.

• What business function does the actor perform for the business or organization?

• What is the measurable value of the roles and responsibilities achieved by the actor? The answer will drive much of the behavior and requirements defined in the use case. Any change to this value can significantly affect these behaviors.

• What behaviors must the system provide to satisfy this value?

• What business needs or requirements are associated with the value?

• Are there timing, performance requirements, or other interface requirements associated with the value?

Secondary actors provide service in the use case and would not exist if there were no primary actors. Secondary actors typically participate in the use case to support creating value for other actors. Examples of secondary actors in a loan processing system include operations personnel who install a system or provide backups of the loan information. When identifying secondary actors, ask the following questions.

• What value is this actor supporting in the use case? Will changes or refinements to the value as the system is developed affect this actor?

• Are there timing, performance, or other interface requirements associated with the service?

Actor Personalities

Actor personalities can be used to guide the process of discovering and identifying actors who can participate in a use case. An actor can have multiple personalities within a use case and across multiple use cases, depending on the specific interactions they are involved in. Actor personalities are summarized in Table 1-1.

Table 1-1. Summary of actor personality types

An initiator is an external entity that initiates a behavior of the system for the purpose of completing an event. An initiator can request a service or otherwise trigger the event. A customer applying for a loan at a bank is an initiator of the event “apply for loan.” An initiator may or may not be a primary actor. When identifying an actor with a initiator personality, ask the following questions:

• What event does this actor initiate? Does this event start the use case?

• Is the event based on time? In many cases, the initiator of a use case is the actor that receives some value from the system (primary actor). However, in the case of batch processing or other time-dependent situation, what triggers the use case?

• What are the requirements for the way the actor interfaces with the system? This question often discovers information, timing, and capacity requirements.

An external server personality is an external entity (person, organization, or external system) that responds to a request by the system. External servers assist the system in satisfying its responsibilities by providing a service. For example, in the “apply for loan” use case example, the loan processing system queries a credit bureau for information on the customer’s credit worthiness. The credit bureau is an external server, since it responds to a request for a service. A server personality is almost always a secondary actor. When identifying an actor with a server personality, ask the following questions.

• What service does the actor provide? How is it related to the value the use case provides to another actor?

• What are the interface requirements associated with this actor—information, timing, capacity?

• If the server actor is another system, will behaviors of that system need to be modified or developed to support its role in this use case? (We have seen that requirements for other systems interfacing with the system to be built tend to be overlooked, resulting in unexpected and additional work on the project.)

External receiver personalities receive information from the system. An example of an external receiver would be a data warehouse that is outside the system and receives information from the system. When identifying an actor with a receiver personality, ask the following questions.

• What information does this actor receive? Why does this actor need the information? An enterprise data warehouse, for example, would need information for customer analysis.

• What specific data format requirements does this actor have? Receivers usually need information in specific data formats.

• What are the interface requirements associated with this actor—information, timing, capacity?

When a primary actor needs to access service performed by the system but does not always interact with the system directly, the interaction can be carried out for the primary by another actor that acts as facilitator. For example, a loan request can be submitted directly to the system by the customer either via the Web or via a paper loan application that is then entered by a data entry clerk. The data entry clerk actor can be viewed as having a facilitator personality; it helps the customer submit a loan. (See the Interesting Issue box on page 13 for a detailed discussion of this topic.)

When identifying an actor with a facilitator personality, ask the following questions.

• What services does the facilitator perform?

• What restrictions does the facilitator place on the primary actor’s interactions with the system?

• Does a special interface have to be built to accommodate this actor?

• Is there is a possibility that the facilitator will be replaced or complemented in the future with automation such as a GUI interface?

Facilitators can be easily confused and misused. A facilitator should be restricted to a specific entity (person or software system), not to general tools or utilities such as a POP3 mail server or paging system. Selecting these general tools as facilitators will hide the actual actors who use the system.

One way to distinguish between initiators and servers/receivers is to determine the direction in which the interaction is occurring. If the actor is initiating the interaction, then the actor is probably an initiator, and this is the start of the use case (Figure 1-5). If the system initiates the interaction, then the interaction is probably taking place to support an event initiated by an another actor. If an actor both initiates and responds to subsequent requests of the system for more information within the same use case, consider that actor to be an initiator. However, if the direction in which the interaction will occur is not clear, do not spend too much time worrying about these relationships. The actor relationships aid in understanding the external entities. However, the system is the important element and should be the subject of concentration.

Figure 1-5. Example of an initiator and a server

It should be noted that there is discussion within the use case modeling community about the level of detail needed to define an external server or receiver. The discussion centers on whether the information in a use case should be only that which is visible to the user. (The pros and cons of this issue are discussed later.)

When finding actors, it is important to identify and understand the different personalities an actor can have so that the requirements for interfacing with external entities can be defined, evaluated, and specified. It is not, however, a good idea to try to rigidly classify each actor into a predefined personality type; instead, use personalities to help you identify actors and their participation in the use case.

Abstract Actors

Some actors play a conceptual role, others a more concrete one. For example, the model of a bank might have in it the role of customer, which takes advantage of a variety of services. The model of a loan processing system, on the other hand, might include a more concrete role, such as applicant or borrower. In a sense, an applicant and a borrower share the properties of being a bank customer. However, the customer role may not be specific enough to capture all the elements necessary to describe a user of a loan processing system.

In this case, the customer is the “superrole” and the borrower or applicant are the “subroles.” The relationship between these two types of roles is generalization. In modeling actors, generalization is used to represent the commonality and differences between two entities. The purpose of this representation is to develop a use case model with as little redundancy in actor communication with the system as possible [Jacobson 1992].

An abstract actor represents shared or common behavior between two or more actors. Abstract actors always perform a superrole. An abstract actor, however, may not be apparent during the process of finding actors. Instead, abstract actors are created to factor out the common behavior resulting from two concrete actors interacting in the same way with the same use case or use cases. An abstract actor differs from the actors (often called concrete actors), and this becomes apparent in system analysis. An abstract actor is made up, so the system has no actual entities that play that role. This concept is similar to the concept of the abstract superclass in object-oriented languages.

Early in the process of finding actors, it may be difficult to determine the abstract actors. However, as the analysis progresses and interactions between system and actors become more detailed, the interaction between the actors and the system will become clearer. Abstract actors typically evolve as the model is refactored and commonalities are discovered.

Actor Notation

We recommend using the UML notation for actors. As an extension to UML, following is a customizable template for actor specification. The template contains fields for the actor’s name, the actor’s description, and whether the actor is abstract. Obviously, an integrated CASE tool to capture the actors and to link them to the use cases is optimal. The set of actor definitions for a use case model is called the actor glossary.

Conclusion

Actors are a core concept in use case modeling. There is no more important phrase than “Know thy user.” Actors are means to identifying and documenting the users of the system so that the users’ needs can be modeled and validated. The goal is to ensure that the system ultimately will meet their needs.

Finding and representing actors can be a challenge in a large system development effort. When identifying actors, remember that they can have different personalties when interacting with the system. Some will initiate use cases; others will provide service. Each use case will have an actor that receives observable value from the system. Additionally, look for those external entities (secondary actors) that support the system.