UML Use Case Diagrams - Lecture Notes

Introduction

• Instructor: Collin
• Topics covered: Systems, actors, use cases, relationships
• Objective: Build a use case diagram for a banking application

Use Case Diagram Overview

• Purpose: Simplify complex ideas for easier communication
• Elements: Shows the system, actors, interactions, and basic workflow

Tools for Diagramming

• Pen and paper or diagramming software
• Recommended Application: Lucidchart (free to use)

Main Elements of Use Case Diagrams

1. Systems

• Definition: What you’re developing (e.g., website, app, business process)
• Representation: Rectangle with system name at the top
• Example: Banking app
  • Actions inside the rectangle happen within the banking app
  • Actions outside do not

2. Actors

• Definition: Entities that use the system to achieve goals (e.g., people, organizations, external devices)
• Representation: Stick figure
• Example:
  • Primary actor (initiates): Customer using the banking app
  • Secondary actor (reacts): Bank providing information
• Placement:
  • Primary actor: Left of the system
  • Secondary actor: Right of the system
• Categorization: Actors should represent types (e.g., customer, bank) rather than specific individuals or organizations

3. Use Cases

• Definition: Actions accomplishing tasks within the system
• Representation: Oval shape
• Placement: Within the system rectangle
• Example: Actions for a banking app
  • Log in
  • Check balance
  • Transfer funds
  • Make payments
• Guidelines:
  • Start with verbs, sufficiently descriptive
  • Logical order (e.g., Log in at the top)

4. Relationships

• Definition: How actors interact with use cases
• Representation: Lines (solid or dashed) with arrows
• Types of Relationships:
  • Association: Basic interaction
    • Example: Customer log in
  • Include Relationship: Dependent actions (always happens)
    • Example: Log in -> Verify password
    • Representation: Dashed line, arrow towards included use case, label ";<<include>>"
  • Extend Relationship: Conditional actions (sometimes happens)
    • Example: Log in -> Display login error (only if incorrect password)
    • Representation: Dashed line, arrow toward base use case, label ";<<extend>>"
  • Generalization: Inheritance (parent and children use cases or actors)
    • Example: Payment methods (Pay from checking, Pay from savings)
    • Representation: Arrow from child to parent
• Notes:
  • Multiple base use cases can point to the same included/extended use case
  • Extension points provide detailed paths (e.g., setup profile with options)

Building a Use Case Diagram

• Example System: Banking app
• Steps:
  1. Identify system boundary (rectangle labeled "Banking App")
  2. Identify primary and secondary actors (stick figures for Customer and Bank)
  3. List use cases (e.g., Log in, Check balance)
  4. Draw relationships (solid lines for associations)
  5. Add dependencies (include and extend relationships)
  6. Generalize where applicable (parent and child use cases/actors)
  7. Include extension points for detailed paths

Additional Resources

• Visit Lucidchart’s example library for more diagrams
• Resource link: training.lucid.co