Introduction to UML Diagrams:
Use Case Diagrams
Georgia State University
CIS 3300 Spring 2010
UML Modeling
You can model 80% of most problems by using about 20% UML
In this course, we will discuss those 20%
UML Primary Diagrams
Use Case diagrams
Describe the functional behavior of the system as seen by the user.
Sequence diagrams
Describe the dynamic behavior between actors and the system and between objects of the system.
Class diagrams
Describe the static structure of the system: Objects, Attributes, and Associations.
UML Primary Diagrams (Cont)
State Machine diagrams
Describe the dynamic behavior of an individual object as a finite state machine.
Activity diagrams
Model the dynamic behavior of a system, in particular the workflow, . a flowchart.
UML – Other Diagrams
Communication Diagrams
Package Diagrams
Introduction to Use Case Diagrams
Use Cases:
Technique for capturing functional requirements of a system
Describe typical interactions between users of a system and the system itself.
A scenario is a sequence of steps describing an interaction between a user and a system.
Scenarios model the goal of the user (an actor).
An actor is a role that a user plays with respect to the system.
A use case is a set of scenarios tied together by a common user goal.
Introduction to Use Case Diagrams:
‘Buy a Product’ Scenario
The customer browses the catalog and adds desired items to the shopping
basket. When the customer wishes to pay, the customer describes the ship-
ping and credit card information and confirms the sale. The system checks
the authorization on the credit card and confirms the sale both immedi-
ately and with a follow-up call.
Who is the actor?
What is the actor’s goal?
What if the customer is a regular customer and you
Already know shipping and credit card information?
What happens if credit card authorization fails?
Contents of a Use Case
Main success scenario
Sequence of numbered steps
‘Other’ scenarios:
Variations on the main success scenario
Are ‘extensions,’ can be successes or failures:
Conditions that result in different interactions from those described in the main success scenario (MSS).
Example Use Case Text
Introduction to Use Case Diagrams
Types:
business use cases
system use cases (our focus)
Use cases tell a story of actors using a system.
They illustrate functional requirements, by the stories they tell.
Complementary with a functional requirements list.
Identifying Use Cases
Major distinct, complete, end-to-end processes of using a system.
Not usually one step, but a complete story.
Common “mistake”!
Examples
Rent Videos
Return Videos
Pay Fines
Use Case Diagram
A way to conceive and illustrate the use cases.
Usually created during the initial use case analysis.
A Sample Detailed Use Case
A Sample Summary Use Case
Same principles a detailed use case, but simplifies steps and details, as a low-fidelity incomplete first draft.
Useful during early requirements and scope analysis
System Responsibilities
3. Remember rented items.
4. Calculate and present price.
6. Authorize and record payment.
Actor Intentions
Customer presents items to rent.
Clerk records items.
Customer pays.
Use Case Diagram
UML Second Pass: Use Case Diagrams
Used during requirements elicitation to represent external behavior
Actors represent roles, that is, a type of user of the system
Use cases represent a sequence of interaction for a type of functionality
The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment
Passenger
PurchaseTicket
Actors
An actor models an external entity which communicates with the system:
User
External system
Physical environment
An actor has a unique name and an optional description.
Examples:
Passenger: A person in the train
GPS satellite: Provides the system with GPS coordinates
Passenger
Use Case
A use case represents a class of functionality provided by the system as an event flow.
A use case consists of:
Unique name
Participating actors
Pre-conditions
Entry conditions (triggers)
Flow of events
Exit conditions (success ‘guarantees’)
Special requirements
PurchaseTicket
The <<extend>> Relationship
<<extend>> relationships represent exceptional or seldom invoked cases.
The exceptional event flows are factored out of the main event flow for clarity.
Use cases representing exceptional flows can extend more than one use case.
The direction of a <<extend>> relationship is to the extended use case
Passenger
PurchaseTicket
NoChange
<<extend>>
OutOfOrder
<<extend>>
Cancel
<<extend>>
Passenger
PurchaseSingleTicket
PurchaseMultiCard
NoChange
<<extend>>
Cancel
<<extend>>
<<include>>
CollectMoney
<<include>>
The <<include>> Relationship
An <<include>> relationship represents behavior that is factored out of the use case.
An <<include>> represents behavior that is factored out for reuse, not because it is an exception.
The direction of a <<include>> relationship is to the using use case (unlike <<extend>> relationships).
Relating Use Cases
When creating the use case diagram, it can be useful (in terms of comprehension and simplification) to:
factor out shared sub-processes
use the <<includes>> relationship
show precedence order (with exceptions)
use the <<extends>> relationship
Contents: ATM
Requirements Capture
A simplified Automatic Teller Machine
Which requirements are to be captured?
The activities in Requirement capture
Identification of system boundaries: actors and use cases
Diagramming use cases
Elaborating scenarios
Diagramming scenarios
A Simplified Automatic Teller Machine
The ATM is associated with only one bank
It gives access to all the accounts the customer owns in the bank
Several types of transactions can be chained in a single session
Withdrawal, deposit, transfer between the customer’s own accounts, consulting an account
The customer may obtain a printed receipt for each transaction
A Simplified Automatic Teller Machine (cont. 1)
The card contains
an ID number
an expiration date
a secret code
The card must be verified by the ATM
The customer cannot make more than 3 attempts to enter the correct code, otherwise the card is swallowed
Interface
Keyboard and screen, with menus
The customer may cancel the current transaction at meaningful points
A Simplified Automatic Teller Machine (cont. 2)
The connections with the bank are kept to a minimum
When a session is opened, a connection makes it possible to known all the accounts the customer owns
Every night, the information about the current day transactions are transferred to the bank
From time to time an employee manually
empties the machine and/or fills it with bank notes
supplies consumables and does any maintenance that may be needed
Which requirements are to be captured?
Functional requirements
Modeled as Use Cases
Non functional requirements
Some are specific to one use case
Some relate to technical issues addressed by implementation diagrams and models
Other in some supplementary documents, out of the UML scope…
Identifying System Boundaries
Identifying Actors
Actors are anything which interface with the system
People, other systems, hardware, software, networks…
They are roles, not necessarily full-fledged objects
Actors are not part of the system
They are just at the boundary (external to the system)
They won’t produce code!
Identifying System Boundaries
Identifying Actors (cont.)
ATM example
Customer using the teller machine
Bank
Maintenance technician
What about the card itself?
Customer
Bank
Technician
Identifying System Boundaries
Identifying Use Cases
Use cases describe the services the system must perform from the point of view of the actors
Functional description
From an usage point of view
Diagramming Use Cases
Top Level Use Case Diagram
Handle Session
Transfer Daily
Maintain
Bank
Technician
Customer
association
system boundary
Diagramming Use Cases
Stereotyped Dependencies
Handle Session
« include »
Verify Card
« include »
Authentify Customer
« include »
Get Customer Information
Handle
Transaction
« include »
Deliver
Receipt
« extend »
Diagramming Use Cases
Stereotyped Dependencies
« include »
The included use case is a mandatory part of the including one (functionality-wise, not actor-wise)
« extend »
The extending use case is an optional part of the extended one (functionality-wise, not actor-wise)
Including
« include »
Included
Extended
« extend »
Extending
Diagramming Use Cases
Generalization
Handle
Transaction
Handle
Deposit
Handle
Withdrawal
Handle
Consult
Handle
Transfer
Diagramming Use Cases
Generalization
The specialized and generalized use cases are in a “sort of” relationship
Generalized
Specialized
Elaborating scenarios
Use Case and Scenarios
Use cases classify the ways of using the system
To each use case correspond many possible usage scenarios
Thus scenarios
are instances of use cases
specify use cases
Each use case has generally
a primary scenario, possibly several (a few)
several secondary (more exceptional) scenarios
Elaborating Scenarios for Use Cases
Alistair Cockburn’s style (1)
Use Case: Handle Session
Precondition: the ATM is free
Primary Scenario
The Customer inserts the card into the ATM.
The ATM verifies the card validity.
The Customer authentifies with the ATM.
The ATM gets the Customer information from the Bank.
The Customer selects a transaction.
The Customer quits.
The ATM ejects the card.
Postcondition: the ATM is free
Handle Session
« include »
Verify Card
« include »
Authentify Customer
« include »
Get Customer Information
Handle
Transaction
« include »
Elaborating Scenarios for Use Cases
Alistair Cockburn’s style (2)
Use Case: Handle Session
Precondition: the ATM is free
Primary Scenario
The Customer inserts the card into the ATM.
The ATM verifies the card validity.
The Customer authentifies with the ATM.
The ATM gets the Customer information from the Bank.
The Customer selects a transaction.
The Customer quits.
The ATM ejects the card.
Postcondition: the ATM is free
Variants
2a The card is invalid; the ATM swallows it; this ends the session.
3a The Customer fails to authentify; the ATM swallows the card; this ends the session.
4a The connection with the Bank is impossible or interrupted; the ATM ejects the card; this ends the session.
5a The Customer may quit immediately.
6a The Customer chooses to perform another transaction; goto step 5.
* The Customer may cancel the session; the ATM ejects the card.
Elaborating scenarios
Primary Scenario
Use Case: Handle Session
Scenario: Primary (typical)
Precondition: the ATM is free
The scenario starts when the customer inserts the card
The card is accepted
The customer enters the secret code correctly
The ATM gets the customer information from the bank
The customer performs a transaction
When the transaction is finished, the customer may ask for another transaction (go to 5) or quit
The scenario is finished when the customer decides to quit; the card is ejected
Postcondition: the ATM is free
Elaborating scenarios
Example of Secondary Scenarios
Use Case: Handle Session
Scenario: Secondary (customer interrupt)
Precondition: the ATM is free
The scenario starts when the customer inserts the card
The card is accepted
The customer enters the secret code correctly
The customer cancel the session
The card is ejected and the scenario is finished
Postcondition: the ATM is free
*
*
*
*
*
Possibly show CD-ROM
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
