This post is intended as support material for another post of mine; see Towards Authoritative Software Design.

The Universal Modeling Language (UML) (Wikipedia) was intended to be a standard notation for expressing software designs, and to replace the multitude of ad-hoc notations that software architects have been using on various mediums such as whiteboard, paper, and general-purpose box-and-arrow diagram-drawing software. The idea was that by following a standard notation which prescribes a specific way of expressing each concept, every diagram would be readily and unambiguously understood by everyone.

It has miserably failed.

(Useful pre-reading: About these papers)

UML is probably very close to the top of the list of things that everyone mentions, but nobody uses, and this is due to a number of good reasons:

• It is incredibly comprehensive, to the point where its sheer size acts as a very strong deterrent to most people attempting to learn it. There are about 20 different types of diagrams for different purposes, each with its own complete set of meticulously detailed notation and rules. UML only begins to make sense once you realize that it has mostly been an effort to catalogue every imaginable type of diagram used in software development, and to standardize the notation of every single one of them. However, the vast majority of those types of diagrams are anywhere from largely irrelevant to completely irrelevant to our day to day job, and even if you pick a single type of diagram that you think you might have some use for, and decide to learn just that one, the notation for even a single type of diagram is still so comprehensive that the task is daunting.
• Most of UML is so rarely useful that it is not worth the learning effort. In the extremely rare event that a software development team is to have a meeting in which they could benefit from having an Interaction Overview Diagram to point at, it will be a lot easier to use some ad-hoc but intuitive notation to get the point across, than to only schedule the meeting after every attendee has completed a UML course to refresh upon the intricacies of the UML Interaction Overview Diagram.
• The type of UML diagram that has received most attention in the software engineering profession is the UML Class Diagram (see Wikipedia) which deals with representing a class, and its relationships with other classes. Unfortunately:
  • The UML Class Diagram insists on prescribing a very specific type of notation for every little aspect of a class, and this notation is not always intuitive, thus posing the same obstacles to understanding as posed by program code written in apocryphal syntax and convoluted structure: in both cases, it is all jargon. This might not be an issue for those who have already gone through the trouble of learning the jargon, but the uninitiated are bound to question the usefulness of the entire exercise.
  • The UML Class Diagram prescribes its notation in excruciatingly meticulous detail, so there is no abstraction, and no information hiding: the amount of information contained in a UML Class Diagram is roughly equivalent to the amount of information contained in a C or C++ header file, or in a Java Interface, so there is virtually nothing to be gained by looking at one vs. the other. This in turn seriously begs the question of why should we be doing double book-keeping.
  • The UML Class Diagram is much too low-level and too finely detailed to be pertinent to software design, where the unit of interest is the component, corresponding to an entire module, rather than an individual class.
• UML is mostly used as documentation, meaning that its role tends to be indicative or suggestive, and usually non-enforceable and non-materializable. This means that mistakes made in the use of the meticulously detailed notation generally go unnoticed, or might be noticed by colleagues, but not by some automated validation tools, because for most types of UML diagrams, there exist no such tools.
• UML is trying to solve a problem that does not exist: When a human needs to communicate something to a machine, this does admittedly have to be done in an inambiguous fashion, which makes special notation, i.e. jargon, necessary. However, when there is no machine involved, and a human simply needs to communicate something to other humans, what matters most is to get the point across, so jargon is actually undesirable, despite the unambiguousness that it would bring. That is okay, because humans are perfectly okay with ambiguity; as a matter of fact, humans thrive in ambiguity. So, UML is an attempt to apply a rigid engineering discipline to a form of communication which is fine as it is: free and fluid. (One of the "Three Amigos" that created UML had a military background; coincidence? maybe.)
• In an attempt to make UML more pertinent to the software development process, some UML tools offer some automatic code generation features. I hate to break it to the creators and users of such tools, but automatic code generation is almost always a bad idea, because each time the design changes, code generation must be re-applied, but this invariably results in the following bad things happening to code that has already been hand-written:
  • Hand-written code is overwritten by auto-generated stubs and thus forever lost; or:
  • Hand-written code does not compile anymore due to dependencies on auto-generated definitions which have now changed; or, more often:
  • Both of the above.
• The idea that you can apply automatic code generation once and never repeat it stems from the "all design up-front" doctrine, which may have been strong back in the early 1990s, when the foundations of UML were being laid down, but as it turns out, it was one of the most stupid ideas that humans ever had; it suffered its well-deserved death in the early 2000s, and it has been dead since then. That was more than 20 years ago.
• From the plethora of diagram types offered by UML, the only one that could perhaps be useful in our daily jobs is the UML Component Diagram (see Wikipedia) but there exist no tools that I am aware of that are capable of either guiding the composition of such a diagram from existing software components, or materializing such a diagram into a running system. Furthermore, if any such tools were to be introduced, they are unlikely to be well-received, because by now people have developed a distaste towards UML and anything associated with it.
• UML literature follows a standardspeak¹ writing style which is not just incomprehensible, but actually annoyingly incomprehensible. For details, keep reading.

So, I tried looking up the term "collaboration" in UML literature, and here is what I found in "IBM DevOps Model Architect" documentation:

In UML diagrams, a collaboration is a type of structured classifier in which roles and attributes co-operate to define the internal structure of a classifier.

There are two problems with this:

• The definition depends on other definitions. This happens everywhere in UML. So, in order to understand a certain term you first have to understand other terms, and quite often the definitions make circles, so in order to understand anything you first have to understand everything. Essentially, you have to have superpowers.

• This kind of looks like a recursive definition. They may be implying that there is something hierarchical in the nature of the concept, but they are not saying it. This is an example of a particular kind of wooden language which is written not with the goal of being understood, but instead with the goal of not being wrong. Note how convenient this is for the author: since nobody understands it, nobody can tell whether it is wrong or not.

Okay, let's look at the next sentence:

You use a collaboration when you want to define only the roles and connections that are required to accomplish a specific goal of the collaboration.

Surprise! recursion again.

This is the point where I, personally, am out.

I am done.

I am fucking done.

And that's how it goes with UML.

To summarize:

UML is insufferably baroque.

It should have never been, and it should cease to be.

It should be let go gently into the good night.

Mandatory Grumpy Cat Meme. "UML: I hate it."

Cover image: The UML logo, by Object Management Group®, Inc. from uml.org; Public Domain.