>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.
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.