Actor   An actor represents a set of roles that a user plays with an entity (system, subsystem or a class). Actors can be human or other systems, subsystems or classes that represent things outside of the entity. The actor "communicates" with the entity by sending a series of messages backwards and forwards.

Explanation

Actors are always external to the entity you are modeling, and represent the roles that people or other systems play when interacting with the entity. They are not individual users but are like the hats that people wear when using the entity. The entity here refers to an entire system, a subsystem or a class. It is far more common to apply the concept of actors and use cases to an entire system, but they are also very useful to model smaller or more granular parts of the system, particularly subsystems. By defining actors clearly, you have implicitly defined a boundary between what is inside and outside the entity you are modeling.

Important Points

		Actors are always external to the entity that is being modeled.		Actors are, by definition, roles that lie outside the entity that is being modeled. Some confusion arises here because of the fact that use cases and thus actors can describe subsystems that lie within the bounds of a system. In this case the actors that communicate with a subsystem, may lie within the larger system. Thus an entity viewed from one perspective may be a subsystem, but viewed from another it may be an actor. There is little support for this change of reference point in current tools.
		Actors are roles that a human or other systems play with respect to the system.		Actors do not represent users themselves, but the role that a user or group of users plays with respect to the system. They are like 'hats' that users put on when using the system.
		Actors can have associations with the elements that "realize" a use case.		At the level of implementation an actor can have associations with some of the elements that realize the behavior or value proposition of the use case. This is why instances of the actor appear on sequence diagrams, and actors can be seen on class diagrams. It is the external interfaces that the actor will have an association with such as boundary classes.
		Actors cannot have associations with other actors.		Even though people or systems play the "role" of a particular actor and people (and systems) clearly communicate with each other, the UML does not allow actors to have associations with each other. The only relationship that can exist between two or actors is the generalization relationship. This does not mean that communication between the two individuals does not exist in the real world. It simply means that when modeling the system or entity it is outside the scope of interest.
		An individual actor may be associated with more than one use case.		Actors can be associated with one or more use cases, and an individual use case may be associated with a number of different actors.
		An individual use case may be associated with more than one actor.		An individual use case may be associated with a number of different actors. The significance of this is that even though a single actor may initiate the use case a number of other actors may be affected by the use case.
		The association between an actor and a use case can involve at most one actor and one use case.		Actors and use cases are both classifiers, but even though other classifiers can participate in n-ary associations, actors and use cases cannot. The association between an actor and a use case can only involve a single actor and use case. This is known as a binary association. This does not mean that a use case cannot be associated with many actors or an actor be associated with many use cases. It simply means that a separate association must be used. It also does not restrict the use of multiplicity in the association.

Related Entries

Use Case  Used Together A use case is related to an actor because an actor communicates with a use case. The use case represents the system's value proposition to the actor. An association, that is most often un-named, can connect the two elements.

Class  Used Together A class is related to an actor because an actor can communicate with a class. In this circumstance the class represents a peripheral part of the system, with which the actor communicates.

Subsystem  Used Together A subsystem is related to an actor because an actor can communicate with a subsystem. A subsystem can have an interface and operations that represent the services that it offers, where these services lie on the perimeter of the system they are available to actors, and associations can be used between actors and the subsystem.