1. IS223D: OBJECT-ORIENTED DESIGN
Information Systems Department
Lecture 2: Use-case Modeling

2. Objectives To explain what use cases are
To present UML use case diagram notation
To present rules for making use case diagrams.
To present the behavior of a use case
Information Systems Department

3. Introduction
Use-case modeling describes what a system does to benefit users.
A use-case model is built through an iterative process, lead to a requirement specification on which all agree.
Information Systems Department

4. Basics of Use Cases
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.
Information Systems Department

5. Cont.
How the use cases are implemented, and how they work internally is not important.
Use-case modeling is used not only to capture requirements of new systems; it is also used when new generations of systems are developed.
Information Systems Department

6. Cont. The people who have an interest in the use-case models:
Stakeholders
Developers
Integration and system test teams
Information Systems Department

7. 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.
Information Systems Department

8. Elements of Use Case Diagram:
2-Actor
3-Use case
4-Relationships
4.1 Between use cases and actors
Generalization
Include
Extend
4.2 Between use cases
4.3 Between actors
1-System
Information Systems Department

9. 1.System
The boundaries of the system, or subject developed are defined.
Defining the boundaries of the system is not easy
It’s not always obvious which tasks are best automated and which are best handled manually or by other systems.
How large the system should be in its first generation.
Information Systems Department

10. Cont.
Identify the basic functionality and concentrate on defining a stable and well-defined system architecture to which more functionality can be added in future generations.
system
Information Systems Department

11. 2.Actors
An actor is someone or something that interacts with the system; it’s who or what uses the system.
An actor can be a human being or another system.
The actor represents a role, not an individual user of the system.
(example: a professor can be an instructor and a researcher – plays 2 roles in the system).
Actor triggers use case.
name
Information Systems Department

12. Cont.
Actor has responsibility toward the system (inputs), and actor has expectations from the system (outputs).
Actors can be
An active actor: is one that initiates a use case
A passive actor: never initiates a use case, but only participates in one or more use cases.
An actor has a name (noun), and the name should reflect the actor’s role.
Information Systems Department

13. 3.Use cases
A use case represents functionality for an actor, named by 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
Information Systems Department

14. Cont. Each Actor must be linked to a use case,
while some use cases may not be linked to actors.
= Use Case
Information Systems Department

15. 4.1 Relationships between Use Cases and Actors
Association:
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
Information Systems Department

16. Example
Draw use case diagram for a restaurant that contains at least three use cases.
Information Systems Department

17. Produce Management Reports
Cont.
Restaurant System
Order Food
Service Person
Customer
Hire Employee
Produce Management Reports
Applicant
Manager
Information Systems Department

18. Example
An online shopping portal allows their customers to browse or buy different items. A customer may buy item(s) or just view the items and logout. If the customer decides to purchase an item, he/she selects the item and adds it to the shopping cart. Once the customer finishes selecting the item(s) the cart can be viewed. 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.
Information Systems Department

19. Cont.
An online shopping portal allows their customers to browse or buy different items. A customer may buy item(s) or just view the items and logout. If the customer decides to purchase an item, he/she selects the item and adds it to the shopping cart. Once the customer finishes selecting the item(s) the cart can be viewed. 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.

20. Online shopping system
Cont.
Online shopping system

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

22. 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
Information Systems Department

23. More about Generalization
registration
graduate
non-graduate
Information Systems Department

24. Generalization Example
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.
Information Systems Department

25. 2. Include
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.
base
included
<<include>>
Information Systems Department

26. 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.
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
output
generating
verifying
student id
<<include>>
Information Systems Department

27. Include relationship
Include relationship – a standard case linked to a mandatory use case.
Authorize Car Loan
Check Client’s Credit History
<<include>>
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 .
Information Systems Department

28. 3. 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>>
Information Systems Department

29. More about Extend
Enables to model optional behavior or branching under conditions.
Request exam copy
Appeal exam-grade
<<extend>>
Information Systems Department

30. Extend relationship Extend relationship – linking an optional use case
to a standard use case.
Register Course
Register for Special Class
<<extend>>
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…).
The optional UC extends the standard UC
Standard use case can execute without the extend case
 loose coupling.
Information Systems Department

31. Cont. place phone call cellular network user receive conference call
additional call
use
scheduler
<<extend>>
Cellular Telephone
Information Systems Department

32. 4.3 Relationships between Actors
Generalization:
The specialized actors inherit the behavior of the superclass and then extend that behavior in some way.
student
non-graduate
graduate
Information Systems Department

33. 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
Information Systems Department

34. Elements of use case diagram Summary
Connection between Actor and Use Case
Boundary of system
<<include>>
Include relationship between Use Cases (one UC must
call another; e.g., Login UC includes User Authentication UC)
<<extend>>
Extend relationship between Use Cases (one UC calls
Another under certain condition; think of if-then decision points)
Information Systems Department

35. Elements of use case diagram Summary
name
Use case , starts with a verb
name
Actor can be human or other system
Information Systems Department

36. Question
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.
Information Systems Department

37. The answer
Information Systems Department

38. 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.
Information Systems Department

39. Use Case Behavior Description
Types of use case behavior
description format
High level
use case
Expanded use case
HL use case
describes a process
very briefly, usually
in 2 or 3 sentences.
Expanded use case describes a process in details. It has an additional section not present in HL, Typical course of events
Information Systems Department

40. 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
Information Systems Department

41. Use case diagram example
Library Information System
Borrow Resources
Librarian
Add Resources
Patron
Return Resources
Information Systems Department

42. Example of High level use case
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.
Information Systems Department

43. Use case diagram example
POST
Buy Items
Cashier
Log In
Customer
Refund Purchased
Items
Information Systems Department

44. Example of High Level 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.
Information Systems Department

45. 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.
Information Systems Department

46. Example: Expanded 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,…
Information Systems Department

47. Typical Course of Events
System Response
Actor Action
1. This use case begins when a
Customer arrives at the POST
checkout with items to purchase
3. Determines the item price and
adds the item information to the running sales transaction
2. The Cashier records the
identifier from each item
If there is more than one of
the same item, the Cashier can
enter the quantity as well
5. Calculate and presents the
sale total
4. On completion of item entry,
the Cashier indicates to the
POST that item entry is
complete
6. The Cashier tells the
Customer the total
Information Systems Department

48. Typical Course of Events
System Response
Actor Action
7. The Customer gives a cash
payment possibly greater than
the sale total
9. Shows the balance due back to
the Customer & generate a
receipt.
8. The Cashier records the cash
received amount
11. Logs the completed sale
10. The Cashier deposits the cash
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
Information Systems Department

49. Essential vs. Real Use Cases
Use Case Degree of Design Commitment
Essential
Very abstract
Real
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
Information Systems Department

50. Essential vs. Real Use Cases Buy Items
Actor Action
1. This Cashier records the
identifier for each item
System Response
2. Determines the item price & adds the item information to the running sales transaction
The description & price of the item are presented
Essential Use Case
Actor Action
1. For each item, the Cashier types in the UPC field of Window1. They then press “Enter Item” button with the mouse or Enter key
System Response
2. Display the item price & adds the item information to the running sales transaction
The description & price of the current item are displayed in Textbox 2 of Window 1
Real Use Case
Information Systems Department

51. 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)
Information Systems Department

52. Example
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
Information Systems Department

53. 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
Information Systems Department

54. Cont. Typical course of event Information Systems Department Actor
System response
1. This use case starts when the user arrives at the ATM and enters his/her identification
3. User enters his password
5. User chooses withdraw transaction
7. User enters the required amount
9. Chose to confirm the receipt operation
11. the user leaves with his/her cash and receipt
2. Validate the user identification. If valid, request password
4. Verifies the authorizations. If authorized, asks for transaction type
6. Display the cash amounts choices
8. Asks for receipt
10. Verifies the requested amount with the account limit and daily limit. If receipt is requested, print the receipt
Information Systems Department

55. Cont.
Alternative:
Line 2: if identification invalid, operation cancelled
Line 4: If password not authorized, error message is displayed and give 2 more trials
Information Systems Department

56. Example
Do the following operations on the use case diagram stated bellow:
Information Systems Department

57. 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.
Information Systems Department

58. Cont.
Information Systems Department

59. Cont. 2) Write a high level format for make appointment use case.
Use case: Make appointment
Actors: Patient (initiator), Nurses
Description: This use case begins when the patient ask the nurses to reserve an appointments with a certain doctor and date, and produce an appointment slip.
Information Systems Department

60. Cont. 3) Write typical course of events for make appointment use case.
Information Systems Department

61. Cont.
Information Systems Department

62. Question Write a high level format for snooze use case (slide #37).
Information Systems Department

63. The answer
Information Systems Department

64. Organizing Use Cases You can have a package own a use case.
Use cases and actors can and often are placed into a substantial package structure.
It is often useful to organize them along either functional lines or by use cases performed by specific actors.
Note that the diagram can include use cases that are from other packages
Information Systems Department

65. Cont.
Information Systems Department

66. Cont.
Information Systems Department

67. Testing Use Cases
Testing involves two different but related goals: verification and validation.
Verification confirms that the system is implemented correctly according to the requirements specifications and the design.
Validation ensures that the system under development actually addresses the customer’s needs.
Information Systems Department

68. Cont.
Use cases provide the functional view of a software project from the start, making it the main source for validation.
If the use cases don’t reflect the needs of the users, then validation is impossible.
Verification can’t be carried out until there are working parts of the system. Then, it is possible to test that the system behaves as specified by the users, that the use cases described in the use-case model perform.
Information Systems Department

69. Use Cases and Requirements Management
Use cases provide an excellent way to capture and to organize requirements.
However, systems will almost always get requirements from additional sources, not just documented use cases.
Additional requirements-gathering efforts (interview, questionnaire, prototyping) are likely needed for many projects.
Information Systems Department

70. Summary
Use-case modeling is a technique used to describe the functional requirements of a system.
Use cases are described in terms of external actors, use cases, and the subject modeled.
Actors represent a role that an external entity such as a user, hardware, or another system plays in interacting with the system.
Information Systems Department

71. Cont.
Actors initiate and communicate with use cases, where a use case is a set of sequences of actions performed in the system.
A use case must deliver a tangible value to an actor and is normally described through text documentation.
An actor is typically connected to one or more use cases through associations.
Information Systems Department