1

I have a question related to Use Case diagram for a mobile app and charging.

So let's say My use case is Set Charging mode. Charging mode can either be Immediately or Scheduled Later. What Relationship should be between the Set Charging Mode UC and the two different options?

I have thought about using Generalization but I am not 100% sure this is correct.

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
Emil
  • 11
  • 1
  • An option is not a use case, I'm not even sure if `Set Charging Mode` is worth to be a use case. Use cases represent user goals, not functions your app provides. – Geert Bellekens Nov 08 '21 at 18:37

2 Answers2

3

Not knowing much about your context, I nevertheless understand that "Set charging mode" is not really a user goal: it's not a set of behaviors with observable results of value for the user. As such it should not be a use case.

In principle, "Set charging mode" would be part of the description of the real use case (e.g. getting something for which the user will be charged). Or maybe you'll specify the expected behaviors in a separate activity diagram.

If I'd be wrong, or if despite the advise you'd opt for a use case, the use case should require a choice, and a mutually exclusive one. This would be part of description of the use case Set charging mode, or indicated as a comment for the use case.

If I'd still be wrong and if you'd really really want to show two use cases, you could indeed either have two specific extensions to the choice or consider specialization. However, from your description, I still understand that these use cases would not be independent (Set charging mode or Set charging mode to later make no sense on their own). Moreover they seem far too detailed for a use-case. I'd therefore really advise not to follow this way keep UC for the big picture and avoid getting lost in details better documented elsewhere.

Christophe
  • 68,716
  • 7
  • 72
  • 138
1

To complete Christophe's answer, you have to keep in mind 2 things (at least):

  1. the purpose of a use case diagram is to help you in the specification of the problem and later in programming
  2. UML does not define a level of granularity for a use case except the famous 'observable and tangible goal' but to help you, keep in mind that a use case is detailed with an activity diagram (among others). In your case, the corresponding activity diagram would contain ONE action
Alan Allen
  • 71
  • 5