Copyright 2007 Isotope28

Purpose

Steps

Heuristics

Artifacts

   The use case diagrams illustrate the behavioral requirements of the product from a business perspective. The use cases seek to identify the behaviors the product must satisfy for the each of the identified stakeholders that interact with the product. The use case diagram is the starting point for the remainder of the analysis and design effort.

  1. 1. Begin with a blank UML use case diagram.

  2. 2. Add the title and date / version to the bottom of the diagram.

  3. 3. Add the main application box to the center of the diagram, and label with the same text as used for the product on the application context diagram.

  4. 4. Consider each of the stakeholders that interact directly with the product.

  5. 5. Add the stakeholders as actors to the diagram outside of the system box.

  6. 6. Consider the behaviors required of the product to satisfy the needs of each stakeholder. As needed, check the behaviors for consistency with the stakeholder profiles.

  7. 7. Add the behaviors as use cases (ellipses) inside the box. Provide suitable verb or verb phrase names for the use cases.

  8. 8. Attach each of the stakeholders involved in a use case with a single line (protocol).

  9. 9. If the number of use cases exceeds reasonable complexity (7 +/- 2), consider refactoring the use cases onto separate diagrams using abstractive decomposition.

  1. • Limit the number of use cases to 7 +/- 2 per page. If the number grows beyond this, consider refactoring a set of common use cases onto another diagram and replacing them on the main diagram with an abstract use case. Ensuring the name of the sub-use case diagram exactly matches the abstract use case name for traceability. Use the UML subsystem icon (pitchfork) to indicate the existence of the new diagram with more detailed use cases. Abstractive decomposition is the preferred technique.

  2. • Limit the use of the includes relationship between use cases to keep the behaviors simple and easy to understand.

  3. • The use cases at this level represent business behaviors and must avoid solution domain concepts.

  4. • Avoid functional decomposition when refactoring, instead preferring abstractive decomposition.

  5. • For any sufficiently complex use case model (more than a few diagrams), consider using nested decimal notation to facilitate traceability and identification between your diagrams.

  6. •Note that the numbers do NOT infer order, and are only provided for traceability. Once  a number is assigned to a use case, it should not be changed or reused.

Use Case Diagrams (Example 1, Example 2)