Applying Use Case Diagrams: Parking Lot System

Let's apply use case diagram principles to design a Parking Lot System. This demonstrates how to identify actors, extract use cases from requirements, and model relationships.
Requirements: The system manages vehicle parking. Customers can find spots, park vehicles, and pay fees. Attendants can issue tickets and assist with parking. Admins can generate reports and configure pricing. The payment gateway processes transactions.
Parking Lot System - Use Case Diagram
Parking Lot System
Customer
Attendant
Admin
Find Parking Spot
Park Vehicle
Pay Parking Fee
Process Payment
Issue Ticket
Generate Report
Configure Pricing
Payment
Gateway
Lines represent associations. "Pay Fee" <<includes>> "Process Payment" (highlighted)
Key Relationships:

Association: Customer connects to Find Parking Spot, Park Vehicle, and Pay Parking Fee

<<include>>: Pay Parking Fee includes Process Payment (always required)

<<include>>: Park Vehicle includes Issue Ticket (mandatory action)

Shared Use Case: Both Customer and Attendant can initiate Issue Ticket
Interview Tip: When identifying actors, ask "Who initiates this action?" not "Who benefits?". The Payment Gateway is an actor because it actively processes payments, even though it's a system. Similarly, a scheduled job that generates nightly reports would be an actor.
Design Decisions Explained:
First, Why is Process Payment a separate use case? Payment processing is complex enough to warrant its own use case. It's included by Pay Parking Fee because every payment requires processing. However, if Y (the payment gateway is unreliable), then you might model Retry Payment as an extending use case that handles failures.
Second, Why can both Customer and Attendant issue tickets? This reflects real-world scenarios where automated kiosks (Customer) and manned booths (Attendant) both provide tickets. The system must support both interaction modes.
Third, Should Exit Parking be a separate use case? Yes, if it involves validation and barrier control. But if it's just a consequence of payment, then it can be part of the Pay Parking Fee workflow. This depends on business requirements.

💡 Key Takeaways

✓Identify actors by asking who or what initiates interactions with the system

✓Extract use cases from requirements as verb phrases representing user goals

✓Use <<include>> for mandatory sub-functionality that's always executed

✓Place shared use cases (like Issue Ticket) where multiple actors can initiate them

✓External systems (Payment Gateway) are actors if they actively participate

✓System boundary clearly separates what's inside vs outside the system

📌 Examples

1Customer finds available spots and parks vehicles independently

2Attendant issues tickets manually at entrance booth

3Payment Gateway processes credit card transactions as external system actor

4Admin configures hourly rates and generates occupancy reports

← Back to Use Case Diagrams Overview