Which UML diagrams are still being widely used?

Question

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

Answer 1

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?) ;-)

Answer 2

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.

Answer 3

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?

Answer 4

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.