Visual Case
Tool - UML Tutorial
2.
The Use Case Diagram
In many design processes, the use case diagram
is the first that designers will work with when
starting a project. This diagram allows for
the specification of high level user goals that
the system must carry out. These goals are
not necessarily tasks or actions, but can be more
general required functionality of the system.
Use Case
More formally, a use
case is made up of a set of
scenarios.
Each scenario is a sequence of steps that
encompass an interaction between a user and a
system. The use case brings scenarios
together that accomplish a specific goal of the
user.
A use case can be specified by textually
describing the steps required and any alternative
actions at each step. For example, the use
case for searching a web for a keyword might be
shown as:
1. Customer enters the keyword
2. Customer clicks the search button
3. The search is executed
4. The results are shown
Alternative: Search Failed
If the search fails at 3, then the user is
redirected back to the search screen at step 1
In Visual Case, you can specify the steps of a use
case in its description field. Simply
right-click on a use case and select properties.
You can then run a report and print or export the
results to html or ascii text. Together, the
report and the diagrams will include all of the
details of the use case - their specific scenarios
and the actors that carry them out.
Actor
The use case diagram
allows a designer to graphically show these use
cases and the actors that use them. An
actor is a role
that a user plays in the system. It is
important to distinguish between a user and an
actor (better thought of as a role). A user
of the system may play several different roles
through the course of his, her or its job (since
an actor may be another system). Examples of
actors are salesperson, manager, support person,
and web store system. It is possible that
the same person may be a sales person and also
provide support. When creating a use case
model, we are not concerned with the individuals,
only the roles that they play.
Associations
On a use case diagram, associations are drawn
between actors and use cases to show that an actor
carries out a use case. A use case can be
carried out by many actors and an actor may carry
out many use cases.
In the above diagram, the actors
are shown as the green stick figure shapes on the
left, the use cases are the blue ellipses, and the
associations between them are represented by the
connecting lines. The developer and the
stakeholder both are responsible for specifying
the system roles, but only the developer creates
the model.
Includes
Use cases can also be related to
each other with three different links. The
diagram below shows the use of the includes link.
Both invoice purchase and online
purchase include the scenarios defined by
purchase valuation. In general, the
includes link is to avoid repetition of scenarios
in multiple use cases.
Generalization
When a use case describes a
variation on another use case, use a
generalization link. In the example below,
the use case limit exceeded describes a
situation in which the usual scenario of online
purchase is not performed. Use cases
that generalize another use case should only
specify an alternative, even exceptional, scenario
to the use case being generalized. The
overall goal of the use cases should be the same.
Extends
In some instances you want to
describe a variation on behaviour in a more
controlled form. In such instances you can
define extension points
in the extended use case. In the example
below, search by name is said to extend
search at the name extension point.
The extends link is more controlled than the
generalization link in that functionality can only
be added at the extension points.
Putting it all Together
When starting a use case model,
it is very important to keep it simple.
Often it is easiest to first determine the actors
of the system, and then flush out the use cases
that they perform. Your use case diagrams
can be as simple or complex as you wish, however
simpler, less cluttered diagrams are easier to
understand, and are often more powerful in
capturing the tasks of the system.
In Visual Case, you can explode
a use case into a new use case diagram. For
example, the use case online purchase may
require further specification as you move into the
design. You can create a sub-diagram within
any use case to help clarify and understand the
tasks involved.
Remember that a use case
represents a goal of a user, not an atomic
programming operation. Your use case design
should be simple and help to clarify the user's
goals and expectations for the system.
