如何修正滑板车系统Use Case Diagram？解决Actor边界与泛化误用问题

Alright, let's walk through exactly how to fix your use case diagram based on the feedback and system requirements you've shared. I'll break this down into clear, actionable steps so you can adjust it properly.

Step 1: Remove the System/Scooter Provider Actor #

The feedback correctly points out that the system shouldn't be an Actor—your system boundary already represents the system itself.

• Delete any "System" or "Scooter Provider" Actor from your diagram entirely.
• All use cases live inside the system boundary rectangle, and only real human Actors sit outside it: Visitor, User, and Gold Member. Every use case now explicitly represents an interaction between an external Actor and the system (e.g., the Visitor asks the system to show nearby scooters, the system responds).

Step 2: Fix the Actor Generalization Relationship #

The current setup where Gold Member can perform "Register" is logically broken—here's how to fix the inheritance:

• The correct generalization is Gold Member → User (draw the generalization arrow from Gold Member to User, pointing to the parent class). Gold Members are a subset of Users: they have all the same capabilities as regular Users, plus exclusive features like scooter reservations.
• Visitor is a separate, standalone Actor (no generalization to User). Visitors are unregistered/unlogged-in users; they can only become Users by completing the "Register" or "Login" use cases. This fixes the logical issue of Gold Members being able to register (since they're already registered Users).

Step 3: Map All System Requirements to the Corrected Diagram #

Now let's align every system requirement to the right Actor and use case, ensuring no gaps or logical inconsistencies:

Actors & Their Associated Use Cases #

All use cases live inside the system boundary. Connect Actors to use cases with standard association lines.

• Visitor (Unregistered/Unlogged-in User)

  • View Nearby Available Scooters: Opens the app and sees nearby scooters (no login required)
  • Register Account: Fills in name, email, credit card info, etc., to become a User
  • Login Account: Uses existing credentials to access User-level features

• User (Logged-in Regular User)

  • Inherits View Nearby Available Scooters (logged-in users can still see scooters)
  • Rent Scooter: Scans a QR code, system validates payment info, then unlocks the scooter
  • End Rental & Complete Payment: Taps an app button, system generates ride summary (route, distance, total), locks the scooter, and user completes payment
  • Upgrade to Gold Member: Reviews benefits and fees, confirms payment, and becomes a Gold Member

• Gold Member (Upgraded User, generalized from User)

  • Inherits all use cases from User
  • Reserve Scooter: Selects a scooter via map or scans a QR code to reserve it for 1 hour; the scooter is hidden from other users during the reservation

Quick Diagram Best Practices #

• Use the generalization arrow (open arrowhead) from Gold Member to User to show inheritance of all User use cases.
• Don't connect Actors to use cases they can't logically perform: e.g., Visitors can't rent or reserve scooters, Gold Members don't need to register.
• Keep the system boundary clear—all use cases must sit inside it to represent interactions with the system.

内容的提问来源于stack exchange，提问作者Ornela