لطفا منتظر باشید ...
4.2 Use Cases
As discussed in Chapter 2, a use
case is a functional requirement that is
described from the perspective of the users of a system. For example,
functional requirements for the project management system include:
security functionality (such as allowing users to log in and out of
the system), inputting of data, processing of data, generation of
reports, and so forth.Use cases follow the type-instance dichotomy first
discussed in Chapter 2 and applied to classes and
object in Chapter 3. You can use the UML to talk
about classes of use cases, and you can use the UML to talk about
specific use cases of a class. When speaking of a class of use cases,
it's customary to
use the term use case or
use-case class. Thus, while you might think of a
use case as a specific thing, in the UML, a use case really
represents a class of things. When speaking of a specific use case of
a class, use the
term use-case
instance.A use case defines a functional requirement that is described as a
sequence of steps, which include actions performed by a system and
interactions between the system and actors. Use cases address the
question of how actors interact with a system, and describe the
actions the system performs.In the UML, a use case is shown as an ellipse and labeled with the
name of the use-case class. Use cases may be enclosed by a rectangle
that represents the boundary of the system that provides the
functionality. Figure 4-3 shows various use cases
associated with the project management system, including
functionality to manage projects, manage resources, and administer
the system.
Figure 4-3. Use cases
A use-case instance, often called a scenario, is
the performance of a specific sequence of actions and interactions.
For example, a specific actor instance that uses security
functionality to log in or out of the project management system
represents a scenario. Other possible scenarios might include a user
who enters data, a user who requests processing to be done on the
data, or a user who requests that the system generate a report.A use-case instance is shown similarly to
a use case
but labeled with the use-case instance name followed by a colon
followed by the use-case name, all fully underlined. Both names are
optional, and the colon is present only if the use-case class name is
specified. Use-case instances address the questions of how actor
instances specifically interact with a system and what specific
actions the system performs in return. Use-case instances are not
commonly shown on use-case diagrams but rather are simply discussed
with users to better understand their requirements.Because use cases are performed by a system, they define the
functional requirements of the system. For example, given the use
cases shown in Figure 4-3, we know generally what
type of functionality must be provided by the project management
system. Other use-case diagrams may refine and decompose these use
cases. If we don't define our use cases, we may fall
into the trap of endlessly debating whether we have identified all
the functionality of the system.Each use case is composed of one or
more behavior sequences. A
behavior sequence is a sequence of steps in
which each step specifies an action or interaction. Each
action specifies processing performed by the
system.
Each interaction specifies some communication
between the system and one of the actors who participate in the use
case. For example, a login use case may have the following behavior
sequence:
The system provides a user interface to capture login information.
The user enters her username.
The user enters her password.
The system validates the username and password.
The system responds appropriately by allowing the user to continue,
or by rejecting the user, depending on whether her username and
password are valid.
Steps 1, 4, and 5 are actions that the system performs, and steps 2
and 3 are interactions between the system and user. It is fairly
simple to see that step 4 is an action, but you may be wondering why
steps 1 and 5 are actions rather than interactions, when the system
is interacting with the user by presenting a user interface to the
user or by responding appropriately with a message window or
something similar. Steps 1 and 5 are actions rather than interactions
because the system is simply taking action to show a user interface
or a response message window that the user can easily choose to
ignore. However, if this were not a human user but another system
that would receive some communication to which it must reply, these
would be interactions rather than actions. Quite often, trying to
classify each step as either an action or interaction is not
necessary; rather, it is more important to consider a use case as a
dialog between actors and the system, to understand how actors
interact with the system, and to understand what actions are the
responsibility of the system.Actions and interactions may
also
be repeated, conditional, or optional. For example, the
Manage Project use case may
have a behavior sequence for finding a project on which to work, and
the following three succeeding behavior sequences:
One for managing projects involving employees only
One for managing projects involving consultants only
One for managing projects involving both employees and consultants
An instance of the Manage
Project use case involves actor instances and
finding a project and managing it using one of the three available
behavior sequences based upon the type of project selected. Behavior
sequences, such as the one shown earlier for the login use case, are
commonly captured in textual form, but may also be captured using
behavioral modeling techniques, as discussed in Part III. However,
the UML does not provide any explicit guidance on how to capture
behavior sequences.Because use cases result in some observable value to one or more
actors, they must allow actors to achieve their goals. After all,
each actor has goals in interacting with a system. Use cases
don't represent actor goals, but instead represent
functionality that enable actors to achieve their goals. For example,
the use cases shown in Figure 4-3 enable the actors
shown in Figure 4-1 to achieve their goals in the
following ways:
To ensure that a project delivers a quality product within the
specified time, cost, and resource constraints, a project manager may
use the Manage Project use
case.
To ensure that trained and skilled human resources are available for
projects, a resource manager may use the Manage
Resource use case.
To ensure that a project management system is available for a
project, a system administrator may use the
Administer System use case,
which may involve a backup system.
The project management system does not offer any functionality to
enable human resources to achieve their goals. Note that such
functionality is outside the scope of the system.
