Program Logic Formulation - Ohio State University

Editor's Notes

• #2: Narrator: Lecture 3: Structured engineering problem solving and logic diagrams.
• #3: Instructor: Many design tools require the programmer to sit down and organize their thoughts in a manner which he or she understands the task to be completed. The methods provided have proved to be useful to programmers. Narrator: A variety of tools and techniques exist that can be used in the process of program development and are useful for organizing tasks in problem solving. Many of these tools are focused on the development of algorithms, representation of these algorithms, and refinement or structuring of the developed algorithms.
• #4: Instructor: Not necessarily a single tool, but a combination of these tools may be used to formulate a program. Students will become familiar with all of these tools and eventually use a method of program development they are most comfortable with. Narrator: The techniques and tools we will look at are the top-down design technique, pseudo code, and logic diagrams. The technique most commonly used in program development is the top-down design technique. This technique starts with the overall function or problems and is broken down into smaller steps. Pseudo-code is a tool used to develop an algorithm, usually in an informal written language. Logic diagrams are a graphical way to represent an algorithm.
• #5: Instructor: Top-down refinement is described and example given in the following slides. Narrator: First we will look in-depth at the top-down design technique. As previously stated, first begin with a single statement that conveys the overall function of the program. This is a complete, yet simple representation of the entire program. Then divide this top statement into a series of smaller tasks and list them in the order in which they must be performed. This is the first step-wise refinement.
• #6: Narrator: Now take each of the smaller tasks and refine these into smaller steps as necessary. Also as it becomes apparent, define specific variables necessary to complete the steps in each task. Continue with this refinement until all tasks are broken into small tasks that can simply be programmed as computer code. Then the algorithm is fully developed. When combining this technique with pseudo-code, writing of the actual program is normally straightforward.
• #7: Instructor: The following slides illustrate a top-down example where a general solution is broken down into its various tasks and variables. Narrator: Now let’s look at an example we can practice the top-down technique with. Let’s say the students in a class have taken their first quiz. The grades, which can be in the range of 0 to 100 are available. The program’s task is to determine the class average on the quiz. The givens in the problem are the grades input from the user, and the possible range of the legitimate grades.
• #8: Instructor: This is one example a flag can be used. If a grade outside the range was to not be used to indicate the end of entering grades it should still be checked if it is within a valid range of responses to create fault-tolerant code. Handing this error could be responding with an error to the screen, asking the user to re-input the data, or rounding the data to a valid result. Narrator: Things that could be useful but aren’t known are the number of students in the class, and thus how many grades must be averaged. We can then assume that when a grade is not in the range of expected grades, 0 to 100, that this is an indication that all of the legitimate grades have been entered and the user wishes for the program to display the result. In programming this is called a sentinel or flag.
• #9: Narrator: In pseudo-code, we can begin be developing an overall statement for the entire program, which will be the top of our top-down refinement. This top is to determine the class average for the quiz.
• #10: Narrator: Now we can perform the first refinement. This refinement include three smaller steps. The first step is to initialize variables to their desired starting values. Then we input, sum, and count the quiz grades. Finally with the information input and calculated from the second step we can calculate and display the class average.
• #11: Narrator: Each of these tasks can now be refined into their respective sub-tasks. We need to initialize two variables in this program, the running total of all grades, and the number of grades, or grade counter. In this case we want to initialize both variables to zero.
• #12: Narrator: Refining the second step one might write pseudo code such as the code shown. We want the user to input a grade, and while the value input is not a sentinel or flag add the grade to the running total of all previous grades. Also we must increment the grade counter by 1, then ask the user to input another value. This section would continue in a loop until the user inputs a flag, or an integer not between 0 and 100.
• #13: Narrator: Finally the last step covers what must be done after the users enters the flag and the answer must be calculated and displayed to the screen. Various cases may occur in this final step as shown with the if-else structure. If the grade counter is not zero, or the user has actually entered valid grades, then the class average would simply be the running total of the grades divided by the number of grades entered. This can then be printed to the screen. If the user didn’t enter any valid grades, thus entering a flag the first time prompted to enter a grade, the program could instead print and error that no grades were entered, and then exit.
• #14: Instructor: It is important that students understand when programs are written they must be able to handle all special cases or “exceptions.” Exceptions are found typically in logical evaluations, mathematical expressions, or anywhere input is given by the user. The consequences of not handling all special cases in some manner results in poor performance (demonstrated by Windows’ BSOD for example). Narrator: Notice the if-else structure on the previous slide handled a special case or exception, that in which the user entered no valid grades. Exceptions are found typically in logical evaluations, mathematical expressions, or anywhere input is given by the user. The consequences of not handling all special cases in some manner results in poor performance (demonstrated by Windows’ BSOD for example).
• #15: Instructor: Special cases not caught by the programmer will eventually be caught by the end-user. Thus thorough testing is necessary to ensure all possible exceptions are handled. One more recently popular method is to release public “beta” copies of software where the public itself tests the programmer’s software and is allowed to provide feedback and problems encountered. This of course can’t be done with all software developed (embedded military, nuclear reactor control, satellite applications for example). Narrator: This is one situation that, unless you are the pilot of a plane, may never expect. Thus it is important to take the mind of the user into account when creating a program or product. Special cases not caught by the programmer will eventually be caught by the end-user. Thus thorough testing is necessary to ensure all possible exceptions are handled. One more recently popular method is to release public “beta” copies of software where the public itself tests the programmer’s software and is allowed to provide feedback and problems encountered. This of course can’t be done with all software developed (such as embedded military, nuclear reactor control, or satellite applications for example).
• #16: Instructor: The following slides describe flow charts and action diagrams, their similarities, differences, and applications. Narrator: Methods of organizing pseudo-code include logic diagrams. Some types of logic diagrams include flow charts and action diagrams. Flow charts are a graphical representation of an algorithm and are well suited for programmers which can visualize the flow of their programs well. It can be used as an aid to writing the actual program, and there are no formal standards, but some common guidelines exist, which will be discussed in the remainder of this lecture. Action diagrams are a more textual-based technique of diagramming the control structures of a program. The result is an outline which will closely resemble the computer application. It typically explains what things happen, when, where, and how many times. The previous pseudo-code example could be used as a basis for an action diagram.
• #17: Instructor: Emphasize that the flow chart should be developed before the program is written. Narrator: Flow charts can be a useful tool in program development. They do not typically show a complete description of the program, and are typically used in conjunction with other tools. Flow charts should be made before writing the program, but can also be developed by programmers trying to understand another programmer’s code after it has been written. The final program may differ from the flowchart as only executable statements are shown in the flowchart. Specific equations and tests are also not included. When using flow charts typically every main and sub-program is charted.
• #18: Instructor: Students will find in their course packets the standard flow chart diagramming symbols and should follow these guidelines when developing a flow chart. The following slides should be covered to ensure all students understand each symbol’s use. Encourage students to ask questions about these slides. Narrator: The following slides show commonly used flowcharting symbols. Please refer to your H192 class notes for these symbols and their descriptions as necessary. We will look over most of these symbols now. Be sure to ask questions about those symbols in which you are unsure of their use since you will be expected to develop a flow chart as part of today’s assignment.
• #19: Narrator: The beginning and end of a program are normally shown within a rectangle with rounded corners. You may use any common text such as “start”, “begin”, or in the case of a subprogram, “enter” for example. The arrow designates the flow of the program. Normally the arrow will point to the next sequential program block in the flow chart.
• #20: Instructor: The input from keyboard does not necessarily need an output to screen preceding it at all times. This is the typical way a user enters information to a program though (computer asks for input, user supplies input). When writing to the screen the shape shown here is used. Notice the text doesn’t necessarily need to be the actual text displayed to the screen, only a summary you are familiar with so that when you go back and develop your actual program you know what you wish to place here later. When reading from the keyboard the input symbol is shown below the output symbol. In this case each input from the keyboard is preceded by output to the screen prompting the user to input information. This doesn’t necessarily occur every time, but it common when inputting information from the keyboard.
• #21: Instructor: The difference in order will change the program’s operation. When a read from a file occurs at some point the program should check that it is not at the end of the file (no more data to input from the file). Typically the read then check method is used more often. This will be described in more detail later when file operations are covered. Narrator: Notice the different symbol when reading and writing to a file as opposed to reading from the keyboard and writing to the screen. Also notice for a read or write the common symbol used is the same as opposed to the previous symbols. When reading from a file you may wish to check if you’ve reached the end of the file. The execution block can be used in conjunction with a selection block in either order shown depending on if you wish to check for the end of file before or after the current read. Notice in the first example if the EOF is true, the program would execute whatever block occurs on the “Y” arrow. If the answer is false, the program will follow the “N” arrow and complete a read from the file.
• #22: Narrator: The EOF examples on the previous slide use the selection structure. A question is posed inside the block, and depending on if the result is true or false, or yes or no, the program may follow a different arrow and execute different code. General commands may be placed in a rectangle. This commands could be completing some mathematical equation for example.
• #23: Instructor: A definite loop (for loop) completes a task a certain number of times. Init = initial condition of variable checked, inc = amount variable is incremented, LIM is the upper limit of the variable to continue in the loop in this case. An indefinite loop occurs as long as expression in the box evaluates true. Narrator: Loops can also be represented in a more complex structure which included an embedded selection block. The definite loop completes a task a certain number of times. It begins execution from the top arrow in which a variable is typically initialized to its starting value. Then while this value is less than or equal to a limit the code is executed on the “Y” branch and returns through the left arrow in which the variable is then incremented. This continues until the variable is greater than the limit, and then the “N” branch is followed. The indefinite loop completes a task for an unlimited number of times. Depending on if the logical expression in the box is true or false the loop may continue on the “Y” branch or exit via the “N” branch. This is very similar to the selection block shown on the previous slide.
• #24: Instructor: In order to keep flow charts as readable as possible one should use the connectors as a last resort. When flow charts get large it may be necessary to use connectors to connect lines from various locations on the page, or to locations on other pages. These should be used as a last resort in order to keep flow charts as readable as possible.
• #25: Narrator: Finally, to invoke a subprogram the symbol is shown. The subname will be the name of the subprogram which may be on the same page or more likely on a separate page.
• #26: Instructor: With the assumptions given on the next slide encourage students to develop either a flowchart or action diagram using the to-down approach. Narrator: In today’s assignment you are given the problem of sorting apples in a large box into separate baskets. The apples can be classified as “large red,” “small red,” or “green.” You are to develop logic diagram for the code used to complete this task.
• #27: Narrator: Some helpful assumptions you may use include the availability of three empty baskets, there are counters of some sort present, the person sorting is not color blind and can tell the difference between large and small apples already, and only three kinds of apples are in the large box that requires sorting.