I teach software engineering at undergraduate level and I have a question to UML practitioners.

Most software engineering textbooks take a serious effort in covering UML diagrams. But on the other hand, I heard from many graduates that UML does not seem to be used in the trenches anymore.

What UML diagrams are still being widely used in professional practice, and why ? Are there diagrams that are no longer used and why ?

N.B: In order to avoid opinion based debates and discussions, please illustrate your answer with factual and objective elements (if possible, verifiable) or neutral observations on personal experience

  • 10
    We don't know. We don't conduct surveys to find out things like this. – Robert Harvey Jan 2 '17 at 0:17
  • 3
    Your question is primarily opinion based. I'm using UML a lot, but you'll find quite a number of people responding "UML is dead". – qwerty_so Jan 2 '17 at 1:44
  • 1
    softwareengineering.stackexchange.com/q/305031/40065 is a very related question (nearly duplicate, but formulated very differently) – Basile Starynkevitch Jan 2 '17 at 2:19
  • 1
    But perhaps UML is not much used anymore (in real life)? That was my point! Then the answer to your question would be : none . – Basile Starynkevitch Jan 2 '17 at 2:26
  • 1
    When UML was young, Martin Fowler wrote the book UML distilled, which became a desk reference for a lot of programmers. Some years later Martin wrote short practical application notes UmlAsSketch, UmlAsNotes, UnwantedModelingLanguage. – Nick Alexeev Jan 2 '17 at 3:36

From the many diagrams proposed by UML, class diagrams and sequence diagrams are still widely used, certainly followed by state diagrams:

  • they can easily be used on white boards to elaborate and discuss design before jumping in the code
  • they allow to convey very quickly an overview which the code alone doesn't give so easily, and there's no viable substitute to it.

I think use-case in real life are used in a more occasional manner. In big projects, with several hundreds of use-cases, diagrams are painful to draw and provide little benefit over a tabular form. BPMN for process design, user story mapping, or event tabular decomposition in a Cockburn style are much more used. Why ? Because they are more easily shared with business users to work out efficiently the requirements.

I am sure that their are places where UML is still heavily and systematically used. I don't imagine that aerospace software or nuclear powerplant control systems are produced without the full set of UML documentation. But I believe it's more the exception than the rule.

I feel confirmed in this statement when looking in the bookshops. A couple of year ago, you could find plenty of books on UML 2.0. Nowadays, if you're looking for UML 2.5, the choice is rather restricted. Worse: many authors don't even make the effort to revise their former books to keep them up-to-date (example: Fowler's nice "UML distilled" introduction which still dates from 2003 with UML 2.0 and same for Ambler's "Elements of UML 2.0 style" !).

I don't think that this decreasing trend will change, looking at the generalization of agile and its promotion of "Working software over comprehensive documentation".

In the end, I'd very provocatively claim that the modeling methods appear to follow a darwinistic scheme: only the most suitable diagramming technique will survive, those that provide a clear advantage over informal approaches (e.g. the napkin illustration) and detailed code (e.g. why draw an A1 activity diagram, when the corresponding code could fit on an A4 sheet?) ;-)

  • See also agilemodeling.com – xmojmr Jan 2 '17 at 9:26
  • 4
    "why draw an A1 activity diagram, when the corresponding code could fit on an A4 sheet?" Perfect. – nbubis Jan 2 '17 at 9:31
  • Well from my own experience, in quite some company modelisation is saw has a waste of time, only coding ... – Walfrat Jan 2 '17 at 21:57
  • @Christophe What is a "napkin illustration"? – rugk Apr 4 '19 at 8:24
  • @rugk I was referring to the simplified informal diagrams that you draw when discussing the design at lunchtime (I know it’s a bad habit) on a paper napkin or a paper table cloth, that everybody understands and that you sometimes take back to the office when you realize that it actually solved your problem. – Christophe Apr 4 '19 at 9:32

On the other hand, I heard from many graduates that UML does not seem to be used in the trenches anymore.

They are all used in practice. But not everyone uses them. Some people eschew design entirely, and leap straight into coding. You cannot rely on anecdotal evidence to know what "everyone" does.

Tools like UML work best if you use when they add value; e.g.

  • for larger projects
  • for complicated parts of a project
  • when the project design requires input from multiple people

Creating them just for the sake of doing them (or because the process says you must) is not productive. Best practice is to be selective on what you diagram, and what kinds that you use. Use UML when and where it helps ... and that includes being selective of the kinds of UML diagrams you use.

Also ... UML was primarily designed as a design tool. It is not so effective (these days) as a documentation tool. Typical IDEs help you to visualize many aspects if a code base structure on the fly. This is often better than relying on UML diagrams that may have become out of date / inaccurate.


UML is still used in the trenches. But, as always, people use a subset of it. Which subset is subject to the problems at hand.

UML comes in many versions. But, as always, people use it's symbols informally and inconstantly.

UML is how we understand much of the patterns books out there. It's also one of the ways we communicate on the whiteboard. It isn't gone. But it's never going to be used as formally as code.

Rather than producing students who can correct any UML diagram to comply with UML version 2.5, or whatever is the latest, produce students that can understand what the diagram is trying to communicate even if it isn't fully consistent with a particular UML version because that's how UML is used in the trenches. It comes in weird local dialects, mixed with other systems, and sometimes we just make up our own symbols.

Teach them that it's ok to ask what things mean. Don't teach them to correct others that are breaking some imagined rules. We're just trying to communicate here.

The best use I've seen uml put to is letting a new programmer show us their plan to solve a problem. It quickly showed us the parts of the system they've neglected or didn't realize existed.

I've also worked places that required UML even when not needed. We were always using the same pattern so it was just a formality. We got to the point that we just photo shopped new names into old diagrams. Don't encourage this kind of use.

But I think we all know there's a difference between the normal arrow head and the open arrow head. Right?


I'm going to be specific according to my experience: - Deployment diagram - Sequence diagram - Class diagram Those three are the most used in any project, they provide real communication value with the team at different levels.

Not the answer you're looking for? Browse other questions tagged or ask your own question.