Custom Search
|
|
  |
|
|
PROGRAM CODING It is important to remember program coding is not the first step of programming. Too often we have a tendency to start coding too soon. As we just discussed, a great deal of planning and preparation must be done before sitting down to code the computer instructions to solve a problem. For the example amortization problem (fig. 3-6), we have analyzed the specifications in terms of (1) the output desired; (2) the operations and procedures required to produce the output; and (3) the input data needed. In conjunction with this analysis, we have developed a programming flowchart that outlines the procedures for taking the input data and processing it into usable output. You are now ready to code the instructions that will control the computer during processing. This requires that you know a programming language. All programming languages, FORTRAN, COBOL, BASIC and so on, are composed of instructions that enable the computer to process a particular application, or perform a particular function. Instructions The instruction is the fundamental element in program preparation. Like a sentence, an instruction consists of a subject and a predicate. However, the subject is usually not specifically mentioned; rather it is some implied part of the computer system directed to execute the command that is given. For example, the chief tells a sailor to "dump the trash." The sailor will interpret this instruction correctly even though the subject "you" is omitted. Similarly, if the computer is told to "ADD 1234," the control section may interpret this to mean that the arithmetic-logic section is to add the contents of address 1234 to the contents of the accumulator (a register in which the result of an operation is formed). In addition to an implied subject, every computer instruction has an explicit predicate consisting of at least two parts. The first part is referred to as the command, or operation; it answers the question "what?" It tells the computer what operation it is to perform; i.e., read, print, input. Each machine has a limited number of built-in operations that it is capable of executing. An operation code is used to communicate the programmer's intent to the computer. The second specific part of the predicate, known as the operand, names the object of the operation. In general, the operand answers the question "where?." Operands may indicate the following:
The number of operands and the structure or format of the instructions vary from one computer to another. However, the operation always comes first in the instruction and is followed by the operand(s). The programmer must prepare instructions according to the format required by the language and the computer to be used.
Instruction Set The number of instructions in a computer's instruction set may range from less than 30 to more than 100. These instructions may be classified into categories by the action they perform such as input/output (I/O), data movement, arithmetic, logic, and transfer of control. Input/output instructions are used to communicate between I/O devices and the central processor. Data movement instructions are used for copying data from one storage location to another and for rearranging and changing of data elements in some prescribed manner. Arithmetic instructions permit addition, subtraction, multiplication, and division. They are common in all digital computers. Logic instructions allow comparison between variables, or between variables and constants. Transfer of control instructions are of two types, conditional and unconditional. Conditional transfer of control instructions are used to branch or change the sequence of program control, depending on the outcome of the comparison. If the outcome of a comparison is true, control is transferred to a specific statement number. If it proves false, processing continues sequentially through the program. Unconditional transfer of control instructions are used to change the sequence of program control to a specified program statement regardless of any condition. Coding a Program Regardless of the language used, there are strict rules the programmer must adhere to with regard to punctuation and statement structure when coding any program. Using the programming flowchart introduced earlier, we have now added a program coded in BASIC to show the relationship of the flowchart to the actual coded instructions (fig. 3-7). Don't worry about complete understanding, just look at the instructions with the flowchart to get an idea of what coded instructions look like. Figure 3-7. - Programming flowchart and coded program.
You will have to have specific information about the computer you are to use. It will tell you how the language is implemented on that particular computer, in order to code a program. The computer manufacturers or software designer will provide these specifics in their user's manual. Get a copy of the user's manual and study it before you begin to code. The differences may seem minor to you, but they may prevent your program from running. Once coding is completed, the program must be debugged and tested before implementation. Debugging Errors caused by faulty logic and coding mistakes are referred to as "bugs." Finding and correcting these mistakes and errors that prevent the program from running and producing correct output is called "debugging." Rarely do complex programs run to completion on the first attempt. Often, time spent debugging and testing equals or exceeds the time spent in program coding. This is particularly true if insufficient time was spent on program definition and logic development. Some common mistakes which cause program bugs are mistakes in coding punctuation, incorrect operation codes, transposed characters, keying errors, and failure to provide a sequence of instructions (a program path) needed to process certain conditions. To reduce the number of errors, you will want to carefully check the coding sheets before they are keyed into the computer. This process is known as "desk-checking" and should include an examination for program completeness. Typical input data should be manually traced through the program processing paths to identify possible errors. In effect, you will be attempting to play the role of the computer. After you have desk checked the program for accuracy, the program is ready to be assembled or compiled. Assembly and compiler programs prepare your program (source program) to be executed by the computer, and they have error diagnostic features which detect certain types of mistakes in your program. These mistakes must be corrected. Even when an error-free pass of the program through the assembly or compiler program is accomplished, this does not mean your program is perfected. However, it usually means the program is ready for testing. Testing Once a program reaches the testing stage, generally, it has proved it will run and produce output. The purpose of testing is to determine that all data can be processed correctly and that the output is correct. The testing process involves processing input test data that will produce known results. The test data should include: (1) typical data, which will test the commonly used program paths; (2) unusual but valid data, which will test the program paths used to process exceptions; (3) incorrect, incomplete, or inappropriate data, which will test the program's error routines. If the program does not pass these tests, more testing is required. You will have to examine the errors and review the coding to make the coding corrections needed. When the program passes these tests, it is ready for computer implementation. Before computer implementation takes place, documentation must be completed. Documentation Documentation is a continuous process, beginning with the problem definition. Documentation involves collecting, organizing, storing, and otherwise maintaining a complete record of the programs and other documents associated with the data processing system. The Navy has established documentation standards to ensure completeness and uniformity for computer system information between commands and between civilian and Navy organizations. SECNAVINST 5233.1 establishes minimum documentation requirements. A documentation package should include: A definition of the problem. Why was the program written? What were the objectives? Who requested the program, and who approved it? These are the types of questions that should be answered. A description of the system. The system environment (hardware, software, and organization) in which the program functions should be described (including systems flowcharts). General systems specifications outlining the scope of the problem, the form and type of input data to be used, and the form and type of output required should be clearly defined. A description of the program. Programming flowcharts, program listings, program controls, test data, test results, and storage dumps - these and other documents that describe the program and give a historical record of problems and/or changes should be included. Operator instructions. Items that should be included are computer switch settings, loading and unloading procedures, and starting, running, and termination procedures. Implementation After the documentation is complete, and the test output is correct, the program is ready for use. If a program is to replace a program in an existing system, it is generally wise to have a period of parallel processing; that is, the job application is processed both by the old program and by the new program. The purpose of this period is to verify processing accuracy and completeness. Q.16 What is programming? |
 
|
