Information Technology Reference
In-Depth Information
case, and other scenarios for each possible variation of flow through the use case
(e.g., triggered by options, error conditions, security breaches, etc.). Scenarios may
be depicted using sequence diagrams.
5.6.1 Structuring Use Cases
UML provides three relationships that can be used to structure use cases. These are
generalization, include and extends. An include relationship between two use cases
means that the sequence of behavior described in the included (or sub) use case is
included in the sequence of the base (including) use case. Including a use case
is thus analogous to the notion of calling a subroutine (Coleman
1992
). The
extends relationship provides a way of capturing a variant to a use case. Extensions
are not true use cases, but they are changes to steps in an existing use case.
Typically, extensions are used to specify the changes in steps that occur in order to
accommodate an assumption that is false (Coleman
1992
). The extends relation-
ship includes the condition that must be satisfied if the extension is to take place,
and references to the extension points which define the locations in the base
(extended) use case where the additions are to be made. A generalization rela-
tionship between use cases ''implies that the child use case contains all the attri-
butes, 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
define new behavior sequences, as well as add behavior into and specialize the
existing behavior of the parent.
5.6.2 Use Case Guidelines
Creation
The following provides an outline of a process for creating use cases:
1. Identify all the different users of the system
2. Create a user profile for each category of user, including all the roles the users
play that are relevant to the system. For each role, identify all the significant
goals the users have that the system will support. A statement of the system's
value proposition is useful in identifying significant goals.
3. Create a use case for each goal following the use case template. Maintain the
same level of abstraction throughout the use case. Steps in higher-level use
cases may be treated as goals for lower level (i.e., more detailed), sub-use cases.
4. Structure the use cases. Avoid over-structuring, as this can make the use cases
harder to follow.
5. Review and validate with users
