The Unified Modeling Language is the most used software modeling language (which doesn't mean it's largely used, just that it is the most common among all the other languages).
As such, everybody has its own opinion about it but I think it's especially interesting to collect some UML opinions expressed by some of the people that were directly involved in the creation of the language in the first place some twenty years ago.
Grady Booch's views on UML
The UML should be used to reason about alternatives. Put up some diagrams. Throw some use cases against it. Throw away those diagrams then write some code against you best decision. Repeat
When we began with the UML, we never intended it to become a programming language
We never got the notation for collaborations right. Component and deployment diagrams needed more maturing.The UML metamodel became grossly bloated, because of the drive to model driven development. I think that complexity was an unnecessary mistake.
I rather still like the UML 🙂 Seriously, you need about 20% of the UML to do 80% of the kind of design you might want to do in a project – agile or not – but use the UML with a very light touch: use the notation to reason about a system, to communicate your intent to others…and then throw away most of your diagrams.
one should only use a graphical notation for those things that cannot easily be reasoned about in code
and a few recent tweets as well
Grady Booch@grady_booch
IMHO the UML standard went off the rails when it was made overly complex to support MDD...the UML is not a prog lang twitter.com/siliconglen/st…14:03 PM - 02 Aug 2016Craig Cockburn 🏴🇪🇺 @siliconglen@Grady_Booch @simonbrown @seidewitz @martinfowler what would be the advantage if we did?
114
134
Grady Booch@grady_boochThe UML is not a dessert topping and a floor wax. twitter.com/seidewitz/stat…14:57 PM - 04 Aug 2016Ed Seidewitz @seidewitz@con_sultan @Grady_Booch @siliconglen @simonbrown @martinfowler Graphical notation can be powerful, but it is not best for everything.
ending up in a slightly positive note
Grady Booch@grady_boochI never left :-) (I still use it in my work) twitter.com/simonbrown/sta…13:57 PM - 02 Aug 2016Simon Brown @simonbrown@seidewitz what do you think will bring people back to UML? // @martinfowler
Read more of his opinions here and here
And one surprising fact that you maybe didn't know. Grady Booch confessing how UML saved his life!
Grady Booch@grady_boochWhen I was diagnosed with an aneurysm of the ascending aorta, I remember laying in a CT machine, then I remembered I knew the team who wrote its software...and they used the UML.
So yes: that which Jim, Ivar, and I conceived then tens of thousands nurtured saved my life. twitter.com/leahy1de/statu…16:00 PM - 14 Mar 2019Dennis Leahy @leahy1de@Grady_Booch You must be proud your child is still growing.
Ivar Jacobson's opinion on UML
UML is not the silver bullet it was sold as ten years ago. Nor it is as bad as academicians, agilistas and competitors claimed five years ago
There are two major challenges to be addressed: the complexity of the UML specification itself, and the need to describe UML in coherent subsets that address the actual needs of users in particular domains
UML has become complex and clumsy. For 80% of all software only 20% of UML is needed
Read some additional quotes/comments here and here.
Bran Selic on UML's complexity
Bran defends that, in fact, UML is not as complex as you may think:
The complexity of UML is often cited as one of its primary drawbacks. In arguing this, many people will point to the apparent simplicity of programming languages such as Java. However, while Java is relatively simple on its own, you have to consider how much of the necessary complexity has been swept under the rug of class libraries? As far as I can tell, you cannot write anything remotely useful in Java unless you are also proficient with at least some of the core Java libraries. In environments such as J2EE or Eclipse, the minimum level of proficiency goes up even further — exceeding in complexity anything that UML requires.
Consequently, although Bran does think that UML is bloated needlessly, he also thinks it is mere pittance compared to what you find in the so-called “mainstream” languages used for most applications development. The problem is that we are trying to solve complex problems. As any carpenter can tell you, complex problems require complex tools.
Or as he puts it:
I can give you 1000 examples of UML being bad but “uml is big” is not one of them. Too big for what?
Other insightful quotes:
UML is the worst modeling language except for all the others
The worst UML book you can buy is “UML Distilled” (the criticism refers to the fact that the book only covers the syntax of UML)
For alternative UML books go here . To know more about Bran's views check his wisdom pearls on modeling/MDE
Do you have other UML quotes you would like to share? Please add a comment! (and if you want to start playing with the language, any of these web-based UML modeling tools will be the easier way to start)
Top comments (3)
I have used only class diagrams from UML for 20 years - it's so much easier to deal in 2 dimensions i.e. a class diagram, when designing or documenting code than living in a world with only a one dimensional stream of characters - i.e. source files :)
Class diagrams are really the only thing that have a one to one representation with the structure of the artifacts in your code base so they are never too far distant from your code.
I like Grady Booch's first few comments you listed in your post.
I still use UML but only really class, sequence, and state diagrams. I use UML to communicate new designs, reverse engineer legacy designs, and even during bug analysis.
I think it is great for getting an overview of object-oriented designs and behaviour especially for large code bases. In my experience, people unfamiliar with UML have been able to understand the diagrams I have presented. But likewise other people use ad-hoc diagrams which work fine too. However I think UML helps developers explore all the facets of a architecture/design in a structured, methodical way.
I think UML was useful for the first revolution (object orientation) but I agree with Grady's observations that what happens during the next revolution (AI) is up to those who work in the field. Whether anyone in that field sees value in having a common modelling language or not remains to be seen. However since agile development dominates at the moment, I think a modelling language for the next revolution needs to be a language primarily for collaboration.
Fully agree with the importance of collaboration. Still, this collaboration support does not only involve the language (which indeed needs to be flexible enough for this) but also the tooling. In this sense I think our preliminary work on using native collaboration platforms like Slack for modeling could be a good first step in this direction