Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sequence diagrams, the only good thing UML brought to software development

mermaidchart.com

Post reply on HN
Print view View original

161–170 of 427 posts

Re: Sequence diagrams, the only good thing UML brought to software development

#161

Post by pavon »

cubefox wrote: post #80
imiric wrote: post #31

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…

There are other types of diagrams beyond what UML formalizes. For example, Data Flow diagrams can be very helpful, but they don't exist in UML (Component, Composite Structure, and Activity diagrams all have similarities with Data Flow diagrams, but none are really a great fit).

Re: Sequence diagrams, the only good thing UML brought to software development

#162

Post by tonnydourado »

hwayne wrote: post #129
tonnydourado wrote: post #54

Earlier quoted context omitted.

Not sure what you mean by multidimensional states?

The car can be in drive, neutral, or reverse, the light can be red, green, yellow, or broken, the seatbelt can be off or on. That's 24 states.

Ah, ok. That's kind of what I meant by upfront design, though. Yeah, mapping this out is gonna suck, but it's better than having it hidden in a bunch of ifs.

Re: Sequence diagrams, the only good thing UML brought to software development

#164

Post by shinycode »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

So sad and so true

Re: Sequence diagrams, the only good thing UML brought to software development

#165

Post by colordrops »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

The pendulum swung, and now we bias towards action rather than design. But to be honest, the "software architect" era wasn't great either, with people in the role sometimes not qualified, spending months on an architecture behind the curtain, releasing some over-verbose spec document that doesn't match the product needs, cargo-culting the latest fad from Martin Fowler.

Re: Sequence diagrams, the only good thing UML brought to software development

#166

Post by ableeb »

feoren wrote: post #48
ivan_gammel wrote: post #34

Earlier 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 document their code

Re: Sequence diagrams, the only good thing UML brought to software development

#167

Post by beyonddream »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

I am curious to know what are these “formalized architectural decision making methodologies” ? Any books that u know of that cover these topics ?

Re: Sequence diagrams, the only good thing UML brought to software development

#168

Post by ajmurmann »

tomohawk wrote: post #146
Xelbair wrote: post #116

Earlier quoted context omitted.

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

> increased time to market 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.

Re: Sequence diagrams, the only good thing UML brought to software development

#169

Post by mkozlows »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

Yeah, hard disagree on all that. As someone who lived through that era professionally, and who has had an "architect" title in the past, I was actually resistant to ever stepping into that role, because I had so many bad experience with the Formal Architecture Methodology crew, who would produce the most absurd and out-of-touch designs. There's a reason that "architecture astronaut" is a term from that era.

Lots of people make bad designs today, sure, but it's not for a lack of formal methodologies, because average design quality was way worse back in the design patterns 'n' UML days.

Re: Sequence diagrams, the only good thing UML brought to software development

#170

Post by doctor_eval »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

I don’t think this is any more true than it ever was. If anything, the rise of open source libraries, GitHub and friends has made it easier than ever to reuse software and avoid NIH. This has lead to a different set of problems, but relative to when I was writing C in the 90s I’d say software reuse and design is far advanced from those days.

I do however agree that design is sorely missing from the current software project management zeitgeist, which means it’s done in a more ad hoc way. People are taking frameworks like Scrum far too literally, and I agree that in some cases there is little vision or overall architecture because the framework doesn’t include these things. There should be design and review activities both before and after coding, but these are largely neglected from most project management frameworks. Scrum for example doesn’t even include backlog management, which in my work is a critical activity.

While that doesn’t mean design, architecture and scope management is not done, it’s certainly less visible than it might be.

All of that said, I’m a big believer that the ultimate expression of any design is code. The design artefacts that come before code is written are scaffolding, age quickly, and are soon useless. So there’s not much need to keep them around, and they are mostly of interest as preliminary directions.

In this regard I’m a big fan of Jack Reeves essays from the same period at https://www.developerdotstar.com/mag/articles/reeves_design_...

Post reply on HN