The user of my app has access to two tools within my app. Each tool is comprised of multiple tables that the user has to fill with information.
The app is more complex but that's roughly what's it's about.
This is the UML Diagram that I have designed based on the app:
enter image description here I am wondering whether the use case diagram should be designed otherwise. Maybe, I should design the use case diagram for each tool independently. That way, it will be less cumbersome.
But, this will mean that each tool represents its own system. And I don't know if from a UML viewpoint, that is the right thing to do.

  • I kinda like this diagram. Everything is on one page, an overall high-level glance. Aug 12, 2019 at 15:46
  • Beware of the "too complicated" comment from others and from yourself. If it is the first thing out of their mouth then immediately walk away. I recall such a "too complicated" assessment but guess what? It was a real joy to code because the class design was complete, fully covering requirements, use cases, and relationships. Conversely I saw, on the same project, "not too complicated" turn into a big ball of mud
    – radarbob
    Aug 12, 2019 at 21:44
  • Sorry if I may sound rude, but where are the real use cases in your diagram ? “utiliser”, “remplir”, “visualiser” are description of a user interface and not at all of the user goals. Furthermore “extends” mean that the base use case would still make sense without any of its extensions which is not true in your diagram. Have a look at qwerty_so’s answer and reading recommendation. Consider user goals independently of user interface: “describe risk” (includes ...), “analyse risks”, ...
    – Christophe
    Aug 16, 2019 at 7:26

2 Answers 2


Use case diagrams are always a bit weird. These diagrams tend to have the following use cases:

  • showing an index of all use cases in a system
  • showing how some use cases relate to each other
  • showing how some actors/users interact

If your goal is to show all use cases, then yes, that will necessarily get a bit messy. Your diagram is fine!

Alternatively, you might notice that the two main use cases “analyze risks” and “resilience management” seem entirely disconnected, so you could split them into separate diagrams.

Models such as UML diagrams are just a simplified view of reality. Every model has some goal or viewpoint. It is necessary to prioritize, arrange, and even omit information in order to communicate the goal clearly.

  • Definitely you should order the last bullet above at first rank! And I strongly disagree that UC diagrams are weird. It's probably just the editors creating weird versions.
    – user188153
    Aug 13, 2019 at 6:33

What you are starting with your UCs is a functional analysis. (My french isn't good enough to decipher it, but I'm pretty sure about that.) That's plain wrong. UCs are about added value, not single functions of a system. The fact that you are using <<extends>> all over clearly indicates that. Focus on only those bubbles that show delivery of added value.

As always I recommend to read Bittner/Spence about use cases. The best read you can find (or rather I found).

P.S. One anecdote I remember: "When your UC diagrams start resembling a spider web your design is likely broken". This holds true for all cases I've seen so far.

  • With my French I can confirm your excellent diagnosis: all these « extends » are functional decompositions. Worse: the verbs “remplir” and “visualiser” suggest that it could even be a user-interface specification, i.e. something that should really not be done with UC !
    – Christophe
    Aug 16, 2019 at 7:12
  • @Christophe I was merely guessing that. Thanks for the confirmation!
    – user188153
    Aug 16, 2019 at 7:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.