In a UML use-case diagram, what does the system boundary assert, and what counts as an actor?
answer
- It draws a line around scope
- Two sides: outside and inside
- Roles, never named individuals
- Not every actor is a person
- Move one across, change the commitment
basics
~20 sThe system boundary separates what you are building from everything outside it: use cases sit inside, actors outside. An actor is any external role that interacts with the system — a person, another system, or a scheduled trigger.
solid answer
~50 sA use-case diagram asserts two things at once. The **system boundary** — the rectangle drawn around the use cases — declares scope: everything inside is behaviour this system commits to provide, everything outside is somebody else's. An **actor** is a role, not a named individual; one person can play two actors and two hundred people can play one. Actors are external by definition, so anything you could open a ticket to change is not an actor. Non-human actors are first class: another system that calls you, a service you call in turn, or a clock that fires scheduled behaviour. The **primary actor** is the one whose goal the use case serves; **supporting actors** are pulled in to help satisfy it. Most of the diagram's value is the boundary argument — move one use case across the line and you have changed what the team agreed to deliver.
code
pseudocode · 16 linessystem boundary: "Payroll Platform"
inside the boundary (use cases):
Run monthly payroll
Submit a timesheet
Correct a paid payslip
outside the boundary (actors):
Employee --- Submit a timesheet
Payroll Administrator --- Run monthly payroll
--- Correct a paid payslip
Tax Filing Service --- Run monthly payroll <<system>>
Month-End Clock --- Run monthly payroll <<system>>
note: plain lines, no arrowheads - association says
"participates in", not "sends data to"go deeper
Be ready to recall the four marks — actor, use case, boundary, association — and to say that actors are outside and use cases inside. Knowing that an actor is a role, and that it need not be human, is most of the answer at this level.
Explain the mechanics: primary versus supporting actors, why an association has no arrowhead, and why anything you can change is inside the boundary. An interviewer expects you to catch a diagram that shows an internal component as an actor.
Show that you use the boundary to settle real scope arguments — what a team signs up for when a use case moves inside, and how you handle an external party you must integrate with but cannot change. Judgment about where the line goes is the point.
Own the tradeoff of where the boundary sits across several systems at once: which obligations you accept, which you push to a neighbour, and what that costs in coordination. Be able to say when a boundary is drawn for organisational reasons rather than technical ones.
## What the diagram is actually claiming A use-case diagram carries almost no notation. There are **actors**, **use cases** drawn as ovals, the **system boundary** drawn as a labelled rectangle around the use cases, plain **association** lines joining an actor to a use case, and three relationship types between elements. Because so little is drawn, nearly all of the meaning lives in *where* something sits relative to one line. That line is the point. The boundary declares: everything inside is behaviour **this** system commits to provide; everything outside is a party we talk to but do not build. An association from an actor to a use case says only "this actor participates in this goal" — it carries no data direction, no sequence and no ordering. Two engineers can agree on every use-case name and still disagree completely, because they drew the rectangle in different places. When a review argues about whether archiving payslips belongs to the payroll platform or to a separate document system, that argument *is* the diagram's content. ## What counts as an actor An actor is a **role played by something outside the system while it interacts with the system**. Three consequences follow, and interviewers probe all three. - **Roles, not individuals.** One person may play two actors — the office manager who both submits her own timesheet and approves everyone else's is two actors, an employee and a payroll administrator. Conversely, two hundred people may play one actor. Naming individuals on the diagram is a beginner tell. - **External by definition.** If you can open a ticket to change it, it is inside the boundary and cannot be an actor. A module the team owns, a table it writes to, a background job it schedules — none of these are actors. The most common single mistake is drawing the team's own storage as an actor because "the system talks to it". - **Not necessarily human.** Another system that calls you, a service you call to satisfy a goal, and time itself are all legitimate actors. Non-human actors are conventionally drawn as a labelled rectangle with a stereotype rather than a stick figure, and a time-triggered actor is what you use when a goal starts with nobody present. | Candidate | Actor? | Why | |---|---|---| | The person who submits a timesheet | Yes, primary | External role whose goal the use case serves | | A tax-filing service you send returns to | Yes, supporting | External, participates, not built by you | | A month-end clock that starts a payroll run | Yes, supporting | Time-triggered start with no human present | | The payments module inside your own system | No | Inside the boundary; it realises use cases | | The database your service owns | No | Implementation detail, not an external party | | A named colleague in the finance team | No | Individuals play roles; model the role | ## Primary and supporting actors The **primary actor** is the one whose goal the use case exists to satisfy — the one who would be dissatisfied if the use case did not exist. **Supporting actors** are pulled in to help complete it. The distinction drives naming: a use case is named from the primary actor's side, in that actor's language, not in the language of the system's internals. "Run monthly payroll" is named from the administrator's side. "Invoke the tax-rate lookup" is named from the code's side and is not a use case at all. Some teams also record an **offstage** interest — a party who cares about the outcome without interacting, such as an auditor. The notation has no symbol for that; it belongs in the written use-case text, not on the diagram. ## Using the boundary as an argument This diagram survives in interviews long after most modelling has faded because it settles a scope argument fast, in a picture anyone can read. In practice: 1. **Draw the boundary first**, before any use case, and label it with the exact deployable thing you are scoping. 2. **List the actors next**, human and non-human, because they force the question "who else has to exist for this to work?" 3. **Add use cases last**, and for each one ask whether the primary actor would go home satisfied when it completed. 4. **Re-run the argument when priorities move.** On an 11-person team under a founder who reprioritises weekly, the boundary is the cheapest artefact to redraw and the fastest way to show what a newly promised obligation displaces. ## Where it goes wrong - Leaving the boundary rectangle off entirely, which turns the diagram into an unscoped bubble chart. - Adding arrowheads to actor associations to imply data flow or call direction — the notation does not mean that. - Placing internal components inside the boundary as though they were use cases. - Modelling one human twice under two personal names instead of once per role. - Treating the diagram as documentation to be completed rather than an argument to be settled. An interviewer asking this is not testing whether you can draw an oval. They are testing whether you can state what is in and what is out of a piece of work, and defend the line you drew.
- The same person submits their own timesheet and approves everyone else's. How many actors is that?Two. An actor is a role, not a person, so that individual appears on the diagram once as an employee and once as a payroll administrator. Modelling them as one actor would attach approval use cases to everybody who can submit a timesheet, which is the wrong claim about who may do what.
- You must integrate with a service another company runs. Inside or outside the boundary?Outside, as a supporting actor. You cannot change it, so it is not behaviour you commit to build. What goes inside the boundary is your use case that talks to it, plus any adapter behaviour you own. Drawing it inside is how teams accidentally sign up to somebody else's roadmap.
- Does an association line between an actor and a use case say who starts the interaction?No. The association carries no direction, no data and no sequence — it means only that the actor participates. Initiation is expressed by naming the primary actor in the written use case, and by the drawing convention of placing primary actors on the left and supporting actors on the right.
The boundary is passport control: inside is territory you are responsible for, outside are visitors and neighbouring states you deal with but do not govern. Who queues at the desk is a role, not a particular traveller.
saying these in an interview costs you the question
- Says an actor must always be a human user
- Draws a module or database the team owns as an actor
- Treats actors as named individuals rather than roles
- Thinks the boundary rectangle is decoration and can be omitted
- Adds arrowheads to actor associations to show data direction
- Cannot say what changes when a use case moves across the boundary