I used to work heavily in this kind of system modeling (developing tools for it, and dogfooding), and still use it when high-value for figuring out or communicating an aspect of a system.
Here's a challenge, to help appreciate the nature of these: try to find an error in the diagrams.
It's usually harder than you might think, since, even when you know the notation and metamodel semantics, it's information-dense talking about a domain.
You usually have to know or learn a lot about the domain, and/or have an domain expert you can walk through it exhaustively, before you can find errors.
And an error can be whopper: a single graph edge missing, or between the wrong vertices, or with the wrong adornments can have huge implications.
For example, large amounts of work that have to be redone, or a project abandoned, or a mess that takes 10x longer than it should to write, and 10x the tech debt going forward with a bad architecture, or a fundamental security flaw.
One of the mistakes many people make is treating formalized diagrams as "marketecture" visuals, like they only need for handwaving sales presentation slides, where there's some kind of visual for every concept they want to be able to literally point to.
Nope, if you have software engineers and domain experts communicating and reasoning about your system in only the fuzzy terms of sales/exec presentations, you're really stabbing yourself in the face.
ak_111 4 hours ago [-]
What happened to UML? I remember it was everywhere in enterprise computing 20 years ago but seems to have disappeared now.
Is it still around or did it go the way of SOAP, Java Applets? If not, what has replaced it?
dcminter 4 hours ago [-]
I'm kind of hazy about where the boundaries between bona fide UML and PlantUML are, but PlantUML is in pretty common use in my world - more for sequence diagrams and state diagrams than class diagrams though. Of course PlantUML has competition from things like Mermaid, but they're all much of a muchness.
My very non-scientific impression is that tools like Rational were mostly used for drawing class diagrams and ... that just turned out not to be that useful because the tooling didn't exist to round-trip changes in the code back into the diagrams meaning the diagrams lost parity with the code rather quickly. It was sort of useful in the linear design/code/deliver world, but we're a lot more iterative now.
afpx 1 hours ago [-]
I remember having to use Rational Rose back in the day, and I had to ask my boss why because the software crashed and the files got corrupted all of the time. If it didn’t help them write better software, why were we using it?
That said, I still find plantuml to be helpful, particularly for sequence and activity diagrams. With LLMs especially. Use dependency injection, fine granularity components, sequence and activity flows. At least for me, helps keep my mind organized. But, these days I work alone. I feel it may be too dated for the modern developer.
nickthegreek 4 hours ago [-]
I just learned about UML earlier today when I wanted to bring in a mermaid flowchart into lucidchart. If you bring in mermaid using lucidchart, it makes it a raster image. But if you use UML markup, you can ungroup it and modify. I couldn’t get a good way to convert from mermaid to UML markup that lucidchart could handle. Ended up a dead end for me.
dcminter 3 hours ago [-]
On a similar note I've had various annoyances with wanting to round trip diagrams from Mermaid or PlantUML into Miro and vice versa. There doesn't seem to be much out there to facilitate this, which is strange, because it feels like a very enterprisey thing to want to do.
There's probably a SaaS product in it for someone sufficiently interested in the topic... probably not at unicorn scale, but enough for a side income perhaps?
I love it. Even with GML, you run into problems. Diagramming is an art more than a science. You have to know your audience (technical people, marketing types, investors, customers...)
Leaving stuff out is also important. (Example: Unless you're building a DNS related product, don't bother to include "DNS" in your diagrams. Your use of it is assumed.)
oleggromov 2 hours ago [-]
This is wonderful. Thank you.
zabzonk 4 hours ago [-]
Just my opinion, but I think that folks realised it was not much use for initial design, but could work reasonably well for documentation of existing systems.
devenson 3 hours ago [-]
Documenting existing system dependencies using the product which which I'm a founder:
Like UML deployment diagrams, but our models are interactive and can be queried.
We also have a large customer doing DDD modeling and then generating code directly from the models they build.
riffraff 4 hours ago [-]
UML as a methodology seems to have disappeared, but bits of it (e.g. sequence diagrams) seem to have been absorbed by the profession at large.
ramon156 4 hours ago [-]
We still learned UML diagrams in school in 2019, though I have to say I haven't used it anywhere in my job
neilv 4 hours ago [-]
In the case of UML, I think enterprise consulting and tool sales might've already obscured much of the real value of semiformal methods, before a CS curriculum could sour students on it.
With ZIRP growth scheme startups hopefully over, and more of us having to get jobs building systems that work reliably and sustainably, we might gain a new appreciation for system modeling.
4 hours ago [-]
NBJack 4 hours ago [-]
Just another data point that the "low code/no code" revolution sputtered out over a decade ago.
I still see and use a small subset of UML for more complex architecture discussions, but that's about it (i.e. service nesting, message passing, etc.).
ohgr 2 hours ago [-]
UML never matched reality and this isn’t really an engineering discipline even if we pretend it is.
You can really break UML by specifying a system then changing it a number of times. That process will hurt you. Badly.
titaphraz 3 hours ago [-]
UML was a scam really. They took a lot of very useful diagrams and created a absolute behemoth of unproven system to develop software and sold it.
The diagrams are very nice and useful. But the UML as a process, if taken literally, it a total disaster.
hmartin 2 hours ago [-]
> UML was a scam really.
Objectively and utterly wrong.
alganet 2 hours ago [-]
Good UML is really simple UML.
"Then what about complex things? Can't make everything simple"
Do partial diagrams. Simplify or skip things your team already knows.
Also, great UML is no UML. Sometimes the code itself is short and clear enough, requiring no diagram (of course, not all diagrams are about code... but use case diagrams are rare these days anyway).
Also, use cases and use case diagrams are great.
Also, perfect UML is disposable. Thinking of long term diagrams that serve as documentation is a mistake.
firesteelrain 2 hours ago [-]
These diagrams make a lot of sense if you understand the symbols and the relationships plus aggregations. You can easily talk to them. I use these diagrams with non technical people all the time
throw_m239339 3 hours ago [-]
It's useful to convey architectures. The problem is that UML has been abused by some vendors that implemented bad software based on "Rapid UML Development" and it soured a lot of developers. Also it is very old java OO oriented. But Sequence diagrams are still in use.
dcminter 2 hours ago [-]
OO yes, but not Java particularly. I was using Rational tools with C++ projects well before Java was getting any visibility.
karlgkk 4 hours ago [-]
Apropos of nothing, all of the major ai models have gotten really good at turning a pdf or document into uml
Not great, mind you. 80% of the way there still saves an hour of your time tho
fuzzer371 2 hours ago [-]
How about we ditch the AI slop
wpollock 1 hours ago [-]
Have you noticed that at the bottom of every HN comment page is an ad for AI Startup School?
Rendered at 00:47:37 GMT+0000 (Coordinated Universal Time) with Vercel.
Here's a challenge, to help appreciate the nature of these: try to find an error in the diagrams.
It's usually harder than you might think, since, even when you know the notation and metamodel semantics, it's information-dense talking about a domain.
You usually have to know or learn a lot about the domain, and/or have an domain expert you can walk through it exhaustively, before you can find errors.
And an error can be whopper: a single graph edge missing, or between the wrong vertices, or with the wrong adornments can have huge implications.
For example, large amounts of work that have to be redone, or a project abandoned, or a mess that takes 10x longer than it should to write, and 10x the tech debt going forward with a bad architecture, or a fundamental security flaw.
One of the mistakes many people make is treating formalized diagrams as "marketecture" visuals, like they only need for handwaving sales presentation slides, where there's some kind of visual for every concept they want to be able to literally point to.
Nope, if you have software engineers and domain experts communicating and reasoning about your system in only the fuzzy terms of sales/exec presentations, you're really stabbing yourself in the face.
Is it still around or did it go the way of SOAP, Java Applets? If not, what has replaced it?
My very non-scientific impression is that tools like Rational were mostly used for drawing class diagrams and ... that just turned out not to be that useful because the tooling didn't exist to round-trip changes in the code back into the diagrams meaning the diagrams lost parity with the code rather quickly. It was sort of useful in the linear design/code/deliver world, but we're a lot more iterative now.
That said, I still find plantuml to be helpful, particularly for sequence and activity diagrams. With LLMs especially. Use dependency injection, fine granularity components, sequence and activity flows. At least for me, helps keep my mind organized. But, these days I work alone. I feel it may be too dated for the modern developer.
There's probably a SaaS product in it for someone sufficiently interested in the topic... probably not at unicorn scale, but enough for a side income perhaps?
[0] https://wiki.c2.com/?GalacticModelingLanguage
Leaving stuff out is also important. (Example: Unless you're building a DNS related product, don't bother to include "DNS" in your diagrams. Your use of it is assumed.)
https://schematix.com/video/depmap
Like UML deployment diagrams, but our models are interactive and can be queried.
We also have a large customer doing DDD modeling and then generating code directly from the models they build.
With ZIRP growth scheme startups hopefully over, and more of us having to get jobs building systems that work reliably and sustainably, we might gain a new appreciation for system modeling.
I still see and use a small subset of UML for more complex architecture discussions, but that's about it (i.e. service nesting, message passing, etc.).
You can really break UML by specifying a system then changing it a number of times. That process will hurt you. Badly.
The diagrams are very nice and useful. But the UML as a process, if taken literally, it a total disaster.
Objectively and utterly wrong.
"Then what about complex things? Can't make everything simple"
Do partial diagrams. Simplify or skip things your team already knows.
Also, great UML is no UML. Sometimes the code itself is short and clear enough, requiring no diagram (of course, not all diagrams are about code... but use case diagrams are rare these days anyway).
Also, use cases and use case diagrams are great.
Also, perfect UML is disposable. Thinking of long term diagrams that serve as documentation is a mistake.
Not great, mind you. 80% of the way there still saves an hour of your time tho