The document discusses use case modeling and diagrams. It provides examples of use cases, actors, and relationships between them. Some key points: - A use case represents a goal of an actor and the interactions needed to achieve that goal. Actors can be people or other systems. - Use case diagrams show use cases, actors, and their relationships to understand system requirements and functionality. - Common relationships include generalization, extension, and inclusion to model optional/exceptional behavior or reuse of common interactions. - Well-defined use cases with descriptions help validate requirements, guide testing, and communicate with stakeholders.

1. Use Case Modeling and Use
Case Diagrams
OOSE
Lecture No 8

2. Goals and Stories
• Customers and Users have goals, objectives known as
REQUIREMENTS or NEEDS
• Variety of users and needs
• User oriented requirement gathering for validation
• Use case diagrams provide mechanism for better gathering and
understanding requirements
• Use Cases - Easy understanding for stakeholders
• Use Case – Stories about system goals

3. Goals and Interactions
• There is a place for both goals and interactions
• Understand what the system shall do
• Capture the user goals
• Understand how the user will achieve the goals
• Capture user interactions
• Sequences of user interactions
• Thus, start with the user goals and then refine the user goals
into several (many) user interactions

4. User Goals versus User Interactions
• Consider the following when formatting a document
• Define a style
• Change a style
• Copy a style from one document to the next
• versus
• Format a document
• Ensure consistent formatting of two documents
• The latter is a user goal
• Something the user wants to achieve
• The former are user interactions
• Things the user does to the system to achieve the goal

5. USE CASE MODELLING
• A use case is a scenario that describes the
use of a system by an actor to accomplish a
specific goal.
• An actor is a user playing a role with respect
to the system.
- people, other systems.
• Scenario
A sequence of steps that describe the
interactions between an actor and the system.
• The use case model consists of the collection
of all actors and all use cases.

6. USE CASE MODELLING
-functional reqts., analysis phase
- what a system does: functions represented as use cases
- Actor: external agent that interacts with the system, exchanges info. with
the system (user, sub-system, etc.)
- a role played by user
Note: a use case represents a complete functionality.
• view of system behavior from an external person’s viewpoint
• effective tool for validating requirements
• an effective communication tool
• basis for a test plan
• basis for user manual
Developing the use cases in not difficult; ensuring that you have them all
is murder.

7. Goals of use cases
• Interactions that provide value to actors
• No implementation specific language
• No assumptions about how the use case may be realized in code or
user-interface
• Note: use-cases drive the whole life-cycle, and they get refined –
implementation specific use-cases
• User-appropriate level of detail
• General at requirements gathering stage
• User-appropriate volume
• Large systems: no more than 70-80 use cases
• Small number of use cases – forces abstraction

8. Use cases help ..
· Capture the system's functional requirements
from the users' perspective
· Actively involve users in the requirements-
gathering process
· Provide the basis for identifying major classes
and their relationships
· Serve as the foundation for developing system
test cases

9. Scenario
• Specific sequence of actions and interactions between actors and
system under consideration
• Also called INSTANCE OF USE CASE
• Describes one particular story or path from the use case
• Scenario can be successful one or failing one
• Example 1: login success, login failure
• Example 2: data saved successfully, missing information

10. Use Case and Scenario
• Use case is collection of related success and failure scenarios of actors
for achievement of goals
• Main Success Scenario
• Alternate Scenario

11. Main Success and Alternate Scenarios

12. Use case scenarios
• a realization of a use case.
• Instance of an use case that effectively tests one path through a use case
• To demonstrate whether a use case accurately reflects user needs
• useful during testing
Example:
Use case name: Determine benefits eligibility for enrollee
Steps:
1. This use case starts when the social worker enters the enrollee’s name and
employment situation.
2. This use case ends when the system responds with a determination of whether the
enrollee is eligible for benefits and the financial extent of benefits.
Alternative path:
In step 1, if the enrollee has applied for benefits previously, based on the enrollee’s
own disclosure, the social worker enters the enrollee’s name to search for his or her
previous records

13. Use case scenario - example
Example of scenario
1. The social worker asks Edward Trueman if he has applied previously for and/or received
benefits. And Mr. Trueman replies that he has applied previously.
2. The social worker provides Mr. Trueman’s name as search criterion
3. The system provides Mr. Trueman’s previous records, which state that he applied for benefits on
Dec 9th, 1997, and was determined to be ineligible on Dec 9th 1997 because of his current part-
time employment status at Boeing Aerospace in the capacity of assembly line worker.

14. Use Case Diagrams
• Use case diagrams are used to visualize, specify, construct, and
document the (intended) behavior of the system, during
requirements capture and analysis.
• Provide a way for developers, domain experts and end-users to
Communicate.
• Serve as basis for testing.
• Use case diagrams contain use cases, actors, and their relationships.

19. Use Case
• Use cases specify desired behavior.
• A use case is a description of a set of sequences of actions, including
variants, a system performs to yield an observable result of value to
an actor.
• Each sequence represent an interaction of actors with the system.
name

21. Actors
• An actor represents a set of roles that users of use case play when
interacting with these use cases.
• Actors can be human or automated systems.
• Actors are entities which require help from the system to perform
their task or are needed to execute the system’s functions.
• Actors are not part of the system.
name

22. Use Cases and Actors
• From the perspective of a given actor, a use case does something that
is of value to the actor, such as calculate a result or change the state
of an object.
• The Actors define the environments in which the system lives

24. Example of Use Case Diagram
student
registration
updating
grades
output
generating
faculty

25. Use-Case Diagrams (POST)
CustomerCashier
Buy Item
Log In
Refund a Purchased Item
POST
Use Case
System Boundary
Adapted from Larman “Applying UML and Patterns”
POST: Point of Sale Terminal

26. Use Case Diagram Another Example

27. Use Case Relationships
• Generalization
• Extends relationship
• Include relationship

28. 1. Generalization
• 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.
parent
child

29. registration
graduate
registration
non-graduate
registration
More about Generalization

31. Extend
• 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.
base extending<<extend>>

32. More about Extend
• Enables to model optional behavior or branching under conditions.
Exam copy
request
Exam-grade
appeal
<<extend>>

34. Include
• The base use case explicitly incorporates the behavior of another use
case at a location specified in the base.
• The included use case never stands alone. It only occurs as a part of
some larger base that includes it.
base included
<<include>>

35. More about Include
• Enables to avoid describing the same flow of events several times by
putting the common behavior in a use case of its own.
updating
grades
output
generating
verifying
student id
<<include>>
<<include>>

36. Includes and Extends
• Includes
• You have a piece of behavior that
is similar across many use cases
• Break this out as a separate use-
case and let the other ones
“include” it
• Examples include
• Valuation
• Validate user interaction
• Sanity check on sensor inputs
• Check for proper authorization
• Extends
• A use-case is similar to another one
but does a little bit more
• Put the normal behavior in one use-
case and the exceptional behavior
somewhere else
• Capture the normal behavior
• Try to figure out what can go wrong
in each step
• Capture the exceptional cases in
separate use-cases
• Makes it a lot easier to understand

37. Relationships between Actors
• Generalization.
student
non-graduate
student
graduate
student

38. Relationships between Use Cases
and Actors
• Actors may be connected to use cases by associations, indicating that
the actor and the use case communicate with one another using
messages.
updating
grades
faculty

39. Example
place
phone call
cellular
network
user
receive
phone call
place
conference
call
receive
additional
call
use
scheduler
<<extend>>
<<extend>>
Cellular Telephone

40. A More Complicate Example

41. 05-Use-Cases
Partial POST
CustomerCashier
Buy Item
Log In
Refund a Purchased Item
POST
Start Up
Manage Users
And a Lot More
Manager
System Administrator
MH
Adapted from Larman “Applying UML and Patterns”

42. POST Use-Case
Use case: Buy Item
Actors: Customer (initiator), Cashier
Type: Primary
Description: The Customer arrives at the
checkout with items to purchase.
The Cashier records the purchase
items and collects a payment.
On completion the Customer
leaves with the items

43. POST Expanded Use-Case
Use case:Buy Item
Actors: Customer (initiator), Cashier
Type: Primary and essential
Description: The Customer arrives at the checkout with items
to purchase. The Cashier records the purchase
items and collects a payment. On completion the
Customer leaves with the items.
Use-Cases: Cashier must have completed the Log In use-case

44. Home Heating Use-Case Diagram
Home Owner
MH
Power Up
Power Down
Change Temp.
Home Heating

45. Home Heating Use-Cases
Use case: Power Up
Actors: Home Owner (initiator)
Type: Primary and essential
Description: The Home Owner turns the power on. Each room
is temperature checked. If a room is below the
the desired temperature the valve for the room is
opened, the water pump started. If the water temp falls
below threshold, the fuel valve is
opened, and the burner ignited.
If the temperature in all rooms is above the desired
temperature, no actions are taken.
Use-Cases: None

46. Modified Home Heating
Home Owner
MH
Power Up
Power Down
Change Temp.
Home Heating
Adjust Temp
Temp. High
Temp. Low
«includes»
«includes»
«includes»
«includes»

47. Modified:
Home Heating Use-Cases
Use case: Power Up
Actors: Home Owner (initiator)
Type: Primary and essential
Description: The Home Owner turns the power on.
Perform Adjust Temp. If the temperature
in all rooms is
above the desired temperature, no actions are taken.
Use-Cases: Perform Adjust Temp
*

48. Modified:
Home Heating Use-Cases
Use case: Adjust Temp
Actors: System (initiator)
Type: Secondary and essential
Description: Check the temperature in each room. For each room:
Below target: Perform Temp Low
Above target: Perform Temp High
Use-Cases: Temp Low, Temp High
*

49. Modified:
Home Heating Use-Cases
Use case: Temp Low
Actors: System (initiator)
Type: Secondary and essential
Description: Open room valve, start pump if not started.
If water temp falls below threshold,
open fuel value and ignite burner.
Use-Cases: None
*

50. HACS
• Homework assignment and collection are an integral part of any educational system. Today, this task is
performed manually. What we want the homework assignment distribution and collection system (HACS for
short) to do is to automate this process.
• HACS will be used by the instructor to distribute the homework assignments, review the students’ solutions,
distribute suggested solution, and distribute student grades on each assignment.
• HACS shall also help the students by automatically distributing the assignments to the students, provide a
facility where the students can submit their solutions, remind the students when an assignment is almost
due, remind the students when an assignment is overdue.

51. HACS Use-Case Diagram
Instructor
Student
System Admin
MH
Configure HACS
Distribute Asignments
Post Solutions
Distribute Grade
Remind Student
Submit Assignment
Get Solution
Get Grade
Get Assignment
HACS

52. HACS Use-Cases
Use case: Distribute Assignments
Actors: Instructor (initiator)
Type: Primary and essential
Description: The Instructor completes an assignment and submits
it to the system. The instructor will also submit the
due date and the class the assignment is assigned for.
Use-Cases: Configure HACS must be done before any user
(Instructor or Student) can use HACS

53. Alternate HACS
Instructor
Student
System Admin
MH
Configure HACS
Distribute Asignments
Post Solutions
Distribute Grade
Remind Student
Submit Assignment
HACS

54. Alternate HACS Use-Cases
Use case:Distribute Assignments
Actors: Instructor (initiator), Student
Type: Primary and essential
Description: The Instructor completes an assignment and submits
it to the system. The instructor will also submit the
delivery date, due date, and the class the assignment
is assigned for. The system will at the due date mail
the assignment to the student.
Use-Cases: Configure HACS must be done before any user
(Instructor or Student) can use HACS

55. Each use case may include all or part of the following:
 Title or Reference Name - meaningful name of the UC
 Author/Date - the author and creation date
 Modification/Date - last modification and its date
 Purpose - specifies the goal to be achieved
 Overview - short description of the processes
 Cross References - requirements references
 Actors - agents participating
 Pre Conditions - must be true to allow execution
 Post Conditions - will be set when completes normally
 Normal flow of events - regular flow of activities
 Alternative flow of events - other flow of activities
 Exceptional flow of events - unusual situations
 Implementation issues - foreseen implementation problems
Use Case Description

56. Example- Money Withdraw
• Use Case: Withdraw Money
• Author: ZB
• Date: 1-OCT-2004
• Purpose: To withdraw some cash from user’s bank account
• Overview: The use case starts when the customer inserts his credit card into the system. The
system requests the user PIN. The system validates the PIN. If the validation succeeded, the
customer can choose the withdraw operation else alternative 1 – validation failure is executed.
The customer enters the amount of cash to withdraw. The system checks the amount of cash in
the user account, its credit limit. If the withdraw amount in the range between the current
amount + credit limit the system dispense the cash and prints a withdraw receipt, else alternative
2 – amount exceeded is executed.
• Cross References: R1.1, R1.2, R7

57. Example- Money Withdraw (cont.)
• Actors: Customer
• Pre Condition:
• The ATM must be in a state ready to accept transactions
• The ATM must have at least some cash on hand that it can dispense
• The ATM must have enough paper to print a receipt for at least one transaction
• Post Condition:
• The current amount of cash in the user account is the amount before the withdraw minus the
withdraw amount
• A receipt was printed on the withdraw amount
• The withdraw transaction was audit in the System log file

58. Example- Money Withdraw (cont.)
 Typical Course of events:
Actor Actions System Actions
1. Begins when a Customer arrives at ATM
2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status
5. Customer chooses “Withdraw” operation 4. System asks for an operation type
7. Customer enters the cash amount 6. System asks for the withdraw amount
8. System checks if withdraw amount is legal
9. System dispenses the cash
10. System deduces the withdraw amount from
account
11. System prints a receipt
13. Customer takes the cash and the receipt 12. System ejects the cash card

59. Example- Money Withdraw (cont.)
• Alternative flow of events:
• Step 3: Customer authorization failed. Display an error message, cancel the
transaction and eject the card.
• Step 8: Customer has insufficient funds in its account. Display an error
message, and go to step 6.
• Step 8: Customer exceeds its legal amount. Display an error message, and go
to step 6.
• Exceptional flow of events:
• Power failure in the process of the transaction before step 9, cancel the
transaction and eject the card

60. Example- Money Withdraw (cont.)
 One method to identify use cases is actor-based:
- Identify the actors related to a system or organization.
- For each actor, identify the processes they initiate or participate in.
 A second method to identify use cases is event-based:
- Identify the external events that a system must respond to.
- Relate the events to actors and use cases.
 The following questions may be used to help identify the use cases for a system:
- What are tasks of each actor ?
- Will any actor create, store, change, remove, or read information in the system ?
- What use cases will create, store, change, remove, or read this information ?
- Will any actor need to inform the system about sudden, external changes ?
- Does any actor need to be informed about certain occurrences in the system ?
- Can all functional requirements be performed by the use cases ?

61. Financial Trading System Example
Salesperson
Trader
Accounting System
Trading Manager
Set Limits
Update Accounts
Analyze Risk
Price Deal
Capture Deal
Limit Exceeded
Valuation
«includes»
«includes»
«extends»

62. UseCaseDiagramforStudentDatabase