3

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:

enter image description here 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.

Christophe
  • 68,716
  • 7
  • 72
  • 138
Ornela
  • 31
  • 3
  • The comments already tell you what you did wrong. There are more bugs in that UC diagram. Without knowing the requirements, nobody here can help you. – qwerty_so Sep 19 '20 at 16:06
  • Hi, I edited the question again including the requirements. – Ornela Sep 19 '20 at 16:29
  • Since you got an answer: `Log in` is no use case since it doesn't add value. It's a constraint you apply to certain use cases. – qwerty_so Sep 19 '20 at 20:22

1 Answers1

3

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.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Hi, I edited the question again including the requirements. The problem is that each of the use case diagram do have interactions with the actors as also explained in the requirements. However, I also think that the system cannot be an actor, but I was thinking of writing TIME as an actor, describing the time necessary for each of the features to be realized. – Ornela Sep 19 '20 at 16:33
  • Hi again, thank you very much for your answer. You were quite helpful. I wanted to ask you one last question. Is it wrong if for the Actor "Scooter Provider", we can do it : <> Scooter Provider? So the Actor in this case would serve the role of Authentication. – Ornela Sep 19 '20 at 17:31
  • @Ornela if you would have an external system that that intervenes in the authentication process, this system-actor could contribute to a login use-case. And it's role as actor could be justified because the use-case also contributes to the goal ot that other system. However you would call it `Authentication service, not `Scooter provider` and it would be exernal to your system. According tot the requirements, all the things in which `Scooter provider` is involved, is in reality things that YOUR system shall do. It's in your system, not outside of it. ANd therefore it can't be an actor – Christophe Sep 19 '20 at 18:08