• 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 you know exactly when to invoke the use case.

  • 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.

  • ]]>