The UML Notation Guide defines the actor [Rational Software 1997a, p. 77]:
An actor is a role of object or objects outside of a system that interacts directly with it as part of a coherent work unit (a use case). An Actor element characterizes the role played by an outside object; one physical object may play several roles and therefore be modeled by several actors.
Actors represent the context of the use case. By developing your actor model carefully, you can better understand who or what is going to use which parts of your system. As you map use cases to your database design, you will fill in blanks as you realize that certain actors need access to certain data elements in specific ways.
An actor may be a user, but an actor may also be another software subsystem or even a piece of hardware [Rational Software 1997b]. Use cases do not limit you to representing the overall system. You can
represent the use of any interface, internal or external, with use cases. For example, consider a subsystem that represents image processing of crime scene photographs. This subsystem provides a series of
services to other subsystems of the overall commonplace book system. Developing a use case diagram for this subsystem provides you with measurable, testable requirements for the crime scene subsystem as a part of the overall system. The end user may not be the actor for this use case, however. Instead, the other subsystems of the commonplace book become its actors.
To develop your actor model for a system, you must first carefully define the boundaries of the system. The requirements gathering process in Chapter 3 results in a broad description of the system. You can start with these requirements to work out your first pass at an actor model.
For example, for the commonplace book system, various requirements refer to certain roles in the system:
Consulting private detective (the main client of the system)
Marketing and sales person (identifies revenue opportunities and gathers testimonial data)
Police and media suppliers (supply information to the system)
Data entry clerk (enters new data)
Data quality engineer (ensures high quality of data in database)
Database administrator (maintains database)
Security administrator (maintains security system)
Legal representatives (resolve privacy and intellectual property issues)
These actors all have some reason to use the system, and the system must supply transactions (use cases) for those actors.
It may be that certain actors relate to other actors in generalization relationships. For example, a security administrator may be a kind of database administrator, or a database administrator may also use the system as a consulting private detective. A detective can also be a data entry clerk if you decide to integrate data entry of case information with the query interface, letting detectives enter case information as they get it. Figure 4-1 shows an actor model with some actor hierarchies. In this case, the model breaks down the consulting private detective into several types based on the type of case with which they deal. The different kinds of actors will use different parts of the commonplace book. You could alternatively break down detectives by security classification if that will have a major impact on system structure. Modeling actors in a hierarchy lets you simplify your use case descriptions. In this context, inheritance means that a subactor inherits the role played by its super-actor parent. Anything a consulting private detective can do, an administrator can do. If you didn't model these overlaps in roles, you would need to connect administrators to the same use cases as the detectives. Now, all you need to do is to model the detective use cases, then show where administrators do something in addition to what a detective can do. This works both ways, of course. A detective uses a certain set of use cases in the system, sharing these with the administrator. But the administrator uses certain use cases not available to the detective.
Actors also perform passive roles in the system. You can define various external elements that the system controls or uses as actors if it has an impact on requirements. An important use for this approach is to define "the database" as an actor. You can integrate your knowledge about the database structure in a first cut at system architecture. For example, it may be that the commonplace book system requires four databases. The first is a U.S. database containing facts relevant to detective practice in the United States. The second is a U.K. database containing facts relevant to international operations around the world. The third is an image database containing photos, fingerprints, DNA profiles, and other images. The fourth is a text database containing media text and graphics. These latter two systems also provide different
interfaces (image searching and text searching engines, for example) that distinguish them from the standard SQL fact databases. You can use these actors to show how the different use cases use the database systems.
Figure 4-1: A Use Case Actor Hierarchy
The database actors also provide a way for you to specify the use of data elements from the database in the use cases. In the details of the use case, you can enumerate the tables and columns or objects that you will use and relate them to the specific database schema in which they appear. See the section "Data Elements and Business Rules Summary" for details.
Defining the hierarchy of actors gives you the staff to use in populating your stage: the use case model.