This chapter is now 14 pages in length and you have covered all of the core fundamentals for program flowcharting. These are the basic building blocks which allow us to create phenomenal designs. The next few examples will give you some idea about how to hook them together. Later in this book we will cover some more involved examples. Logic is the path you must take to get from point A to point B. These tools are what you use to both build and see the path.
The way you tell them they are idiots, without actually saying it to their faces, is to have them flowchart the process. At first they will come back and tell you that is not their job. If you are working for a big company, you can ask them to have HR send you the process flow diagram for the manual task. That will pretty much point out they never did a process flow diagram. From there the gopher will ride down the mountain. Nobody will want to draw the process flow diagram. Resist all efforts by them to put the flowchart creation on your back. Eventually their most junior person will be saddled with the task. Some six to eight weeks later, after a bunch of meetings, the request will simply go away. They will realize they have been idiots for a very long time and will begin to look for a politically correct way out of the debacle.
Both flowcharting and computer languages have had to deal with multiple decisions for a very long period of time. Many methods have been created to handle them in as sane a manner as possible. One such method is the switch/select/evaluate/ON construct. I gave you multiple choices on the name because you will get a different name depending on which programming language you end up using. Some languages, like BASIC, give you two implementations. It provides both an ON-GOTO statement and a SELECT-CASE statement. From the flowcharting aspect, it is all pretty much the same.
Once you progress to actual programming, you will be taught multiple languages at the same time. When you go out into the real world you will support applications and systems written in multiple languages. You will get burned during a design session “thinking” you can use this tool for a string or a range, only to find out at coding/compile time that you cannot. Write this day down and what you were told. Tape it to your bedroom mirror. Within two years you will suddenly be reminded of it, trust me.
I really must belabor this point with an example. You take a job at a bank. The bank wants you to write a stand-alone function that will return the current interest rate based upon the loan amount. The interest rates change daily and are stored in a file on the system. They will have the following groupings: Auto, small mortgage, medium mortgage, large mortgage, jumbo mortgage and national debt. The maximum value for each of these loan rates is stored on the record with the loan rate. The variable names are given to you and will be globally accessible to your function.
How do you flowchart something like that? Here is where you have to know the programming language you will be working with. The worst-case scenario is that you have to brute force the function with nested decision symbols. If you are lucky enough to be working with BASIC, your function flowchart will look much like the one above. The decision symbol will contain LOAN_AMT. Instead of “new” you will have “<= Auto.” Instead of “good” you will have “<= small mortgage.” The “default” will not have a test, but simply receive the rate for “national debt.” In each of the boxes you will assign the corresponding rate to the return value. When working with a language that doesn’t allow ranges or dynamic variables for the individual “case” clauses, your flowchart will become more difficult.
1.7 Flowcharting Summary
Here, inside of 16 pages, you have covered the fundamentals of flowcharting. You do not, by any means, understand how to create flowcharts. What you have been shown is a hammer, saw and drill; but you don’t yet know how to build a house.
It used to be said that a flowchart was a tool for program design. When you are learning how to program, this is true to a point. A more accurate statement would be that a flowchart is a visual tool that allows you to learn how to program. Once you learn how to program, you will still use a flowchart when you have a particularly nasty problem to solve. There is no replacement. There are many “visual” programming languages on the market. None of them teach developers how to program. None of them let you design a solution from the ground up. The problem is they all claim to do this. What they create are drag and drop idiots. You are reading this book so you can become somewhat more than an idiot.
Flowcharts come in many varieties. The two most common of these is the system flowchart and the much maligned program flowchart. I have only shown you the majority of the symbols for program flowcharting. Later on you will see some snippets of system flowcharting. A thousand-page program flowchart usually amounts to little more than a single box on a system flowchart because those charts work from a much higher level.
You cannot be a great software developer, nor even a good programmer until you have walked the path of flowcharting. The act of creating flowcharts teaches you the difference between good and bad logic. You can see the difference rather than be told. When the flowchart you are looking at, or Heaven forbid, writing, ends up with dozens of criss-crossed lines and branches that are impossible to follow, you begin to realize this was a bad design. Many will try to say it is just a poorly drawn flowchart and in some cases that will be correct. But the majority of the time it’s a bad design.
There will only be a few questions at the end of this chapter. Don’t worry, I’m not going to ask you to memorize symbols. You learn them by using them and the focus of this book is to provide problems for you and the instructor to solve during class.
These questions are designed to teach you that some of the most important details seem insignificant the first time you are exposed to them. Welcome to your first real lesson in logic.
1.8 Exercises
1. What is the main difference between a bottom checking loop and a top checking loop? The answer has nothing to do with where the check is performed.
2. Under what circumstance must you choose a bottom checking loop over a top checking loop?
3. On most of today’s computers, what is the size of a byte?
4. What is another term for multiple decisions when they are dependant upon each other?
5. When drawing a decision symbol, on which side does the “loop back,” “return” or “branch above” line connect?
6. What is a program flowchart?
7. When would you use a middle checking loop?
8. What is a decollator, and why was it used?
9. Given a specification “If a = 1 do_something, a = 2 do_something_else, a = 3 do_a_different_thing, any other value do nothing,” which structure would you draw?
10. When multiple lines need to enter a single symbol, which symbol should you use to join them?