Since it’s first introduction in 1996, UML has become widely used as the default language for software design. It’s practical application however, is still miles away from what the language designers originally intended. Did they strive for the impossible, or is this gap between goals and reality caused solely by the users of the language, and their environment?
One of the propositions that comes with Gerrit Muller’s PhD thesis (Embedded Systems Institute) reads “€œIn practise, UML is a counterproductive tool in software and systems development“€. A challenging statement, and likely not one that he added to his thesis only as a space filler. From my point of view, the cause of this counter-productiveness lies not with the UML itself, but with it’s users and the way they apply the language.

UML is a technical tool for software and system developers and as with any tool, it’s users should take care of a number of technical, organisation and process related matters. A number of these matters are discussed in this article.

Technical matters

As the name indicates, UML is a modeling language. A language which roots are embedded in object oriented software development, but parts of which are equally applicable to functional development. Even design of non-software systems is possible. Still, we’re talking about a language, not a methodology. This is a fact that is often overlooked by developers and managers, like those responsible for improvement processes.

Not long ago, someone mentioned that the Hatley-Pirbhai approach to systems development was ‘really outdated by now’. Not the best of reasons to switch to a ‘UML no matter what’ approach, given that HP is a real methodology, including both a way-of-working and a modeling language. Worse, Derek Hatley published a sequel to the original HP book in 2000, in which he, together with Peter Hruschka, added UML syntax to the overall method.

The fact that UML is such a rich language only makes matters worse. Depending on their background and eagerness to learn, developers treat UML differently from their first encounter onward. Where one developer strictly follows the standard, another one attempts to use the UML symbols as replacements for other symbols in a functional notation. The result: miscommunication on modeling level. In order to avoid this, UML has to be regarded as a language, with grammar and syntax rules that must be obeyed.

As part of introducing UML, organisations also have to select supporting tools – which must be tailored to the needs of the chosen development approach. Generating code from models requires different tools than diagram sketching on the white board of the brainstorm room. In practise however, a lot of companies select an expensive UML tool from a well known vendor, while their architects and developers spent most of their time in front of the white board and the compiler. Pity, because a lot of diagrams on the white board have no relation to UML whatsoever, and after translating them into something the tool understands the main point that led to them is lost. A waste of time, and money.

On the other hand, if people want to use a model based development approach, and generate code from models, the biggest issue becomes selecting the right tool out of many available. Some tools focus only on full UML support, while others target superb code generation. The optimal in-between solution is rarely found, although vendors like Borland, IBM/Rational and Sparx Systems are working hard to realise it. The level of UML support, as in ‘which of the 13 UML 2.0 diagrams do we need’ is another issue. While choosing a tool, organisations should know beforehand which of these diagrams they really want, and which constructs are important<sup>1</sup>.

The level of succes of using a modeling tool also depends on the level of agreement with regard to using certain UML language constructs (such as stereotypes) and checking of design rules. The balance between adopting sufficiently many parts of UML to create a consistent model, and sufficiently few to keep things understandable for all developers is a delicate one. And even when this full code generation with selected UML constructs approach is choosen, the best ideas will still come from the brainstorm room.

Organisational matters

Organisational matters start playing a role form the moment the choice for UML is made, not in the least because of the different directions from which the introduction may be initiated.

First of all, a UML design tool may be available that is not used until the day a new developer arrives, with (some) knowledge of UML. This inspires the other developers, who have been on the team for a while, and informally and uncontrolled the use of UML increases. At some point, an architect or manager will pick up on this, and starts structuring the use of the tool and the language. This is a time consuming process, with little in initial benefit, because knowledge is not shared from the beginning. Worse, there’s a risk of reduced quality both at run-time and in areas of maintainability, on the boundaries of subsystems maintained by different people with different insights.

A second reason to introduce the UML is development of a new product, where developers and architects will use every opportunity to start using new tools and new technology, in an attempt to become ‘state-of-the-art’. Quality of the development process and the resulting product are likely to improve in this situation, because people feel, and are, more involved with what they are doing. The drawback is loss of interest in maintaining the old product, which is ‘old stuff’, which is at least a minor business risk.

A final, third reason to start using the language comes from management. Sometime it happens that a company gets access to tooling, for example as part of a package deal, and management just dumps it on the engineering crew. &acirc;€œThis is what we get for free, and this is what we will use from now on.&acirc;€ A situation in which no real technical foundation for moving over is available. It will take quite while to get sufficient awareness of this problem into the management team and convince them to spent more of their budget on training and restructuring of activities. As a result, developers will develop an unhealthy dislike of language and tools.

When introducing the UML into an organisation, it is important to involve architects and engineers from the start &acirc;€“ both with respect to timing and approach of the introduction. The logical result of this involvement should be selection of the right tools and training facilities for the team that is going to use them. Afterwards, management and users should take care of continuity, by guarding ways of working through informal control (people checking on each other) and through process support. The development department deserves all possible support in the area of training and upgrades on the selected tools.

Still, all of this is useless if it is not clear from the start what the purpose of using UML is. Models in software development are equally important as blue prints in other engineering disciplines. Only if all those involved keep that in mind, UML becomes a toy for individual users rather than a useful, productive part of software development.


Processes are involved with management and control of all activities that are part of software development. In most organisations, a process is described as a set of procedures. Each procedure describes how the organisation creates or updates a specific deliverable (like a design), or how it verifies and corrects such a deliverable. Part of this is prescribed by a selected development method. While UML is only a modelling language, these procedures have no direct influence on how it is used, even though they do affect the way of working. This applies to most methodologies in which UML is used, with the exception of Model Driven Development (MDD). In the Model Drive Architecture based approach of MDD the whole development process is build around models of software, and transformation of these models into code. The Object Management Group positions UML als the preferred language for this approach. With models being the most important artifact in this approach, they become more than just illustrations for design documents. The software development procedures will thus have to be on the models, where traditionally they focus on code and documents.

Not a goal in itself

The usefulness of blue prints in engineering has been proven ages ago, and the same applies to standard notations. However, in software engineering this still seems to be a battle field. The fact that too many people still believe writing software is easy and design is just a waste of time doesn’t help us here. UML could be part of the solution, without loosing productivity, or better, by increasing productivity. Very likely, Gerrit Muller’s proposition is thus not referring to the counter productivity of UML itself, but rather that of the way of working around the language.

Effective use of UML, as with any other tool or technology, is possible only in organisations that think things through in advance. In the technical area, users have to regard UML for what it is: a modelling language with well defined syntax and semantics &acirc;€“ a development tool rather than a goal in itself. Next to this, a way of working needs to be defined in which UML fits as a modelling language, where possible based on widely accepted development methods. Effective use of UML requires proper tooling, both for modelling and process support. Involvement of people in the development organisation, both developers and management, plays an important role. The issues to deal with here are shared awareness and responsibility for everything related to introducing and using UML and the accompanying methodology. Contuous training and tool maintenance are crucial here. And last but not least, processes need to be aligned with the development way of working rather than the other way round.

Only with these preconditions in place, the balance between technology, process and organisation is sufficiently stable to succesfully and productively use UML. Not the language, but the developers using it are the key to success.

By Angelo Hulshout – Originally published in Dutch, in Bits &amp; Chips, on November 17, 2005 &acirc;€“ in Dutch.

1) after the article was published, a discussion on SysML profile for Systems engineering revealed to me that the UML standard allows vendors to call their tool UML 2.0 compliant even if it only supports predefined parts of UML. This makes ‘UML compliant’ an empty statement when applied to a tool.