In the days long ago before I joined Microsoft, I was an itinerant consultant in UML.

I'd wander the countryside with a slide deck, a projector and a cooking pot on my back, gathering small crowds under the shade of a tree to tell them the Good News: about how they could better understand and communicate about their software designs by drawing boxes, lines and stick people on their cave walls; and about how they would, if they did this properly, surely achieve their goals and feed their families. Well - they'd improve the chances a bit, anyway. I asked only a mug of tea and a biscuit in return. (And my standard fee, of course.) It was an ascetic life but a rewarding one, particularly when some youngster would show especial enthusiasm and I would introduce them, by the flickering light of my camp PC, to the arcane beauty of the Object Constraint Language and its virtues in the successful construction of tests; or the subtleties of covalent and contravalent composition among collaborations, and their uses in describing and applying design patterns.

But there were sorrows too. And the most poignant of these came whenever my followers gathered about me would ask, as they inevitably would, "OK chief, this UML stuff is cool. But what about tools?" And I would have to shake my head with a heavy sigh and reply that alas, there were apps that would help you draw the diagrams, but few that really delivered the goods in terms of what you'd want to do with the drawings once you'd drawn them. And that in consequence, they might as well stick to drawing on the cave walls. (Note: if you wish to do this, please make sure your walls are made of glass, and use dry-wipe pens.)

And one or two of them, perhaps those who had traveled beyond the bounds of their own village, would sometimes say "Yeah, but we heard you can get these tools where you can reverse engineer your code into diagrams, and then edit the diagrams and transform the diagrams back into code." And I would agree that these tools are indeed of value in showing you the complex interactions between the objects, and to help you visualize the links and dependencies between the classes. But after all, they only give you pictures of what is there in the program text. These tools have no power to abstract the higher design of your code, the grand vision that was in your mind when you wrote it (always assuming you had a grand vision, of course...); they cannot know what you meant when you wrote the code. That meaning has to come from you.

This is the real strength of UML, properly used: to help you think about and discuss and communicate the crucial aspects of your design in just a handful of skillfully-chosen lines. A bit like a cartoonist drawing the key features of a politician; and not like a camera slavishly recording pixels. Good UML tools don't just do the reverse engineering - they also help you express your big ideas, help you look at them from different angles, and help you turn them into plans, designs, and tests.

So I'm delighted, now that I'm working for a toolsmith, to be working on modeling tools. And yes, some of the tools are about reverse engineering from code - and they do in fact help you abstract the overall structure. But they are also about using UML to understand your users' needs better, and to help you meet those needs successfully.

My role is to write the user guides - not just at the mechanical level of what button to push, but also about how to make good use of UML in your project. So in this blog, I'm going to talk about that - and, I hope, hear from you how you use UML - and what you want from our tools.

BTW, I wrote a blog about domain specific languages a few years back.