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

111–120 of 427 posts

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

#111

Post by slowmovintarget »

kazinator wrote: post #74
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…

> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. I completely agree with you. It's a good way for other people to present information, for me to look at. I just won't do it myself. It's not only me; and that's why it's dead. I won't do it because the first thing that comes to mind is how it will go out of date in a month, an…

I'll draw those diagrams... on a whiteboard, sans boxes (Tufte). Great for point-in-time communication, less useful as specifications.

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

#112

Post by nivertech »

not only, also UML Statecharts[1,2] basd on Harel Statechars[3]

--

1. https://en.wikipedia.org/wiki/UML_state_machine

2. https://en.wikipedia.org/wiki/State_diagram#Harel_statechart

3. https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts....

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

#113

Post by lemmsjid »

kazinator wrote: post #74
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…

> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. I completely agree with you. It's a good way for other people to present information, for me to look at. I just won't do it myself. It's not only me; and that's why it's dead. I won't do it because the first thing that comes to mind is how it will go out of date in a month, an…

I've taken a throwaway approach to diagramming, where I'll produce them more or less on demand for a meeting or presentation, but not think of them as an enduring artifact. PlantUML is my friend here because I can knock out ugly but gets-the-point-across diagrams in 30 minutes before a meeting and check them into source control, so I can then take the bones of older diagrams and rework them for a fresh meeting.

I used to whiteboard for this, but that hasn't carried over well in the remote world. What I miss about whiteboarding though is that you can tell a story as you draw, so whoever's viewing can watch something unfold from a blank slate while I'm walking them through the history of whatever system we're describing. That said, I can make a PlantUML diagram much more correct than a whiteboard.

All that said I too would love for more of that to be automated increasingly through AI. And I suppose it should make sense conceptually, because for me the value of a crafted diagram over an automated one is that no one really wants to look at the insane ERD of an OLTP database or a production object model. They want the digestible high level vision of the important bits, or the bits that are relevant to the conversation taking place. So it's a summarization problem. How to get the right data to produce a correct summary is interesting--I'm sure if I look there's a dozen papers to read on a similar subject :).

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

#114

Post by ThinkBeat »

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 all will require some level of explanation of notation and grammar for others to grok it.

A class diagram can contain a lot of rather valuable information.

I do agree that sequence diagrams are great, but if you rip them out of context and throw the rest in the bin it can only partially communicate, whereas if you had the object model to study as well as the sequence diagrams new connections can be quickly made.

To this day I prefer to create my object structures in a UML diagram. Plenty of software takes it creates the code, or takes the code and produces the diagram.

I love creating the diagram(s) when I first start working on an existing system.

What I have seen of code generation off of sequence diagrams have bit hit or miss. more miss. But reverse engineering sequence diagrams can be quite revealing.

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

#115

Post by radicalbyte »

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…

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.

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

#116

Post by Xelbair »

neilv wrote: post #76

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

>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 correct, or even well designed to support a business case. It is one of software greatest strengths and weaknesses compared to other disciplines.

It does helps in some integration tasks, and works decently as schema definition language that's format agnostic.

I'll also concede that state diagrams are good, but well.. they are also quite simple.

Then there's readability issue - unless you worked tons with UML you WILL make mistakes when it comes to object relationship counts, and there's a lot of other non-obvious gotchas for newcomers(i used to teach reading entity relationship diagrams to non-technical people so they could understand the model they were working with, as it was a part of legal bill).

Not to mention that only proponents of UML that i've personally met, were people who were stuck in academia, and never worked on any real software product..

And even for R&D work on a harder problems it's usually easier to write a toy side project and test solutions.

Code you write in such toy project IS an entity relationship model. Tests, and example usage is a happy path of sequence. etc.

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

#117

Post by radicalbyte »

holoduke wrote: post #109
Kwpolska wrote: post #95

Earlier quoted context omitted.

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.

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

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

#119

Post by barrkel »

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/

The cross product of multiple state machines, I expect. If you try and use a single state diagram to encode the product of states, everything multiplies.

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

#120

Post by jacobr1 »

neilv wrote: post #76

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

Part of the disconnect is formal modeling methods vs informal. There is tremendous value in having a shared understanding of the architecture of system such as how components interact, the data model and any type of sequence or state modeling if needed. That can sometimes be accomplished just with ephemeral whiteboard diagrams and sometimes more complex situations require deeper analysis.

The challenge comes when trying to document the entirety of the system, and keep that up to date. The overhead is too high and complexity is such that it defeats the value of a model used to communicate shared understanding.

Post reply on HN