Diagrams, diagrams, diagrams

I’ve been sitting here for the last couple hours contemplating a program design in my head. (Actually, I’ve been contemplating this design for a month or so, but I really was putting some brain power into it for the last couple hours. Anyway…back to my point…) I have decided to start putting the ideas into some codified form in an effort to start documenting my code and designs better. In trying to figure out which diagrams to draw, I realized that it has been so long since I have done a formal diagram to formal standards that I have actually forgotten a lot of the minor notations. I’ve decided to go with UML, but I have forgotten the rules for using a filled in shape vs. an empty shape, not to mention all the line styles needed to convey relationships…GASP! Looks like tomorrow that I’m going to have to dust off the UML Distilled book laying around here somewhere.

It’s no wonder that I’ve forgotten a lot of these diagramming tools: Many of the clients I work for don’t have a clue what they’re looking at. For the last 4 years, I’ve been relying on text-based use cases because everybody, regardless of technical skill, can communicate with them. Frankly, I’ve gotten use to and comfortable with this format. There are some serious drawbacks to this though, namely the difficulty in seeing interactions between more than a couple modules at once. I seriously need some activity diagrams so I can start writing better test cases. I need to quit being such a Duct Tape Programmer. It’s quick, but it makes maintainability much harder than it has to be.

The best news is that free, open source diagramming tools are exponetially better now than they were just 4 years ago, so as soon as I acquaint myself with some of the formalities, I should be able to have my diagrams cranked out in no time.

Leave a Reply

Your email address will not be published. Required fields are marked *