The document outlines the importance and elements of use case diagrams in software development, emphasizing their role in capturing system requirements and validating architecture. It discusses the definitions of actors and use cases, relationships within use case diagrams, and provides examples along with notation summaries. Additionally, it includes a case study on designing an online shopping portal, detailing the user interaction workflow.

1. Lesson 02:
Use Case Diagrams
Eng Marwa Ali Eissa
Software Developer
Email:marwa84eissa@gmail.com
You can Also Find Me on Facebook

2. Outline
 Justify the need for a Use Case diagram
 Identify and describe the essential elements in a UML
Use Case diagram
 Identifying the Actors in a System.
 Identifying Use Cases in a System
 Create a Use Case Diagram that shows the Use
Cases in your system.
 Recognize and document use case dependencies
using UML notation for extends, includes, and
generalization

3. Use Case Diagram
 Built in early stages of development
 Purpose
 Specify the context of a system
 Capture the requirements of a system
 Identify external and internal factors influencing the system
 Validate a systems architecture
 Drive implementation and generate test cases
 Developed by analysts and domain experts

4. Use Case Diagram – Cont.
 A Use Case diagram is one of the UML diagrams that uses the Use
Case - Driven approach for modeling the dynamic aspects of
systems
 A Use Case Driven Approach to software development is an
approach where the focus of the requirements of a system is meeting
specific needs that Users of the System Under Development (SUD)
have. This approach helps ensure that Customers get the software
that they want.

5. What is a use case?
 A case of a use of the system/product
 Describes the system's actions from a the point of view of a user
 The specification of actions, including variant sequences and error
sequences that a system, subsystem, or class can perform by
interacting with outside actors.
 The specification of how a system interacts with external actors
 Specifies one aspect of the behavior of a system, without
specifying the structure of the system
 Is oriented toward satisfying a user's goal
 A complete set of use cases = system requirements

6. How do use case diagrams fit in?

7. Elements of Use Case Diagram
Actor
 Is a person , organization , or external system that plays a role in one or more
interactions with the system
 Actors Usually represented with a stick figure
 Actor triggers use case
 Actor has responsibility toward the system (inputs), and Actor have
expectations from the system (outputs).
Use Cases
 Are the sequence of action that can be provided as a measurable value
to an Actor. These Use Cases are represented using ovals that are
labeled with verbs that represent the system’s functions
 Each Actor must be linked to a use case, while some use cases may
not be linked to actors.

8. Elements of Use Case Diagram
Associations
Defines the relationship of an Actor with the Use Cases of the system ;
Represented by a solid line.
System Boundary Box
Indicates the scope of the system functions with a rectangle drawn around
the Use Cases. The Use Cases inside the rectangle represent the
functionality that you intend to implement. Place Actors outside the System’s
boundaries.
Use Case
Use Case
Packages
Is a mechanism that allows you to organize model elements
such as Use Cases into groups.

9. Identifying the Actors in a System
Actors
 Software systems are built to be used by people or machines.
Any person or machine that interacts with the System Under
Development is called an Actor. Actors are the users of a system.
An Actor may have one or more roles when using or interacting
with the system. In such cases, each role is considered to be a
separate Actor.
 An actor represents a role that a user can play, but NOT a
specific user

10. Types of Actors
 Human Actors
Are the people using the system who have a particular purpose or
task to accomplish.
 Machine Actors
Are the machines that interact with the computer.
 Primary Actors
Primary actors are those who use the system’s main functions,
deriving benefits from it directly. Typically, the Primary Actor initiates
functionality with a System.
 Primary actors are completely outside the system and drive the system
requirements
 Primary actors use the system to achieve an observable user goal

11. Types of Actors – cont.
 Secondary Actors
An Actor who is an incidental user of the system. Typically this
includes Actors who serve in maintenance roles.
Secondary actors play a supporting role to facilitate the primary
actors to achieve their goals.
 Secondary actors often appear to be more inside the system than outside
 Secondary actors are usually not derived directly from the statement of
requirements. Hence, the designer can have more freedom in specifying
the roles of these actors
 Usually found on the right of the system (primary on the left)

12. Use Case Diagram :Actors
Actors are treated like classes and thus can be generalized

13. Finding Actors [1]
 External objects that produce/consume data:
 Must serve as sources and destinations for data
 Must be external to the system

14. Finding Actors [2]
Ask the following questions:
 Who are the system’s primary users?
 Who requires system support for daily tasks?
 Who are the system’s secondary users?
 What hardware does the system handle?
 Which other (if any) systems interact with the system in question?
 Do any entities interacting with the system perform multiple roles
as actors?
 Which other entities (human or otherwise) might have an interest
in the system's output?

15. Identifying Use Cases in a System
 Use Case:
• A particular task that a system can do for Actors.
 Task:
• A function to be performed an objective. This is not an official
UML word. The official word is Use Case.
 Step:
• One of a series of actions that is a stage in a process.
 Sub-Task:
• A function that is to be performed as a sub-process of a
higher level task or another sub-task.
For example, when a user uses an ATM, the task might be withdrawing
money from the account. On the other hand, inserting the ATM card into the
ATM is not a task; it is a step or subtask along the way to accomplishing the
task

16. Example Use Case Diagram : Example #1

17. Example Use Case Diagram : Example #2

18. Relationships in use-case diagrams
 Association relationships
 Generalization relationships
One element (child) "is based on" another element (parent)
 Include relationships
One use case (base) includes the functionality of another (inclusion
case)
Supports re-use of functionality
 Extend relationships
One use case (extension) extends the behavior of another (base)

19. Generalization relationships
 A use case generalization shows that one use case is simply a special kind of
another.
 In UML modeling, a generalization relationship is a relationship in which one
model element (the child) is based on another model element (the parent).
Generalization relationships are used in class, component, deployment, and use-
case diagrams to indicate that the child receives all of the attributes, operations, and
relationships that are defined in the parent.
 The child use case inherits the behavior and meaning of the parent use case.
 The child may add to or override the behavior of its parent

20. Generalization relationships – Example #1
The following figure illustrates an e-commerce application for a Web site that sells a
variety of merchandise. The application has an InventoryItem class that is a parent
class (also called a superclass). This class contains the attributes, such as Price, and
operations, such as setPrice, that all pieces of merchandise use.
After defining the parent class, a child class (also called a subclass) is created for each
type of merchandise, such as books and DVDs. The book class uses the attributes and
operations in the inventory class and then adds attributes such as author and
operations such as setAuthor. A DVD class also uses the attributes and operations in
the inventory class, but it adds attributes such as manufacturer and operations such as
setManufacturer, which are different from those in the book class.

21. Generalization relationships – Example #2

22. Include relationships
In the process of developing a use case model, we may discover that some use
cases share common behaviors.
There are also situations where some use cases are very similar but they have
some additional behaviors.
For example, Withdraw Money and Deposit Money both require the user to log-
on to an ATM system

23. Include relationships – cont.

24. Include relationships – cont.
Include relationships are used when two or more use cases share
some common portion in a flow of events
This common portion is then grouped and extracted to form an
inclusion use case for sharing among two or more use cases
Most use cases in the ATM system example, such as Withdraw
Money, Deposit Money or Check Balance , share the inclusion use-
case Login Account

25. Include relationships – cont.
 In UML modeling, an include relationship is a relationship in which one
use case (the base use case) includes the functionality of another use case
(the inclusion use case). The include relationship supports the reuse of
functionality in a use-case model.
 You can add include relationships to your model to show the following
situations:
 The behavior of the inclusion use case is common to two or more use
cases.
 The result of the behavior that the inclusion use case specifies, not the
behavior itself, is important to the base use case.
a Use Case that is a subtask of
another Use Case
a Use Case that uses the
functionality of another Use
Case

26. Include relationships – Example #1
In an ATM, the process of Login can be thought of as a subtask of
many different Use Cases. It can be used when a person Withdraws
Money, Deposits Money or Checks Balance .You can draw this in a
Use Case diagram.

27. Include relationships – Example #2
In an ATM, the process of printing a receipt can be thought of as a
subtask of many different Use Cases. It can be used when a person
withdraws money or when he deposits money. It could also be used
when a bank customer wants to checks his balance. You can draw
this in a Use Case diagram.

28. Include relationships – Example #3
in a hotel reservation system, you might find that both the Cancel
Reservation use case and the CheckIn Reservation use case need to
perform the same steps to find a reservation.

29. Extend relationships
 In UML modeling, you can use an extend relationship to specify that
one use case (extension) extends the behavior of another use case
(base). The Extending Use Case adds to the existing functionality and
characteristics of the Base Use Case. This type of relationship reveals
details about a system or application that are typically hidden in a use
case.
 The extend relationship specifies that the incorporation of the
extension use case is dependent on what happens when the base use
case executes. The extension use case owns the extend relationship.
You can specify several extend relationships for a single base use case.
 While the base use case is defined independently and is meaningful by
itself, the extension use case is not meaningful on its own.

30. Extend relationships –cont.
 You can add extend relationships to a model to show the following situations:
 A part of a use case that is optional system behavior
 A subflow is executed only under certain conditions
 A set of behavior segments that may be inserted in a base use case
 The extension takes place at one or more extension points defined in
the extended use case.
 Extend relationship is shown as a dashed line with an open arrowhead
directed from the extending use case to the extended (base) use case. The
arrow is labeled with the keyword «extend».

31. Extend relationships – Example #1
Assume that a customer wants to withdraw money from an ATM. He
can withdraw the money from his savings account, credit card account,
or from another bank. Therefore, the task of withdrawing the money
can be extended with the tasks of withdrawing money from the savings
account, withdrawing money from the credit card account, and
withdrawing money from another bank.

32. Extension points
In UML models, an extension point identifies the point in the base
use case where the behavior of an extension use case can be
inserted. The extension point is specified for a base use case and is
referenced by an extend relationship between the base use case and
the extension use case.
A base use case can have several extension points. Each extension
point has a unique name that identifies one or several locations in the
behavior sequence of the base use case.
As the following figure illustrates, the name of the extension is listed
in the Extension Points compartment of the use case.

33. Conditions in an Extend Use Case
To show how one Use Case extends another Use Case, extension points are
added in the UML. In these extension points, the conditions from the UML
can also be specified that shows the actual logic necessary for one Use
Case to extend to another. They also show the exact extension point that is
used between the two Use Cases. These conditions are specified as a
note to the extend relationship
The extensions operate only under certain conditions

34. Extend relationships – Example #2
Registration use case is complete and meaningful on its own.
It could be extended with optional Get Help On Registration use case.
Registration use case is conditionally extended by Get Help On Registration
use case in extension point Registration Help.

35. Summary of Notations

36. Summary of Notations – Cont.

37. Use Case Relationships Compared
Generalization Extend Include
Base use case could be abstract use
case(incomplete) or concrete
(complete).
Base use case is complete (concrete)
by itself, defined independently.
Base use case is incomplete
(abstract use case).
Specialized use case is required, not
optional, if base use case is abstract.
Extending use case is optional,
supplementary.
Included use case required, not
optional.
No explicit location to use
specialization.
Has at least one explicit extension
location.
No explicit inclusion location but is
included at some location.
No explicit condition to use
specialization.
Could have optional extension
condition.
No explicit inclusion condition.

38. Case Study : Online Shopping Portal
 Case Statement
In this case, we will be designing a simple online shopping portal .The
site will provide a soothing shopping experience for customers. The
system will allow more than one categories and different brands under
the segment. The case will trace the following sequence.
 Scenario
A customer visits the online shopping portal. A customer may buy
item or just visit the page and logout. The customer can select a
segment, then a category, and brand to get the different products in
the desired brand

39. Example #2 : Online Shopping Portal – cont.
The customer can select the product for purchasing. The process can
be repeated for more items. Once the customer finishes selecting the
product/s the cart can be viewed , If the customer wants to edit the final
cart it can be done here.
For final payment the customer has to login the portal, if the customer
is visiting for the 1st time he must register with the site, else the
customer must use the login page to proceed
Final cart is submitted for payment and card details and address
(where shipment has to be made) are be confirmed by the
customer .Customer is confirmed with a shipment Id and delivery of
goods within 15 days.