Previous | UML Classes | Table of Contents | UML Packages | Next |
An actor specifies a role played by a user or any other system that interacts with the subject. (The term role is used informally
here and does not necessarily imply the technical definition of that term found elsewhere in this specification.)
Issue 8078 -Actor specializes BehavioredClassifier instead of Classifier.
•
BehavioredClassifier (from BasicBehaviors , Communications ) on page 451
Description
An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data),
but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its
corresponding subject). Actor s may represent roles played by human users, external hardware, or other subjects. Note that
an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., role) of some entity
that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several
different actors and, conversely, a given actor may be played by multiple different instances.
Since an actor is external to the subject, it is typically defined in the same classifier or package that incorporates the
subject classifier.
Attributes
No additional attributes
Associations
No additional associations
Constraints
[1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary.
self.ownedAttribute->forAll ( a |
(a.association->notEmpty()) implies
((a.association.memberEnd.size() = 2) and
(a.opposite.class.oclIsKindOf(UseCase) or
(a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))
[2] An actor must have a name.
name->notEmpty()
Semantics
Actor s model entities external to the subject. When an external entity interacts with the subject, it plays the role of a
specific actor.
When an actor has an association to a use case with a multiplicity that is greater than one at the use case end, it means
that a given actor can be involved in multiple use cases of that type. The specific nature of this multiple involvement depends
on the case on hand and is not defined in this specification. Thus, an actor may initiate multiple use cases in parallel (concurrently)
or they may be mutually exclusive in time. For example, a computer user may activate a given software application multiple
times concurrently or at different points in time.
Notation
An actor is represented by stick man icon with the name of the actor in the vicinity (usually above or below) the icon.
Customer
Presentation Options
An actor may also be shown as a class rectangle with the keyword «actor», with the usual notation for all compartments.
«actor»
Customer
Other icons that convey the kind of actor may also be used to denote an actor, such as using a separate icon for nonhuman
actors.
User
Style Guidelines
Actor names should follow the capitalization and punctuation guidelines used for classes in the model. The names of abstract
actors should be shown in italics.
Changes from previous UML
There are no changes to the Actor concept except for the addition of a constraint that requires that all actors must have
names.