It is very useful to illustrate a facet of a system - how four components interact, how something is meant to be deployed, the state machine used to make certai

It is very useful to illustrate a facet of a system - how four components interact, how something is meant to be deployed, the state machine used to make certain decisions, network communication, and so on. UML 2's concept of a core set of primitives that are used to build out a whole bunch of different kinds of diagrams was inspired. It was a shame that they didn't "just" do that. That is because once you start trying to generate diagrams from code, or code from diagrams, you no longer are doing illustrations but are making accurate/constrained views of the system. A class diagram built from running through C++ header files is often less useful than a textual table of the classes themselves. It is distinctly less useful than someone actually writing up a page or two of text to explain how the parts of the system are related. UML shines when it is used to graphically illustrate such an explanation. Things like Model Driven Architecture were doomed because the complexities of the system still have to be created, whether in a set of text files or a set of 2d pictures. Once all of the informational complexities are there, there's no benefit to an illustration. I find doing UML diagrams promotes the needs of other stakeholders earlier. Similar to how doing TDD winds up encouraging an architecture which is more testable, early UML diagrams (for me) tends to encourage a more explainable, domain-driven design. I would say that the negative for UML is that it sometimes tends to promote more object-oriented designs, where internal concepts and external interfaces may be created and maintained with more formality than otherwise needed. That might just be conflating bad habits at the time where it was most popular, however.