NASSI-SHNEIDERMAN CHARTS
1. SEQUENCE:
2. DECISION:
3. LOOP:
WHILE LOOP FOR LOOP DO WHILE LOOP
4. SUBPROCESS:
THIS SYMBOL IS USED TO REPRESENT A
FUNCTION CALL
1. SEQUENCE:
EXECUTE STATEMENTS IN
SEQUENTIAL ORDER.
NOTICE: NO BRANCHING
2. DECISION:
IF THEN ELSE
IF (BOOLEAN EXPRESSION IS TRUE)
THEN DO THIS
ELSE DO THIS
CASE STATEMENT: USED WHEN THERE ARE MULTIPLE POSSIBLE
CONDITIONS (MORE THAN TWO)
3. LOOP:
WHILE LOOP: PRE-TEST. USE
THIS LOOP STRUCTURE WHEN
YOU NEED TO TEST THE
CONDITION BEFORE ENTERING
THE LOOP.
FOR LOOP: USE THE FOR LOOP
WHEN THE NUMBER OF REPETITIONS
IN THE LOOP IS KNOWN.
DO WHILE LOOP: POST TEST.
USE THIS LOOP STRUCTURE WHEN
YOU WANT TO TEST THE CONDITION
AFTER EACH ITERATION OF THE
LOOP.
NASSI-SHNEIDERMAN CHARTS
An Alternative To Flowcharts For Design
INTRODUCTION
In recent years, structured programming has emerged as an advanced programming technology, and many tools have been developed for facilitating the programmers’ use of structured programming. One of these tools, the structured flowcharts developed in 1972 by I. Nassi and B. Shneiderman, is proving its value in both the design and coding phases of program development. This paper describes the uses of and techniques for producing Nassi-Shneiderman charts.
PROBLEMS ADDRESSED
Several IBM programming groups in Endicott, New York have been using Nassi-Shneiderman (N/S) charts as replacements for conventional flowcharts in structuring programs. On some projects, the charts have been used extensively for structured walk throughs, design reviews, and training.
This paper describes N/S charts and explains their use in programming, in development process control, in walk throughs, and in testing. In addition, the value of N/S charts is analyzed and compared to other design and documentation methods, including pseudocode, HIPO charting, and conventional flowcharts.
N/S charts have many features to recommend them for use in top-down structured programming environments. It is, in fact, extremely difficult to design unstructured programs using the charts. It should be noted, however, that N/S charting is not the only language technique that has been developed: pseudocode, for example, is another excellent technique. Nor is N/S charting the only documentation method. Pseudocode can be useful for program documentation, HIPO charting also has many advocates.
Because each of these techniques has its advantages and disadvantages, and each is useful in certain situations, this paper compares N/S charts to other design and documentation methods.
STRUCTURED PROGRAMMING CONCEPTS
Structured programming, contrary to some programmers’ beliefs, is not a set of coding rules and restrictions. Structured programming is a style, an attitude toward programming that starts with the fundamental goals of the programming process. Classically, these goals were correctness, efficiency, and creativity. Of these, correctness is the only goal that is still considered valid. Efficiency is considered less important because of the advent of very high speed computers and virtual memories. Creativity, while not bad in itself, was typically directed toward cleverness and obscurity, frequently with detrimental results.
In today’s programming environment, new goals have been set. Correctness remains the primary importance, however, maintainability and readability have replaced program efficiency and obscurity as desirable characteristics. The programmer who sacrifices maintainability to save a few bytes or who gleefully hands over a program saying, “I’ll bet you can’t guess what this one does!” is finally receiving the disdain so long deserved.
Once these goals were set, it was inevitable that many programming techniques would be developed to achieve them. One of the best techniques has been structured coding. This is a set of standard coding methods for accomplishing the goals of structured programming. Structured coding uses a set of program structures (with one entry point and one exit point) sufficient for writing any proper program, together with some rules for segmentation and indention. The required set of program structures is not unique; the minimum set is usually thought to consist of the SEQUENCE, IFTHENELSE, and DOWHILE structures. Frequently, other structures such as DOUNTIL and CASE are included.
NASSI-SHNEIDERMAN CHARTS
In SIGPLAN, Notices of the ACM, August 1973, Nassi and Shneiderman published a new flowcharting language with a structure closely akin to that of structured code. The advantages they claim for their charts, which have proven to be correct are as follows:
[] The scope of iteration is well defined and visible.
[] The scope of the IFTHENELSE clause is well defined and
visible, moreover, the conditions or process boxes
embedded within compound conditions can be seen easily
from the diagram.
[] The scope of global and local variables is immediately
obvious.
[] Arbitrary transfers of control are impossible.
[] Complete thought structures can and should fit on one
page (i.e. – there should be no off page connectors).
[] Recursion has a trivial representation.
[] These charts are adaptable to the peculiarities of the
system or language with which they are used.
By combining and nesting the basic structures, all of which are rectangular, a programmer can design a structured, branch-free program. Note that a PROCESS symbol can have other symbols nested within it, and can be of any dimensions as long as it fits on one page.
The IFTHENELSE symbol is used to represent a decision. This symbol contains the test or decision in the upper triangle and the possible outcomes of the test in the lower triangles. “YES” and “NO” can be substituted for “TRUE” and “FALSE”, and there is no particular objection from switching them right and left, although consistency is desirable and should be maintained for readability. The rectangles contain the functions to be executed for each outcome. Note that the ELSE and THEN clause boxes are actually PROCESS symbols and may contain any valid PROCESS statements or nested structures.
Repeating processes are represented by an iteration symbol. One of three symbols can be used depending on whether loop termination is at the beginning or end of the loop.
The form of CASE requires the setting of a variable to a value, and the choice of path is based on the value of that variable.
The nesting of structures to create programs should now be an obvious extension of the use of basic symbols.
USING NASSI-SHNEIDERMAN CHARTS
The major uses of N/S charts are: creating the logic design, programming from the charts, and writing program documentation. In addition, N/S charts can be used for higher level design and procedural documentation as well as for walk throughs and design review.
CREATING THE LOGIC DESIGN
N/S charts were developed as an alternative to traditional flowcharts for describing the logic of a structured program. Drawing the chart and developing the logic go hand-in-hand. In fact, the constraints of N/S charts (single page, no branch symbols) force the development of a structured design that in turn leads to a structured code.
To start, let us assume that the functional design for a project has been completed and that a modular design technique was used to determine function, input, and output for each module to be programmed. At this point, the programmer is ready to design logic for structured coding.
An N/S chart starts with a rectangle drawn at the top of the page. This block can be any of the N/S symbols, depending on the module’s function. If the module requires initialization of some variables, the first block would probably be a PROCESS symbol. If the module’s function is to be performed repeatedly, a block with an iterative symbol would be near the top of the page. If the function to be performed is conditional, a decision symbol would be used initially.
When a block symbolizing a decision is drawn, the programmer must make a decision about the assignment of processing paths on the chart. An effective technique is to use the right path for the equivalent to the THEN clause of an IF statement and to use the left path for the equivalent to the ELSE clause. Note that a consistent technique for path assignment makes the charts easier to draw and to read.
Note that if repeated decisions must be made, it is possible for much of the page to be taken up by blank paths (corresponding to null ELSE statements) or by paths with little processing. This would leave very little room for describing the main processing path of the program. A technique for handling this problem is described next.
As the programmer continues to draw the chart and develop the design, nested iteration and decision symbols cause the blocks to get increasingly smaller. If the programmer does not initially give some thought to segmentation of the module, she or he may find that space has run out before the design is complete. Any rectangular portion of an N/S chart can be removed from the main routine, be replaced by a processing block, and made a separate segment or internal subroutine with its own N/S chart.
DIFFERENCES IN N/S STRUCTURE
The N/S chart for a module visually reflects the design of the module. It can be large or small, complex or simple, depending on the function to be performed. A module at the top of the modular design hierarchy consists mainly of calls to lower level modules and evaluation of return codes. Its chart will probably have a diagonal look.
A module at the lowest level performs the actual processing of the data.
To allow more room on the chart for describing the processing paths, the decision triangle can be skewed, allocating space as it is needed.
PROGRAMMING FROM N/S CHARTS
Once the logic design for the module is completed, coding and testing of the module can begin. In both coding and testing, the N/S chart serves as a guide.
Translating from the N/S chart to code, especially in a high level language, is very easy. This ease is one reason why N/S charts have been accepted enthusiastically by most of the programmers who have tried them.
The code will be structured, there is no possibility of a branch, and the coded segments will be small. Note that IFTHENELSE statements are well defined by the chart, as are the limits of the DO structures.
The N/S chart can be used as a guide while testing a module. The number of test cases required can be readily determined by counting decision blocks (count two per decision) and iteration blocks (count two or three per loop, depending on loop boundary conditions).
The precise test cases needed and data required can be developed directly from the charts, and the tested paths can be checked off on the charts as the tests are executed.
N/S CHARTS AS DOCUMENTATION
The N/S chart is a graphic representation of a module’s logic design and a blueprint for the code. This makes it an excellent tool to use in training other programmers in the function of the module. An N/S chart provides a maintenance programmer with a quick reference for finding the code that performs each logical function.
This paper has described the use of N/S charts to design and program structured code. The high acceptance level of the charts by programmers who have used them, however, indicates that the symbols can be readily applied to other activities such as functional design, for example. For this use, process blocks can be described in general terms, rather than at the detailed level used for logic design.
As the use of N/S symbols and charts extends beyond programmers to people in other technical areas (as have traditional flowcharts and symbols) they can become part of a user’s procedural documentation.
Another area in which the use of N/S charts has expanded beyond initial expectations is for presentations at walk throughs and reviews. The graphic, visually descriptive qualities of the charts make them quite suitable for use as presentation aides, describing the program function to users and nonprogrammers. Code inspections are significantly easier when a corresponding N/S chart is available to graphically depict the code under inspection. If N/S charts are used for design inspection, code can be compared directly with them in such inspections.
A COMPARISON WITH OTHER DEVELOPMENT TOOLS
Of many design/documentation methods in use today, some of these methods have existed for many years, and some methods have been developed recently. Among the older methods are prose (the writing of specifications in English paragraphs), and conventional flowcharting. The newer methods include N/S charts, pseudocode, and HIPO charting. None of these methods is the best in all situations. For a particular use, one is often better than another.
For example, a program design at a high level, such as a functional specification, can often be best described in prose and with HIPO charts. Yet, neither of these methods is much good for detailed logic specifications. Prose is often ambiguous and seldom possible to use for coding, while HIPO charts have no facilities for structuring program logic and are also difficult to use in coding.
Flowcharting has usually been the method to get from prose or HIPO carts to code, however, flowcharting is quickly giving way to pseudocode and N/S charts. The latter tools have structuring ability built in and both can be easily translated directly into code. Pseudocode has the advantage of graphically depicting the logic and also clearly and visually identifying processes within compound conditionals.
For training users and for walk throughs and reviews, a combination of HIPO charts for input/function/output and N/S charts for logic has proven extremely useful. Flowcharts and pseudocode are too strongly programmer oriented for use by nonprogrammers. Pseudocode can be useful for code inspections, particularly if coded into the program as comments.
Program documentation has traditionally been separate from programs. One of the anticipated benefits of structured code was self-documenting programs. To some extent, this benefit has been realized, yet, in many cases, supplementary documentation is required. Pseudocode provides one excellent way of including this supplementary explanation of code within the program as comments. Modification of documentation then requires exactly the same mechanism as modification of the code, and as a result, it aids in maintaining documentation currency.