Nothing. Because UML was pointless to begin with.<p>As a medium to describe systems it was harder to understand that just a flowchart, and less specific than just reading the code code. A useless halfway house.
What replaced flowcharts? Um, pretty much nothing. We just quit making flowcharts, and we found that we could get by just fine without them. (In fairness, when structured programming replaced goto-based programming, we didn't need flowcharts nearly as often in order to keep track of what was going on.)<p>We mostly quit doing UML because for most people, most of the time, it mostly wasn't worth it. It didn't provide enough value to be worth the effort. So what replaced it was usually nothing.
On a related note - are there diagramming tools that let you draw (and write) freehand and then automatically neaten the diagram up?<p>I'm imagining something on an iPad or Android tablet that lets me just draw my usual boxes, circles, lines, terrible handwriting, and so on, and then I can punch a button and get it as a draw.io (or whatever) compatible diagram...?<p>The Newton handheld had some abilities along this line in the mid nineties so it seems like it shouldn't be an impossible dream.
Checkout the C4 model (<a href="https://c4model.com" rel="nofollow">https://c4model.com</a>) if you're looking for a easy but detailed method to describe your software architecture. I my experience it works well in teams, you can let any dev contribute since there are only a handful of rules/notations.
The key problem with UML was that it was trying to work on a too low a level, essentially replacing code with diagrams, which didn't really work. The only UML diagram that is still relevant today is the sequence diagram, because it has just the right balance between being too abstract and being too specific.<p>In my experience, the best approach in documenting software systems is the C4 model: <a href="https://c4model.com/" rel="nofollow">https://c4model.com/</a>
It's been a while since I've done a class diagram, but I still use sequence diagrams to coordinate non-trivial component interactions. Occasionally, I'll use a state diagram to describe workflow. More commonly, I've used ad-hoc network diagrams to describe the architecture of a system. I think flowcharts are still useful.
Nicely specced TTD style tests can show and then also verify that things work as you might expect them to.<p>They can serve as example and documentation on how the architectural pieces fit together in a piece of software.<p>That plus high level, loosely specced diagrams can encapsulate most simple/medium complexity apps.
Interested to hear any answer, my opinion is nothing has. However I think this is a struggle of the domain UML solves, as I am not too sure UML ever established itself as a goto diagram/modelling language?