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

281–290 of 427 posts

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

#281

Post by ivan_gammel »

bluGill wrote: post #271
ivan_gammel wrote: post #211

Earlier quoted context omitted.

Part of engineering culture in general, not just software engineering, is ability to share knowledge though documentation and best practices. If you share the source code, you communicate your solution on a very low level. It is often necessary to zoom out to see the big picture and there visualization helps. You can create ad-hoc diagrams, but their expressive power is low: without a convention it’s basically just s…

UML didn't help though because it is never kept up to date with what the code really is

How was it supposed to keep up? The most popular programming languages did not introduce concepts that are too hard to reflect with UML. Or do you mean the problem of maintaining documentation?

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

#282

Post by kristjansson »

bluGill wrote: post #249
greiskul wrote: post #215

Earlier quoted context omitted.

Design patterns are missing language features. http://norvig.com/design-patterns/

People who say that don't understand design patterns and have never worked on a very large project with code dating back a few decades. Design patterns are what let you deal with the mess that results from that.

Good _design_ improves long term maintainability. Design Patterns (in the GoF sense) are basically orthogonal to good design.

Besides, Peter Norvig, even as of 1996, is not not the sort of neophyte you’re referring to.

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

#283

Post by PaulHoule »

UML isn't that bad but it isn't that good.

I was involved in a project based on OMG's Meta Object Facility. The MOF is a tiny system which was designed to be sufficient for bootstrapping an implementation of UML 2 but I found out that the bootstrapping is not so straightforward (I think you have to manifest some objects from UML 1 that doesn't exist in UML 2) and there are some chicken-and-egg problems to resolve but I think it would be possible to build something that, in several stages, can build a complete set of stubs for UML 2 itself as well as any objects defined inside UML 2. I got my project done without doing the whole bootstrap so I am still wondering... I've solved so many chicken-and-egg problems that nobody else has and it's earned me just about $0 and 0 cents.

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

#284

Post by RossBencina »

sidpatil wrote: post #47
knsv wrote: post #40

Earlier quoted context omitted.

The problem with state machines that I run into often when using them, is "multi-dimensional" states. When managing to get that right they are great, otherwise you get loads of edges...

I'm not sure what you mean by "multi-dimensional" states. Is it something that statecharts [1] can help with? [1] https://statecharts.dev/

UML Statecharts are Harel Statecharts, which are hierarchical state machines. Described here:

Statecharts - A visual formalism for complex systems. David Harel. 1987

https://archive.org/details/7.-statecharts

Looks like you can also freely download the paper from here: https://www.sciencedirect.com/science/article/pii/0167642387...

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

#285

Post by snapdaddy »

mkozlows wrote: post #169
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 p…

I don't think it was software architecture, UML or design patterns that was bad. I think the 'Open-Closed Principle' is one of the worst ideas to ever gain popular acceptance.

For anyone who didn't live through that time, the Open-Closed Principle states that software should be open for extension, but closed for modification.

However, you could also rephrase that principle to be: 'you should always prematurely abstract your designs'.

I think if abstraction was viewed as a negative to be avoided unless necessary, software architecture would have been far better off.

To be fair, premature abstraction is a lot of fun for those that do it. It's just those that follow who aren't so keen.

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

#286

Post by WuxiFingerHold »

snapdaddy wrote: post #285
mkozlows wrote: post #169

Earlier quoted context omitted.

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

I don't think it was software architecture, UML or design patterns that was bad. I think the 'Open-Closed Principle' is one of the worst ideas to ever gain popular acceptance. For anyone who didn't live through that time, the Open-Closed Principle states that software should be open for extension, but closed for modification. However, you could also rephrase that principle to be: 'you should always prematurely abstra…

That is an import perspective. I've always struggled to understand why (esp. in the Java enterprise world) things were so complex. It took me a while to see through it and now I create abstractions when I need them, not just in case. That's why I don't like things like Clean Architecture.

E.g. I don't create an abstraction in case I someday need to switch the database from SQL to NoSQL, but when I need the abstraction right now for an alternative implementation (e.g. mocks for testing).

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

#287

Post by bb88 »

bluGill wrote: post #249
greiskul wrote: post #215

Earlier quoted context omitted.

Design patterns are missing language features. http://norvig.com/design-patterns/

People who say that don't understand design patterns and have never worked on a very large project with code dating back a few decades. Design patterns are what let you deal with the mess that results from that.

So, here's something I hate on this site. Arguments that are made in the fashion "People who disagree with me must not understand X". When in fact you're often talking to some of the smartest people in programming on here (though, maybe not in other things.)

It's possible to understand design patterns and work in a language that doesn't require them as much.

Here's a talk about it from 2009 with regards to python.

https://www.youtube.com/watch?v=kSQFZrTDaQ0

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

#288

Post by DSMan195276 »

_proofs wrote: post #178
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…

while i feel as if i largely understand what you're pointing out, i kinda want to offer my own speculation as a SWE who is very guilty in thinking in terms of sequence diagrams (and also more formal UML) -- sometimes UML is so fucking bogged down with (impl) details , i am just over here going "i don't give a shit about the (impl) details, i just want to know the abstract concept(s), and logical flows , and focus on…

I've noticed the "over-detailed" problem a lot at my company that has dedicated "software architect" roles. IMO part of the issue is that most of them do not write any code anymore, but 'architecture' alone just doesn't have a full-time job's worth of stuff to do (or they're bad about finding it). The 'solution' they end up on is just treating UML like code and specifying exactly how they would have written the whole thing - which is a huge waste of time when they could have just been writing real code.

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

#289

Post by agumonkey »

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…

to me seq diagrams are .. too sequential, my brain needs a protocol / graph proof like formalism to see things more globally.

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

#290

Post by ChicagoDave »

mkozlows wrote: post #169
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 p…

I’d argue software architecture has never been more healthy.

DDD Europe by all accounts was a resounding success. We’ve replaced older architecture activities like data modeling first with event modeling and Domain-Driven Design.

We’ve learned to embrace monoliths when appropriate and reduce complexity with bounded contexts.

We have phenomenal testing capabilities that didn’t exist 20 years ago.

We have a myriad of data storage tools.

We understand front-end engineering from an information architecture perspective.

We can design detailed architectures in tools like LucidChart very quickly with detailed solution details.

I’ve been at this for 40 years and I’ve never felt better about being a software architect.

Post reply on HN