Tools vendors stuck on UML and agility

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.