Five Reasons Developers Don’t Use UML and Six Reasons to Use It

In many professions, people use graphical models to represent what they are creating or studying. For example, chemists have 2D and 3D diagrams to model molecules; cartographers use various kinds of maps to represent different geographical aspects of a region. If you’re a software developer, you’ve seen diagrams that represent some facts about the software design. UML is a visual language commonly used to create such diagrams.

UML is not specific to any software process (e.g., XP, RUP), programming paradigm (e.g., OOP), or technology (e.g., Java, .NET, embedded real-time). It originally targeted object-oriented systems but has evolved and now can be used to model any kind of software system.

Recently a friend asked me why people don’t like using UML. I gave him my opinion (which I share here) and also pondered that even if you don’t like UML, there are good reasons to use it.

Five Reasons People Don’t Use UML

1. Don’t know the notation

Some people don’t use UML simply because they don’t know the notation. In many cases, the person can read UML diagrams, but is not confident enough to create them. By analogy, software developers in Latin America in general can read English but are not comfortable writing in English (I know that because I work a lot with developers in Brazil).

2. UML is too complex

UML has increased in complexity and size over the years. Today there are 14 different types of diagrams! That’s too much for a human being to grasp. Some people shy away from UML because they judge that the effort to climb the learning curve will not pay off.

3. Never took a UML class

Old timers (like me) didn’t learn UML in college. Since UML training is not so pervasive and people usually don’t feel compelled to buy and read UML books, many simply never learned UML.

4. Informal notations do just fine

In many situations, people don’t think they need UML diagrams to communicate their designs. They get by with informal, box-and-line diagrams, which are easy to create in PowerPoint, in Visio, or on a whiteboard. Software developers are accustomed to being formal at the code level (after all, programming languages are formal languages and the code has to compile and run). They don’t like formalism at the architecture level.

5. Architecture documentation not deemed important

In many projects, the software architecture is quite simple or it just follows a reference architecture, and hence there’s no strong need to create diagrams to represent and communicate the design. George Fairbanks calls this situation “architecture-indifferent design.”

In some cases, design is communicated orally or using other graphical notations, such as informal box-and-line diagrams (as mentioned above).

Whether the lack of design documentation is a conscious decision or a result of lack of architecture knowledge, such situations are quite common, and in those cases creating UML models is deemed unimportant.

Six Reasons to Use It

It’s easy to say “Don’t use UML,” but it’s hard to say “Use this instead” because there are no acclaimed substitutes for UML. Or are there?

  • Informal notations? They help in many contexts but in others the inherent ambiguity impairs the ability to understand the design.
  • Absent design documentation? May be OK in some cases, but the lack of documentation becomes a problem when the design has to be communicated across time (to a developer who will join the team six months later) or space (to a developer working in another country).
  • Domain-specific languages (DSLs) for visual modeling? If you’ve developed using Visual Studio and have not used its DSL SDK, that indicates that DSLs for visual modeling have not found broad adoption.
  • (Formal) Architecture description languages (ADLs)? Some formal ADLs, such as AADL, have found niches where their applicability yields benefits that outweigh the cost of learning the language and creating detailed models. And yet, for many of these languages there are UML profiles that let you work on designs using the UML notation.

Thus, although I concur with some of the criticism over UML, I can’t point out a better all-purpose alternative. It is healthier to think about good reasons to use UML. There are at least six:

1. It’s the standard

UML is the de facto standard notation for software design. In other words, it’s the only software design notation that you can expect your peers to be familiar with.

2. Tool support

UML tools from FOSS to multi-thousand $ price abound in the market, including plug-ins to most popular IDEs. Besides drawing diagrams, some of these tools can generate code, apply design patterns, mine requirements, reverse engineer code, and perform impact analysis, refactorings, and complexity analysis. The ability to generate code from the design found in many UML tools alone is a good reason to use UML.

3. UML is flexible

Stereotypes and profiles can let you tailor UML to your needs. In other words, you can have modeling elements and relations that are specialized for your domain or for the technologies you’re using.

4. UML models are portable

UML models can be saved in the standard XMI format. These XMI files can be read by different UML tools, though some pain is expected (as usual with interchangeable data formats).

5. Just Need a Subset of the Notation

UML has 14 different types of diagrams. You won’t find anyone who uses all 14 types to document a software system. It is not a goal to try. Years ago a survey showed that in practice developers regularly use class, sequence, and use-case diagrams. The Pareto Principle seems to apply: 20% of the UML language may cover 80% of your modeling needs. That means you can learn a subset of the notation and effectively communicate your designs using UML.

6. Architecture is important

The software architecture is the blueprint for the system; it allows reasoning about performance, availability, security, and other attributes, allows planning for incremental development, and guides work assignments and tracking. However, even the best architecture, created based on years of experience and carefully selected design patterns, may be useless if not properly communicated to the people who need to use it. Paraphrasing Steuart Henderson, designing an architecture without documenting it is like winking at a girl in the dark. You know what you’re doing, but nobody else does. We use this argument in Documenting Software Architectures, Views and Beyond, 2nd Edition to explain why should we document the architecture. UML is a well-known visual language that can capture much of the information that one needs to communicate about the architecture.

Paulo Merson, SEI

21 responses to “Five Reasons Developers Don’t Use UML and Six Reasons to Use It

  1. ok have you tried to “port” your UML models over 2 Applications or even 3? Using XMI?My Experience is that it works very bad to absolutely not, because each vendor uses its own meta Data…

  2. Hi Bill,

    > UML is a well-known visual language that can capture much of
    > the information that one needs to communicate about the architecture.

    Yes, it’s a really good point. In a way, though, the use of UML for architecture only really came of age in version 2 with the introduction of full component diagrams and composite structures. These allow UML to act as an architecture description language.

    However, i’d argue that we can use diagrams to do much more than communicate the architecture of a system. We can use them to fully represent and create the stucture of the systems, even with dynamic changes. With that in mind, I created Evolve, a system using UML2 component and state diagrams to fully describe the architecture of a system.

    I’d be interested in your views on it.

    Oh – as an integral part, it includes powerful evolution and reuse facilities which allow system variants to be described.

  3. You don’t touch on a more primordial question: are there any necessity for a formal abstract notation over code? And just saying “because the chemistry guys has one” is not an answer, at all.

    One may say that it is just too difficult to understand the architecture of very complex systems just reading code. But then you will have to explain how very complex systems such as the Linux kernel, the MySQL database, the Apache webserver, and hundreds of other systems came about, with tens of thousands of programmers being able to not just understand it but also evolve it, without a single diagram to support them.

    As a simplistic answer, I would say that people that defend diagrams and notations are simply not able to grasp code, at all.

  4. The idea behind UML is wrong in many cases, since some people think software engineering is like machine construction. But software development is much more dynamic with continually changing requirements. An UML diagram is one more artefact that needs to be updated in an agile process, and model driven development doesn’t work in practise, because it is easier to write the code directly instead of modelling every detail.

    UML is fine to show some key aspects of a software design.

    • An UML diagram is one more artefact that needs to be updated in an agile process

      Depending on the project, you may evaluate that a design diagram has fulfilled its purpose once the first implementation of that piece of the system is done (hopefully along with test cases that help understand the behavior). In such cases, it may not pay off to update the diagram. That’s fine! As I suggested in an InfoQ panel, in such cases you can delete the design diagrams or mark them as out-of-date. (See answer to the following question on the panel discussion: “What is the role of software architecture documentation in development teams that are using Agile…?”)

  5. > As a simplistic answer, I would say that people that defend
    > diagrams and notations are simply not able to grasp code, at all.

    well, it is simplistic. it’s also bad logic to jump from the truism that people can understand systems without diagrams to then claim that people who defend diagrams cannot code.

    now, of course people can construct systems without diagrams. these people have mental models of the system that lives in their heads. diagrams are about communicating these models so that others can also understand them.

    there are also a great many diagrams of systems like linux etc around.

    • I second Andrew’s words, and would like to add some thoughts.
      Several times I joined large software projects as a developer/maintainer and the welcome email was usually like this: “Paulo, welcome to the team. Below is the URL to the svn repository. Once you configure your local repository, let’s go over the list of features/bugs that will be assigned to you…”
      Today I’m in the architecture team for a project that comprises over 10K classes, not to mention other implementation artifacts (JS, JSP, XSD, SQL, etc.). Whenever we have new developers joining the team, we go over some top level architecture diagrams that describe:

      how the codebase is structured in layers.
      what are the main packages and their dependencies.
      what are the major architectural patterns in use.
      what’s the typical sequence of steps to process a user request.
      what’s the runtime structure (tiers and respective types of components, protocols, replication, databases).
      what are the main elements of the hardware infrastructure.

      This information is transferred in a couple of hours with the aid of diagrams. Newcomers get up to speed on the codebase much faster after this architecture walkthrough than I used to in projects where I had to read tons of code to try to grasp the big picture. Besides, a basic understanding of the architecture avoids that new developers inadvertently fix bugs and implement new features by diverging from the intended architecture, for example by introducing disallowed dependencies.

      I can’t conclude that complex open source systems were designed and implemented without the aid of diagrams just because when I download the source code I don’t download UML models or design diagrams. Indeed, the design of Unix (richly documented with diagrams in “The Design of the UNIX Operating System” by Maurice Bach; great book!) acted as a scaffolding for Linux.

      I defend that people who create design diagrams must be able to code.

  6. It is the standard : For some fields yes. Not for all computer sciences modeling cases : database, hardware, real time systems, business rules, networks…

    Tool Support : Ok. But you need five minutes to draw an UML diagram on the whiteboard, and from 30 minutes to 2Hours to do the same in an UML tool. You want to be able to generate usable code with theses diagrams. Count another 2 hours. The best you can have is taking a photo of your sketch and put it in the wiki. When your sure of your model, if your company need good looking diagrams, the go for a fast UML tool (like UMLlet) when you don’t waste time figuring the details. If indeed you have written the code. Generate the diagrams from it automatically. At least these diagrams will not be outdated.

    UML is flexible (annotations) : Only usefull for “formal” UML when you need code generation and all. Code generation with UML comes with big merge problems (SCM), so much time spent to do the “diagram” that your tool need to make the correct generation. It’s not uncommon to generate several time, to tweak the diagram for hours so the tool generate the correct thing.

    UML model are portable : No. there is a standard yes, XMI. But only the basics is supported. Import/Export from software to sofware is really limited. With errors, with loss of information. If you use a software for your UML needs, better to stay with it or all the generation, advenced features will be lost.

    Just need a subset : Yes.

    Architecture is important : Yes it is important. But we need “high level” architecture with only a few diagrams. The more diagrams you make by hand, the more time you need to maintain them. Detailled architecture is developper and “code” responsability. If you want the help of diagrams to understand implementation details, better your tool can make the diagram automatically from the code. Otherwise your documents will be outdated as soon has you finished them.

    You need to have a formal description of your software : it is code for now. For now, UML diagrams fails to deliver the fine details you need to make the software work. So UML diagrams are better just for communication between humans.

    • > For now, UML diagrams fails to deliver the fine details you need
      > to make the software work.

      sure, this is the case in most UML tools. however, it doesn’t have to be. for instance, ObjecTime (which later became rational rose realtime) was directly synched up to the code and was a description of the system and the executable. it was widely used in avionics and real-time domains. it shows that the disconnect between code and diagrams is an oversight, not a necessity.

      > So UML diagrams are better just for communication between humans.

      i’d simply say that the human to human aspect is a critical part of engineering, and the breakdown of this is a key failing of many failed systems. as per knuth:

      “Knuth: My shtick is to promote the idea that humans, not computers, read programs.”

      i.e. we program in high level languages so that humans can understand them, not for machines. the machines are happy with binary. anything therefore that we can do to understand code better is a good thing, subject to not creating multiple redundant copies which all need updating.

  7. UML excels at what it was originally developed for: selling consulting and training contracts for Rational and their partners.

    Every large project team that I’ve been a part of that used UML either was desperately trying to generate usable, maintainable code (and failing spectacularly), or acknowledged that the diagrams had at best a passing resemblance to the current code architecture and layout. We old-timers often think of it as “DOD 2167 without the boxcars.”

    I’ve been on dozens of agile projects over the last couple decades, since long before “Agile” became a marketing term. The next such project I see that makes use of UML for anything more complex than back-of-the-napkin thought exercises while planning a sprint will be the very first.

  8. > We old-timers often think of it as “DOD 2167 without the boxcars.”

    well, i’m an old timer too coming from OTI and the original places where agile were first practised well before it became a buzzword.

    and i’ve successfully used UML on a number of large systems, including a real-time live-to-air digital broadcasting system where we kept the code completely in sync with the models. that particular example was the early days of rational rose (’99 or so), but it created a powerful synergy between the code and the architecture.

    perhaps you just aren’t very good at it.

    (and as an aside, when did we start blaming tools when we couldn’t get something working)

  9. @Andrew McVeigh — I certainly didn’t mean to sound as though I was blaming the tool. I was merely stating my observation that every project I have seen it used on (none of which I was involved in tool selection) required copious amounts of consulting time to get the team working reasonably effectively with it. This experience has been consistent in my work in a dozen different countries, with teams of varying levels of experience.

    Any tool can be used effectively for its stated purpose by somebody. The question I was posing wasn’t so much on the merits of the tool, as on the way it’s often been marketed… and especially on the race-to-the-bottom mentality in recent software development that has managers looking for “silver bullet” tools to cover for the fact that they haven’t invested the resources to hire or grow an appropriately effective team.

  10. @Jeff – I hear you. My belief is also that code is what counts and if something doesn’t contribute to that or help with creating or maintaining code then it is not helpful. I’ve also seen UML used in very bad ways, basically to demarcate between so-called architects (who don’t code) and the developers (who do). Bad stuff.

    What I’m reacting to though is the silly perception (and the increasingly common viewpoint apparently) that visual depictions of a system are always bad and that people who use them are deficient in some way. It’s almost become a mantra. Take an earlier comment from AkitaOnRails which expresses a not uncommon sentiment: “I would say that people that defend diagrams and notations are simply not able to grasp code, at all”. Huh? These ill-thought out comments really do programming a disservice and move it further away from the notion of engineering back into an ad hoc approach to stringing code together without any coherence.

    Diagrams are very useful for showing the relationship between things, and they are used by many engineering disciplines. They become increasingly important as a system grows large. A sofware system has many relationships, and displaying them visually is often the clearest way to show them – certainly far easier than forcing someone to peruse a million lines of code to get the “big picture”.

    Does that mean that diagrams are always good. Definitely not. They serve a purpose and when they serve as the primary artifact then something has gone very wrong. We also suffer from the multiple-representation dilemma — and code will always win the battle where diagrams are overlapping. It doesn’t have to be this way though, and earlier systems like ObjecTime showed how synergistic code and diagrams can be.

    Further, as you pointed out, UML has been used for bad things and to force people into accepting a false demarcation between architect and programmer. I also think that class diagrams tend to be far too low level. As UML also tends not to be used to directly create code, diagrams have also been associated with waterfall and analysis paralysis.

    However, we should be very careful not to throw the baby out with the bathwater. Diagrams definitely have their place in distiling down a view of the system, and a good technical lead will use them appropriately. And hopefully, in the future, we will find a way to accommodate a visual, diagrammatic view and a coding view without tension. It’s certainly a goal that I’ve been working towards lately:

    And diagrams are very useful in the analysis of large systems. I have used tools like structure101 ( to quickly understand and work with very large codebases that have gotten out of control. i.e. 100+ developers, multi-year projects that tend towards balls of mud.

  11. As a UML practitioner, I have one major gripe with the use of UML. Most companies are not willing to buy a decent tool to create diagrams – diagrams which in my opinion need to be there for new hires to understand complex areas of code. This leaves most of us having to use tools where we spend lots of time just aligning lines and arrows which keep self-aligning to anchor points on objects. The use of these tools is nothing more than frustrating. Most of the time we don’t need to capture all the details so that we can code generate or port our model, yet just merely drawing a simple diagram with our basic design thoughts is tedious and a hindrance. So we don’t use UML, other than simple sketches on a sheet of a4 paper, we just get on with examining and writing code…

    • I too have suffered the pain of inflexible UML tools that auto-arrange boxes and lines poorly, and at times force us to enter more details than we already know or want to show in the model. These days, most UML diagrams I create use Visio or paper and pencil. You lose the consistency of an integrated model and the ability to generate code, but you gain in flexibility and speed.

  12. As a professional developer I understand all the pros of UML. However there is a huge con: no good schooling. Yes, one can say that there are hundreds of books and dozens of videos. But when it comes to real projects (not some restaurant or ATM examples) – it is not easy to describe something in UML. Maybe it is because of completely new notation (to me)?
    Can anyone recomment any good resource which will help practicing UML. And also (very important) will have some way to validate my diagrams, since without validation I really do not know if I am drawing my diagrams correctly.

  13. Very interesting points. As you have pointed out the single biggest factor is that people don’t know the notation. Even in universities they usually teach you about few UML diagram types, class and use case diagrams been the most prominent.

  14. Dima, Nishadha, you touch exactly what I listed as reason #3 people don’t use UML.
    I believe the book we wrote a few years ago is a good source for how to use UML and to contrast it with other notations that may work better in different situations. The book (Documenting Software Architectures – Views and Beyond, Second Edition) has tons of example diagrams based on real systems.
    One thing we say in the book is “You probably won’t find anyone who uses all 14 types of diagrams to document a software system. It is not a goal to try. Pick a subset chosen to match the modeling tasks you have at hand. Try to use UML diagrams that your readers are familiar with and express the right meaning. Avoid any temptation to show off your UML knowledge by using uncommon UML symbols. Otherwise you may fail to communicate the design”.
    I work with enterprise applications. All UML diagrams we create are basically sequence diagrams, class diagrams, and state machine diagrams. If the people who produce and consume design diagrams are familiar with these three diagrams, you probably may fulfill all your UML diagram needs. In the post, this idea is reason #5 for using UML.
    I often interview CS undergrads for internship positions. I’ve noticed that they all learn a few UML diagram types like Nishadha pointed out. Well, I think that’s fine, most of the cases that’s good enough.

  15. +1 on what Jeff Dickey said.

    Also: your argumentation in favor of UML is bunk.

    * Reasons #1, #2 and #4 all say the same thing: UML has been pushed by somebody – mostly obsessive-compulsive bureaucrats, it seems to me – so much that it has become a widely recognized standard and now of course there’s a lot of support around for it and expectation to see it used. This has nothing to say about how good it actually is for practical everyday development work. I’m willing to bet a year’s pay that the majority of developers who like to write actual code and make things that work try to avoid or ignore UML because they can see how impractical it is.

    * Reasons #3 and #5 both basically say that UML is so bloated and overcomplicated that you’re bound to find a few actually useful parts in there somewhere. All this says is that a better modeling language would be one reduced to those parts and that most of UML is actually no good to most developers (of course not, it’s a bureaucratic language, not an engineering one).

    * Reason #6 is just a reply to the above negative reason #5 and is not an argument specifically about UML itself.

    So yeah, thanks but no thanks.

    Now look at Object-Process Methodology and you will see an actually usable and understandable modeling language that’s just as general as UML but has only 1 (ONE!) type of diagram that fits your entire system _and_ can be launched into a sort of execution so you can see the general flow of control before you’ve even written a single line of code. You want to talk about something that’s “unified” and should be an industry standard, you talk about OPM.

  16. Only 1 (ONE!) type of diagram?!
    UML or not, people who create software design know that you need different perspectives to understand the entire system. For example, the diagram that shows the possible states of bank account is different from the diagram that shows how the banking system is packaged and deployed.
    The analogy to “real” architecture is applicable: the many people involved in the construction of a house will look at different blueprints–different diagrams.
    So, showing the entire system in ONE type of diagram sounds risky… thanks but no thanks.
    Many projects are simple enough and there’s no clear need to create design diagrams at all (#5 people don’t use UML). But for large projects involving many people from different organizations, not creating design diagrams or ignoring the diagrams is a liability. If the problem is the notation (UML), you should choose a different one (see #4 people don’t use UML).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s