®

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