UML Specification Excerpts about Role
(and not Actor)
1. V1.5 UML Specification
Quotes are directly from the noted UML Specification in black font color. [My comments are in blue font color like this sentence.]
A coherent set of roles that users of use cases play when interacting with these use cases. An actor has one role for each use case with which it communicates.
[Note that by definition an actor is a set of roles. Also note that an actor plays a different role for every use case it communicates with.
Question: Have you ever seen roles documented?]
The named specific behavior of an entity participating in a particular context. A role may be static (e.g., an association end) or dynamic (e.g., a collaboration role).
2. UML 2.0 Specification
16.3.1 Actor Semantics:
Actors model entities external to the subject. Each actor represents a coherent set of roles that users of the subject can play when interacting with it. When an external entity interacts with the subject, it plays the role of a specific actor.
[Note the role above should be plays one of the roles. See 3. UML 2.1 Specification, 16.3.6 Use Case: below.]
3. UML 2.1 Specification
[No glossary - neatly avoids those pesky definitions! (2.0 had a glossary)]
16.3.6 Use Case:
Use cases may have associated actors, which describe how an instance of the classifier realizing the use case and a user playing one of the roles of the actor interact.
Instances of different classifiers can play a role defined by a given interface, as long as these classifiers realize the interface, i.e., have all the required properties.
[Here a role is equated to an interface.]
4. Jacobson in Object-Oriented Software Engineering
To stress the difference between actor and user, we think of an actor as a class, that is, a description of behavior. A user, on the other hand, can play several roles, that is, serve as many actors. For instance, think of Brian. He is the operator of the machine [a recycling machine], so he normally acts as an instance of the Operator actor. However, sometimes he deposits his own bottles and cans, and then he acts as an instance of Customer [actor].
[Note again that Jacobson equates actor with role.]
A.2.2 Development entity objects
In system development, entity objects are primarily used to model information about objects known to the system. … Actors are not development entity objects since we do not describe them.
[Somehow, the idea that actors do not even belong to the system being developed was lost. Part of the problem is that we do not visually notate system boundaries. If we did, it would be obvious that actors exist outside the system boundary. See
TAP Case Study
From Role UML Specification Excerpts to UML Specification Excerpts