Martin Fowler describes the way
some people use UML as a Sketch type tool rather than something formal to create
stub code or use as a formal blueprint. My personal leanings are to use it as
a Sketch myself as I find the UML diagrams helpful in defining objects BUT
anytime I want to use a serious UML tool I find that:
- It costs a lot of money for a good tool. I’m not against paying money for a good tool. But for a >single
- The tools are specific for a certain language. This is great if I was programming for language X. Too bad I’m not always using C++ or Java. Although I could just use the tool to make pretty pictures.
- The tools can be complex themselves to make them do what you want. If I spend 30 minutes to figure out how to align an object the way I want to, that sucks. I could have drawn a new one with pen and paper in oh about.. 5 minutes?
I shouldn’t knock these tools though. If I was in a different situation such as a work environment that could afford these tools they’d be great. So I’m usually back to the one dollar notepad and pencil for most of my modeling and idea brainstorming.
The idea of using UML to sketch parts of a system sounsd very attractive to me
since it’s a nice semi-formalized way to show something to someone and not have
them go ‘gee what’s that?’
Hear more from Martin:
The essence of sketching is selectivity. With forward sketching you rough out some issues in code you are about to write, usually discussing them with a group of people with your team. Your aim is to use the sketches to help communicate ideas and alternatives about what you’re about to do. You don’t talk about all the code you are going to work on, just important issues that you want to run past your colleagues first, or sections of the design that you want to visualize before you begin programming. Sessions like this can be very short, a ten minute session to discuss a few hours of programming or a day to discuss a two week iteration.
