He's not heavy, he's my UML tool

Paul Wells, AgileJ Ltd

Photo of Paul Wells Software development tools can be wonderful things in the right hands, but it can be difficult to find the right tool for the right job. Paul Wells of AgileJ Ltd looks at what happens when UML tools meet the agile coding world.

BBC News Magazine recently ran a story entitled 'The economics of ice-cream' naming the gadgets that we purchase but seldom make any ongoing use of. The ice-cream maker topped the list. Software engineering has its own equivalents to the fondue maker and sandwich toaster in the back of the cupboard. Of course no one gives you a software tool as a wedding present, so that excuse is no use here.

The early Unified Modelling Language (UML) tools surely qualify as software's exercise bike or rowing machine. UML tools have been procured and installed in an atmosphere of heightened anticipation, only to be consigned to the storeroom when the novelty wore off and the 'real' software development began.

However UML toolmakers are reshaping their products in response, but face a community now much more clued up on alternative ways of arriving at a good design by following agile coding methods.

UML tools grow heavy

UML, adopted by the Object Management Group (OMG) in 1995, was born when the software industry had its sights set on achieving better project success rates through the application of strict engineering rigour. UML's contribution to this vision was the unification of the language of visual communication between software engineers and domain experts.

As a hand-drawn notation, UML undoubtedly continues to bring richness to the process of requirements capture and big-picture illustration. A hand-drawn diagram is fast and expressive, and there is no pretence that altering it will somehow mechanically alter what it represents.

The difficulties start when the humble flipchart is pushed aside to make space for the heavyweight UML modelling tool. Such tools, which had started out as an innocent aid to neat drawing, mutated into an entire regime for software system development centring a shared design model requiring its own repository, and staff training to get the whole thing off the ground.

Code and up-front design diverge

All software, whether the result of applying strict methods or not, possesses a design. Let us use the term 'up-front design' to distinguish the use of a planned and dedicated design phase from the design, which a programmer conceives of and expresses in source code, either directly or perhaps with the aid of a small hand-drawn sketch.

This decade has seen the notion of up-front design, central to the ethos of the UML modeling tool, met with heavy criticism from proponents of agile methods. No longer is it necessary or even desirable to invest in a system definition, which typically lives a separate life apart from the compileable code it is supposed to be documenting and directing. Eric Evans, author of Domain-Driven Design, wrote in 2004 of this divergence: 'Projects do attempt some sort of domain model, but they don't maintain a tight connection between the model and the code.

The model they develop, possibly useful as an exploratory tool at the outset,  becomes increasingly irrelevant and even misleading. All the care lavished on the model provides little reassurance that the design is correct, because the two are different.'[1]

Agile coding methods flatten cost of change

Agile coding methods have begun to change developers' perceptions of the role of design in the project life cycle. The cost of making a change to a program naturally rises over time due to the increasing impact that change will have upon the growing volume of dependent parts.

Therefore the more changes you can make at the early (up-front design) stage, the fewer the number of expensive changes that will be necessary at the later stages. But what if rather than place ever greater emphasis upon getting the up-front design correct first time, the problem could be tackled from the other end: lowering the cost of last-minute modifications?

'If the cost of change rose slowly over time, you would act completely differently... You would introduce elements to the design only as they simplified existing code or made writing the next bit of code simpler,' says Kent Beck in Extreme Programming Explained[2].

Agile coding methods focus on continuous delivery of working software, accommodating changes in requirements at any stage, and the ongoing streamlining of the design as improvements become apparent.

Test-driven development ensures that there is traceability within the code back to the requirements, and that the constant reworking of the code to fulfil a new requirement or exploit a freshly emerged design tweak never throws other parts of the system into a spin. With all of these checks and balances in place, it is reasonable to proceed with coding without any up-front design. So what role do UML tools now play?

The OMG takes modelling forward with model-driven architecture

Model-driven architecture (MDA), a second adoptee of the OMG since 2001, seeks to promote separation of the domain model from the technical concerns to enhance readability and preserve the investment in analysis. A fully automatic translation of the clean domain model to the dirty technical deliverable implies the elimination of hand-written code.

This is no small undertaking given that hand coding has clocked up many decades of maturity. But automatic translation leaves the design free to be given regular airings, each guiding it closer to its target. In other words: agile modelling. However, MDA accommodates a variable degree of automatic translation.

The more manual translation needed between the domain model and the implementation, the lower the agility, the greater the speed of divergence between model and code and the heavier the reliance upon up-front design. To the up-front designer, MDA offers domain model purity, but to the agile coder, MDA can retain design viscosity and compromise the benefits of an agile approach.


The MDA and agile coding camps both want to deliver working systems to satisfy the customer, albeit via different means. It is likely that the two will exist for some time serving different kinds of project.

Favouring MDA - a warehouse stock control system

To deliver a replacement for a large legacy system, which runs on a platform no longer supported. The customer is happy for the new system simply to replicate the function of the old but would like to avoid any future change of platform requiring an entire rewrite.

MDA works well in this case because the development process would see great benefit from the total separation of the large but manageable domain model from the unreadable implementation code containing repetitive detail about distribution, persistence, transactions and auditing. Agile coding would add little because the requirements are already known and hand coding on this scale would be slow and vulnerable to human error.

Favouring agile coding - adding a voice user interface to document management

To enable documents to be searched for, displayed, emailed or printed under speech control. No one person knows all of the requirements at the outset and this is the customer's first use of this combination of technologies. The document management system already exists and a third-party voice recognition package will be purchased.

Agile coding works well in this case because the task largely concerns wiring other systems together. Hand coding is an unavoidable but nonetheless relatively simple activity. There is no particular domain logic to model. The code will be reworked as different third-party packages are tried out.

Mix of opinion

For many software developers agile coding methods have served as a welcome reminder of what it was they ever liked about software development and why they ever chose it as a profession. For that reason they want to see agile coding succeed, and plan to return to the creation of up-front design with heavyweight tools.

Writing code is fast, expressive, gives unfettered access to the power of the programming language, and is reinforced by mature development and visualization tools. Others remain cautious of the agile coding approach, and believe the way ahead is towards the creation of better software with more refined designs using tools which remain loyal to UML.

Still others believe that ideas selected from each can be exploited where suited to the unique project they find themselves a part of.

And finally...

The tools that agile code developers recommend are generally low-cost or open source tools for developing, building, visualizing and unit testing their code. Those tools are undoubtedly the kettles, microwaves, fridges and televisions of the software world. In the right hands they give fantastic benefit for minimal cost.


1. Evans E (2003) Domain-Driven Design, Addison-Wesley.
2. Beck K (2000) Extreme Programming Explained, Longman Higher Education.