131–140 of 427 posts
Wouldn't be surprised if the main reason UML ended so despised is 99% to do with class diagrams.
Sequence diagrams are really nice though.
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 m…
significantly more interesting technological failures deserve dibs on this excuse
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 m…
>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 co…
> 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.)
I also find sequence diagrams to be the most useful, but disagree that the rest of UML is useless. Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. 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, ea…
People who say "UML is useless" basically say "diagrams are useless". Which obviously isn't true. The alternative to UML is everyone inventing their own "diagram language" when they want to visualize something. 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…
Earlier quoted context omitted.
> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. 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, an…
I've taken a throwaway approach to diagramming, where I'll produce them more or less on demand for a meeting or presentation, but not think of them as an enduring artifact. PlantUML is my friend here because I can knock out ugly but gets-the-point-across diagrams in 30 minutes before a meeting and check them into source control, so I can then take the bones of older diagrams and rework them for a fresh meeting. I use…
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 m…
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.
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 m…
"real UML has never been tried" significantly more interesting technological failures deserve dibs on this excuse
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 also find sequence diagrams to be the most useful, but disagree that the rest of UML is useless. Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. 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, ea…
> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. 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, an…