8.3.

Developing Use-Case Diagrams

A use case diagram is " a diagram that shows the relationships among use cases and actors within
a system ".
A use case model is comprised of one or more use case diagrams and any supporting
documentation such as actor definition and use case specification. The use case specification tend
to be the primary artifact with use case diagrams filling a supporting role as the " glue " that keeps
your requirements model together. Use case models should be developed from the user point of
view and not from the (often technical) point of view of developers
It is used to
I.Provide an overview of all or part of the usage requirements for an organization or system in the
form of a business model or an essential model.
II.To communicate the scope of a development project .
III.Model your analysis of your usage requirements in the form of a system use case model.
We can also create our own set of diagrams to meet our requirements. UML diagrams are generally
made in an incremental and iterative way.There are two broad categories of UML diagrams and
then are again divided into sub-categories:
There are guidelines for:
Use Cases
Actors
Relationships
System Boundary Boxes

1. Use Cases

A use case specifies a sequence of actions that provide a measurable value to an actor. A use
case is drawn as a horizontal ellipse on a UML use case diagram, as you see in the figure.
Each use case focuses on describing how to achieve a goal or task. A use case should:

Describe what the system shall do to assist the actor in achieving a goal
Not include any details about the screens or user interfaces.

For example, the below use case describes a simple Login.Sequence of steps included in the
Login use case are :

i.System prompts the user to log in.

ii.User enters user name and password in the system.
iii.System verifies the user name and password.
iv.The system logs user on to the system
2. Actors
An actor is an external entity (outside of the system) that interacts with the system by
participating a Use Case. Actors can be in real life people (for example users of the system),
external events and other computer systems.

An actor is an external entity (outside of the system) that interacts with the system by
participating a Use Case. Actors can be in real life people (for example users of the system),
external events and other computer systems.
Actors do not represent the physical systems or people , but their role. This means that when a
person interacts with the system in different ways , he will be represented by several actors.
For example a person that gives customer support by the telephone would be represented by an
actor ' Support Staff '. A person who takes orders from the customer is represented by an actor '
Sales Representative '.
3. Relationships
There are several types of relationships appear on a use case diagram:
Association :
An association can be between " a use case and an actor " or between two use cases.
It is the relationship between an actor and a use case. It indicates that an actor can use a certain
functionality of the business system - the business use case: Association can be represented as
below.

Example : A traveler purchases a transport ticket

In the following figure ,Purchase Ticket is the Use case and the Traveler is the actor. A given
ticket purchase can only be made by one traveler,but a traveler can purchase any number of
tickets(represented as 1..*).This is a type of association relationship

Include Relationship :
It is a relationship between two business use cases that signifies that the business use case on
the side to which the arrow points is included in the use case on the other side of the arrow. For
one functionality that the business system provides, another business functionality is accessed.
Functionality that are accessed repeatedly can be depicted as individual business use cases,
which can be used in multiple ways. In can be represented as below.

Example :
In the following figure , An include relationship points from the CheckOrderStatus use case to the
LogIn use case.It indicate that the CheckOrderStatus use case always includes the behaviors in
the LogIn use case.
The included use case LogIn cannot stand alone and the original use case CheckOrderStatus is
not complete without the LogIn use case.

4. System Boundary Boxes

The rectangle around the use case is called the system boundary box and it indicates the scope
of your system - the use cases inside the rectangle represent the functionality that you intend to
implement.
Sample Use Case Diagrams
Example 1 : Sales Application
There are two actors customer and other is the sales clerk. In this example Sales Clerk checks
out an item is the use case identified.
Use Case Specification: Sales Clerk checks out an item.
i.Customer sets the selected items on counter.
ii.Sales Clerk swipes UPC(Universal Product Code) reader across UPC code on item.
iii.System looks up UPC code in database to retrieve item type ,description and price.
iv.System emits beep sound.
v.System adds price, item type and item description to current invoice.
vi.System calculate price along with the tax details.
Following figure shows what the above use case might look like in UML schematic form. The use
case is drawn as an oval. The actors are represented as stick figures. Actors and use case are
connected using lines.

Example 2 : Bank ATM

An Automated Teller Machine (ATM) or the Automatic Banking Machine (ABM) is banking
subsystem that provides customers with access to financial transactions without the need for a
clerk,cashier or bank teller.
Customer (actor) uses bank ATM to check balance of his/her bank accounts, withdraw cash
,transfer funds and deposit funds(use cases). ATM Technician(actor) provides maintenance and
repairs((use cases). All these use cases also involve Bank as an actor, it is related to customer
transactions or to ATM servicing.

Example 3 : Passenger Services

Following figure illustrates a use case diagram with the actors: the Passenger (1) and the CheckIn representative (2), as well as the business use cases Check-In (3) and Express Check-In (4):

Starting with the Passenger (1)(actor) , we find association lines to two use cases, Check-In (3)
and Express Check-In (4). This means that people, who appear as passengers, can either go
through Check-In, or Express Check-In(which can be conducted without luggage) use case.
Example 4 : Order Management System
The following is a sample use
case diagram representing the
order management system. If
we look into the use case
diagram, we will find three use
cases (Order, Special Order
and Normal Order) and one
actor which is customer.
The Special Order and Normal
Order use cases are extended
from Order use case,it is an extends(generalization)relationship. Customer(actor) lies outside the
system as it is an external user of the system.

Where can Use Case Diagrams be applied?

Use case diagram is used to gather system requirements and actors.
It specify the events of a system and the flow. It never describes how they are implemented. Use
case diagram can be imagined as a black box where we can see only the input, output and the
function of the black box is known.
These diagrams are used at a very high level of design. High level design is refined again and
again to get a complete picture of the system. A well structured use case also describes some
extra elements such as precondition, post condition and exceptions. These extra elements are
used to make test cases during testing phase.
Following are the places where use case diagrams can be used:

Requirement analysis and high level design phase.

Model the context of a system.

Please refer the below link for more information.

http://www.uml-diagrams.org/use-case-diagrams-examples.html
http://www.smartdraw.com/resources/tutorials/uml-diagrams/#/resources/tutorials/UML-UseCase-Diagram
http://www.cragsystems.co.uk/uml_tutorial/