Today, whenever UML is mentioned in a conversation, chances are that UML is the target of a joke and not part of serious conversation about using UML as part of a software development project.
I disagree with this (IMHO) unfair hypercriticism of UML. As Bran Selic said “UML is the worst modeling language except for all the others” so in this post I’ll try to debunk the most frequent myths and misconceptions about UML so that people better understand what UML is for (and what it is not) and next time they decide to criticize it they can do it with better grounds to do it.
To collect the top 10 myths, I just asked ChatGPT. Simply as a way to get an aggregated response. Maybe ChatGPT is not yet ready to be our pair-modeler but it is for sure able to regurgitate repetitive statements it has seen in the training data, which is precisely what I’m looking for here. My initial prompt was: “what are the top 10 criticisms people say about the UML language?”. Remarkably, I tried other similar prompts and the answers were quite consistent.
So, let’s review all these misconceptions and concerns and start fixing them!
Myth 1. Complexity
UML can be perceived as overly complex, especially for beginners. Its extensive set of diagrams, notations, and concepts can be overwhelming and difficult to learn and apply effectively.
It’s true that the UML specification is huge but nobody is forcing you to use all types of diagrams, not even all the possible elements for any given diagram. There is no rule saying that when using class diagrams, you’re obliged to add at least an association class. You don’t get extrapoints for cluttering your models with all possible types of elements. As part of adopting UML in your enterprise, you should be explicit on the types of diagram and modeling primitives you think are needed in your domain.
Our recommended books for learning UML can help on this as well.
Myth 2. Ambiguity
The UML language is sometimes criticized for being too ambiguous or open to interpretation. Different users may interpret the same diagram differently, leading to potential misunderstandings and communication issues.
It’s partially true that UML itself offers what it is called semantic variation points. But I’d also say these ambiguity points only impact a very reduced number of UML users. Most designers will never run into these issues. And if your company/domain is one of the exceptions, as said on the previous point, just fix the semantic variation point so that all your team shares the same understanding. You can also restrict yourself to more precisely defined subsets of the UML language.
Myth 3. Lack of standardization
Although UML is intended to provide a standardized notation for modeling software systems, there can still be variations and inconsistencies in its implementation across different tools and organizations.
I don’t think it is fair to blame UML for tool vendors not properly implementing the language.It’s indeed true that each tool implements a different part of the language and that sometimes they use slightly different semantics but this is not a UML problem, it’s a tooling problem.
Myth 4. Limited support for agile methodologies
UML was primarily developed during the era of traditional software development methodologies and may not align perfectly with agile approaches. Critics argue that UML does not offer enough flexibility and adaptability for agile development practices.
UML is a notation, not a software development method (this misconception was at the origin of many of the initial disappointments with UML, if your team was dysfunctional, if you add UML, you’ll just have a dysfunctional team with a UML tool). As such, UML, and in general, modeling and agile methodologies can be excellent friends.
Myth 5. Overemphasis on documentation
UML is often associated with extensive documentation requirements. Some argue that the focus on documentation can hinder agility and be time-consuming, particularly in fast-paced development environments.
Same as for the previous myth. UML is a notation and as such, UML itself does not prescribe any level of modeling for your project. It’s up to you to decide how much modeling (what diagrams, what level of completeness, …) is required in your project. UML will not complain nor get angry at you if you just use it a little bit because your project is a clone of previous projects and you just want to model some small variations.
Myth 6. Maintenance challenges
UML diagrams can become outdated and difficult to maintain over time, especially in large-scale projects. Keeping diagrams up to date with evolving software systems can be a significant challenge.
In a large-scale projet everyghing is a challenge. The evolution of the system in particular. But this is true if you look at the system models, at the system code, at the system data,… Unless you follow a full model-driven approach (where models are always updated as the full code is generated from them), you’ll need to book some effort to keep them updated as you update the rest of the system. But again, this is not a UML problem, if anything is more of a methodology problem.
Myth 7. Steep learning curve
Due to its complexity and the wide range of available diagrams and notations, learning UML can be a time-consuming and challenging process. Critics argue that this steep learning curve can discourage adoption and limit its practicality.
This is similar to myth 1. You don’t need to know all possible diagram types to start using UML. Several works have highlighted that most projects just use class diagrams, use cases and sequence diagrams. So start there and learn the rest along the way whenever you need them. At least, and in contrast with other modeling languages and DSLs, there is plenty of online material to learn UML.
Myth 8. Disconnect from implementation
UML focuses on high-level abstractions and does not provide direct mappings to specific programming languages or implementation details. Some argue that this disconnect can lead to a gap between the models and the actual code, potentially resulting in discrepancies or misunderstandings.
UML aims to be platform-independent. So I don’t see this lack of direct mappings as negative, more the opposite. But if you want to model with annotations that better express how that modeling concept should be implemented, UML itself provides you with the profiles lightweight extension mechanism. I’m more into the “convention over configuration” to maximize the output I can generate without polluting my models.
Myth 9. Limited tool support
While there are many UML modeling tools available, the quality and features of these tools can vary. Some critics argue that the available tooling for UML is not as advanced or user-friendly as desired.
I think the same can be said for any other language. Tools always lag behind the languages specifications (comprehensible, as it’s easier to write things down in a spec document than implementing them in a solid and scalable way in a real tool!). And I think the UML tool ecosystem is very much active and blossoming with new types of tools (web-based, textual, chat-based,..).
Myth 10. Perception as outdated
With the rise of newer modeling approaches and techniques, such as domain-specific languages and model-driven engineering, some view UML as outdated or less relevant. Critics argue that UML may not adequately address the needs and challenges of modern software development
I’d dare to say that many DSLs are just subsets of UML. And as such, they would not be strictly necessary if current UML tools would be more flexible and allow you to easily configure the palette to show only those UML elements you’re interested on. I do think that the new SysML 2.0 will be a major rival and may indeed impact on the adoption of UML for complex systems. Still, even in that case, SysML and UML are part of the same family so I don’t see it as a loss for UML.
And if you liked this post, maybe you want to follow up with this other related one looking at what the UML creators think about the language now, twenty years after its initial proposal
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Excellent post, Jordi, thanks! The (UML) baby was certainly thrown out with the bath water!
My main criticism of UML is the complexity of its metamodel. This makes it nearly impossible to create automated transformations of your models or generate code from them — unless you have a human-readable form of your model or a debugger for your UML tool. Anyhow is it going to be a cumbersome exercise to find in which metamodel field at which level metaclass e.g. a role name is being stored.
And IMHO, if we cannot use UML models as a base for the automation of at least some parts of our development process, the value of using UML is greatly reduced.
Nevertheless, and as you said: ensure everyone on the team has the same understanding of the UML concepts used by the team, then UML diagrams / models will already bring a lot of clarity to your project.
Oliver said:
> if we cannot use UML models as a base for the automation of at least some parts of our development process, the value of using UML is greatly reduced.
Vehemently agree. This was all wrapped up in the “elaboration vs translation” debate. I’m personally hard-line on this: translation was the only viable answer. Hand-iterating was never going to bring about improvements in productivity: it had to be automated. Unfortunately that was the minority view. I might suggest that history has shown the minority to be correct, though I clearly have bias here!
The other challenge is usability. Every tool I tried felt like there was friction in creating diagrams. I haven’t looked for a while, maybe it’s improved. But it was a systemic problem.
Stepping back, it still seems to me like there’s opportunity. Even well-structured code bases are an intertwined mishmash of genuine domain considerations, architectural decisions, and implementation consequences.
I had a glimpse of how things could be when using the Shlaer-Mellor method and tooling. Neither was perfect: the method never fully answered inter-domain bridging, and the tooling never fully supported the recursive design method. It also had some plenty!) of the UI frustrations per above. Nevertheless: being able to concentrate on the domain model, completely shorn of architectural considerations, was utterly compelling. I still use the approach today (if not the tools).
Things are always cyclic. The rise in no/low code might precipitate a refresh in interest. Success will mean learning important lessons from the past though:
1. Usability matters. The vast majority of software developers code: they’re used to the text-based ecosystem and are extremely partisan on tooling choice.
2. Productivity matters. Repeating @Oliver’s observation, drawing pictures isn’t the point. If it doesn’t get us to working, better software quicker, then it will fail.
Great post!
Personally, my main criticism of UML is how it locks you into a ‘classical OOP’ way of thinking. The base language is simply not abstract enough to cover languages that aren’t in this paradigm and the tools don’t readily support other paradigms without add-ons and profile development.
It would be good to see a modelling language that didn’t rely so heavily on the class-object distinction (something SysML V2 has kept) so that different forms of inheritance and reuse were easier to model out-of-the-box.
Two features that are also sorely missing from the UML family are first-class functions and sum types–they elegantly solve so many abstraction problems and are standard in modern languages such as Kotlin, Rust and Haskell (and are even now in Java & C++).
Perhaps a UML descendent based on Intuitionistic type theory is a bit too much of an ask at the current moment…
Not strictly for UML, but you may enjoy reading this post: “OCL Monads – Functional Interpretation for the Object Constraint Language”
Yep, like one of my students recently said: “How can I model this JavaScript function in UML?”
All functions in javascript belong by default to the global object. So create a global object as a class, in browsers it is the window object. Maybe the deployment diagram gets more complicated in sturcured languages like c or semi-structured as js
Most people that complains about UML are folks that don’t understand architecture as a basis of building an app/system.
In my working experience most project i have been associate the ‘architect’ only have created a context diagram and declares he has created an architecture.
In my project I have always developed SAD to depict the architecture of my projects I was the architect.
Comment from Benton Bovee (on linkedin):
As an early adopter and published contributor to UML, I’d like to age some fair supporting observations and criticisms of the language as it has aged and been built on with extension (i.e., Profile) languages (e.g., BPMN, SysML).
1. Complexity: Fair criticism; it twists over backwards to enable an OO-centric ontology
2. Ambiguity: Within scope of what it expresses, false.
3. Inconsistent implementations: Not the fault of the language
4. Limited Agile support: Unfair; predated Test-Driven Design (“Agile”)
5. Documentation overemphasis: Without it, there would be near zero documentation
6. Learning curve steep: Fair criticism
7. Maintenance challenges: See #8.
8. Disconnect from implementation: False, but there are two related criticism: Due to side-lining Jacobsens’ Analysis stereotypes to optional, traceability to requirements is lost; and IML os silent on Requirements taxonomy and traceability ( RTT). I have a one-page post among my profile Media entries summarizing the RTT from SysML. If anything, heavily elaborated UML models are indistinguishable from detailed implementation
9. Limited tool support: False, many tools; and
10. Outdated: False; has not had to change for a long time for its (direct software) applications.
Jordi-
It’s a good summary. But I also like to emphasize the “value” of modeling.
Everyone needs some modeling tools in their arsenal: models can be good for thinking through a problem, understanding the best places to decouple and decompose the key design mechanisms, and explaining specific design choices to your friends. Even if you aren’t doing model-driven design, a set of simple models can still help with thinking and communication.
Models let us “abstract away from the code” — even if the models are high-level, they can help us navigate through many design decisions.
The designers of the UML notation had a lot of popular notations to choose from, and they made some excellent selections. But like any language, you don’t need to learn “everything” to use it effectively.
First, class diagrams are a great way to lump your abstractions. We have been modeling with “entities” (later called classes) since the early 1980s — I first used Entity-Relationship Diagrams for designing a real-world database-centric system in 1982. It doesn’t matter that they boxes are called “classes” — if you aren’t using “object-oriented”, the boxes still mean something. In almost every type of modeling, you need to identify key entities that lump together a group of related data (a data structure, a table in a database schema, an interprocess message, a user screen). It helps to also identify responsibilities (like we have done using CRC Cards, but it’s the same for semantic data models… a very old and venerable set of modeling techniques).
Class Diagrams are never enough, so some “dynamic model” notations are essential. There are many choices for describing dynamics in software modeling, so it is not surprising that UML chose to support at least three (state machines, scenario diagrams [UML’s Sequence Diagrams], and communication diagrams). From my point of view, it was an excellent choice to *not* include dataflow diagrams… the worst modeling notation ever, because it leads to awful spaghetti code.
State models have the trickiest learning curve, but most people don’t need to use them for simple data processing. But when your system has stateful objects or stateful interfaces or “reactive” components, you can’t live without state machines… so you have to take the time to learn them. Once you implement a group of system components from a state-based model, it becomes tricky to keep the model and the code in sync, but it is even harder to try to modify state-based code without a model.
Everything else in UML is extra (timing diagrams and other specialized notations). Use Case Diagrams are marginally useful for requirements traceability – the majority of implementation choices are not about “whole use cases”, they are about individual steps in a use case scenario or specific error handling/recovery scenarios.
It’s all about using taste and judgment to build “just enough” of a model to help you through. I remember working with a 12-person team that was doing a reengineering project on a medium-sized system. We built two class diagrams and about 40 sequence diagrams. Most of the sequence diagrams were easy to build, because we could walk through the existing code and write down the existing sequence of steps. The reengineered system added another 12 scenarios and made minor modifications to the steps of another 20. Writing the test plan was really easy. Without the model, everyone would have struggled to ensure the modifications were consistent.
Thanks Dennis for your contribution. Plenty of valuable insights!
Hello guys.
I agree with my friend Bran Selics comment completely, but adding that UML can also be simple and quite easy to use.
Just check the pdf’s I have published here: https://www.linkedin.com/in/tonisiljamaki/
To me (and where I have worked) the UML is about the semantics (not the notation), so I do not understand the “Myth 3” discussion.
“Myth 4”: Papyrus UML supports perfect agile MDD and DSL/DSML tooling development. (check the pdf’s above)
“Myth 8-9”: That’s why you develop your own MDD process and toolchain, your DSML and code-generator expertise are key to your success.
“Myth 10”: The embedded systems created today, having an expected life span of 20+ years, are as complex as the ones developed 30 years ago.
With your own and customized MDD toolchain you can implement your own and agile MDD process.
Regards/Toni
See also the comments in this LinkedIn post about this entry https://www.linkedin.com/feed/update/urn:li:activity:7080508173027028992/