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

301–310 of 427 posts

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

#301

Post by phs318u »

colordrops wrote: post #165
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.

Just as well we no longer cargo-cult any practices these days.

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

#303

Post by wiz21c »

cubefox wrote: post #255
radicalbyte wrote: post #115

Earlier quoted context omitted.

UML as a projection is fine and a valuable tool. Starting with UML to describe a set of classes or - worse yet - an entire system is lunacy and a massive red flag.

What's wrong with describing some classes first with a UML diagram?

Nothing wrong, but code is already formal enough that you don't need a formal visual language (UML is not just a bunch of diagrams, it's a formal language). So yeah, a bit of drawing might help to understand, a few ideas from UML might help, but it's not like it is super necessary.

As said, the sequence diagram is a real plus because sequence information is not very well expressed by code, so that diagram has much added value.

I personnaly find UML hard to use becaues if you want to communicate your ideas precisely, you have to know much of its formalism and most often, people who read your drawings don't master its intricacies, so communication quality is no good...

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

#304

Post by kitd »

Sequence diagrams are good when you're already inside the system. Showing my age here but IMO, for sketching a high-level view of the whole system and how its components interact, nothing beats SSADM's data flow diagrams. You can go as detailed as you like. Break up parts into a new component: draw a ring around them, network traffic: note where the flows cross the rings and document the message sizes and rates.

Sigh Happy days ...

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

#305

Post by lionkor »

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…

In my short experience this is mostly due to OOP falling out of style, being replaced by a more hybrid approach that combines a lot of functional programming, procedural programming, and OOP - that, together with newer languages providing alternatives for inheritance (traits/concepts), and such, you rarely find yourself needing much more than visitor- and factory pattern.

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

#306

Post by [deleted] »

phs318u wrote: post #301
colordrops wrote: post #165

Earlier quoted context omitted.

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.

Just as well we no longer cargo-cult any practices these days.

[deleted]

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

#307

Post by snapdaddy »

ThinkBeat wrote: post #114

I thought UML was pretty great when it came out. It attempted to establish a uniform manner to model and communicate out software models / systems. I still think it is great. People who never learned about UML tend to reinvent some such thing when they wish to communicate the same structures and information. Then you end up with 10 different people drawing approximately the same information in 10 different forms, and…

I agree completely. I tend to do 'UML light', where I don't worry about the finer details (e.g. marking fields public or private). The best solution is one where I can sketch out the outlines of a class and have some tool automatically generate UML which I can then edit.

And C4 diagrams are great for explaining software architecture, which wouldn't have been possible without UML and esp. class diagrams.

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

#309

Post by jxramos »

radicalbyte wrote: post #117
holoduke wrote: post #109

Earlier quoted context omitted.

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.

Assuming that you're using a modern IDE: it is an order of magnitude quicker to model the domain (classes + attributes) in code and project them as diagrams, say with graphvis. High level boxes are great for thinking about systems but the key there is abstraction - minimal viable level of detail..

this phrase caught my eye, "minimally viable level of detail", to which I immediately thought "minimal detail for a coherent thought". That's a cool concept actually I might hold on to and develop.
Post reply on HN