UML is terrible. At least the version of the unified modeling language that I was presented in a recent graduate class came off as an awful waste of time, which was in line with my prior impression of it. UML fills me with such unreasonable rage that I hesitate to try to put into words the reasons why, as the irrationality of my hatred of it will surely render my opinions biased in the extreme. I’ll try to get this out of my system early by stating the following:
Why on earth am I wasting my time writing out classes in this this bullshit intermediate language when I could be just fucking writing the classes?
I don’t see any downside to roughing out classes in the actual target language. You can skip defining things like method bodies and building any real functionality; if you’re just defining structure and relations, then get it created and keep moving. It’s there, ready to start defining behavioral tests on.
So why else would I want to start with a UML diagram of my system? If you want some sort of language independent description of a system, I would ask to what end? There will always be language limitations to consider, or benefits that can’t be realized in UML. If you want some sort of documentation of a system to show off after the fact, there are tools that’ll happily show you the completed object model of your software as a pretty graph.
I understand defining the problem being addressed and analyzing the high-level architecture of the system as a starting point, but once you dive into the minutia of defining public/private on fields and methods and insane levels of complex diagrams for even the most simple processes, I start wondering how much time it’d be possible to waste on such pursuits. All this work before it’s even understood how the code will actually work as described in the selected implementation system!
Breaking it down:
- UML can’t be tested. It sits there, waiting to fall out of date. No rapid feedback here, no idea what might be missing or setup incorrectly.
- UML doesn’t consider cross-cutting concerns. I shudder to imaging the UML diagram that does. Cross-cutting concerns are a part of every project, like it or not.
- UML is not reactive and certainly not a learnable solution for programming; it’s not programming that updates, communicates, lives, breathes, and reacts as it’s created. I can think of nothing less all those things than a static vector diagram of some classes and behaviors.
- A UML diagram doesn’t actually document any design decisions, their reasoning or purpose. While this could be added to the “required” documentation, the UML itself (at least the version that I saw in class) exists only to state “how” not “why”.
- UML is wedded to object oriented design principals. With functional and prototype languages being very popular these days, UML would seem very limiting indeed.
Deep breaths. Deep breaths. Okay.
A Glimmer of Value
The smallest defense I can offer is that in my nascent ideal of a learnable programming system, diagrams can be a great way to quickly express how various data structures relate to each other. Such live diagrams would definitely offer a useful view into how components interact, and could offer insight that a static code view does. The key here is that the data view has to be live.
The SalesForce platform actually has something like this, where you can view the current system configuration. Again, this is something that comes after the initial model is composed. It also can be used to make basic changes, as well; it’s a living, breathing development tool, not a static, time-wasting boondoggle.
UML is terrible.