> and in many case you also somewhat want something which is less precise (and verbose) then UML theoretically is
This tends to be "the" big problem with UML (and similar): Very few people care about, or have a reason to, stick 100% to UML. They want to "speak diagrams", and just like written or spoken language, our syntax and semantics is context dependent and dependent on the dialect and speech patterns and understanding of those we speak to.
So the "UML" people learn is often a dialect of sorts closer or further from the formal grammar, and a lot of tools fail to take that into account and try to force you into conformity. We accept that for programming languages, yet we still use pseudo-code in all kinds of contexts, but diagrams are one step up - one of the things we "escape to" when writing formal code is too complex or we want to explain things to people who don't know or care about the details.
There's a significant strain there between those conflicting goals of diagrams as communication, and the evolution of CASE tools that wants diagrams to be formal, that is much closer to how we deal with natural languages (people arguing over formal use vs. slang) than with programming languages, and it's fascinating.
It’s a pity, because one benefit of UML would be that everyone speaks the same language. Before UML, there were many different modeling notations [0], and the goal with UML was to create a single interoperable unified language. This was successful insofar as it displaced the previous object modeling languages. However, it would be nice to have that benefit of a modeling lingua franca not only in modeling tools, but for casual usage as well.
Yes, but the problem of this thinking is that when communicating we inherently look for shortcuts and shaping language to the context rather than sticking strictly to a grammar and a dictionary, and to be successful at defining a natural language (and that includes diagrams) you need to accept that the job is 90% describing reality and 10% trying to shape it. If that.
UML has been reasonably successful where it described reality, or tried to gently shape things by proposing things that were close to how most people already did things. Much less so where it tried to prescribe a reality not aligned with how people communicates, or where it has not kept up with the way that has evolved. It'd be more successful at being a lingua franca if the focus was more on documenting how people actually use diagrams, and just provide gentle nudges in one or the other direction where use is inconsistent.
I think this is also why so many people hate UML tooling - because it forces you to communicate in this strange dialect that is very different from how most of us communicate with diagrams, and that most people find awkward.
I think the problem comes from the difference between "modelling" as in the CS field of modelling and diagram generation for documentation purpose.
They are fundamentally two different use-cases which just seem similar if you ignore all the subtle but important details.
But UML tries to bridge both by having something you roughly could describes of "layers" of details.
But for documentation, especially tutorials, well suited diagrams aren't often just simplified by omitting/grouping details or similar. They are often simplified in ways which makes them subtle wrong in ways anyone getting started with the software can ignore and (hopefully) a foot note about this wrongness.
And most times for most people it's only ever used for less formal diagrams instead of "proper modelling". And more often for on-boarding/tutorial documentation then for deep technical documentation.
UML sucked so much, it took OOP down the drain along with it. Unfortunately, UML also had to contaminate nascent BPM modeling, by making BPMN a fscking "profile" of UML. I'll never forget the look of once motivated process modelers when they learned they need "stereotypes" and such - the result of their modeling was more like a psychoanalysis and beyond useless. Ever had to deal with RMI, EMF, MOF, and UML's weird and unsound meta-modelling "in itself" for exchanging model data modulo the worst of XML? To hell with it.
This tends to be "the" big problem with UML (and similar): Very few people care about, or have a reason to, stick 100% to UML. They want to "speak diagrams", and just like written or spoken language, our syntax and semantics is context dependent and dependent on the dialect and speech patterns and understanding of those we speak to.
So the "UML" people learn is often a dialect of sorts closer or further from the formal grammar, and a lot of tools fail to take that into account and try to force you into conformity. We accept that for programming languages, yet we still use pseudo-code in all kinds of contexts, but diagrams are one step up - one of the things we "escape to" when writing formal code is too complex or we want to explain things to people who don't know or care about the details.
There's a significant strain there between those conflicting goals of diagrams as communication, and the evolution of CASE tools that wants diagrams to be formal, that is much closer to how we deal with natural languages (people arguing over formal use vs. slang) than with programming languages, and it's fascinating.