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