Oh come on. Uml database tables aren't half bad
Sequence diagrams, the only good thing UML brought to software development
101–110 of 427 posts
Re: Sequence diagrams, the only good thing UML brought to software development
#102[dead]
Re: Sequence diagrams, the only good thing UML brought to software development
#103Agreed. We published a post recently about how to interpret a sequence diagram based on the 7 basic features and how our dev tool makes them automatic and interactive. https://dev.to/appmap/quickly-learn-how-new-to-you-code-work...
Re: Sequence diagrams, the only good thing UML brought to software development
#104Earlier quoted context omitted.
I don't think I have ever seen anybody actually getting value from a class diagram. I have seen many people creating them, but they are always useless. I also don't think the UML variant of state machines and workflow are any popular. But well, there is probably somewhere where people use them. Also, those lists usually ignore entity-relationship diagrams, where UML just adopted the popular format (without even minor…
Class diagrams are a good way to detect circular dependencies.
If your class diagram is comprehensive enough to get circular dependencies, then I'm completely sure¹ nobody will use them for anything.
Computers are much better at this kind of checks anyway, and they don't need diagrams.
1 - Instead of "well, maybe it's possible despite I never seeing it"
Re: Sequence diagrams, the only good thing UML brought to software development
#105Earlier quoted context omitted.
Every software engineering team in my 20+ years career actually used 2-5 types of UML diagrams: classes, sequences, deployment, activity, state. I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. There’s certainly some value in it.
> I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. I suspect that's true: teams with a very immature engineering culture probably do use a lot more UML. It's a good way to feel like you're doing something useful instead of actually doing the hard part. Mature teams write code.
> Mature teams write code.
Sounds very Dunning-Krugerish “smart people like me do X and not smart people do Y”
Coding and documenting aren’t exclusive. Modeling is part of documenting. UML is a type of modeling.
I would think effective teams will want to build good software. And to build good software they’ll want to capture requirements, communicate with other teams, and test their software. Design helps with this and is part of coding.
At the end of a successful day, I should have some updated models, some code, and some running software. If someone wants to see what I did, they’d likely read through different parts.
Just like trying to figure out a stage by just reading models sucks, so does trying to figure it out by just running the software.
Re: Sequence diagrams, the only good thing UML brought to software development
#106I 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 diagrams feel pointless to me, this information works better as code, and how do you draw a class diagram with more than 10 classes and keep it readable?
If you use class diagrams to show the "truth" you are in painland in my experience.
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.
Re: Sequence diagrams, the only good thing UML brought to software development
#107Thinking "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…
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?"
Oh wait.
Re: Sequence diagrams, the only good thing UML brought to software development
#108Sequence diagrams are great, but creating them by hand is a pain. It's not just manual toil, they also go out of date. AppMap (where I work) can generate them automatically based on runtime analysis of an application: https://www.youtube.com/watch?v=8l4-hNih_GQ
Re: Sequence diagrams, the only good thing UML brought to software development
#109I 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 diagrams feel pointless to me, this information works better as code, and how do you draw a class diagram with more than 10 classes and keep it readable?
Maybe before you actually start writing code its nice to create some domain diagrams which you can convert to class diagrams. Saves a ton of time. And you have good discussions about the general high level workings of an architecture. Can be done on a whiteboard. Make some pics and start coding.
Re: Sequence diagrams, the only good thing UML brought to software development
#110I'll just hop in here without reading the article and say that I've actually been using UML (plantUML specifically if that matters) to communicate with LLMs about software structure with some pretty good success.
Turns out computers are good at dealing with symbols, who knew!?