Guidelines: Use-Case Model
Topics
A use-case model is a model of the system's intended functions and its
surroundings, and serves as a contract between the customer and the developers.
Use cases serve as a unifying thread throughout system development. The same
use-case model is the result of the Requirements discipline, and is used as input to
Analysis & Design and Test disciplines.
The diagram below shows a part of a use-case model for the Recycling-Machine
System.
A use-case diagram, showing an example of a use-case
model with actors and use cases.
There are many ways to model a system, each of which may serve a different
purpose. However, the most important purpose of a use-case model is to communicate
the system's behavior to the customer or end user. Consequently, the model must
be easy to understand.
The users and any other system that may interact with the system are the
actors. Because they represent system users, actors help delimit the system and
give a clearer picture of what it is supposed to do. Use cases are developed on
the basis of the actors' needs. This ensures that the system will turn out to be
what the users expected.
Both the actors and the use cases are found by using the requirements of
customers and potential users as vital information. As they are discovered, the
use cases and the actors should be briefly described. Before the use cases are
described in detail, the use-case model should be reviewed by the customer to
verify that all the use cases and actors are found, and that together they can
provide what the customer wants.
In an iterative development environment, you will select a subset of use
cases to be detailed in each iteration. See also Activity:
Prioritize Use Cases.
When the actors and use cases have been found, the flow of events of each use
case is described in detail. These descriptions show how the system interacts
with the actors and what the system does in each individual case.
Finally, the completed use-case model (including the descriptions of use
cases) is reviewed, and the developers and customers use it to agree on what the
system should do.
It is not uncommon that the use-case model degenerates into a functional
decomposition of the system. To avoid this, watch for the following symptoms:
- "Small" use cases, meaning that the description of the flow of
events is only one or a few sentences.
- "Many" use cases, meaning that the number of use cases is some
multiple of a hundred, rather than a multiple of ten.
- Use-case names that are constructions like "do this operation on this
particular data" or "do this function with this particular
data". For example, "Enter Personal Identification Number in an
ATM machine" should not be modeled as a separate use case for the ATM
machine, since no one would use the system to do just this. A use case is a
complete flow of events that results in something of value to an actor.
To avoid functional decomposition, you should make sure that the use-case
model helps answer questions like:
- What is the context of the system?
- Why is the system built?
- What does the user want to achieve when using the system?
- What value does the system add to the users?
It is quite easy to see that use cases are a very good way of capturing
functional requirements on a system. But what about the non-functional
requirements? What are they and where are they captured?
Non-functional requirements are often categorized as usability-, reliability,
performance, and substitutability-requirements (see also Concepts:
Requirement). They are often requirements that specify need of compliance
with any legal and regulatory requirements. They can also be design constraints
due to the operating system used, the platform environment, compatibility
issues, or any application standards that apply. In general, you can say that
any requirement that does not allow for more than one design option should be
regarded as a design constraint.
Many non-functional requirements apply to an individual use case and are
captured within the properties of that use case. In that case, they are captured
within the flow of events of the use case, or as a special requirement of the
use case (see Guidelines: Use Case).
Example:
In the Recycling-Machine System, a non-functional requirement
specific to the Return Deposit Items use case could be:
The machine has to be able to recognize deposit items with a
reliability of more than 95 percent.
Often the non-functional requirements apply to the whole system. Such
requirements are captured in the Supplementary Specifications (see Artifact:
Supplementary Specifications).
Example:
In the Recycling-Machine System, a non-functional requirement
that applies to the whole system could be:
The machine will allow only one user at a time.
One of the more difficult things is to learn how to determine at what level
of detail the use cases should "start and end". Where does features
start and use cases begin, and where does use cases end and design begin? We
often say that use cases or software requirements should state "what"
the system does, but not "how" it does it. Consider the following
graph:
One person's destination is another's starting point.
Depending on your background, you will use a different context to decide what
you think is "what" and what is "how". This needs to be
taken into consideration when determining whether or not a certain detail should
be left out of the use-case model.
There is a distinction between concrete and abstract use cases. A concrete
use case is initiated by an actor and constitutes a complete flow of events.
"Complete" means that an instance of the use case performs the entire
operation called for by the actor.
An abstract use case is never instantiated in itself.
Abstract use cases are included in (see Guidelines:
Include-Relationship), extend into (see Guidelines:
Extend-Relationship), or generalize (see Guidelines:
Use-Case-Generalization) other use cases. When a concrete use case is
initiated, an instance of the use case is created. This instance also exhibits
the behavior specified by its associated abstract use cases. Thus, no separate
instances are created from abstract use cases.
The distinction between the two is important, because it is concrete use
cases the actors will "see" and initiate in the system.
You indicate that a use case is abstract by writing its name in italics.
Example:
The use case Create Task is included in the use case
Register Order. Create Task is an abstract use case.
In the Depot-Handling System the abstract use case, Create
Task, is included in the use case Register Order. When Register Order is
initiated, an instance of Register Order is created that, apart from following
Register Order's flow of events, also follows the flow of events described in
the included use case, Create Task. Create Task is never performed by itself,
always as a part of Register Order (or any other use cases in which it is
included). Create Task is therefore an abstract use case.
There are three main reasons for structuring the use-case model:
- To make the use cases easier to understand.
- To partition out common behavior described within many use cases
- To make the use-case model easier to maintain.
Structuring is, however, not the first thing you do. There is no point in
structuring the use cases until you know a bit more about their behavior, beyond
a one sentence brief description. You should at least have established a
step-by-step outline to the flow of events of the use case, to make sure that
you decisions are based on an accurate enough understanding of the behavior.
To structure the use cases, we have three kinds of relationships. You will
use these relationships to factor out pieces of use cases that can be reused in
other use cases, or that are specializations or options to the use case. The use
case that represents the modification is called the addition use case.
The use case that is modified is called the base use case.
- If there is a part of a base use case that represents a function of which
the use case only depends on the result, not the method used to produce the
result, you can factor that part out to an addition use case. The addition
is explicitly inserted in the base use case, using the include-relationship.
See also Guidelines: Include-Relationship.
- If there is a part of a base use case that is optional, or not necessary
to understand the primary purpose of the use case, you can factor that part
out to an addition use case in order to simplify the structure of the base
use case. The addition is implicitly inserted in the base use case, using
the extend-relationship. See also Guidelines:
Extend-Relationship.
- If there are use cases that have commonalties in behavior and structure
and similarities in purpose, their common parts can be factored out to a
base use case (parent) that is inherited by addition use cases (children).
The child use cases can insert new behavior and modify existing behavior in
the structure they inherit from the parent use case. See also Guidelines:
Use-Case-Generalization.
You can use actor-generalization to show how actors are specializations of
one another. See also Guidelines: Actor-Generalization.
Example:
Consider part of the use-case model for an Order Management
System.
It is useful to separate ordinary Customer from Internet
Customer, since they have slightly different properties. However, since Internet
Customer does exhibit all properties of a Customer, you can say that Internet
Customer is a specialization of Customer, indicated with an
actor-generalization.
The concrete use cases in this diagram are Phone Order
(initiated by the Customer actor) and Internet Order (initiated by Internet
Customer). These use cases are both variations of the more general Place Order
use case, which in this example is abstract. The Request Catalog use case
represents an optional segment of behavior that is not part of the primary
purpose of Place Order. It has been factored out to an abstract use case to
simplify the Place Order use case. The Supply Customer Data use case represents
a segment of behavior that was factored out since it is a separate function of
which only the result is affecting the Place Order use case. The Supply Customer
Data use case can also be reused in other use cases. Both Request Catalog and
Supply Customer Data are abstract in this example.
This use-case diagram shows part of the use-case model
for an Order Management System.
The following table shows a more detailed comparison between the three
different use-case relationships:
Question |
Extend |
Include |
Generalization |
What is the direction of the relationship? |
The addition use case references the base use case. |
The base use case references the addition use case. |
The addition use case (child) references the base use case (parent). |
Does the relationship have multiplicity? |
Yes, on the addition side. |
No. If you want to include the same segment of behavior more than once, that
needs to be stated in the base use case. |
No. |
Does the relationship have a condition? |
Yes. |
No. If you want to express a condition on the inclusion you need to say it explicitly in the base use case. |
No. |
Is the addition use case abstract? |
Often yes, but not necessarily. |
Yes. |
Often no, but it can be. |
Is the base use case modified by the addition? |
The extension implicitly modifies the behavior of the base use case. |
The inclusion explicitly modifies the effect of the base use case. |
If the base use case (parent) is instantiated, it is unaffected by the child.
To obtain the effects of the addition, the addition use case (child) must be instantiated. |
Does the base use case have to be complete and meaningful? |
Yes. |
Together with the additions, yes. |
If it is abstract, no. |
Does the addition use case have to be complete and meaningful? |
No. |
No. |
Together with the base use case (parent), yes. |
Can the addition use case access attributes of the base use case? |
Yes. |
No. The inclusion is encapsulated, and only "sees" itself. |
Yes, by the normal mechanisms of inheritance. |
Can the base use case access attributes of the addition use case? |
No. The base use case must be well-formed in the absence of the addition. |
No. The base use case only knows about the effect of the addition. The addition is encapsulated. |
No. The base use case (parent) must in this sense be well-formed in the absence of the addition (child). |
Another aspect of organizing the use-case model for easier understanding is
to group the use cases into packages. The use-case model can be organized as a
hierarchy of use-case packages, with "leaves" that are actors or use
cases. See also Guidelines: Use-Case Package.
This graph shows the use-case model hierarchy. Arrows
indicate possible ownership.
The execution of each use case includes communication with one or more
actors. A use case instance is always started by an actor asking the system to
do something. This implies that every use case should have
communicates-associations with actors. The reason for this rule is to enforce
the system to provide only the functionality that users need, and nothing else.
Having use cases that no one requests is an indication that something is wrong
in the use-case model or in the requirements.
However, there are some exceptions to this rule:
- If a use case is abstract (not separately instantiable), its behavior may
not include interaction with any actor. In that case, there will not be any
communication-associations to actors from that abstract use case.
- A child use case in a generalization-relationship does not need to have an
actor associated with it if the parent use case describes all actor
communication.
- A base use case in an include-relationship does not need to have an actor
associated with it if the inclusion use case describes all actor
communication.
- A use case may be initiated according to a schedule (for example, once a
week or once a day), which means the system clock is the initiator. The
system clock is internal to the system - and the use case is not initiated
by an actor, but by an internal system event. If no other actor interaction
occurs in the use case, it will not have any associations to actors.
However, for clarity, you can use a fictive actor "Time" to show
how the use case is initiated in your use-case diagrams.
The survey description of the use-case model should:
- State which are the primary use cases of the system (the reason the system
is built).
- Summarize important technical facts about the system.
- Point out system delimitations - things that the system is not supposed
to do.
- Summarize the system's environment, for example, target platforms and
existing software.
- Describe any sequences in which use cases are normally performed in the
system.
- Specify functionality not handled by the use-case model.
Example:
Following is a sample survey
description of the Recycling Machine's use-case model:
This model contains three actors and three use cases. The
primary use case is Recycle Items, which represents the main purpose of the
Recycling Machine.
Supporting use cases are:
-
Print Daily Report, which allows an operator to get a
report on how many items have been recycled.
-
Administer Deposit Item, which allows an operator to
change refund value for a type of deposit item, or add new deposit item
types.
|