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