Use Case- Diagram

The traceability of the UML diagrams begins with the use case. The use
case diagram initially sets the boundaries of the business solution. It is the
primary mechanism to capture business requirements.

The use case diagram is a graphical depiction of use cases and the
actors that participate in them. The use case diagram documents
external interactions with the system. This includes human, other system
and machine interactions.

Its purpose is to present a graphical overview of the functionality provided
by a system in terms of actors, their goals (represented as use case), and
any dependencies between those use cases.
Use cases are not inherently object-oriented
- An external (user) view of the system
- Intended for modelling the dialog between the users
and the system

The main concepts in use cases are
- Actor
- Use Case
- <<includes>>
- <<extends>>
Actor

An Actor is a role of an object or objects outside of a system that
interacts directly with it as part of a coherent work unit (a use case)
- One physical object (or class) may play several different roles and be
modeled by several actors
Notation



Reservation Agent
Example actors for an Airline Reservation system
- Airline administrators (fare/schedule setting)
- Travel Agent
- Airline Reservations Agent
- Check-in Agents at Airport
- Gate Agent at Airport

Use Case
- A Use Case captures some actor-visible function
- Achieves some discrete (business-level) goal for that actor
- May be read, write, or read-modify-write in nature
Interaction among actors is not shown on the use case diagram. If this
interaction is essential to a coherent description of the desired behavior,
perhaps the system or use case boundaries should be re-examined.
Interaction among actors can be part of the assumption.

In use case diagrams one can have three types of relationships i.e. Include,
Extend and Generalization.
Example
A Simple Example

Handle Message
Cellular Phone
Customer

Bill Management

Handle Call
External Phone
Company
Actors
Use Case
System
boundary
Association
Finding Actors
External objects that produce/consume data:
Must serve as sources and destinations for data
Must be external to the system
Humans Machines External systems Sensors

Database
Printer
Organizational Units
<<includes>>
One common fragment of a user-perceivable action has been pulled out into a separate
use case
- Like a use case subroutine
Make Reservation and Arrange Tour both depend on Peruse Available
Flights
* Note that the arrows go from the dependent use cases
Typically used when the same unit of functionality is part of more than
one use case
- The base use cases are, in a sense, incomplete without the included use
case
<<extends>>
A significant alternative course of action exists within the use case
- Like use case inheritance
Typically used when there are important, optional variations
on the basic theme of the base use case
- The base use case is complete in and of itself
A use case diagram may contain three types of associations.
A communicates association indicates which actor participates in a use
case.

1. The uses association indicates that one use case must include the
behavior of another use case and shows mandatory yet commonly shared
behavior.

2. The extends association indicates that one use case may optionally
include another extends use case under certain circumstances and shows
the dependency between them. With extends association, the use case
identifies the trigger or reference to the extends use case within the use
case description.
The text behind each use case evolves through refinement from a
summary to a detailed description, which then transforms into multiple
use case scenarios. A use case diagram does not represent a use case
scenario with a model element, that is, a graphical representation. A use
case scenario is an instance of a use case.

It is a type of behavioural diagram.
Example
Actors can be generalized
The child actor
inherits all use-
cases associations



Should be used if (and only if),
the specific actor has more
responsibility than the
generalized one (i.e.,
associated with more use-
cases)

Register Client
Sales Person
Institutional
Sales Person

Perform Sale

Perform
Business Sale
Sales Manager

Cancel Sale
overview the usage requirements
presentations project stakeholders
"the meat" of the actual
requirements
Structure of a Use Case Specification
Name
Actors
Preconditions
Post conditions
Success Scenario
Alternatives flows
Trigger
Triggers
What starts the use-case?
Examples:
Customer reports a claim
Customer inserts card
System clock is 10:00

Preconditions
What the system needs to be true before
running the use-case.
Examples
User account exists
User has enough money in her account
There is enough disk space
Post-Conditions
A post-condition is the outcome of the use-case.
Examples
Money was transferred to the user account
User is logged in
The file is saved to the hard-disk
Minimal guarantee
The minimal things a system can promise, holding even when
the use case execution ended in failure
Examples: Money is not transferred unless authorization is
granted by the user
Success guarantee
What happens after a successful conclusion of the use-case.
Examples: The file is saved; Money is transferred