Hacker News Reader

Comment by dragontamer | Hacker News Reader

Sequence diagrams are very useful. Flow charts and state diagrams are also useful but less so in my experience.

If your inheritance structure is so complicated that you need a class diagram, you are probably in for pain... But class diagrams do their job for sure.

I find UML useful as post-coding documentation. After you figured out how things work, you UML diagram your code to help explain the complicated parts.

UML is also useful for talking with coworkers. As a 'sketch' don't try to get everything right, but coworkers often need to know what your plans are if they are to find work that won't conflict with your plan.

I think another UML post was talking about sketch 'masala' graphs (throw everything into a touchy feely graphic that really doesn't say much). Being absolutely vague and nontechnical is an advantage in some cases, but not useful to engineers. UML, for all of it's faults, is precisely defined. Every symbol means something.

View on HN

I still handwavily use one concept of class diagrams, letting arrows point at something that it depends on, without caring about the style of arrow, for sure I don't draw dashed arrows. It doesn't even have to be classes, could be a function calling another function, or a library depending another.

In my view, Statecharts have been the most useful UML diagrams, since it is possible to represent complex behaviour in it, even more than Sequence Diagrams. Their unlimited nesting, and capability to "remember", etc makes them quite useful.

UML statecharts are based on the theory of Harel statecharts, which you might find interesting: http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso...

I love Harel statecharts. They are a useful formalism that maps easily to code for a wide range of practical solutions. The key innovation is embedded states.

That said, the formalism does not say much about error handling. This is where state machines can get really hairy, in much the same way that throw/catch gets nasty in any non-trivial system.

Sequence diagrams, as probably most other UML diagrams too, predate UML.

Apparently it postdates UML too: there's a sequence diagram tool trending on the front page right now[1].

[1] https://news.ycombinator.com/item?id=26956728

I think there's only one kind of diagram that in UML that doesn't have a clear predecessor: the activity diagram. There's a reason it's called the Unified Modelling Language, after all.

The point of UML was never to "invent" new diagrams. The point was to unify all diagrams so that your arrows in one visual-language are compatible with the arrows in another visual-language.

> Sequence diagrams, as probably most other UML diagrams too, predate UML.

This misses the point of UML, entirely. The point is not that diagramming was invented, it was that it was standardized.

So you don't have to spend half your meeting discussing just exactly what this particular arrow between these two boxes means.

> UML, for all of it's faults, is precisely defined. Every symbol means something.

That's another fault, in my opinion. I'd rather have a vague high-level diagram with a write-up that rigorously describes all the invariants and structure than have a really semantic diagram which is meant to stand alone.

I think software structure is too complex to model with anything less powerful than natural language — that's why we add comments into code to explain the things that even the code itself doesn't make obvious.

Yeah, sequence diagrams are the only ones I really like. Sometimes I auto-generate a UML class diagram from my code for a slide but I always have to trim out excess stuff I'm not interested in and usually add some annotations to make it say what I want.

Reply on news.ycombinator.com