لطفا منتظر باشید ...
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.
