Perhaps you remember Nassi-Schneiderman diagrams as an alternative to traditional flow charts. Or perhaps you remember them as Chapin Charts. Whether you remember them or not, it's time to dig out those old computer science textbooks and bone up, because this month we're going to be drawing some of them.

There is no prototype for this Challenge, because you are going to build a complete Macintosh application. The basic requirement is that you open a text file containing valid C/C++ source code and generate a Nassi-Schneiderman diagram for each routine included in that file. To do that, you will need to provide menu options to open a file, allowing the user to navigate through the file system to select a file. You should parse the source code and open a window for each routine, drawing in the window the diagram that describes the program logic. The user must be allowed to move and resize the windows, and you should draw the diagram at a level of detail that fits into the window as sized by the user. You must provide a means for the user to select a section of the diagram, or click on a section of interest, and zoom in on that section. The zoomed-in display should increase the level of detail displayed, until no further increase in detail is possible. Your code must allow the user to switch to another application, and must properly update the window contents when appropriate.

A Nassi-Schneiderman diagram consists of four simple block types: an instruction block, an alternative (e.g., if-then-else) block, a multiple choice (e.g., switch) block, and an iteration (e.g., do … while) block. The instruction block is simply a block with code inside:

The alternative block looks like this:

The multiple choice block looks like this:

And the loop block:

Normally, these diagrams would contain pseudo-code that describes the intent of the actual code. Obviously, we won’t have pseudo-code available, so you’ll have to display something based on the code itself. Exactly what you display is at your discretion, but it should provide enough information so that you can identify the code associated with a block in the source file, subject to screen real estate limitations.

In creating the diagrams, you are encouraged to provide the user with additional features. For example, you might allow the user to change the text font and text size, and then adjust the text in the diagram if more or less text fits inside the boxes. You might provide a Window menu with the name of each diagrammed routine. You might provide an option to bring up the full text of a block inside a window. You can provide keyboard shortcuts or use modifier keys to implement special options. You might add a magnification capability that adds scroll bars to the window (in addition to the required zoom feature). You can add preference settings that make sense for your application. There might be a useful way to use color.

In the event the code contains a construct that cannot reasonably be diagramed (e.g., a goto statement), you should highlight the associated block in the diagram in some way and treat the offending construct as a no-op.

This will be a native PowerPC Challenge, using the latest version of CodeWarrior, or the development environment of your choice (provided I have a copy — email progchallenge@mactech.com to check before you use something else). You can develop for Mac OS 9 or Mac OS X. Evaluation of your entry will be subjective, based first on the required features, then on optional features, and finally on general usability and look-and-feel. To ensure that I fairly evaluate your solution, you should include in your submission a list of any optional features you incorporated.