®
IBM Software Group
Work Unit 1: Defining the system
Module 1: Structure the Use-Case Model
1
Objectives
Simplify the maintenance of the
requirements without sacrificing clarity or
comprehension for stakeholders.
Able to define what structuring is about and to
perform the structure of the use-case model.
Define and describe the relationships between
use cases.
• Using Include, Extend, Generalization
Describe concrete and abstract use cases.
Define actor generalizations.
Describe concrete and abstract actors.
2
Where Are We in the Requirements Discipline?
3
Manage Change: Activities and Artifacts
4
Structure the Use-Case Model
What is model structuring?
Factoring out parts of use cases
to make new use cases.
Why structure the use-case
model?
Simplify the original use cases.
• Make easier to understand.
• Make easier to maintain.
Reuse requirements.
• Share among many use
cases.
5
Relationships Between Use Cases
Include
«include»
Extend
Generalization
«extend»
Handout WP5:
Structuring the Use-Case
Model
6
What Is an Include Relationship?
AT
A relationship from a base use case to an
inclusion use case.
The behavior defined in the inclusion use case
is explicitly included into the base use case.
Inclusion
«include»
Base
7
Include Relationship: RU e-st Example
Get Quote «include» Handout
RUCS7:
Structured Use-
Execute «include» Identify Customer Case Reports
Trade
Trading
Customer
Other Use Case «include»
Identify Customer Use Case
Get Quote Use Case 1. Log on
1. Include “Identify Customer” 2. Validate logon
to verify customer’s identity 3. Enter password
2. Display options. Customer 4. Verify password
selects “Get Quote” A1: Not valid logon
3. ... A2: Wrong password
A3: ...
8
Execution of an Include Relationship
Fully executed when the inclusion point is
reached.
Base
Use Case
Use-Case
Instance
Included
Use Case
9
Why Use an Include Relationship?
Factor out behavior common to
two or more use cases.
Inclusion • Avoid describing same behavior
multiple times.
«include» • Assure common behavior remains
consistent.
Base Factor out and encapsulate
? behavior from a base use case.
hy • Simplify complex flow of events.
W
• Factor out behavior not part of
primary purpose.
10
What Is an Extend Relationship?
c ii
Connects from an extension use case to a
base use case.
Insert extension use case’s behavior into base
use case.
Insert only if the extending condition is true.
Insert into base use case at named extension
point.
Base
«extend»
Extension
11
Extend Relationship: RU e-st Example
Handout
RUCS4:
Structured Use-
Case Reports
Trading Customer
Get Quote
«extend» «extend»
Get News Get Expert
Predictions
Expert Quote
System
News System
12
Extend Relationship: RU e-st Example (cont.)
Get Quote Use Case Get News Use Case
Basic Flow: This use case extends the Get Quote
1. Include “Identify Customer” Use Case, at extension point
to verify customer’s identity. “Optional Services.”
2. Display options. Basic Flow:
3. Customer selects “Get
1. If Customer selects “Get News,” the
Quote.”
system asks customer for time
4. Customer gets quote. period and number of news items.
5. Customer gets other quotes.
2. Customer enters time period and
6. Customer logs off.
number of items. The system
A1. Quote System unavailable sends stock trading symbol to
… News System, receives reply, and
displays the news to the customer.
Extension Points: 3. The Get Quote Use Case continues.
The “Optional Services”
extension point occurs at Step 3 A1: News System Unavailable
in the Basic Flow and Step A1.7 A2: No News About This Stock
in Quote System Unavailable …
alternative flow.
13
Execution of an Extend
Executed when the extension point is
reached and the extending condition is true.
Use-Case Base
Instance Use Case
Extension
Point
Extension
Use Case
14
Why Use an Extend Relationship?
Factor out optional or
exceptional behavior.
Base
Executed only under certain
conditions.
«extend»
Factoring out simplifies flow of
Extension events in base use case.
Example: Triggering an alarm.
Add extending behavior.
Behavior developed
separately, possibly in later
version.
15
Concrete Versus Abstract Use Cases
A use case is Abstract use cases (A & D):
either concrete or A • Do not have to be complete.
abstract.
• Exist only for other use cases.
«include» • Are never instantiated on their
own.
Hint:
B C
Cover up all
abstract use
cases and you
«extend» should still be
Concrete use cases (B & C): able to
• Have to be complete and D understand the
meaningful. main purpose of
• Can be instantiated on the system.
their own.
16
Why Wouldn’t You Structure The Model?
Inclusion The solution is harder to see
when the use case gets
«include»
fragmented.
I • Functionally decompose the
Base N
requirements.
«extend» • Decrease understandability.
• Increase complexity.
Extension • Increases effort for reviewers, rit
implementers and testers.
Child o t?
n • Not all stakeholders are
hy
W comfortable with the format.
The use-case model looks like
a design.
17
What Is Actor Generalization?
Actors may have common characteristics. AM
Multiple actors may have common roles or
purposes interacting with a use case.
Parent
Child 1 Child 2
18
Actor Generalization: Hospital Example
Parent: Medical Worker
Schedule
Medical Worker can read
Operation
charts
Children: Doctor, Nurse,
Doctor Aide
Doctor, Nurse, and Aide
can read charts
Nurse Medical
Worker Read Chart
Aide
19
Why Use Actor Generalization?
S
S
Simplify associations
between many actors
Parent and a use case.
Show that an instance of
a child can perform all
behavior described for
the parent.
Child 1 Child 2
Represent different
security levels.
20
Abstract Versus Concrete Actors
An abstract actor contains the
common part of the roles.
It cannot be instantiated itself.
Example:
Medical • No person is hired to be a
Worker
Medical Worker.
A concrete actor can be
instantiated.
Example:
Doctor Nurse • Lauren is a Doctor.
• Daniel is a nurse.
21
Use-Case-Modeling Guidelines
Notations to use and not use.
For example, whether to use generalization
relationships.
Rules, recommendations, style issues, and
how to describe each use case.
Recommendations for when to start
structuring the use cases (not too early).
Handout
RUCS11: Use-
Case Modeling
Guidelines
22
Discussion: Structuring the Use-Case Model
How should we structure the use-case
model for our class project?
Include relationships?
Extend relationships?
Actor generalizations?
23
Review: Relationships in the Use-Case Model
to
from
generalization communicates
«include»
communicates «extend»
generalization
24
Checkpoints for Use Cases
For an included use case: does it make
assumptions about the use cases that
include it? Such assumptions should be
avoided so that the included use case is not
affected by changes to the including use
cases.
Are there some optional requirements that
are not part of the standard product
requirements? If so, you model this with an
extend-relationship to the other use case.
25
Review: Structure the Use-Case Model
1. Why might you decide to structure your use-case
model?
2. When is an extend-relationship used?
3. When is an include-relationship used?
4. What is an abstract actor?
A concrete actor?
An abstract use case?
A concrete use case?
26
Summary (1 of 2)
Build the right system right by using a
process to define and manage
requirements to meet the customer’s
needs.
Effective problem analysis helps avoid the
“Yes, but…”
Elicitation helps you understand your
stakeholders’ needs.
Use features and a use-case model to gain
agreement with the customer on the
definition of the system.
27
Summary (2 of 2)
Increase your chances to deliver on time
and on budget by managing scope
throughout the lifecycle of the project.
A use-case model of requirements helps
refine the system definition to drive design,
test, and user documentation.
Requirement attributes and traceability help
you manage change and avoid “scope
creep.”
28
