Everybody has its own opinion about the Unified Modeling Language but I think it’s interesting to collect some UML opinions expressed by the people that created 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
IMHO the UML standard went off the rails when it was made overly complex to support MDD…the UML is not a prog lang https://t.co/aFabrgpAug
— Grady Booch (@Grady_Booch) August 2, 2016
The UML is not a dessert topping and a floor wax. https://t.co/GWCXKbqqDk
— Grady Booch (@Grady_Booch) August 4, 2016
ending up in a slightly positive note
I never left 🙂 (I still use it in my work) https://t.co/8x4SDiL6DF
— Grady Booch (@Grady_Booch) August 2, 2016
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!
When 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. https://t.co/zCMpZd3HwU
— Grady Booch (@Grady_Booch) March 14, 2019
Ivar Jacobson’s opinion on UML
He starts by stating loud and clear that rumors of the death of UML are all false. Other highlights:
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: 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.
If UML is used in a smart way, it is very practical and results in products with higher value. UML is a great language to create architectures. It works very well for agile teams.
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 I do think that UML is bloated needlessly, I think 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)
If you want to check alternative UML books go here . To know more about Bran’s views check his wisdom pearls on modeling/MDE
Do you have other quotes you would like to share? Please add a comment!
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
OK I’ll bite. I find Booch’s comments contradictory. To be fair: his earlier work (the Booch Method) was clear in stating the diagrams were mere thinking tools, never intended for automated translation into working software. But if UML was only ever meant to be a set of symbols with loose semantics, why did he lend his name to its formalisation? Why sit atop an organisation that made a lot of money from selling expensive UML tools that were billed as facilitating (for example) ‘forward and reverse engineering’?
Whatever the motives, the evidence is clear. UML has not had a positive, lasting impact on software delivery. It’s a backwater now, with use steadily declining. Elaboration as a philosophy did not lead to better software faster and has rightly died.
Model driven approaches may still be a niche market. But where they do have traction, the common feature is automation. Producing better software quicker. In fact, I’d argue it’s the *only* part of UML/MDA that has stood the test of time. Booch himself has said that rising abstraction is a fundamental theme in software evolution. No arguments there. But the implicit consequence is that the translation from progressively higher abstractions to those underneath has to be automated. Without that, the commercial and cognitive benefits diminish greatly. UML is a graphic exemplar of that (pun intended).
Your comment reminded me that I had forgotten several recent tweets (that in fact were the ones to trigger the writing of this post). I’m sure you’ll like Grady even more after reading those tweets.
I agree that Grady’s view (at least today, I don’t know whether his view has evolved though some of his comments suggest that in fact he already thought this from the very beginning) is clearly against using UML as part of any automated code-generation process. Why he accepted (or maybe resisted but had to concede defeat to more pragmatic reasons) to play along the company is something will probably never know.
Btw, I’d argue that even more than code-generation the part of MDE that has stood the test of time is reverse engineering. Even hardcore programmers agree that any help in understanding the code is useful
Reverse engineering triggered some thought. Isn’t our everyday coding mixed with some sort of reverse engineering? You reverse engineer some models from code and your change and repeat. Providing some (graphical and non graphical) abstraction helps work with existing code.
OK, I too will bite. Disclaimer: This is all anecdotal evidence and therefore has no scientific standing. That being said, I started out modeling using Bran Selic’s ObjecTime tool in 1997 for round-trip code engineering and I really liked it. We were building complex telephone switching systems using C++ and the quality of the code was very good with the modeled software and not so good when the models were not used. The software was also easier to test. Since then I have used the Xylogics and Enterprise Architect UML tools on various real-time systems with teams of two or three people up to 150 people scattered across multiple continents. When the modeling tools were used, communicating the system architecture with the other members of the team was much more effective, and maintaining the systems over time was easier. Modeling makes software engineering easier and less error prone. When models are not used, the process has often degenerated into crude hacking with quality to match.
It may be that UML is falling into disuse and modeling is a backwater. But what else do we have? I haven’t seen an effective alternative yet.
Lest it wasn’t obvious from my post: I was a strong proponent of using UML in this way (still am). I used the Shlaer-Mellor tools (Bridgepoint), even worked for the company. They – in common with ObjecTime – met the automation need. Models weren’t (aren’t) sketches, they were the primary artefact, automatically translated into working software.
My disappointment is that the wider UML/MDA community didn’t embrace that approach and has suffered the consequences.
Irrelevant. The Unification process involved many more heads and approaches than those of the 3 Amigos, not to mention numerous CASE tool makers of the time suppliying (dis)proof-of-concept for numerous candidate notations. OOPSLA’95 at Austin TX was a really important milestone branding-wise, but just that. The real work from 0.x to 1.1 was helped by many, and IMO Krys Cobyrn instrumental for the first “usable” 1.3 . UML would be sterile without the likes of Harel, Wirfs-Brooch, Reenskaugh, D’Souza, Reich, Casanave, Digre, and so many others
I don’t think the post says the 3 Amigos were the only ones behind the UML. In fact, the opinions currently displayed include those of Bran Selic. And if you have links to the opinion of any other person involved, I’ll be more than happy to add them.
I think it’s interesting to see what all of them think about their creation right now. We could learn a few interesting things
Well, I was involved in the gestation and birth of UML since ’94, and I have often submitted my verbatim opinion to this outstanding MOLA site many times. Many others involved can be found in my contact list
Yep I agree, that’s why I did not need to mention Bran in the list of instrumental Actors in UML.
Bran, along with Trygve Reenskaug and Desmond D’Souza are in my opinion, the ones who provided the most powerfull complexity management techniques. Among others: Capsules, Roles, Patterns. When I first swamped my brains with the ideas from the work of these 3 enormous thinkers, I started to actually grasp how to really disect problems and synthesize complex solutions for them.
Specifically about Bran, I would like to highlight that ROOM powerfull abstractions where not included in the UML set, until the Community at large pushed them into the EDOC Profile for UML, the EAI Profile of UML and the ebXML BPSS by the end of the ’90s – to be later cooked in the excellent UML2 specification (the original one with infra/super and package merges, not current washed off 2.5 ) – not without significant hassle and battling from the Big Vendors.
But I insist: apart from their famousness, 3 Amigos opinions are irrelevant these days, they already gave us their best in the 90’s, and we all were SO GLAD for Rumbaugh to loose his balls and Booch dissipate his clouds – back in OOPSLA’95.
The ball is now in younger’s field – we’re too busy these days building systems or helping others to do it, to play branding and corporate battles.
I must also state my first hand observations at the time, how Trygve Reenskaugs OORAM was kind of included in the original UML1, but kind of with “the inside-out” where roles where specified as partials of classes, as opposite to the original intent of classes as eventual realizations of already synthesized roles.
Furthermore, there was quite a messy politico-economical trade between a number of VENDORS and vendors, around who would sign under UML Collaborations, and who would sign under OCL submissions – so actually the “official” records and copyrights do now actually represent the real authors of each part. Funny ! but anything was worth to get UML out the door.
I will say that modeling (not UML), is a smart way to produce solutions to any problem. Documentation is a big part, but as Scott said we can generate working data that can run anything from that documentation. One of the things about modeling is the grasp of the big picture. Code can infact get quite ugly, while a picture is worth 1000 words.
And to rant a bit, automation is the key. Using BridgePoint I have succesfully developed many programs and tools with the automated approach.
Very nicely put, Travis. Thanks.
Ok, let’s assume that UML is dead.
What can we say about requirements collection ?
My everyday experience is that requirements gathering is bad or even very bad.
So, my opinion is:
do not throw the good 20% part of UML (communicate with others, let everyone understand what you understood and what you intend to do after listening to them) together with the 80% bad on which I agree (too big, too much symbols, MDD bias, etc.).
I find amusing the criticism of UML’s not being appropriate for generating code. If it doesn’t do that, what is it good for?
I am not a developer, but a data modeler by trade. From the beginning UML (at least as used) was not useful for discussing data architecture with the business community. The notation was too confusing, and no one paid attention to aesthetic considerations.
I have always used the Barker/Ellis notation, both because the aesthetics are kinder and because they included a discipline for naming relationships.
But then I spent a year working with the OMG attempting to define a Metadata model to encompass everything. We never accomplished that, but over the course of the year I figured out why the UML world and the data modeling world didn’t connect: To a data modeler, a relationship is a structure connecting two entity types. By definition, you have to have both ends. To an object modeler, an association is a *path* from one class to another. Since you have to program both directions, if you only need one, that’s all that exists.
In addition, to data people, data constitute a corporate asset. Organizing them is important, controlling who can change definitions as well as who can change values is important. This affects the way that addresses the problems. Object oriented programmers view data as support for their programs. Thus anyone can change definitions, and establishing security is secondary.
With that understanding, I accepted my colleagues’ challenge that “you can model anything in UML, and decided to publish my next patterns book (*Enterprise Model Patterns: Describing the World*) using UML. My data modeling colleagues were firmly convinced that I had “gone over to the dark side”, and my OMG buddies were concerned that I had bastardized their sacred notation.
So, I published a companion book, *UML and Data Modeling: A Reconciliation*. It seems that what I created was a “Domain specific language” (and, gee, I even got my own acronym, “DSL”!).
What UML lacked was a sense of aesthetics. And none of this community seemed interested in presenting their models to the world at large.
If it can’t even be used to generate code, why is it?
Completely agree that there is still a mismatch between the “programming” and the “database” community and when trying to use the same language for both we suffer from some shared understanding problems. For instance, I always struggle with the fact that EMF does not support associations (you’re forced to implement them, and maintain them!, as two cross-references in the participant classes)
UML is just a collection of notations. All the diagram types you could possibly want in one box. To generate code from UML you need to employ a method such as the Shlaer-Mellor Method or its modern day derivatives, Executable UML or Matrix. These methods give UML diagrams the precise meaning and purpose required to generate code.
UML is a metamodel used as a metametamodel. The articulation MOF/UML is fundamentally broken. If it was used as an M2 nobody would talk about it, let alone use it. It’s a bit like trying to use a broom to fly because someone told you they saw someone who saw someone flying on a broom and complain it does not work for you. Now it does now mean that a broom has no purpose.
Jordi:
I am glad I could find your site and a very balanced and frank statements of the “Creators of UML”. I agree with most of them including Bran Selic’s defense of “UML Complexity” partly. UML is needlessly complex in many places and too lax and misleading in many other places. It is the failure to deal with the double fault on complexity that almost ruined UML.
I would be glad to work on simplifying and making UML compact useful with sufficient precision and rigor. Please take a look at my PDF on SlideShare: https://www.slideshare.net/putchavn/use-casesingle-session?qid=7d7adfbd-52e8-4d31-b0c9-ab199634fd9f&v=&b=&from_search=3 There are many associated PPTs and PDFs on UseCases which I have studied and applied extensively.
[email protected] 02OCT17
Personally I do not like working on projects where analysis is not done using UML.
In such case it usually means a lot of textual requirements (often written in custom style 🙂 of each particular analyst) or almost no documentation at all (usually “written” by over-motivated agile enthusiast) which leads in both cases to the same state…loosing of context, unknown dependencies, and spending time on defining the current state…
For me Use Case and Logical Model (of analytical classes) + interfaces described (by custom UML diagram, or by Swagger) are backbone of documentation for most of the projects. Other diagrams very rarely (Activity diagram to describe very high level decision logic, Sequence diagram)
Personally I don’t dislike UML per se , I rather disliked most of UML Corporate tools and corporate usage.
UML had been given a huge boost in the 1990s thanks to IBM, I’d even been part of the “army” of consultants who participated in promoting it 🙂 If finally according to even proponents 9/10 people don’t use UML that should tell something: modeling is needed but king is naked.
So I’m now working on another type of diagram that would be able to bridge with/generate UML if wanted.
For almost 20 years now, I’ve found the UML useful for planning the structure and tracing the requirements of the software I develop. Saves me a bunch of time and helps make the code I write maintainable. Never found the UML all that complex or complicated (at least the way I use it).