The other day I started another set of technical specifications at work. Trying to do things properly, I started with a simple use-case diagram to sum up the operationnal goals of the system. Two actors, three use-cases and I'm stuck. How to represent that in a particular use-case, the system delegates the control to another actor? I was thinking there was no problem, UML is open, there are a lot of examples on the internet, and the spec is readily available. There are a lot of exemples, most of them are in PDF which makes a quick browsing near impossible. But worse, those examples are contradictory. Some of them present a use-case as a sub-system, others as an action on the system. They use different kinds of relationships between actors and use-cases, with little coherence. So, let's see UML specifications after all. Since I used Poseidon CE for this little work (and since I work for a software firm, that means we have no paid license for doing our job) and Poseidon seems to handle UML until 1.4 (1.5 current), I went for the 1.4 spec.

Here we are, page 134:

The Use Cases package is a subpackage of the Behavioral Elements package. It specifies the concepts used for definition of the functionality of an entity like a system. The package uses constructs defined in the Foundation package of UML as well as in the Common Behavior package.

The last time I've seriously worked with UML was in year 2000. At that moment, UML 1.3 was hardly final and most of people were working with the informal UML 1.2, which was a "cleaned-up" revision of UML 1.1. I didn't remember the spec was so obscure, so quick check and... same paragraph. I didn't realize before the UML spec was so convoluted. The thing is a nightmare to read, it's not a specification, it's a philosophical orientation on Object Oriented Modeling. The spec depends on OCL to be read ! While many language specifications around here depend on some kind of BNF, which is a fairly readable language with few attached semantic, the OCL specification is a 48 pages beast. Back in year 2000, I viewed UML as a big forward lap, as I was accustomed to IDEF0, flow charts, class diagrams, functions call tree and organigrams... But at least, each of those things had well defined semantics, even IDEF0 with its subtleties. Furthermore, each of those diagrams was a tool for communication with the customer. I think this is not the case anymore with UML.

What I do see most of the times presented as UML diagrams don't even respect what could be perceived as the spirit of UML. But we have to throw big names at the customer's face, even if the little schemas have nothing to do with UML. How to communicate efficiently when the UML Notation Guide is 176 pages long in version 1.4? Of course, when criticizing UML diagrams, often we are faced with "UML strong point is the metamodel". I'm forced to say that the customer doesn't want to pay for using the metamodel. Bertand Meyer (Eiffel's father) said in 1998:

UML is too complex to be of much help in practice ... all the more remarkable when we realize that UML is only a tool for Analysis and Design - in the end you still have to write the program.

And in an article from the same person back to 1997, we can see his main points of dissenssion. This article has been commented several times, and many of the mentionned points have been solved... the results lies in the 176 notation pages of UML 1.4. So the situation is: companies are earning money with UML with books, conferences, training, training, training and training. The "UML" word is widely known across our customers, and most of the ones I frequent use UML as the best way to finish the annual budget and to justify they need more money for the following years. UML is no silver bullet. But like Struts today in the Java world, it's good to put on a resume, even if that only means that you know how to read and write a class diagram. Perhaps we don't need those rich semantic models after all?