Iconic notations exist to describe all manner and form of reality and technical specification.
The first "goal" of UML was to eliminate and consolidate the free-range software development notations. And that was something that could have turned into something useful.
UML's attention turned to code generation and no-code paradigms that will take generations of refinement to ever be useful in complex environments. Diagramming notations were contorted to serve the goal of code generation instead of programmer utility.
The consequence was that programmers were denied anything personally useful about UML and instead were saddled with a soul-sucking, task master of a tool that never fulfilled the business community's no-code expectations. The kicker was that now the development staff needed to untangle the no-code, generated code to make it work. What's to like?
We still have diagramming tools that create and work with the useful parts of UML in reasonable ways, we just needed to jettison the no-code weight that was dragging the notation into dead ends.
> The other ambiguity is what we mean by UML. First of all, UML consists of over a dozen different diagram types. I still see people regularly use sequence diagrams. Second, there’s many different ways people use UML diagrams. Martin Fowler, a prominent figure in both the UML and Agile worlds, identifies three types of uses: sketching, blueprinting, and programming.
Then they talk explicitly about blueprinting.
It may be useful, but aside from sequence diagrams I rarely see anyone using it; its not just CASE that has died but the wider field of systematic analysis and modeling has declined in relative importance. Not having a good model of how it fits into short-iteration development workflows that eschew big upfront design seems to be the main cause.
And for what remains of that space, there are newer tools occupying some of it.
The former is alive and well, after shedding a lot of the fiddly details and requirements that the bits of the diagram be expressed in low-level details. Case in point: association vs aggregation vs. composition in class diagrams. All three express a similar idea by having a line joining the two classes: this class and this other class work together. But for aggregation and composition, one end of the line is supposed to have a diamond. Which end? Should the diamond be open or closed? What about multiplicity? Which end of the line has the number? It depends, sometimes both.
But all that detail, while sometimes useful to people looking at the diagram, really only matters for the benighted folks who try to make their UML diagrams input into code generators.
Forget "UML is dying", accept that CASE tools will never be more than fancy and fiddly code generators, and use the general ideas around diagramming, including some UML syntax, as a way to communicate among team members and stakeholders who are sufficiently technical.
1. https://news.ycombinator.com/item?id=26934577
p.s. Don't use quotation marks for emphasis. Ever. It's wrong.