UML Keywords: keywords are used much the same as stereotypes except that they are explicitly defined in the UML metamodel where stereotypes are not.
| Keyword || Applies to… || Meaning |
| Actor || Class || Specifies a coherent set of roles that users of a use cases play when interacting with these use cases |
| Bind || Dependency || Specifies that the source instantiates the target template using the given actual parameters |
| Exception || Class || Specifies an event that may be thrown or caught by an operation |
| Interface || Class || Specifies a collection of operations that are used to specify a service of a class or a component |
| Model || Package || Specifies a semantically closed abstraction of a system |
| Refine || Dependency || Specifies that the source is at a finer degree of abstraction than the target |
| Signal || Class || Specifies an asynchronous stimulus communicated among instances |
| Subsystem || Package || Specifies a grouping of elements of which some constitute a specification of the behavior offered by the other contained elements |
| Trace || Dependency || Specifies that the target is an historical ancestor of the source |
| Use || Dependency || Specifies that the semantics of the source element depends on the semantics of the public part of the target |
Users are referred to as Actors
The users are referred to as actors. An actor is a role that a user plays with respect to the system. Actors might include customer, customer service rep, sales manager, and product analyst. Actors carry out use cases. A single actor may perform many use cases;
conversely, a use case may have several actors performing it. Usually, you have many customers, so many people can be the customer actor. Also, one person may act as more than one actor, such as a sales manager who does customer service rep tasks. An actor doesn't have to be human. If the system performs a service for another computer system, that other system is an actor.
Actor is not the correct term and role would be more appropriate. Use cases are well known as an important part of the UML. However, the surprise is that in many ways, the definition of use cases in the UML is rather inadequate. Nothing in the UML describes how you should capture the content of a use case. What the UML describes is a use case diagram, which shows how use cases relate to each other. However, all the value of use cases lies in the content, and the diagram is of somewhat limited value.