Descriptive slides for the Use case Diagrams in UML

1. Duration: 3 Hrs
1
Ramakant Soni
Assistant Professor
Dept. of Computer Science
B K Birla Institute of Engineering & Technology, Pilani, India
Ramakant Soni @ BKBIET Pilani

2. Each use case represents a unit of useful functionality that subjects provide to
actors.
An association between an actor and a use case indicates that the actor and the
use case somehow interact or communicate with each other.
Only binary associations are allowed between actors and use cases.
Ramakant Soni @ BKBIET Pilani 2
Only binary associations are allowed between actors and use cases.
An actor could be associated to one or several use cases.
Customer actor is associated with two use cases - Browse Items and Place Order.

3. A use case may have one or several associated actors.
Manage Account use case is associated with Customer and Bank actors.
Ramakant Soni @ BKBIET Pilani 3
If there are several actors associated to the same use case, it may not be obvious
from use case diagram which actor initiates the use case, i.e. is a "primary
actor". (In non-standard UML, primary actors are those using system services,
and supporting actors are actors providing services to the system.)

4. UML allows the use of multiplicity at one or both ends of an association between the
actor and the use case.
Multiplicity of a Use Case
When an actor has an association to a use case with a multiplicity that is greater than
one at the use case end, it means that a given actor can be involved in multiple use
cases of that type.
Ramakant Soni @ BKBIET Pilani 4
Bank actor is involved in multiple Transfer Funds use cases.
use case multiplicity could mean that an actor interacts with multiple use cases:
• in parallel (concurrently), or
• at different points in time (overlapping), or
• mutually exclusive (sequentially, random, etc).

5. Multiplicity of an Actor
Required actor may be explicitly denoted using multiplicity 1 or greater.
Multiplicity 0..1 of actor means that the actor may or may not participate in
any of their associated use cases.
Ramakant Soni @ BKBIET Pilani 5
Checkout use case requires Customer actor, hence the 1 multiplicity of
Customer. The use case may not need Credit Payment Service (for
example, if payment is in cash), thus the 0..1 multiplicity.

6. Two or more Player actors are involved in the Play Game use case.
Each Player participates in one Play Game.
Ramakant Soni @ BKBIET Pilani 6
Each Player participates in one Play Game.
For instance, multiplicity of actor could mean that interaction of a particular
use case with several separate actor instances might be:
• simultaneous (concurrent) interaction, or
• overlapping interaction, at different points in time, or
• mutually exclusive (sequential, random, etc.) interaction.

7. Use cases could be organized using following relationships:
• Generalization
• Association
• Extend
• Include
Ramakant Soni @ BKBIET Pilani 7
• Include

8. Generalization between Use Cases
Generalization between use cases is similar to generalization between classes –
child use case inherits properties and behavior of the parent use case and may
override the behavior of the parent.
Generalization is shown as a solid directed line with a large hollow triangle
arrowhead, the same as for generalization between classifiers, directed from the
more specific use case to the general use case.
Ramakant Soni @ BKBIET Pilani 8
Web User Authentication use case is abstract use case specialized by Login,
Remember Me and Single Sign-On use cases.

9. Use cases can only be involved in binary associations.
Binary Association
Binary association relates two typed instances. It is normally rendered as a
solid line connecting two classifiers, or a solid line connecting a single
classifier to itself (the two ends are distinct). The line may consist of one or
more connected segments.
Job and Year classifiers are associated
Ramakant Soni @ BKBIET Pilani 9
Job and Year classifiers are associated
Two use cases specifying the same subject cannot be associated since
each of them individually describes a complete usage of the system.

10. Ramakant Soni @ BKBIET Pilani 10

11. Example 1:
Airport check-in and security screening business model
Purpose: An example of a business use case diagram for airport check-in
and security screening.
Credits to: http://www.uml-diagrams.org
Ramakant Soni @ BKBIET Pilani 11
and security screening.
Summary: Business use cases are:
 Individual Check-In
 Group Check-In (for groups of tourists)
 Security Screening, etc.
representing business functions or processes taking place in an airport and
serving needs of passengers.

12. Actors are :
• Passenger,
• Tour Guide,
• Minor (Child),
• Passenger with Special Needs (e.g. with disabilities), all playing external
roles in relation to airport business.
Use cases are :
Ramakant Soni @ BKBIET Pilani 12
• Individual Check-In
• Group Check-In (for groups of tourists),
• Security Screening , etc. - representing business functions or processes
taking place in airport and serving the needs of passengers.
• Baggage Check-in and Baggage Handling <<extend>> Check-In use
cases, because passenger might have no luggage, so baggage
check-in and handling are optional.

13. Ramakant Soni @ BKBIET Pilani 13

14. Example 2: Bank ATM
Purpose: Describe use cases that an automated teller machine (ATM)
provides to the bank customers.
Summary:
Customer (actor) uses bank ATM to check balances of his/her bank
accounts, deposit funds, withdraw cash and/or transfer funds (use cases).
ATM Technician provides maintenance and repairs.
Ramakant Soni @ BKBIET Pilani 14
All these use cases also involve Bank actor whether it is related to
customer transactions or to the ATM servicing.
ATM is a banking subsystem that provides bank customers with access to
financial transactions in a public space without the need for a cashier,
clerk or bank teller.

15. Ramakant Soni @ BKBIET Pilani 15

16. On most bank ATMs, the customer is authenticated by inserting a plastic
ATM card and entering a personal identification number (PIN). Customer
Authentication use case is required for every ATM transaction so we show it
as include relationship.
Ramakant Soni @ BKBIET Pilani 16
If needed, customer may ask ATM for help. ATM Transaction use case is
<<extended>> via Menu extension point by the ATM Help use case
whenever ATM Transaction is at the location specified by the Menu and
the bank customer requests help, e.g. by selecting Help menu item.

17. ATM Technician maintains or repairs Bank ATM. Maintenance use case
includes Replenishing ATM with cash, ink or printer paper, Upgrades of
hardware, firmware or software, and remote or on-site Diagnostics.
Diagnostics is also included in (shared with) Repair use case.
Ramakant Soni @ BKBIET Pilani 17

18. Example 3:
e-Library online public access catalog (OPAC)
Purpose: List top level use cases for e-Library online public access catalog.
An Online Public Access Catalog (OPAC) is an e-Library website which is
part of Integrated Library System (ILS), also known as a Library
Management System (LMS), and managed by a library or group of libraries.
Ramakant Soni @ BKBIET Pilani 18
Summary: Patrons of a library can search library catalog online to locate
various resources - books, periodicals, audio and visual materials, or other
items under control of the library. Patrons may reserve or renew item,
provide feedback, and manage their account.

19. Ramakant Soni @ BKBIET Pilani 19

20. Example 3:
Online shopping use case diagrams
Purpose: Provide top level use cases for a web customer making purchases
online.
Summary: Web customer actor uses some web site to make purchases
online.
Ramakant Soni @ BKBIET Pilani 20
online.
Top level use cases are:
•View Items,
•Make Purchase and
•Client Register.

21. Description:
Web Customer uses some web site to make purchases online. Top level
use cases are View Items, Make Purchase and Client Register.
View Items ( use case) could be used by customer as top level use case if
customer only wants to find and see some products. This use case could
also be used as a part of Make Purchase use case.
Ramakant Soni @ BKBIET Pilani 21
Client Register ( use case) allows customer to register on the web site.
Note, that Checkout use case is <<included>> use case not available by
itself.
checkout is part of make purchase.
Except for the Web Customer actor there are several other actors which
will be described below with detailed use cases.

22. Ramakant Soni @ BKBIET Pilani 22

23. View Items use case is extended by several optional use cases - customer
may search for items, browse catalog, view items recommended for
him/her, add items to shopping cart or wish list. All these use cases are
extending use cases because they provide some optional functions
allowing customer to find item.
Ramakant Soni @ BKBIET Pilani 23
Customer Authentication use case is included in View Recommended Items
and Add to Wish List because both require customer to be authenticated.
At the same time, item could be added to the shopping cart without user
authentication.

24. Checkout use case includes several required uses cases. Web customer
should be authenticated. It could be done through user login page, user
authentication cookie ("Remember me") or Single Sign-On (SSO).
Web site authentication service is used in all these use cases, while SSO also
requires participation of external identity provider.
Checkout use case also includes Payment use case which could be done
either by using credit card and external credit payment service or with
PayPal.
Ramakant Soni @ BKBIET Pilani 24
PayPal.

25. Ramakant Soni @ BKBIET Pilani 25

26. Example 4:
Credit card processing system
Purpose: Define major use cases for a credit card processing system (credit
card payment gateway).
Summary: The merchant submits a credit card transaction request to the
credit card payment gateway on behalf of a customer. Bank which issued
Ramakant Soni @ BKBIET Pilani 26
credit card payment gateway on behalf of a customer. Bank which issued
customer's credit card is actor which could approve or reject the
transaction. If transaction is approved, funds will be transferred to
merchant's bank account.

27. Credit card processing system description
Credit Card Processing System is a system under design or consideration.
Primary actor for the system is a Merchant’s Credit Card Processing System.
The merchant submits some credit card transaction request to the credit
card payment gateway on behalf of a customer. Bank which issued
customer's credit card is actor which could approve or reject the
transaction. If transaction is approved, funds will be transferred to
merchant's bank account.
Ramakant Soni @ BKBIET Pilani 27
Authorize and Capture use case is the most common type of credit card
transaction. The requested amount of money should be first authorized by
Customer's Credit Card Bank, and if approved, is further submitted for
settlement. During the settlement funds approved for the credit card
transaction are deposited into the Merchant's Bank account.

28. Credit card processing system description
In some cases, only authorization is requested and the transaction will not
be sent for settlement. In this case, usually if no further action is taken within
some number of days, the authorization expires. Merchants can submit this
request if they want to verify the availability of funds on the customer’s
credit card, if item is not currently in stock, or if merchant wants to review
orders before shipping.
Capture (request to capture funds that were previously authorized) use
Ramakant Soni @ BKBIET Pilani 28
Capture (request to capture funds that were previously authorized) use
case describes several scenarios when merchant needs to complete some
previously authorized transaction - either submitted through the payment
gateway or requested without using the system, e.g. using voice
authorization.

29. Credit card processing system description
Credit use case describes situations when customer should receive a refund
for a transaction that was either successfully processed and settled through
the system or for some transaction that was not originally submitted through
the payment gateway.
Void use case describes cases when it is needed to cancel one or several
related transactions that were not yet settled. If possible, the transactions
will not be sent for settlement. If the Void transaction fails, the original
Ramakant Soni @ BKBIET Pilani 29
will not be sent for settlement. If the Void transaction fails, the original
transaction is likely already settled.
Verify use case describes zero or small amount verification transactions
which could also include verification of some client's data such as address.

30. Ramakant Soni @ BKBIET Pilani 30

31. References:
[1] http://www.uml-diagrams.org/
Ramakant Soni @ BKBIET Pilani 31