Why People Fail With UML Diagrams
Wednesday, April 7th, 2010 - By Seth Rosen
UML and UML tools seem to always be getting a lot of
bad press. This might be the result of developers not utilizing them for their intended purposes. As they were originally imagined, UML diagrams should only be used when designing code. They should not be used when sitting down to detangle a pile of incomprehensible logic or making sense of an alien design pattern; and especially not for generating all your project’s code. Experienced designers may already have come to this realization but for others some explanation is in order.
There are a lot of options when it comes to UML diagrams. Other than the ever present Class Diagram there are: Structure Diagrams (class, deployment, package, etc), Behavior Diagrams (activity, usecase, etc), and Interaction Diagrams (communication, sequence, etc). They are all used to meet a very specific need; communicating design requirements from product management to the development team. This is very important when working with most software processes since they require all functionality to be determined during the design phase. Five months later when features are added/removed and code is re-factored, maintaining the UML diagrams becomes tedious and the diagrams are no longer helpful.
The strict guidelines governing UML usage are great for preventing ambiguity during the design process but immediately become a nuisance when a new team member needs to understand how a new feature relates to the existing codebase. Software Architects can take advantage of the power of the UML to create detailed specifications that would be difficult to create with other tools. However, much of the information in UML diagrams is represented by unintuitive, non-graphical symbols. For example, the 1-* notation in class diagrams conveys that a one to many relationship exists but this may not be immediately obvious from a cursory glance at the diagram. In fact, it is often difficult to get a quick overview of a feature or concept since most aspects are broken into separate UML diagrams. Someone new to a large project would have to pour over piles of diagrams to get a clear idea of the task at hand.
Some UML tools are marketed with claims that they can provide unlimited diagramming abilities and solve all your programming problems; allowing you to understand existing code and even generate code. However they often fall short when it comes to keeping diagrams concise or modifying existing diagrams. These UML tools are not flexible or adaptable, which makes understanding and code maintenance difficult, but some new tools may help with these challenges. Dynamic modeling tools will help users easily generate, modify, share, and save different types of UML diagrams. Automatically generated, interactive varieties of diagrams may soon become the norm, allowing users to understand their code faster and more intuitively.
As these tools become more intelligent and continue to stretch the boundaries of UML standards we can expect to see a rise in diagrams being used at all stages of development. But for now keep UML where it belongs, in the hands of experienced developers during the design process.
There is an old joke that sport is not needed for a healthy person and dangerous for a sick one. In my opinion the same is applicable to UML – for small project is just adds something useless. For big ones it requires a lot of additional job to create a bunch of incomprehensible graphics. I think that UML is the most useless invention in IT (unless you want to impress your boss to make him think that he understands “the architecture”). It is really amazing how such a stupid thing gained such an attention.
Frankly I think it is all to do with knowledge. Educating on UML best practices and tool usage is sure to help.
Forza, Yeah, knowledge is important. But some of the best UML tools have tried to use that to take the easy way out and just put out a lot of it (via user guides).
I think it is more important now to focus on the main use-cases (like what developers need) and make sure that those parts are easy and intuitive to use.
Please continue discussion on the forum: link
That’s a very insightful analogy and I think it is true in many situations. Yes, UML diagrams are useless in many situations.
However there are cases where UML can be helpful. For example, if you have a large team and need to split your project into multiple parts, an hour or two creating a Component Diagram can save you many hours of frustration down the road. I have been thinking about this a little bit, and will try to write a post where I will elaborate on situations when UML diagrams are helpful.
Interesting points. I both disagree, and agree, this probably depends on personal experience. I think you are correct in that many uses UML in a non-optimal way, sort of speak. But I totally disagree with your statement that “UML diagrams should only be used when designing code”. (Not to mention what I think of iskorns comments above).
Software and systems development is all about communication between team members. And that’s what UML is all about too. But to achieve great communication one has to master a set of “tools” such as social capabilities (no pun intended) and others as UML (if deemed to be appropriate).
UML, I think, is a seriously misunderstood language by many; overused and misused. But it is just a tool, among many others, and correctly used it can bring clarification to really complex problems. We can not hide complexity, we can only master it. However, this requires really skillfull engineers who knows how to use UML in a sensible manner.
Few are those.
Can you please explain why we need a FORMAL GRAPHICAL notation for “communication between team members”? Why on earth a class description is supposed to become more clear when placed in a rectangle? You admit that “UML …. is a seriously misunderstood language by many; overused and misused”, but can you please provide an example when “it can bring clarification to really complex problems”? I mean when UML usage has any substantial advantage for such a clarification comparing to other (informal) approaches?
There are a few examples when formal graphical notation for description of non-material things (in contrast to e.g. engineering drawing) proved to be really useful and have been widely accepted. I can recall Feynman diagrams and Lie algebras root systems’ description. In both cases the pictures have strict interpretation in terms of non-graphical formalisms. On the contrary UML attempts to describe something non-formal with formalized graphics (the notion of class is much less formal than a notion of a term of a perturbation theory series).
I think that the idea of the code generation from UML diagrams is a result of an attempt to provide some justification for this strange idea. Another idea of the similar nature is a “non-graphics UML”.
@mrelbe Good points.
I think the core of the problem lies in UML tool providers who focus on features that are helpful mostly on the design phase, but sell their tools to be used for all phases of development. This just results in such tools being overused.
When I hear someone say “but UML does not work”, they really mean “UML software tools do not work for non design tasks”. I think many people do use some form of UML with white-boards or pen & paper do help for many phases of development work.
I love your blog! Keep it up!
I think that the sequence/collaboration diagram is really useful. This is especially true when you want to talk about how to re-factor a process. Without the diagram people don’t use a common language to describe the objects involved and a lot of times have a misunderstanding about how the components really work together. You can also get a pretty good sense of implementation complexity and object creation problems pretty quickly (just by looking at the image as a whole).
To quote Martin Fowler “Comprehensiveness is the enemy of Comprehensibility”. In my experience, this is where UML “fails the most”. There are several aspects to this, but most noticeably: (1) in sequence diagrams, i see folks trying to put in every interaction with every object/component rather than focusing on what is important for understanding. These are the sequence diagrams that when printed out would be 6 feet in length
and (2) the desire to put in every attribute and every method into class diargrams, where it is much more informative to put in only the key methods and possibly attributes that enhance understanding of the message you are trying to convey. It seems strange to me to put in sooo much text where the idea of UML is to be a GRAPHICAL language. This goes to the point of how UML is all too often a non-graphical means of communication. I also believe that the dinosaurs in SW that still advocate for “big up front design” are responsible for this trend. And tool vendors tend to want to cater to those “big software” mentalities. But to Matt’s point, when UML is done within reason and where necessary, it can add a wealth of information and as good refererence. I always found the diagrams (as simple as they are) in Design Patterns to be of great use, for example.
I agree entirely John, documentation, especially diagrams and graphical documentation do not always benefit from a ‘more is better’ mentality. Highlighting key concepts is often much more valuable than showing an entire class or all of a method’s calls. Determining the correct methods and metrics for achieving this is a much more difficult prospect, especially given the variety of projects, languages, and design patterns. Keep an eye on this blog for more tips on better visual documentation techniques as this is something we are keenly interested in.