Lab 2-Use Case Modeling

Lab 2:
Use-case Modeling
16-Nov-20 T.A GHADEER AL-HOMYANI 1

Objectives
- To introduce the use case modeling
- To present UML use case diagram notation
- To present rules for making use case diagrams.
- To present the behavior of a use case
16-Nov-20 T.A GHADEER ALHOMYANI 2

Introduction
- Use case modeling describes what a system does to
benefit users.
- A use case model is built through an iterative process
(discussion between the system’s developers and the
stakeholders), lead to a requirement specification on which
all agree.
- Use case modeling was created by Ivar Jacobson based on
OOSE and Objectory methods.

Basics of Use Case Model
-The primary components of a use-case model are use cases, actors, and the
system modeled, also called the subject.
- Each use case specifies a complete functional unit.
- A use case must always deliver some value to an actor, something the actor
wants.

The primary purposes for use cases
- To decide and describe the functional requirements of the system.
- To give a clear and consistent description of what the system should do.
- To provide a basis for performing system tests that verify that the system works
appropriately and validate it.
- To provide the ability to trace functional requirements into actual classes and
operations in the system.

Elements of Use Case Diagram:
1-System 2-Actor 3-Use case 4-Relationships
4.1 Between use 4.2 Between use 4.3 Between

cases and actors cases actors
Generalization Include Extend

Elements of Use Case Diagram:
1.System
- The boundaries of the system, or subject developed are
defined.
- The system can itself be a classifier, or subject, that owns
the set of use cases.
- Includes the name of the subject inside or on top
system

2.Actors
- An actor is someone or something that interacts with the system; it’s who or
what uses the system.
- Depicted as a stickman.
- An actor can be a human being or another system.

2.Actors (Cont.)
- The actor represents a role, not an individual user of the system.
◦ Example: John is a professor. So, the name of the actor should be professor not
John.
professor
- Actor triggers use case.

- Is placed outside the subject boundary/ system.

3.Use cases
- A use case represents functionality for an actor, named by a verb.
- A use case in UML is defined as “a set of actions performed by a system, which
yields an observable result for one or more actors”.
Do something

3.Use cases (Cont.)
- Each Actor must be linked to a use case, while some use cases may not be
linked to actors.
- Is placed inside the system boundary.
- Can extend another use case.
- Can include another use case.

4.1 Relationships between Use Cases and Actors
Association: Links an actor with the use case(s) with which it interacts.
updating
grades
faculty

Example 1:
Draw a use case diagram for a restaurant system that contains the following
functional requirements:
◦ The system will allow a customer and service person to order food.
◦ The system will allow a manager to:
◦ Hire employee
◦ Produce management reports

Example 1 (Cont.)
Restaurant System
Order Food
Customer Service Person

Hire Employee
Produce Management Manager

Reports

Example 2:
An online shopping portal allows their customers to register to
their portal. He can login to the system anytime to browse items
and add it to the shopping cart. He also can view his shopping
cart. The customer can edit the final cart then submit the final cart
for payment, or logout from the site without buying the items. The
site's administrator can add or update different items in the
system, manage the registration of new customer, and ensure the
authorization of already registered customers.
Draw the use case diagram for the online shopping system.

Example 2 (Cont.)
First, do the requirement analysis.
What a customer can do?
◦ Register
◦ Login
◦ Browse item
◦ Add to cart
◦ View cart
◦ Edit cart
◦ Make payment
◦ Logout
What an administrator can do?
◦ Add new item
◦ Update item
◦ Manage registration
◦ Authorize customers

Example 2 (Cont.)
Online shopping system

4.2 Relationships between Use Cases
1. Generalization - specifying how a child can specialize all behavior and
characteristics described for the parent.
2. Include - use cases that are included as parts of other use cases.
3. Extend - use cases that extend the behavior of other core use cases.

1.Generalization
- The child use case inherits the behavior and meaning of

the parent use case. parent
- The child may add to or override the behavior of

its parent. child

1.Generalization (Cont.)
registration
under-graduate post-graduate
registration registration

1.Generalization (Cont.)
21
} The actor, Order Registry Clerk can

instantiate the general use case, Place
Order. Place Order can also be
specialized by the use cases, Phone
Order or Internet Order.
T.A GHADEER ALHOMYANI
16-Nov-20
2. Include
base <<include>> included
When a number of use cases have common behavior, this behavior

can be modeled in a single use case that is included by the other
use cases.
The included use case never stands alone. It only occurs as a part
of some larger base that includes it.

2. Include (Cont.)
Enables to avoid describing the same flow of events several times
by putting the common behavior in a use case of its own.
If the use case you include has no use for other use cases, don’t
separate it out as a separate complete behavior.
updating
grades <<include>>
verifying
student id
output <<include>>
generating

2. Include (Cont.)
• Include relationship – a standard case linked to a
mandatory use case.
Authorize Car <<include>> Check Client’s
Loan Credit History
• Example: to Authorize Car Loan (standard use case),

a clerk must run Check Client’s Credit History (include use case).
• The standard UC includes the mandatory UC (use the verb

to figure direction arrow).
• Standard use case can NOT execute without the include
case à tight coupling .
3. Extend
base <<extend>> extending
The base use case implicitly incorporates the behavior of another

use case at certain points called extension points.
The base use case may stand alone, but under certain conditions
its behavior may be extended by the behavior of another use case.

3. Extend (Cont.)
Enables to model optional behavior or branching under

conditions.
<<extend>> Appeal
Request
exam copy exam-grade

3. Extend (Cont.)
• Extend relationship – linking an optional use case
to a standard use case.
<<extend>>
Register Register for
Course Special Class
• Example: Register Course (standard use case) may have

Register for Special Class (extend use case) – class for
non-standard students, in unusual time, with special
topics, requiring extra fees…).
• Standard use case can execute without the extend case
• The optional UC extends the standard UC

3. Extend (Cont.)
Cellular Telephone
place
place <<extend>>
conference
phone call
call
cellular
network receive
receive <<extend>>
additional
phone call
call
use
user scheduler

4.3 Relationships between Actors
Generalization:
◦ The specialized actors inherit the behavior of the superclass and then extend
that behavior in some way.
student
under- post-
graduate graduate
student student

Use case diagram rules
- At least one use case
- At least one actor
- At least one use case associated with each actor
- No association line between actors
- No association line between use cases
- Name every actor and use case
- Not label any association line

Example 2
Do the following operations on the use case diagram stated
bellow:

Example 2 (Cont.)
1) Update the use case diagram such that a new patient may
open a file. Also nurses help in making appointments and they
may view a schedule. Also, Management and doctors may
view the schedule. Add any other appropriate missing things.

Example 2 (Cont.)

Question 1
Suppose we want to develop software for an alarm clock. The clock shows the
time of day. Using buttons, the user can set the hours and minutes fields
individually, and choose between 12 and 24-hour display. When an alarm fires, it
will sound some noise. The user can turn it off, or choose to ’snooze’. If the user
does not respond at all, the alarm will turn off itself after 2 minutes. ’Snoozing’
means to turn off the sound, but the alarm will fire again after some minutes of
delay.
Draw the use case model of the system.

The answer

Specifying the Behavior of a Use Case
Describing the flow of events within the use case.

Can be done in natural language, formal language or pseudo-
code.
Includes: how and when the use case starts and ends; when
the use case interacts with actors and what objects are
exchanged; the basic flow and alternative flows of the
behavior.

Use Case Behavior Description
Types of use case behavior
description format
High level (HL) Expanded use

use case case
HL use case Expanded use case describes a

describes a process process in details. It has an
very briefly, usually additional section not present in
in 2 or 3 sentences. HL, Typical course of events

High level use case format
It has the following format:
◦ Use Case: Use case name

◦ Actors: List of actors (external agents), indicating who initiates
the use case
◦ Description (Success scenario): Narrative description of the
process

Example 1: Use case diagram
Library Information System
Borrow Resources
Librarian
Add Resources
Patron
Return Resources

Example 1 (Cont.)
Use Case: Add Resources.
Actors: Librarian.
Description: The use case begins when the Librarian receives new
resources (books and 17 videos) to add to the catalog. The title,
call number, and other information are recorded. Then the
resources are placed on a shelf organized by resource type and call
numbers.

Example 2: Use case diagram
POST
Buy Items
Cashier
Log In
Customer
Refund Purchased
Items

Example 2 (Cont.)
Use Case: Buy Items
Actors: Customer (initiator) , 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.

Expanded use case format
} Use Case: Name of use case
} Actors: List of actors (external agents), indicating who initiates the use
case
} Purpose: Intention of the use case
} Overview (Success scenario):
} Repetition of HL use case, or some similar summary
} Type:
} 1-primary, secondary or optional
} 2- essential or real
} Cross References: Related use cases and system functions.
} Typical course of actions: describes in detail the conservation of
interaction between the actors and the system.

Example 1: Expanded Use case Buy Items with
Cash
Use Case: Buy Items with Cash
Actor: Customer (initiator), cashier
Purpose: Capture a sale & its cash payment
Overview (Success scenario):
A customer arrives at a checkout with items to purchase. The
Cashier records the purchase items and collects a cash payment.
On completion, the Customer leaves with the items
Type: primary
Cross References: Functions R1.2,…

Typical Course of Events
Actor Action System Response
1. This use case begins when a

Customer arrives at the POST
checkout with items to purchase
2. The Cashier records the 3. Determines the item price and
identifier from each item adds the item information to the running
If there is more than one of sales transaction
the same item, the Cashier can
enter the quantity as well
4. On completion of item entry, 5. Calculate and presents the
the Cashier indicates to the sale total
POST that item entry is
complete
6. The Cashier tells the
Customer the total

7. The Customer gives a cash
payment possibly greater than
the sale total
8. The Cashier records the cash 9. Shows the balance due back to
received amount the Customer & generate a
receipt.
10. The Cashier deposits the cash 11. Logs the completed sale
received & extracts the balance owing
The Cashier gives the balance
owing, & the printed receipt to
the Customer
12. The Customer leaves with the
items purchased
Alternatives:
Line 2. Invalid identifier entered. Indicate errors
Line 7. Customer didn’t have enough cash. Cancel sales transaction

Example 2:
Write an expanded use case “ATM withdraw cash”; which details

the withdraw cash process from an ATM. Assume that:
◦ The user will choose only the transaction type withdraw
◦ The user account covers the required cash
◦ ATM is ready for this service

Example 2 (Cont.)
} Use Case: ATM withdraw cash
} Actor: user
} Purpose: To withdraw some cash from user’s bank account
} Overview (Success scenario):
} The use case starts when the user arrives at the ATM and enters
his/her identification. The system requests the user password.
The system validates the password. If the validation succeeded,
the user can choose the withdraw operation. On completion, the
user leaves with his/her cash and receipt.
} Type: primary

Example 2 (Cont.)
Typical course of event
Actor System response
1. This use case starts when the user arrives at the ATM and
enters his/her identification
2. Validate the user identification. If valid, request password
3. User enters his password

4. Verifies the authorizations. If authorized, asks for transaction type
5. User chooses withdraw transaction 6. Display the cash amounts choices
8. Asks for receipt

7. User enters the required amount
10. Verifies the requested amount with the account limit and daily
9. Chose to confirm the receipt operation limit. If receipt is requested, print the receipt
Example 2 (Cont.)
Alternative:
Line 2: If identification invalid, operation cancelled
Line 4: If password not authorized, error message is displayed and

give 2 more trials

Essential vs. Real Use Cases
Use Case Degree of Design Commitment
Essential Real
Very abstract Very concrete
Essential use cases are expanded use cases that are

expressed in an ideal form free of technology and
implementation details
Real use cases concretely describes the process in terms of

its real current design, committed to specific input and output
technology

Essential vs. Real Use Cases Buy Items
1. This Cashier records the 2. Determines the item price &
identifier for each item adds the item information to the
running sales transaction
Essential Use Case The description & price of the

item are presented

1. For each item, the Cashier 2. Display the item price & adds
types in the UPC field of the item information to the
Window1. They then press running sales transaction
“Enter Item” button with the The description & price of the
mouse or Enter key current item are displayed in
Real Use Case Textbox 2 of Window 1

Plan & Elaborate Phase Steps
- Define system function
- Define system boundary, actors & use cases
- HL use cases
- Draw use case diagram
- Expand critical use cases (essential / Analysis)
- Real use case (Design)

I. Begin with a Use Case!
A user placing an order with a sales company might
follow these steps :
1.Browse catalog and select items.
2. Call sales representative.
3. Supply shipping information.
4. Supply payment information.
5. Receive conformation number from salesperson.
II. Then translate Use Case sequence into Diagram


Lab 2-Use Case Modeling

Uploaded by

Document Information

Original Title

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

Lab 2-Use Case Modeling

Uploaded by

Copyright:

Available Formats

Lab 2:

16-Nov-20 T.A GHADEER AL-HOMYANI 1

16-Nov-20 T.A GHADEER ALHOMYANI 2

16-Nov-20 T.A GHADEER ALHOMYANI 3

16-Nov-20 T.A GHADEER ALHOMYANI 4

16-Nov-20 T.A GHADEER ALHOMYANI 5

1-System 2-Actor 3-Use case 4-Relationships

4.1 Between use 4.2 Between use 4.3 Between

Generalization Include Extend

16-Nov-20 T.A GHADEER ALHOMYANI 6

16-Nov-20 T.A GHADEER ALHOMYANI 7

16-Nov-20 T.A GHADEER ALHOMYANI 8

- Actor triggers use case.

16-Nov-20 T.A GHADEER ALHOMYANI 9

16-Nov-20 T.A GHADEER ALHOMYANI 10

16-Nov-20 T.A GHADEER ALHOMYANI 11

16-Nov-20 T.A GHADEER ALHOMYANI 12

16-Nov-20 T.A GHADEER ALHOMYANI 13

Customer Service Person

Produce Management Manager

16-Nov-20 T.A GHADEER ALHOMYANI 14

16-Nov-20 T.A GHADEER ALHOMYANI 15

16-Nov-20 T.A GHADEER ALHOMYANI 16

16-Nov-20 T.A GHADEER ALHOMYANI 17

16-Nov-20 T.A GHADEER ALHOMYANI 18

- The child use case inherits the behavior and meaning of

- The child may add to or override the behavior of

16-Nov-20 T.A GHADEER ALHOMYANI 19

16-Nov-20 T.A GHADEER ALHOMYANI 20

} The actor, Order Registry Clerk can

base <<include>> included

When a number of use cases have common behavior, this behavior

16-Nov-20 T.A GHADEER ALHOMYANI 22

16-Nov-20 T.A GHADEER ALHOMYANI 23

• Example: to Authorize Car Loan (standard use case),

• The standard UC includes the mandatory UC (use the verb

base <<extend>> extending

The base use case implicitly incorporates the behavior of another

16-Nov-20 T.A GHADEER ALHOMYANI 25

Enables to model optional behavior or branching under

16-Nov-20 T.A GHADEER ALHOMYANI 26

• Example: Register Course (standard use case) may have

16-Nov-20 T.A GHADEER ALHOMYANI 27

16-Nov-20 T.A GHADEER ALHOMYANI 28

16-Nov-20 T.A GHADEER ALHOMYANI 29

16-Nov-20 T.A GHADEER ALHOMYANI 30

16-Nov-20 T.A GHADEER ALHOMYANI 31

16-Nov-20 T.A GHADEER ALHOMYANI 32

16-Nov-20 T.A GHADEER ALHOMYANI 33

16-Nov-20 T.A GHADEER ALHOMYANI 34

16-Nov-20 T.A GHADEER ALHOMYANI 35

Describing the flow of events within the use case.

16-Nov-20 T.A GHADEER ALHOMYANI 36

High level (HL) Expanded use

HL use case Expanded use case describes a

16-Nov-20 T.A GHADEER ALHOMYANI 37

It has the following format:

◦ Use Case: Use case name

16-Nov-20 T.A GHADEER ALHOMYANI 38

Library Information System

16-Nov-20 T.A GHADEER ALHOMYANI 39

16-Nov-20 T.A GHADEER ALHOMYANI 40

16-Nov-20 T.A GHADEER ALHOMYANI 41