Actor Generalization in Use Case Diagrams (UML in Visio)
When one kind of user can do everything another can, plus more, use actor generalization. Learn the hollow triangle arrow and which way it points, with a hotel booking system drawn in Visio.
Step by step
- Actor generalization. A Loyalty Member can do everything a Guest can, plus a bit more. A use case diagram shows this with actor generalization. Here it is drawn in Visio for a hotel booking system.
- UML Use Case stencil. All the shapes come from the UML Use Case stencil in the Shapes pane.
- The set-up. First, drop a Subsystem shape for the system boundary and label it Hotel Booking System. Drop an Actor on the left, outside the boundary, and name it Guest. Drop a Use Case inside the boundary and name it Book room. Join Guest to Book room with an Association connector. This plain line means the actor takes part in that use case. Add a second Use Case called Cancel booking. Connect Guest to Cancel booking with another Association.
- The special actor. Drop a second Actor below Guest and name it Loyalty Member.
- Generalization. Draw a Generalization connector from Loyalty Member to Guest. The hollow triangle sits at Guest, the general actor. Read it as "a Loyalty Member is a Guest".
- Only the extra. Loyalty Member inherits Book room and Cancel booking, so don't draw those lines again. Add only what is new: a Use Case called Redeem points. Connect Loyalty Member to Redeem points with an Association. Guest has no line to it, so a normal guest can't redeem points.
- Done. Click an empty part of the page to deselect everything and see the finished diagram: 2 actors, 3 use cases and 1 generalization.
- The rule. The rule: the triangle points at the general actor, and the special actor only gets lines to its extra use cases. This keeps the diagram clean and shows developers who may do what.
Common mistakes
- The arrow points the wrong way. The line starts at the special actor (Loyalty Member) and the hollow triangle ends at the general actor (Guest). If you can't read it as "a Loyalty Member is a Guest", flip the connector.
- Drawing the inherited lines again. Don't connect Loyalty Member to Book room or Cancel booking. The generalization already gives it those use cases. Extra lines only clutter the diagram.
- Using an Association between the actors. A plain line between 2 actors doesn't mean one is a kind of the other. Use the Generalization connector, which has the hollow triangle.
- Using generalization when one role can't do everything the other can. Generalization means the special actor can do all of the general actor's use cases. If a role is missing even one of them, draw its own associations instead.
When a business analyst uses this
In a requirements workshop for a customer portal, stakeholders list Customer and Premium Customer as roles. A Generalization from Premium Customer to Customer, plus lines only to the premium use cases, shows the extra features on 1 clean page. Developers can then use it to set up role permissions before sign-off.
Questions people ask
What is actor generalization in a use case diagram?
It shows that one actor is a special kind of another and can do everything the general actor can, plus more. It is drawn as a solid line with a hollow triangle pointing at the general actor.
What is an actor in a use case diagram?
An actor is a role outside the system that uses it, such as a Guest. It can be a person or another system. It is drawn as a stick figure and joined to its use cases with association lines.
Is actor inheritance the same as actor generalization?
Yes. The special actor inherits all the use cases of the general actor, so you only draw lines from it to the use cases that are new for it.
