UML – the Unified Modeling Language – is now widespread. But some platitudes are widespread too, in some cases acting as a brake, in other cases giving birth to unrealistic hopes.

1 – UML requires a change in the working habits, to adopt a new “methodology”.

–>
UML is not a methodology, and it does not ask for any change of working style.
UML is a language – notation for the representation of software systems in a standardized form. It is the exact equivalent, in the software world, of the notation used everywhere to represent electric installations. No electrician in the world would use a non standard notation to represent an installation: there would be no advantage. The same for UML.

2 – Using UML takes more time (and is more expensive).

–>The alternative to UML is not the absence of any representation, of any documentation.
The alternative is the use of another, non standard notation.

The big majority of software developers uses, sometimes, graphic representations. They
draw rectangles and arrows. To draw those forms in UML is not more expensive than to draw them otherwise, and it eases communication and comprehension.

3 – UML representations must be detailed.

–>
This is a variant of the previous remark. Sometimes, making explicit every detail, even those that seem obvious, may be needed. It depends on what we want to communicate, to whom, in which circumstances. In many other situations, and mostly when we use UML as an aid to think about real problems, such small details are harmful, because we lose time. UML may be used in a very pragmatic way, to represent only what we need, without useless details.

4 – UML is difficult.

–>
There is some truth. As for any language-notation, it takes some time to learn. Since UML is very articulated (it is intended to represent at various abstraction levels every kind of software system, implemented with whatever technology) the “complete” learning of UML would take – if doable! – really a lot of time.

Luckily, we can use UML in a pragmatic way, even without the mastery of every detail and every nuance, after a good learning course (if, at the end of the course, the participants do not feel able to begin to use UML in their real projects, it is a symptom that the course didn’t work).

5 – UML requires a management sponsorship to be used in the organizations.

–>
The decision to use UML is an individual one, to be taken by the single software developer.

In some cases, the management understands the advantages of a standardized language-notation to communicate better, both inside the organization and towards the outside. In such cases, the management can ease the diffusion of the UML. In other situations, the management does not care. But it is very improbable that the management forbids or hinders the UML.

6 – In order to use UML, expensive modeling tools are needed.

–>
Expensive tools are useful, in those organizations which leverage the whole of (at least, the most of) the functionalities of the tool.

But to represent software systems in UML may be used, with good results, low-cost modeling tools, even free ones. It depends on the real needs, to evaluate with a cost-benefit analysis.

7 – UML is only for object oriented projects.

–>
This is a legend, born because UML was created by object oriented gurus. Some UML concepts do have object oriented roots, some don’t.

However, UML is perfectly adequate to represent any system, no matter the implementation technologies, even, for example, those used in the mainframe environment decades ago.

8 – Using UML is in conflict with agile development methods.

–>
Agile software development methods minimize documentation, and look negatively to (non-agile) projects in which during long periods people produce documents instead of working software.

Some people think, wrongly, that UML is only appropriate for non-agile approaches. But in reality UML is used in many environments as an informal way to communicate inside work teams, not in a bureaucratic way. Any decision regarding more or less documentation, which documents are needed, who should produce those documents and when, are completely outside the realm of UML.

9 – Using UML we can raise our competence level in software design.

–>
Alas, no. UML is just a language-notation for representing software systems, not a silver bullet. The most it can help is in favoring the comparison of different solutions, because it eases communication and reciprocal comprehension among project participants.

But, the big majority of books and papers on software design published in recent years
uses UML, so knowing it is useful to improve, by studying, our competence.