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.
I used to whiteboard for this, but that hasn't carried over well in the remote world. What I miss about whiteboarding though is that you can tell a story as you draw, so whoever's viewing can watch something unfold from a blank slate while I'm walking them through the history of whatever system we're describing. That said, I can make a PlantUML diagram much more correct than a whiteboard.
All that said I too would love for more of that to be automated increasingly through AI. And I suppose it should make sense conceptually, because for me the value of a crafted diagram over an automated one is that no one really wants to look at the insane ERD of an OLTP database or a production object model. They want the digestible high level vision of the important bits, or the bits that are relevant to the conversation taking place. So it's a summarization problem. How to get the right data to produce a correct summary is interesting--I'm sure if I look there's a dozen papers to read on a similar subject :).
> All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey.
I spent a bit of time prototyping this recently. It's definitely possible. Rational Rose also had the capability to generate diagrams from code though. I don't remember how good it was at the task though. Was Rational Rose just a very bad implementation?
I find the hate in this chat strange because diagrams are incredibly useful when working through complex problems* and then conveying that information to other engineers. My experience over 20+ years is that a huge portion of engineers can't grok complex problems from code alone.
*Most of my projects are optimizing billion+ row databases, micro-service architectures, and various other scaling challenges.
Where those boxes are in relation to each other matters. You can't just randomly throw boxes and lines on the page, you need to arrange them so that boxes that we can tell what things are related by how close they are to each other. Automatic UML doesn't capture that.
Sometime you have complexity in code that needs tobe hidden by default. I don't care about rare error cases most of the time, but automatic UML can't know what is the complexity needed for rare cases and what is complexity you need to show the junior on the first day.. related to this when i'm interested in one error path how do you hide the others?
Then the real killer of both. Next week there is a minor requirement change (new features we always knew were coming and planned for even), and now the code changed. UML doesn't follow that. Either you generate UML and have the above problems. Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway.
I've heard this argument many times, but how is it different from keeping documentation, comments, tests, or the issue tracker up to date?
They all require some discipline, but if the team finds value in any of these things, they would make an effort to keep them synchronized with the code.
Besides, I suggest not falling in the trap of having formal design documents early on in the project's lifetime. Rather start with informal diagrams and sketches, and once the design has mostly settled, switch to something like UML. This would mean it wouldn't require changes every other week.
As for automatically generating, and dynamically arranging diagrams, this is more up to the generating tool than UML. These tools are still stuck using decades old technology at this point AFAIA, but there's no reason that a smarter tool couldn't do the things you mention.
I would kill for a tool that could output class and sequence diagrams from a project or component. If the format is editable and tools can automatically layout/filter out components, all the better. Right now the main time sink in putting together diagrams is trying to express what's in the code. Once that's in place, we can prune stuff we don't need.
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.
It most certainly is not.
This is clearly better than UML. UML is full of shorthands that nobody remembers. That's worse than people making labelled custom diagrams.
Here's an example:
https://buck2.build/docs/concepts/concept_map/
Imagine how much worse that would be with UML arrows.
I agree on the "shorthands", like empty/filled arrows, that people may not know. But there isn't much alternative to such shorthands other than leaving them out completely, which wouldn't be an advantage. In diagrams some information is either conveyed succinctly or not at all. The "alternative" is a block of text instead of a diagram.
> People who say "UML is useless" basically say "diagrams are useless".
Starting with UML to describe a set of classes or - worse yet - an entire system is lunacy and a massive red flag.
As said, the sequence diagram is a real plus because sequence information is not very well expressed by code, so that diagram has much added value.
I personnaly find UML hard to use becaues if you want to communicate your ideas precisely, you have to know much of its formalism and most often, people who read your drawings don't master its intricacies, so communication quality is no good...
Code can be formal enough but in reality it is almost never formal enough. Many constraints can be expressed imperatively (eg. someone validates the number of related objects in the create view) and in unexpected places (across repositories and libraries and maybe not even in code but in some stored procedure). And then it is all in flux and can go away the moment you change your stack.
I don't know if UML is perfectly flexible (maybe?) but its sure benefit is a source of truth that does not depend on your implementation.
There a diagrams that are useful before coding, but most of them aren’t part of UML, which is a product of the simultaneous highwater of class-based-OOP-is-everything and pre-Agile industrial software development methodologies, and (except for some isolated bits) poorly fit to anything else.
I don't think this is right or a well founded opinion. The whole point of any diagram language, including UML, is to provide the means to describe software projects in different views, including class diagrams but also component and system diagrams.
What do you think is the whole point of a modeling language?
Sometimes motivations are misguided, and sometimes instances aren’t well fit for major motivations of their broader class.
You, and OP, failed to present a single argument supporting the thesis that modeling languages in general, and UML in particular, are "lunacy and a massive red flag."
> Sometimes motivations are misguided (...)
Not only did you failed to support anything in the original anti-diagram rant, now you also tried to support generalizations with hypothetical corner cases involving misuses, which is an absurd argument to make.
So not only do you have zero substance for show with regards to the original anti-UML rant, you also resort to using vague, unsubstantiated strawmen.
This is to be expected. Like many discussions involving technical aspects, generally detractors come from positions of opinionated ignorance.
I failed to support that thesis because I never endorsed it. Pointing out a flaw in a counterargument is not endorsing the argument it is deployed against.
Not building an entire system down to class level which is what it is all too often used for (in my experience exclusively by people who have never and cannot code).
It's inefficient, doesn't play well with Software Engineering (diff, version control etc..) and is a relic of the past.
Keep the classes in code, project that into a diagram for the few occasions that is actually needed, and stick to a simplified tool like C4 (https://c4model.com) for your architectural views. Sprinkle some sequence diagrams in too to help describe the key data flows (they're handy next to C4).
Why use C4 over UML? Because the vast majority of the audience don't even know what UML is. So keep it extremely simple and include a key / guide to any of the (few) shapes or colors you use so that it's completely self contained.
The vast majority of UML belongs to be put into the Indiana Jones storage facility along with other archaic ideas such as Function Points / Function Point Analysis.
That was never the point of modeling languages.
Your baseless assumption is even more absurd when you factor in the fact that modeling languages even express runtime behavior, componente, and packaging.
The main problem with these mindless attacks on modeling languages in general and UML in particular is that the bulk of their retractors clearly knows nothing nor has any direct contact with them, or how they are used in the real world. Their arguments are nothing more than poorly thought through strawmen. Your comment fits well.
> Why use C4 over UML?
See, this is a telltale sign you know nothing about what you're commenting on. Not only is C4 a modelling language like UML but it also covers the exact same responsibilities and features of UML. C4's main selling point is advocating for the representation multiple points of view, and UML is a standard specification to express all the points of view you see fit in a coherent and rational way. There is no C4 vs UML. They have both the exact same design goals and usecases.
However I sometimes find them useful to extract key parts of the system and showing their interaction. Cutting away many attributes, many helper classes, many other things.
That can lead to pictures which are quick to grasp and then allow further digging based on code.
High level boxes are great for thinking about systems but the key there is abstraction - minimal viable level of detail..
That discussion is almost never going down the the level of an individual class and NEVER adheres to the UML standard.
Very occasionally I've had discussions about class structure by drawing class name + methods on a whiteboard but having the same discussion using Visual Studio's UML projection was just as effective.
For interactive discussion I just use Visual Studio's projection, for databases I use the SQL Server Management Tool ERD projector or pgAdmin if I'm using Postgres.
Those are a different kind of diagram than the one you create from scratch to decide what goes in the program.
Also, class diagrams are more useful when you can’t give out source.
That being said, I think you can autogenerate class diagrams from code so it’s not like you should spend a lot of time making them.
I dunno, whenever I heard people say they're doing Agile all I see is them doing Waterfall without documentation.
Is essentially the argument i see over and over again. And every time i start a new project and that project has docs or uml or whatever I appreciate it. Even if it is a bit out of date, it's way better than nothing.
In my opinion, every project should have a readme file with instructions for running the project locally, and ideally also a high level visual representation of the system.
It should be separated into sub systems/modules for separate functionality and each module could have it's own set of readme and high level visuals. In addition, modules should have small coupling points, typically interfaces and these should have documentation comments describing what they do, inputs, outputs etc. APIs should have something like a swagger doc.
I used to hear people say the same thing about laziness about code style before reformatting/linting tools became standard.
Sounds a lot like laziness to me. It may be more accurate to say it's because people don't care. I've seen projects full of typos. Ive seen projects where basically everything had been duplicated not once but twice because they wanted a slightly different version of the same website so instead of adding some configuration or otherwise finding a reasonable solution for it they just went and copied hundreds of files and prefixed their names before making a couple minor changes and leaving the mess for someone else to discover. No mention anywhere of the fact that this had been done, nor why.
These are the actions of people who don't give a shit. Whatever problems they create are someone else's problems. The way i see it, if you care about your work you'll make sure the code is readable, well documented and so on. If you don't, you won't.
Don't forget that some details shouldn't be in UML.
Rather: managers do not highly value work on documentation, so many programmers care little about it. If writing good documentation was valued more by managers than implementing feature stories, the situation would be different. Incentives do matter.
It's all just bad excuses for not doing work properly. Writing clean and well documented code very quickly becomes faster than writing a tangled undocumented mess.
Plans are useless, but planning is indispensable. The act of diagramming things up front is useful to get you thinking about the problem space and come up with the outline of a solution. After that, keeping the initial design documents up-to-date is optional, and often might not be necessary.
During the prototyping phase diagrams do help, but they're usually sketches written on paper or whiteboard. You don't want to waste time with tools and strict specifications to design perfect diagrams, mostly because the design will change frequently, and you don't want your tools getting in the way.
Later on, once the design has settled down and maybe once development has started, those initial diagrams are mostly worthless, but you _do_ want neat and professionally done design documents that describe the system. This allows you to share them with coworkers, and quickly onboard other developers to the project. Hopefully by then the design won't change frequently, which would make updating these a chore.
In terms of artifacts for future maintainers? Maybe not as helpful. As previous posters have mentioned, the diagrams go stale very quickly if the engineering department isn't disciplined about keeping documentation up to date. But this is true for any documentation.
Some diagrams (class and activity, in particular) are less valuable as time passes. I can get the idea of the class structure by just looking at the code itself. The class diagram just ends up being a stale representation of the code.
It is unfortunate that UML has developed a reputation as being overly complex. Now I see more ad-hoc diagrams being created, with whatever notation/symbols make sense to author, rather than using a common diagram system that can be read by many.
They're not bad, but the C4 model is a much better approach to high level modelling (while you can still use class diagrams on the lowest level). https://c4model.com/
It wasn't also visual design tools that Agile killed. Agile killed design documentation altogether.
With Agile, today's problems are addressed on tomorrow's sprint, and changes in software architecture take place only in the code. Any effort to document the system architecture in any remotely rigorous way is quickly deprecated, and teams simply don't waste time maintaining something that might already be deprecated once they finish editing the document.
The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. So we saw no need for these visual design tools to model the entire system, since we ended up changing the design during the lifetime of the project anyway. The drawback of this, of course, is that with the Agile approach these diagrams never end up being made, so developers are left to assemble their own mental model of the system, which hurts the overall comprehension. Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date, which is true, but this is not unlike documentation, comments, and a myriad other things that needs to be synced with the code.
Yet sequence diagrams are useful in a wide variety of use cases, and let's face it, they're the easiest ones to comprehend, and are even understandable by a non-technical audience. In contrast to the other UML diagram types that have strange notations and the information is more densely packed.