Here is my use case. In this system, Organizer has more 'Right' than Supporter so he/she can use the Budget Management feature. So in this case, how can I show by extending from 'View Main Dashboard' use case, only Organizer can access Budget Management?
Asked
Active
Viewed 762 times
1
-
1I acknowledge that the arrow is in the wrong direction. – Programforlifeitf May 26 '21 at 17:20
-
1These are not use cases, and they should definitely not all be extending a single use case. Use cases are about added value to the actor, not functional decomposition. – Geert Bellekens May 26 '21 at 18:16
-
Once you come up with real use cases you can add constraints for the purpose you are asking for. – qwerty_so May 26 '21 at 23:08
1 Answers
4
Your use-case diagram tries to model the user interface, with a View main dashboard
that leads to different software functions such as Party control
and so on. This is not the way for use-cases. Instead:
- Each use-case should correspond to some higher level goal of some actors. THE goals should be independent of how the solution would look like. It's the same goals whether it's a text-based UI or a GUI, whether it's one single windows or multiple ones.
- Use-case diagram shall not represent any sequence. Your diagram shows some kind of sequence, first the dashboard and from there, party control. Use case diagram should never rely on any sequencing.
- Dotted arrows such as
«include»
and«extend»
are dependencies and not a sequential flow. By the way, extension should be the other way round: the target of the arrows is the use-case to be extended.
Let's igore those issues for the sake of answering your question; let's suppose you'd have only valid use-cases and dependencies. There is also a flaw in the actor inheritance:
- Is an organizer a supporter ? Well, may be that some persons who have an organizer role also act as a supporter. In this case you should consider keeping both actors completely independent: it's not about the persons, but about their roles.
- Your diagram tells another story: if
Organizer
is aSupporter
(inheritance, i.e. the arrow should be a big hollow triangle) it means that everyOrganizer
is always aSupporter
. - If there are goals that a
Supporter
has but not anOrganizer
, then you shouldn't use inheritance. Or if you do, create a pseudo-actor with the common goals and let each role be a specializations of the common denominator and adding the relevant goals. - If there are a couple of thing that the
Organizer
can do but not the theSupporter
, then you can keep it as it is, but add a link fromOrganizer
to the the more specialized goals.

Christophe
- 68,716
- 7
- 72
- 138