Name use cases using domain terminology.
Imply timing considerations by stacking use cases.
Place your primary actor(s) in the top-left corner of the diagram.
Draw actors on the outside edges of a use case diagram.
Name actors with singular, domain-relevant nouns.
Associate each actor with one or more use cases.
Name actors to model roles, not job titles.
Use > to indicate system actors.
Don’t allow actors to interact with one another.
Introduce an actor called “time” to initiate scheduled events.
Indicate an association between an actor and a use case if the actor appears within the use case logic.
Avoid arrowheads on actor-use case relationships.
Apply > when a use case may be invoked across several use case steps.
Apply > associations sparingly.
Generalize use cases when a single condition results in significantly new business logic.
Do not apply >, >, or >.
Avoid more than two levels of use case associations.
Place an included use case to the right of the invoking use case.
Place an extending use case below the parent use case.
Apply the “is like” rule to use case generalization.
Place an inheriting use case below the base use case.
Apply the “is like” rule to actor inheritance.
Place an inheriting actor below the parent actor.
Indicate release scope with a system boundary box.
Avoid meaningless system boundary boxes.