Ask HN: Are UML diagrams still used today? - tzhenghao
======
kpil
I think that entity-relation diagrams are underused, especially when analysing
requirements with stake holders.

Unfortunately a lot of otherwise capable people that could benefit from some
simple structuring of things and their relations have never thought about the
world in that way and may take a little while to catch up.

In some cases I have found it to be easier to represent one-to-many relations
as a bunch of stacked boxes on the "many" side. But that only works once...

Sequence diagrams and state-charts helps from time to time, but does not
really help much when talking to non-professionals.

But I don't really like the very formal UML. Some bubbles, arrows and crow's
feet will do fine in most cases. The precision promised by UML is really a
lie, as most diagrams are simplifications and can probably not represent the
actual complexity in anything that warrants the use of UML...

Anyway, I think it might actually be a good idea to do some simple entity-
relationship analysis in schools at some point, if not to just get another
tool for sorting out the mess.

The underlying reason that led to OO-languages still exists, namely that a lot
of things can be described rather nicely with entity-relation maps. It's just
unfortunate that the "relation" part was forgotten, and all energy was spent
on wrestling various languages into bizarre "OO" hacks such as C++.

~~~
BoiledCabbage
Entity relationship diagramming is such an incredibly simple at powerful tool
- it's criminal it's not mandatory for a degree.

Doing modeling without it is like analysing logic with without boolean algebra
or 1st order logic.

And thete is nothing to it - it just focuses your thinking and communication.

~~~
IslaDeEncanta
Where is it not mandatory for a CS degree?

~~~
2_listerine_pls
I graduated a year ago and it was not mandatory at my University.

------
EliRivers
UML diagrams. I sometimes use sequence diagrams, but almost certainly with all
the wrong symbols and so on. They're just parallel timelines showing
communication between conceptual objects.

Otherwise, all I've ever seen anyone do is take their actual design diagrams
and laboriously turn them into UML diagrams of some kind for a document. The
recipient then took the UML diagrams from that and made their own new sketches
from that, turning them into something they could easily read and understand
and that generally looked very similar to the original diagram that was
laboriously translated into UML.

My conclusion is that a UML diagram is better than nothing, but not as good as
a well-written and well-explained design. I suspect UML diagrams are meant to
be part of a well written, well-explained design, but for any given design
there seems to be a better way to draw it than UML diagrams.

------
arca_vorago
In the sysadmin world yes but not nearly enough. UML along with similar ones
like blockdiag and nwdiag interface nicely with my documentation systems in
orgmode and asciidoc.

One of my side projects is an automated nwdiag mapping system with diff's to
be able to help sysadmins coming in blind to orgs (happens way more than you'd
think, usually a 5 yr old visio file somewhere).

Anyway, in the future I see uml style things as useful for similar automation
projects, due to the simple text nature.

Also, I live in a terminal most of the time so personally prefer stuff like
nwdiag over say visio or some of the alternatives.

I also used to make repair flowcharts with seqdiag for my t1 and 2s.

------
7ewis
I'm doing a degree part-time, online, and that's the only time I've ever used
UML.

I work at a kind of graduated tech start up, so we're doing most things the
modern way. I've never even heard anyone mention UML.

~~~
kpil
It's probably best to avoid Use Cases, (R)UP, and the associated process and
document bloat, but a nice diagrams here and there can really simplify
discussions.

Class diagrams are more or less useless, and it's mostly requested by non-
professionals that can't read code. Use case diagram are more or less
irrelevant too, with just an actor connected to one or two things.

I think that it's mostly administrative (in house) systems that models reality
and complex processes that benefits from a modest dose of UML diagrams, not
typical applications.

------
seanwilson
I've not seen anyone use any UML for years to be honest except for class
diagrams or something similar to give a high level architecture overview or to
explain how major components interact.

~~~
squarefoot
I still use traditional flowcharts, though only for personal consumption :^)

------
jjgomez
They are, but perhaps agile methods who diminish the importance of documenting
have played against it. We will see what price we have to pay for this.

In my experience, people don't like to document, developers even more, and
managers probably don't like to read documents, either. However, if people
leave your company (something highly probable), how are you expected to train
the new people?

If you are working in a startup, that's not major problem: the startup may
just die and you can have fun programming in the meantime. However, if there
is company that intends to last more than a few years, ways of documenting
your system are needed.

IMHO, not using UML, or any other language, to think about our systems or even
tell others how they work is a complete mistake. It is not only for telling
others (colleagues and future workers) what the system does and why it does it
that way, it is also to save effort and realize sooner that it will not work.

So, whatever the case, training in how to explain your system to others is
required. Call it UML or whatever. And, since UML is there, it may be worth to
use it. It is not just the invention of a couple of mad engineers. You are
free to use UML as you like. And do not need to use a huge tool. Text UML is a
nice and refreshing way of looking at UML which I strongly recommend. Have a
look at [http://planttext.com](http://planttext.com), for instance.

------
BjoernKW
A few months ago I wrote this
[https://news.ycombinator.com/item?id=12879493](https://news.ycombinator.com/item?id=12879493)
and I think that's still valid.

Simplified UML class diagrams (i.e. boxes and arrows) are expedient for
explaining specific aspects of a design. Complex class diagrams trying to give
an all-encompassing picture of an application: Not so much.

Sequence and activity diagrams can be quite useful for clarifying application
state, too.

------
based2
Yes (ex: with plantUML for a just quick DSL draws) and you can use Archimate
too. ([http://www.archimatetool.com](http://www.archimatetool.com))

Are you using RUP?
[https://en.wikipedia.org/wiki/Rational_Unified_Process](https://en.wikipedia.org/wiki/Rational_Unified_Process)

~~~
quantumfoam
Thanks for linking to Archimate! I've been looking for similar software to
build out attack trees when doing threat modeling.

I've been using these in the past [1] MonoDraw and this free [2] diagramming
website. Came across [3] Draw today, although I have yet to try it.

[1] [https://monodraw.helftone.com/](https://monodraw.helftone.com/) [2]
[https://www.websequencediagrams.com](https://www.websequencediagrams.com) [3]
[https://www.draw.io/](https://www.draw.io/)

------
palidanx
For software projects with new clients, I use cacoo.com and create simple
domain and sequence diagrams to capture more complex workflows. I usually
don't tell them it is UML and say these diagrams help better express
workflows.

------
beders
I just call all my diagrams "boxes with arrows" nowadays ;)

~~~
meh2frdf
Likewise, I create uml diagrams keeping them as standard as i can, but do not
expect anyone else to know all the nuances of UML.

It amazes me the amount of time I see convoluted discussions when a simple
diagram would make it so much simpler and explicit.

------
racktash
Where I work, we use it extensively for analysing problems and designing code.
It's invaluable for communicating and collaborating on designs.

------
jbms
Yes.

If they're used as an analysis/design tool and not as a documentation-after-
the-code-is-written tool, with tools that generate code from the diagrams,
they are really powerful.

I work in Embedded Software and mainly use: Use Case Diagrams, Statecharts,
Sequence Diagrams, Component Diagrams, Class Diagrams. The 80/20 rule is true,
and I think about 80% of the value comes from 20% of the entirety of UML.

------
kbody
In the past 2 jobs even though it was just small startups with less than 5
devs, we used them in relatively critical or complex cases, but it wasn't
anything formal (e.g. for every major component introduced do this).

I personally like them, maybe because I like thinking of the big picture no
matter the task, plus we had extensive practice on uni.

------
softmodeling
More than we tend to think. Less than I'd like.

But the key to benefiting from UML is to first decide what subset of the whole
language you need and focus only on that. Very few companies will find a use
for the 13 types of UML diagrams.

~~~
LeonStarr
And have an actual methodology and process for its application.

------
Jugurtha
Just for memo (for me or someone else):

For Python code, one can use pyreverse to generate UML representation.

------
edimaudo
Of course! Great design starts with UML.

