Using Diagrams effectively
I recently had to draw some diagrams for a recent project involving a complex GUI. It is all too easy to get sucked into adding more and more detail to UML class diagrams, until in the end you lose the design message you were originally intending to convey. You end up spending more time drawing a diagram which is actually less instructive.
I was interested to see Martin Fowler’s comments on this, in his essay entitled ‘Is Design Dead‘ :
So here’s my advice for using diagrams well.
First keep in mind what you’re drawing the diagrams for. The primary value is communication. Effective communication means selecting important things and neglecting the less important. This selectivity is the key to using the UML well. Don’t draw every class – only the important ones. For each class, don’t show every attribute and operation – only the important ones. Don’t draw sequence diagrams for all use cases and scenarios – only… you get the picture. A common problem with the common use of diagrams is that people try to make them comprehensive. The code is the best source of comprehensive information, as the code is the easiest thing to keep in sync with the code. For diagrams comprehensiveness is the enemy of comprehensibility.
I suppose effective diagrams are often, by nature, a simplification of real life.
I am thinking now of the London tube map, which famously abandons geograpical accuracy in favour of legibility and good communication. In comparion to the map of the New York metro, it is fabulously easy to interpret.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Leave a Reply