Ask HN: Do you still use UML?

The 3 actually useful diagrams that I have seen in the last 10 years are:

- Sequence

- Entity relationship

- State chart

All 3 are useful for communicating protocols, schemas and state charts.

Sequence diagrams are probably the most ubiquitous, and very useful in explaining protocols. Even RFC-s have them.

Relationship diagrams are often (ab)used to visualize relationships between tables in SQL databases. While it's not very useful for designing, I have actually used them for understanding and simplifying a complicated database schema. I actually believe every API documentation should start with an abstract entity relationship diagram. Abstract in the sense that it should not necessarily represent physical tables, but give an overview of the underlying structure to the first time user. Doesn't even have to complete or correct.

State charts are occasionally useful for obvious reasons. Try explaining TCP without one.

I think it's worth noting that the above 3 existed before UML and UML merely tried to formalize them, so while I don't think anyone uses "UML" anymore, being able to comprehend the above 3 charts is as basic of a skill as being able to read pseudo-code, and saying they are not is use would also be false.

Edit: formatting

The best way to make sure your diagrams map to code, is to generate your diagrams and the code from a common piece of text.

At a job not too long ago, we used a modified form of DOT to describe a protocol state machine. This generated dot, .h's, and some template .c files. This made it such that each state machine for the protocol had a diagram that would map out all the states. Logging and other subsystems output were generated as well so you could go from a log of a test run back to a diagram of what had run.

Code generation (or compilers for compilers) are entirely underrated outside of Lisp, and they're not too difficult to create.

EDIT: And note that your linked presentation is AWESOME, but I think he misses the description / guidebook being up to date is best accomplished by having it be what needs to be updated to create the software.

We used Enterprise Architect.

Indeed, I only use UML for documentation of existing code. Having a standard allows for consistent reverse-engineering, and a class diagram is still the best way to visualize an OOP class hierarchy.

Keeping them up to date with the code is an issue, as with all documentation. I actually wrote my own Java class diagrammer [1] for that purpose so I can just re-run a project file to create updated diagrams of the current code base, with little or no editing required.

[1] http://kynosarges.org/Diagrammer.html

Usually I diagram the very high level architecture of the program. Anything lower is to volatile and wouldn't reflect the design due to code changing all the time.