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

About these ads

16 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.

    http://www.intrinsarc.com

    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: http://www.intrinsarc.com/evolve

    And diagrams are very useful in the analysis of large systems. I have used tools like structure101 (www.structure101.com) 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.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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