USE CASE DIAGRAM

It is one of the diagram in UML for modeling the dynamic aspects of the system. We can apply
the UMl-use-case diagram to visualize the behavior of a system, subsystem or a class.

In short we can define a use case diagram as, a diagram that shows a set of use cases and
actors and their relationships.

Developed and formalised by Ivar Jacobson in Objectory method and adopted by the UML. UML
defines a use case as “a set of sequences of actions a system performs that yield an
observable result of value to a particular actor”.

Contents of the Use-case diagram:

It commonly contains
• use cases
• actors
• relationships

Generalization
Association
Dependency

Use-Cases:

A use-case specifies the behavior of a system when the human interacts with the system. It
captures the various functionalities of the system (what the system has to do) without specifying
how that behavior is implemented. From this we can define the use-cases as follows

Definition:

A Use-Case is a definition of a set of sequence of actions, including variants that a system

performs to yield a result to the actor.

• A use-case describes a set of sequences of actions. Each

sequence represents the intersection of the system with the things that exist outside the
system.
• A use case may have variants we can factor the common,
reuseable behavior of a set of usecases by organizing them according to three kinds or
relationships.
• A Use-case carries some tangible amount of work which yields an
observable result to the actors.
• We can apply use-cases to the whole system, sub system and even
for individual classes.

Notation for Use-Case is an Ellipse.

Issue
Book
Validate
User
 Return USECASE
Actors: Book

An actor represents a set of roles that users of use-case play when interacting with the system.

Generally, an actor represents,

o A role that a human play (Customer, Librarian)
o A hardware component (Printer ,Scanner)
o An another system (A billing system)
o Any external system.

An actor is represented as a stick figure.

Notation for an Actor:

(or) <<actor>>
Librarian

Librarian
<<actor>> < … Stereotype for an actor.

Flow of Events:

Each use-case describes what a system (or) sub-system does but it does not specify how it
does it. For better understanding of the system functionalities, (or) use-cases we have to
describe the flow of events for each use-case.

Flow of events are used to specify the behavior of the use-cases. This is the inside view of the
system’s functionalities.

Through this flow of events, we an define

- When the use-case starts and ends.
- When the use-case interacts with the system.
- What objects are exchanged.
- Basic flows and alternate flows of the behavior.

Example:

In the context of ATM systems we can describe the use-case “Validate User” with the following
flow of events.

Main Flow of Events:

- System prompts the customers for a PIN number.

- Customer enters a PIN Number.
- Customer commits the entry by pressing ENTER button.
- System checks the PIN number for validity.
- If it is valid, the system acknowledges the entry and thus ending the use-case.
Exceptional Flow of Events:
- Customer can cancel a transaction at any time by pressing CANCEL button.
- Customer may enter an invalid PIN number, which causes the use case to restart.

Use-Cases and Scenarios:

The only relationships that can be defined between actors is the Generalization relation.

Symbol :

Example :

Employee

Manager Worker

Generalization

Relationship between Actors and Usecase:

The actor is connected to a set of use-cases to show the interaction between them. The only
relationship between an actor and the use-case is Association.

Symbol :( )

Example :
Issue Book
Librarian

Reserve
<<Actor>> Association book

Relationship between use-cases:

We can organize the usecases by specifying the relationships among them. These relationships
are specified in order to factor common behavior and also to factor variants.

The common relationships among the use-cases are:

 Generalization
 Dependency
 Include
Extend
Generalization:

Generalization is a relationship in which a child usecase inherits he behavior and meaning of its
parent use-case. The child may add to or override the behavior of its parents.

Example
Check
Password
Validate
user Generalization

Retinal
scan

Symbol:
Generalization among usecase is rendered as a solid directed line with a large open arrowhead.

Include Relationship:

An include relationship between usecases means that the base use explicitly incorporates the
behavior case of another usecase. The included usecase never stand alone. An include
relationship is used to avoid describe some behavior in more than one usecase. The include
relationship is rendered as a dependency relationship, stereotyped as <<include>>.

<<include>>
Notation: (-------------->)
Borrow
Example: Book <<include>>
Check for
reservation
Reserve
Student Member Book <<include>>

Extend Relationship:

An extend relationship means that base usecase implicitly incorporates the behavior of another
usecase.The base usecase may stand alone, but under certain conditions, its behavior may be
extended by the behavior of another usecase. The base usecase may be extended only at
certain points called Extension points.

We can use the extend relationship to model the part of a usecase. The user may see to be
optional, showing variation from the behavior.

Notation:

Graphically, extend relationship is rendered as a dependency, stereotyped as <<extend>>.

<<extend>>
(<----------------)
 Borrow book

Example: Extn point: <<extend>>

limit exceeds

Refuse book
Reserve
Student Member Book

Difference between <<include>> and <<exclude>>:

<<include>> <<extend>>
1 Base usecase explicitly Base usecase implicitly incorporates
incorporates behavior of another another usecase.
usecase.
2 The usecase which is included It can stand alone.
can never stand alone.
3 This is used when there is a This is used when the usecases wants to
need of reusing the same show the exceptional (optional) behavior.
usecase by more than one
usecase.
4 Example. Example.

Usecase diagram:

UseCase diagram is used to model the static view of the system. We can apply use case
diagram in 2 ways.

1. To model the context of a system: This is used to know which actors lies outside the system
and interact with it.

2. To Model the requirements of a system : Modeling the requirements of a systems involves

specifying what the system should does from the users point of view.

Steps for drawing usecases:

 Identify the actors that surround the system.

 Organize the actors that are similar to one another using
generalization relationship.
 Whenever necessary, provide a stereotype for each other.
 Identify the various use cases associated with each other.
 Draw a use case diagram, with all the actors and specify the
communication path from each actor to the use-cases.
Example:
Check for
Borrow book reservation
Library member

Issue books Refuse book

Return books
Librarian

Reserve books

Staff Student Pay fine

Member Member

Collect fine

Tips For drawing a use-case diagram

For each use-case diagram, give a name that

communicates its purpose.
Use clear Layouts.
Organize the elements spatially
Use notes and colors to draw attention to important features
Do not show to many kinds of relationships.

The purpose of the use-case diagram are

• It provides a way for domain experts to specify outside view and developers to construct
the inside view.
• It helps the developers and the end-users to understand the system easily. Elaboration
method of discovering user goals or system interactions.
• It is used in validation, ie to check whether all the requirements are gathered forms basis
for test data generation (systems test).
• It helps to visualize and document the behavior of the system which is understandable by
the end-user.
• Use-cases represent black box functionality of the system.