People sometimes do a double take when I talk about analysis, design and agility in the same sentence. And if I mention UML and agility, they spin round several times and fall over. At the expense of inviting a flurry of email replies for posing a rhetorical question, I have to ask: why?

Aside from the analysis paralysis issue, there's also the problem that most, if not all, UML tools just don't measure up to the rapid development experience offered by modern integrated development environments (IDEs).

Martin Auer, co-creator of the open source UML modeling tool UMLet, agrees this is a real problem, one that most tool vendors appear to be blithely ignorant of:

"The topics we feel strongly about have less to do with UML tools as with tools in general: in many instances, they get in your way, distract you, and break your workflow. This happens with pop-up dialogs, bubble alerts, sounds etc. Also, tools often require you to make steps that are unnecessary, but tedious and difficult to automate. This, along with the growing number of unnecessary features in applications (media player in PDF files, autosummarize in Word) makes many tools' usage unintuitive."

The problem is horribly obvious in UML tools. It's difficult to fly along when the user interface (UI) forces you to click through fiddly dialogs and operate on individual model elements at a time. Modern IDEs, on the other hand, grease the skids of agility. Their creators understand the agile mindset.

With support for pattern-based refactoring we've begun to see a single mouse click perform several steps for you. In NetBeans, Eclipse and IDEA, for example, many refactorings are tied to keyboard shortcuts, that further ties them into the coder's workflow.

Working with legacy code in IDEA I continually use Ctrl-Alt-M not just to extract a method, but as an auto scan to see if there are any dependencies on a block of code - variables passed in from outside its scope. The function works well because it's quick, doesn't get in your way, and it's useful.

Developers are a demanding group of people, and even if the end-user UIs they create might not always be considered especially usable, the irony is their IDEs are.

Contrast this with UML tools, which have always been - and generally still are - extremely awkward to use. If you've created a component and linked it up to a dozen or so classes in different packages, then decide that it isn't really a component but an external Actor it should be a quick change to transform its type, right? Pretty much all modeling tools will require you to create a new Actor then recreate all the relationships again. Is this agile, or the sign of a tool vendor who hasn't thought about the users?

This example goes to show how rigid UML tools are for the modern agile developer. We've grown used to being able to create a Java class and refactor it to smithereens, pushing methods up and down, extracting interfaces and introducing variables. So this raises the question: if you right click on a model element in any modern UML tool, where's the refactor sub menu?

In fact it should be a prefactor sub menu, as you'll be working on models that may not exist in code yet. UML tools do have functions that could class as prefactoring tools, but they're distributed around in the UI, not centralized under a single sub menu that hangs off a model element.

It's a mindset thing. However, I predict that the first modeling tool to offer a prefactor sub menu will hit the industry like a bolt of lightning. It'll do for modeling tools what refactoring support did for IDEs.®

Matt Stephens is co-author of Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to get from use cases to code using a core subset of UML, and Extreme Programming Refactored: The Case Against XP.

More comments…

Related stories

Read, test, don't repeat - how to avoid code complexity (5 May 2008)
Micro Focus buys NetManage (1 May 2008)
Hafta Man and the threat to agile design (30 April 2008)
JBuilder 2008: Bold vision, rough edges (28 April 2008)
Early calls to simplify Eclipse (31 March 2008)
Comment judiciously, refactor if needed, avoid the 'f' word (28 March 2008)
Next Eclipse platform in two years (20 March 2008)
Sweet, sweet smell of comments in code? (18 March 2008)
Uncovered: the lost humor of flowcharts (17 March 2008)
Next Eclipse platform could slip IBM's grip (14 March 2008)
IBM shadow looms over next Eclipse (11 March 2008)
SOA benefits: too much reuse of reuse? (8 March 2008)
Time for UML tools to evolve (29 February 2008)
Agile lands role in games and business software (28 February 2008)
UML officially an unfunny matter (20 February 2008)
Ruby runs on Rails with NetBeans (13 February 2008)
Polished NetBeans means Ruby (31 January 2008)
Streamline your search with Yahoo! Web Services and AJAX (29 January 2008)
Penguin-powered UML modeling (29 January 2008)
Salesforce.com bitten by the ALM bug (17 January 2008)
Eclipse gets Fishy on SOA (7 January 2008)
Telltale signs your model is stuck (3 January 2008)
Sequence diagramming that's fit for purpose (22 December 2007)
How to avoid the model quagmire (18 December 2007)
Close the gap between analysis and design (14 December 2007)
Bloody code! (4 December 2007)
Model use cases that work (23 November 2007)
Boffins: Dark times for application development (1 October 2007)