Roles and Activities >
Analyst >
Structure the Use-Case Model
Activity:
Structure the Use-Case Model
Purpose
To extract behavior in use cases that need to be considered as
abstract use cases. Examples of such behavior are common behavior,
optional behavior, exceptional behavior, and behavior that is to be
developed in later iterations.
To find new abstract actors that define roles that are shared by
several actors.
If a use case contains a segment of behavior of which only the result, not
the method for getting the result, is of any importance to the rest of the use
case, this behavior can be factored out to a new inclusion use case.
The original use case then becomes the base use case in an
include-relationship with the inclusion use case. See also Guidelines:
Use-Case Model.
An include-relationship between two use cases means that a use-case instance
following the description of the base use case also needs to follow the
description of the inclusion use case in order to be complete.
The include-relationship can help clarify a use case by:
Isolating and encapsulating complex details so they do not obscure the
real meaning of the use case.
Improving consistency by including behavior which are included in several
base use cases.
Generally, more than one use case must include an inclusion use case to make
it worth it to maintain an extra use case and the include-relationship.
Only the base use case knows of the relationship between the two use cases;
no inclusion use case knows what other use cases includes it.
Describe the include-relationship by briefly stating the purpose of the
inclusion, as well as the location in the base use case at which the inclusion
is to be inserted.
When describing the flow of events of the base use case, you should refer to
the inclusion at the location in which the inclusion is inserted.
Establish Extend-Relationships Between Use Cases
If a use case has segments of behavior that are optional or exceptional in
character, and that do not add to the understanding of the primary purpose of
the use case, factor those out to a new extension use case. The
original use case then becomes a base use case, to which the
extension use case has an extend-relationship. See also Guidelines:
Use-Case Model.
In the base use case you declare extension points, which define where in the
base use case extensions may be made. See also Guidelines:
Use Case.
Complex sub-flows and optional behavior are the first candidates for being
partitioned out into extension use cases. Often this behavior can be quite
complex and hard to describe: including it in the flow of events of a use case
can make the "normal" behavior harder to see. Extracting it should
improve the comprehensibility of the use-case model.
Make sure that the flow of events of the base use case is still complete and
understandable by itself, without any reference to the extension use case.
Only the extension use case knows of the relationship between the two use
cases. The base use case only knows it has extension points, it doesn't know
what extension use cases are using them.
Briefly describe every extend-relationship you define. Define the conditions
that must be met for the extension to occur. Make sure to define the extension
point in the base use case at which the extension should be inserted.
If you do not define any conditions, it means the extension always is
performed.
If the extension use case has several behavior segments that are to be
inserted at different extension points in the base use case, make sure to
define these segments and the extension point for each segment in the base
use case.
Establish Generalizations Between Use Cases
If two or more use cases have similarities in structure and behavior, you can
factor out the common behavior to create a new parent use case.
The original use cases will then be child use cases in generalization-relationships
with the parent. The child use case inherits all behavior described for the
parent use case. See also Guidelines: Use-Case
Model.
A generalization-relationship between two use cases means that when a
use-case instance follows the description of a child use case, it also needs to
follow the description of the parent use case in order to be considered
complete.
Generally, for it to be worth it to maintain a parent use case and a
generalization-relationship with a child, there needs to be at least two child
use cases inheriting from the same parent. An exception is if you have two use
cases where one is a specialization of the other, but both need to be
independently instantiable.
Only the child use case knows of the relationship between the two use cases;
no parent use case knows what child use cases are specializing it.
To assist others in understanding the model, you should briefly describe the
generalization-relationship. Explain why you created the
generalization-relationship.
In the flow of events of the child use case you need to explain how the child
will modify the inherited behavior sequences by inserting new segments of
behavior.
Establish Generalizations Between Actors
Actors will have common characteristics that you should model by using
actor-generalizations. This part of the work is best performed after you have
made your first attempt at a use-case model.
Write a brief description of the actor-generalizations, and include them in
use-case diagrams for further clarification.
Evaluate Your Results
You should continuously discuss the incorporation of include-, extend-, and
generalization-relationships with the customer and the users, and see that they
have a clear understanding of the resulting use cases and actors, and that they
agree on their descriptions.
Check the use-case model at this stage to verify that your work is on track,
but do not review the model in detail. You should review and discuss the newly
incorporated use cases and relationships with the customer and users so that
they have a clear understanding of the use cases and agree on their
descriptions.
You should also consider the checkpoints for the use-case model while you are
working on it. See especially checkpoints for actor, use case and use-case model
in Activity: Review Requirements.