Ask HN: Is UML still relevant today?

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

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?

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.

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

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

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.

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.

No.

Proof:

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.

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.

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/ 2: http://www.eclipse.org/sirius/

Disclaimer: I work for the company behind Eclipse Sirius.

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

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.

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

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.

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.

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.

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.

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.

No.

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.

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.

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.

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.

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 and http://www.amazon.com/exec/obidos/ASIN/0750687061/quantumlea...

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

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.

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.

Here's another way of putting it:

Are squiggly boxes with lines and words in them still usefull? And maybe we should have some convention around them squigglies?

Well, considering you're reading this on a screen filled with squiggly boxes and lines and words, yes, I'd say that much is still useful.

The advantage of UML, as with any standard, is that it is a universal way of drawing those squiggly lines and boxes. If you've ever tried to draw a software representation, you'll realize its actually quite difficult to do.

Until language and conventions stop being useful, UML will remain.

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.

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.

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

Only for consultants for milking money from clients.

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 (state chart is at bottom)

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.

Was it ever "relevant"?

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.

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?

No. Except maybe sequence diagrams.

No.

Yes!

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://oro.open.ac.uk/35805/

(via Erik Meijer on Twitter)