The document provides guidance on developing use case models for a system. It defines key concepts like actors, use cases, include and extend relationships. It explains that use cases describe interactions between actors and the system to achieve goals. The document also provides examples of use case diagrams and descriptions to illustrate how to identify actors and use cases, and describe typical and alternative flows and exceptions. It emphasizes that use cases specify expected behavior from the user's perspective without detailing implementation.

1. 1

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.

5. 5

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.

13. 13
actor
communication
system boundary
use case
system name

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.

15. 15

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.

19. 19

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

21. 21
Login Account
(Included use case)
Withdraw Money
(Base use case)

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.

23. 23

24. 24
Process Excess Amount
(Extending use case)
Withdraw Money (Base use case)
If conditional guard is true, extending flow is executed.

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

28. 28

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.

32. 32

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

41. 41

42. 42

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

52. 52