Fixing a Use Case Diagram: actor boundaries and generalization

Question

I am trying to create an use case diagram regarding an Scooter system. I already created the diagram, which you can find it in here: Use Case Diagram:

I got some comments regarding this diagram which were:

1. The system (or scooter provider) is not an actor. In fact, the system boundary indicated the system and in the use cases we describe how outside actors interact with the system.
2. Incorrect usage of generalization between the actors, for example, now gold members are also allowed to sign up.

How can I fix the diagram according to the comments?

---

Additional information: The requirements for the system are:

Upon opening the application, it shows available scooters near the guest's device. To access further features, the application requires guests to register an account or login. When logged in, users can select any of the available scooters and rent it. They will then make a ride and eventually stop and end the rental period. Besides this basic functionality, users have the option to upgrade their account to a Gold member account, which further allows them to reserve scooters in advance. In the remainder of this text you will find more details about the application that should be incorporated in your solutions. Not all steps are completely expanded, so you have some freedom to choose these details for yourself.

Before using any of the services of the app, customers must first create a user profile. This entails filling out some personal information (name, e-mail address, credit card information, etc.). In the following, we describe scenarios that are accessible to users that have successfully logged in using their accounts.

To start renting a scooter, users must scan the QR code sticker on the scooter itself. The app then checks the payment information and asks to enter new information if no payment information is present. When the payment information is ok, the scooter is unlocked and the user can start the ride. To end the ride, the user clicks a button in the app. The app then calculates a summary of the ride, showing the route taken, distance travelled, and a final price. In parallel, the scooter is locked again. The user can then proceed by authorizing payment using the provided credit card details, or selecting a different means of payment.

To become a gold member, users click a button and are then presented with an overview of the new features and costs. If agreed, the user may then proceed by the same process as before; authorizing payment using the provided credit card details, or selecting a different means of payment. Gold members may reserve scooters in advance. This process starts by selecting one on the map in the application, or by scanning the QR code of a scooter. The Gold member then selects to reserve the scooter for the next hour. During this time, it is no longer shown as available for other users.

Answer 1

The main problem in this diagram is that most of its use-cases are not really use-cases. Use-cases require interactions with an actor, and should correspond to actor goals. Most of the things you have in your diagram seem to be in reality features.

The ScooterProvider could be an actor if it would be:

• a human representative of the company, for example a clerk, a call-center operator. But I can hardly imagine a human interaction for every scooter rental made via an app.

• another system that contributes to the use-case. We could imagine here a specialized system that makes pricings and that interacts with the system under consideration. But looking at the overall picture, this appears not probable: I think you try to show here things that your system should do automatically. This is not the purpose of a use case diagram.

Rethink your use-cases in terms of goals: what are the different reasons a user may want to interact with your system? You'll obtain a reduced set which then better correspond to use cases. The remaining features are just specific requirements to be added in the use-case description.

Not knowing the requirements, it's difficult to advise on the actor generalization:

• Actor generalization means that the specialized actor can do everything what the general actor can do, and perhaps more.
• Actors are roles that the a user/system takes in the interaction. If some differences are not based really based on roles, better not show it with generalization; use constraints to explain in plain text that some conditions apply for a user to invoke the use case.
• Avoid generalization if some use cases would provoke a change of role in the middle, because this is utterly ambiguous.

Now with a the revised list of use-cases, you'd probably have less of such problems: once the discount disapears in a more general pay or check-out use-case, you'll no longer have to make difference between coupon and other users. Anyway, any user can suddenly remember to have a coupon in the pocket, or may decide to keep the coupon for a next ride: the coupon is really not actor-specific.

Edit, in view of requirements:

Elimination of coupon-user is confirmed ;-)

You have chosen an analysis viewed from the system: any user could probably use the system, but as long as not logged-in the system doesn't know about the kind of users and the possibilities are limited. If you take this approach, you'd have: guest (not logged-in), logged-in (normal) user, (logged-in) gold user.

Since only guests can create a new account with sign-up, the other actors cannot "inherit" from the guest. But the other actors would not log-in either, because they have their role only once they are already connected. A gold user is then necessarily a registered user.

Another approach is to look at the actor role independently of the system state. You'd then have: visitor (people who don't have an account at all), registered users (they have an account, but when they use the system they can log in) and gold users who are indeed necessarily registered users.

The fact that there is a special use-case reserve scooter that is only for gold members and that the gold-membership is bound to the actor (entitlement obtained through a payment) and not to a short-live temporary system state are two arguments that make the actor relevant and more appropriate than handling this status via a constraint.