If you've ever modeled classes in Visio's UML, you may or may not have known that you can actually copy the contents of the classes as text. If you select the class box and copy it won't work, but if you click again on either the method or field section, you get a sub selection and you can copy this as text. It will copy whatever you have set to be visible. Why is this a big deal? Well, it isn't, but if you generate code from lists, or use, erm, 'clipboard generation', then it can save you some time. Code gen doesn't have to be lofty, you can hack a little util into your favorite text editor in minutes and it can still be pretty handy. I used to even use an swf on a bookmark. The fla in same dir, same name, if you care to modify it. It is always nice to witness ugly code producing pretty code. This can happen with genetic code too, as my kids have proven. This is known in nature as the 'flower in the shit pile' pattern. Where there is nothing else, there is hope...

Speaking of large piles of shit with the odd daisy, lets talk a bit more about uml. Ideally there is a stronger connection between your uml model and code -- this way changes to the code update the model. There are C# (etc) backends for this in Visio, but none for actionscript that I know of. That being said, I find things like uml only become useful once you lose all respect for it. I mostly use uml as a throw away black board for class models. Like a lot of good ideas, it is a very simple concept (layout your program structure visually like you would on paper, dragging instead of drawing). Like a lot of good and simple ideas, those involved tend to want to make it more complicated (xml anyone?). Their giant minds are worthy of oh so much more than pithy concepts that can be explained to children. So they set out to solve all computing problems, to overcome all communication problems, to win every pissing match, and to reduce anal itching by fifty percent. What we end up with is usually more complicated than the problem we need solved, and ends up being just another way of representing the same jumbled mess we started with.

Uml has certainly blazed down that path in parts - which is fine, I'm sure innovation comes of this at some point. The nice thing about uml though, is that you can still just pick a little chunk from the running fester that is useful to you, and there is no penalty. There are no extra requirements that breed extra requirements. There are no component incompatibilities or glue code. There are no extra bugs introduced (even if your arrows are all backwards, or you didn't put any in). You are left with a handy little reference, and work gets done. It is the programmatic equivalent of storyboards (which incidentally, are also completely useless if they are treated as anything but a fast and simple way to model an animation - argh already!). Like storyboards, uml is most useful if done before all the work, not afterwards to satisfy some requirement ; ). Actually, even though programming is often related to achitecture, I think the process most resembles animation production - and there is much much much much to learn both ways there. Hmm, topic for another day.