Sequence diagrams, the only good thing UML brought to software development • Hacker News Board

radicalbyte wrote: post #368

rewmie wrote: post #363

Earlier quoted context omitted.

> Starting with UML to describe a set of classes or - worse yet - an entire system is lunacy and a massive red flag. I don't think this is right or a well founded opinion. The whole point of any diagram language, including UML, is to provide the means to describe software projects in different views, including class diagrams but also component and system diagrams. What do you think is the whole point of a modeling la…

> What do you think is the whole point of a modeling language? Not building an entire system down to class level which is what it is all too often used for (in my experience exclusively by people who have never and cannot code). It's inefficient, doesn't play well with Software Engineering (diff, version control etc..) and is a relic of the past. Keep the classes in code, project that into a diagram for the few occas…

> Not building an entire system down to class level (...)

That was never the point of modeling languages.

Your baseless assumption is even more absurd when you factor in the fact that modeling languages even express runtime behavior, componente, and packaging.

The main problem with these mindless attacks on modeling languages in general and UML in particular is that the bulk of their retractors clearly knows nothing nor has any direct contact with them, or how they are used in the real world. Their arguments are nothing more than poorly thought through strawmen. Your comment fits well.

> Why use C4 over UML?

See, this is a telltale sign you know nothing about what you're commenting on. Not only is C4 a modelling language like UML but it also covers the exact same responsibilities and features of UML. C4's main selling point is advocating for the representation multiple points of view, and UML is a standard specification to express all the points of view you see fit in a coherent and rational way. There is no C4 vs UML. They have both the exact same design goals and usecases.

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

#426

Post by feoren » Mon, Jun 19, 2023, 6:03 PM UTC

ivan_gammel wrote: post #211

feoren wrote: post #48

Earlier quoted context omitted.

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

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…

I agree with everything you said until you got to UML diagrams. The problem with UML diagrams is that they communicate exactly the same thing that the code should be communicating. Class diagrams are not higher-level than the code they describe. Instead, communicate high-level intent and interactions.

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

#427

Post by feoren » Mon, Jun 19, 2023, 6:19 PM UTC

prepend wrote: post #105

feoren wrote: post #48

Earlier quoted context omitted.

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

UML is not documentation, it's code for people who can't read code. UML diagrams offer no additional information to someone who already can read code (and write readable code). They are training wheels. Mature bike riders don't use training wheels. Mature teams don't write UML -- they write code instead.

Other forms of documentation have their own tradeoffs, but I was not discussing those. You're the one who automatically equated UML with all possible documentation.

> to build good software they’ll want to capture requirements, communicate with other teams, and test their software

UML is awful at all of this.

> At the end of a successful day, I should have ...

> “smart people like me do X and not smart people do Y”

You don't see the irony here?