When I started our software architecture course about eight years ago, I was happy to find out about a book series on the architecture of open source applications. I was thrilled: Not only code, but architecture descriptions! I expected great material for my course. Sadly, I had to realize that none of the chapters in this book series used UML, a staple of most academic software architecture courses.
Does this mean UML is not used in practice? Of course not. It is just not used in open source projects. This doesn’t imply that UML doesn’t have its uses. However, they may not be what tool vendors are telling you.
My most certainly non-representative observation of how people actually use UML comprises the following four situations:
- communication and discussion
- documentation
- specification
- round-trip engineering (code generation)
I’d say about 95% of all uses of UML are in front of a whiteboard, where people discuss object-oriented designs using class models. These class models look like UML and have probably been inspired by the notation. They will never compile, however, because these models are incomplete or even incorrect. This doesn’t matter as long as the lines and boxes aid communication between developers. Nothing wrong with this.
The next 4.5% of uses of UML are in documentation. Occasionally, during my corporate days, I saw people trying to document an architecture after the fact using UML models of various sorts. This documentation was almost always already out-of-date after it had been finished, because the system and long moved on. But a check-mark could be checked, which was the purpose of the exercise, whether required by internal rules or some consulting contract.
An additional 0.5% of uses of UML serve as specification in contracts. This invariably is based on use-cases, Jacobson’s contribution to the three amigo’s work back then when. Whether a good choice or not, it hardly dominates the industry, as prose or sentence templates still reign supreme.
A final 0.01% of uses of UML is in code generation as part of round-trip engineering and as far as I can tell it only exists in vendor brochures and research projects. As soon as it hits the real world, the lack of semantic precision of UML and the gaping holes that vendor-specific implementations have to bridge kick in. When the vendor eventually goes out of business or sun-sets the product, users are left with a final one-way trip to code.
One more comment: Percentages don’t mean impact. That one working round-trip engineering project that someone may be able to point us to, may well be more important than any use oF UML in contract specifications (I don’t know, I’m not aware of such a project). Users or customers should realize, however, that they are effectively funding research that will hopefully benefit the world as we lift the levels of abstraction in programming. Just don’t want to tell your CFO.
Leave a Reply