1

>

Use Case

Dr. Anıl Koyuncu

> UML Use Case
➢A use case is a kind of behaviored classifier that specifies a
[complete] unit of [useful] functionality performed by [one or
more] subjects to which the use case applies in collaboration with
one or more actors, and which yields an observable result that is
of some value to those actors [or other stakeholders] of each
subject.

2
> Relationships Between Use Cases
• Use cases can be organized using the following relationships:
• Generalization
• Extend
• Include

3
> Generalization Between Use Cases
➢Definition:
• Generalization is similar to generalization between classes.
• A child use case inherits properties and behaviors from the parent use
case.
• The child may override the behavior of the parent.

4
> Generalization
➢Visual Representation:
• Symbol: Solid directed line with a large hollow triangle arrowhead.
• Direction: From the more specific use case to the general use case.

5
> Extend Relationship
➢Extend is a directed relationship that specifies how and when the
behavior defined in an optional extending use case can be
inserted into the behavior of the extended use case.

6
> Extended Use Case
• Meaningful on Its Own:
• An extended use case is complete and makes sense independently.
• Independence:
• It does not rely on the extending use case for its functionality.

7
> Extending Use Case
• Typically defines optional behavior.
• This behavior may not be meaningful by itself.
• Ownership:
• The extend relationship is owned by the extending use case.

8
> Extended vs Extending

➢Registration use case is complete and meaningful on its own.

➢It could be extended with optional Get Help On Registration use

case.

9
> Extend relationship
➢Visual Representation:
• Symbol: Dashed line with an open arrowhead. The arrow is labeled with
the keyword «extend».
• Direction: From the extending use case to the extended (base) use
case.

10
> Include Relationship
➢Use case include is a directed relationship between two use
cases which is used to show that behavior of the included use
case (the addition) is inserted into the behavior of
the including (the base) use case.

11
> Purpose of Include Relationship
• Simplification:
• Simplifies large use cases by splitting them into several smaller use
cases.
• Extraction of Common Behavior:
• Extracts common parts of the behaviors of two or more use cases.

12
> Include relationship
➢Visual Representation:
• Symbol: Dashed arrow with an open arrowhead. The arrow is labeled with
the keyword «include».
• Direction: From the including (base) use case to the included
(common part) use case.

Checkout use case includes several use cases - Scan Item,

Calculate Total and Tax, and Payment
13
 The Generalization Relationship in Use Case
> Diagrams
➢The inheriting use case replaces one or more of the courses of
action of the inherited use case. The inheriting use case overrides
the behavior of the inherited use case.

- 14 -
> Use Case Relationships: Includes

● You have a piece of behavior that

is similar across many use-cases.
● Break this out as a separate use-
<<includes>>
<<includes>>
case and let the others “include” it.
● Avoids repetition in written use-
cases.
○ Step 1: Complete “Validate PIN” use-
case.
○ Step 2: Select account.
○ ...

- 15 -
> Use Case Relationships: Extends
Extends
● A use-case is similar to another, but does
more or takes an alternate path.
● Put the normal behavior in one use-case
and the exceptional behavior somewhere
else:
○ Capture the normal behavior.
○ Try to figure out what went wrong in each
step.
○ Capture the exceptional cases in separate
use-cases
● Allows for easier to understand
descriptions.

- 16 -
> UML use case diagrams

<<includes>>

- 17 -
 A Use case diagram looks so simple, why bother with
> it?

➢Firstly it shows the BIG-PICTURE without getting bogged down in the details of design and
implementation (i.e. It’s pretty much independent of hardware, OS, GUI, programming
language, databases, networks etc) so it focuses on what needs to be done, not on how it will
be done.

➢Secondly, the customer can easily relate to a use-case diagram and identify the major
objectives of their business within it.

➢This means that any major or miss-understood functionality required from the system is less
likely to be overlooked during analysis (very important) or incorrectly interpreted.

➢From a developers point of view they can immediately assess the functionality required and
assess the risk involved in implementing each use case. Resources, hiring and training can
then be allocated appropriately as part of the project planning.
> Use Case Modeling Benefits
➢A view of system behavior from an external person’s viewpoint.
→An effective tool for validating requirements.
→An effective communication tool.
→As a basis for a test plan.
→As a basis for a user’s manual.
>

20
> Problem Example: Safe Home Access
➢Problem detected:
• inconvenient physical keys or unwanted intrusion
(plus: operating household devices and minimizing living expenses)
➢Analysis of the Causes:
• User forgets to lock the door or turn off the devices
• User loses the physical key
• Inability to track the history of accesses
• Inability to remotely operate the lock and devices
• Intruder gains access
➢System Requirements: based on the selected causes

21
> Deriving Use Cases from System Requirements
1
REQ1: Keep door locked and auto-lock 2
REQ2: Lock when “LOCK” pressed 3
4
REQ3: Unlock when valid key provided
5
REQ4: Allow mistakes but prevent dictionary attacks X
REQ5: Maintain a history log Y
REQ6: Adding/removing users at runtime
REQ7: Configuring the device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries

Initiator Initiator’s Goal Participants Use Case Name

Lock, Household Devices,
Tenant Unlock and enter home. Unlock (UC-1)
Database
Lock, Household Devices,
Tenant Lock the door. Lock (UC-2)
Database
Create a new user account and allow access to
Landlord Tenant, Database AddUser (UC-3)
home.
Landlord Retire an existing user account and disable access. Database RetireUser (UC-4)

Tenant Review the history of home accesses. Database ViewHistory (UC-5)

Configure the operational preferences for household

Tenant Database SetDevicePrefs (UC-6)
devices.
Visitor Visit a resident’s home. Lock, Database VisitHome (UC-7)

• Initiating actors (“users”) are already identified in user stories

• Participating actors identified as part of use case analysis
> System Boundary & Subsystems

Use Case Variations Example:

C a se (a ):
L o c a l fa c e r e c o g n itio n

Local
c o m p u te r

Face
im a g e
A p a r t m e n t b u ild in g

S e c u r ity
c a m e ra

NN ee t tww oo r rkk
C a se (b ):
R e m o t e f a c e r e c o g n it io n F a c e R e c o , L td .
> Use Case Diagram: Case (a)
UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login
system
boundary Base use cases Subroutine use cases

actor
UC8: AuthenticateUser

UC1: Unlock
LockDevice

Tenant

LightSwitch
UC2: Lock

communication use case

Landlord Timer
> Use Case Diagram: Case (b)
UC1: Unlock
UC2: Lock
UC3: AddUser

Authentication subsystem (FaceReco, Ltd.) UC4: RemoveUser

UC5: InspectAccessHistory
UC6: SetDevicePrefs
is externalized from the system-to-be: UC7: AuthenticateUser
UC8: Login

U C 2 : L o c k

« p
U C 1 : U n lo c k L o c k D e v ic e
« i
T e n a n t n »
a » c
e U C 7 : A u th e n tic a te U s e r
t l
r u « p
a
i d
tt
i a e »
i e « p a t
n » U C 3 : A d d U s e r r t ic p a r»
« i c ip i
« i it c a t e t
i r i
« i p n a c»
n » » « p
it
U C 4 : R e m o v e U s e r
i
p
F a c e R e c o , L td .
iaa « i c
L a n d lo r d n »
t a
te c l
e l uu t
U C 8 : L o g in e
d
d
e
e
> Use Case Diagram: Account Management
UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login

A c c o u n t M a n a g e m e n t S u b s y s te m
ia te
e
« in it t »
a U C 3 : A d d U s e r
« i
« i p n
n i
c it » c »
L a n d lo r d i ia l
t u
te » « in e
r U C 4 : R e m o ve U s e r
a
c
lu
d d»
d e l ue
« p e
c » U C 8 : L o g in
te d
ia « in
it » u
« in U C 5 : In s p e c tA c c e s s H is to r y l
»
c
n
« in i
«
it »
ia
T e n a n t te U C 6 : S e tD e v ic e P r e f s
> Login Use Case?

BAD: GOOD:

Login

AddUser
AddUser
Login
Landlord
SetDevicePrefs Landlord SetDevicePrefs
> Login Use Case?
➢Use case is motivated by user’s goal

➢The user initiates interaction with the system to achieve a certain

goal. You are not logging in for the sake of logging in—you are
logging in to do some work, and this work is your use case.

28
 Subroutine Use Cases
> Optional Use Cases: «extend»
UC1: Unlock
UC2: Lock
UC3: AddUser
Example optional subroutine use cases: UC4: RemoveUser
UC5: InspectAccessHistory
UC5: InspectAccessHistory UC6: SetDevicePrefs
UC7: AuthenticateUser
UC8: Login
ManageAccount

UC6: SetDevicePrefs

Key differences between «include» and «extend» relationships

Included use case Extending use case
Is this subroutine use case optional? No Yes
Is the base use case
complete without this use case?
No Yes

Is the execution of subroutine use case conditional? No Yes

Does this subroutine use case change
the behavior of the base use case?
No Yes
> Use Case Generalizations
➢More abstract representations can be derived from particular
representations
UC1: Unlock
UC2: Lock
UC3: AddUser
UC4: RemoveUser
UC5: InspectAccessHistory
UC6: SetDevicePrefs
UC7: AuthenticateUser
More UC8: Login
general
Resident

UC9: ManageUsers

Tenant Landlord

More particular UC3: AddUser UC4: RemoveUser

Actor Generalization Use Case Generalization

>

31