It more or less unified a few notations that were already quite common or at least similar enough. There were two problems that it had: - it was over-engineere

It more or less unified a few notations that were already quite common or at least similar enough. There were two problems that it had: - it was over-engineered because model driven architecture people at some point got involved and there was this whole meta model that they came up with and unleashed some design by committee style processes on. This resulted in complex tools and companies like Rational Rose emerging; which promptly got acquired by IBM because they love complex stuff and the need for consulting that provides. I always joke that the wrong people got way too excited about this for the wrong reasons. - it coincided with the emergence of agile software processes, which de-emphasized the creation of a lot of up front design documentation, which is a waterfall thing to do. And there simply was no need for it over the course of a single sprint. Some companies still create diagrams to document stuff but mostly that serves very little purpose other than box ticking. But basically as companies switched to scrum, kanban, extreme programming, etc. they stopped using design tools and started using wikis, issue trackers, git, etc. These days the only design tools that are used are UI design tools like Figma. Software design mostly happens on white boards. That may or may not involve some box and arrow diagrams. Mostly those are talking points rather than detailed designs with little relevance beyond the meeting they are used in. With remote development now common; even whiteboards are not used that much any more. UML design tools are awful for their intended use. They are documentation tools and using them usually is a form of process bureaucracy: somebody insists on having diagrams. Usually not a software engineer. They are not useful as a design tool. Using them is fiddly and simply too slow. I can draft something on a whiteboard or on a bit of paper in seconds that would take a lot of time to do in a design tool. Instead of writing class diagrams, I'll actually stub out the classes and almost immediately start refactoring and renaming things; which is something that that UML tools don't support. Most UML diagrams state the bleeding obvious in either way too little detail or way too much detail. Neither is very useful. Complete waste of time creating these diagrams usually. But sometimes useful to impress the non technical people (We have stuff! It's amazing! Here's a pretty slide for you to look at.). I usually just wing it and maybe once a year sit down and do some boxes and arrows so I can put it in a slide.