In a UML use-case diagram, what does generalization mean between two actors, and between two use cases?

## The notation, and why it looks different Generalization is drawn as a **solid line with a large hollow triangle** at the end touching the **more general** element. That is worth stating precisely, because a use-case diagram carries three inter-element relationships and two of them — include and extend — are dashed lines with small open arrowheads and a keyword. Generalization has no keyword, a solid line and a triangle. If you can only remember one thing under interview pressure, remember that the triangle points at the parent, the general thing, never at the specialised one. | Relationship | Line | Head | Points at | |---|---|---|---| | Generalization | Solid | Hollow triangle | The more general element | | Include | Dashed | Small open arrow | The included use case | | Extend | Dashed | Small open arrow | The base use case | ## Generalization between actors Between actors, the relationship asserts **substitutability of roles**: wherever the general actor can participate, the specialised actor can participate too. A payroll administrator drawn as a specialisation of an employee can do everything an employee can — submit a timesheet, view a payslip — and additionally has its own associations to administrative goals. The practical value is economy. Without it, an 11-person model with seven actors ends up drawing the same three association lines from four different actors, and the picture becomes a mesh nobody reads. With one triangle, those lines are drawn once. Things to be careful about: - **It is not an org chart.** A manager is not a specialisation of an employee because a manager is senior; the claim is only about which use cases the role can participate in. - **It is not a permission model.** Real authorisation is rarely a clean tree, and a diagram that promises inheritance the access rules do not implement will mislead readers. - **Inheritance is additive, not subtractive.** A child actor cannot remove a parent's associations. If the specialised role must *not* do something the parent can, the hierarchy is wrong and the two roles are siblings, not parent and child. ## Generalization between use cases Between use cases, the child is a **complete variant** of the parent: same overall goal, different way of achieving it, and substitutable wherever the parent appears. Paying an employee by direct transfer and paying by cheque are two whole flows that both satisfy "Pay an employee". This is far rarer than actor generalization, and the reason is worth being able to say aloud. A child use case must be a *whole* alternative flow, not an insertion. That is exactly what separates it from extend: - **Generalization** — the variant replaces the parent's flow, end to end, and satisfies the same goal a different way. - **Extend** — the base flow is unchanged and the variant inserts an optional chunk at a named point under a condition. - **Include** — nothing varies at all; the behaviour runs every time. When candidates reach for use-case generalization, the honest answer is usually extend, and saying so is a better signal than drawing the triangle. ## When not to draw it 1. **When the hierarchy has one child.** A parent with a single specialisation adds a symbol and no information; keep one use case and describe the variation in its flow text. 2. **When the variants differ only in data.** Paying in two currencies is not two use cases; it is one flow with a parameter. 3. **When the tree is deeper than two levels.** Readers stop tracing inheritance quickly, and a three-deep actor hierarchy costs more attention than it saves. 4. **When it exists to look thorough.** Under pressure to appear complete, teams add structure that no reader uses; a diagram earns each symbol by changing a conclusion. ## What an interviewer is checking This is a differentiator rather than a gate — almost nobody is turned down for not recognising the triangle. What it does reveal is whether you know the notation is *three* relationships rather than two, and whether you can keep them apart by their line style and direction rather than by guessing. The strongest answers add the restraint point: actor generalization earns its place by deleting duplicated lines, use-case generalization usually does not earn its place at all, and the substitutability test — can the child stand in wherever the parent is expected? — is what decides either case.