Use Case Modeling

SE 3140
SYSTEM DESIGN AND

MODELING
Prepared by: Dams Gabriel Fall 2021

ICT University
CHAPTER 4:
Use Case Modeling
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 2

Topics Overview
• Use Case Modeling
• What Use Cases are?
• Example of Use Case Diagram
• Documenting Use Cases
• Activity Diagrams
• Documenting Uses Cases with
Activity Diagrams
• Advanced Use Case Modeling
• Use Case Relationships

Use Case Modeling
• Use Case Model:
– Identifies black box functionality of
system
• Use case: black box function / goal /
feature – System level
• Actor: External role interacting with
system – can be anything
– This overall defines the system boundary
– Shows interaction between actor and
black box system
Use Case Modeling
• Use cases refined in Dynamic Model
– Show objects participating in use case
– Develop interaction diagrams
• Use cases refined further in Design Model
• Use cases form basis of integration &
system test cases

Architectural Views
Logical View Development View
Static Implementation
• Classes • Code organization
• Abstraction Scenarios
• Associations
• Structure Use Cases
• Requirements
• Testability
• Planning
Dynamic Deployment
• Interactions • System topology
• Behavior over • Installation
time
Process View Physical View

Multiple View (4 + 1) Model for Software Design
Use Cases
• A collection of user scenario that
describes the thread of usage of a
system
• Each scenario is described from the
point-of-view of an “actor”
– Actor is a person or device that
interacts with the software in some way

Use Cases
• Each scenario answers the following
questions
– Who is the primary actor, the secondary
actor(s)?
– What are the actor’s goals?
– What preconditions should exist before the
story begins?
– What extensions might be considered as the
story is described?
– What variations in the actor’s interaction are
possible?
Use Cases
• Each scenario answers the following
questions continued…
– What system information will the actor
acquire, produce or change?
– Will the actor have to inform the system about
changes in the external environment?
– What information does the actor desire from
the system?
– Does the actor wish to be informed about
unexpected changes?

Use Case Diagram
Use Case
Actor

Actors
• Actor models external roles interacting
with the system
• Actors interact directly with system
– Human user
– External device
– Timer
– External system
– Primary actor initiates use cases
– May use I/O devices or external system
to physically interact with system
Actors
• Typically human if interacting through
standard I/O devices
• Often non-human for embedded systems

where input is through sensors, etc.

Actors
Make
Reservation
Customer Timeout
Timer

More on Actors
• Primary Actor
– Starts the use case by providing input
to the system
• Secondary Actor
– Participates in use case
– Can be Primary Actor of a different use
case

More on Actors
• Actor
– Represents a role rather than an individual
• e.g. with ICT moodle, I can act as a Teacher or a
Student
• 2 Actors, 1 physical person
• Conversely, ALL students represented by

single Student actor

Use Cases
• Define system functional requirements in
terms of Actors and Use Cases
– Underlying description of scenarios - most
important part of use case
– Described from the user/actor point of view
• Identifying use cases

– Consider requirements of each actor who
interacts with system
– Use case is a complete sequence of events
initiated by an actor
• Use case starts with input from an actor
• Describes interactions between actor and system
Use Cases
• Captures what the system does in response to
inputs, not internals of how it does it
• Some questions to ask

– What functions will a specific actor want from the
system?
– Does the system store and retrieve information? If so,
what triggers this behavior?
– Are any actors notified when the system changes
state?
– Are there any external events that affect the system?
Who/what notifies the system and what actions are
taken?
• Document basic path and all alternatives

Example: Car Reservation Rental System

Example: Car Reservation Rental System
Rental Car Reservation
System
Not Complete
Login
Make
Reservation
View
Reservation
Modify
Reservation
Customer Customer
Get Receipt Service Rep
Contact
Customer
Service
Timeout
Timer

Documenting Use Cases
• Name
• Summary:
– Short description of use case
• Dependency (on other use cases)
• Actors
• Preconditions
– Conditions that are true at start of use case
• Description
– Sequence/flow of basic steps from actor’s
point of view
• Can be textual or graphical (preferred)
Documenting Use Cases
• Nonfunctional Requirements
– Considerations needed for performance,
security etc.
• Postcondition
– Condition that is true at end of use case
• Outstanding questions
– Discussion points for stakeholders

Activity Diagram
• Visually presents a series of actions or flow
of control in a system.
• Similar to a flowchart or a data flow
diagram.
• It describes the steps in a use case diagram.
– It describes what happens to satisfy the use case
• The activities modeled can be sequential and
concurrent.
– In both cases an activity diagram will have a
beginning (an initial state) and an end (a final
state).
Activity Diagrams
• Initial Node
• Control Flow
• Action or Activity
• Decision Point
• Merge
• Fork (without decision)
• Join
• Final Node

Activity Diagram
• Initial Node:
– A small filled circle followed by an arrow
represents the initial action state or the start
point for any activity diagram.
• Control/Action Flow:
– called edges and paths
– illustrate the transitions from one action
state to another.
– They are usually drawn with an arrowed line.

Activity Diagram
• Action or Activity:
– represents the non-interruptible action of
objects.
• Decision Point:
– When an activity requires a decision prior to
moving on to the next activity, the symbol is
used.
– The outgoing arrows should be labeled with a
condition or guard expression.

Activity Diagram
• Merge
– An event that brings together multiple flows that
are not concurrent.
– We can merge two or more activities into one if
the control proceeds onto the next activity
irrespective of the path chosen.
• Fork (without decision)

– Notation used to split a single incoming flow into
multiple concurrent flows.
– When we use a fork node when both the activities
get executed concurrently i.e. no decision is made
before splitting the activity into two parts
Activity Diagram
• Join
– Notation to join multiple concurrent flows
back into a single outgoing flow.
– NOTE: A fork and join mode used together

are often referred to as synchronization.
• Final Node
– The state which the system reaches when a
particular process or activity ends.
– Also known as a Final State or End State.
Documenting Uses Cases with Activity Diagrams
• Precondition
• Actor Input
• Step in the flow
• Alternative/extension
• Return to nominal flow
• Parallel Activities
• Postcondition
Advanced Use Case Modeling
• Most industrial applications contain a large
number of use cases and actors
• Advanced use case modeling can help
simplify the overall model by:
– Factoring common use case functionality and actor
roles
– Providing extension mechanisms for use case
variations
• Two basic relationships for use cases:

– «include»
– «extends»
Use Case Relationships
• «include» relationship
– Factor common repetitive patterns (sequences) in
several use cases
– Separate more complicated steps or steps that
are more likely to change
– Use case specification for «include» is similar to a
function call
– Included use case may or may not be complete
– Base use case is not complete without the included
use cases
• Example
– Modify Reservation includes View Reservation
«include» Relationship
Rental Car Reservation
System
Not Complete
Login
Make Reservation
View Reservation
«include»
Customer Customer
Service Rep
Modify Reservation
Get Receipt
Contact
Customer
Service
Timeout Timer
• «extend» relationship
– Provides conditional variation to use cases
– Extension points identified in the base use case
– Extension use cases executed at the specified
extension points based on identified conditions
– Extension use cases are generally not complete
– Base use case is complete without the extended
use cases
• Extension points are simply “hooks”
– Can be extended in different ways

• When to use «extend» relationship
– Show conditional parts of use case
– Model complex or alternative paths
• Example
– Register «extends» Login at the extension point for
new users

«Extend» Relationship
Login
<<extends>>
New User «extends»
[New User] Register
Make Reservation
View Reservation
Customer «include»
Modify Reservation
Get Receipt
Not Complete
Contact
Customer
Service
Timeout Timer
Additional Use Case Options
• Dealing with large number of use cases
– Can structure use cases in packages
• Related functionality
• Related actors
• By incremental development plans
• Packages are basically folders such as

those used in most OS file structures.

Use Case Summary
• Use case models provide the transition
between software/system requirements
specifications and software design
– Actors: identify external roles (human, system,
or device)
– Use cases: identify black-box functionality
assigned to the software system
• Must involve stakeholders when

constructing use case models
– In general, stakeholders can understand actors
and use cases
Use Case Summary
• Use cases form the basis of system test
plan
• Use cases must have specifications
– Text is common
– Activity diagrams are preferred(less ambiguous)
• Must have well-written specifications, not

just drawings

Q&A

Use Case Modeling

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Use Case Modeling

Uploaded by

Copyright:

Available Formats

SE 3140

SYSTEM DESIGN AND

Prepared by: Dams Gabriel Fall 2021

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 2

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 3

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 5

Process View Physical View

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 7

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 9

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 10

• Often non-human for embedded systems

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 12

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 13

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 14

• Conversely, ALL students represented by

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 15

• Identifying use cases

• Some questions to ask

• Document basic path and all alternatives

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 18

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 19

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 21

• Fork (without decision)

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 23

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 24

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 25

• Fork (without decision)

– NOTE: A fork and join mode used together

• Return to nominal flow

• Two basic relationships for use cases:

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 32

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 33

[New User] Register

• Packages are basically folders such as

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 35

• Must involve stakeholders when

• Must have well-written specifications, not

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 37

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 4: Slide 38

You might also like