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.)
>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.
Not really, UML was doomed from start due to increased time to market metric. And frankly you can read the code if you are working on the already built system. Remember that software usually does not need to be correct, or even well designed to support a business case. It is one of software greatest strengths and weaknesses compared to other disciplines.
It does helps in some integration tasks, and works decently as schema definition language that's format agnostic.
I'll also concede that state diagrams are good, but well.. they are also quite simple.
Then there's readability issue - unless you worked tons with UML you WILL make mistakes when it comes to object relationship counts, and there's a lot of other non-obvious gotchas for newcomers(i used to teach reading entity relationship diagrams to non-technical people so they could understand the model they were working with, as it was a part of legal bill).
Not to mention that only proponents of UML that i've personally met, were people who were stuck in academia, and never worked on any real software product..
And even for R&D work on a harder problems it's usually easier to write a toy side project and test solutions.
Code you write in such toy project IS an entity relationship model. Tests, and example usage is a happy path of sequence.
etc.
You might enjoy looking a little deeper. For one example:
> I'll also concede that state diagrams are good, but well.. they are also quite simple.
One of the goals of state modeling is to simplify. A sufficient metamodel will include (in addition to states and transitions on events that people might see in automata theory and misc. CS education) less-simple features like concurrency, superstates, transition guards, maybe real-time constraints.
When you need a nontrivial system to actually work, in all cases, (not just toss your sprint task over the wall, and then do bug tasks later) good use of the abstractions of this "simple" diagram, and inspecting it, will tend to avert problems that even an unusually conscientious programmer might miss in just code. And it also helps communicate less-ambiguously to others who come later and need to evolve the code. Unlike formal proofs, it's pretty accessible to read.
(It can be too accessible, in that people who are accustomed to seeing hand-wavy business diagrams with ad hoc notation used inconsistently think they also get the gist of this diagram, while not realizing how much more rigorous it is. But that's not a big problem -- you just have to walk them through it, ask questions to confirm facts expressed, emphasize when something has to be precise and exhaustive, etc. The problems are more when the diagram is poor, yet the technical appearance confers an undeserved aura of respectability, and people who can't tell the difference, act on that, but that's not unique to these diagrams.)
> good use of the abstractions of this "simple" diagram, and inspecting it, will tend to avert problems that even an unusually conscientious programmer might miss in just code
Very good point. If you have expertly written UML and an expert viewer, they will get quite a lot out of it. One of the biggest issues I have seen with UML documentation is that it is extremely difficult to keep it in sync with what the actual implementation does. In one of my past jobs we actually had started an effort to quelch this by generating plantml from code but it never really came to fruition.
I used those features, i used to work with UML, and as i said - even teach how to read it to non-technical folks.
It helps in very niche cases - as i said mostly state diagrams, and non-trivial data models when you have to interop with different systems, or define a common data model. Haven't worked with designing protocols, but that's basically a committee work..
That does not change the fact that it is useless for 99.9%, or higher, of typical dev work, for typical dev systems - which are basically CRUD systems with some fluff. This is the biggest barrier for UML to gain traction, and it is completely incompatible with that.
And that's disregarding parity of diagrams with codebase - there's a reason why a lot of codebases reduce comments - as they go out of date pretty fast.
I've seen people spend days and days trying to save a few hours of paper design time.
We often do quick paper or marker board designs, which often have some UML. You don't want to spend more than 10% of your time on this, but it can save quite a bit of time to market. If someone really wants the design saved somewhere, we just take a pic and upload it.
I think you are right and it depends so much on what you are building and in what context.
If shipping is expensive, you build something complex and correctness matters, you want to go all in on design and verification. You might even want to use TLA+ to verify your algorithms beforehand.
If you build a SaaS app that people use for leisure and is mostly CRUD, you probably don't need UML diagrams for the vast majority of your work. Exceptions will be the larger systems design where you still need to plan things like DB sharding approach, services etc.
Is ERD part of UML? I find ERDs useful representations of databases. They can be generated automatically and are very good for quickly locating the right tables for a query. So I wanted to add a comment stating this to the parent - but then I googled to check if they really are part of UML - and it seems that they predate UML and are not really related.
Correct uml didn't have anything to say about relational databases.
I use two types of diagrams:
Erds
and
Random blocks and arrows and icons that mean whatever I want them to mean for that particular diagram, based on whatever concept I want to communicate at that point. Maybe it's network architecture, maybe it's dataflows, maybe it's software components. Each diagram comes with some text explaining what it represents.
A subset of UML's static object modeling diagram notation (which they adapted from OMT) can be used like ERDs, for a relational database without an ORM.
I wonder if there's a parallel here with the journey that some people go on with respect to design documentation in general. In can be easy to have a mandate from on high that your process should be research -> planning -> design -> review -> implementation -> review -> ship, and that the design doc is the key deliverable between the design and implementation stages. You can even argue that this is an "agile" process, if there's a feedback loop that permits the design to be revised as further discovery emerges during implementation.
But the reality is that an awful lot of the software we build just isn't complex enough to warrant all this ceremony. It's not branchy, there's no significant error handling to talk about, no big new dependencies being added, no security implications, no long-term maintenance of an external interface— it's just grabbing widgets from pile A, frobnicating them, and dropping them on pile B. There's barely enough there to even unit test much less write a "design doc" about and agonize over in a meeting with bigwigs.
And unfortunately a lot of the projects that junior developers start out with look exactly like this. Boring, obvious code that does one thing in the exact boring, obvious way that you'd expect. So it's easy to fall out of the habit of thinking intentionally about design, until you're suddenly faced with a big thorny problem that legitimately has multiple paths forward, and what starts as a rubber-duck conversation with the person beside you eventually becomes "hmm... I think I need to write down a page or two that describes these options, gives background on why the choice matters, describes why the selection was made that was made; then maybe afterward I'll circulate that document to my colleagues for their review and thumbs-up, because maybe there's something I'm overlooking here that they could contribute to?"
Some of these methodologies and their tools have been used very successfully. By people who built complex systems that really needed to come together and work correctly.
I'm addressing the masses of us Webrogrammers, who classify all that space as "UML", and dismiss it. Not everyone is just going to be tossing (ChatGPT-assisted) sprint tasks over the wall, while calculating when to make their next job hop. Some teams will have to build complex things that work, and they can benefit from informed and judicious use of abstractions and views on the system.
> I'm addressing the masses of us Webrogrammers, who classify all that space as "UML", and dismiss it. Not everyone is just going to be tossing (ChatGPT-assisted) sprint tasks over the wall, while calculating when to make their next job hop. Some teams will have to build complex things that work, and they can benefit from informed and judicious use of abstractions and views on the system.
On the contrary, people who are doing routine webdev are the ones who can afford the overhead of doing this nonsense, whereas for people who actually have to make something complex that works it will sink them.
Definitely, bad diagrams (as opposed to bad diagram notation) give UML a bad name. Your example of the misuse of state diagrams as a glorified flowchart is something I see very often.
Undergraduate students probably don't have the experience and design maturity to fully appreciate when and how to use most UML diagrams. I think you need to get stuck at design problems a few times before you can appreciate the need to capture ideas using the right diagram, and then you might be ready to adopt some standard so you can share your design decisions with others in a way that correctly captures and conveys just the right amount of detail.
Part of the disconnect is formal modeling methods vs informal. There is tremendous value in having a shared understanding of the architecture of system such as how components interact, the data model and any type of sequence or state modeling if needed. That can sometimes be accomplished just with ephemeral whiteboard diagrams and sometimes more complex situations require deeper analysis.
The challenge comes when trying to document the entirety of the system, and keep that up to date. The overhead is too high and complexity is such that it defeats the value of a model used to communicate shared understanding.
UML really wasn't a methodology. It was a "visual modeling language" telling you how you should draw a picture of a code construct.
It didn't give much (if any?) advise on which development tasks you should do in which order. It was just a TOOL that could be used as part of your SW development activities.
I'm not sure how people used it. Did they first draw the picture and then code, or vice versa? Or maybe drawing the pictures was optional? A "Software Development Method" should answer such questions, among others.
A note about words: "Methodology" means something like "study of methods". A more proper word for individual documented or prescribed approaches to how to develop software would be simply "method". A "method" tells you how to do something.
I like the class diagram notation, although I get frustrated at the tendency to try to auto-generate it, which ends up including way more detail than is useful.
> 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.
UML. Use what you need, but need what you use.
Come to think of it, that probably applies to abstraction. And threads. And probably several other things.
Sounds like you never had to deliver something created with that god awful Rational Rose crapware. Who's genius idea was to use UML as a code skeleton generator? That is a perfect the recipe to guarantee your non-lead developers never gain any ownership nor intimacy with the software they are working on.
The only organizations using UML were bureaucratic heavy nightmare places to work too.
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.)