Analyse et Méthodologie

Informatiques

Use Case Diagrams

Roel Wuyts
ULB
2005/2006

http://decomp.ulb.ac.be/education/ami0506/
UML Use Cases
Can be used to discover requirements
✦ and write them down
Central to UML
✦ Link users and system builders
Tend to be better to find out functional user
requirements (focus on interaction)
✦ not well suited to find out about constraints, high-level
business and non-functional requirements, or domain
requirements

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 2

Parts of a Use Case Diagram...
System
Systems Name_Of_System
Actors

Use cases

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 3

Parts of a Use Case Diagram...
The system
✦ Could be any system, not just SW systems.
✦ Define clear and precise boundaries:
‣ Don’t be too ambitious - think small !
‣ Identify basic functionality and concentrate on defining a
stable and well-defined architecture.
‣ More functionality can always be added later!
✦ Compile a catalog of central concepts or entities

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 4

Parts of a Use Case Diagram...
The actors
✦ Who or what uses the system
‣ Represents a role, not an individual user!
✦ Communicates with the system by sending and
receiving messages
✦ Actors are in control and initiate actions
✦ Actors can be ranked :
‣ Primary and secondary actors

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 5

Parts of a Use Case Diagram.
Use cases
✦ A set of sequences of actions a system performs
‣ A textual description !
✦ Always initiated by an actor
✦ Delivers an observable result of value to an actor
✦ Is connected to an actor through associations
‣ Normally bidirected one-to-one relations

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 6

Use case
Specify desired behaviour
✦ not how it is carried out (implemented)
✦ Therefore it is useful for communication between
users and developers
carries out some tangible amount fo work
✦ not too big, nor too small
✦ does something that’s of value to an actor

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 7

Use case diagram Example

Insurances

Process loan

LoanOfficer

actor association use case system

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 8

Describing the use case
Flows of events specify the behaviour of a use case
✦ clearly enough for an outsider to understand it
✦ what a system does, not how!
Several ways
✦ structured text (without/with pre-post conditions)
✦ pseudo-code
✦ sequence diagrams
✦ state diagrams

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 9

Use case descriptions
A description should include:
✦ how and when the use case starts and ends
✦ when it interacts with actors and what objects are
exchanged
✦ the basic flow and alternative flows of the behaviour

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 10

Use Case Specification Structure Example
Actors
Pre-conditions
Post-conditions
Basic Flow
Alternative Flows
Special Requirements
Use case relationships
✦ (for complex systems)

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 11

Description Example
Main flow of events: The use case starts when the system prompts the
Customer for a PIN Number. The Customer can now enter a PIN number
via the keypad. The Customer commits the entry by pressing the Enter
button. The system then checks this PIN number to see if it is valid. If the
PIN number is valid, the system acknowledges the entry, thus ending the
use case.

Exceptional flow of events: The Customer can cancel a transaction at any

time by pressing the Cancel button, thus restarting the use case. No
changes are made to the Customer’s account.

Exceptional flow of events: The Customer can clear a PIN number anytime
before committing it and reenter a new PIN number.

Exceptional flow of events: If the Customer enters an invalid PIN number,

the use case restarts. If this happens three times in a row, the system
cancels the entire transaction, preventing the Customer from interacting
with the ATM for 60 seconds.
Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 12
Describing a Use Case…
Use cases are goal oriented !
✦ What is it trying to achieve
✦ Which functions does the actor require, what does he/
she need to do?
✦ Which actor initiates the use case and in which
situations?
✦ Which messages or events are necessary

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 13

Describing a Use Case.
What is the flow of messages between actors and the
use case?
✦ Depends on conditions and exceptions
‣ Be cautious : don’t be too detailed
‣ Specific exceptions can be clarified by scenarios

Which entities are modified and/or used?

When is the use case considered to be finished and
what kind of value is delivered to the actor?

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 14

Relationships
Between actors
✦ generalization
Between use cases
✦ generalization
✦ inclusion
✦ extension

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 15

Actor generalization
Can have general kinds of actors, and specialize them
with the generalization relationship

Customer

Commercial
Customer

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 16

Use case generalization
child use case inherits behaviour and meaning from
the parent use case
✦ and can override
child use case can be used wherever the parent use
case is used

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 17

Use case generalization example

Validate User

Check
Retinal Scan
password

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 18

Includes relationship
A base use case including a supplier use case means
that the base use case explicitly incorporates the
supplier use case at a certain location
✦ the included use case never exists alone
✦ think of include as: the base case pulling behavior from
the supplier case
Used to model common behaviour in one place, and
afterwards use it in several other places

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 19

Includes relationship example

Signing
Insurance
Policy

<include> <include>

Signing Car Signing Life

Insurance Insurance

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 20

Includes relation description

<include>
Track Order Validate User

Description of Track Order use case:

Main flow of events: Obtain and verify the order

number. include (Validate User). For each part in the
order, query its status, then report back to the user.
Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 21
Extends relationship
“A base use case extends an extension use case”
means that the base use case implicitly incorporates
the behaviour of the extension use case at a location
specified by the extension use case
✦ the location is called the extension point
Used to model optional system behaviour
✦ So mandatory behaviour can be modeled separately
from optional behaviour

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 22

Extends relationship
extend relationship

Place order <extends>

(set priority) Place rush
Extension points order
set priority

<include>

extension point
Validate User

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 23

Extends relationship description
Description of Place Order use case:

Main flow of events: include (Validate user). Collect

the user’s order items. (set priority). Submit the order
for processing.

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 24

Example
Cellular Telephone

<extend>
Place
Place phone call
conference call
Cellular
Network

<extend>
Receive
Receive phone call
additional call

User

Use scheduler

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 25

What to model with use cases?
Behavior of an element
✦ what a element does
Context of a system
✦ interaction of outside actors with the system
Requirements of a system
✦ make contract between outside and system

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 26

Modeling element behaviour
Advantages
✦ let domain experts specify outward view (what) so
that developers can construct inside view (how)
✦ let developers approach an element and understand it
✦ basis for testing

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 27

Modeling element behaviour
Identify the actors that interact with the element
Organize actors by identifying general and more
specialized roles
For each actor, consider the primary ways it interacts
with the element
Consider exceptional ways of interaction
Organize these behaviours as use cases
✦ Every behaviour -> one use case

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 28

Example

Bill customer
Place order

<include>

<include>
Validate customer
Track order

<include>

Ship order
<extend>
Ship partial order
Extension points
materials ready

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 29

Modeling the System Context
Systems have an inside and an outside
✦ Those inside carry out behaviour that those on the
outside expect
Can be modeled explicitly with use cases
✦ Focus lies on actors surrounding the system
✦ What to include as an actor
‣ and what not

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 30

Modeling the System Context
Identify the actors that surround the system
✦ which groups require help from the system
✦ which groups are needed to execute the system
✦ which groups interact with external hardware
✦ which groups perform secondary functions for
administration and maintenance
Organize the actors (generalization relationships)
When needed, stereotype actors
Put them in a use case and connect to use cases
Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 31
Modeling the System Context
Credit Card Verification System

Perform card
transaction

Customer

Process customer Retail

bill institution

Reconcile
Individual Corporate transactions
Customer Customer
Sponsoring
financial
institution
Manage customer
account

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 32

Modeling System Requirements
Establish outside actors
For each actor, model expected or required behaviour
name these common behaviour with use cases
model relations between actors and use cases
Adorn the use cases with notes that assert
nonfunctional requirements of the system

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 33

Modeling System Requirements
Credit Card Verification System

Perform card
transaction
Customer Report on account
status

Process customer
bill

Retail
institution Detect card fraud
Reconcile
transactions

Manage customer Manage network

Sponsoring account outage
financial
institution

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 34

Notes and Tips
A well-structured use case:
✦ names a single identifiable behaviour of the system
✦ factors common behaviour by using inclusion
✦ factors variants by using extension
✦ describes the flow of events clearly enough for an
outsider to easily understand it
✦ uses a minimal set of descriptions that specify the
normal and variant semantics of the use case

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 35

Notes and tips: drawing
When drawing a use case:
✦ show only those use case that are important to
understand the behaviour
✦ show only the actors relating to these use cases
When drawing a use case diagram:
✦ give it a name communicating its purpose
✦ minimize lines that cross
✦ semantically close elements should be physically close
✦ Use different diagrams when needed
Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 36
Examples
University
Camera

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 37

Example 1 : University

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 38

Example 2 : University

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 39

Example 3 : Camera

Camera

Open
Shutter

Flash

Photographer

Close
Shutter

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 40

Example 4 : Camera

Camera

Take Picture

Photographer
Change Film

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 41

Conclusion
Use “Use Case Diagrams” to capture user
requirements
✦ Note that there is the diagram and the descriptions
Can have relations between use cases: generalization,
inclusion and extension

Roel Wuyts - ULB - Analyse et Méthodologie Informatiques - 2005/2006 42