STEPS TO PROGRAMMING
1. Define the problem - This step involves carefully reading and rereading the
problem until you understand completely what is required. To help with initial analysis
the problem should be divided into three separate components.
 The inputs
 The outputs, and
 The processing steps to produce the required outputs
2. Outline the solution - Once the problem has been defined, you break into smaller
tasks or steps and establish an outline solution. We will use a Hierarchy Chart to
show outlines in this class. This initial outline is usually a rough draft of the solution
which may include:
 The major processing steps involved, and
 The major subtasks (if any)
3. Develop a skeleton - The framework from which to begin programming. A
skeleton will compile and execute. It contains function stubs and menus.
4. Develop the outline into an Algorithm - This involves expanding the outline to
include the precise steps that describe exactly the tasks to be performed and the order
in which they are carried out. We will use Nassi-Schneiderman Charts to represent
the solution algorithms in this class. Other methods that can be used are Flowcharts
and Pseudocode. This step includes the use of:
 Major control structures, and
 Mainline logic
5. Test the algorithm for correctness - The main purpose of desk checking the
algorithm is to identify major logic errors early, so that they may be easily corrected.
The programmer walks the logic of the algorithm, exactly as a computer would,
keeping track of all major variables on a sheet of paper.
6. Code the problem - The logic from the developed algorithms is added to the
functional skeleton created in Step 3.
7. Run the program on the computer - Correct any syntax errors found during
compiling. Enter a set of test data that will provide known results to determine if the
program functions as desired. This step may need to be performed several times with
corrections being made to the program.
8. Document and maintain the program - Documentation involves both external
documentation (such as hierarchy charts, Nassi-Schneiderman Charts, and test data
results) and internal documentation that may have been coded in the program.
Program documentation is really an ongoing task from the initial definition of the
problem to the final test result.
HIERARCHY CHARTS
Program
0000
Initialize
1000
1100
1200
Meat of Program
2000
1300
2100
2200
Clean up
3000
3100
3200
RULES FOR HIERARCHY CHART DESIGN








Each block must be fully described by its children (if any)
NO single children
If you have more than about 5 children consider breaking the structure down
further.
Children functions performed in order
Start simple and then break each block down until you have the detail required
so that ANYBODY can understand the sequence of events.
Do not include logic in the hierarchy chart. Write as if you are only going to do
something once.
Number each process
Each process needs to be labeled with a VERB and OBJECT
Because child processes fully describe their parent, the following sequence of
processes will be performed:
1100
1200
1300
2100
2200
3100
3200
FUNCTIONAL PROGRAM DESIGN
We break up programs into subsets of code called functions. This allows more than
one program to work on the same program and provides for easier maintenance of the
program.
 Once the chart is designed, determine where you will break your code into
functions. Each function (in code) should fit on the computer screen (24
lines)(not a hard fast rule)
 Indicate the a process is a function by placing Bars inside of the box (see 0000)
For the purposes of this class all programs and hierarchy charts will have at least three
levels, have at least two functions besides main(), and at least one function besides
main() will call another function.
THE STRUCTURE THEOREM
The Structure Theorem forms the basic framework for structured programming. It
states that it is possible to write any computer program by using only three basic
control structures that are easily represented:
sequence, selection, and repetition.
The three basic control structures
1.Sequence
The sequence control structure is the straightforward execution of one processing
step after another.
statement a
statement b
statement c
The sequence control can be used to represent the first four basic computer
operations listed previously. For example, a typical sequence of statements in an
algorithm might read:
READ customer record
GET payment amount
customer balance = balance - payment
WRITE customer record
These instructions illustrate the sequence control structures as a straightforward
list of steps written one after the other, in a top-to-bottom fashion. Each instruction
will be executed in the order in which it appears.
2. Selection
The selection control structure is the presentation of a condition and the choice
between actions. The choice depends on whether the condition is true or false.
IF its raining
THEN
get umbrella
ELSE
mow lawn
In the case where we want to compare a single item with more than one value to
determine what we want to do we can use a CASE statement.
CASE Option of Grade
A
B
C
D
F
good student
average student
ok student
needs help
take class again
Some computer languages do not allow the use of CASE or similar structures. The
above structure can be represented by a nested group of IF - THEN - ELSE
structures:
IF Grade = A
THEN
ELSE
good student
IF Grade = B
THEN
average
student
ELSE
IF Grade = C
THEN
ELSE
Ok student
IF Grade = D
THEN
needs help
ELSE
take class again
3. Repetition
The repetition control structure can be defined as the presentation of a set of
instructions to be performed repeatedly, as long as a condition is true.
If we do not know how many times we are going to perform an operation, and the
operation may not be performed at all, we use a WHILE structure.
WHILE condition is TRUE
Do something a
Do something b
Do something c
If we do not know how many times we are going to perform an operation and the
operation will be performed at least once, we use a DO-WHILE structure.
Do something a
Do something b
Do something c
WHILE condition is TRUE
If we know exactly how many times we are going to perform an operation we use a
FOR structure.
FOR counter = 1 to 8
Do something a
Do something b
Do something c
NASSI-SCHNEIDERMAN CHARTS
Nassi-Schneiderman charts are used because they are not as bulky to draw as traditional
flow charts. The major uses of N/S charts are: creating the logic design, programming
from the charts, and writing program documentation. 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 structured
code.
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.
PRINT HEADINGS
CALC TOTALS
PRINT DETAIL
NOTICE: NO BRANCHING
2. DECISION:
IF THEN ELSE
EXPRESSION
T
F
IF EXPRESSION
IS TRUE…
ELSE
IF (BOOLEAN EXPRESSION IS TRUE)
THEN DO THIS
ELSE
DO THIS
DO THIS
THEN DO THIS
CASE STATEMENT: USED WHEN THERE ARE MULTIPLE POSSIBLE CONDITIONS
(MORE THAN TWO)
CASE OPTION OF
A
B
DO THIS
DO THIS
C
DO THIS
DEFAULT
DO THIS
3. LOOP
WHILE (CONDITION = = T)
REPEAT WHAT IS IN THIS
BOX WHILE THE
CONDITION IS TRUE.
WHILE LOOP: PRE – TEST .
USE THIS LOOP STRUCTURE
WHEN YOU NEED TO TEST
THE CONDITION BEFORE
ENTERING THE LOOP.
DROP OUT OF LOOP WHEN
THE CONDITION BECOMES
FALSE
FOR COUNTER = 1 TO 8
FOR LOOP: USE THE FOR
LOOP WHEN THE NUMBER OF
REPETITIONS IN THE LOOP IS
KNOWN.
ACCUM
TOTAL
DO WHAT IS IN THIS BOX
WHILE THE CONDITION IS
TRUE.
DO WHILE LOOP: POST TEST.
USE THIS LOOP STRUCTURE
WHEN YOU WANT TO TEST
THE CONDITION AFTER EACH
ITERATION OF THE LOOP.
WHILE (CONDITION = = T)
WHICH OF THE 4 STRUCTURES WOULD YOU USE FOR THE FOLLOWING?
1. Calculate REG PAY = HRS * RATE
2. Test to see if an employee worked OT
3. Repeat calculating pay for all of your employees
4. Call a process to print a P/R report
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 NassiShneiderman (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 in 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, the 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 ban 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 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. Not 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 or 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 of 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 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 of 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 a 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. A 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 aids, 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 win 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, on 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 charts 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.
If, however, external program documentation is required, a graphic representation of code
(something impossible to code into the program) can be significantly better. The success
of HIPO charts has demonstrated this fact for overview and function documentation. For
displaying logic, however, N/S charts are much better than HIPO charts and far better than
flowcharts and prose.
SUMMARY
Nassi-Shneiderman charts have proven useful in nearly all phases of program
development, from early design through walk through, coding, testing, and user training.
An excellent graphic technique, N/S charts provide a simple yet elegant language that is
intentionally compatible with structured programming goals and methods. As Nassi and
Shneiderman have written:
“Programmers who first learn to design programs with these symbols never
develop the bad habits which other flowchart notation systems permit…Since
no more than fifteen or twenty symbols can be drawn on a single sheet of
paper, the programmer must modularize the program into meaningful
sections. The temptation to use off-page connectors, which only lead to
confusion is eliminated. Finally, the ease with which a structured flowchart
can be translated into a structured program is pleasantly surprising.”