Casting the System s Actors | UML 2 For Dummies

Casting the System’s Actors

It’s easy to start identifying the main groups of actors (refer to Table 8-1) by taking a high-level view of the workers and customers who act as end-users. Evaluate these main actors to see if there are subdivisions with special privileges and capabilities. For example, in the hotel registration system, special types of Potential Guests represent large parties for conferences or affairs—typically they want to reserve blocks of rooms at a special price, and may also be reserving other hotel facilities. These Event Organizers are another type of actor for this particular system. Identifying these subgroups helps you construct an evolving list of actors for your system.

Tip Many systems have paired sets of actors. For every customer actor type, (for example) there is often a parallel worker actor type. The system allows the customer-actor to work directly with the system or through a worker-actor intermediary—which gives you two actors with paired roles. You might be able to treat both actors as only one actor if their user interface is identical (as it would be when their privileges are exactly the same)—but typically these paired actors use the system in different ways. In the hotel registration system, the customer-actors of Potential Guest and Event Organizer have paired worker-actors of Registration Clerk and Event Consultant.

When classifying actors, you have to consider all sources of input to the system. For example, a system typically needs input to define the evolving configurations. In the Registration system, someone—perhaps the Hotel Manager—must define configurations for the rooms, their prices, checkout policies, and the like.

Finding nonhuman actors

In UML, human end-users aren’t the only actors in the system. The term actor also includes everything that passes information or events directly to or from the system. Such actors include other systems/subsystems, other databases, hardware, and devices.

Incorporating system and database actors

You have to consider these nonhumans as actors even though they aren’t stakeholders—or (really) users of the system—for several reasons. Each external system that interacts with your system has its own stakeholders and actors. By modeling the external system as an actor, you capture it as a proxy—a symbol for the collected goals and requirements of these stakeholders and actors. The Hotel Reservation system must deal with an external Credit Card Authorization system. The Credit Card Authorization system, considered as an actor, works for you as a proxy for its clients, customers, and workers. Another such actor might be an external database (such as external Frequent Traveler database).

Ignoring internal components (databases and systems)

Tip When considering databases and other systems, you should only consider and model the external ones as actors. If they’re an internal part of your own system, you can just leave them off the diagram.

Adding an internal component to the list of actors doesn’t really add any value, because that component’s clients, customer, and workers are just a subset of your own system’s actors—not a source of new requirements or information. Even so, don’t just ignore the internal components; be sure to check whether any of them qualify as actors that must be added to your total list of actors.

Telling internal databases from external databases

Tip If a database is external, it should be modeled as an actor; if it’s an internal component, then it shouldn’t be modeled as an actor. Sometimes it’s hard to tell whether a database is external or internal; you have to look at the list of clients, customers, and workers who deal with the database. If the actors for the database are vastly different from the other actors of your system, don’t add them to your list; instead, treat the entire database as an external actor. If the actors for the database are mostly the same as your actors, then you probably have control over the database—and you can probably treat it as an internal component without flinching. For another way of looking at this criterion, consider that the more you think of a system component as under your control and design, the more likely it is to be internal. If you think of it as outside your control, then it’s most likely external, and best modeled as an actor.

Incorporating device actors

Input and output devices must also be considered potential actors:

Input Devices: Input devices (sometimes called sensors) have to be considered because they report on some condition or events in the outside world. A sensor typically serves in one of two roles:
- Proxy for the causer of the events: For example, a TV remote control acts upon the TV system to change the channel as an agent of the person using the remote control.
- Proxy for the setter of the sensor threshold: For example a thermostat in a refrigeration system. It reports when the temperature increases over a preset level. The thermostat is an actor because it acts for the person(s) who set the temperature threshold.
Output Devices: You should consider output devices because (by definition) they produce an effect or output for some stakeholder to use, or to comply with a stakeholder’s wishes. The compressor in a refrigeration system (for example) is an actor because it acts upon the system’s contents to satisfy the wishes of the person who wants the contents cold.

Consider the card reader in an ATM system. It reads the card to get identity and account data of the patron. As such, it acts for the person as a way of getting his or her data into the system—therefore it should be considered an actor. The display in an ATM system is an actor for much the same reason because it outputs data to the user. When the whole unit is essentially one device, you can combine the card reader, display, keyboard, and so on into one (complex) actor for your system.

Ignoring transparent actors

Tip Don’t treat all sensors and devices as actors. Most devices are so ubiquitous that you deal with them transparently. Consider the standard keyboard, display screen, and computer mouse. These hardware elements can often just pass data or events from your system to its actors so easily that you consider its direct actions as your own. Standard computer hardware provides examples of internal design elements that are so well understood or easy to use that you need not (typically) consider them as sources of system requirements. They are transparent to the system.

Incorporating clock actors

An actor starts every thread of activity in your system. To complete the identification of the actors, you may have to include a device—in this case, a clock—as an actor to initiate internal scheduled activities. The clock-actor stands in for the stakeholder who scheduled the activities. In the Hotel Reservation system, the Clock automatically cancels room reservations if the Guest hasn’t arrived by some cutoff time.

Identifying the roles of the actors

As you look for actors for your system, consider that an actor isn’t a specific person, but rather, a role in which a person may act. Don’t use individuals’ names. (They may be stars, but from the system’s viewpoint, they’re only instances of roles.) Individuals often serve as different actors, depending on what part of the job they’re doing. The same person may act as a Registration Clerk and then later as an Event Consultant, depending on the job flow.

Also, consider that job titles alone may not be sufficient to distinguish actors. A particular job title such as hotel manager may encompass several separate roles—you may have to define several actors, one for each role. In your diagram, reserve the actor Hotel Manager for the role that only a hotel manager can play.

One way you may try to distinguish the different roles an employee may play is to construct a class diagram around the employee, where each employee is considered a class. (Class diagrams with roles are discussed in Chapter 4.) If there are several different relationships (associations) connecting the employee to the other system elements, then there is a separate role for each association the employee participates in. Usually each of these roles would be a separate actor. You can see an example in Figure 8-1, where an employee with the job title of Hotel Desk Clerk acts in at least two roles—Reservation Clerk and Check-In Clerk—and these are the true actors of the system.

Figure 8-1: Using roles to find actors.

Naming the actors

Actors are very much like classes, so you should use nouns to name your actors. Generally, the names of human actors should be singular-agent nouns formed from an active verb. In English, many of these end in -er or -ant, though they may end in -or, -ee, or -ar (Customer, Organizer, Consultant, Debtor, Professor, Employee, Registrar). Be sure to examine the role names that come from association roles in the class diagram (as discussed in Chapter 4). These often contribute such standard names as Reservation Clerk, Check-In Clerk, Guest, Student, or Patron, which identify specific types of relationships between actor and system. If an employee who has a particular job title acts in only one role, you can use the job title as the actor’s name.

When naming the nonhuman actors, you can use the name of the role that the hardware or external system performs relative to your target system. Or, you may find it convenient to use the given name of the system to simplify identification. For example, if there is an external system to authorize the potential guests’ credit cards, it is acting in the role of CreditCardAuthorizer, and that’s not a bad name for it as an actor. But if it’s already well known by a specific name such as credit card authorization system, then that might be a better name for the actor.