2. 2
A use case consists of a series of actions that a user
must initiate with the system to carry out some useful
work and to achieve his/her goal.
A use case is a sequence of transactions performed by a
system that produces a measurable result for a
particular actor.
Use cases specify the expected behavior [what], and
not the exact method of making it happen [how]
A good use case must represent the point of view of the
people who will use or interact with the system.
A complete set of use cases = system requirements.
3. 3
A use case diagram enables the system designer to
discover the requirements of the target system from the
user's perspective.
If the designer uses use case diagrams in the early stage
of system development, the target system is more likely
to meet the needs of the user.
From both the designer and user’s perspectives, the
system will also be easier to understand.
Use cases are created based on identified functional
requirements but are not mapped one-to-one to
requirements.
4. 4
A use case diagram consists of three main components:
Actors,
Use Cases, and their communications, and
some additional documentation such as use case
descriptions for elaborating use cases and problem
statements that are initially used for identifying use
cases.
In addition, a use case diagram may consist of a system
boundary.
6. 6
Actors
Actors are the external entities that interact with the
system.
Represent roles that humans, hardware devices, or
external systems play while interacting with a given
system
They are not part of the system and are situated outside
of the system boundary
Actors may be both at input and output ends of a use case
An actor represents a role that a user can play, but not a
specific user.
7. 7
Primary actors:
Primary actors use the system to achieve an observable user
goal.
Primary actors are completely outside the system and drive
the system requirements.
Secondary actors:
play a supporting role to facilitate the primary actors to
achieve their goals.
Secondary actors often appear to be more inside the system
than outside.
8. 8
Define system boundary to identify actors correctly
Identify users and systems that depend on the system’s
primary and secondary functionalities
Identify hardware and software platforms with which
the system interacts
Select entities that play distinctly different roles in the
system
Identify as actors external entities with common goals
and direct interaction with the system
Denote actors as nouns
9. 9
Use Case
A use case describes a sequence of actions a system
performs to yield an observable result or value to a
particular actor.
Naming convention = verb + noun or verb + noun phrase,
e.g. withdraw cash.
10. 10
Lines between Actor and Use Case summarize
interactions graphically
Actors and use cases exchange information to achieve the
goal but the details of interaction are not shown
11. 11
Describe a sequence of transactions performed by a
system that produces a measurable result (goal) for a
particular actor;
Describe the behavior expected of a system from a
user's perspective;
Enable the system analyst to understand and model a
system from a high-level business viewpoint; and
Represent the interfaces that a system makes visible to
the external entities and the interrelationships between
the actors and the system.
12. 12
An automatic teller machine (ATM) system is typically
used by different types of users (actors).
You are given a task to develop software for such an
ATM system.
The manager of the bank explains the first requirements
of the system: The user can open and close accounts. He
or she withdraws and deposits cash. The user can view
his / her accounts, and can make cash transfer between
his / her accounts.
14. 14
We will consider a simple hotel information system for
two types of customers:
Tour Group customers and Individual customers.
Tour Group customers are those who have made
reservations through a tour operator in advance
while Individual customers make their reservations
directly with the hotel.
Both types of customers can book, cancel, check-in
and check-out of a room by phone or via the
Internet.
16. 16
In the process of developing a use case model, we may
discover that some use cases share common behaviors.
There are also situations where some use cases are very
similar but they have some additional behaviors.
17. 17
Use Case: Withdraw Money
Flow of Events:
1. The user inserts an ATM card. The
system prompts the user to enter a
password.
2. The user enters the password. The
system validates the user password.
....
….
….
Use Case: Deposit Money
Flow of Events:
1. The user inserts an ATM card. The
system prompts the user to enter a
password.
2. The user enters the password. The
system validates the user password.
....
….
….
Common
Behavior
18. 18
Use Case: Withdraw Money
Flow of Events:
1. include (login)
....
….
….
Use Case: Deposit Money
Flow of Events:
1. include (login)
….
….
…..
Use Case: Login Account
Flow of Events:
1. The user inserts an ATM card. The system prompts
the user to enter a password.
2. The user enters the password. The system validates
the user password.
20. 20
Include relationships are used when two or more use
cases share some common portion in a flow of events.
This common portion is then grouped and extracted to
form an inclusion use case for sharing among two or
more use cases.
Most use cases in the ATM system example, such as
Withdraw Money, Deposit Money or Check Balance,
share the inclusion use case Login Account.
Include relationship: Allows reuse of functionality by
multiple use cases
22. 22
Extend relationships are used when two use cases are
similar, but one does a bit more than the other.
For example, you may have a use case that captures the
typical case (the base use case) and use extensions to
describe variations.
A base use case may therefore conditionally invoke an
alternative use case.
25. 25
Alternative flow of events
Base use case flow of events
Alternative flow does not return to the point at which it is
inserted. <<extend>> relationship is for modeling
alternative flow!
26. 26
Exception flow of events
Base use case flow of events
Exception flow may or may not return to a base use
case flow. <<extend>> relationship is not for
modeling exceptions.
27. 27
Shows inheritance and specialization
One use case is simply a special kind of another
29. 29
Base use case – invoked directly by actor to achieve an
observable goal.
Abstract use case – invoked by other use cases and is not
a complete goal from user’s perspective.
e.g. withdraw cash (concrete use case) vs login (abstract
use case)
30. 30
Organize use cases by grouping them in packages as in
the organization of classes
Generalization
• One use case is a special case of another
Includes
• Included use case embodies common behavior
Extends
• Extending use case adds behavior
31. 31
A use case is a description of what a system is used for,
and who uses it, without providing details of how it
performs its functions.
A use case description serves as an agreed description
between the user and the system designer on the flow of
events that would happen when a use case is invoked.
A use case description is explained and elaborated
through scenarios (a set of sequences of actions).
Each of these scenarios is simply an instance of the use
case.
33. 33
A brief user story explaining who is using the system and
what they are trying to accomplish.
Specify behavior of use case by description, not modeling
Examples include informal structured text, formal structured
text with conditions, and pseudocode
Typically specifies:
How and when the use case starts and ends
Interaction with the actors and the exchange of objects
Flow of events:
• main / typical (success),
• alternative(success), and
• exceptional (failure) flows
34. 34
In a human resources system, for the “Hire Employee”
use case, the following scenarios may apply:
Typical success scenario: Hire a person from outside
of the company, for example, from another company
Alternative success scenario: Hire a person from
within the same company, for instance, from another
division
Exceptional failure scenario: No qualified person
could be hired
35. 35
Entry and Exit Conditions
Entry conditions describe the environment under
which the use case is invoked
Exit conditions reflect the impact of the use case on
the environment through its execution
Quality Requirements
Describe quality attributes in terms of a specific
functionality
For example, requires system response in < 30
seconds
36. 36
Extract the functionality that is available to each actor
Establish specific instances and not general descriptions
Denote situations in the current and future systems
Identify:
Tasks to be performed by the user and the system
Flow of information to the user and to the system
Events that are conveyed to the user and to the system
For the events flow, name steps in active voice
37. 37
Informal Description:
For this case study, the task is of constructing the
design elements for a system that can be used to
manage courses and classes for an organization that
specializes in providing training. The name of the
system is Courseware System. The organization offers
courses in a variety of areas such as learning
management techniques and understanding different
software languages and technologies. Each course is
made up of a set of topics.
38. 38
Informal Description(Cont.):
Tutors in the organization are assigned courses to teach
according to the area that they specialize in and their
availability. The organization publishes and maintains a
calendar of the different courses and the assigns tutors every
year. There is a group of course administrators in the
organization who manage the courses including course
content, assigning courses to tutors, and defining the course
schedule. The training organization aims to use the
Courseware System to get a better control and visibility to
the course management and to also streamline the process of
generating and managing schedules for different courses.
39. 39
The following terms and entities are specific to the
system:
Courses and Topics that make up courses
Tutors that teach courses
Course Administrators who manage the assignment of
courses to tutors
Calendars and Course Schedules that are generated as a
result of the work performed by the course administrators
Students who refer to Calendars and Course Schedules
todecide which courses they wish to take up for study
40. 40
Actors: Tutor, Student, Course Administrator (main
actor)
Use Cases (primary business: secondary user)
Manage courses: View courses, Manage topics for a
course, and Manage course information
Manage tutors: View course calendar, View tutors,
Manage tutor information, and Assign courses to
tutors
43. 43
Use Case: Manage Course Information (UC_ID1)
Participating Actors: Course Administrator
Entry Conditions: Course Administrator is logged into
Courseware
Exit Conditions: Course Administrator has received an
acknowledgement from the system that the selected
transaction is complete, or if not complete, a message
explaining the failure
Quality Requirements: (Performance) Course
Administrator receives a response from the system in less
than 3 seconds
Related Requirements: Create, Modify, and Delete Course
…
44. 44
Use Case: Manage Course Information (UC_ID1)
Typical flow of events:
1. Course Administrator selects Create New Course
– System invokes Create New Course use case
2. Course Administrator selects Modify Existing Course
– System invokes Modify Existing Course use case
45. 45
Use Case: Create New Course (UC_ID2)
Participating Actors: Course Administrator
Extends: Manage Course Information (UC_ID1)
Entry Conditions: Course Administrator has selected
Create New Course option
Exit Conditions: Course Administrator has received an
acknowledgement from the system that a course has been
created, or if not, a message explaining the failure
Quality Requirements: (Performance) Course
Administrator receives a response from the system in less
than 3 seconds
Related Requirements: Create Course
…
46. 46
Use Case: Manage Course Information (UC_ID2)
Typical flow of events:
1. Course Administrator enters New Course Information
a) System invokes Validate Course Information use case
b) For a valid response, system creates a new course entry and
sends an acknowledgment back to the actor
Exceptions:
2. Course Administrator enters New Course Information
b) Invalid response received, so system reports failure with a
message indicating invalid course information
47. 47
Use Case: Modify Existing Course (UC_ID3)
Participating Actors: Course Administrator
Extends: Manage Course Information (UC_ID1)
Entry Conditions: Course Administrator has selected
Modify Existing Course option
Exit Conditions: Course Administrator has received an
acknowledgement from the system that a course has been
modified, or if not, a message explaining the failure
Quality Requirements: (Performance) Course
Administrator receives a response from the system in less
than 3 seconds
Related Requirements: Modify and Delete Course
…
48. 48
Use Case: Modify Existing Course (UC_ID3)
Typical flow of events:
1. Course Administrator selects Find Existing Course option
a) System searches for a selected course and returns existing
course information
2. Course Administrator enters new course information
a) System invokes Validate Course Information use case
b) For a valid response, system updates the existing course
entry and sends an acknowledgment back to the actor
49. 49
Use Case: Modify Existing Course (UC_ID3)
Alternatives:
1. Course Administrator selects Delete Existing Course option
a) System invokes Delete Existing Course use case
Exceptions:
1. Course Administrator selects Find Existing Course option
a) System searches for a selected course and returns failure
stating that the course could not be found
2. Course Administrator enters New Course Information
b) Invalid response received, so system reports failure with a
message indicating invalid course information
50. 50
Use Case: Delete Existing Course (UC_ID4)
Participating Actors: Course Administrator
Extends: Modify Existing Course (UC_ID3)
Entry Conditions: Course Administrator has selected
Delete Existing Course option
Exit Conditions: Course Administrator has received an
acknowledgement from the system that a course has been
deleted, or if not, a message explaining the failure
Quality Requirements: (Performance) Course
Administrator receives a response from the system in less
than 3 seconds
Related Requirements: Delete Course
…
51. 51
Use Case: Delete Existing Course (UC_ID4)
Typical flow of events:
a) System deletes a selected course and sends an
acknowledgment back to the user
Exceptions:
a) System cannot delete a selected course so it returns
failure stating that the course could not be deleted