Previous UML Classes Table of Contents UML Packages Next

16.3.1 Actor


   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


   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.


   No additional attributes


   No additional associations


   [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.



   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.


   An actor is represented by stick man icon with the name of the actor in the vicinity (usually above or below) the icon.


   Presentation Options

   An actor may also be shown as a class rectangle with the keyword «actor», with the usual notation for all compartments.



   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.


   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.