Begining Programming - Part II

Section Two, Tools for the Analysis of a Process

Pseudo-Code

NewsLetter TOC

Newsletter Home

Blast

MDI

OS Editor

LBW Review

Fast Data

SQLite

Tsunami

Begin Prog II

Locate/LBCard

What we have written above is called pseudo-code. It is one of the two tools that we are going to introduce you to. Pseudo-code is a very English representation of a process or program is a loose, undefined format that specifically describes the process or program. It is not executable by any compiler or interpreter (like Liberty Basic). It is a tool that lets you examine the solution to a problem in basic English phrases. With it you can express the basic structure of a program (your method to solve a problem) without worrying about the specific syntax of each command - and from it you can create your program.

Lets work with a real problem that we can write real code for. Lets deal five random cards from a deck of 52 (each individually numbered from 1 to 52 to make it easy), and lets not place the same card on the table more than once.

In real life we would begin by shuffling the deck to make it random. We will use a simpler method in our attempt by simply selecting a card from the deck from a random spot (we could do that in real life too - I suppose).

1) Cut the deck randomly

2) Select the top card as our card

3) Place the card face up on the table

4) If this is not the first card then check to make sure this card value is not already showing - if it is then put the card back and go back up to step 1

5) Count the number of card showing

6) Reassemble the deck

7) If there are less than five cards showing then go back up to step 1 and repeat.

8) If there are five cards showing then we are done.

Eight steps. Not bad. But are these simple enough to write a program from? I probably could do it, but if you can't then you need to dig deeper. A complex step that could use a bit more work is step number 4. We seem to be examining how many cards are showing and then examining each card against the last card. I think we need to take a closer look at this:

a) If the total number of cards is greater than one then do the following:

b) For each card on the table, not counting the last one do the following:

c) Look at the card on the table and your new card - if they are the same do the following:

d) Pick up the latest card and place it back into the stack of cards

e) Go to step one (in the earlier list).

Waiter - There are Flaws in my Pseudo-code

What I noticed as I examined the problem a little deeper is that I have introduced a logic error in the first set of processes. I got a step out of order. Have you noticed which one it was yet? In the examination of the cards on the table, in step 4; I presume to know how many cards are on the table. However I do not actually count the cards on the table until step 5. Step 5 needs to be moved ahead of step 4.

Here is what the program looks like so far, combining both the first and second level processes. Note that I moved the step to count the cards on the table ahead of the step to examine the cards:

1) Cut the deck randomly

2) Select the top card as our card

3) Place the card face up on the table

4) Count the number of card showing

5) Examine the cards for duplicates

a) If the total number of cards is greater than one then do the following:

b) For each card on the table, not counting the last one do the following:

c) Look at the card on the table and your new card - if they are the same do the following:

d) Pick up the latest card and place it back into the stack of cards

e) Go to step one.

6) Reassemble the deck

7) If there are less than five cards showing then go back up to step 1 and repeat.

8) If there are five cards showing then we are done.

This seems to work however there is one more slight logic error we have introduced by moving the counting of the cards into the step 4 position. What happens if we have counted 4 cards and we find that the fourth card (the one we just extracted from the deck) was a duplicate? Once we put it back the still have a count of four cards even though there really are only three.

Of course in real life we would simply look at the table and know that there are only three cards, but this is a computer program and there is not real table or cards to see. We must then track how many cards are on the table at any given time. We do this by using a variable as a counter and incrementing and decrementing the counter as needed. When our code adds a card to the table it is like a transaction. We increment the card count in response to the transaction. When we remove a card it is like a transactions again. We must decrease our count or the counter will not accurately reflect the actual situation.

We will have to add a step into our code between steps "d" and "e" where we decrease the count of cards on the table. That step would look something like:

e) Reduce the count of cards on the table by one.

and then step e will have to be moved to step f. The finished pseudo-code program would look something like:

1) Cut the deck randomly

2) Select the top card as our card

3) Place the card face up on the table

4) Count the number of card showing

5) Examine the cards for duplicates

a) If the total number of cards is greater than one then do the following:

b) For each card on the table, not counting the last one do the following:

c) Look at the card on the table and your new card – if they are the same do the following:

d) Pick up the latest card and place it back into the stack of cards

e) Reduce the count of cards on the table by one.

f) Go to step one.

6) Reassemble the deck

7) If there are less than five cards showing then go back up to step 1 and repeat.

8) If there are five cards showing then we are done.

Introducing the Flow Chart

This is to write this simple little program from. It will require a couple new commands in addition to those you learned in the last installment. We will be looking at those a little bit more in depth in just a bit. Before we leave the subject of analysis, lets discuss the other valuable tool for examining and breaking a problem down into manageable pieces. It is the flow chart.

The flow chart - yep I heard it, someone groaned! The bane of programming students the world over. Why would I recommend a flow chart? Because the work. For those who never had to sit through a COBOL or FORTRAN class in college, let me explain.

A flow chart is a method of expressing the flow of a process and describing the steps to be taken during the process execution. It uses lines with arrows to connect one of several shapes to other shapes. Each shape is significant and is used deliberately. These are the more common shapes and their meanings:

There are other shapes that can be used, and the process of flow charting can become very complex if you let it. I recommend you apply the KISS rule. Keep It Simple Sunshine! Flowcharts do not need to be highly complex, or even pretty to communicate their message. They simply need to state how the process works and offer a solution to the problem.

In reality I seldom use flowcharts in my programming. There are times, however, when they help me grasp a problem and visualize its solution like no other tool. What I find in real life is that a hybrid of the pseudo-code and flowchart working together are most helpful. I know there are process analysts out there just dying to get their hands on me for that idea, but it really works. Most times I can express the concept of a program well enough to code the solution using pseudo-code, but then I hit a section that is impossible to express well with pseudo-code – this is where the flowchart shines. Two tools used together. It is twice as nice.

Getting back to working with flow charts - lets take our example from above. Most of the program is a simple top down design. Nothing too complex until we reach step 5. Those processes are made more complex by the looping structure and the evaluations. They would be well represented by a flow chart.

I have created a flow chart that shows each discrete step in the solution to the problem. See if you can follow along – compare the flow chart to the pseudo-code we produced earlier also.

You should be able to align each of the steps in the pseudo-code with a block in the flow chart, all except step 6. The pseudo-code was written using the real world processes. The Flow chart is more closely matched to the way a computer works and "thinks". Because of the way we "draw" our card from the "deck" in the computer, there really is no need or even way to reassemble the deck, so this step was skipped.