0% found this document useful (0 votes)
47 views

SE331: Software Design & Architecture: Lecture # 2 Use Case Modeling

The document discusses use case modeling and provides examples. It defines what a use case is and different types of actors. It also covers use case diagrams, relationships between use cases like include and extend relationships, and provides an example use case model for a library information system.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
47 views

SE331: Software Design & Architecture: Lecture # 2 Use Case Modeling

The document discusses use case modeling and provides examples. It defines what a use case is and different types of actors. It also covers use case diagrams, relationships between use cases like include and extend relationships, and provides an example use case model for a library information system.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 40

SE331: Software Design &

Architecture

Lecture # 2
Use Case Modeling
Outline
 What is a Use Case?
 What is Use Case Actor?
 Type of Actors
 Primary Actor
 Supporting Actor
 Off-Stage Actor
 Guidelines to find use cases
 Relationships in use cases
 Include Relationship
 Extend Relationships
 Generalization Relationships
 Example Case Study
2
Outline
 Case Study
 Activity: find use cases, Actors and System boundary
 Tool Description
 Enterprise Architecture (EA)
 Installation
 Creating New Project
 Drawing Use Case Diagram from Case study
 Assignment Task
 Make a group of two and propose a project
 Describe the project in at least 500 words
 There must be at least 5 use cases in the project
 These must be at least 3 actors of the system
 Use EA to draw use case diagram
 Prepare a PDF document where you place: Actors and their
responsibilities, Use Case Diagram and justification of each use case
3
What is a Use Case?

 They are stories or scenarios of how people


use the system
 Use Cases describes sequence of action and
interaction between user and the system

4
What is Use Case Diagram?

 A graphical representation of use case, such


that
 It describe the use case
 It describe the actor and use case relation
 It describes the boundary of the system

5
Actor
 Actors
 Something with behavior such as person, computer system, or

organization

6
Kinds of Actors

 Primary actor
 has user goals fulfilled through using services of the SuD
 why identify? To find user goals, which drive use cases
 Supporting actor
 provides a service (for example, information) to the SuD
 why identify? To clarify external interfaces and protocols
 Offstage actor
 has an interest in the behavior of the use case
 why identify? To ensure that all necessary interests are
identified and satisfied

7
Kind of Actors

For a use case context Show computer system actors


diagram, limit the use cases to with an alternate notation to
user-goal level use cases. human actors.

NextGen

«actor»
Process Sale Payment
Authorization
Service
Cashier
...

primary actors on supporting actors


the left on the right
8
Use Case Diagram
system boundary NextGen POS communication

Process Sale alternate


notation for
Customer a computer
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier

«actor»
Cash In Accounting
System
Manager
«actor»
«actor» Analyze Activity
HR System
Sales Activity
System

Manage Security

System Manage Users


Administrator use case
...
9
Common Use Case Issues
 What Tests Can Help Find Useful Use Cases?
 The Boss Test
 The EBP (Elementary Business Process) Test: A task
performed by 1 user in 1 place at 1 time in response to a
business event, that adds measurable value to the business
and leaves data in a consistent state.
 The Size Test
 Writing Style
 Essential (keep the UI out)
 Concrete (UI decisions embedded in the UC text)
 Guideline: Write use cases in an essential style; keep the user
interface out and focus on actor intent

10
Library Information System
(Problem Statement)
 A computerized library system for a university keeps track of
all books and periodicals in the library and their check-out
status
 Checkout and return are automated through a bar code
reader (an external device)
 The library system also interfaces with an external relational
database which stores information about the library users
(students, faculty, and staff), including whether they have any
library items checked out
 Library users can access the catalog and recall books and
periodicals
 Library employees have the same access as well as
additional capabilities (e.g., listing the status of an item) 11
Library Information System
(Use Case Diagram)

Login

CheckIn
LibEmployee
BarCodeReader
CheckOut

LibUser CheckAvailability
UsersDB

Recall
Note: the library catalog is part of the library computer system so it is not shown
as an actor 12
Library Information System
(Use Case Text: Login)
1. Employee initiates use case by entering user
name and password
2. If user name and password is valid, employee is
logged on and now has access to employee
commands

 Starting and ending conditions?


 Extensions? e.g., cannot find the employee
login

13
Library Information System
(Use Case Text: CheckAvailability)
 User/Employee initiates use case by selecting the check
book availability option
 System prompts for choice of search by title, author, or
call number
 User makes selection and enters title, author or call
number
 System performs search through the library catalog
database
 If a match is found, system displays item status (not
checked out, checked out and due date, overdue)

 Starting and ending conditions?


 Extensions?
14
Use Case Associations
 Use case association = relationship between
use cases
 Important types:
 Include
 A use case uses another use case (functional
decomposition and reuse of existing functionality)
 Extends
 A use case extends another use case
 Generalization
 A use case has different specializations
≪include≫: Functional Decomposition

 Problem:
 A function in the original problem statement is too complex to be
solvable immediately
 Solution:
 Describe the function as the aggregation of a set of simpler
functions. The associated use case is decomposed into smaller
use cases
CreateDocument

≪include≫
≪include≫
≪include≫

Scan OCR Check


≪include≫: Reuse of Existing Functionality
 Problem:
 There are already existing functions. How can we reuse them?

 Solution:
 The include association from Use Case A to Use Case B

indicates that an instance of A performs all the behavior


described in B (“A delegates to B”)
 Example:
 The use case “ViewMap” describes behavior that can be used by

the use case “OpenIncident” (“ViewMap” is factored out)


 Note: The base use case cannot exist alone. It is always called with
the supplier use case

≪include≫

OpenIncident
ViewMap
Base Use ≪include≫
Case Supplier
AllocateResources Use Case
When to Use Include Relationship?

 Use include when you are repeating yourself in


two or more separate use cases and you want to
avoid repetition.

 A use case is very complex and long, and


separating it into subunits aids comprehension.
≪extend≫ Association for Use Cases
 Problem:
 The functionality in the original problem statement needs to be

extended.
 Solution:
 An extend association from Use Case B to Use Case A indicates

that B is an extension of A.
 Example:
 The use case “ReportEmergency” is complete by itself , but can

be extended by the use case “Help” for a specific scenario in


which the user requires help
 Note: In an extend association, the base use case can be executed
without the use case extension
Base Use
Case B
Help
FieldOfficer
A ≪extend≫

ReportEmergency
Generalization Association in Use Cases
 Problem
 You have common behavior among use cases and want to factor
this out.
 Solution
 The generalization association among use cases factors out
common behavior. The child use cases inherit the behavior and
meaning of the parent use case and add or override some
behavior.
 Example
 Consider the use case “ValidateUser”, responsible for verifying
the identity of the user. The customer might require two
realizations: “CheckPassword” and “CheckFingerprint”

CheckPassword

Parent ValidateUser
Child
Case
CheckFingerprint Use Case
Use-Case Experts advise to Keep Things Simple
and Prefer the include Relationship
NextGen POS

Process Sale

Cashier
«include» «include» «actor»
Accounting
«include» System

Handle Check Handle Cash Handle Credit


Payment Payment Payment
Customer «actor»
«include» Credit
«include» «include» Authorization
Service
UML notation:
the base use
Process Rental
case points to
the included use
case

Handle Returns

Manage Users

...
21
Case Study

 Read the case study from attached document


and identify
 Use Cases
 Primary Actors
 Supporting Actors
 System Boundary
Walkthrough Task

 From use cases and actors identified from


the case study, the EA tool shall be used to
draw use cases.
Walkthrough task

 Open EA tool on your local machine


Walkthrough task

 Click on the file and choose new project


Walkthrough task

 Name your project as Point of Sale System


and press save button
Walkthrough task

 Close the wizard


windlw

27
Walkthrough task

 Click on the new Package option

28
Walkthrough task

 Write down package name as Point of Sale


UC and choose Package only
 Press ok

29
Walkthrough task

 Choose Add
Diagram option

30
Walkthrough task

 Choose use case from UML behavioral


Diagrams

31
Walkthrough task

 The Final window appears as following


 Drag and drop use case icon to the white
space

32
Walkthrough task

 Double click on use case icon to update the


name of use case

33
Walkthrough task

 The use case appears as following

34
Walkthrough task

 Now drag and drop actor icon

 Double click on actor1 to update the name


 Stretch the arrow from the actor to use case
and make association relation

35
Walkthrough task

 Create association relation between actor


and use case

36
Walkthrough task

 Drag and drop the boundary icon and name it


as Point of Sale

37
Walkthrough task

 The system boundary appears as following

 Repeat steps to add other use cases

38
Lab Tasks

 Repeat the steps to add other actors,


supporting actors in use case model

 Make use of include, extend and


generalization operation

39
Unseen task

40

You might also like