How to Draw

There are several approaches on how to draw UML use case diagrams. If you don’t know from where to start, try to follow the steps described here.

Define Subject

Subject is a business, software system, subsystem, component, device, etc. that we are designing or just trying to understand how it is working. It is very important to define what kind of system it is, and what is its scope or boundary. Give it a proper name, and use appropriate stereotype, e.g. «Business» or «Subsystem».
For example, we want to describe a Pharmacy, and it is not software pharmacy prescription system but actual pharmacy business. So, we will draw it as shown below, using «Business» stereotype.

«Business» Pharmacy as UML subject.
Another example of a subject shown below is Ticket vending machine, i.e. vending machine that sells and produces tickets to commuters. This kind of machine is a combination of both hardware and software, and it is only a part of the whole system selling tickets to the customers. So we will use «Subsystem» stereotype.

Ticket vending machine as UML subject.
Here are some other examples of UML subject name:

• Department Store
• Airport
• Automated Teller Machine (ATM)
• Point of Sale (POS) Terminal
• Online Travel Reservation System
• Electronic Prescription Service

By declaring a subject we are defining boundaries of the system, to be able to determine what or who is inside the system, and what or who is outside of it.

Define Actors

UML actor is some type, group or particular facet of users that require some services from the subject. Actor is an external entity, which could be a human user of the designed system, or some other system or device using our system.
For the Pharmacy business we defined above, Customer is an example of an actor. Customer uses services provided by pharmacy. Pharmacist working in the pharmacy is not an actor, he or she is part of the business and is usually called business worker.

Customer is a business actor for the Pharmacy business.
Ticket vending machine allows commuters to buy tickets. So Commuter is our actor in this case.

Commuter is an actor for the ticket vending machine.
Actors should have names according to the role they play in relation to our system. Examples of actor names (user roles):

• Supplier
• Passenger
• Receptionist
• Web Client
• Bank

• Payment Authorization System

  Define Use Cases

  Now as we defined the boundaries of the system that we are designing or analysing, and external users of the system, we need to define what do those users need from the system. Each use case specifies a unit of complete and useful functionality that the subject provides to the actor(s). Use case should reflect user needs and goals, and should be initiated by an actor.
  For the pharmacy customer a business use case would be to get some medicine. So we are adding Procure Medicines business use case. Business actor Customer participating in the business use case should be connected to the use case by association.
  
  Business use case Procure Medicines for the Customer
  of the Pharmacy business.
  The ultimate goal of the Commuter in relation to our ticket vending machine is to buy a ticket. So we are adding Purchase Ticket use case. Purchasing ticket might involve a bank, if payment is to be made using a debit or credit card. So we are also adding another actor - Bank. Both actors participating in the use case should be connected to the use case by association.
  
  Ticket vending machine provides Purchase Ticket use case
  for the Commuter and Bank actors.
  Top-level use cases should describe complete unit of functionality provided to the actor. Examples of use case names:

• Hire Employee

• Transfer Funds
• Find Book
• Make Travel Reservations

• Schedule Patient Appointment

  Describe Use Case Behaviors

  Use case behaviors may be described in a natural language text (opaque behavior), which is current common practice, or by using UML behavior diagrams for specific behaviors such as

• activity,

• state machine,
• interaction.

UML tools should allow linking behaviors to the described use case. Example of such binding of a use case to the behavior represented by activity is shown below using UML 2.5 notation.

Purchase Ticket use case owns behavior
represented by Purchase Ticket activity.
Purchase Ticket activity diagram example below describes behavior of the Purchase Ticket use case.

Example of Purchase Ticket use case behavior described using activity diagram.

https://www.uml-diagrams.org/use-case-diagrams-how-to.html