Steps to programming define the problem
Download 74.99 Kb.
|
 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.
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:
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:
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
Clean up 3000
Meat of Program 2000
3200 3100 1300 2100 2200 1100 1200 RULES FOR HIERARCHY CHART DESIGN
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.
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.
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:
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.
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.
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 ELSE take class again needs help IF Grade = D THEN ELSE Ok student IF Grade = C THEN ELSE average student 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. WHILE condition is TRUE Do something a Do something b Do something c 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.
WHILE LOOP FOR LOOP DO WHILE LOOP
THIS SYMBOL IS USED TO REPRESENT A FUNCTION CALL
EXECUTE STATEMENTS IN SEQUENTIAL ORDER. NOTICE: NO BRANCHING
IF THEN ELSE IF (BOOLEAN EXPRESSION IS TRUE) THEN DO THIS ELSE DO THIS
EXPRESSION T F
ELSE DO THIS
IF EXPRESSION IS TRUE… THEN DO THIS CASE STATEMENT: USED WHEN THERE ARE MULTIPLE POSSIBLE CONDITIONS (MORE THAN TWO) CASE OPTION OF A B C DEFAULT DO THIS DO THIS DO THIS DO THIS
WHILE LOOP: PRE – TEST . USE THIS LOOP STRUCTURE WHEN YOU NEED TO TEST THE CONDITION BEFORE ENTERING THE LOOP. WHILE (CONDITION = = T) REPEAT WHAT IS IN THIS BOX WHILE THE CONDITION IS TRUE. DROP OUT OF LOOP WHEN THE CONDITION BECOMES FALSE FOR LOOP: USE THE FOR LOOP WHEN THE NUMBER OF REPETITIONS IN THE LOOP IS KNOWN. FOR COUNTER = 1 TO 8 ACCUM TOTAL
WHICH OF THE 4 STRUCTURES WOULD YOU USE FOR THE FOLLOWING?
DO WHILE LOOP: POST TEST. USE THIS LOOP STRUCTURE WHEN YOU WANT TO TEST THE CONDITION AFTER EACH ITERATION OF THE LOOP. DO WHAT IS IN THIS BOX WHILE THE CONDITION IS TRUE. WHILE (CONDITION = = T) 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:
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.” Download 74.99 Kb. Share with your friends:
| |||||||||||||||||||||||||||||||