
Ask HN: Is UML still relevant today? - beltsazar
Are UML diagrams worth to be designed? Are top technology companies still using it?
======
jashmenn
If you learn only one diagram from UML, take the time to understand and use
Sequence Diagrams [1].

Being able to break down an interaction into a sequence diagram (especially
between 2 or 3 servers) is a powerful thought tool for specifying interactions
and its easy for people to understand.

[1]
[http://en.wikipedia.org/wiki/Sequence_diagram](http://en.wikipedia.org/wiki/Sequence_diagram)

~~~
endgame
zenbowman's reply is [dead]. Why?

~~~
dangrossman
The most common cause of individual [dead] comments on an otherwise not-banned
account is double posting. If you accidentally submit the same comment twice,
the second one is killed. Since both show as live on your screen, when you
delete one of the duplicates, you may delete the one that's live to everyone
else, while leaving the one that's dead to everyone else.

~~~
dang
I'm impressed that you got this exactly right. We've made a few fixes to try
to plug this hole, but it unfortunately still happens.

------
programminggeek
You should read about it just so that you can read the acronym OMG over and
over again. It makes all the UML related documentation hilarious. It's OMG
this and OMG that.

For example, check out this 100% legit Wikipedia reference:

OMG (2011). OMG Unified Modeling Language (OMG UML), Superstructure, V2.4.1,
p. 507.

OMG is short for Object Management Group, but the acronym has obviously not
aged well, so what we are left with is a really funny, but totally
unintentional joke. Like, check out these certificiations:

OCEB - OMG Certified Expert in Business Process Management (BPM)

OCUP - OMG Certified UML Professional

OCSMP - OMG Certified Systems Modeling Professional

OCRES - OMG Certified Real-time and Embedded Systems Specialist

Who wouldn't want to be OMG Certified?

------
patio11
UML is used in many companies, but learning it is _probably_ not the highest
leverage use of your time. Be forewarned that it comes out of the same general
regions within the enterprise as WindowAdapterFactoryServiceLocatorFactory.

Personally, in about a decade of programming, I've only had call to say "You
know what we need right now? A UML diagram, that's what." about two or three
times, and it is _always_ about a sequence diagram for fairly complicated
protocols.

------
adrianhoward
It depends where you work and who you work with. I'd say only about a quarter
of the places I've worked since UML became popular have used them at all (yes
- I'm an old f __k who can remember before UML ;-).

Despite what some have said here I don't think using UML is an sign of
technical chops, or otherwise. It's just a tool. Some people use it sensibly.
Some people use it stupidly. Thus has it ever been.

People drew and draw representations of data, structure and flow long before
UML was around, and will continue to do so in years to come.

People wasted a bunch of time writing diagrams which would have been more
effectively spent writing code before UML was around, and will continue to do
so in years to come.

People wasted a bunch of time writing code when they should have spent five
minutes drawing a diagram to make sure they were building the right thing
before UML was around, and will continue to do so in years to come.

I'd say the more important skill is being able to talk about data and
structure and flow visually - and to know when the right time to do that is.
UML is a nice common language to throw on top of that skill.

But UML is certainly not used everywhere. Never has been.

------
Rabidgremlin
TL;DR Yes but only the basics and only certain key diagram types

Of course it is! Now the verbose, overblown specs are only really useful for
propping up your monitor (see
[http://www.omg.org/spec/](http://www.omg.org/spec/)) but fundamentally UML is
all about a common way of discussing code, patterns, architectures and
algorithms visually.

It's kinda handy to be able to sketch out something on a whiteboard and have
everyone in the room be able to read what you have drawn.

[Showing my age] I was around before UML and there were any number of
conflicting notations used to describe things... total chaos.

There are like 14 different types of UML diagrams which is complete overkill.
You only really need to understand a few (at a high level) and you are
sweet...

Roughly in order of usefulness:

* Sequence diagrams

* Deployment diagrams

* Use case model

* State diagram

* Activity diagram

* Class diagram

See more [http://creately.com/blog/diagrams/uml-diagram-types-
examples...](http://creately.com/blog/diagrams/uml-diagram-types-examples/)

~~~
wwkeyboard
I mostly agree, but I would qualify this with saying you don't need to know
exact UML. I wouldn't worry about filled in triangles vs. diamonds, just the
big ideas.

Like everything enterprise, before it UML was wrapped in a three ring binder
and sold by consultants it was created to solve a problem. That problem is; at
the beginning of a project(or at cross-team-collaboration-bs-meetings) you'll
have an idea in you head, a fist full of markers, and an empty whiteboard. How
do you go about explaining that idea to everyone in the room? UML was an
attempt at standardizing some of the boxes-with-lines schemes everyone
invented.

------
jfim
It really depends what you mean by designing UML diagrams. From my personal
perspective, UML is mostly a communication language, so that certain abstract
concepts (class structures and hierarchies, message passing sequences, etc.)
can be communicated using a common language. For example, if two people are to
work on the same piece of code or two pieces of code that are to interact
together, being able to sketch a quick class diagram or a sequence diagram so
that both parties can understand what is happening is much easier than writing
it in an unambiguous textual representation.

If you're asking about designing UML diagrams for tools that will
automagically generate your application from diagrams, then I think that's
definitely a different question. I haven't looked at what the current state of
the code generation tools are, but when I looked at it several years ago, it
didn't look very promising.

------
smoyer
I'll admit it ... I drank the UML cool-aid and thought that someday we'd have
code-generation directly from the diagrams (we do in part) and round-trip
engineering (changes to the code automatically reflected in the diagrams).

Since then, I've become a lot more realistic and use the diagrams when they're
the best method of communicating a conceptual or concrete thought. I rarely
use class diagrams, but I find myself using sequence diagrams and deployment
diagrams a few times a month. Occasionally I also use Use-Case diagrams when
there's more complexity than can be easily included in a single user story.

------
Theodores
No.

Proof:

[http://www.google.co.uk/trends/explore#q=%2Fm%2F07x3g&cmpt=q](http://www.google.co.uk/trends/explore#q=%2Fm%2F07x3g&cmpt=q)

Interesting though, Grady Booch - the man who wrote the Ada text book I had to
learn for university - is behind UML. Glad it failed.

~~~
Rabidgremlin
That is not exactly an accurate portrayal.

For instance add object oriented or test driven development:
[http://www.google.com/trends/explore#q=%2Fm%2F07x3g%2C%20%2F...](http://www.google.com/trends/explore#q=%2Fm%2F07x3g%2C%20%2Fm%2F05prj%2C%20Test%20driven%20development&cmpt=q)

I would say that it's much more likely that UML is just one of the many tools
that developers use, it just isn't generating any "buzz"

------
MortenK
Depends on how you define top technology companies, but many large software
companies (5000+ employees) uses UML as a part of their systems architecture
deliverables.

Whether they are worth being designed will very much depend on who you ask.
The architect who spends a lot of time on designing them will of course be
very much in favor. He might feel they properly communicate his architecture.

Certain business types might favor them, on a more simple account - they look
deliciously technical and can be used to persuade a customer "we really know
what we are doing".

My personal opinion is that certain diagrams can be useful. In general though,
way too much time is wasted on doing these diagrams, which aren't going to be
at all representative of the end system.

It's not a good communication tool, and it'll in most cases be hopelessly out
of date just a few weeks or months into the project.

UML also smells of a top-down approach where the star architect is sitting in
an ivory tower handing down blueprints to lowly developers. That kind of
approach goes against what I believe about successful software development.

There's useful elements in UML and you definitely won't be worse off if you
understand it. But I do not think it's in any way required unless your
aspirations are to be developer /architect #2032 in BigCorp.

But again, it'll depend on who you ask.

------
sbegaudeau
Lot of companies are moving away from UML but not away from modeling tools by
using domain specific languages (DSL) instead of a language like UML which
tries to please everybody. The Eclipse Foundation hosts lot of domain specific
tools like Xtext (1) for textual DSL or Sirius (2) for graphical DSL. Both
tools are even compatible since they are using the same underlying framework,
the Eclipse Modeling Framework (EMF). With those tools, and others (have a
look at all the modeling tools in the Eclipse Foundation), you can build a
"development environment" for your own domain with your dedicated editors
(syntax highlighting, completion, error detection, etc) and designers.

1: [https://www.eclipse.org/Xtext/](https://www.eclipse.org/Xtext/) 2:
[http://www.eclipse.org/sirius/](http://www.eclipse.org/sirius/)

Disclaimer: I work for the company behind Eclipse Sirius.

------
nfmangano
There was a presentation that tackled this question at the most recent ICSE
conference. Here's the paper: "UML in practice",
[http://oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf](http://oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf)

The author interviewed people from 50 different major companies, and found
people's use fit within the following:

Category of UML Use, Instances of Declared Current Use

no UML, 35

retrofit, 1

automated code generation, 3

selective, 11

wholehearted, 0

From the conclusion: "The majority of those interviewed simply do not use UML,
and those who do use it tend to do so selectively and often informally."

In my own experience and research, people draw extensively, but have their own
shorthand for writing things specific to their domain.

------
mahmud
No. I have never known anyone that uses UML, outside UML coaches.

~~~
platz
You know UML coaches?

~~~
mahmud
Read your company's info@ email address; all sorts of training consultants are
lurking there.

------
bane
UML is pretty lousy as a formal design language, but it's about the best we
have. It's a pretty good communication tool though and a pretty good tool for
documenting an existing system for later reference. Not all of the diagram
types are equally useful, some are better than others. Sequence diagrams are
really useful for example, but use-case diagrams are usually small enough that
they aren't necessary.

------
kfcm
Simple answer: it depends.

Different companies doing development (pure tech to Fortune level
corporations) all have different requirements and environments. A small, fast-
pivoting, ever changing start-up isn't going to need, want or have the time
for all the detailed documentation a large, regulated Fortune X company will
require.

That said, I think a knowledge of UML is beneficial to all levels, if just
having a common modeling "language".

Start-ups can use selected diagrams (eg, sequence, deployment, component) to
develop, work out and "document" the high-level vision, and maybe major bugs.
Keep them light on details and flexible. Like a paper road-map, they show only
the major things, and don't require much time to update.

Large and maybe regulated corporations (and even start-ups in regulated
industries) will not only need, but require deeper levels of detail. Class,
state and other diagrams. They get into the city-street level maps. But again,
they can afford the levels of bureaucracy staffing (like "enterprise
architects") required to maintain all the documentation.

------
camus2
Yes,it helps communicate ideas between engineers and is not bound to any
paradigm. UML can even be a great tool to communicate between devs and non
devs.I ask my clients to draw actor diagrams all the time. It's often better
than a long paragraph of text.

I'm not sure how any big team can work without using some UML diagram of some
sort. SCRUM boards dont help writing code.

------
osteele
Outside of sequence diagrams:

Over many years as a indie developer, corporate developer, architect,
engineering manager, product manager, technical founder, and CTO, I've never
found the specifics of UML (which arrows and box types mean what, or its
distinctions between different types of containment and relationships) to be
useful. I've never been in a room with someone who admitted knowing UML, or
where UML made a discussion shorter or easier. I've never seen architecture
diagrams or sequence diagrams, in whitepapers, technical documentation, or
engineering discussion, use UML. I'd hoped that at the least UML would
introduce a shared vocabulary, but within my experience it hasn't.

Reading Fowler's “UML Distilled”, on the other hand, did teach me a lot about
software architecture and design, and it also taught me to read the rest of
Fowler's work, which has been equally rewarding.

~~~
andrewcooke
just want to second uml distilled. if you need to use uml you should read it -
it's very slim and very practical.
[http://martinfowler.com/books/uml.html](http://martinfowler.com/books/uml.html)

also, uml with a tool like enterprise architect (which is basically a set of
gui interfaces onto a database, where you construct a design in the database
using the views, and are forced to be consistent) is very different from
sketching a few diagrams.

it's not for me, but with a good tool you can see the attraction in certain
scenarios.

------
sergiotapia
Nope, learned about it during college and had to present every project I made
using it (ugh...) and I haven't used it -once- in the real world. Nobody
cares.

Learn how to diagram sequences and that's about it. The rest is just a fancy
way to charge $150/hr consulting fees for 'architecture.' Utterly useless
these days.

------
tptacek
No.

------
marpalmin
In embedded software development some companies use Rational Rose (state
digrams) to specify behavior and perform model checkings. So YES top companies
use it but not the kind of top Rails or mobile software company that you
usually see in HN. And No it's not used a lot.

I think UML is a nice communication tool for the general purpose development
(just the basic syntax of UML). But not more than that, please don't specify
an app in UML, is just bullshit.

However, in embedded software development it makes sense to specify the system
using UML (like some very important controller software). Why? Because the
system is very small (so you can model it) and you need a high certainty that
it will perform as it it supposed to (you can perform model checkings and
validation).

Otherwise UML is just a nice way to have a common language in the whiteboard.

------
specialk
I think I spent three years in college getting examined on UML diagrams of all
sorts. There is so much detail you can put into a UML diagram that means so
much, like arrow heads mean class A implements interfface B. I have never seen
anyone in work life ever use that much detail. I have done 100s of sketches of
class diagrams and sequence diagrams but never have I made one that would fit
the rigid rules of UML diagrams.How can there be so many rules for drawing
lines between boxes?

I once did create fully compliant UML diagrams for a requirements document.
The next day half the team emailed me back asking what all the box types,
arrow heads and broken lines meant. Honestly, simple sketches with annotations
have served me so much better than following the rigid rules of UML.

------
sshine
No. TL;DR: Drawing is useful, UML is not.

For database designs, textual schemas, E/R diagrams or plain SQL are
sufficient. I've drawn plenty of state diagrams without crediting UML
handbooks. E/R diagrams can double as "class diagrams" in the sense that you
don't need all the complexity of properties and methods in a diagram to convey
which classes exist and how they're related.

People who think that drawing bubbles with arrows between them is a language,
in more than a philosophical-linguistic sense, should probably take some more
certificates.

To be fair, and to repeat some answers I've read so far: Of course, some
diagrams are very useful. But to credit UML because individuals find it useful
and necessary to draw things is stretching it.

~~~
collyw
Yes, but it is also useful having a standard way to express some of the things
in your diagram.

------
HelloNurse
I work for a very object-oriented customer, and I find class or object
diagrams useful (for example, to take notes about an unfamiliar system being
explained to me, like expressing precisely and concisely that Permissions are
granted either to Employees or Groups of Employees, and not associated to the
Employee's or Group's parent OU directly) much more often than sequence
diagrams (typically used to document boring and straightforward odysseys of
method calls through layers and layers of indirection, not interesting
protocols).

All non-bullshit UML diagram types are going to be valuable sooner or later in
one's career; basic familiarity with all of them is a useful language skill.

------
mokelly
State charts can be a powerful method for rapid prototyping of embedded
systems if you use a minimalist code generation tool like Quantum Leaps QM.

It is a little difficult to get a hang of, but with familiarity it greatly
increases the speed at which I can iterate on designs.

See: [http://state-machine.com/qm/index.php](http://state-
machine.com/qm/index.php) and
[http://www.amazon.com/exec/obidos/ASIN/0750687061/quantumlea...](http://www.amazon.com/exec/obidos/ASIN/0750687061/quantumleap06-20)

Note: I am not affiliated with Quantum Leaps, but I have found the tools to be
very useful.

------
contingencies
As an illustrative anecdote, I spoke at _Code Generation 2010_ in Cambridge,
UK on real world DIY code generation from found models in a normal software
practice. The event was attended by people from the Object Group, who are
responsible for UML. I used the phrase _UML Hell_ as something to avoid in my
talk, and it garnered much amusement and understanding. I was even audience
rated near highest for a first time speaker in the history of the event and
invited back to speak again... but it's a long way to fly from Asia! I don't
use UML today, but encourage documentation and automated diagrams where
appropriate.

------
ZeppelinDePlomo
You don't "design" diagrams, they are design tools. The point is communicating
and formalizing models to iterate ideas more quickly and cheaper than coding
or prototyping (of course, they work up to a point). They are ways of
visualizing interactions, states, operations and so on, the "heart", the main
"idea" or "the point" of a system in a way that implementation details don't
get in the way of the main innovation and/or core value added.

It's a really useful skill.

...but "UML" as a brand to add to your resumé is pretty much useless.

------
wglb
I don't think so; but there may be disciplines that find benefit from it.

However, there is one element that I still use and find very useful--time
sequence diagrams. Like tracking web requests and responses and communications
with back ends, for example.

And often used, but not really exclusive to UML are state diagrams. Certain
problems are elucidated nicely that way.

There may be some enterprise, governmental, or aerospace environments that
benefit from it or are required to use them.

------
codyod
Like a few have pointed out, it depends, but even then not the whole beast.
Certain few diagrams are useful in the early stage, where having diagrams is
fastter to communicate ideas and concepts across. Other than that UML is a
wastage of time as the software base evolves - it cannot pace itself well to
that dyanamism and agility; it has no inbuilt dialectical characteristics.
However, document core stable parts could be done. I personally do not know
any body who does though.

------
loumf
Learn to sketch UML (not use it as a formal development language) -- it's
incredibly useful if you don't get too caught up in formalities. "UML
Distilled" by Martin Fowler is a tiny book that teaches you enough to sketch
it.

I made a UML cheatsheet a while ago for a talk:

[http://loufranco.com/blog/uml-cheatsheet](http://loufranco.com/blog/uml-
cheatsheet)

------
neduma
Only for consultants for milking money from clients.

------
tlarkworthy
Yes ... hierarchical UML state charts are best in class for their niche,
sequence diagrams are useful too. I use both for a Firebase abstraction layer:
[https://github.com/tomlarkworthy/firesafe/wiki/Send-
Item](https://github.com/tomlarkworthy/firesafe/wiki/Send-Item) (state chart
is at bottom)

------
talles
UML is something that shouldn't be avoided nor encouraged. Is a mere tool to
represent code in a graphical and compact manner.

"Worth to be designed?", depends on your situation, you tell me. If you don't
know if you need you probably don't need at all.

------
mrpickles
Was it ever "relevant"?

------
joshdance
Diagramming out a system can be very useful. Strict UML is no as important
today. I learned a lot of UML in university and have never used it once. I did
a rough diagram of a process once, but that was just for communication.

------
fjordan
If not UML, what do you recommend for most effective communication?

ERDs? Documentation tools? Or do you simply tell the engineer to read the
code?

~~~
sshine
Yes, just read the code (and whatever textual documentation comes along with
it). The best I can hope for is a set of OO interfaces that is really well-
described in their comments. And some oral presentation/walkthrough. And some
small tasks to get me acquainted with a new codebase. If there's a large
library, some HTML-based documentation, perhaps even with examples, is very
fine.

------
saltylicorice
No. Except maybe sequence diagrams.

------
gburt
No.

------
AxisOfEval
Yes!

------
archonjobs
Here are a couple recent research papers that basically say no, UML isn't used
much in practice.

[http://www.gorschek.com/doc/publications_files/GorschekTempe...](http://www.gorschek.com/doc/publications_files/GorschekTemperoAngelisModeling20140327.pdf)

[http://oro.open.ac.uk/35805/](http://oro.open.ac.uk/35805/)

(via Erik Meijer on Twitter)

