Thursday, June 16, 2011

UML for Reverse Engineering

There's an entry on Martin Fowler's blog that I find interesting. I talks about using UML as a tool to understand the existing code. It resonates with me since that is how I find myself using UML lately i.e: more as a reverse engineering helper than as a top down development design tool.

I still use UML in a top down fashion sometime, usually when trying to solve certain mechanism directly in the code seems to spawn too much options/thoughts. This is the time that I usually fire up UML tool (I use Astah, BTW) and do some mockup of classes, association and interations until it's clearer what I need to do next in the code. However, this is not frequently happening since many coding tasks have a clear next-actions (to borrow GTD term).

On the other hand, reading existing code usually require the understanding of the base code structure first before I could do the tracing and debugging. It's like try to get a map first of the are so I know where the location of certain things and how I can get from there to somewhere. This is where the UML come in, to help get the understanding of the big picture of the code. And like the above article said, I find using our own modelling is much more useful in getting the understanding of the code than using automated reverse-engineering typically exist in CASE Tool.

I usually keep the file/diagram for future references/re-use but not neccessarily keeping it updated as it's already done it's purpose i.e: helping to drive the development process and keep moving it forward. I could always refresh the model when needed, for example when trying to understand part of the code that I haven't been working on for a long while.

No comments: