Actors & Use Cases

Actors & Use Cases

Every system exists to serve someone or something outside itself. Before you draw a single diagram, you must answer two questions: Who interacts with the system? and What does the system do for them? These questions are answered by identifying actors and use cases — the two building blocks of every UML use case diagram.

What Is an Actor?

An actor is any entity that interacts with the system from outside the system boundary. Notice three things in that definition. First, an actor is outside the system — actors are never part of what you are building. Second, an actor interacts — it sends information to or receives information from the system. Third, an actor is an entity — it can be a human role, an external system, a device, or even a timer.

UML represents an actor as a stick figure with a label beneath it. The label names the role, not the person. A single user named Ahmed might play the roles of Patient and Administrator depending on context — those are two separate actors.

Primary vs. Secondary Actors

Actors fall into two categories that shape how you read and draw the diagram:

• Primary actors are the ones who initiate use cases to achieve their own goals. They are the reason the system exists. In a clinic booking system the Patient is a primary actor — the patient books an appointment to get medical care, and that goal drives the entire booking workflow.
• Secondary actors (also called supporting actors) assist the system in delivering the service but do not initiate the interaction. A Payment Gateway is a secondary actor — it does not decide to process a payment; it only responds when the system calls it. Similarly a Notification Service sends confirmation emails only when triggered internally.

Identifying Actors from Requirements

When you read a requirements document or interview stakeholders, ask these trigger questions to surface actors:

1. Who provides data to the system or receives results from it?
2. Who manages or administers the system?
3. What external systems does this system communicate with?
4. Is anything time-triggered (a scheduler that runs nightly reports)?
5. Who benefits from each function the system performs?

For a public library system those questions might yield: Member (borrows books), Librarian (manages the catalog and loans), External Catalog Service (provides bibliographic data), and Email Service (sends overdue reminders). That is four distinct actors, each with a different relationship to the system.

What Is a Use Case?

A use case describes a specific goal that an actor achieves by interacting with the system. It captures a complete unit of valuable behavior — not a single button click, and not a vague mission statement, but a purposeful interaction that delivers a result the actor cares about.

UML represents a use case as an ellipse containing a short verb-phrase label. Good labels are action-oriented: Book Appointment, Search Catalog, Process Payment, Generate Monthly Report. Poor labels are either too granular (Click Submit Button) or too broad (Manage System).

Identifying Use Cases from Requirements

Once you have your actor list, derive use cases by asking: What goal does this actor pursue when interacting with the system? Each distinct goal is a candidate use case. For the clinic booking system:

• Patient can: Book Appointment, Cancel Appointment, View Appointment History, Receive Reminder
• Doctor can: View Daily Schedule, Update Availability
• Receptionist can: Register Patient, Book Appointment on Behalf, Confirm Walk-in
• Email Service (secondary): Send Confirmation, Send Reminder

Notice that Book Appointment appears for both Patient and Receptionist — a single use case can be associated with multiple actors.

The System Boundary

The system boundary is a rectangle drawn around all use cases. Its name (the system name) appears at the top. Actors sit outside this rectangle. The boundary makes explicit what is inside the scope of what you are building and what is considered external infrastructure. This matters enormously in project scoping: a Payment Gateway outside the boundary means your team is integrating with an external service, not building a payment processor.

Clinic Booking System — Full Use Case Diagram

The diagram below assembles all of the elements discussed: primary actors on the left, secondary actors on the right, use cases inside the system boundary, and association lines connecting each actor to the use cases it participates in.

Reading the Diagram

When you examine a use case diagram, read it systematically:

1. Find the system boundary — the rectangle tells you what is in scope.
2. Identify each actor — note whether it is a human role or an external system.
3. Read each use case — the ellipses are the goals the system supports.
4. Trace the associations — each line means "this actor participates in this use case."

Online Store — A Second Example

To reinforce the technique, consider a simplified online store. Primary actors: Customer and Store Manager. Secondary actors: Payment Gateway and Shipping API. Use cases include: Browse Products, Add to Cart, Place Order, Track Shipment, Manage Inventory, Generate Sales Report, Process Payment, and Dispatch Shipment. The diagram below shows how to organize these elements.

Common Actor Mistakes to Avoid

• Treating departments as actors. "Finance Department" is not an actor. The role of Finance Manager is. Actors must be a role played by a person or external system, not an organizational unit.
• Creating actors for every individual. If 50 customers all do the same things, there is one actor called Customer, not 50 actors.
• Forgetting system actors. Beginners often omit external systems (payment gateways, email services, ERP integrations). These are legitimate actors with association lines, just like humans.
• Putting actors inside the boundary. If it is inside the rectangle, it is not an actor — it is part of the system you are building.

Summary

• An actor is any entity outside the system boundary that interacts with the system. It can be a human role, an external system, or a device.
• Primary actors initiate use cases to achieve their own goals; secondary actors support the system in responding to those goals.
• A use case is a goal-level description of a complete interaction between an actor and the system, shown as an ellipse with a verb-noun label.
• The system boundary rectangle defines scope: everything inside is built by your team; everything outside is external infrastructure.
• Identify actors by asking who provides data, who receives data, who administers the system, and which external systems the system communicates with.