Ten Misunderstandings About UML Modeling

Misconceptions include: UML is only for software development and if you use it, you automatically get software reuse.

by Bob Maksimchuk

Jun 18, 2010

Page 1 of 2

With a language as complex as the UML (Unified Modeling Language), which is described in a specification that is more than 700 pages long, we all can understand how parts of the UML and their use can be misunderstood. Even though thousands of books have been written on the UML, certain misunderstandings seem to still be floating around.

Most of the confusion is not about a specific UML element or its meaning (although such confusion still does exist and fuels fiery debates in certain circles), but is about the application of the UML when modeling. The following is a list (in reverse order) of common misunderstandings that I am still hearing in our industry.

[login]

No. 10: The UML is only for software development

The UML is actually a very utilitarian language. I have known it to be used for varied, non-software development purposes from modeling biological systems to analyzing legal documents. It can be used to model businesses, enterprise architectures, and manufacturing processes just to name a few. With the advent of SysML, modelers have specialized diagrams for systems engineering. Also, the UML has built in extension capabilities (e.g. stereotypes, profiles) that allow you to customize it to your particular needs while staying compatible with the UML specification.

No. 9: You need to use all of the UML diagrams on your project

This is a particularly malicious misunderstanding exploited by some less scrupulous consultants (internal or external) at their clients' expense -- literally. Having used the UML since its inception, on projects large and small, I have never seen a system that MUST use ALL of the UML diagrams to be successful. Learn the purpose of the various diagrams that are available and use the ones that best suit your needs.

No. 8: If we use the UML we automatically get software reuse

Reuse -- maybe. Automatically -- no. There seems to be an unspoken assumption here that reuse will come automatically with the use of a standard language (the UML) and object-oriented development. Reuse does not come free. The often heard rule-of-thumb is that developing truly reusable assets requires three times the effort vs. not developing for reuse. Also, in order to fully recover that cost, the asset must be reused multiple times. Reuse is a serious practice. If you really are going for reuse, it must be a key project goal, not just something you want the developers to "do" along the way. You can develop quality reusable assets, but it takes a focused effort to do so.

No. 7: The UML is good just for 'sketching' diagrams

You can use the UML for sketching diagrams. At least your team will have a common set of symbols to work with. However, the UML is not just for "sketching". (This misunderstanding took hold a number of years ago fueled by an aggressive, anti-UML marketing program.) The UML enables designers to perform very robust analysis and design of their systems, even to the point of code generation if you wish to invest enough modeling time for that purpose. Even if you are not generating code, using object-oriented analysis and design techniques with the UML, in your modeling practice, is truly valuable.

No. 6: I can use whatever UML diagram I want (i.e. UML diagrams are interchangeable)

You could try this but it quickly will degrade into the old "Lipstick on a Pig" joke. While it is true that various UML diagrams share similar overarching purposes (i.e. some depict structure, some depict behavior), they are not necessarily interchangeable. Each has a particular viewpoint. For example, two behavioral diagram types, Activity and Sequence diagrams, both can depict behavior. However the "focus" of an Activity diagram is the flow of a process, whereas the focus of a Sequence diagram is the time ordered sequence of messages. Yes both can describe a behavior, but each approaches this from a different direction. Use what works for you, but understand the strengths of each diagram type before you choose to use it.