UML slices code oddly. You can't fit a big system on a piece of paper. So, let's say you have a big graphics system. One of your base classes is Widget. It is

UML slices code oddly. You can't fit a big system on a piece of paper. So, let's say you have a big graphics system. One of your base classes is Widget. It is almost certainly worthless to show every class that derives from Widget on one page, even if you could. What you are really interested in is how subsystem interact when in various states. For example, you might have a map window that uses a small collection of items derived from Widget, some strategy pattern type things (to project to Mercator or whatever), and so on. The only useful graphic is a sheet that shows how all of these components interact. But, maps are complex, so you are probably pulling in and using 100+ classes. Most of which are not relevant. So it takes a human, and a lot of thought, to figure out how to slice through the code to produce a useful UML diagram for the area of interest. And then the diagrams are static. You have a bunch of other stacks of paper to try to show how things happen in time. Typically there are several scenerios - each scenerio is going to involve a different subset of classes. Its combinatorial explosion. No one can do this. Its far more work than writing and debugging the code itself. The code IS the documentation, for better and worse (and yes, sometimes it's worse). So, like most people, I do whiteboard sketches of high level design. If I am particularly pressed, I'll sit down with pen and paper, sketch 2-4 competing UML diagrams, then hand write in different transactions/events - showing how data flows, and so on. But capturing an entire source tree? Impossible, unless you just want the spaghetti diagrams that are not displayable on any monitor, and that are completely useless at telling a story.