Is it still around or did it go the way of SOAP, Java Applets? If not, what has replaced it?
Is it still around or did it go the way of SOAP, Java Applets? If not, what has replaced it?
Good diagrams are an art form though, just like other forms of good documentation. There is a big difference between a diagram being a normative source of truth, and being a good tool.
Take this diagram as an example: https://takaakit.github.io/uml-diagram-for-ddd-example-in-ev...
* Nearly the top half is taken up by relations which aren't especially helpful, and would be better expressed on the entities themselves.
* The "Location" type looks like the primary type in the system based on nearly half the types in the system connecting with it, creating a nest of graph edges. However, this is likely a simple and immutable record type. If the entities in this diagram had attributes (e.g. like a class diagram), you could refer to it by name, and greatly simplify the cognitive load in understanding this picture.
This is the sort of diagram that gets generated from code, and is at the level of specificity needed to generate code from a diagram. It also isn't very useful for using the model to convey the system to a person - a developer might be more comfortable reading the code rather than looking at a picture generated from it.
IMHO, that split focus in UML between people and tooling greatly reduced the overall usefulness and understanding of the system. It gave UML a bad reputation. Training on MDD tools prevailed over providing a baseline of common nomenclature to enable "team cave drawing on a whiteboard", which has no commercial tooling or market other than the whiteboard and markers.
The areas where visual languages have a bit more prevalence are on the business modeling side, including things like network architecture diagrams.
It is a bit of a shame - going through a set of use cases while iteratively improving the architecture by improving a set of class, sequence and ECB diagrams is something I always found to be crazy efficient vs diving immediately down to prototype code.
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.
> I feel it may be too dated for the modern developer.
Sounds like you're still ahead of the curve, worry not.
I'm still too much of a curmudgeon to even give LLMs a try.
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?
Had an intern a year ago whose school forced them to go the whole nine yards with UML. Our company gave them a project to build, and their school made them draw use-case diagrams, class diagrams, sequence diagrams, and activity diagrams, before the student was allowed to write any code.
This was a waste of everyone's time, and we gave the school some choice feedback which I'm sure they'll ignore.
Sequence diagrams are still used quite a lot, and for good reason, they're incredibly useful. I see simple class diagrams quite frequently as well, but without the poorly designed arrow nonsense (shaded? open? closed? argh!).
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.
You can really break UML by specifying a system then changing it a number of times. That process will hurt you. Badly.
Too bad, they aren't that popular to document behaviour, because sequence diagrams really don't convey that much.
For example timeouts are very neatly described in a harel state chart. How will one describe timeout and timeout handling in sequence diagrams.
They were part of a telecom language called SDL. There were tools to “compile” to various languages such as C. If you followed their rules, you were supposed to be able to go back and forth between C and SDL.
I only remember this because the biggest tool provider at that time was a French company called Verilog. They preceded the HDL by a few years, I guess.
It is pretty much alive in big corps.
I imagine it got out favour on hipster coffee shops coding their next big idea, rewriting multiple times, instead of validating their ideas in first place.
Github supports UML diagrams in their markdown for a reason.
[0] https://littlegreenviper.com/the-curious-case-of-the-protoco...
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.
The diagrams are very nice and useful. But the UML as a process, if taken literally, it a total disaster.
Objectively and utterly wrong.
All agile does is ask you to iterate, which means updating your design, your code, and your tests & documentation, as you learn.
Please read the agile manifesto again, and actually apply it. It does not say we don’t do design at all. Never did.
Agile and scrum and iteration saw them off.
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.).