From: Frank Farance [frank@farance.com]
Sent: Wednesday, October 02, 2002 5:11 PM
To: Multiple recipients of list
Subject: Excerpt from UML on Use Cases


[Here's and excerpt from UML on Use Cases]

2.11 Use Cases

2.11.1 Overview

The Use Cases package is a subpackage of the Behavioral Elements package. It specifies the concepts used for definition of the functionality of an entity like a system. The package uses constructs defined in the Foundation package of UML as well as in the Common Behavior package.

The elements in the Use Cases package are primarily used to define the behavior of an entity, like a system or a subsystem, without specifying its internal structure. The key elements in this package are UseCase and Actor. Instances of use cases and instances of actors interact when the services of the entity are used. How a use case is realized in terms of cooperating objects, defined by classes inside the entity, can be specified with a Collaboration. A use case of an entity may be refined to a set of use cases of the elements contained in the entity. How these subordinate use cases interact can also be expressed in a Collaboration. The specification of the functionality of the system itself is usually expressed in a separate use-case model (i.e., a Model stereotyped «useCaseModel»). See Section 4.3, “Stereotypes and Notation,” on page 4-3 for additional information. The use cases and actors in the use-case model are equivalent to those of the top-level package.

The following sections describe the abstract syntax, well-formedness rules, and
semantics of the Use Cases package.

2.11.2 Abstract Syntax

The abstract syntax for the Use Cases package is expressed in graphic notation in
Figure 2-18.

[Diagram Here]

Figure 2-18 Use Cases

The following metaclasses are contained in the Use Cases package.

2.11.2.1 Actor

An actor defines a coherent set of roles that users of an entity can play when
interacting with the entity. An actor may be considered to play a separate role with
regard to each use case with which it communicates.

In the metamodel Actor is a subclass of Classifier. An Actor has a Name and may
communicate with a set of UseCases, and, at realization level, with Classifiers taking
part in the realization of these UseCases. An Actor may also have a set of Interfaces,
each describing how other elements may communicate with the Actor.

An Actor may have generalization relationships to other Actors. This means that the
child Actor will be able to play the same roles as the parent Actor (i.e., communicate
with the same set of UseCases) as the parent Actor.

2.11.2.2 Extend

An extend relationship defines that instances of a use case may be augmented with
some additional behavior defined in an extending use case.

In the metamodel an Extend relationship is a directed relationship implying that a
UseCaseInstance of the base UseCase may be augmented with the structure and
behavior defined in the extending UseCase. The relationship consists of a condition,
which must be fulfilled if the extension is to take place, and a sequence of references
to extension points in the base UseCase where the additional behavior fragments are to
be inserted.

Attributes
Associations

2.11.2.3 ExtensionPoint

An extension point references one or a collection of locations in a use case where the
use case may be extended.

In the metamodel an ExtensionPoint has a name and one or a collection of descriptions
of locations in the behavior of the owning use case, where a piece of behavior may be
inserted into the owning use case.

Attributes

condition An expression specifying the condition that must be
fulfilled if the extension is to take place.

base The UseCase to be extended.

extension The UseCase specifying the extending behavior.

extensionPoint A sequence of extension-points in the base UseCase
specifying where the additions are to be inserted.

location A reference to one location or a collection of locations
where an extension to the behavior of the use case may be
inserted.

Include

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

In the metamodel an Include relationship is a directed relationship between two
UseCases implying that the behavior in the addition UseCase is inserted into the
behavior of the base UseCase. The base UseCase may only depend on the result of
performing the behavior defined in the addition UseCase, but not on the structure (i.e.,
on the existence of specific attributes and operations) of the addition UseCase.

Associations

addition The UseCase specifying the additional behavior.

base The UseCase that is to include the addition.

2.11.2.5 UseCase

The use case construct is used to define the behavior of a system or other semantic
entity without revealing the entity’s internal structure. Each use case specifies a
sequence of actions, including variants, that the entity can perform interacting with
actors of the entity.

In the metamodel UseCase is a subclass of Classifier, specifying the sequences of
actions performed by an instance of the UseCase. The actions include changes of the
state and communications with the environment of the UseCase. The sequences can be
described using many different techniques, like Operation and Methods,
ActivityGraphs, and StateMachines.

There may be Associations between UseCases and the Actors of the UseCases. Such
an Association states that an instance of the UseCase and a user playing one of the
roles of the Actor communicate. UseCases may be related to other UseCases by
Extend, Include, and Generalization relationships. An Include relationship means that a
UseCase includes the behavior described in another UseCase, while an Extend
relationship implies that a UseCase may extend the behavior described in another
UseCase, ruled by a condition. Generalization between UseCases means that the child
is a more specific form of the parent. The child inherits all Features and Associations
of the parent, and may add new Features and Associations.

The realization of a UseCase may be specified by a set of Collaborations (i.e., the
Collaborations define how Instances in the system interact to perform the sequences of
the UseCase).

Associations

extend A collection of Extend relationships to UseCases that the
UseCase extends.

extensionPoint Defines a collection of ExtensionPoints where the UseCase
may be extended.

include A collection of Include relationships to UseCases that the
UseCase includes.

2.11.2.6 UseCaseInstance

A use case instance is the performance of a sequence of actions specified in a use case.

In the metamodel UseCaseInstance is a subclass of Instance. Each method performed
by a UseCaseInstance is performed as an atomic transaction (i.e., it is not interrupted
by any other UseCaseInstance).

An explicitly described UseCaseInstance is called a scenario.

2.11.4 Semantics

This section provides a description of the semantics of the elements in the Use Cases
package, and its relationship to other elements in the Behavioral Elements package.

2.11.4.1 Actor

Figure 2-19 Actor Illustration

Actors model parties outside an entity (such as a system, a subsystem, or a class),
which interact with the entity. Each actor defines a coherent set of roles users of the
entity can play when interacting with the entity. Every time a specific user interacts
with the entity, it is playing one such role. An instance of an actor is a specific user
interacting with the entity. Any instance that conforms to an actor can act as an
instance of the actor. If the entity is a system, the actors represent both human users
and other systems. Some of the actors of a lower level subsystem or a class may
coincide with actors of the system, while others appear inside the system. The roles
defined by the latter kind of actors are played by instances of classifiers in other
packages or subsystems. In the latter case the classifier may belong to either the
specification part or the realization part of the subsystem.

Since an actor is outside the entity, its internal structure is not defined, but only its
external view as seen from the entity. Actor instances communicate with the entity by
sending and receiving message instances to and from use case instances and, at
realization level, to and from objects. This is expressed by associations between the
actor and the use case or the class. Furthermore, interfaces can be connected to an
actor, defining how other elements may interact with the actor.

Two or more actors may have commonalities (i.e., communicate with the same set of
use cases in the same way). The commonality is expressed with generalizations to
another (possibly abstract) actor, which models the common role(s). An instance of a
child can always be used where an instance of the parent is expected.

2.11.4.2 UseCase

Figure 2-20 UseCase Illustration

In the following text the term “entity” is used when referring to a system, a subsystem,
or a class and the terms model element and element denote a subsystem or a class.

The purpose of a use case is to define a piece of behavior of an entity without revealing
the internal structure of the entity. The entity specified in this way may be a system or
any model element that contains behavior, like a subsystem or a class, in a model of a
system. Each use case specifies a service the entity provides to its users (i.e., a specific
way of using the entity). The service, which is initiated by a user, is a complete
sequence. This implies that after its performance the entity will in general be in a state
in which the sequence can be initiated again. A use case describes the interactions
between the users and the entity as well as the responses performed by the entity, as
these responses are perceived from the outside of the entity. A use case also includes
possible variants of this sequence (e.g., alternative sequences exceptional behavior,
error handling, etc.). The complete set of use cases specifies all different ways to use
the entity (i.e., all behavior of the entity is expressed by its use cases). These use cases
can be grouped into packages for convenience.

>From a pragmatic point of view, use cases can be used both for specification of the
(external) requirements on an entity and for specification of the functionality offered
by an (already realized) entity. Moreover, the use cases also indirectly state the
requirements the specified entity poses on its users (i.e., how they should interact so
the entity will be able to perform its services).

Since users of use cases always are external to the specified entity, they are represented
by actors of the entity. Thus, if the specified entity is a system or a subsystem at the
topmost level, the users of its use cases are modeled by the actors of the system. Those
actors of a lower level subsystem or a class that are internal to the system are often not
explicitly defined. Instead, the use cases relate directly to model elements conforming
to these implicit actors (i.e., whose instances play the roles of these actors in
interaction with the use cases). These model elements are contained in other packages
part or the realization part. The distinction between actor and conforming element like
this is often neglected; thus, they are both referred to by the term actor.
There may be associations between use cases and actors, meaning that the instances of
the use case and the actor communicate with each other. One actor may communicate
with several use cases of an entity (i.e., the actor may request several services of the
entity) and one use case communicates with one or several actors when providing its
service. Note that two use cases specifying the same entity cannot communicate with
each other since each of them individually describes a complete usage of the entity.
Moreover, use cases always use signals when communicating with actors outside the
system, while they may use other communication semantics when communicating with
elements inside the system.

The interaction between actors and use cases can be defined with interfaces. An
interface of a use case defines a subset of the entire interaction defined in the use case.
Different interfaces offered by the same use case need not be disjoint.
A use case can be described in plain text, using operations and methods together with
attributes, in activity graphs, by a state machine, or by other behavior description
techniques, such as preconditions and postconditions. The interaction between a use
case and its actors can also be presented in collaboration diagrams for specification of
the interactions between the entity containing the use case and the entity’s
environment.

A use-case instance is a performance of a use case, initiated by a message instance
from an instance of an actor. As a response, the use-case instance performs a sequence
of actions as specified by the use case, like communicating with actor instances (not
necessarily only the initiating one). The actor instances may send new message
instances to the use-case instance and the interaction continues until the instance has
responded to all input and does not expect any more input, when it ends. Each method
performed by a use-case instance is performed as an atomic transaction, i.e. it is not
interrupted by any other use-case instance.

In the case where subsystems are used to model the system’s containment hierarchy,
the system can be specified with use cases at all levels, as use cases can be used to
specify subsystems and classes. A use case specifying one model element is then
refined into a set of smaller use cases, each specifying a service of a model element
contained in the first one. The use case of the whole may be referred to as
superordinate to its refining use cases, which, correspondingly, may be called
subordinate in relation to the first one. The functionality specified by each
superordinate use case is completely traceable to its subordinate use cases. Note,
though, that the structure of the container element is not revealed by the use cases,
since they only specify the functionality offered by the element. The subordinate use
cases of a specific superordinate use case cooperate to perform the superordinate one.
Their cooperation is specified by collaborations and may be presented in collaboration
diagrams. A specific subordinate use case may appear in several collaborations (i.e.,
play a role in the performances of several superordinate use cases). In each such
collaboration, other roles specify the cooperation with this specific subordinate use
case. These roles are the roles played by the actors of that subordinate use case. Some
of these actors may be the actors of the superordinate use case, as each actor of a
superordinate use case appears as an actor of at least one of the subordinate use cases.
Furthermore, the interfaces of a superordinate use case are traceable to the interfaces of
those subordinate use cases that communicate with actors that are also actors of the
superordinate use case.

The environment of subordinate use cases is the model element containing the model
elements specified by these use cases. Thus, from a bottom-up perspective, an
interaction between subordinate use cases results in a superordinate use case, i.e. a use
case of the container element.

Use cases of classes are mapped onto operations of the classes, since a service of a
class in essence is the invocation of the operations of the class. Some use cases may
consist of the application of only one operation, while others may involve a set of
operations, usually in a well-defined sequence. One operation may be needed in several
of the services of the class, and will therefore appear in several use cases of the class.
The realization of a use case depends on the kind of model element it specifies. For
example, since the use cases of a class are specified by means of operations of the
class, they are realized by the corresponding methods; while the use cases of a
subsystem are realized by the elements contained in the subsystem. Since a subsystem
does not have any behavior of its own, all services offered by a subsystem must be a
composition of services offered by elements contained in the subsystem (i.e.,
eventually by classes). These elements will collaborate and jointly perform the
behavior of the specified use case. One or a set of collaborations describes how the
realization of a use case is made. Hence, collaborations are used for specification of
both the refinement and the realization of a use case in terms of subordinate use cases.
The usage of use cases at all levels implies not only a uniform way of specification of
functionality at all levels, but also a powerful technique for tracing requirements at the
system package level down to operations of the classes. The propagation of the effect
of modifying a single operation at the class level all the way up to the behavior of the
system package is managed in the same way.

Commonalities between use cases can be expressed in three different ways: with 1)
generalization, 2) include, and 3) extend relationships. A generalization relationship
between use cases implies that the child use case contains all the attributes, sequences
of behavior, and extension points defined in the parent use case, and participates in all
relationships of the parent use case. The child use case may also define new behavior
sequences, as well as add additional behavior into and specialize existing behavior of
the inherited ones. One use case may have several parent use cases and one use case
may be a parent to several other use cases.

An include relationship between two use cases means that the behavior defined in the
target use case is included at one location in the sequence of behavior performed by an
instance of the base use case. When a use-case instance reaches the location where the
behavior of another use case is to be included, it performs all the behavior described by
the included use case and then continues according to its original use case. This means
that although there may be several paths through the included use case due to
conditional statements, for example, all of them must end in such a way that the use-case
instance can continue according to the original use case. One use case may be
included in several other use cases and one use case may include several other use
cases. The included use case may not be dependent on the base use case. In that sense
the included use case represents encapsulated behavior which may easily be reused in
several use cases. Moreover, the base use case may only be dependent on the results of
performing the included behavior and not on structure, like Attributes and
Associations, of the included use case.

An extend relationship defines that a use case may be augmented with some additional
behavior defined in another use case. One use case may extend several use cases and
one use case may be extended by several use cases. The base use case may not be
dependent of the addition of the extending use case. The extend relationship contains a
condition and references a sequence of extension points in the target use case. The
condition must be satisfied if the extension is to take place, and the references to the
extension points define the locations in the base use case where the additions are to be
made. Once an instance of a use case is to perform some behavior referenced by an
extension point of its use case, and the extension point is the first one in an extends
relationship’s sequence of references to extension points, the condition of the
relationship is evaluated.

If the condition is fulfilled, the sequence obeyed by the use-case instance is extended
to include the sequence of the extending use case. The different parts of the extending
use case are inserted at the locations defined by the sequence of extension points in the
relationship, one part at each referenced extension point. Note that the condition is
only evaluated once at the first referenced extension point, and if it is fulfilled all of the
extending use case is inserted in the original sequence. An extension point may define
one location or a set of locations in the behavior defined by the use case. However, if
an extend relationship references a sequence of extension points, only the first one may
define a set of locations. All other ones must define exactly one location each. Which
of the locations of the first extension point to use is determined by where the extension
is triggered. This is not possible for the other ones. In other words, once the extension
has been triggered, all locations where to add the different part of the extending use
case must be uniquely defined. Hence, all extension points, except for the first one,
referenced by an extend relationship must define single locations. The description of
the location references by an extension point can be made in several different ways,
like textual description of where in the behavior the addition should be made, pre-or
post conditions, or using the name of a state in a state machine.

Note that the three kinds of relationships described above can only exist between use
cases specifying the same entity. The reason for this is that the use cases of one entity
specify the behavior of that entity alone (i.e., all use-case instances are performed
entirely within that entity). If a use case would have a generalization, include, or
extend relationship to a use case of another entity, the resulting use-case instances
would involve both entities, resulting in a contradiction. However, generalization,
include, and extend relationships can be defined from use cases specifying one entity
to use cases of another one if the first entity has a generalization to the second one,
since the contents of both entities are available in the first entity. However, the contents
of the second entity must be at least protected, so they become available inside the
child entity.

As a first step when developing a system, the dynamic requirements of the system as a
whole can be expressed with use cases. The entity being specified is then the whole
system, and the result is a separate model called a use-case model (i.e., a model with
the stereotype «useCaseModel»). Next, the realization of the requirements is expressed
with a model containing a system package, probably a package hierarchy, and at the
bottom a set of classes. If the system package (i.e., a package with the stereotype
«topLevelPackage») is a subsystem, its abstract behavior is naturally the same as that
of the system. Thus, if use cases are used for the specification part of the system
package, these use cases are equivalent to those in the use-case model of the system
(i.e., they express the same behavior but with possibly a slightly different structure). In
other words, all services specified by the use cases of a system package, and only
those, define the services offered by the system. Furthermore, if several models are
used for modeling the realization of a system (e.g., an analysis model and a design
model) the set of use cases of all system packages and the use cases of the use-case
model must be equivalent.

2.11.5 Notes

A pragmatic rule of use when defining use cases is that each use case should yield
some kind of observable result of value to (at least) one of its actors. This ensures that
the use cases are complete specifications and not just fragments.
_______________________________________________________________________
Frank Farance, Farance Inc.     T: +1 212 486 4700   F: +1 212 759 1605
mailto:frank@farance.com        http://farance.com
Standards, products, services for the Global Information Infrastructure