Overview:

How data are stored and manipulated is extremely important for programmers to understand. There are many complexities involved that we will NOT need to incorporate into our designs, but to have a basic understanding will help understand and complete what is required of us for this course.

Up to this point, our interaction with the computer has been at the most basic level. What's interesting about that is the computer has absolutely no problem understanding what we're asking of it, but it is extremely difficult for a human to easily understand how to communicate at the machine language level. Thankfully, we don't need to write designs (or even programs for that matter) using machine language. But, having some basic understanding of the processing of the CPU, we now can begin to look at "easier" ways of communicating with the computer (at least from the human perspective).

Programming History:

As you might be aware, it's extremely difficult to understand machine language and how we read and write it. It's also considered communication at the "bit level", using memory addresses and CPU registers. Only the most technical humans can consistently communicate in this manner and on a regular basis. The humans that excel at this level are often called "geeks" or "nerds" because they more easily communicate with the computer than they do with humans. Now, enough stereotyping!

Once computers were invented and this very basic, but complex, language was developed, the industry saw that only rare individuals would be able to make the computer work. Therefore, they began to work with educational institutions and the military to come up with an easier way to communicate with the computer. Over the years, many programming languages were developed to do just that.

These languages were called procedural languages because they focused on what processes we wanted the computer to do for us. Procedural languages, while still a bit difficult for the average human, allow us to move away from the bit level and not to worry about addresses and registers. We can, instead, focus on data, calculations and input/output.

The first programming language introduced was ForTran (FORmula TRANslator). This language made writing mathematical formulas a piece of cake. The science and military industries loved this language. During the same time frame (we're talking 1950s); the business community realized that the computer could help them keep track of customers, inventory and employees. But, ForTran was so cryptic that the business industry felt it would be too difficult to use (besides, how many times a week does Nordstrom's calculate rocket trajectories). So, in conjunction with the military, a second programming language was developed for Business: CoBOL (COmmon Business Oriented Language).

These two languages were the premier programming languages and the standard by which every other language tried to either emulate or improve. As time moved through the '60's and into the '70's, other languages appeared on the scene. At the same time, the companies and organizations currently using ForTran and CoBOL were discovering that their programmers followed no standard organizational pattern for writing code. The programmers would write programs to the best of their ability, but everyone was unique. That made maintenance of programs extremely difficult because everyone was different.

The effort at writing a program is so costly to a company that it's important not to waste time trying to figure out what someone else was up to. The industry asked education to help them by teaching organizational skills to programmers. From that request came a movement to write very orderly, easy to read and maintain programs (of course, this is all relative). Out of that effort, the concept of Structured Programming was developed.

Structured Programming:

A program that is “structured” follows these simple rules:

- Every program will be made up of combinations of three simple structures
- Every program will have a single entry point and a single exit point, including in and out of structures and modules.
- Every program will have a design, following either top-down or bottom-up methodology

The three structures are:

- Simple sequence (the machine language is an example of a simple sequence)
- Selection
- Iteration

PLEASE NOTE: to help you understand what a "structure" is, think of it as an example of how to write organized statements. One of our goals is to be consistent. Structures give us guidelines to help us be consistent. For example, when we need to write a series of statements in sequence (one after the other), if we use the simple sequence structure (the guideline) every time, our sequences of statements will be consistently written, and, therefore, easier to follow and understand.


Simple Sequence:

When we think about a machine language program, we might realize that the computer cannot pass to the next instruction until it fully completes the machine cycle of the first instruction. In other words, the CPU works on one instruction at a time, completes that instruction and THEN moves to the next instruction. Order matters. This is why computers are said to be "algorithmic" machines.

Think about giving someone instructions to your house. Order matters. They can't turn left at the second stop sign until they GET to the second stop sign. Think of the computer in this simplistic manner and you can begin to imagine that you pass one instruction, then the next, then the next, and so on. Hence, a simple sequence. This is how stereo instructions are intended to be read, unfortunately, we don't read them until we have a problem. The computer doesn't have that ability. It must read EVERY instruction and in the order given. And, we must take care to give them in the proper order.

Selection:

Unfortunately, not all programs can be written as simple sequence. There will be times when we need to make a decision. And, based on the outcome (or results) of that decision, do different things. Think of this as a fork in the road. We cannot choose to go down BOTH forks at the same time; we have to decide which way to go, left or right. We'll need this same decision making ability and options in programming as well. You may have heard selection statements called by other names, such as branching statements, decision statements, or IFTHENELSE statements.

Iteration:

The third type of structure is an iterative (or, repetitive) structure. There will be times when we identify a series of statements that we want to do over and over again. What's important is that we must learn to properly control these repeating statements. You may have heard iterative statements called loops.

Top-Down Methodology:

When we focus on a problem, whether it's a logic problem, a computer program, a mathematical problem, or a human problem; sometimes it's a bit overwhelming. So, we begin to divide it into areas that we can look at individually. This is called “top-down” methodology. For example, when studying for a test, can you focus on ALL of the material at one time? No, you must read the book, study the book, and study your notes. While we all need to be multi-tasking, it is really difficult to read all of the chapters in the text at the precise same moment. As we begin to work on the individual tasks, we might realize that the individual task is STILL overwhelming and we might need to divide that task into subtasks. This is called "stepwise refinement" (more on that below).

Bottom-Up Methodology:

Instead of dividing the project into tasks, sometimes we look at it from the detail level. We actually do much of our work from this perspective. Or, at least, we start from here and then go on to look at it from the top-down approach. Bottom-up is the way I make my grocery list. I just write down the items I want as I think of them. Top-down is actually planning menus and thinking of recipe ingredients that you need to shop for.

Let's try another example: when it's time to "spring clean" the house, how do you approach the job (it's overwhelming, isn't it)? We decide, because it makes sense, to use a top-down approach (cleaning one room at a time). But, when we walk into the living room, we realize that there is clutter everywhere. As we look around, we see clutter in ALL of the rooms. So, before we can continue, we must deal with the clutter (the details).

Another example is how I pay my bills. At the beginning of the month, I organize my bills using a bottom-up approach. I open them, put them with their envelopes and begin writing checks. After all of the checks are written, I put the statements away using a top-down approach. I put them in appropriate folder so they can be used for taxes.

Stepwise Refinement:

When it's time to do my taxes, I discover that I need to separate the folder that contains the receipts and statements of expenses into two categories: business expenses and educational expenses. Doing that and creating new folders is called stepwise refinement. The same process can help us in programming. When we identify a task and discover that task is too big, we can divide that task into subtasks. This really is a form of refinement.

Also, the subtasks aren't necessarily INSIDE the bigger task, they are INSTEAD of the bigger task. This is also a form of refinement.

The idea of modularity is a form of refinement in programming. As we begin to think about the logic of what we want the program to do, we might identify modules that we can use more than one time. A module is a series of design statements that can be given a name. Think of it as a recipe. Whenever we want to bake those special cookies, we don't have to reinvent the recipe. We just get the written-down recipe and follow it. We can even give our recipes to others, if we wish. And, they might make changes to the recipe to match their family’s tastes. Programmers can do the same with their modules. As we create modules, we are refining our program design. And, in this case, we're not looking at it from the top or the bottom we're looking at it from the side. That's what "stepwise" means in "stepwise refinement".

Single Entry/Single Exit:

This means that every program, every module and every structure will have a single entry point into it and a single exit point leaving it. If you can enter a program, module, or structure from multiple points, you've made that entity more difficult to understand and, ultimately, more difficult to maintain and modify. You've also "violated" a standard.

Standards are written so that everyone is on an equal footing. Plus, if you violate the structured programming standard, the structured programming police will get you (just kidding). Actually, you've not only made it difficult for the person coming behind you to maintain and/or modify the code, you've made it difficult for YOU to maintain and modify your own code. That ultimately relates to a waste of company time and money.

So, who cares about structured programming? You do. Programming will be difficult enough without making your designs and, ultimately, your code into spaghetti code. Spaghetti code is the name for code that's unorganized. Think of how difficult it is to isolate a single spaghetti noodle in a big pot of spaghetti. Plus, ALL professional programmers expect you to write structured code. Believe it or not, I'm not making this up. Structured Programming IS important and used in the industry.

One final thought on structured programming: once the educational community began to develop teaching methodologies based on “structured programming”, the computer industry began enhancing their programming languages to support this structured approach. That means that a programming language that has an ifthenelse structure can actually use that structure if you write the logic correctly. The same is true with a loop structure. This means the branching and/or repeating properties of these structures are “built into” them in the language itself. We’ll talk more about that when we actually focus on the structures.

Languages, Revisited:

In addition to ForTran and CoBOL, there are BASIC, C, Pascal, etc., that are all considered "procedural". The procedural paradigm is one model for programming languages. There are others.

Functional Paradigm:

The Functional model began to take form as structured programming took hold. This meant that programmers became more organized and began to share code in the form of modules by putting them in libraries that other programmers could use. This allowed programmers to begin to move away from needing to know EVERY detail of a program to a point they could trust and reuse code rather than reinventing the wheel. This is also known as "black box" programming.

Languages such as C are made up almost entirely of libraries of modules. To use these modules, you don’t need to know the exact code that makes them work, you just need to know what you must "set up" properly before you use the module and what that module will give you after it's finished.


Declarative Paradigm:

As applications programs became more sophisticated, users needed to embrace the procedural or functional paradigms to enhance their documents. The thought of having to become a "programmer" to create a simple report using Access or Excel, shook the business world to its knees. Rather than require the world to become programmers, the industry changed the languages of the applications to be "declarative". The macro languages of word processing, spreadsheets and report languages of databases were written to be more declarative. This means rather than focusing on HOW to do something, you simply "declare" what it is you want to do. For example, think about writing an "if" statement in Excel.

Database languages such as SQL (Structured Query Language) and VBA (Visual Basic for Applications) are examples of the declarative paradigm.

Object Oriented Programming Paradigm:

This programming model has, literally, put the programming world on its head. For those of us who've been programmers since ForTran and CoBOL, this OOP-stuff is really magical. OOP focuses on data: what it looks like and how it behaves. OOP is what makes it possible to create Windows applications.

Do any of you remember DOS? That's the original operating system of the IBM/PC desktop (Intel-like chip) computers. It was pretty simple as an OS goes, but it didn't allow us to do too many things at one time. Do you remember that if you wanted to write a document, you had to type in the command to run the word processing program? Then, if you wanted to do something else, you had to shut down the word processing program to be able to run another program? And, what about printing? Do you remember having to go get a soda and take a break if you wanted to print a long document? Your computer, under DOS, couldn't do more than one thing at a time.

Not only that, but you didn't have the ability to put your spreadsheet document inside your word processing document. There was no graphics, and, certainly no OLE (Object Linking and Embedding). To be able to insert an Excel document into a Word document so that if you double-click on it in Word, the Excel program will start, is pure magic.

OOP says let's treat things as objects and not care WHAT created them. Let's just use them when we want to. For example, we've all seen OK/CANCEL buttons when we're using Windows. If we didn't have OOP, we would have to figure out HOW to draw the button, where in the XY axis of the screen bitmap we want to put it, and figure out HOW to make it "hot" (allow the mouse to work with it). With OOP, all of that is already worked out for us, we just need to say what we want the button to look like, we "drag and drop" it to the desired location, and define what is to happen when we click it.

Just having an area on the screen that is sensitive to a mouse is unheard of in procedural programming. As I said before, it's pure magic.