Sequence diagrams, the only good thing UML brought to software development

It would be useful if everyone would at least be vaguely familiar with basic UML notation, i.e. action vs. object, multiplicity, connectors (association vs. composition vs. dependency vs. specialization, interface/implementation), class vs. instance, fork/join, swimlanes, etc. Otherwise you have to clarify over and over what means what in a diagram.

One powerful aspect of UML is that you can combine different diagram types. For example, you can use activity-diagram elements in parts of a sequence diagram.

For pragmatic use, “UML Distilled” [0] by Martin Fowler is a good introduction and reference.

[0] https://martinfowler.com/books/uml.html

> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually.

I completely agree with you.

It's a good way for other people to present information, for me to look at.

I just won't do it myself.

It's not only me; and that's why it's dead.

I won't do it because the first thing that comes to mind is how it will go out of date in a month, and have to be maintained to stay accurate.

Maybe in the not-too-distant future we will have AI grokking large code bases and cranking out accurate, useful, UML diagrams out of it.

All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey.

Thinking "the only good thing" is understandable, since there's a lot of noise, but that talk discourages people from learning a lot of good stuff that's buried.

Before UML, there were many methodologies. UML was started by a unified team of some of the most noted OO methodologists.

There was a lot of good thinking, but one of the adoption problems we had before UML (as tools developers and methodologists) was that many people got a poor introduction to it, and missed the whole point.

For example, on a diagram metamodel that emphasized formalizing and visualizing the relationships among objects... some people would think it was a TPS Cover Sheet task, to laboriously draw their class inheritance hierarchy and summarize their attributes and method signatures, for purely corporate bureaucratic reasons.

You could also contrast people who needed to build complex embedded system behavior, for whom Statecharts were a very valuable tool for keeping the model manageable -- distinguished from people who were told to do it when it wasn't appropriate, and they just kinda tried to document their code control flow by misusing that same diagram notation.

Today, I can't blame people for not understanding, since most examples they'll now see are incorrect noise, and the current UML spec itself doesn't do this reputation any favors.

Half-seriously, maybe we could use a reset, in which people who neither know or care what they're doing stop being required to go through the motions of pretending to do it. Also stop trying to have people who don't actually use it teach it to students who just want a good grade in the class (for their FAANG job application), and who have little-to-no experience necessary to appreciate the real thing. Also don't make it a marketable resume keyword. Then the only people who will be doing or talking about it are people who care enough to figure out the genuine merits, with no incentive to pretend.

Then, ideally, the only time others will see it is when someone whips out a formalized diagram for something complicated, and proceeds to start explaining it by walking the audience through the diagram... Some people in the audience will get the tingles, as they're not only understanding, but they're also sensing a very powerful modeling tool that would address some problems that they and their team have in their work. (Realistically, this would start to happen, but as soon as it becomes a resume keyword or interview ritual, history would repeat, but maybe that time with a larger mitigating mass of people who understand and appreciate.)

With any non-trivial set of messages, seq diagrams become unwieldy. Always use communication diagrams over sequence as a first choice.

People who say "UML is useless" basically say "diagrams are useless". Which obviously isn't true. The alternative to UML is everyone inventing their own "diagram language" when they want to visualize something.

Moreover, I think comparing different UML diagrams can also be enlightening for university students. E.g. state machine digrams look quite similar to activity diagrams, but the former emphasize states and the latter actions. And class diagrams let you learn the connection between class structures of OOP languages and database structures.

UML lets you visually learn the abstract higher level concepts without having to rely on irrelevant specifics of practical implementations, or just on dry theoretical text.