Exactly. The sane use-case for UML is as a visual aid to help one human to communicate something they know about some code to another human being. It's a visual

Exactly. The sane use-case for UML is as a visual aid to help one human to communicate something they know about some code to another human being. It's a visual summary of something. For this purpose "boxes and circles with lines and arrows between them, and text in or next to them" is fine. We don't even need different arrowheads to differentiate "owns"/"consists of"/"inherits from" - a piece of text next to the arrow that says "inherits" is fine (if actually needed and not obvious from the context). Heck, different arrows can mean "inherits from", "displays data from" and "sends a network request to" all within the same diagram, and most humans will pick up on that just fine It seems some people wanted to turn this into a visual programming language instead, and thus kept adding details to the specification to make that possible. But it's not a very good visual programming language. Compare to something like Scratch, or Bubble or Unity ShaderGraph or Unreal Blueprints for examples of what actually usable (though still far from perfect) visual programming could look like. The problem is, by adding all this detailed specification, they actually made UML worse as a product, because it actually makes it harder to use for the first use case, sketching, because suddenly the receiver has to have all this existing knowledge of the protocol to receive what's being communicated. Thankfully most people ignore all that and just stick with boxes and arrows and text, and it works just fine.