MIRPUR UNIVERSITY OF SCIENCE AND TECHNOLOGY
DEPARTMENT OF SOFTWARE ENGINEERING
Software Design & Architecture
(Lecture # 6)
UML Use Case Modeling
Saba Zafar
(Lecturer)
Date: April 28, 2020
LECTURE CONTENTS
1. Notation used in Use Case Diagram
2. Extend Relation in Use Case Diagram
3. Include Relation in Use Case Diagram
4. Use Case Documentation
Software Design & Architecture 3
USE CASE DIAGRAM : NOTATIONS USED
• System boundary
• Actors
• Use-cases
• Flow of information / stimulus
Software Design & Architecture 4
ACTORS
• An actor is an external agent that interacts with the system
• An actor stimulates the system with input events, or receives something from it
<actor’s name>
Software Design & Architecture 5
USE CASE
• Describes a process from the user’s point of view expressed in the user’s language
• A collection of interactions between the system and actors
• A Use Case is an end-to-end process description that includes many steps or
transactions
Maintain Orders
Software Design & Architecture 6
EXAMPLE: POS
Software Design & Architecture 7
HOW TO PROCEED?
• Choose the system boundary
• Identify primary actors
• Those that have user goals fulfilled through using services of the system
• For each actor, identify their user goals
• Define use cases that satisfy user goals; name them according to their
goal
Software Design & Architecture 8
EXAMPLE: VIDEO STORE
Software Design & Architecture 9
TERMS AND CONCEPTS
• Actor:
• Something with behavior, such as a person, computer system, or organization,
e.g. a cashier.
• Scenario:
• Specific sequence of actions and interactions between actors and the system
under discussion, e.g. the scenario of successfully purchasing items with cash.
• Use case:
• A collection of related success and failure scenarios that describe actors using
a system to support a goal
Software Design & Architecture 10
EXTEND RELATIONSHIP OF USE CASES
• 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».
• If an alternative course is itself a stand-alone use
case, you can extend the normal course by inserting
that separate use case into the normal flow
• The "Search Vendor Catalogs" use case extends the
"Request a Chemical" use case
• In addition, the chemical stockroom staff use the stand-alone
"Search Vendor Catalogs" use case by itself
Software Design & Architecture 11
EXTEND RELATIONSHIP OF USE-CASES
Software Design & Architecture 12
INCLUDE RELATIONSHIP OF USE-CASES
• The include relationship could be used:
a. To simplify large use case by splitting it into several use cases
b. To extract common parts of the behaviors of two or more use cases
• Sometimes several use cases share a common set of steps
• To avoid duplicating these steps in each such use case:
• Define a separate use case that contains the shared functionality
• Indicate that the other use cases include that sub use case
Software Design & Architecture 13
INCLUDE RELATIONSHIP OF USE-CASES
Software Design & Architecture 14
INCLUDE RELATIONSHIP OF USE-CASES
Software Design & Architecture 15
USE-CASE DOCUMENT
A narrative document that describes:
• The sequence of system events
• The system responses originating from the initiating
actors of the system
Software Design & Architecture 16
TYPES AND FORMATS
Uses cases may be written in three formality types
Brief:
One-paragraph summary, usually of the main success
scenario.
Casual:
Informal paragraph format
Fully dressed:
Elaborate. All steps and variations are written in detail.
Software Design & Architecture 17
SCENARIOS
• Main success scenario:
• The normal flow of processing
• E.g., A customer arrives at a checkout with items to return. The cashier uses
the POS system to record each returned item…
• Alternate scenarios:
• If normal flow deviates, then the alternate course of action
• If the credit authorization is reject, inform customer and ask for an alternative
payment method e.g. cash.
• If item identifier not found in the system, notify the Cashier and suggest manual entry
of the identifier code.
Software Design & Architecture 18
FULLY DRESSED USE-CASE (PROCESS SALE)
• Use case UC1: Process Sale
• Primary Actor: Cashier
• Stakeholders and Interests:
• -Cashier: Wants accurate and fast entry, no payment errors, …
• -Salesperson: Wants sales commissions updated.
• Preconditions: Cashier is identified and authenticated.
• Success Guarantee (Postconditions):
• -Sale is saved. Tax correctly calculated.
• Main success scenario (or basic flow): [on next slide]
• Extensions (or alternative flows): [on next slide]
Software Design & Architecture 19
FULLY DRESSED USE-CASE (PROCESS SALE)
• Special requirements: Touch screen UI, …
• Technology and Data Variations List:
• -Identifier entered by bar code scanner,…
• Open issues: What are the tax law variations? …
Software Design & Architecture 20
UCI:PROCESS SALE
• Main success scenario (or basic flow):
• The Customer arrives at a POS checkout with items to purchase.
• The cashier records the identifier for each item. If there is more than one
of the same item, the Cashier can enter the quantity as well.
• The system determines the item price and adds the item information to the
running sales transaction. The description and the price of the current
item are presented.
• On completion of item entry, the Cashier indicates to the POS system that
item entry is complete.
• The System calculates and presents the sale total.
• The Cashier tells the customer the total.
• The Customer gives a cash payment (“cash tendered”) possibly greater
than the sale total.
• Extensions (or alternative flows):
• If invalid identifier entered. Indicate error.
• If customer didn’t have enough cash, cancel sales transaction.
Software Design & Architecture 21
REFERENCES
• Software Engineering: A Practitioner’s Approach, Roger S. Pressman,
Bruce R. Maxim, 8th Ed, McGraw-Hill Education, 2015.
• Object-Oriented Analysis, Design and Implementation, Brahma
Dathan, Sarnath Ramnath, 2nd Ed, Universities Press, 2014
Software Design & Architecture 22
THANKS
