Class Descriptions


Actor (from UseCases)

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

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). Actors 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 some 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, subsystems, components and classes, and these associations must be binary.

[2] An actor must have a name.
       name->notEmpty()

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.

Notation

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 non-human 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.

Rationale

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.

Classifier (from UseCases, as specialized)

Description

Extends a classifier with the capability to own use cases. Although the owning classifier typically represents the subject to which the owned use cases apply, this is not necessarily the case. In principle, the same use case can be applied to multiple subjects, as identified by the subject association role of a UseCase (see "UseCase (from UseCases)" ).

Attributes

No additional attributes

Associations
Constraints

No additional constraints.

Semantics

See "UseCase (from UseCases)" .

Notation

The nesting (owning) of a use case by a classifier is represented using the standard notation for nested classifiers.


Rationale

This extension to the Classifier concept was added to allow classifiers in general to own use cases.

Changes from previous UML

No changes.

Extend (from UseCases)

A relationship from an extending use case to an extended use case that specifies how and when the behavior defined in the extending use case can be inserted into the behavior defined in the extended use case.

Description

This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case. On the other hand, the extending use case typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending use case defines a set of modular behavior increments that augment an execution of the extended use case under specific conditions.
Note that the same extending use case can extend more than one use case. Furthermore, a extending use case may itself be extended.

It is a kind of DirectedRelationship, such that the source is the extending use case and the destination is the extended use case. The extend relationship itself is owned by the extending use case.

Attributes

No additional attributes.

Associations

  • extendedCase : UseCase [ 1 ]
References the use case that is being extended. (Specializes DirectedRelationship.target.)
  • extension : UseCase[1]
References the use case that represents the extension and owns the extend relationship. (Specializes DirectedRelationship.source.)
  • condition : Constraint [0..1 ]
References the condition that must hold when the first extension point is reached for the extension to take place. If no constraint is associated with the extend relationship, the extension is unconditional. (Specializes Namespace.ownedMember.)
  • extensionLocation: ExtensionPoint [ 1..* ]
An ordered list of extension points belonging to the extended use case, specifying where the respective behavioral fragments of the extending use case are to be inserted. The first fragment in the extending use case is associated with the first extension point in the list, the second fragment with the second point, and so on. (Note that, in most practical cases, the extending use case has just a single behavior fragment, so that the list of extension points is trivial.)

Constraints

[1] The extension points referenced by the extend relationship must belong to the use case that is being extended.

extensionLocation->forAll (xp | extendedCase.extensionPoint->include(xp))

Semantics

If the condition of the extension is true at the time the first extension point is reached during the execution of the extended use case, then all of the appropriate behavior fragments of the extending use case will also be executed. If the condition is false, the extension does not occur. The individual fragments are executed as the corresponding extension points of the extending use case are reached. Once a given fragment is completed, execution continues with the behavior of the extended use case following the extension point. Note that even though there are multiple use cases involved, there is just a single behavior execution.

Notation

An extend relationship between use cases is shown by a dashed arrow with an open arrowhead from the use case providing the extension to the base use case. The arrow is labeled with the keyword «extend». The condition of the relationship as well as the references to the extension points are optionally shown in a Note attached to the corresponding extend relationship.(See Figure 402.)

Examples



In the use case diagram above, the use case "Perform ATM Transaction" has an extension point "Selection". This use case is extended via that extension point by the use case "On-Line Help" whenever execution of the "Perform ATM Transaction" use case occurrence is at the location referenced by the "Selection" extension point and the customer selects the HELP key. Note that the "Perform ATM Transaction" use case is defined independently of the "On-Line Help" use case.

Rationale

This relationship is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in another use case (which is meaningful independently of the extending use case).

Changes from previous UML

The notation for conditions has been changed such that the condition and the referenced extension points may now be included in a Note attached to the extend relationship, instead of merely being a textual comment that is located in the vicinity of the relationship.

 ExtensionPoint (from UseCases)

An extension point identifies a point in the behavior of a use case where that behavior can be extended by the behavior of some other (extending) use case, as specified by an extend relationship.

Description

An ExtensionPoint is a feature of a use case that identifies a point where the behavior of a use case can be augmented with elements of another (extending) use case.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

[1] An ExtensionPoint must have a name.

self.name->notEmpty ()

Semantics

An extension point is a reference to a location within a use case at which parts of the behavior of other use cases may be inserted. Each extension point has a unique name within a use case.

Semantic Variation Points

The specific manner in which the location of an extension point is defined is left as a semantic variation point.

Notation

Extension points are indicated by a text string within in the Use Case oval symbol or use case rectangle according to the syntax below:

<extension point> ::= <name> [: <explanation>]

Note that explanation, which is optional, may be any informal text or a more precise definition of the location in the behavior of the use case where the extension point occurs.

Examples

See Figure 402  and Figure 408 .

Rationale

ExtensionPoint supports the use case extension mechanism (see "Extend (from UseCases)").

Changes from previous UML

In 1.x, ExtensionPoint was modeled as a kind of ModelElement, which due to a multiplicity constraint, was always associated with a specific use case. This relationship is now modeled as an owned feature of a use case. Semantically, this is equivalent and the change will not be visible to users.

ExtensionPoints in 1.x had an attribute called location, which was a kind of LocationReference. Since the latter had no specific semantics it was relegated to a semantic variation point. When converting to UML 2.0, models in which ExtensionPoints had a location attribute defined, the contents of the attribute should be included in a note attached to the ExtensionPoint.

 Include (from  UseCases)

An include relationship defines that a use case contains the behavior defined in another use case.

Description

Include is a directed relationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case. The including use case may only depend on the result (value) of the included use case. This value is obtained as a result of the execution of the included use case.

Note that the included use case is not optional, and is always required for the including use case to execute correctly.

Attributes

No additional attributes.

Associations

Constraints

No additional constraints.

Semantics

An include relationship between two use cases means that the behavior defined in the including use case is included in the behavior of the base use case. The include relationship is intended to be used when there are common parts of the behavior of two or more use cases. This common part is then extracted to a separate use case, to be included by all the base use cases having this part in common. Since the primary use of the include relationship is for reuse of common parts, what is left in a base use case is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base use case depends on the addition but not vice versa.

Execution of the included use case is analogous to a subroutine call. All of the behavior of the included use case are executed at a single location in the included use case before execution of the including use case is resumed.

Notation

An include relationship between use cases is shown by a dashed arrow with an open arrowhead from the base use case to the included use case. The arrow is labeled with the keyword «include». (See Figure 403.)

Examples

A use case "Withdraw" includes an independently defined use case "Card Identification".



Rationale

The Include relationship allows hierarchical composition of use cases as well as reuse of use cases.

Changes from previous UML

There are no changes to the semantics or notation of the Include relationship relative to UML 1.x.

UseCase (from UseCases)

A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.

Description

A UseCase is a kind of behaviored classifier that represents a declaration of an offered behavior. Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors. Use cases define the offered behavior of the subject without reference to its internal structure. These behaviors, involving interactions between the actor and the subject, may result in changes to the state of the subject and communications with its environment. A use case can include possible variations of its basic behavior, including exceptional behavior and error handling.

The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem or class. Each use case specifies a unit of useful functionality that the subject provides to its users, i.e., a specific way of interacting with the subject. This functionality, which is initiated by an actor, must always be completed for the use case to complete. It is deemed complete if, after its execution, the subject will be in a state in which no further inputs or actions are expected and the use case can be initiated again or in an error state.

Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.

The behavior of a use case can be described by a specification that is some kind of Behavior (through its ownedBehavior relationship), such as interactions, activities, and state machines, or by pre-conditions and post-conditions as well as by natural language text where appropriate. It may also be described indirectly through a Collaboration that uses the use case and its actors as the classifiers that type its parts. Which of these techniques to use depends on the nature of the use case behavior as well as on the intended reader. These descriptions can be combined. An example of a use case with an associated state machine description is shown in Figure 405.

Attributes

No additional attributes.

Associations
  • subject : Classifier
References the subjects to which this use case applies. The subject or its parts realize all the use cases that apply to this subject. Use cases need not be attached to any specific subject, however. The subject may, but need not, own the use cases that apply to it.
  • include : Include
References the Include relationships owned by this use case. (Specializes Classifier.feature and Namespace.ownedMember.)
  • extend : Extend
References the Extend relationships owned by this use case. (Specializes Classifier.feature and Namespace.ownedMember.)
  • extensionPoint: ExtensionPoint
References the ExtensionPoints owned by the use case. (Specializes Classifier.feature and Namespace.ownedMember.)

Constraints

[1] A UseCase must have a name.

self.name -> notEmpty ()

[2] UseCases can only be involved in binary Associations.

[3] UseCases can not have Associations to UseCases specifying the same subject.

Semantics

An execution of a use case is an occurrence of emergent behavior.

Every instance of a classifier realizing a use case must behave in the manner described by the use case.

Use cases may have associated actors, which describes how an instance of the classifier realizing the use case and a user playing one of the roles of the actor interact. Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the subject. It is not possible to state anything about the internal behavior of the actor apart from its communications with the subject.

Notation

A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse. An optional stereotype keyword may be placed above the name and a list of properties included below the name. If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle. Note that this does not necessarily mean that the subject classifier owns the contained use cases, but
merely that the use case applies to that classifier. For example, the use cases shown in Figure 404  apply to the "ATMsystem" c lassifier but are owned by various packages as shown in Figure 406





Extension points may be listed in a compartment of the use case with the heading extension points. The description of  the locations of the extension point is given in a suitable form, usually as ordinary text, but can also be given in other forms, such as the name of a state in a state machine, an activity in an activity diagram, a precondition, or a postcondition.

Use cases may have other associations and dependencies to other classifiers, e.g. to denote input/output, events and behaviors.

The detailed behavior defined by a use case is notated according to the chosen description technique, in a separate diagram or textual document. Operations and attributes are shown in a compartment within the use case.

Use cases and actors may represent roles in collaborations as indicated in Figure 407.


Presentation Options

A use case can also be shown using the standard rectangle notation for classifiers with an ellipse icon in the upper-right-hand corner of the rectangle with optional separate list compartments for its features. This rendering is more suitable when there are a large number of extension points.


Examples

See Figure 402 through Figure 408.

Rationale

The purpose of use cases is to identify the required functionality of a system.

Changes from previous UML

The relationship between a use case and its subject has been made explicit. Also, it is now possible for use cases to be owned by classifiers in general and not just packages.