Search code examples
inheritanceumluse-caseuse-case-diagramstaruml

Inherited but exclude one use case


enter image description here

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?


Solution

  • 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 a Supporter (inheritance, i.e. the arrow should be a big hollow triangle) it means that every Organizer is always a Supporter.
    • If there are goals that a Supporter has but not an Organizer, 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 the Supporter, then you can keep it as it is, but add a link from Organizer to the the more specialized goals.