What is an Actor?
An actor is any entity that interacts with the system from the outside. Actors initiate use cases, respond to system events, or exchange information with the system. They represent roles that users or external systems play when using your software.
Important: an actor is not a specific person — it's a role. One person might play multiple actors (e.g., someone can be both a "Customer" and an "Admin"). And an actor doesn't have to be human — it can be an external system, a timer, or a hardware device.
Types of Actors:
1. Primary Actor
──────────────
Initiates the use case to achieve a goal.
"Customer places an order" → Customer is primary
2. Secondary Actor
────────────────
Provides a service or responds to the system.
"System sends email" → EmailService is secondary
3. External System
────────────────
Another software system that interacts with yours.
"Payment processed by Stripe API" → Stripe is external
4. Timer/Clock
────────────
Triggers events at specific times.
"Daily report generated at midnight" → Timer is actor
Examples for an E-commerce System:
┌────────────────────────────────────────────────┐
│ Actor │ Type │ Interacts When │
├────────────────────────────────────────────────┤
│ Customer │ Primary │ Browses, buys │
│ Admin │ Primary │ Manages system │
│ Warehouse │ Secondary │ Fulfills orders │
│ Payment Gateway│ External │ Processes payment│
│ Email Service │ External │ Sends emails │
│ Backup Timer │ Timer │ Nightly backups │
└────────────────────────────────────────────────┘Identifying Actors
To find actors, ask these questions about your system:
1. Who uses the system?
→ Customers, administrators, support staff
2. Who provides data to the system?
→ Data entry clerks, external APIs, sensors
3. Who receives output from the system?
→ Managers (reports), customers (notifications)
4. What external systems does the system interact with?
→ Payment gateways, email servers, databases
5. Who maintains the system?
→ System administrators, DevOps engineers
6. Are there scheduled events?
→ Timers, cron jobs, batch processorsOnce you've identified candidates, validate them. A good actor should have at least one use case — if it doesn't interact with the system at all, it's not an actor.
Actor Generalization
When multiple actors share common use cases, you can use actor generalization to model the relationship. The child actor inherits all use cases from the parent and may add its own.
Actor Generalization Example:
┌──────────────┐
│ User │ (base actor)
│ │
│ • Login │
│ • Logout │
│ • Update │
│ Profile │
└──────┬───────┘
│
┌────┴────┐
▼ ▼
┌──────────┐ ┌──────────┐
│ Customer │ │ Admin │
│ │ │ │
│ • Browse │ │ • Manage │
│ • Buy │ │ Users │
│ • Review │ │ • View │
│ │ │ Reports │
└──────────┘ └──────────┘
Both Customer and Admin can login/logout/update profile.
Customer adds: browse, buy, review.
Admin adds: manage users, view reports.Use Case Diagrams
A Use Case Diagram is a UML diagram that shows the actors, use cases, and their relationships. It provides a high-level overview of the system's functionality.
UML Use Case Diagram Notation:
Actor: Stick figure
┌───┐
│ │
└─┬─┘
│
Use Case: Oval with name
┌──────────────┐
│ Use Case │
└──────────────┘
System Boundary: Rectangle
┌──────────────────────────────┐
│ System │
│ │
│ ┌────────────────────────┐ │
│ │ Use Case │ │
│ └────────────────────────┘ │
└──────────────────────────────┘
Associations: Solid lines connecting actors to use cases
«include»: Dashed arrow with «include» label
«extend»: Dashed arrow with «extend» label
Generalization: Solid arrow with hollow triangleComplete Example: Hospital Appointment System
┌────────────────────────────────────────────────────────┐
│ Hospital Appointment System │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Make │ │ Cancel │ │
│ │ Appointment │ │ Appointment │ │
│ └────────┬─────────┘ └────────┬─────────┘ │
│ │ │ │
│ ┌────────┴─────────┐ │ │
│ │ Check Doctor │ │ │
│ │ Availability │ │ │
│ │ «include» │ │ │
│ └──────────────────┘ │ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ View Medical │ │ Prescribe │ │
│ │ Records │ │ Medication │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Manage │ │ View │ │
│ │ Appointments │ │ Reports │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
└────────────────────────────────────────────────────────┘
▲ ▲ ▲ ▲
│ │ │ │
┌──┴───┐ ┌────┴─────┐ ┌────┴────┐ ┌────┴────┐
│Patient│ │ Doctor │ │ Admin │ │System │
└──────┘ └──────────┘ └─────────┘ │(Timer) │
└─────────┘Writing Use Case Descriptions
For each use case in your diagram, write a detailed textual description. This is where the real value lies — the diagram is just an overview; the text captures the behavior.
Use Case: Make Appointment
────────────────────────────────────
Primary Actor: Patient
Scope: Hospital Appointment System
Level: User Goal
Preconditions:
• Patient is logged into the system
• At least one doctor is available in the system
Main Success Scenario:
1. Patient selects "Make Appointment"
2. System displays available departments
3. Patient selects a department
4. System shows doctors in that department with their schedules
5. Patient selects a doctor and preferred time slot
6. System checks doctor availability
7. System confirms the appointment
8. System displays appointment confirmation with details
9. System sends confirmation SMS/email to patient
Extensions:
5a. No available slots in desired timeframe:
→ System suggests next available slots
→ Patient can accept or choose a different doctor
6a. Doctor becomes unavailable between selection and confirmation:
→ System shows error and asks patient to select again
7a. System fails to create appointment:
→ System logs error and displays retry message