The document discusses use cases and use case diagrams. It defines a use case as a description of a set of sequences of actions that a system performs to yield an observable result for an actor. Actors can be human users or other systems. Use cases specify what a system does without specifying how. Relationships like generalization, inclusion, and extension are used to organize use cases. A use case diagram visually depicts the actors and their interactions with the system's use cases.

1. BY:
ALTAF HUSSAIN
MS(CSE), NUST
SSO. KRL
USE CASES
&
Use Case Diagram

2. INTRODUCTION
 No system exists in isolation. Every interesting system
interacts with human or automated actor that use that
system for some purpose, and those actors expect that
system to behave in a predictable way.
 A USE CASE specifies the behavior of a system or a part of a
system and is a description of a set of sequences of actions,
including variants, that a system performs to yield an
observable results of value to an actor.

3. USE CASEs & ACTORs
 We apply use cases to capture the intended behavior of the
system we are developing, without having to specify how that
behavior will be implemented.
 Use case provide a way for our developers to come to a
common understanding with your system’s end user and
domain experts.
 In addition use cases serve to help validate our architecture
and to verify our system as it evolves during development.
 As we implement the system, these use cases are realized by
collaborations whose elements work together to carry out
each use case.

4. USE CASEs & ACTORs
 A use case describes a set of sequences, in which each
sequence represents the interaction of the things outside the
system (its actor) with the system itself ( and its key
abstraction).
 These behaviors are in effect system-level functions that we
use to visualize, specify, construct and document the
intended behavior of our system during requirement
capturing and analysis.
 A use case represents the functional requirements of our
system as a whole

5. USE CASEs & ACTORs
 A use case involves the interaction of actors and the system.
 An actor represents a coherent set of roles that users of use
case play when interacting these use cases.
 Actor can be human or they can be automated systems.
 For example in modeling a bank, processing a loan involves,
among other things, the interaction of customer and loan
officer.

6. Use Case & Flow of Events
 A use case specify what a system (subsystem, class or
interface) does but it does not specify how it does it.
 Modeling use cases we try to keep clear the separation of
concerns between outside and inside view.
 We specify the behavior of a use case by describing a flow of
events in text clearly enough for an outsider to understand it
easily.
 Writing use cases, we specify the flow of events, we include
how and when the use case starts and ends, when the use case
interacts with the actors and what objects are exchanged, and
the basic flow and alternative flows of the behavior.

7. Example of Use Case & Flow of Events
 In the context of ATM system, consider the use case
ValidateUser.
 Main Flow of events:
 The use case starts when the system prompts the customer for a
PIN number. The Customer can now enter a PIN number via
keypad. The Customer commits the entry by pressing the Enter
button. The system then checks this PIN number to see if it is
valid. If the PIN number is valid, the system acknowledges the
entry, thus ending the use case.
 Exceptional Flow of events:
 The Customer can cancel a transaction at any time by pressing the
Cancel button, thus restarting the use case. No changes are made
to the Customer’s account.

8. Example of Use Case & Flow of Events
 Exceptional Flow of events:
 The Customer can clear a PIN number before committing it and
reenter a new PIN number.
 Exceptional Flow of events:
 If the Customer enters an invalid PIN number, the use case
restarts. If this happens three times in a row, the system cancel
entire transaction, preventing the Customer from interacting
with the ATM for 60 seconds.
 Use Cases can be specified in a number of ways, including
informal structured text (as in this example), formal
structured text (with pre- and post-conditions), and with
pseudo code.

9. Use Cases & Scenarios
 An interaction diagram includes collaboration and sequence
diagrams.
 Typically first we describe the flow of events for a use case in
text.
 As we refine our understanding of the system, we want to also
use interaction diagrams to specify these flows graphically.
 Typically we use one sequence diagram to specify the use
case’s main flow and variations of that diagram to specify a
use case’s alternate or exceptional flows.

10. Use Cases & Scenarios
 It is desirable to separate main versus alternate flows because a
use case describes a set of sequences, not just single sequence,
and it would be impossible to express all the details of an
interesting use case in just a single sequence.
 For example in a HR System, we might find a use case Hire
Employee. This general business function might have many
possible variations. we might hire a person from another
company (the most common scenario); we might transfer a
person from one division to another (common in international
companies); or we might hire a foreign national (which
involves its own special rule). So each of these variants can be
expressed in different sequence.

11. Use Cases & Scenarios
 Actually one use case (Hire Employee) describes a set of
sequences in which each sequence in the set represents one
possible flow through all these variations.
 Each sequence of a use case is called a Scenario.
 A scenario is a specific sequence of actions that illustrates
behavior.
 Scenarios are to use cases as instances are to classes, meaning
that a scenario is basically an instance of a use case.
 For each use case we will find primary scenario (which define
essential sequences) and secondary scenarios (which define
alternate sequences).

12. Organizing Use Cases
 We organize use cases by specifying generalization, include,
and extend relationships among them.
 We apply these relationships in order to factor common
behavior (by pulling such behavior from other use cases that it
includes) and in order to factor variants (by pushing such
behavior into other use cases that extend it).
 Generalization among use cases is like generalization among
classes. It means that 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; and the child may be
substituted any place the parent appears (both parent or child
may have concrete instances).

13. Organizing Use Cases
 For example, in a banking system, we might have the use case
Validate User, which is responsible for verifying the identity of
the user.
 We might have its two specialized children of this use case
Check Password and Retinal Scan. Both of these behave like
Validate User and may be applied anywhere Validate User
appears, yet both of which add their own behavior (the former
by checking a textual password and the later by checking the
unique retina patterns of the user.
 Generalization is rendered as solid directed line with a large
open arrowhead, just like generalization among classes.

14. Organizing Use Cases
 An Include relationship between use cases means that the base
use cases explicitly incorporates the behaviors of another use
case at a location specified by base.
 The include use case never stands alone, but it is only
instantiated as a part of some larger base use case that includes
it.
 We can think of it as the base use case pulling the behavior
from the supplier use case.
 We might include relationship to avoid describing the same
flow of events several times, by putting the common behavior
in a common use case of its own (the use case that is included
by the base use case).

15. Organizing Use Cases
 An Extend relationship between use cases means that the base
use case implicitly incorporates the behavior of another use case
at a location specified indirectly by the extending use case.
 The base use case may stand alone, but under certain
conditions, its behavior may be extended by the behavior of
another use case.
 These base use case may be extended at certain point called the
extension points.
 We can think of extend as pushing the behavior to the base use
case. Extend relationship is used to model the part of use case
that the user may see as optional system function.

16. Organizing Use Cases
 Using Extend relationship we separate optional behavior from
mandatory one. Similarly we use it to model separate sub flow
that is executed only under given conditions.

18. Organizing Use Cases
Organizing use cases by extracting common behavior
(though include relationships) and distinguishing
variants (through extend relationship) is an important
part of creating simple, balanced, and understandable
set of use cases for a system.

19. USE CASE DIAGRAM
 Use Case Diagram is one of five diagrams in UML for modeling
the dynamic aspects of systems (Activity diagrams, Statchart
diagram, Sequence diagram, Collaboration diagram & four
other type of diagrams in UML for modeling dynamic aspects
of a system).
 Use case diagram show use cases, actors and their
relationships to model the context of a system, subsystems, or
a class or model the requirements of behavior of these
elements.
 Use Case diagram is central to model the behavior of a system.

20. USE CASE DIAGRAM…
 Suppose someone hands you a box. On one side of that box
there are some buttons and a small LCD panel. Moreover, the
box is nondescript; you are not even given with a hint about
how to use it. You could randomly punch buttons and see what
happens, but you would be hard to pressed to figure out what
that box does or how to use it properly unless you spent a lot of
trial-and-error time.
 Software intensive systems can be like that. If you are a user,
you might be handed an application and told to use it. If the
application follows normal conventions of operating system
you are use to, you might be able to get it to do something
useful after a fashion, but you’d never come to understand its
more complex & subtle behavior that way.

21. USE CASE DIAGRAM…
 Simply we apply use case diagram to visualize the behavior of a system
so that users can comprehend how to use that element and so that
developers can implement that element.

22. USE CASE DIAGRAM EXAMPLE

23. USE CASE DIAGRAM EXAMPLE
Last slide Use Case diagram show the context of a Credit Card
Validation System, with an emphasis on the actors that
surround the system. We will find Customer, of which there are
two kinds (Individual Customer and Corporate Customer).
These actors are the roles that human play when interacting
this system. In this context, there are also actors that represent
other institutions, such as Retail Institution (with which a
Customer performs a card transaction to buy an item or
service) and Sponsoring financial institution (which serves as
the clearinghouse for the credit card account). In the real
world, these later two actors are likely software intensive
systems themselves.

24. Questions…