Diagramming Debugger

I (Ward) developed a notation that organized a subroutine call graph over regions representing object instances. Called routines were shown in strata corresponding to the inheritance in play for the particular instance.

I created a lot of slides by hand using felt pen on transparency. I taught classes by just walking through these diagrams.

I explained the mysterious interaction between views in Smalltalk-80 that allowed a single thread to feel like parallel computing.

These diagrams were once known as "Cunningham Diagrams".

I remember the conversation with Kent Beck where we discussed the semantics of the diagram and asked the simple question: Where in Smalltalk-80 was that information available?

The information necessary to draw the diagram included static information from the source code and dynamic information from the particular trace.

The information came together in one Smalltalk-80 window: the debugger.

The debugger could single-step a method with calls on an amazing method: interpretNextInstructionFor:

We wrote a subclass of the debugger and captured the arguments of this call. This gave us enough information to add objects to a diagram as we were single stepping.

When debugging View logic control would pass from one View to another. The diagram would augment the debugger's stack view by showing which View inherited methods were executing on behalf of at any instant of time.

The diagram would get full quickly. We found that objects of interest at one moment would become clutter at the next. We just deleted them. If they participated again they would be recreated.

We were struck with how this combined the notion of a software tool with that of a notion of use in documentation. We wrote a paper on the subject for the CASE '89 Conference. paper