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

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 ELSE
get umbrella / 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:

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.

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.

If we know exactly how many times we are going to perform an operation we use a FOR structure.

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:
  1. DECISION:
  1. LOOP:

WHILE LOOPFOR LOOPDO WHILE LOOP

  1. SUBPROCESS:
  1. SEQUENCE:
PRINT HEADINGS
CALC TOTALS
PRINT DETAIL
  1. DECISION:

IF THEN ELSE

CASE STATEMENT: USED WHEN THERE ARE MULTIPLE POSSIBLE CONDITIONS

(MORE THAN TWO)

  1. 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 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.