the minimum you need to know about logic to work in it
Post on 05-Oct-2015
29 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
About Logic to Work in IT
By Roland Hughes
Logikal Solutions
The Minimum You Need to Know
-
Copyright 2007 by Roland Hughes
All rights reserved
ISBN 0-9770866-2-3
ISBN-13 978-0-9770866-2-7
This book was published by Logikal Solutions for the author. Neither Logikal
Solutions nor the author shall be held responsible for any damage, claim, or expense
incurred by a user of this book as a result of its use or reliance upon.
These trademarks belong to the following companies:
DEC Digital Equipment Corporation Hewlett-Packard Corporation
WordPerfect Correl Corporation
Depends Kimberly-Clark Worldwide, Inc.
PDP Hewlett-Packard Corporation
dBASE dataBased Intelligence, Inc.
Btrieve Pervasive Software
Novell Novell, Inc.
ISAM IBM (International Business Machines Corporation)
RMS Hewlett-Packard Corporation
VSAM IBM (International Business Machines Corporation)
CICS IBM (International Business Machines Corporation)
SyncSort SyncSort Incorporated
MQSeries IBM (International Business Machines Corporation)
MySQL MySQL AB
Unix The Open Group
Linux Linus Torvalds
ACMS Hewlett-Packard Corporation
PostgreSQL PostgreSQL Global Development Group
RDB Oracle Corporation
Oracle Oracle Corporation
All other trademarks inadvertently missing from this list are trademarks of their respective owners. A best
effort was made to appropriately capitalize all trademarks which were known at the time of this writing.
Neither the publisher nor the author can attest to the accuracy of this information. Use of a term in this
book should not be regarded as affecting the validity of any trademark or service mark.
-
Acknowledgments
I really would like to dedicate this book to the students about to embark on a career
in IT. Having spent nearly 20 years in this industry myself, I felt I owed it to the
following generations to put back some knowledge that has been lost in this industry.
It is an obligation of those who become seasoned in this industry to pass that
knowledge onto the following generations. This book is my attempt to pass some of the
most important, yet least taught, knowledge onto you, the reader.
Welcome to IT.
-
Source Code License
Unlike the other books in this series, there will be no source code for you to worry
about. While we will create diagrams and pseudocode, there will be nothing you can
actually compile and run.
-
Table of Contents
Introduction.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1
I.1 Why Logic?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1
I.2 What is Logic?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2
I.3 Prerequisites for This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4
I.4 Approach of This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5
I.5 Who Should Read This Book?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-6
I.6 Why is Flowcharting and Pseudocoding Shunned?. . . . . . . . . . . . . . . . . . . . I-6
I.7 Flowcharting and the Current State of IT. . . . . . . . . . . . . . . . . . . . . . . . . . . I-9
I.8 Additional Reading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-11
Chapter 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Basics of Flowcharting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1 Flowcharting Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.2 Linear Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
1.3 Top Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
1.4 Middle Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
1.5 Bottom Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
1.6 Multiple Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
1.7 Flowcharting Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.8 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Chapter 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Basics of Pseudocode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.1 What is Pseudocode?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.2 Rules of Pseudocode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.3 The Why and When of Pseudocode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.4 How Do You Learn to Write Pseudocode?. . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.5 Linear Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.6 Top Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.7 Middle Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
2.8 Bottom Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.9 Multiple Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.10 Pseudocode Followup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.11 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
-
Chapter 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Some Fundamental Data Types.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.1 Core Data Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.2 Data Type Sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
3.3 Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.4 Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
3.5 Records and Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
3.6 Indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
3.7 Record and Structure Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
3.8 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
3.9 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Chapter 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Searching and Sorting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.2 The Bubble Sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.3 Class Exercise One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
4.4 Linear Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
4.5 Insertion Sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
4.6 Class Exercise Two.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
4.7 Class Exercise Three. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
4.8 Shell Sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
4.9 Binary Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
4.10 Class Exercise Four. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
4.11 Leaping Lynn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
4.12 Class Exercise Five. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
4.13 When All Search Routines Fail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
4.14 The Two Part Compare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
4.15 Comparing Dates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
4.16 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
4.17 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
Chapter 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Decision Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.1 Choosing Your Decision Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.2 Creating an Extract File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
5.3 Class Exercise One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
5.4 Class Exercise Two.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
5.5 Class Exercise Three. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
5.6 Class Exercise Four. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
5.7 Class Exercise Five. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
5.8 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
-
Chapter 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Knowing What Questions to Ask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.1 How are You Going to Use This?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.2 Who is the Audience?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.3 What Business Areas and Systems are Impacted by This?. . . . . . . . . . . . . 6-3
6.4 Is This Legal?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
6.4.1 Example One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
6.4.2 Example Two (Where Did You Get This?). . . . . . . . . . . . . . . . . . . . . . . . . 6-6
6.5 Who Owns This Project?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
6.6 How Will Success Be Measured?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
6.7 Who Will Sign Off on This Project?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
6.8 What are the Deliverables?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
6.9 How Much Time Do I Have?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
6.10 How Reliable Does This Have to Be?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
6.11 What is the Required Availability?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
6.12 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Chapter 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Linked Lists.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.1 Pointers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.2 A Singly Linked List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.3 Doubly Linked Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
7.4 Which do you use?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
7.5 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
7.6 Class Exercise One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
7.7 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Chapter 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Hash.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
8.1 What is a Hash?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
8.2 Collisions.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
8.3 File vs. Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
8.4 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
8.5 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Chapter 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Relational Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
9.1 What is a Relational Database?.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
9.2 Some Important Relational Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
9.3 Data Integrity and Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
9.4 SQL and Flowcharting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
9.5 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.6 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
-
Chapter 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
Surviving the Fire.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
10.1 The Philosophy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
10.2 Beware the Deadly Embrace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
10.3 The Stock Order Problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
10.4 Some Career Advice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
-
Introduction
I.1 Why Logic?
I could start playing the game with you and respond with Why not logic?, but it
is too soon in this book to tick you off; there will be time enough for that later. This
book came about for many reasons. It is not one I originally intended to write as part
of this short series, if ever. Many circumstances coalesced to allow time enough for it,
but there still had to be a need for this book to justify writing it. The need came from
a very odd place (at least for those of you unfamiliar with the ways of IT professionals):
conversations in bars.
Oh, this wasnt conversations with a bunch of grizzled coworkers swilling suds and
having a gripe session. These were conversations with college students when I actually
ran into one who was enrolled in some aspect of IT. My current consulting contract has
me staying near a college town, so when you head out for a beverage or eight, you
inevitably run into college students even in the old fogey bars. What was appalling
wasnt the fact that in a bar with more than 300 people you only ran into, at most, one
IT student, but what they were being taught. Logic isnt required any more at a lot of
campuses. Many others dont even offer it as a class.
In todays pointy-clicky world, logic has been tossed aside. The trouble with tossing
aside logic is that you toss aside what is the fundamental core of application and
system design. Once you understand that logic is no longer being taught, it is easy to
understand the complete lack of design so visible in todays PC and Unix products.
Those students who graduate today and actually accept a job working with a 3GL
writing non-GUI back end applications flounder miserably. Were there any justice in
the world, they would be able to get their money back from the university which gave
them the degree.
When I obtained my first degree some two decades ago, I saw the beginning of the
end for logic in college courses. They started teaching Pascal in the logic class. The
excuse was that students needed to implement the logic tools they were being taught.
The second excuse was that they needed to know Pascal to survive the data structures
class later in the curriculum. Neither argument was worthy of pushing any language
into the logic course. Being in the absolute last group of students to take the logic class
in its pure form, Im in a unique position to criticize the following classes. It also helps
to have gone back a decade later and heard much the same criticism from former
instructors. They claimed that none of the newer students did very well later in the
curriculum. That a lot of students changed their major when they started hitting the
more coding intense classes.
-
I-2 Introduction
The reason those students floundered isnt because IT got harder. Indeed, IT had
gotten easier by then with good 3GL compilers and syntax checkers. It was because
they had burned almost their entire logic class learning a 3GL (Pascal) rather than
learning the depths of logic. They were focusing on the syntax of a language. The
larger portions of logic, those portions that take you above simple program design into
complex application design and simple systems design, were never covered. When they
got to the more advanced programming classes, they had no frame of reference. They
did not know how to design a control break report, or even what a control break report
was. The last part is really sad considering how most college students have a credit
card. Every month they get a statement for their credit card account that is a control
break report.
Why logic? Because you cannot hope to succeed or even survive in software
development without it. Why logic? Because most of you have went through or are
going through a college curriculum that didnt teach you logic. Why logic? Because the
drive to be the absolute best in software development cannot be taught, but logic can,
and you cannot be the best without logic.
In years gone by, hiring a new programmer to your staff was much like buying a
new car. You got to pick and choose the features, but you never had to ask if the car
came with an engine. Programmers from the old curriculums all had been taught logic,
you didnt have to ask. In todays market, you have to ask if the car comes with an
engine.
I.2 What is Logic?
That is the fundamental question. There are many answers. Depending on the
situation surrounding the question, some answers are more correct than others. When
you complete this book and begin working in the real world of IT, you will constantly
use a variant of this question with every program and system you design. What is
logical?
No, Im not trying to lay a bunch of academic babble on you. People dont buy a
book they arent forced to read because they like having academic babble shoved down
their throats. I have found few things more boring than listening to what career
academics have said or reading what they have written. There are several periodicals
that handle that market. There was a time in my career when I believed I could obtain
something useful from them, so I paid expensive fees to read those magazines. What
I obtained from them was a substitute for Nytol most of the time.
-
Introduction I-3
Logic is the fundamental tool of IT. It is the tool from which all other tools are
created. There are many kinds of logic in the world of IT. Scholars would like you to
believe that there is only one definition of logic and it always yields the same outcome.
That statement is incorrect. They will try to proof their statements with truth tables
and lectures that glaze over your eyes inside of 15 minutes. Had there been even the
most remote grain of truth to those proofs AI (Artificial Intelligence) would have been
more than a mid-80s flash in the pan.
For logic to provide the same answer twice, given the same set of truths, you must
start in the same place each time. Logic isnt a set of gears producing the same output
every time you turn a crank handle. A single instance of a logic path will provide that
type of output. In the world of IT, we tend to refer to that single instance as a
program. When a program doesnt provide a consistent set of output, we say it has
bugs. The term bugs became shorthand for implementation failure. Every program
fails at some point. Because we dont like to say we exist to create failure, we say we
exist to create software and some of that software has bugs. It is probably a good thing
we call them bugs so the tool to remove them can be called a debugger, otherwise we
would be talking about running our programs through failure removal instead of
running them through the debugger.
Back in the beginning days of computers, they were a collection of tubes and
programmed by either wiring or tossing a series of switches. There was only one type
of logic: hardware. For most computers it was the hard-wired truth. A switch was
either on or off. Some computers, though few exist today, used frequency logic for
lack of a better term. They were analog, not digital. Most of you reading this should
be familiar with the classic sine wave from your math classes: the perfectly
symmetrical S laid on its side and a line drawn exactly through the middle of it.
Everything above the line was positive, or truth, while everything below the line was
negative, or false. Analog was much like real life. It allowed for varying degrees of
true and false. Some of you using digital cameras may have heard a term called fuzzy
logic. Fuzzy logic tends to get used in a lot of automatic focusing. (Those of you
reading this who are intimately familiar with analog computers and fuzzy logic, please
allow me some literary freedom here. Conceptually, they are similar as a car and truck
are similar. We dont want to go too far down a bunny hole at this point.)
There are still some analog computers around, thought not many. I dont
remember the exact problems they were the best at solving, but there is/was a niche
of software development which could use no other form of computer. I have a nagging
thought in the back of my mind that stellar drift calculations were among the
applications best served by analog boxes. If any of you reading this are old enough to
have owned the older cell phones, then you have a shining example of analog
technology. When you were in a bad spot you could still make out pieces of what the
other person said even with all of the static. With modern digital cell phones you
simply get a dropped call. Analog keeps going as long as there is any degree of truth;
binary stack dumps. Analog knew there was interference and allowed for it; binary
-
I-4 Introduction
requires perfection.
Logic has taken many turns during the past two decades. The study of AI and the
creation of truth tables lead to the creation of rules-based systems back in the mid- to-
late 80s. Truck loads of dollars were poured into companies claiming they would
create thinking machines and personal helpers with all of the intelligence of a hired
servant in just a few short years once the tables were constructed. There was a
market correction when none of these start-ups bore the tasty fruit investors were
looking to savor. Financially, it was not as horrific as the DOT COM flame out, and
it did not have quite as many criminals with their fingers in the venture capital grab
bag. It did have one very ugly side effect though logic got a bad wrap. Colleges
pretty much stopped teaching it and IT started a downward spiral.
Logic taken too far gives you problems like the AI investment debacle. What the
industry failed to realize is that logic, like cholesterol, must exist. There is good logic
and bad logic just like there is good and bad cholesterol.
The short answer is that logic is the most fundamental of IT tools. Logic is what
allows you to get from input to output, no matter what. Logic is the framework upon
which every computer application is developed, even the object-oriented applications.
I.3 Prerequisites for This Book
This book only requires that you have some interest in computers and software
development. It will help if you have poked around with some software development
tools or attempted some fundamental programming on your own. By fundamental
Im not talking about some GUI development product where you only clicked and
dragged things together. Im talking about older, lower level, C or BASIC programs
where you printed HELLO to the screen and tried to work out how to print columns
of asterisks from 10 down to one so they looked like a crude bar graph. If that last
problem sounds horribly simple, try doing it without having had a logic class. Try
doing it in under an hour. If you feel like adding insult to injury, try printing numbers
going down the left side, along with as solid a bar as you can print and letters going
across the bottom with a solid bar above them so it looks even more like a bar graph.
Dont worry if all you have is a casual interest in computers or software
development. We wont be writing any programs, only mapping out their logic, so you
do not even need a computer. You might want to surf the Web or visit an office supply
shop and see if you can find a flowcharting template. This is a little green plastic
thing with different shaped holes cut in it. You use it and a pencil to draw a flowchart
on paper.
-
Introduction I-5
I.4 Approach of This Book
Most books on programming logic tend to be less than 100 pages in length. The
reason for that is they focus on either flowcharting or pseudocoding, then stop. They
give you one or two problems that could relate to the real world, then leave you to
figure out things on your own. If Im going to slam those books that hard here, then
you can be assured it will not be my approach.
I will cover the boring and dry components of flowcharting and dabble a little with
pseudocode. From there we will move forward to some of the standard programming
situations. This will let you actually see logic in action. It will also allow some
images to sink into your brains. From there we will move forward into the general
approach of application design.
This may be a book whose later chapters you wish to read two or three times,
especially if you are new to IT. Nothing you do in your career will save you more time
and anguish than allowing the career advice chapter to fully settle in. Trust me on this
one. My first year in college I had to take a class on logic. We had two little paperback
books. One for flowcharting and one for pseudocoding. Needless to say we completed
those in the first month. The entire rest of the semester was class participation. Each
session would start with a new problem usually and the entire class would be spent
with students calling out or suggesting the steps of logic required while the instructor
drew with chalk. Admittedly, he had it rough for the first few days of that, but once
the bit was set in our teeth, all he had to do was draw and try not to inhale too much
chalk dust.
I dont have a classroom setting for you, nor do I wish to create one. Im sure
someone reading this book will do that in the end. What I do have is nearly two
decades of software development experience to draw on when creating problems for
you. There will be no choice but to start you out with some of the fluffy ones, but I plan
to leave you with some really good ones toward the end.
One thing that was always done in the past was to separate analysis and
programming logic classes. Now that Im long in the tooth, so to speak, I dont agree
with that separation. I wont go into all of the high-minded and far-reaching concepts
of application and systems analysis. There are an awful lot of other diagrams and
specification refinement methods. If you learned them all, each project would have you
burning a week up front deciding which method was going to work best for the current
project. I will take you through the common sense approach, naturally extending
program logic to application logic to systems design logic.
-
I-6 Introduction
I.5 Who Should Read This Book?
Anyone who has even the slightest interest in software development or needs to
manage the software development process should read this book. If you are
contemplating a career in software development, then this should be one of the first
books, if not the first book, you read before going too far down that career path.
Understanding the most fundamental concepts of the software development process
is critical to success in either of those career paths.
I.6 Why is Flowcharting and Pseudocoding Shunned?
Ill be honest. I havent drawn a program flowchart in nearly two decades. The
only time I write what could be called pseudocode for a module is when I have either
a really big chunk to chew or Im writing a bid for approval. Notice that I specifically
stated program flowchart and pseudocode for a module. The devil is in the details.
When doing application or systems design work, I either draw or participate in the
drawing of flowcharts for each project. Once you get into VLA (Very Large Application)
or system level designs, you have absolutely no choice. The human mind was not
meant to remain stretched around designs of that magnitude for prolonged periods of
time. Normally, projects of that size take six months to a year before they even get
close to a testing stage. You need really good diagrams to remember what it was you
intended to do six months ago so you can set up useful test conditions.
As you progress in the field if IT, you will begin to understand why companies will
spend in excess of $10,000 for an ink jet or plotter that uses rolled paper three to four
feet wide. One system I helped develop in the past few years had a system flow
diagram done from a very high level so management could understand it. It took two
sheets of that paper six feet in length taped on the long edge to contain the diagram.
When it was scaled down to print on regular letter size paper on a normal ink jet it
took close to a dozen sheets of paper taped edge to edge, and that was using fonts no
larger than six points inside of the symbols. You couldnt read it if it was more than
a foot from your eyes.
Program flowcharting has been shunned because it is a lot of work. A flowchart
is only good before you write your first line of code. Once you start testing, you realize
there are problems with your design and start making changes to the program. The
flowchart never gets updated. Bad documentation is worse than no documentation at
all because it leads people in the wrong direction. In the early 80s many shops still
endeavored to keep their flowcharts current. Once management got involved and
started chanting cut costs, flowcharts were the first thing to go.
-
Introduction I-7
Pseudocode was simpler. You could write it with any text editor or word processor.
In many ways it was much like COBOL. Some shops used to write pseudocode with
such detail that you could almost put a period at the end of each statement and get it
to compile. This level of pseudocode was impossible to maintain and also died after
hearing the cut costs mantra. High-level pseudocode still gets written in quite a few
shops. It usually gets wrapped in a word processing template that calls it a program
specification.
In days of old, a new programmer would be given a program specification from a
systems analyst, or just an analyst. That specification would range in quality from
incredibly detailed specifications you could begin coding from, or just a few lines
scribbled on a napkin with a sweat ring from a beverage on it. Laugh all you want at
that statement. The most complex systems you will ever get involved with start out
as just a few lines on a napkin. They generally take about five years to settle into a
company and become stable. The reason you end up working on them is they look so
simple and innocent being only a few lines on a napkin.
Once a programmer received a specification for a new program, they would sit
down with pencil and paper drawing out a very detailed flowchart. This flowchart
would document close to every line in the initial version of the program. They would
not be allowed to start coding until the analyst reviewed the flowchart completely and
agreed it was correct. When the analyst was too busy to bother with you, they would
reject the flowchart outright with the phrase Needs more detail. This statement was
designed to tick you off for a day or two until the analyst had time for you. It really
didnt have much to do with what you had done. How do I know this? I was once one
of those flowchart drawing programmers who got a flowchart rejected with that exact
phrase. A week later I submitted that exact same flowchart and it was accepted.
During that week I did flowcharts for the other analysts because they had time to chat
with me.
Developers who paid their dues got to be programmer analysts. These were the
cherished job titles. Once you became a programmer analyst you never had to draw
another program flowchart. You got to code straight from the specification. When the
specification was only a few lines on a napkin you got to work with an analyst to flesh
out the specification. Developers werent allowed to reject a specification from an
analyst with the phrase Needs more detail.
The result was that everyone wanted to be a programmer analyst. Everyone
wanted to just throw code at a problem and see what sticks. That was the fun job in
IT. Some geeks prided themselves on how close to the metal they could code. Even if
the shop had chosen BASIC or COBOL, they would find a way to toss in some
Assembler code just to prove how much of a geek they were. The fact that the
Assembler code could never port to a new machine, even in the same family of
computers, never stopped the geek of geeks from throwing it into the application.
-
I-8 Introduction
During your stint as a programmer analyst, you would get to cut your teeth writing
program specifications. Because you werent a systems analyst, your specification
could never be three lines on a napkin. Normally you would be the one receiving three
lines on a napkin and be told to flesh it out. Then your specification would have to be
reviewed by an analyst or systems analyst before it would be assigned to a
programmer.
Life would then take an ugly turn for you. After one to five years as a programmer
analyst you would be promoted to analyst. It was the only way to get further pay
increases. You would also be relieved of writing any more code. Instead, your life
would be application specifications and programmer management. While you would
toggle between writing systems specifications and application specifications, you would
never really do systems design. The task of systems design fell to the systems analyst.
When it came to bidding on contracts or very large applications, they would have to
draw a system flow diagram showing how all of the pieces were to fit together. Filling
in the actual details would fall to those below. The only code you would ever get to
write was the occasional operating system command script.
Most programmers went into IT not only for the money, but because they really
liked the idea of coding up solutions to problems. Once they got to the skill level of
programmer analyst, most would change jobs. Indeed, the average length of stay when
I was at that level was two years. Developers who loved to program simply didnt want
to give it up. The only way to avoid it was to leave the company.
Never let it be said that marketing wont sell you a product that will kill you.
Along came case tools followed by pick and drag code generators. They would market
these products claiming great leaps in productivity. The tools would have an interface
so appealing that even an MBA could generate the sample contact manager program
in under half an hour. That poisoned apple sure tasted sweet to upper management.
They threw tractor trailers full of money at the vendors of those products. Once PCs
with graphical desktops came out, an even bigger slew of visual type tools flooded the
market. Every one of them promised to make programmers more productive. Every
one of them cost the industry more than will ever truly be known.
The argument was made on college campuses that students would never have to
flowchart in real life, so why make them do it now? Grading those flowcharts certainly
took a lot of time. Drawing flowcharts was a lot of work. It was agreed that flowcharts
would be dropped. Because pseudocoding was taught in the same class as
flowcharting, it died a death by association.
Perhaps the saddest part of this story is that nobody with any clout stood up and
answered the question Why make them do it now? Had anyone answered that
question, it wouldnt have been dropped. Specification writing would have been added
to each and every language/tool class added to the curriculum and IT would have
remained a shining star instead of a downwardly spiraling industry.
-
Introduction I-9
Flowcharting is shunned because it is a lot of work. College students want to do
nothing but party when they first get away from home. Nobody wanted to spend their
evenings with a table full of eraser crumbs, which is pretty much what a class
requiring flowcharting made of their evenings.
Flowcharting is shunned because management didnt want to eat the cost of
training a developer who was only going to spend two years at their company. They
expected colleges to do that. When colleges failed, they threw money at tools to
eliminate the need, or so they thought.
Flowcharting is shunned because this is a Visa/MasterCard society. Buy now, rack
up enough debt to declare bankruptcy, and avoid paying altogether.
Pseudocoding at the program level died with flowcharting. It survives in a watered
down form at the much higher level of program specification. Until you see actual
application pseudocode, you wont understand just how watered down it is.
Nobody wants to pay their dues. That first year of flowcharting is horrible. If you
dont drink, you will find yourself starting. The first few months are bad because you
arent any good at logic then. You understand some of it, but dont really know how to
put it all together. By the end of the first year, you were approaching the level of
quality the IT industry needed: The kind of individual who could hear a problem and
begin the design in their head. Not an entire application or system problem, but a
single module or program problem. You would find yourself looking forward to hearing
newer developers ask, How am I supposed to do this? Turning around with a smile
you would say It is accomplished this way and give a detailed verbal explanation.
You looked forward to that day because that was the day all would know you had paid
your dues in full.
Flowcharting is shunned because nobody wants to pay their dues.
I.7 Flowcharting and the Current State of IT
Admittedly, this section probably belongs in one of my Ruminations chapters, but
it fits here. There are few uglier tasks in the world of IT than being asked to draw a
flowchart. While it may take you months to track down a bug in a particularly nasty
piece of code, there is an immense sense of accomplishment that follows fixing it and
pointing the fix out to all of those programmers who shied away from the task. When
you are asked to draw a flowchart for a large program, it can feel like being asked to
lug rocks from one pile to a new pile ten feet away, then lug them back again.
-
I-10 Introduction
Flowcharting is a mental training tool that must be endured. There is no other tool
that will condition your mind to be ready for a life in IT. Flowcharting is not a useful
learning tool unless you have a seasoned developer who will take the time to actually
review your flowchart and critique it. I can give you the fundamental examples. There
was a method to the madness in the job title hierarchy.
Every year for the past two decades, fewer and fewer students have been asked to
endure it. The result has been that fewer and fewer competent developers have
entered the IT job market. We are not talking about the total body count here, just the
percentage of that body count that actually has employable skills. Most of those
developers went straight into coding at shops without any mentor. During the ga-ga
days of massive IT growth, shops that were either low paying or just true Hell holes
to work at had turn over rates that exceeded 100%. Some shops today are Hell holes
which find themselves in the same situation. While the developers who never learned
logic or flowcharting became better at the syntax of the language, they found
themselves failing miserably once they were promoted higher in the company.
Systems analysts have been moved into infrastructure roles and analysts are now
doing everything the systems analysts used to do as far as software design. I am of
course talking about shops that still have analysts. Most have made that a task of the
IT department manager.
The reality is that most of the IT professionals who actually took a logic class that
required flowcharting and pseudocoding are approaching retirement. They are as high
in the IT shops as they can get. The staff under them, while technically competent and
knowledgeable about the business, hasnt focused on logic. They have focused on
enhancements and the occasional new program for the past 10 years. While they know
the existing system very well, they have never really been taught how to design or
build one from scratch.
We, as an industry, are already seeing the fallout from this. Skilled coders are
being forced into management roles where every new functionality request becomes
an enhancement to the existing system rather than a new system design. Systems,
which were originally designed to do only a few things really well, have now evolved
into a monster performing 20 to 30 completely unrelated tasks. Some companies have
already imploded because they were unable to respond to new information requests.
You, as a reader of this book and a student, are in a unique position. It is quite
possible that you will go straight from graduation to junior analyst role, completely
skipping the coding portion of this industry. Companies are playing a game of grab
right now searching for the cheapest indentured servants they can buy for the coding
portion of projects. Most of those projects end in utter failure that must then be
hidden, both publicly and in the books. What is missing from their mix is logic. The
coders they are hiring for $10/day havent been skilled in logic. The highly skilled
programmers they are tossing out didnt have it in school either, but they have had at
-
Introduction I-11
least a decade of experience so they dont make large blunders at the program logic
level. They do, however, stumble at the application and system design level.
In days gone by, what saved the system analyst when they wrote a three line
specification on a napkin was the quality of people under them. Everyone was trained
in logic. Everyone knew what had to be done to make it work. The project succeeded.
What happens now is upper management issues a one line spec on the back of a
napkin. The analyst issues a 12 or fewer page design document that was always good
enough before. The coders who havent got a clue about logic hack something together
and deliver it. Then everybody stands around pointing fingers while eyeing the black
smoking hole in the ground where the project was supposed to land.
I.8 Additional Reading
If you like the style and readability of this book you may like to read two additional
books written by myself. They should be appearing or have appeared in the
marketplace by the time this book is published. You need to read these two books in
order as they build upon each other. The Minimum You Need to Know to Be an
OpenVMS Application Developer ISBN 0-9770866-0-7. The Minimum You Need to
Know About Java on OpenVMS Volume 1" ISBN 0-9770866-1-5. Being the author, my
opinion of them is somewhat skewed.
-
I-12 Introduction
Page left blank intentionally.
-
Chapter 1
Basics of Flowcharting
1.1 Flowcharting Symbols
When you are drawing program or function-level flowcharts, there are only a
handful of symbols you need to concern yourself with. As you move onto application
and system flow diagrams, you encounter additional symbols. It seems each new tool
for laying out system flow diagrams adds a few symbols or changes the meaning of
them. Unless you stick to universal basics, system flow diagrams become very difficult
for anyone who is not a techno geek to follow. The goal of a flowchart is as much to let
the end user or customer see how things will work as the developer and IT types to
envision a solution. Some of the tools on the market lose sight of that. Be careful
when choosing programs to draw flowcharts for you.
Start/End
Terminator
Hello
World!
Screen
Output
Calculation or
Assignment
Report
Hard copy
output
Keyboard
Manual Input
?
Decision
Do_things
Internal
Predefined
Process
do_something
External
Predefined
Process
A
Connector
IO
IO
Operation
B1
Off Page
Connector
Collate
-
1-2 Chapter 1 - Basics of Flowcharting
A good many of these symbols you will never use. There are even more symbols
that I simply didnt provide. In part I didnt provide them because they are not built
into WordPerfect. The other part is quite simply that they dont come up that often at
the program or application level.
The last two symbols probably have some of you laughing and asking if I can still
wear underwear or now need Depends. You have to remember that flowcharting
started when developers had to work close to the bare metal. Many of us
programmed in Assembler. This was as close as you could get to the machine
instructions without hand entering octal values. (Dont worry if your eyes glazed over
on that, you dont need to know it, just understand that it was laborious and difficult.)
Back in those days, a computer had to be set up to run a program. In many cases
we didnt even have full-blown operating systems. There were independent card
reader subsystems, paper tape subsystems and, if your company had oceans of money
to burn, a magnetic drum. When you flowcharted a program, you had to flowchart
the entire execution. Hence, we have the Manual Operation symbol where you would
instruct the computer operators to configure card readers, tape punches, etc. In many
cases you would tell the operator to load a set of cards in front of your set of cards or
your paper tape that would actually load the subsystem of the device(s) you needed
into core. Memory wasnt called RAM back then, it was called core. The reason is
it actually was a magnetic core. It wasnt until much later that RAM came along,
followed by DRAM and a host of other types of RAM.
Sort
Extract
Merge
Connect
Drive
Manual
Operation
Punched
Card
Punched Tape
-
Chapter 1 - Basics of Flowcharting 1-3
Here is an odd little tidbit for you. Any idea what the ticker tape was in a ticker
tape parade? It had two sources. The first source was the brokers and stock
exchanges. A paper tape device would print bid, ask and last sale for stock symbols as
transactions happened. It wasnt printing like you would think of today. Every time
it printed it would make a ticking noise. This lead the industry to call the minimum
price movement for a stock the tick size. Our second source of ticker tape was
abandoned paper tape from computer rooms. Because the financial markets were some
of the first businesses to use computers outside of the military, this made sense. Now,
when people hold a ticker tape parade, they have to buy confetti.
As subsystems became better and better, they began to get standardized. The
standard groupings of these subsystems came to be called operating systems.
Computer memory started to get quite large in the 1970s. Digital Equipment
Corporation (DEC) produced the PDP line of computers which had 64 K-words
addressable and around 2 MEG of memory installable. That is correct, words. Bytes
are 8 bits and words are 2 bytes. Today, most systems measure RAM as some grouping
of bytes, so in todays terms it would be 128K. In todays world, compilers from
Microsoft can barely create a program that prints Hello Word! to the screen using less
than 128K, but back then we ran 30 to 64 users on a machine with that much.
Operating systems began providing utilities that programmers could use when
writing programs and/or applications. The most used of these utilities was the
SORT/MERGE utility. Every real operating system provides this utility. The Sort,
Extract and Merge symbols allowed us to show in our flowcharts that we planned on
using this utility.
The really old-timers would have a set of cards for input. They would indicate a
Manual Operation for the computer operators to load the cards into the stand-alone
Card Sorter and set the switches a certain way. Some time later they would come back
and the cards would be sorted. There would be another manual operation for the
operator to load the cards into one or more card readers and start the program. If you
were lucky enough to get all of your cards into a card sorter, it could perform a merge
for you by the simple virtue of sorting the entire bundle.
Disk drives turned Sort, Extract and Merge into a software-oriented process.
Oddly enough, the Extract feature became the front-end process for Sort. As
operating system sort utilities provided more and more functionality, they came with
various methods for creating either sort specification files or sort specification
parameters. Both sets allowed you to indicate which records you wanted the Sort
utility to actually process. Typically, once you defined the key for the sort (i.e.
account number, last name, etc.), you were allowed to add some sort of selection
qualifier for that key. The sort utility created a temporary file with the records you
selected, then it sorted those. It didnt take long for people to figure out that if the
temporary file name could be specified and Sort could be made to stop after creating
it, then you just didnt need to write extract programs.
-
1-4 Chapter 1 - Basics of Flowcharting
Collate is an odd little symbol. As I recall, it started as a manual operation for
operators to organize bundles of cards to be broken up between multiple card readers
(too many for a single card reader). Then it morphed into being used for organizing
reports that were printed on different printers. The last I remember it being used was
for the massively expensive all-in-one copy-print machines. This was way before your
sub $300 all-in-one copy-fax-print machines came out. We are talking about massive
high speed printers that sometimes had copy functions built in. A collation device was
hung on it that could sort and store anywhere from 12 to 30+ copies. Before we had
really good printer control languages, the computer operator running the batch job had
to ensure the printer was set to collate. He or she also had to sit there and pull out the
reports as each tray got a completed one.
Let me explain the collate function a little bit more. Prior to printing systems that
could bundle their output directly into an envelope stuffer, it was important. If you
had a charge account with someone, you wanted to be the only one who got your
statement. In the days of continuous form printing and hand collating, this wasnt
always the case. The collating device ensured that only your statement was on that
tray, assuming the operator got the tray empty before it had to be re-used by the
printer. The operator would either hand fold and stuff it or hand carry it to the
stuffing machine.
As long as we are talking about odd computer hardware and terms, let me drop a
couple more on you: burster and decollator two of the noisiest machines to ever find
their way into a computer room. It wasnt good to handle all of this paper in a
computer room, but the printers of the days needed the additional cooling found in the
computer room. A burster would separate continuous form printouts into single
sheets. You had to tell it the length of the form and start the form feeding from the
correct way, then it sat there popping apart the perforations between pages. When you
fed a report in, you had to feed it in backwards or facing the other way because the first
sheet would end up at the bottom of the pile facing exactly the way it faced coming in.
More than one newbie computer operator got to spend their afternoon turning a report
around after feeding it in the wrong way.
The decollator was probably my favorite. These machines were an OSHA
(Occupational Safety and Health Administration) disaster waiting to happen. Many
things that got printed by computers back then, and even to some degree today, needed
to be printed in multiple copies. Today, people buy elcheapo ink jet printers and just
print multiple copies, then hope for the best if they end up in court. What big business
did was print on multi-part form, normally somewhere between two- and five -part
forms. This meant that the exact same pre-printed form occurred that many times in
a single perforated section. Early on they came with carbon paper between each sheet
and later simply used self-duplicating pages. Once printed, the operator hand peeled
the tractor-feed edges off the forms, then fed it through a decollator. The decollator
had a stacking channel, or bin, for each part of the form and had these spinning
slotted shaft-type things to wind up the carbon paper. They were the perfect tie
-
Chapter 1 - Basics of Flowcharting 1-5
catcher. I honestly think we avoided a lot of deaths in the IT industry by having the
female operators run the decollator. It was a fair trade. They usually made the male
operators lose their hearing running the burster. Dress codes seemed to always make
the guys wear ties.
The off-page connector is just what you think it is. When you run out of room
on a sheet of paper, you put one of these on the end of your line and put a label in it.
You use the same connector and label on the start of the continuation page.
Our IO Operation symbol is used when reading or writing to files and databases.
You use the hard copy output symbol when writing to a report file and the screen
output symbol when writing to the terminal. When accepting input from the user, you
use the manual input symbol.
The connector is usually a much smaller circle than I have drawn here. I needed
to make it large enough to get the caption under it without a line break. Whenever you
have multiple lines that need to intersect, you are supposed to use a connector.
Instead of having 15 arrow heads going into one box, you mash the 15 arrow heads into
the connector and have one line running from the connector to the box. (Dont worry,
you will understand before this chapter is over and not a lot of people do it.)
Another use of the connector is the labeled connector as I have shown you.
When you are drawing a large flowchart, it is not uncommon to find yourself on the
other side of the diagram needing to return. You can either create the worlds ugliest
multiply bent line crossing over all other lines, or you can use a nice short line going
to a labeled connector. You then use a labeled connector having the same label where
you wish to return.
I used to flowchart on the back of continuous form. It was not uncommon for me
to have single module flowcharts that were seven pages long. When you had a lot of
things to do in a processing loop before you read your next record, there was simply no
other way to get back to your input statement.
External predefined process encompasses operating systems library, home
grown library and system service functions. In todays world it also indicates stored
procedures in a database engine. Ordinarily you just put the name of the procedure
in the box. When drawing by hand I would put the name in the small area at the top
of the symbol. A lot of electronic tools dont give you that option.
Internal predefined process gets kind of tricky to define. Most people give you
the purist definition, then bank heavily on you not flowcharting in the real world.
It is a good bank in this day and age. The purist definition is you use this to indicate
a subroutine that is a separate flowchart, but written as part of this program.
Depending on the language used by your programming shop, this either worked for you
or put you in a world of hurt.
-
1-6 Chapter 1 - Basics of Flowcharting
Look back at the explanation for external predefined process. See that phrase
home grown library? That is where the hurt comes in. Some programming
languages enforce making every subroutine or function you write callable from
anywhere. Some languages force you to decide at creation time whether your
function/subroutine will be accessible from other programs. The hurt comes, not at the
time of creation, but later in life. As you write more programs and others learn about
your function/subroutine, it gets re-used. This means it gets placed in the home
grown library. Your program didnt change, but your flowchart is now out of date if
you are using the purist definition.
The decision symbol has some odd uses. The normal use is single condition if
testing. Usually there is just a Yes and No (or True and False) branch coming out of
it. Fight off the temptation to give it wings. Have one line come out the bottom and
the other come out a side. Using the side points for each condition only looks good in
very short examples. When drawing out larger logic diagrams, it paints you off the
page pretty fast.
I said it has some odd uses. They arent really odd, they just look odd to those
unfamiliar with them. Most computer languages today have what is known as a
switch, select or evaluate statement. The general explanation for these statements is
that you do different things depending on the value of one variable. The variable name
gets placed in the decision symbol, then you draw a line with a lot of drop points off it
and label each drop point with the variable value. It drops into the action to be taken
for that value. Dont worry, I will provide an example later in this text.
Our calculation/assignment box is pretty much what it sounds like. In it you
will find statements like SALES_TAX = NET_SALES * TAX_RATE. Dont worry if you
dont understand those names, as understanding them isnt a big hurdle.
Terminator should be the most straight forward symbol in flowcharting. It has
caused more heated discussions than any symbol I know. You use one of these symbols
to start your flowchart and another to end your flowchart. Shouldnt be a problem,
right? Guess again. The problems surface around what goes inside of the symbols.
Some camps became quite religious about using EXIT when the module is stand-
alone and others just as deeply convicted about END. They argued strongly that EXIT
should only be used for subroutines that do not return a value to their caller. Save
your laughter, it gets better. Functions which return a value had some equally divided
camps. Some believed strongly that it should be RETURN RET_VAL where RET_VAL
was the name of the variable containing your return value. Others believed it should
just be RETURN and the documentation for the function should stipulate the return
value. One camp believed it should be EXIT RET_VAL because whatever language
they were using for programming actually ended a function with that syntax. A small
group of FORTRAN programmers used to champion the idea of the ending symbol
-
Chapter 1 - Basics of Flowcharting 1-7
being left blank. This was because in FORTRAN you assigned the return value to the
function name and the code simply stopped.
Do you really want me to go into the arguments about the content of the starting
symbol? We are just going to use START for stand-alone modules and ENTER for
callable routines. Sometimes I will slip and use START all of the time. I will use
STOP, EXIT, END or RETURN as I see fit on the last terminal. Please forgive me.
As I stated earlier, there are symbols I didnt cover. Some things we will cover
later as I take you further into logic, and others you will need to pick up on your own.
Knowing what the symbols are wont do you much good if you dont know how to use
them.
1.2 Linear Sequence
You will draw many small sections of flowcharts
that use the linear sequence. It is a tool you use to
build other tools. By itself it is of little use.
In this example I chose to show you an
unexpected use of the IO symbol. Before you can
read from a file, the file must be opened for input.
Back in the day, many shops were adamant about
seeing both the open and the close clearly defined in
the flowchart.
All we did with this example is:
Open an input file
Read a unit of IO from it
Display that unit of input
Close the file
End the program
It is very important you understand why I
phrased Read a unit of IO the way I did. Computer
files can contain a wide variety and organization of
data. In this example I didnt include any
information about the file type or organization. Some
shops had a separate document that contained that
information. Others had you put it in the comments.
I have to start you somewhere, so this is where Im
starting you.
-
1-8 Chapter 1 - Basics of Flowcharting
My display input symbol doesnt have any preceding symbols that would convert
binary data to display format. For the purposes of this discussion, you must assume
that the input file has one line of readily displayable ASCII text. (If you dont know
what ASCII is, please take some time and search the Web for the definition and
history.)
As you progress in the field of IT, you will encounter indexed files. These are files
which contain both text and binary data organized in records. They will have one or
more keys on them. A key is one or more fields defined at file creation time to be
an index into the file. An index is used to quickly get to one or more records in the
file. If the index is defined to identify only one record in the file, then it is called a
unique index. This also translates into a unique key. Most index file systems
require, some just recommend, that the first key defined for a file be a unique key. The
first key is also usually called the Primary Key. Ordinarily, when you access a file
via its primary key, you want to get exactly one record. The record that matches the
key value you passed in.
I know Im getting a little deep here this early in the text, but please plod through
it. Ill give you a small example later in this book. The point Im trying to make right
now is to be very careful about how you phrase things with respect to file IO.
-
Chapter 1 - Basics of Flowcharting 1-9
1.3 Top Checking Loop
You are looking at one of the most
implemented logic structures in IT, the top
checking loop. Every 3GL (Third Generation
Language), most Object Oriented and many
4GLs (Fourth Generation Language) provide
this very logic structure. Many provide it in a
single statement like a for or while loop.
Quite simply, you initialize a variable to
some value. At the top of that loop you check
the value against some condition. Normally
this is a known maximum, but it can also be a
known minimum. In our case, X must be less
than or equal to 10 to continue. Ten is our
known maximum.
Inside of the loop there is always some
quantity of logic that gets performed. From the
loop perspective what happens in there is of
little importance. The one and only
requirement is that your loop counting variable
must be adjusted prior to returning to the top
of the loop. Because we are checking against a maximum, we added one to the loop
counter. If you are working your way down to a minimum, you would subtract a value
from the counter variable.
Let me speak about convention here. Forward flow always runs down the page.
Return branches are always drawn on the left. Forward branches either go down or
to the right. Most instructors would not let me have the end terminal stuck out to the
right like that. They would make me place it at the bottom of the page and connect my
arrow to it. Some people are quite picky about the placement of this terminal. Id
rather be picky about how much logic you learn.
Some of you may be wondering how I created these flowchart images because they
are much smaller and somewhat different from the images I presented initially. The
first images came directly from WordPerfect. To save space and speed things up I
purchased a copy of Flow Diagrams Software http://www.anydraw.com. I didnt do
a large quantity of analysis. There are a lot of shareware products out there which
draw flowcharts. This product cost me around US $30.00 and let me save flowcharts
as JPEG files to import into WordPerfect. Your instructors may make you draw things
by hand with a plastic template. No great crime there, I did it for two years. Back
then I think I spent $30.00 and got a good 0.05mm pencil. They had just come out and
werent common enough to be cheap. (I told you, Im old!)
-
1-10 Chapter 1 - Basics of Flowcharting
There is a variation of the this loop that does not use a counter variable, it uses a
flag variable. Many professors and books will call this a boolean variable. From the
logic perspective, it doesnt matter what you call it, and the data type may be
preordained by your choice of implementation languages. To use this variation you
initialize a variable to a known value (TRUE, FALSE, 0, 1, etc.). The test in the
decision symbol checks for an equality or inequality. You typically set the flag to
another value based on some condition which may be triggered from outside resources.
Sometimes it becomes what is really a middle checking loop.
-
Chapter 1 - Basics of Flowcharting 1-11
1.4 Middle Checking Loop
You will notice a symbol you havent seen before in the image on the left. This is
the symbol that once meant tape input. Many drawing programs, including the one
Im using, now use it to indicate sequential data.
Pay attention to the dashed lines running from the tape symbol to the IO symbols.
There are a lot of different rules about this, depending on where you go. Some places
want the dashed line to have no arrow heads. Some only want dashed lines to the open
and close. They mandate you put the actual record name in the other IO symbols. I
dont really like the file symbol to appear at all when working at this level. When
laying out the flow for an actual program, we used to create a data legend page that
contained the disk drive symbol, name of the file, organization of file, keys and method
of access (read, write, update or delete). Each file would be given some hokey little
code like #1, #2, #3, etc. Because the symbols were small, we would use the codes
inside of the symbols. When we were drawing flowcharts for BASIC programs the
-
1-12 Chapter 1 - Basics of Flowcharting
numbers directly corresponded to the channel numbers we would use in the programs.
Take a close look at the above diagram. Where do I ever set EOF to TRUE? The
answer is I dont. The error handling wrapped into the IO operation is going to set that
value for us. You probably do not know enough about software development to fully
understand that statement, so let me explain. Every language Ive ever worked with
(higher in the food chain than Assembler) provides some method of built in IO
exception trapping. Ive encountered people in the past who demanded you show this
in the flowchart. Going to that level really is a bit much. COBOL has an AT END
clause on its read statement. BASIC tosses BASIC ERROR 11. C provides the feof()
function so you dont even declare the EOF variable we used in this diagram. Most
developers are smart enough to understand EOF means End of File. If you have more
than one file use something like EOF_name or EOF_#2.
Take a look at my decision symbol in this diagram. I didnt label the branches.
Most instructors will slap you pretty hard for that. Many instructors want you to put
simply EOF in the decision symbol then label the branches TRUE and FALSE. It will
be up to your instructor to set the ground rules. My focus is getting you to visualize
the logic you need. The finer details about drawing it dont interest me that much. As
long as you can see it in your mind, you will be able to code it when you move onto
programming.
When it comes to the middle checking loop, most academics will hiss, cluck their
tongues and call it bad design. Those people have never worked in the real world for
a living. A middle checking loop is forced on us by language limitations involving IO.
If you want to make a politically correct loop that checks at the top, then you have to
code up two IO calls along with their complete sets of error handling. The first one is
executed only one time before entering the loop, and the last one is executed at the
very bottom of the loop. I have coded it both ways in my professional life. The rules
of the shop you work at will force the decision on you.
Take a look at the above diagram. If we made it a purist bottom checking loop, we
would have to add one more IO symbol after do something. Then we would have to
find a way to get the dashed line from the sequential data symbol over to it, or we
would have to make an additional copy of the sequential data symbol. Either way, a
little bitty loop would start to get messy.
You are now beginning to understand why every programmer must cut their teeth
with flowcharting. While it is technically true that you wont physically draw a
program flowchart in the real world, you will draw little pieces in your mind as you are
writing.
-
Chapter 1 - Basics of Flowcharting 1-13
1.5 Bottom Checking Loop
I didnt perform any file IO in this example to keep it
simple for you. A bottom checking loop cannot really be
used when file IO is involved. A bottom checking loop is
used when you always wish to perform the loop contents
(instructions inside of the loop) at least once. With file IO
you have to handle the possibility the file will be empty,
locked or missing.
Careful readers will note that in my previous example,
I didnt handle the condition of a missing file. Some
instructors will mandate you handle those conditions, others
will allow you to assume critical error checking is handled
by the actual program.
Critical error checking is the trapping and handling of
hard errors that normally wouldnt occur during program
run time. You must handle those errors from inside of your
program unless you consider letting the user see an ugly
stack dump on the screen acceptable.
Some operating systems will give you what is called a
stack dump when you dont handle a critical error or your
program has a logic bomb. Most of you have probably used
an operating system of feeble capabilities like Windows.
Putting it in terms you understand, it would be when you
see that lovely General Protection Fault displayed. When
the Windows developers themselves forget to handle critical
errors you end up with the Blue Screen of Death.
Flowcharting doesnt give us a good method of drawing out critical error handling.
It is one of the many arguments used against the teaching of flowcharting. You must
be taught flowcharting if you are to ever succeed in programming. What you learn
when you learn flowcharting is the logic to accomplish your task. Programmers who
start with drag & drop component tools never learn logic and tend to be of little use.
-
1-14 Chapter 1 - Basics of Flowcharting
1.6 Multiple Decisions
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 first combination you need to be
able to visualize is multiple decisions.
The term multiple decisions really refers
to nested decisions. From a mechanical
standpoint they are pretty easy to draw.
Once you take a look at the example
to the left, you will begin to see my advice
about not giving decision symbols wings
wasnt just some stylistic preference. Had
I given my decision symbols wings, the
drawing would have quickly either gone
off both page edges, or had to be shrunk
down so small you couldnt make
anything out.
Nested decisions cannot be avoided.
The logic of everyday life tends to throw
us into situations that require them.
What you have to try avoiding are
situations like on Thursdays, when it rains, and Fred is at the keyboard, X happens.
Laugh all you want at my little expression. When you get farther along in your IT
career, you will be asked by your employer to implement something just as messed up.
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.
-
Chapter 1 - Basics of Flowcharting 1-15
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.
When drawing one of these
constructs, it is important to either
specifically include a default/else
branch or add a document comment
as to why it wasnt provided. When
you use this structure, you can
replace m any nested decision
statements with one clean structure.
It is a very powerful tool.
Normally, logic is independent of
the programming language used.
Should you choose to use this tool,
you need to understand what
capabilities it has in the underlying
language. Most every language will
let you check a single integer
variable against hard coded
(constant) integer values. Some
languages will let you check string
variables, but others, like C/C++ will
not. Other languages, like BASIC
on the OpenVMS platform, will let
each case be a range and will check
them in the order they are provided,
processing the first true condition.
At this stage of your career, you
are probably thinking that and a
dollar will get him a soda out of the
vending machine. Write it down.
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.
-
1-16 Chapter 1 - Basics of Flowcharting
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
-
Chapter 1 - Basics of Flowcharting 1-17
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 its a bad design.
There will only be a few questions at the end of this chapter. Dont worry, Im 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 todays 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?
-
1-18 Chapter 1 - Basics of Flowcharting
Page left blank intentionally.
-
Chapter 2
Basics of Pseudocode
2.1 What is Pseudocode?
Pseudocode is basically a tersely worded English language description of the
algorithms to be implemented later in a programming language. In days of old, you
were told not to use words specific to a programming language. While that is good
advice, many of the words you need to use were implemented as verbs by a large
number of 3GL programming languages. Words like if, do-while and perform
have been implemented in one fashion or another by many of the languages you will
find yourself eventually programming in. As a consequence of this: Most pseudocode
looks a lot like COBOL code.
You will find pseudocode still in use at many shops, but not as it was originally
intended. It now exists primarily in sections of systems specifications. When an
analyst writes a specification for a new and large system, there will inevitably be
several areas where tricky algorithms or formulas are needed. Were this formula
simply named or written as a paragraph of text, they would be open to interpretation.
To remove that point of failure early on, the analyst will provide the formula or
al
top related