4.1 Actors

As discussed in Chapter 2, an actor is a user or external system with which a system being modeled interacts. For example, our project management system involves various types of users, including project managers, resource managers, human resources, and system administrators. These users are all actors.

Actors follow the type-instance dichotomy first discussed in Chapter 2 and applied to classes and objects in Chapter 3. You can use the UML to talk about classes of actors, as well as specific actors of a class. When speaking of a class of actors, it's customary to use the terms actor or actor class. Thus, while you might think of an actor as a specific thing, in the UML, an actor really represents a class of things. When speaking of a specific actor of a class, use the term actor instance.

An actor is external to a system, interacts with the system, may be a human user or another system, and has goals and responsibilities to satisfy in interacting with the system. Actors address the question of who and what interacts with a system. In the UML, an actor is shown as a "stick figure" icon, or as a class marked with the actor keyword and labeled with the name of the actor class.

Figure 4-1 shows various actors associated with the project management system:

A project manager

Responsible for ensuring that a project delivers a quality product within specified time and cost, and within specified resource constraints

A resource manager

Responsible for ensuring that trained and skilled human resources are available for projects

A human resource

Responsible for ensuring that worker skills are maintained, and that quality work is completed for a project

A system administrator

Responsible for ensuring that a project management system is available for a project

A backup system

Responsible for housing backup data for a project management system

Figure 4-1. Actors

An actor instance is a specific user or system. For example, specific users of the project management system include Jonathan, Andy, Si, Phillip, Nora, and so forth. An actor instance is shown similar to an actor class, but is labeled with the actor instance name followed by a colon followed by the actor class name, all fully underlined. Both names are optional, and the colon is only present if the actor class name is specified. Actor instances address the question of who and what specifically interacts with a system.

Figure 4-2 shows various actor instances of the actor classes in Figure 4-1, including Jonathan and Andy who are project managers, Si who is a human resource, Phillip who is a system administrator, Nora who is an unspecified type of actor instance, a backup system named BackupSys1.0, and other actor instances. Just as it's possible to have an actor of an unspecified type, such as Nora, it is possible to have actors such as HumanResource for which a type is specified, but not a name.

Figure 4-2. Actor instances

Because actors are external to a system and interact with that system, they define the boundary or scope of the system. For example, given the actors shown in Figure 4-1, we know exactly who and what will interact with the project management system. If we don't define our actors, we may fall into the trap of endlessly debating whether we have identified all the users of the system and all the other systems that interact with the system. Consequentially, because every functional requirement should be of interest to at least one user (otherwise, why would we build the system to provide the functionality?), without identifying actors, we have no way of knowing whether we have identified all the functional requirements of the system. An actor may also represent a resource owned by another project or purchased rather than built. For example, the backup system must be provided by another project, and it may be purchased from a vendor or built rather than purchased. Independent of how it is developed, we are interested in interacting with it as a resource.