I l @ ve RuBoard

Actors are not part of the systemthey represent anyone or anything that must interact with the system. An actor may

  • Only input information to the system

  • Only receive information from the system

  • Input and receive information to and from the system

Typically, these actors are found in the problem statement and by conversations with customers and domain experts. The following questions may be used to help identify the actors for a system:

  • Who is interested in a certain requirement?

  • Where in the organization is the system used?

  • Who will benefit from the use of the system?

  • Who will supply the system with this information, use this information, and remove this information?

  • Who will support and maintain the system?

  • Does the system use an external resource?

  • Does one person play several different roles?

  • Do several people play the same role?

  • Does the system interact with a legacy system?

In the UML, an actor is represented as a stickman, as shown in Figure 3-1.

Figure 3-1. UML Notation for an Actor


What Constitutes a "Good" Actor?

Care must be taken when identifying the actors for a system. This identification is done in an iterative fashionthe first cut at the list of actors for a system is rarely the final list. For example, is a new student a different actor than a returning student? Suppose you initially say the answer to this question is yes. The next step is to identify how the actor interacts with the system. If the new student uses the system differently than the returning student, they are different actors. If they use the system in the same way, they are the same actor.

Another example is the creation of an actor for every role a person may play. This may also be overkill. A good example is a teaching assistant in the ESU Course Registration System. The teaching assistant takes classes and teaches classes. The capabilities needed to select courses to take and to teach are already captured by the identification of functionality needed by the Student and the Professor actors. Therefore, there is no need for a Teaching Assistant actor.

By looking at the identified actors and documenting how they use the system, you will iteratively arrive at a good set of actors for the system.

Actors in the ESU Course Registration System

The previous questions were answered as follows :

  • Students want to register for courses

  • Professors want to select courses to teach

  • The Registrar must create the curriculum and generate a catalog for the semester

  • The Registrar must maintain all the information about courses, professors, and students

  • The Billing System must receive billing information from the system

Based on the answers to the questions posed, the following actors have been identified: Student, Professor, Registrar, and the Billing System.


  1. Right-click on the Use Case View package in the browser to make the shortcut menu visible.

  2. Select the New:Actor menu option. A new actor called New Class is placed in the browser.

  3. With the actor called New Class selected, enter the desired name of the actor.

The Browser view of the actors for the ESU Course Registration System is shown in Figure 3-2.

Figure 3-2. Actors


Actor Documentation

A brief description for each actor should be added to the model. The description should identify the role the actor plays while interacting with the system.

The actor descriptions for the ESU Course Registration System are:

  • Student a person who is registered to take classes at the University

  • Professor a person who is certified to teach classes at the University

  • Registrar the person who is responsible for the maintenance of the ESU Course Registration System

  • Billing System the external system responsible for student billing


  1. If the documentation window is not visible, open the documentation window by selecting the Documentation menu choice from the View menu.

  2. Click to select the actor in the browser.

  3. Position the cursor in the documentation window and enter the documentation.

The documentation for the Student actor is shown in Figure 3-3.

Figure 3-3. Student Actor Documentation


I l @ ve RuBoard

Visual Modeling with Rational Rose 2002 and UML
Visual Modeling with Rational Rose 2002 and UML (3rd Edition)
ISBN: 0201729326
EAN: 2147483647
Year: 2002
Pages: 134

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: