Scribd
Upload
73 views23 pages

Mirpur University of Science and Technology: Department of Software Engineering

This document summarizes a lecture on UML use case modeling. It discusses use case diagrams and their key components like actors, use cases, and system boundaries. It describes how to identify actors and their goals to define relevant use cases. The relationships between use cases, including extend and include relationships, are explained. Guidelines for documenting use cases with scenarios and variations are provided. Examples throughout help illustrate the concepts discussed.

Uploaded by

ali
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
73 views23 pages

Mirpur University of Science and Technology: Department of Software Engineering

This document summarizes a lecture on UML use case modeling. It discusses use case diagrams and their key components like actors, use cases, and system boundaries. It describes how to identify actors and their goals to define relevant use cases. The relationships between use cases, including extend and include relationships, are explained. Guidelines for documenting use cases with scenarios and variations are provided. Examples throughout help illustrate the concepts discussed.

Uploaded by

ali
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 23

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy