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

121–130 of 427 posts

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

#121

Post by MilStdJunkie »

imiric wrote: post #49
MilStdJunkie wrote: post #17

Yeah, Mermaid gets it. Mermaid . . wait a second . . oh, ok, these are the same people that do Mermaid.js, they're just trying to make a living doing it. Another useful chart type provided by Mermaid.js is the git diagram, which I use all the time when brainstorming change processes, especially for other folks who might not be git-conversant. https://mermaid.js.org/syntax/gitgraph.html

I find Mermaid's syntax difficult to use and understand past the simplest examples. I've also run into some strange edge cases with it, but can't remember the details right now. Out of these text-to-diagram tools, D2's syntax seems the friendliest to me. See https://text-to-diagram.com/ .

Is there a way to get a git diagram out of D2? It does have nicely streamlined syntax.

One thing that worries me is that the profusion of text-based graph description languages will result in a family of software that's unparseable due to its success. We have Graphviz, GNUplot, PlantUML, BlockDiag, Mermaid, Kroki, Vega, and too many others to count - but we don't have a Pandoc.

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

#122

Post by travisgriggs »

As a general rule I've come to believe that anything with "unified" (or the like) in its title is destined for doom of there's a sales/marketting/monetization agenda behind it. And if it's a bunch of hackers who agreed to clean up a mess, then it is often successful.

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

#123

Post by musha68k »

Dig1t wrote: post #66
anonzzzies wrote: post #22

Earlier quoted context omitted.

> I see them used all the time in FAANG. Does that mean something? Besides you saying you worked in them? It’s a question ; I don’t know.

It is shorthand for saying that it is used by engineers working on high-profile, high-impact, software that ships to hundreds of millions of people. Some people might argue that these teams work on some of the most important software in the world. So if the people who work on this important software do a thing, like use sequence diagrams, that is a decently good signal that the thing is useful.

Also used a lot in automotive software development processes for example. Basically, the more safety critical a system is the more formal diagramming / modelling there will be part of the design and development process. It’s important to be able to reason about complexities of such systems across a team / teams.

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

#124

Post by lesuorac »

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…

> 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, early design and system architects, in favor of Agile, just-in-time design and empowering developers.

I dunno, whenever I heard people say they're doing Agile all I see is them doing Waterfall without documentation.

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

#125

Post by barbariangrunge »

I like sequence diagrams for understanding unfamiliar or complex code that I need to work with.

Go in, head spins, make a sequence diagram, grok, then make your change.

They're awesome for that, and they make decent notes later, but realistically they'll be out of date by the next time you look at them. I recommend plantuml for this: very friendly syntax, git friendly, and easy to regenerate over time as the code changes

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

#129

Post by hwayne »

tonnydourado wrote: post #54
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...

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.

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

#130

Post by michaelsbradley »

Statecharts[1] predate UML, and became part of UML[2].

From the time of their invention to the present, people have devised systems for serializing (i.e. as data structures and code) statecharts and translating them to (or interpreting them as) executable programs[3].

While they may not be all the rage and take some discipline to learn and use effectively (what software tool/concept doesn't?), they can be a valuable tool for building reactive systems:

   A typical reactive system exhibits the following distinctive
   characteristics:

   It continuously interacts with its environment, using inputs and
   outputs that are either continuous in time or discrete. The inputs
   and outputs are often asynchronous, meaning that they may arrive or
   change values unpredictably at any point in time. This should be
   contrasted with transformational systems, in which the timing of the
   inputs and outputs is much more predictable. A transformational
   system repeatedly waits for all its inputs to arrive, carries out
   some processing, and outputs the results when the processing is done.

   It must be able to respond to interrupts, that is, high-priority
   events, even when it is busy doing something else.

   Its operation and reaction to inputs often reflects stringent time
   requirements.

   It has many possible operational scenarios, depending on the current
   mode of operation and the current values of its data as well as its
   past behavior.

   It is very often based on interacting processes that operate in
   parallel.

   Examples of reactive systems include on-line interactive systems,
   such as automatic teller machines (ATMs) and flight reservation
   systems; computer-embedded systems, such as avionics, automotive, and
   telecommunication systems; and control systems, such as chemical and
   manufacturing systems.
— Harel and Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach (1998) [4]

[1] https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/res...

[2] https://en.wikipedia.org/wiki/UML_state_machine

[3] https://userweb.cs.txstate.edu/~rp31/papersSP/stateMate.pdf

[&] https://www.w3.org/TR/scxml/

[&] https://github.com/jbeard4/SCION

[&] https://github.com/statelyai/xstate

[&] https://www.rtsys.informatik.uni-kiel.de/en/archive/kieler

[&] search the web and you'll find more

[4] https://www.wisdom.weizmann.ac.il/~harel/reactive_systems.ht...

Post reply on HN