Ya, that's pretty terrific. Having the diagrams paired with the code is a boon. My GoF study group (of mostly Java and C++ devs) spent way too much time divining how to "realize" (something short of implementation) the design patterns. I wish we had the SmallTalk version of these graphs.

Last year, I used the UML static object modeling notation for understanding and documenting an existing RDBMS schema. Also last year, I used some of the UML state modeling (or Harel Statecharts) for getting the UI right for a SwiftUI app. Earlier this year, I used DeMarco-Yourdon DFDs (but we can call it UML) for business process modeling. (And our director of marketing picked it up instantly, and even had an insight into some structure of the data flows between some processes, because of this formalism.) And I'll probably use UML imminently for a new schema, if it turns out to be nontrivial.

I used to use UML (well, OMT, but fortunately Rumbaugh's notation won over Booch's for UML) constantly, when I was doing lots of Java. I worked on high-end CASE and methodology, and on the side I made a convenient little tool to help go from OMT to Java, and keep it up-to-data (in conjunction with Rumbaugh's own OMTool): https://www.neilvandyke.org/jomtool/

One thing to know about these system analysis&design methodologies (before UML, there were maybe a dozen prominent ones) and their various diagrams is that the user bases seemed to change over time. If you were a technical developer of a large system, or maybe a certain kind of big embedded systems developer, you might use it. If you were a database architect, there was a different camp for that, and they had different needs and tools. At some point, maybe around the time that Java was adopted for corporate internal IS development, the UML I occasionally saw was usually simply as a way of visualizing class inheritance hierarchies (and summarizing their Java attribute and method signatures). Which is fine, but it's only a fraction of the benefit they could get from higher-level modeling and documenting, with even that one kind of UML diagram.

Not really, everybody is up to their own Heuristical Modelling Language, that is simply based on custom circles/rectangles. Shockingly, works pretty well (and faster to draw) if there's some context understanding between people who read the graph.

Apparently JPL uses Model Driven Development to build telescopes. There is an interesting presentation[0] which describes their setup to design and build the JPL Thirty Meter Telescope. They use SysML[1] and Jupyter to provide true model driven development, i.e., changes to models are propagated to the code.

[0]=https://www.youtube.com/watch?v=CshfBGrjdBU [1]=https://en.wikipedia.org/wiki/Systems_Modeling_Language

Just discovered plantuml and liked it - i can use some visual aid if only i do not have to draw it.

Sequence and use case diagrams are useful. Class diagrams i would rather see in code.

I also misuse use case diagrams for arbitrary graphs. It is good to see if a graph i came up with looks too much like spaghetti. Helps to untangle it. But it is not proper UML and i could use the graphviz dot itself for it without plantuml frontend.

I use it. Diagrams are easy to grasp especially when the alternative is lots of text. UML2 is a good specification IMHO. There are tools that let's you model your solution, which makes it easy to maintain it. https://www.omg.org/spec/UML/About-UML/

I generate them automatically from intellij otherwise it wouldn't be worth it. The UML notation is easily cryptic to the neophyte but it can sometimes help to give an overview.

The only pattern I regularly use is the Visitor pattern, which is very common in compilers these days. It's productive, but I'm still slightly worried when I use it because it seems to encourage relatively stateful code that doesn't compose properly. Writing a new visitor takes a while, so people also put too much in one visitor.

Yes, sequence, flux and class diagrams, all the time.

I rather do whiteboard UML than throw away code that costs money and no one is going to use.

ER for database modelling.

Same applies to UIs, Balsamiq with paper simulations, and click dummies, until everyone agrees what the GUI workflow should actually be like.

Using UML implies that someone is planning development more then a week ahead, be agile man, no plans, no docs and no time for unit tests.