Use case diagram

Main ideas / lessons (Use Case Diagram)

Purpose of a use case diagram

• To represent the system and clearly show the services/functional capabilities the system provides.
• Emphasizes “what” the system does, not “how” the processes are implemented.
• Helps communicate understanding between:
  • Technical team and business owners
• Supports:
  • Requirements gathering
  • Testing planning
  • Project planning
• Serves as an easy summary of:
  • System behavior/services available
  • Who/what interacts with each service (actors and their roles)

Core diagram structure

• System boundary: drawn as a square/container that holds the use cases.

• Use cases: drawn as circles or ovals; each represents a service/operation (e.g., “Book an appointment”, “Inquire about balance”).

• Actors (external parties):

  • Positioned outside the system boundary
  • Can be people, other systems, or organizations
• Communication/association links:
  • Actors connect to use cases using lines to show interaction/participation in providing the service.

---

Methodology / how to draw a use case diagram (step-by-step)

1. Step 1: Define the system being modeled

   • Decide the “box” (system boundary) that contains all use cases.
   • Only one system should be diagrammed per diagram.

2. Step 2: List services as use cases

   • Inside the system boundary, create use case circles/ovals for each service the system provides.

   • Name use cases clearly, typically using verb phrasing (e.g., “Book an appointment”).

   • Avoid overly broad names like “Hospital administration” when a single use case can’t capture the internal scope.

3. Step 3: Identify actors (outside the system boundary)

   • Add actors that interact with the system services.
   • Actor types include:
     • Primary actors (people/roles such as patient, receptionist, etc.)
     • Service/system providers (systems that provide services, e.g., Absher for identity verification)
     • Off-stage actors (benefit from output but don’t directly interact, e.g., reports/receipts/messages)

4. Step 4: Connect actors to relevant use cases

   • Use a line between an actor and a use case to show participation in that service.

5. Step 5: Represent dependencies between use cases

   • Use Include and Extend relationships (both are necessary for clarity).

---

Relationship rules: include vs extend (detailed)

1) <<include>> (mandatory dependency)

• Meaning
  • The parent use case cannot be completed unless the included child use case is performed.
• Diagram implication
  • The parent use case depends on the included use case.
• Example
  • “Book appointment” cannot be completed without identity verification → identity verification is <<include>>d.

2) <<extend>> (optional behavior)

• Meaning
  • The child use case is optional; it may or may not occur depending on conditions.
• Diagram implication
  • The parent use case still works even if the extending behavior does not happen.
• Example
  • Sending confirmation to a mobile phone is optional → it is <<extend>>ed.

---

Naming and design best practices / do’s and don’ts

Do

• Keep diagrams focused:
  • one system per diagram
  • Prefer splitting if needed: try not to exceed ~15 use cases per system in one diagram.
• Keep actors outside the system boundary.
• Name use cases clearly:
  • Use verbs (e.g., “Book an appointment”, “Cancel an appointment”)
  • Avoid overly generic phrases that can’t fit into one use case cleanly.
• Use include and extend to show what is:
  • essential (include) vs optional (extend)
• Keep to minimal necessary detail:
  • Focus on availability of services, not internal implementation steps.

Don’t

• Don’t connect actors to each other; actors should connect to use cases only.
• Don’t include unnecessary internal components (e.g., databases or internal services not required for understanding external behavior).

---

Speakers / sources featured

• No specific named individual speaker is identified in the subtitles.
• Example external systems/actors mentioned:
  • Absher (identity verification)
  • Ministry of Health
  • Ministry of Hajj
  • System administrator (as an example actor)
• Example domains mentioned (as systems being modeled or scenarios):
  • ATM system
  • Appointment booking system
  • Password verification service
  • Identity verification / reporting (receipts/messages)