Start at 17th March 2012
end at 31th March 2012
Use Case Diagrams
 Any use case diagram should contain:

Actor(s).

Use cases.

Associations/Relationships
among actors and use cases.
Actors

Actors are drawn as stick persons with the role of the actor written below.

Actor names are unique typically
an actor plays with respect to the system.

Is someone (e.g. human beings) or something
represent
the
role
that
(e.g. other objects or systems) that interact with the system.

Is entity external to the system who participates in the story
of the use case (receive or input),
such as a person, computer system or organization.
Actor role name

Example: a library clerk, cashier, customer,
Passenger, GPS satellite, bank, customer department.
Use Case

Use cases are drawn as ellipses with the name of the use case written
inside the ellipse.

Use case name typically consists of an active verb and one or more
nouns that concisely describe the system function modeled.
Use case
5
Use Case(s)

Each use case have an associated behavior specification which describes the
sequence of actions making up a use case scenario.

Use case behavioral description has two formats:
High Level Use Case
Expanded Use Case
Describes a process very briefly, usually in 2 or
3 sentences.
Describes a process in details.
It has an additional section not present in HL.
It consists of :
• Use Case: Use case name.
• Actors: List of actors (external agents)
indicating who initiates the use case.
• Description (Success scenario): Narrative
description of the process.
• Purpose: Intention of the use case.
• Type:
1- Primary, Secondary or Optional.
2- Essential or Real.
• Cross References: Related use cases and
system functions.
• Typical course of actions: describes in
detail the conservation of interaction
between the actors and the system.
Plan and Elaborate Phase Steps
1. Define system function.
2. Define system boundary, actors & use cases.
3. HL use cases.
4. Draw use case diagram.
5. Expand critical use cases (Essential / Analysis).
6. Real use case (Design).
7. Rank use case.
Relationships between Use Cases
Include - use cases that are included as parts of other
use cases.
Extend - use cases that extend the behavior of other
core use cases.
Relationships between Use Cases
base
<<include>>
included
 The base use case explicitly incorporates the behavior
of another use case at a location specified in the base.
 The included use case never stands alone. It only
occurs as a part of some larger base that includes it.
The <<include>> Relationship
Relationships between Use Cases
base
<<extend>>
extending
The base use case implicitly incorporates the behavior 
of another use case at certain points called extension
points.
The base use case may stand alone, but under certain 
conditions its behavior may be extended by the
behavior of another use case.
The <<extends>> Relationship
Example: Library System
University library system requirements
Books and journals – the library contains books and journals. It may have several
copies of a given book. Some of the books are for short term loans only. All
other books may be borrowed by any library member for three weeks. Only
members of staff may borrow journals. Members of the library can normally
borrow up to six items at a time, but members of staff can borrow up to 12
items at a time. New books and journals arrive regularly, and old ones are
sometimes disposed of. The current year’s journals are sent away to be bound
into volumes at the end of each year.
Borrowing – it is essential that the system keeps track of when books and journals
are borrowed and returned. The new system should also produce reminders
when a book is overdue. There may in future be a requirement for uses to be
able to extend the loan of a book if it is not reserved.
Browsing – this system should allow users to search for a book on a particular
topic, by a particular author, etc., to check whether a copy of the book is
available for loan and, if not ,to reserve the book. Anybody can browse in the
library.
P. Stevens, R. Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, 2000
Define actors and use cases:
Borrower
Visitors
Library clerk
reserve books,
Borrow Resources ,
Extend loan, Resources
Browsing, Manage loans
Resources Browsing
Add resources, delete
resource , Register
Borrowers, update
catalogue
High Level Use Case Format: HL
Borrow Resources
 Use Case: Borrow Resources.
 Actors: Borrower (initiator), library clerk
 Type: Primary, Essential.
 Description: A Borrower arrives at a checkout with
Resources to Borrow. The library clerk records the
Borrowed resources and calculate loans. On
completion, the Borrower leaves the library with the
resources.
High Level Use Case Format: HL
Resource Browsing
 Use Case: Resources Browsing.
 Actors: Visitors (initiator).
 Type: Primary, Essential.
 Description: A Visitors can search for a resources by
their topic, authors, ISBN ,titles and….Members of the
library can check the availability of resources or
reserve it.
High Level Use Case Format: HL
Add resources.
 Use Case: Add Resources
 Actor: Library clerk.
 Description (Success Scenario):
The use case begins when the Librarian receives new
resources (books and journals) to add to the catalog. The
title, call number, and other information are recorded.
Then the resources are placed on a shelf organized by
resource type and call numbers.
Use Case Diagram
Lib system
Browse
Cancel Borrowing
Visitor
Borrow copy of Resources
Return copy of Resources
Manage loan
Borrower
Extend loan
Delete Resources
Reserve books
Add Resources
Librarian
Register Members
Update Catalogue
Expanded Use Case Format
Borrow Resources
 Use Case: Borrow Resources.
 Actor: Borrower (initiator), library clerk.
 Purpose: Capture borrowing information.
 Overview (Success Scenario):
A Borrower arrives at a checkout with Resources(books and journals)
to Borrow. The library clerk records the Borrowed resources and
calculate loans. On completion, the Borrower leaves the library with
the resources..
 Type: Primary, Essential .
 Cross References: none.
19
Expanded Use Case Format
Example: Borrow Resources(cont.)
Actor Action
System Response
1. This use case begin when Borrower
arrives at the checkpoint after
browsing a list of resources to
borrow.
2. The Library Clerk records the
resources for registered borrowers.
3. The system will check member ship
and calculate the number of
resources, check resources overdue
then issues loans card for it.
4. The clerk will give borrower
resources with loan card.
5. Logs the completed borrowing.
5.The Borrower will leave with
resources and load card.
20
Expanded Use Case Format
Example: Borrow Resources(cont.)
Alternatives:
Line 2. Borrower are not register cancel borrowing operation.
Line 3. Borrower exceed the number of allowed resources.
Example 2 - Banking System
Example 3 – ATM System