Lecture 07: Use Case Diagram

CSC210A Software Development Fundamentals

B. Tech. 2017

Course Leader(s):
Ms.Sahana.P.Shankar
sahana.cs.et@msruas.ac.in
Ms. Supriya, M. S.
supriya.cs.et@msruas.ac.in

1
Faculty of Engineering & Technology © Ramaiah University of Applied Sciences
 Lecture Objectives

• At the end of this lecture, student will be able to

– Identify the basic building blocks of UML Use Case diagram
– Explain the concepts of object oriented analysis
– Model and analyze a software system with Use Case diagrams
– Design the context of given software system with object oriented approach

2 2
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Lecture Topics

• Behavioral diagrams
• Use Case diagram
• Elements in Use Case diagram
• Relationships in Use Case diagram

3 3
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Behavioral Diagrams

• The diagrams to visualize, specify, construct, and document the

dynamic aspects of the system

• The dynamic aspects of a house encompasses airflow through the

rooms of a house

• The UML includes five behavioral diagrams

– Use Case diagram
– Sequence diagram
– Collaboration diagram
– State chart diagram
– Activity diagram

4 4
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Use Case Diagram

• A Use Case diagram lets you view the whole system as a black box
– You can see what's outside the system and how that system
reacts to the things outside
– You can't see how that system works on the inside

• Use Case diagrams commonly contain

– Use Cases
– Actors
– Dependency, generalization, and association relationships

5 5
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 A Use Case Diagram

6 6
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Common Uses of Use Case Diagrams

• To model the context of a system (from the actors)

– Emphasizes the actors that surround the system
– Involves drawing a line around the whole system and asserting
which actors lie outside the system and interact with it
– Which actors carry out which use cases?

• To model the requirements of a system (from the

events)
– Specify what that system should do (from a point of view of outside
the system), independent of how that system should do it
– Specify the desired behavior of the system
– Which use cases include other use cases?
7 7
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Elements of a Use Case Diagram

• Use Cases
– Sequences of actions, including variants, that the interacting system
can perform together with the system actors
Use Case
name
• Actor
– A coherent set of roles played by a user when interacting with the
system

• System boundary Actor name

– The limit between the physical system and the actors that interact
with it

8 8
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Use Case

• A Use Case
– A technique for capturing the functional requirements of a system
– Represent an external view of the system
• A Use Case does not describe
– User interfaces, performance goals, non-functional requirements

9 9
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Use Cases

Common information that can be added to a use case

• A pre-condition
– Describes what the system should ensure is true before the system
allows the use case to begin
– Useful for telling the programmers what conditions they don't have to
check for in their code
• A guarantee
– Describes what the system will ensure at the end of the use case
– Success guarantees hold after a successful scenario; minimal
guarantees hold after any scenario
• A trigger
– Specifies the event that gets the use case started

10 10
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Actors

• An actor
– Represents a coherent set of roles that users of Use Cases play
when interacting with the Use Cases
– Is anyone or anything that interacts with the system causing it to
respond to events
• Typically, an actor represents a role that a human, a hardware
device, or even another system plays with a system
• They live outside the system
• It is also possible to relate actors using
generalizations
• Actors are rendered as stick figures

11 11
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Identifying Participants

• What users or groups use the system to perform a task?

• What users or groups are needed so that the system can perform its
functions?
• What external systems use the system to perform a task?
• What external systems, users, or groups send information to the
system?
• What external systems, users, or groups receive information from
the system?

12 12
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Actors

• Initiator versus participant

– When there is more than one actor in a Use Case, the one that
generates the stimulus is called the initiator and the others are
participants

• Primary versus secondary

– The actor that directly interacts with the system is called the
primary actor, others are called secondary actors

13 13
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Use Cases and Actors
• Actors may be connected to Use Cases only by association
– An association between an actor and a Use Case indicates that the
actor and the Use Case communicate with one another, each one
possibly sending and receiving messages

14 14
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Example for High Level Use Case
Use Case Buy items
Actors Customer, Cashier
Description A Customer arrives at a checkout
with Items to purchase. The
Cashier records the purchase
items and collects payment. On
completion, the Customer leaves
with the items

15 15
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Include and Extend Stereotypes

• Include: rendered using the “include” stereotype

– The behavior of a Use Case includes that of a base Use Case
– The included Use Case never stands alone
– Only instantiated as part of some larger base that includes it

• Extend: rendered using the “extend” stereotype

– The behavior of a Use Case extends that of a base Use Case
– The base Use Case may stand alone
– Under certain conditions, its behavior may be extended by the
behavior of another Use Case

16 16
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Include and Extend

17 17
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Include and Extend Stereotypes

18 18
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Summary
• The building blocks of UML used in Use Case diagram
are:
– Elements
– Actor : Any external entity, including
– Hardware like scanner
– Servers and Clients
– Human users
– Use Case
– Functionality

19
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
 Summary
– Relationships
– Dependency
– Between Use Cases
– Includes
– Extends
– Association
– Between Actor and Use Case
– Generalization
– Between Actors

20
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences