A tool that we use almost exclusively to design the processes that make up our systems is the Nassi-Schneiderman chart. An alternative to the overly flexible flow chart, NS charts enforce structure and modularity in the programming process. An excellent NS charting tool is available that makes the use of NS charts quite painless. This white paper describes NS charts and illustrates their advantage in the modern world of structured programming.
We all give lip service to “structured design techniques” but how many of us are true disciples? Even worse, how do we control a programming group faced with impossible schedules when getting something – anything – to demonstrate quickly to management is the top priority item? Wouldn’t it be nice to have a design tool that enforced structure? That is what this paper is about.
The first key to building a well-structured system, of course, is to design the system before building it. Can you imagine your anger at an architect who directs a contractor to build the kitchen and living room of your new home only to find out there is no wall space left for a door to the bedroom? Yet we often seem to build software systems in this piecemeal fashion. I often hear the excuse “We don’t have time to design.” I submit that any system will be put into operation faster if it is designed properly in the first place. If you don’t have time to design, then you certainly don’t have time not to design.
Given the acceptance of proper design, we now can turn our attention to design tools. A good design tool should:
- Enforce structured design.
- Enforce program modularity.
- Be easy to use.
- Generate design documents easily understood by others.
There is, in fact, a hierarchy of design tools required for a large project. At the outset, we must define the software architecture and the data flow between elements. This paper concerns itself with the next level – the detailed design of a program module.
The classical flow chart used for program design has many shortcomings, the greatest being its extreme flexibility. Any imaginable structure can be represented by a flow chart; hence, desirable structures cannot be enforced. Furthermore, arbitrarily large programs can be designed, defeating any attempt at modularity. Have you ever tried following a flow chart from page three via an off-page connector to page 17, then back to page 10? And the code is as bad!
Our choice for an excellent tool which has proven its worth on dozens of large projects is the Nassi-Schneiderman, or N/S chart, named for I. Nassi and B. Schneiderman, who published this technique in 1982. (some may recognise these as Chapin charts.)
The N/S chart starts with the basic characterization of modern day languages as being block-structured languages. In these languages, procedures are blocks as shown in Figure 1. A block has a beginning and an end. When the procedure is called, or when the process is entered, instruction execution begins at the beginning (or top) of the block and proceeds to the end (or bottom) of the block.
 |
Sequential Statements
Figure 1
Figure 1 shows the simplest block. It simply contains a sequence of instructions.
The conditional IF structure is shown in Figure 2. At the top of the block is a conditional test. Depending upon the outcome of the test, one of two paths are taken through the block. If X equals Y, procedure A is executed. If X does not equal Y, procedure B is executed. In either case, control is passed to the top of the block and falls to the bottom of the block.
 |
IF X = Y THEN A ELSE B
Figure 2
Figures 3 and 4 show the WHILE-DO and DO-UNTIL structures. These are similar except that the WHILE-DO structure evaluates the condition first before executing the procedure, and the DO-UNTIL structure executes the procedure first and then evaluates the condition. In Figure 3, if X is not equal to Y, procedure A is executed; otherwise, control passes through the block. In Figure 4, procedure A is executed, and then the condition is evaluated. If X is not equal to Y, then the procedure is re-executed; otherwise, control passes from the block.
 |
WHILE X NOT EQUAL TO Y
DO A
Figure 3
 |
DO A
UNTIL X = Y
Figure 4
The FOR structure in Figure 5 executes the procedure A repetitively over a specified range of the variable X. Entering the block from the top causes the first value of X to be chosen, and A is evaluated relative to that value for X. When A completes, control is returned to the top of the block where the next value of X is chosen. When all values of X have been exhausted, control passes from the block.
 |
FOR X FROM Y TO Z
DO A
Figure 5
The CASE structure is shown in Figure 6. The variable X is tested. If its value is 1, 2 or 3, the procedures A, B, or C, respectively, are executed. Otherwise, procedure D is executed.
 |
CASE ON X
Figure 6
Note that not only are all these structures representable as blocks but their sub-elements are also blocks. These sub-elements may themselves be any of the allowable block structures. The structures shown in Figures 1 through 6 are only the most common ones. Though they are sufficient, other structures may be defined for a particular project.
Let us consider a simple example of an N/S representation of a program. A server named MSGAB must service a queue of messages. There are but two types of messages, A and B, to be processed by the procedures MSGA and MSGB, respectively. Once given control, the server processes all messages, if any, in its queue. If there are no messages, then the server must return an “I’m Alive” message to indicate to the calling procedure that it is still operational. Before exiting, it updates statistics. One exception condition is the receipt of an erroneous message type (not A or B). In this case an error message is returned and processing of further messages is terminated.
The N/S chart for this server is shown in Figure 7. It comprises three main blocks. The first one initializes various parameters in the program. The second one performs the message processing. The third block updates statistics.
The message processing block checks to see if there are any messages in the queue. If not, an “I’m Alive” message is sent. If the queue contains messages, their message types are analyzed via a case statement which calls the appropriate message processing routine (MSGA or MSGB). If an erroneous message type is found, an error message is sent and an exit is made from the server.
Note that three new notations have been introduced:
The procedure or process name is indicated at the top of the chart.
Called procedures are noted with asterisks (e.g., *MSGA*).
The EXIT operator is an implied transfer of control to the bottom of the block, thus terminating the procedure or process.
 |
N/S Example
Figure 7
In this example, the nesting of structure is clearly shown in the message processing block. This block is an IF structure which contains a DO-WHILE structure which contains a CASE structure.
The power of N/S charts as a design tool useful for controlling the quality of a design group can be appreciated by noting the following:
A procedure can have only one entry point (the top) and only one exit point (the bottom).
No off-page connectors exist, so the program is forced to be modular. Large procedures simply cannot be represented. They must be organized into control structures which call other procedures.
Only acceptable structures can be used.
Nesting of structures is limited by the fineness of one’s pencil point. It is difficult to draw IF statements nested 11 deep.
There is no way to represent a GOTO. GOTO-less coding is assured. (The EXIT operator is the only case of a very limited use of GOTO in some languages.)
Structured coding proceeds pleasantly and effortlessly from these charts. Whereas (in Nassi and Schneiderman’s words) “the translation from flow chart to computer program is a one to many relationship whose output ranges over programs only some of which are legible, concise and efficient,” N/S charts give rise to code that is quite consistent in its content and quality.
In these days of being tied to the keyboard, no tool is adequate unless it can be automated at the developer’s desktop. Fortunately there is an excellent NS tool that is even integrated with Word, allowing NS charts to be treated as objects in a Word document. One simply types in the pseudo code for the desired NS chart, and out comes a pleasantly constructed chart. This tool is available from Kast Associates (bobk@legato.com).Using this tool, the previous example would be represented by the following psuedo code:Initialize
IF Message_To_Process THEN
WHILE Message_Queue_Not_Empty DO
SWITCH Message_Type;
CASE
A;
*MSGA*
CASE B;
*MSGB*
CASE
Other;
Send_Error_Message
Exit
EXIT
END
END
ELSE
Send_I'm_Alive_Message
END
Update_Statistics
A click on a button yields the following NS Chart:
 |
Thus, N/S charts represent a valuable design tool to enforce structure and modularity and to insure a consistent quality of design throughout a programming organization. In addition, these charts present an easily understandable depiction of data flow to the non-designers – the programmers and the users – and as such form an invaluable basis for maintenance documentation.
Back to design documentation tools
Back to the IPM Lecture Notes index