Download the full version of the ebook at ebookfinal.

com

Tools For Structured and Object Oriented Design

7th Edition Marilyn Bohl

https://ebookfinal.com/download/tools-for-structured-and-
object-oriented-design-7th-edition-marilyn-bohl/

OR CLICK BUTTON

DOWNLOAD EBOOK

Download more ebook instantly today at https://ebookfinal.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Object oriented and Classical Software Engineering 7th

Edition Stephen R. Schach

https://ebookfinal.com/download/object-oriented-and-classical-
software-engineering-7th-edition-stephen-r-schach/

ebookfinal.com

Object oriented Design in Java 1st Edition Stephen Gilbert

https://ebookfinal.com/download/object-oriented-design-in-java-1st-
edition-stephen-gilbert/

ebookfinal.com

Practical Object Oriented Design with UML 2nd Edition Mark

Priestley

https://ebookfinal.com/download/practical-object-oriented-design-with-
uml-2nd-edition-mark-priestley/

ebookfinal.com

Head First Object Oriented Analysis and Design 1st Edition

Brett D. Mclaughlin

https://ebookfinal.com/download/head-first-object-oriented-analysis-
and-design-1st-edition-brett-d-mclaughlin/

ebookfinal.com
Object Oriented Construction Handbook Developing
Application Oriented Software with the Tools Materials
Approach 1st Edition Heinz Zã¼Llighoven
https://ebookfinal.com/download/object-oriented-construction-handbook-
developing-application-oriented-software-with-the-tools-materials-
approach-1st-edition-heinz-za%c2%bcllighoven/
ebookfinal.com

Head First Design Patterns Building Extensible and

Maintainable Object Oriented Software 2nd Edition Eric
Freeman
https://ebookfinal.com/download/head-first-design-patterns-building-
extensible-and-maintainable-object-oriented-software-2nd-edition-eric-
freeman/
ebookfinal.com

Object Oriented JavaScript 2nd Edition Stoyan Stefanov

https://ebookfinal.com/download/object-oriented-javascript-2nd-
edition-stoyan-stefanov/

ebookfinal.com

Object oriented JavaScript 3rd Edition Ved Antani

https://ebookfinal.com/download/object-oriented-javascript-3rd-
edition-ved-antani/

ebookfinal.com

Object Oriented Programming and Java Second Edition Danny

Poo

https://ebookfinal.com/download/object-oriented-programming-and-java-
second-edition-danny-poo/

ebookfinal.com
 Tools for Structured
and Object-Oriented Design
This page intentionally left blank
 Tools for Structured
and Object-Oriented Design
An Introduction to Programming Logic
Seventh Edition

Marilyn Bohl

Maria Rynn
Northern Virginia Community College

Upper Saddle River, New Jersey

Library of Congress Cataloging-in-Publication Data
Bohl, Marilyn.
Tools for structured and object-oriented design : an introduction to
programming logic / Marilyn Bohl, Maria Rynn.— 7th ed.
p. cm.
ISBN-13: 978-0-13-119445-8
ISBN-10: 0-13-119445-3
1. Structured programming. I. Rynn, Maria , 1953- II. Title.
QA76.64B63 2008
005.1'13—dc22
2007041906

Vice President and Editorial Director, ECS: Marcia J. Horton

Executive Editor: Tracy Dunkelberger
Assistant Editor: ReeAnne Davies
Editorial Assistant: Melinda Haggerty
Senior Managing Editor: Scott Disanno
Production Editor: Irwin Zucker
Art Director: Greg Dulles
Cover Design: Kiwi Design
Cover Art: Getty Images, Inc.
Full-Service Project Management: John Shannon/Pine Tree Composition, Inc.
Composition: Laserwords Private Limited
Manufacturing Manager, ESM: Alan Fischer
Manufacturing Buyer: Lisa McDowell
Executive Marketing Manager: Margaret Waples
Marketing Assistant: Mack Patterson

© 2008, 2003, 2001, 1998, 1993, 1989 Pearson Education, Inc.

Pearson Prentice Hall
Pearson Education, Inc.
Upper Saddle River, NJ 07458

All rights reserved. No part of this book may be reproduced, in any form or by any means, without permission in writing from
the publisher.

Pearson Prentice Hall™ is a trademark of Pearson Education, Inc.

All other trademarks or product names are the property of their respective owners.
The author and publisher of this book have used their best efforts in preparing this book. These efforts include the develop-
ment, research, and testing of the theories and programs to determine their effectiveness. The author and publisher make no
warranty of any kind, expressed or implied, with regard to these programs or the documentation contained in this book. The
author and publisher shall not be liable in any event for incidental or consequential damages in connection with, or arising out
of, the furnishing, performance, or use of these programs.

Printed in the United States of America

10 9 8 7 6 5 4 3 2 1

ISBN 0-13-119445-3
978-0-13-119445-8

Pearson Education, Ltd., London

Pearson Education Australia PTY. Limited, Sydney
Pearson Education Singapore, Pte., Ltd
Pearson Education North Asia Ltd, Hong Kong
Pearson Education Canada, Ltd., Toronto
Pearson Education de Mexico, S.A. de C.V.
Pearson Education—Japan, Tokyo
Pearson Education Malaysia, Pte. Ltd
Pearson Education, Inc., Upper Saddle River, New Jersey
 To My Family—
Tedd, Vanessa, Teddy, and Donna
From Maria Rynn
This page intentionally left blank
 Contents

Preface xiii

Part One
Structured Programming Concepts 1
1 Introduction to Structured Design 3
Objectives 3
Introduction 3
System Development Life Cycle 4
Analyze the Current System 4
Define the New System Requirements 4
Design the New System 5
Develop the New System 6
Implement the New System 12
Structured Programming 12
Basic Control Structures 13
Key Terms 15
Exercises 15

2 SIMPLE SEQUENCE Control Structure 17

Objectives 17
Introduction 17
Data Hierarchy 19
Sales Application Example 20
Sales Application System Flowchart 20
Sales Application Program Flowchart 21
Design Verification 25
Sample Problem 2.1 Temperature Conversion Problem 26
Sample Problem 2.2 Billing Problem 28
Flowcharting Tools 30
Enrichment Visual Basic 31
Key Terms 34
Exercises 34

3 IFTHENELSE Control Structure 37

Objectives 37
Introduction 37
Billing Example 37
Pseudocode 39
IFTHENELSE Control Structure 39
Time Card Example 40
vii
viii Contents

Sample Problem 3.1 Payroll Problem 42

Sample Problem 3.2 Finding the Smallest Number 43
Sample Problem 3.3 Bank Problem 45
Character-String Constants 47
Sample Problem 3.4 Sales Problem 48
Enrichment Visual Basic 51
Key Terms 55
Exercises 55

4 DOWHILE Control
Structure—Counter-Controlled Loops 59
Objectives 59
Introduction 59
Problem (Adding Six Numbers) 61
Simulation (Adding Six Numbers) 62
The DOWHILE Loop 63
DOWHILE Pseudocode 65
Counter-Controlled Loops 65
Sample Problem 4.1 Payroll with Counter Loop 66
Sample Problem 4.2 Averaging Problem with Counter Loop 68
Header Record Logic 68
Sample Problem 4.3 Payroll with Header Record 71
Sample Problem 4.4 Averaging Problem with Header Record 73
The No-Data Condition 74
Proper Programs 76
Enrichment Visual Basic 77
Key Terms 79
Exercises 79

5 DOWHILE Control Structure—Trailer Record Logic 83

Objectives 83
Introduction 83
Sample Problem 5.1 Defective Parts Problem 84
Heading Lines 86
Detail Lines 86
Total Lines 87
Priming Read and Loop Read 87
Automatic End-of-File Processing 88
Sample Problem 5.2 Defective Parts with Multiple Headings 90
Multiple Headings—Summary 93
Sample Problem 5.3 Credits Problem 95
DOWHILE Loop Control—Summary 97
Enrichment Visual Basic 99
Key Terms 103
Exercises 103
 Contents ix

6 Modularization 107
Objectives 107
Introduction 107
Structure Charts 110
Sample Problem 6.1 Averaging Problem Using Modules 113
Sample Problem 6.2 Defective Parts
with Multiple Headings Using Modules 117
Sample Problem 6.3 Credits Problem Using Modules 121
Enrichment Visual Basic 125
Key Terms 127
Exercises 127

7 CASE Control Structure 129

Objectives 129
Introduction 129
Inventory Control Example 129
Solution 1: Nested IFTHENELSE Control Structure 131
Solution 2: CASE Control Structure 131
Sample Problem 7.1 Op Code Problem 134
Sample Problem 7.2 Sales Problem without Modules 136
Sample Problem 7.3 Sales Problem Using Modules 138
Sample Problem 7.4 Sales Problem with Totals 142
Enrichment Visual Basic 149
Key Terms 155
Exercises 155

8 DOUNTIL Control Structure 161

Objectives 161
Introduction 161
DOUNTIL Counter Loops 163
Sample Problem 8.1 Property—Counter-Controlled 164
Sample Problem 8.2 Property—Header Record Logic 166
Sample Problem 8.3 Property—Trailer Record Logic 169
DOWHILE Versus DOUNTIL 171
Enrichment Visual Basic 174
Key Terms 177
Exercises 177

9 Introduction to Arrays 181

Objectives 181
Introduction 181
List Structures 181
List Examples 183
Sample Problem 9.1 Finding the Smallest Number 185
x Contents

Sample Problem 9.2 Finding the Average 187

Sample Problem 9.3 Counting Words 189
Sample Problem 9.4 Doubling an Array 192
Sample Problem 9.5 Squaring and Cubing an Array 193
Table Structures 194
Table Examples 196
Sample Problem 9.6 Seating Chart Problem 200
Sample Problem 9.7 Finding the Highest Average 203
Sample Problem 9.8 Two-Dimensional Array Computation 207
Multidimensional Structures 210
Enrichment Visual Basic 213
Key Terms 216
Exercises 216

Part Two
Object-Oriented Programming Concepts 221
10 Introduction to Object-Oriented Design 223
Objectives 223
Introduction 223
Objects and Classes 224
Object-Oriented Design 224
GradeBook Class 226
Encapsulation and Data Hiding 226
GradeBook Class Pseudocode 227
Driver Program—GradeBook Example 229
Constrictors 230
Overloading 232
Destructors 234
Sample Problem 10.1 Determining the Perimeter 234
Sample Problem 10.2 Determining the Perimeter and
Area with Parameters and Return Values 235
Key Terms 238
Exercises 238

11 Inheritance 241
Objectives 241
Introduction 241
Generalization/Specialization 242
Inheritance 242
Class Hierarchy 243
Polymorphism 244
Employee Class 245
Faculty Subclass 245
Staff Subclass 247
Driver Program—Employee Example 250
 Contents xi

Sample Problem 11.1 A Structure for Bank Account

Processing 251
Sample Problem 11.2 Implementing the Account Class 253
Sample Problem 11.3 Implementing the Standard
Checking Account Class 256
Abstract Class 258
Unified Modeling Language (UML) 259
Key Terms 261
Exercises 261

12 Other Class and Object Relationships 265

Objectives 265
Introduction 265
Association 266
Sample Problem 12.1 Vases and Flowers 268
Aggregation 269
Managing Assets Example 270
Composition 271
Iterative Design 273
Sample Problem 12.2 Planning a Group Event 274
Inner Classes 276
Benefits of Object-Oriented Design 278
Key Terms 280
Exercises 280

Part Three
Applications 283
13 Array Applications 285
Objectives 285
Introduction 285
Table Lookups 285
Sample Problem 13.1 Table-Lookup Example 286
Binary Searches 292
Sample Problem 13.2 Binary Search Example 293
Sorting Lists 301
Exchanging Values 302
Sample Problem 13.3 Sort Example 303
Key Terms 307
Exercises 307

14 Master File Update Processing 313

Objectives 313
Introduction 313
File Maintenance 314
xii Contents

Sequential Processing 315

Direct Processing 316
Sequential Master File Update Example 317
Key Terms 331
Exercises 331

15 Control-Break Processing 333

Objectives 333
Introduction 333
Sample Problem 15.1 Single-Level Control Break 334
Sample Problem 15.2 Multiple-Level Control Break 342
Key Terms 356
Exercises 356

APPENDIX A Program Flowcharting Symbols 365

Input/Output Symbol 365
Process Symbol 365
Flowline Symbol 366
Annotation Symbol 366
Connector Symbol 366
Terminal Interrupt Symbol 366
Decision Symbol 367
Preparation Symbol 367
Predefined-Process Symbol 367

APPENDIX B Structured-Programming Control Structures 369

SIMPLE SEQUENCE 369
IFTHENELSE 370
DOWHILE 371
CASE 372
DOUNTIL 373

Index 375
Preface
Tools for Structured and Object-Oriented Design: An Introduction to Program-
ming Logic, Seventh Edition, teaches program design in a well-thought-out,
language-independent manner. This text assumes no previous programming
background. It can be used as the main text in a programming logic class or as a
supplement in any beginning programming class.

Approach and Objectives

Our approach is to start with simple concepts and build on these concepts as
new topics are introduced. We use a sequential step-by-step approach that intro-
duces, by way of example, only one new concept at a time. Sample problems
are included throughout the chapters to illustrate the use of program design
tools in practical situations. Enrichment sections are included in many chapters
to illustrate the program design concepts in Visual Basic. Exercises are given at
the end of each chapter to help you apply what you are learning.
Enrichment sections are included in many chapters to illustrate some of the
sample problems in the programming language Visual Basic. It is important to
note that our approach to teaching program design remains language independent.
All program design concepts are covered prior to the enrichment sections in each
chapter. The enrichment sections are optional and are included as a supplement to
further illustrate some of these concepts.
Our objective is to analyze a problem and express its solution in such a way
that the computer can be directed to follow the problem-solving procedure.
With simple language and frequent examples, this book explains how to
understand and how to use many important problem-solving tools. We begin
with system and program flowcharts. Flowcharting guidelines approved and
published by the American National Standards Institute (ANSI) and its inter-
national counterpart, the International Standards Organization (ISO), are
explained and applied to solution planning. Emphasis is placed on maintain-
ing an overall structure in program design. We show how to use pseudocode
as an alternative or supplement to flowcharting in planning the logic of a well-
structured program. We analyze techniques of top-down, modular program
development by describing how to read and how to develop structure charts
that show the hierarchical relationships of modules within a program.
Our coverage of object-oriented design is expanded in this edition. The
concept that a class may have multiple relationships is emphasized more and
earlier in the text. The concepts that aggregation is a form of association and
that composition is a form of aggregation are also given more emphasis. The
concept of iterative design is given more emphasis. In addition, the coverage
of both the evolution and the use of Unified Modeling Language (UML) is
expanded. The UML diagram types applicable to fundamental object-oriented
design—namely, UML class diagrams and UML object diagrams—are used in
problem solving.

Support Materials for Instructors and Students

The seventh edition of this book offers the same pedagogical features as in previ-
ous editions. Each chapter includes objectives and a list of key terms. Additional

xiii
xiv Preface

illustrations and additional exercises are included in this edition. The Instructor’s
Manual contains the objectives and key terms listed in the textbook as well as
suggested teaching strategies. Solutions to all end-of-chapter exercises are in-
cluded in the Instructor’s Manual. At the end of the Instructor’s Manual you can
find a correlation guide that tells you whether the questions at the end of each
chapter are new for the seventh edition, unchanged from the sixth edition, or mod-
ified from the sixth edition. The correlation guide also lists changes to the objec-
tives, key terms and figures that were made to the seventh edition.
The text comes with an accompanying CD with Microsoft Visual Basic 2005 Ex-
press Edition. An accompanying online site, www.prenhall.com/bohl-rynn, pro-
vides the source code for all the Visual Basic examples in the enrichment sections of
the text. The Visual Basic source code is contained in a zip file called Visual Basic
Source Code.zip. Be sure to preserve the file structure when you unzip the file. Once
unzipped, all required files for each chapter are contained in a folder identified by
the chapter number. To run one of the programs, make sure you first install Visual
Basic 2005 Express Edition. Then double-click the solution file for the program you
want to execute. The solution file for each chapter is located in the folder for that
chapter. Solution files have the extension .sln.
This online site also includes resources for instructors including the Instructor’s
Manual, the test bank of 450 true/false and multiple choice questions including
answers, and the PowerPoint slides of all textbook figures.

Text Organization and Content

The text is organized into three parts as follows:
Part 1 - Structured Programming Concepts (Chapters 1–9) introduces
the theory of structured programming and includes a chapter on each
control structure as well as a chapter on array fundamentals. These
chapters should be covered in sequence.
Part 2 - Object-Oriented Programming Concepts (Chapters 10–12)
introduces many fundamental concepts of object-oriented design and
programming. These chapters should be covered in sequence after
Part 1 is completed.
Part 3 - Applications (Chapters 13–15) illustrates more complex appli-
cations, building on material introduced previously. These chapters can
be covered in any sequence after Part 1 is completed.
The specific content of each chapter and appendices follows.
Chapter 1 describes the system development life cycle and how program
design fits with it. Computer-assisted software engineering (CASE) tools are
introduced in this chapter and are referred to throughout the book, where
appropriate, to increase your awareness of current tools and trends in the in-
dustry. The history of structured programming is also introduced in this chap-
ter. Several nontechnical examples illustrate the basic control structures to give
the student a sense of what structured programming entails. The concepts of ob-
ject-oriented design, event-driven programming, and graphical user interfaces
are also introduced in this chapter.
Chapter 2 introduces the SIMPLE SEQUENCE control structure. Chapter 3
introduces the IFTHENELSE control structure and teaches simple, sequential,
 Preface xv

and nested IFs. Chapter 4 introduces the DOWHILE control structure,

focusing on simple counter loops and header record logic. Chapter 5 focuses
on trailer record logic and also includes a discussion of automatic end-of-file
processing and multiple-heading logic. Chapter 6 introduces modularization.
As in the sixth edition, the material on modularization is introduced after both
header record logic and trailer record logic are discussed.
Chapter 7 introduces the CASE control structure. Chapter 8 introduces the
DOUNTIL control structure. Chapter 9 introduces one- and two-dimensional
arrays with many short simple examples.
Chapter 10 introduces concepts of object-oriented design. Unified Modeling
Language (UML), class and object diagrams, and pseudocode examples are used
to illustrate object-oriented design concepts such as classes, objects, data members,
methods, encapsulation, driver programs, and overloading. Chapter 11 introduces
generalization/specialization relationships, inheritance, overriding, polymorphism,
and abstract classes. Chapter 12 introduces additional types of relationships: asso-
ciation, aggregation, and composition. Inner classes are explained. The advantages
of object-oriented design and programming are summarized.
Chapter 13 concentrates on more advanced array applications such as search-
ing (both sequential and binary) and sorting. Chapter 14 illustrates the design
of a sequential master file update program. Chapter 15 covers control-break
processing.
Appendix A contains ANSI-approved symbols for program flowcharting, and
Appendix B summarizes the basic control patterns of structured programming.
Appendices A and B should be referred to whenever the student is in doubt about
which symbols to use in flowcharts.

Acknowledgments This book would not exist today if it were not for the hard work of many people.
We would like to thank: Paula Worthington, Northern Virginia Community Col-
lege; Terry A. Puperi, Belmont Technical College; Alireza Fazelpour, Palm
Beach Community College, Boca Campus; Gene Robeen, Lewis & Clark Com-
munity College, Godfrey; Jay Benson, Anne Arundel Community College;
Krysten Hall, Anne Arundel Community College; and Mary Ellen Vitrano, Palm
Beach Community College.
We hope that all who use this book will find it provides a clear, systematic,
and direct approach to problem-solving. We welcome your comments and
suggestions.

Marilyn Bohl
Maria Rynn
bohl-rynn@prenhall.com
This page intentionally left blank
 Tools for Structured
and Object-Oriented Design
This page intentionally left blank
 Part 1
Structured
Programming
Concepts

Chapter 1: Introduction to Structured Design

Chapter 2: SIMPLE SEQUENCE Control Structure
Chapter 3: IFTHENELSE Control Structure
Chapter 4: DOWHILE Control Structure—Counter-Controlled Loops
Chapter 5: DOWHILE Control Structure—Trailer Record Logic
Chapter 6: Modularization
Chapter 7: CASE Control Structure
Chapter 8: DOUNTIL Control Structure
Chapter 9: Introduction to Arrays

1
This page intentionally left blank
 Introduction to
Structured Design 1
Objectives Upon completion of this chapter you should be able to
■ Name and identify the six steps in the system development life cycle.

■ Define a computer-based information system.

■ State four objectives of computer-assisted software engineering (CASE)

and give examples of CASE tools.

■ Name and identify the five steps in the program development cycle.

■ Distinguish between a program flowchart and a system flowchart.

■ Name and identify some of the tools and methodologies used in the

design of well-structured programs.

■ Define what is meant by a graphical user interface (GUI).

■ Distinguish between procedure-oriented languages and object-oriented

languages.
■ Define what is meant by event-driven programming.

■ Distinguish between syntax errors and logic errors in a program.

■ Distinguish between unit testing and system testing.

■ Name some forms of documentation needed in a computer-based

information system.
■ Name the three basic control structures of structured programming.

Introduction We live today in a business world. Goods and services are bought and sold,
distributed, produced, and created worldwide at incredible rates. Some businesses
are international conglomerates; others are small mom-and-pop shops. The
success of any business depends, for the most part, on how well the business is
run. Every business uses one or more systems to produce its end products or
services. A system is a combination of people, equipment, and procedures that
work together to perform a specific function. A system can be manually operated
or computer-assisted. A computer-based information system is a system in
which some of the procedures are performed by a computer. Since desktop
computers, laptop computers, and a wide range of handheld computing

3
4 Chapter 1

devices are readily available, even small businesses are using computers or
are looking into converting their manual systems to computer-based ones.
Such a conversion is not an easy task, but it can be simplified by following a
series of well-defined steps.

System The system development life cycle (SDLC) (see Figure 1–1) is a series of
Development well-defined steps that should be followed when a system is created or
Life Cycle changed. The SDLC represents the big picture of what happens during system
creation or modification. In this chapter, we outline the steps in the SDLC and
identify the ones on which this book focuses.

Analyze the Current System

Assume the owners of a local bookstore have decided to computerize the
store’s ordering and inventory control procedures. By doing so, they hope to
know the quantities of inventory in stock at any time, what products are selling
the best, when to reorder to avoid being out of stock, and so on. Where might
they begin? All aspects of the current system need to be studied carefully. This
is usually done with the help of an information system professional known as a
system analyst. The analyst studies every aspect of the existing system to get
a clear understanding of what things are done and how. He or she also attempts
to identify any problems associated with the system.
The analyst can go about this task in several ways, but the most effective tech-
nique is to talk to users of the system. The users are people who are directly in-
volved with the system in their day-to-day activities. (In our example, the store
buyers, assistants, sales personnel, and so on are users.) They are the ones who
can most clearly define each system function and any problems associated with
that function.

Define the New System Requirements

Once the existing system is understood, the requirements of the new or
changed system are defined in the second step of the SDLC. The analyst
should specify what needs to be done, not how to do it. These requirements
should state which changes are necessary to eliminate the problems identified
in the initial analysis. For example, concerning the required system outputs,
the analyst might ask: What types of reports are required? What information
should each report contain? How should the reports be formatted? What head-
ings, spacing, and so on should be used? The analyst may need to define screen
formats for display on terminals, desktop computers, laptop computers, and
handheld devices.

Figure 1–1
System Development Life 1. Analyze the current system.
Cycle (SDLC) 2. Define the new system requirements.
3. Design the new system.
4. Develop the new system.
5. Implement the new system.
6. Evaluate the new system.
 Introduction to Structured Design 5

In addition to input and output requirements, all storage and processing

requirements must be defined. For example, what files will be needed?
What data should be contained in those files? After the analyst works out all
the requirements, he or she prepares a report outlining these requirements
for management. Management can then decide whether to proceed. If the
decision is yes, the next step of the SDLC can begin.

Design the New System

In the third step of the SDLC, either the analyst or a coworker known as a
system designer uses the requirements defined in the preceding step as a
basis for designing the new or modified system. He or she determines how the
system will be constructed. Any of several tools may be used to illustrate the
system design.
One such tool is a system flowchart, which is a graphical representation
detailing all of the programs within a system and how they interrelate. For
each program, the system flowchart shows all the major inputs and outputs.
Figure 1–2 illustrates a system flowchart for a payroll system. Each symbol in
the system flowchart has a special meaning. These symbols will be discussed
in more detail in Chapter 2.
In this example, the data on time sheets is entered into a payroll program, to-
gether with data from the payroll master file. (Master files will be discussed in
Chapter 7 and Chapter 14.) The payroll program produces two reports and the
actual paychecks. This example shows what data the program needs to begin
its processing and what output the program actually produces. No detail is
given as to how the program actually works. This will be done when the new
system is developed.
In recent years, much emphasis has been placed on automating the tasks of
system development. The goals underlying such automation are to gain more

Figure 1–2
System Flowchart
PAYROLL TIME
MASTER SHEETS
FILE

PAYROLL
PROGRAM

PAYROLL PAYROLL
PAYCHECKS SUMMARY EXCEPTION
REPORT REPORT
6 Chapter 1

control over the processes of system development (to avoid large budget
overruns; to avoid projects that are months or years late or never completed
at all); to improve software development productivity (especially in busi-
nesses with not enough trained people to do all the necessary development);
to make the developer’s job easier (manual drawing of system flowcharts, for
example, can be very tedious); and to improve program quality (a program
that is used to direct airplanes in flight or to maintain a hospital’s life-support
system must be right). The term computer-assisted software engineering
(CASE) has been coined to refer to the automation of tools, methods, and
procedures for system development. The widespread availability of comput-
ers has accelerated the trend toward the use of CASE. By increasing your
basic analysis and design skills through study of this book, you can enable
yourself to make effective use of the ever-increasing array of CASE tools in
the marketplace.

Develop the New System

In the fourth step of the SDLC, each of the programs called for in the system
design is constructed. For example, the details of the payroll program shown
in the system flowchart in Figure 1–2 will be specified. This development
stage is composed of a series of well-defined steps called the program devel-
opment cycle (PDC) (see Figure 1–3). The steps of the PDC are carried out
by a programmer, software developer, or software engineer. A description
of the types of activities in each step follows.

Review the Program Requirements In the first step of the program devel-
opment cycle, the software developer reviews the requirements defined in the
second step of the SDLC. If anything is unclear at this point, the developer asks
for more information from the system analyst who wrote the original require-
ment, from the system designer, or even from a future user of the program (such
as a store buyer). The developer must not make unfounded assumptions. It is
just as useless to solve the wrong problem correctly as it is to solve the right
problem incorrectly.

Develop the Program Logic In this step, the actual processing steps within
each program in the system are developed. We shall focus on this step through-
out this book. Just as there are tools to use in the design of a system, there are
tools to use in the design of a program. Two common tools discussed in de-
tail in this book are program flowcharts and pseudocode. Like system
flowcharts, program flowcharts contain standard symbols. These symbols
graphically depict the problem-solving logic within a program. Pseudocode
consists of English-language statements that describe the processing steps of

Figure 1–3
Program Development Cycle 1. Review the input, processing, output, and storage
(PDC) requirements.
2. Develop the logic for the program.
3. Write the program using a programming language.
4. Test and debug the program.
5. Complete the program documentation.
 Introduction to Structured Design 7

a program in paragraph form. Figure 1–4 illustrates both a program flowchart

and pseudocode to compute and print an employee’s paycheck.
Another important program design tool is the hierarchy chart, or structure
chart. Structure charts are used in program design to show the relationships
among parts of a program. Each program part is called a module, and the process
of breaking down a program into parts or modules is called modularization.
Figure 1–5 illustrates a structure chart for a payroll program.
In this example, the payroll program is subdivided into three major modules.
Each module is identified by a name and a number. Module B010 (compute
pay) is further subdivided into three modules. Notice that descending levels on
the structure chart represent modules of greater detail or refinement.
There are many ways to divide a program into modules. Some are better
than others. We will explore modularization in more detail in Chapter 6.
Program flowcharts, pseudocode, and structure charts are very useful tools
during program design. They also provide handy references during pro-
gram modification. So do class diagrams expressed in the Unified Modeling

Figure 1–4
Program Flowchart and
START
Pseudocode Start
Read employee data
Compute gross pay
READ
Compute deductions
EMPLOYEE Compute net pay
DATA Write employee paycheck
Stop

COMPUTE
GROSS PAY

COMPUTE
DEDUCTIONS

COMPUTE
NET PAY

WRITE
EMPLOYEE
PAYCHECK

STOP
8 Chapter 1

Figure 1–5
Structure Chart PAYROLL
PROGRAM

A000

READ COMPUTE WRITE

EMPLOYEE PAY CHECK
DATA
B000 B010 B020

COMPUTE COMPUTE COMPUTE

GROSS DEDUCTIONS NET PAY
PAY
C000 C010 C020

Language, or UML (see Figure 1–6). Notice that the names of the modules
at the second and third levels on the structure chart in Figure 1–5 contain
verbs (Read, Compute, Write). The names of the classes represented by the
rectangles in Figure 1–6 do not contain verbs; they are nouns. That is one
clue to a major difference between procedure-oriented design and object-
oriented design. Procedure-oriented design, discussed in Parts 1 and 3 of
this text, emphasizes processes. Object-oriented design, discussed in Part 2,
emphasizes data.
Once the design of a program has been completed, it should be reviewed by a
small group of developers, designers, and analysts. In this way, potential prob-
lems that might have gone unnoticed by the person who designed the program
surface early in the program development cycle. (It is always easier to find some-
one else’s error than to locate your own.) The goal of the review is to ensure that
high-quality software is produced. A good program is reliable, producing what it
is expected to produce. In other words, it works!
Another characteristic of high-quality software is ease of use. As a user,
you want programs to be user friendly. For example, assume you are about to
use a program to compute the average of a series of numbers. You select the
program and cause it to be executed. An empty box appears on the display

Figure 1–6
UML Class Diagram
Customer Order

Header Body

TotalCost LineItem
 Introduction to Structured Design 9

screen (see Figure 1–7). What should you do? It is not clear whether you
should type in all of the numbers or only one number at a time. If you type in
all the numbers, should they be separated by spaces or commas? You cannot
tell from the screen. Now, suppose you select and execute another program to
compute an average. This time a message on the screen tells you exactly what
to do (see Figure 1–8). Which program would you rather use? Which one is
user friendly?
Both Figures 1–7 and 1–8 are examples of what is called a graphical user in-
terface (GUI). Graphical user interfaces make it easier for the user to interact
with the computer. They present information in an easy-to-use point-and-click
fashion. For example, once the user enters a number in the box in Figure 1–8,
the user can click the OK button using some type of pointing device. Common
pointing devices include mice, track balls, and touch pads. If the display
screen is a touch screen the user can simply touch the appropriate portion of
the screen lightly with his or her finger. Thus, a GUI minimizes the amount of
typing required by presenting the user with choices from which desired op-
tions can be selected by point-and-click actions.
What about ease of use from a software developer’s point of view? Although
a developer does not use a program in the same sense that a user does, he or she
must be able to understand the steps in the design if modifications are required.
Consider a program that handles income tax calculations based on current tax
laws. What happens when some of these laws change? The program will have
to be modified to reflect the changes. In all probability, the person modifying
the program will not be the one who wrote it originally, so the program logic
must be clear and easy to follow. This textbook discusses methodologies that
are used to design reliable, well-written programs.

Figure 1–7
Sample Input Screen (Not
User-Friendly)

Figure 1–8
Sample Input Screen (User-
Friendly)
10 Chapter 1

Write the Program After the program logic has been developed, it must be
expressed in a programming-language form. The selection of the language de-
pends on the type of application and on the software development tools avail-
able. In the past, scientific and mathematical applications were written in
FORTRAN. Most business applications were written in COBOL because it is
oriented to business use. Then structured languages such as Pascal and C were
used more frequently because they contain language elements that closely parallel
the structures used in program design. A developer who uses these procedure-
oriented language codes the specific steps in the problem-solving process. Pro-
grams in which the primary focus during development is on the processing steps
in a program are called procedure-driven programs.
In addition to this traditional procedural approach, another approach to pro-
gram development using fourth-generation languages (4GLs) has become
common. Most 4GLs are nonprocedural languages; a developer using a 4GL
defines what needs to be done, not how. For example, many popular software
packages (word processors, electronic spreadsheets, and database managers, to
name a few) contain programming statements that can be used alone or in com-
bination (macros and programs) to accomplish a task more efficiently. Even
personal computer (PC) users will find that a strong base in programming logic
can be a tremendous help when using a particular package to implement
decision-making activities.
With the increased use of applications containing graphical user interfaces,
visual languages such as Visual Basic and Visual C++ have become popular.
These languages support the concept of event-driven programming. An event-
driven program is designed to respond to actions that occur when the program
is executing. The actions can be initiated by the computer or by a user. For ex-
ample, when the user clicks the OK button illustrated in Figure 1–8, a click
event is triggered. The software developer must design the logic associated
with that click event. We will see many examples of event-driven programs in the
Visual Basic examples later in this book.
Finally, widespread use of the Internet and the World Wide Web have been
accompanied by rapid growth in the use of the Java programming language.
Java is often described as similar to C++ but without some of C++’s complex
programming constructs. Java and C++ are object-oriented languages. Java
and C++ developers deal with classes and objects, which are instances of those
classes, as discussed in Part 2. More and more Web users are creating their own
display screen designs, or Web pages. Web pages are becoming increasingly
more sophisticated as users learn to use Web-authoring tools. Small segments
of Java code, called Java applets, are commonly embedded in Web pages to
create exciting and dynamic Internet-based applications.
Thus, an understanding of programming logic is important in computer-
related jobs. Some developers write programs using procedural or event-
driven programming languages; some use object-oriented languages; some
use popular software packages as tools; some use previously written pro-
grams as applications. Many users write programs designed for the Web.
This is not to say that anyone can program. Training in program design and
the use of the tools is necessary. The amount of detailed logic that users
need differs according to what they do. Many of the CASE tools include
basic tutorials and online help systems designed to help users, analysts,
designers, and developers use the applications and tools effectively (see
Figure 1–9).
 Introduction to Structured Design 11

Figure 1–9
Online Help Screen

Test and Debug the Program In this step, the program is checked for errors
(bugs) and tested with sample data to see whether actual results produced by
the program match expected results. Two main categories of errors may exist in a
program: syntax errors and logic errors. Syntax errors occur when the developer
does not follow the rules of the language he or she is using. For example, many
statements in C must end with semicolons. If the developer forgets to enter a
semicolon, he or she makes a syntax error. Such errors are usually easy to find
and eliminate. A logic error occurs when a step in the program logic is incor-
rect. For example, an averaging program will produce the wrong answer if the
sum of the numbers to be averaged is divided by a number other than the total
count of numbers. Such errors are not always easy to detect. The developer
may need to go back and review the logic created in the second step of the pro-
gram development cycle in order to locate the error.
The program also must be tested thoroughly with computer help using sim-
ple data. Every possible condition should be tested, if feasible. For example, if
a payroll program computes an employee’s pay at time and a half for all hours
worked over 40, the program should be tested using data values that are less
than 40 hours, exactly 40 hours, and greater than 40 hours. The program also
should be designed to handle input data that is invalid. For example, an hours
value that is less than 0 in the payroll example should be detected and noted in
an error message or on an input exception report.
The programs, modules, or classes that make up a system should first be
tested individually to make sure that each works correctly. This is called unit
testing. Then the programs, modules, or classes should be tested together as a
system, either entirely or in part. This is called system testing, or integration.
The more thorough the unit testing is, the more likely that the integration will
proceed successfully. All too often, the unit testing is not adequate, or verbal or
written communications among designers and developers do not occur as
needed. In such situations, the integration of the system components becomes
a tedious, time-consuming sequence of dos and redos.
12 Chapter 1

Complete the Program Documentation Documentation is an ongoing

process that occurs throughout the program development cycle. A technical
reference needs to be created for developers who may need to modify one or
more of the programs. User guides need to be created to tell users how to use
and operate the system. Some of the documentation may be in hard copy
(printed) form; other documentation may be provided as online help for conve-
nient reference by users. We cannot overemphasize the importance of good
documentation. It is a tremendous help during program development and a
vital aid during program modification.

Implement the New System

After the program development cycle is completed for each program within the
system, the new system is implemented. Users are trained, and operating pro-
cedures are defined. The system documentation is reviewed, revised as neces-
sary, and prepared in its final form. Any of several implementation strategies
may be employed: The new system may be run concurrently with the existing
(old) system; the new system may completely replace the old system; or the new
system may be phased in gradually. The specifics of each strategy are beyond the
scope of this book, but you should be aware that they exist.

Evaluate the New System In the sixth step of the SDLC, the new system is
evaluated to determine whether it is meeting the required objectives. If some of
the objectives are not being met, parts of the system may have to be modified.
In any case, a system evaluation report should be prepared for management. It
is likely to serve as one input to a subsequent system development life cycle.

Structured As stated earlier, this text will focus on the second step of the program devel-
Programming opment cycle, developing the program logic. There are many ways to solve a
problem, particularly a complex one. There are usually many correct solutions;
however, some are more desirable than others. In this text, we will adhere to the
principles of a methodology called structured programming, a technique that
has proven to be very effective in solving problems as well as in modifying solu-
tions. The principles of structured programming are fundamental to procedure-
oriented programming (Parts 1 and 3 of this book). They are also relevant to
object-oriented programming (Part 2). That is why we need to look at them
now, at the outset of our discussion of program design.
Structured programming is the ability to express a problem solution using
only three basic patterns of logic. These patterns are referred to as control
structures. The patterns are based on the computer’s ability to execute instruc-
tions in a step-by-step, sequential manner; its ability to make decisions; and its
ability to repeat instructions. The theoretical framework for this approach is
usually traced to a paper by C. Bohm and G. Jacopini, initially published in
Italian in 1965, and then republished in English in 1966.1 Their “structure the-
orem,” which appears in that paper, is generally accepted as a proof of the
claim that the three structures are sufficient for programming. In addition, as

1
C. Bohm and G. Jacopini, “Flow Diagrams, Turing Machines and Languages with Only Two Formation
Rules,” Communications of the ACM 9,5 (May 1966): 366–71.
 Introduction to Structured Design 13

early as 1965, Professor E.W. Dijkstra of The Netherlands insisted that programs
using definite structuring were easier to write, read, and verify.2 There is a vast
amount of literature documenting numerous program development projects in
which this does, indeed, appear to be the case. This information is as relevant
today as it was more than 40 years ago.
The following sections will use familiar examples to illustrate the three patterns
of structured programming. They should give you a sense of how each structure
works. The next several chapters will teach you how to use each structure to solve
specific, well-defined problems.

Basic Control Structures

The three patterns referred to in the previous sections are called the SIMPLE
SEQUENCE control structure, the IFTHENELSE control structure, and the
DOWHILE control structure.

SIMPLE SEQUENCE Control Structure The SIMPLE SEQUENCE

control structure represents the computer’s ability to execute instructions in a
step-by-step, sequential manner. A simple example not involving the computer
can be used to illustrate this concept. The sequential steps given in Figure 1–10
represent directions you might give a friend to get to your house. The steps
must be followed in a sequential manner. If not, your friend might never find
your house.

IFTHENELSE Control Structure The IFTHENELSE control struc-

ture represents the computer’s ability to make a decision. Let us modify the
SIMPLE SEQUENCE example to illustrate this concept. Suppose the left turn
at the fork is blocked at certain times. You need to provide alternative direc-
tions to your friend. You also need to include the original directions (because
they are shorter) to use if the left turn at the fork is not blocked. Notice how the
directions in Figure 1–11 incorporate decision-making logic.
Notice that, if the road is blocked, there are eight separate instructions to fol-
low. If the road is not blocked, there are three instructions. Both sequences of
instructions are included because you do not know whether the road will be
blocked when your friend approaches. However, your friend will follow only
one of the sequences. Although this example is nontechnical, we have included
the keywords and indentation that identify an IFTHENELSE control structure.
You will learn more about this control structure in Chapter 3.

Figure 1–10
SIMPLE SEQUENCE: An 1. Proceed down Main Street for two miles.
Example 2. Turn left on Ocean Drive.
3. Proceed on Ocean Drive for three blocks to the fork.
4. At the fork, take Swan Street to the left.
5. Proceed two blocks.
6. House is second on the left (246 Swan Street).

2
Among Dijkstra’s writings on the subject are “GOTO Statement Considered Harmful,” Letter to the Editor,
Communications of the ACM 11,3 (March 1968): 147–48; “The Structure of the Multiprogramming System,”
Communications of the ACM 11,5 (May 1968): 341–46; and “Structured Programming,” in J.N. Buxton and B.
Randell, eds., Software Engineering Techniques (NATO Scientific Affairs Division: Brussels 39, Belgium, April
1970): 84–88.
14 Chapter 1

Figure 1–11
IFTHENELSE: An Example 1. Proceed down Main Street for two miles.
2. Turn left on Ocean Drive.
3. Proceed on Ocean Drive for three blocks to the fork.
4. IF left turn at fork is blocked THEN
Take right turn at fork onto Eagle Street.
Proceed five blocks.
Turn left at Clifton Avenue.
Proceed three blocks.
Turn left at Circle Drive.
Proceed two blocks.
Turn left at Swan Street.
House is fourth on the right (246 Swan Street).
ELSE
At the fork, take Swan Street to the left.
Proceed two blocks.
House is second on the left (246 Swan Street).
ENDIF

DOWHILE Control Structure The DOWHILE control structure repre-

sents the computer’s ability to repeat a series of instructions. A series of repeated
instructions is called a loop. Let us look at a different example to illustrate this
concept. Consider the simple instructions on the back of a shampoo bottle
(listed in Figure 1–12). Although these instructions are simple enough for us to
understand, a computer would get confused. First of all, the second instruction
says to “Rinse,” but “Rinse” what? Also, the third instruction says to “Repeat.”
Clearly, we know to repeat the process from the beginning. However, we need
to specify to the computer which steps it should repeat. Figure 1–13 gives a new
version of these instructions.
These new instructions clarify some unknowns, but the computer would still
have trouble. Can you see why? Every time the computer got to Step 3, it
would begin again at Step 1, just as the instructions say. This is an example of
an infinite loop: There is no way out. Theoretically, the computer would exe-
cute forever. In common practice, this would not actually happen. A special pro-
gram would halt the program execution and issue an error message indicating
that too much time had passed since the program began executing.
Every loop must include a statement that defines how many times to execute
the loop steps or under what condition to continue or to stop the looping
process. In this example, we could indicate that the steps be performed two
times, or that the steps be performed as long as the hair is not clean. Consider
our example one more time (see Figure 1–14). We have included the keywords

Figure 1–12
DOWHILE: Example 1 Wash hair.
Rinse.
Repeat.

Figure 1–13
DOWHILE: Example 2 1. Wash hair.
2. Rinse hair.
3. Repeat from Step 1.

Figure 1–14
DOWHILE: Example 3 DOWHILE hair is not clean
Wash hair.
Rinse hair.
ENDDO
 Introduction to Structured Design 15

and indentation that identify a DOWHILE control structure. The two indented
steps represent what needs to be done, and the first statement (DOWHILE) spec-
ifies the condition necessary to continue processing. We will explore DOWHILE
loops in more detail in Chapters 4 and 5.

Key Terms system user friendly

computer-based information system graphical user interface (GUI)
system development life cycle procedure-oriented language
(SDLC) procedure-driven program
system analyst fourth-generation languages (4GLs)
user nonprocedural language
system designer event-driven program
system flowchart object-oriented language
computer-assisted software online help system
engineering (CASE) bug
program development cycle (PDC) syntax error
programmer (software developer, logic error
software engineer) unit testing
program flowchart system testing (integration)
pseudocode structured programming
hierarchy (structure) chart control structure
module SIMPLE SEQUENCE control
modularization structure
class diagram IFTHENELSE control structure
Unified Modeling Language (UML) DOWHILE control structure
procedure-oriented design loop
object-oriented design infinite loop

Exercises 1. Name the steps in the system development life cycle.

2. Name the steps in the program development cycle.
3. (a) What does the acronym CASE stand for?
(b) List four major objectives of CASE technologies.
4. What is shown on a system flowchart?
5. What is shown on a program flowchart?
6. What are the characteristics of a high-quality program?
7. (a) What does it mean to say that a program is user friendly?
(b) Give an example of a user-friendly program.
(c) Give an example of a program that is not user friendly.
8. What is a graphical user interface?
9. What does it mean to say that a language is procedure oriented?
10. (a) Give an example of a procedure-oriented language.
(b) Give an example of a visual language.
(c) Give an example of an object-oriented language.
16 Chapter 1

11. What is meant by event-driven programming?

12. What is an online help system?
13. (a) What is the difference between a syntax error and a logic error?
(b) Give an example of each type of error.
14. What is the difference between unit testing and system testing?
15. Give some examples of documentation.
16. What was the purpose of Bohm and Jacopini’s structure theorem?
17. Name the three basic control structures of structured programming.
SIMPLE SEQUENCE
Control Structure 2
Objectives Upon completion of this chapter you should be able to
■ Define an algorithm.

■ Name the characteristics of an algorithm.

■ Name the four parts, in order, of a data hierarchy.

■ Identify, and use in program design, the SIMPLE SEQUENCE control

structure.
■ Define the terms information processing and information-processing

system.
■ Identify, and use in program design, the terminal interrupt, general I/O,

and process program flowcharting symbols.

■ Distinguish between a variable and a constant.

■ Identify, and use in program design, variables, constants, and assignment

statements.
■ Distinguish between input and output, and explain why input and output

steps are needed in program design.

■ Perform a procedure execution of a simple algorithm.

Introduction A computer is an extremely powerful, fast machine. In less than a second, it can
perform difficult calculations that otherwise would take days, months, or years
to perform. Yet a computer has no magical power; it is only a tool. It cannot
decide to act. It can do only what it is told to do. We can direct the computer to
do what we want by specifying our needs in a discrete step-by-step manner.
Specifically, we can develop an algorithm, which is a step-by-step procedure to
solve a problem.
A computer cannot act independently; it has no intelligence of its own. For
this reason, any algorithm used to direct a computer must be set up to identify
all aspects of a processing situation and to present, in detail, all steps to be
performed.
The algorithm must meet the following requirements:
■ Use operations from only a given set of basic operations
■ Produce the problem solution, or answer, in a finite number of such
operations

17
18 Chapter 2

The concept of a given set of basic operations is important because the

computer can perform only certain operations; its capabilities are planned very
carefully by computer hardware designers who lay out specifications that direct
subsequent construction of the machine. The concept of a finite number of such
operations is important because each operation performed by a computer takes
a certain amount of time (say, from one-millionth to one-billionth of a second,
depending on the machine architecture). If an unlimited number of steps is re-
quired, it is impossible, even using the fastest computer available, to obtain the
solution in a finite amount of time.
The term algorithm may be new to you, but most of us use numerous al-
gorithms daily. For example, we adopt routine procedures, or algorithms, for
getting up in the morning, fixing meals, going to work, and so on. A typical
wake-up algorithm is shown in Figure 2–1.
Figure 2–1 is an example of a program flowchart. It may also be called a
block diagram or logic diagram. Very simply, a program flowchart is a picture
of an algorithm. Each step in this algorithm is defined in a rectangle, the symbol
used to indicate a specific process. The rectangle represents the process sym-
bol. Every algorithm must have one entry point (START) and one exit point
(STOP). These are indicated by the ellipsis symbols, called terminal interrupt
symbols.

Figure 2–1
Wake-Up Algorithm
START

GET OUT 1
OF BED

EAT 2
BREAKFAST

BRUSH 3
TEETH

TAKE 4
SHOWER

GET 5
DRESSED

STOP
 SIMPLE SEQUENCE Control Structure 19

All symbols on a program flowchart are connected by flowlines, which may

or may not have arrowheads. The arrowheads show the direction of flow. They
can be omitted when the flow is from top to bottom or left to right, but are re-
quired otherwise. Program flowcharts are usually easier to read when arrowheads
are used.
Notice that the flowchart in Figure 2–1 has five steps, all processed one after
another. The flowchart illustrates the first of the three basic control structures
used to develop algorithms. As you may recall from Chapter 1, this structure is
called the SIMPLE SEQUENCE control structure. It is the simplest and
most frequently used of the three basic control structures.
In common practice, the algorithm shown in Figure 2–1 is carried out some-
what informally. The person who executes the algorithm may even be unaware
that he or she is following an algorithm. In other situations, however, algorithms
are more formally defined. For example, business operations within a company
are firmly established—uniform accounting procedures must be followed; inven-
tory must be tightly controlled; manufacturing volumes must be correlated with
both distribution and sales; and so on.
All of these business applications involve some form of paperwork. The
term information processing is really another name for paperwork. It is a
series of planned actions and operations upon data to achieve a desired re-
sult. The methods and devices that achieve the result form an information-
processing system. Regardless of the kind of data processed or the methods
and devices used, all information-processing systems involve at least three
basic elements:
■ The source data, or input, entering the system
■ The orderly, planned processing within the system
■ The end result, or output, from the system

Data Hierarchy Before we look at our first formal algorithm, we will discuss some terms asso-
ciated with the structure of the data processed by algorithms. The four terms,
file, record, field, and character, make up what is known as the data hierar-
chy. This hierarchy defines how data is structured for use in the algorithms that
we will explore.
FILE A file is a collection of related data or facts. For
example, payroll facts for all employees in a company
form a payroll file. All the data in Figure 2–2
represents a payroll file.
RECORD A record is a collection of data, or facts, about a
single entity in the file. For example, payroll facts
for a single employee in a company form a payroll
record. Each line in Figure 2–2 represents one
payroll record.
FIELD A field is any single piece of data, or fact, about a
single entity (record) in a file. For example, an em-
ployee number might be one of the fields in a payroll
record. The employee number 06337 represents a
field in the first payroll record in Figure 2–2.
20 Chapter 2

Figure 2–2
Data Hierarchy EMPLOYEE EMPLOYEE EMPLOYEE PAY CITY STATE
NUMBER LAST NAME FIRST NAME RATE
Field
Character

06337 Jones Fred 10.50 New York NY Record

09155 Smith Susan 7.25 Atlanta GA

16840 Adams John 8.35 Atlanta GA

File
31719 Baker Jane 12.60 Detroit MI

CHARACTER A character is a letter (A–Z, a–z), number (0–9), or

special character (for example, . or ? or %, and so on).
For example, in Figure 2–2 the employee number
contains all numeric characters; the employee last
name contains all alphabetic characters; and the pay
rate contains several numeric characters and a special
character.

Sales Application Consider the sales operations of a large department store. A sales manager del-
egates responsibilities to supervisors in various departments. Each supervisor
Example submits a weekly sales report that is checked against inventory changes and
then used as the basis for figuring commissions. Each supervisor is confronted
with the task of preparing the weekly sales report for his or her department. In
some stores, each supervisor may be asked to develop his or her own proce-
dure. In other stores, the sales manager develops a detailed set of instructions
for each supervisor. In either case, the supervisor starts with the sales data
available (the input), thinks about the weekly sales report that is needed (the
output), and plans how to prepare the report on the basis of the sales data (the
process).

Sales Application System Flowchart

Before a program flowchart is developed to solve a problem, a system flow-
chart is often created to show more general information about the application.
A system flowchart illustrating the basic inputs, processes, and outputs for the
sales program needed for this application is shown in Figure 2–3.

Figure 2–3
Sales Problem (System
Flowchart) WEEKLY WEEKLY
SALES
SALES SALES
DATA
PROGRAM REPORT
 SIMPLE SEQUENCE Control Structure 21

The leftmost symbol on the system flowchart is the general input/output

(I/O) symbol, that is, the parallelogram. It always represents either input (data
available for processing) or output (processed data, or information, available to
users or for additional processing). Because this symbol can be used for both
input and output, it appears twice on the flowchart.
The rectangular symbol appears again in Figure 2–3. Here it is a general-
purpose symbol indicating, collectively, all processing steps within the sales pro-
gram. When this symbol appears on a system flowchart, it represents an action
or a series of actions performed with computer help—the carrying out of an
algorithm expressed in a computer-program form.
One important function of a flowchart is to aid in problem analysis and so-
lution planning; another is to aid the problem solver in communicating ideas
to others. To help standardize such communication, the American National
Standards Institute (ANSI) coordinated the development of a standard set of
flowcharting symbols and associated meanings. We use many of these symbols
in the flowcharts in this book. Their shapes and meanings are summarized in
Appendix A.
Thus, a system flowchart shows the data, flow of work, and workstations within
an information-processing system. In this chapter, we deal with simple problems
requiring only one computer program for their solution. A system flowchart may
show the flow of work through several programs, each having several inputs and
outputs, but such systems are beyond the scope of this chapter.

Sales Application Program Flowchart

Although a system flowchart is very helpful in showing the inputs, major pro-
cessing functions, and outputs of an information-processing system, it gives
little or no detail about how the computer performs the specific processing
steps. The system flowchart in Figure 2–3 shows that a program for computing
a weekly sales report is to be written and executed. It does not show which
mathematical operations are needed or the order in which the operations must
be performed. To provide this detailed information, we construct a program
flowchart.
In the program flowchart, the detailed steps needed to process the data
about one person’s sales must be specified. It is sometimes helpful to work
backward. In this flowchart, for example, we should first decide what we
need to know to compute a salesperson’s pay. Usually, a salesperson’s pay is
determined in part by how much he or she has sold in a given week. In this
example, the sales will be divided into two categories: those items sold at
regular price, and those sold at a reduced or sale price. Each person will be
paid a base amount as well as a percentage of his or her weekly sales. This
percentage (commission) will be 6 percent on the sales of regular-priced
items and 3 percent on the sales of sale-priced items.
Here is a representative sequence of instructions to solve this problem:
1. Input the two weekly sales totals for any employee.
2. Compute the regular commission by multiplying the regular sales
amount by 6 percent.
3. Compute the sales commission by multiplying the reduced sales
amount by 3 percent.
22 Chapter 2

4. Compute the total pay due: $400.00 (base pay) + regular

commission + sales commission.
5. Output the total pay on the payroll report.
These instructions also can be expressed pictorially whereby the steps to be
followed can be seen at a glance. A program flowchart of the required steps is
shown in Figure 2–4.
We have just traced the first two major actions within any problem-solving
task:
■ Define the problem to be solved.
■ Develop a solution algorithm—steps to be taken to solve the problem.
The five steps on the flowchart in Figure 2–4 correspond to Steps 1 through
5 of the written procedure. Notice, however, the use of the general I/O symbol
in Steps 1 and 5. It is important to understand that, before the pay can be com-
puted, the sales data must be known to the computer. We get this data into the
computer in an input step (notice the I/O symbol). This is almost always one of
the first steps in an algorithm. Typically, the word READ is used to indicate
input, but a word such as ENTER, GET, or INPUT can also be used.

Figure 2–4
Sales Problem (Program
Flowchart) START

READ 1
REGSALES,
SALESALES

REGCOM = 2
REGSALES
∗ .06

SALESCOM = 3
SALESALES
∗ .03

PAY =
REGCOM + 4
SALESCOM
+ 400

WRITE 5
PAY

STOP
 SIMPLE SEQUENCE Control Structure 23

In Step 1 the word READ is followed by the words REGSALES and SALE-
SALES. These words are names for variables. Variables are data items whose
values may change, or vary, during processing. We create variable names to
represent, or refer to, these data items.
One common mistake is to put specific data right in a program, such as:

READ
$1000,
$3000

This step may tell the reader that the salesperson sold $1000 worth of regular
items and $3000 worth of sale items. These numbers, although correct for one
employee, are likely to need changing each time the program is run because each
employee’s sales data is likely to differ. This problem is handled by the use of
variables. The variable names are place-holders for the specific data values. The
value of a variable can change each time a program is run, or even within one run
of the same program. Think of a mailbox: The address (variable name) is always
the same, but the mail (content) is different every day.
When a variable is used in conjunction with a READ statement, we can as-
sume that the value of the variable is now known to the computer; this is
called a defined value. The use of variables helps to ensure that the program
is data independent, which means that the program will perform the re-
quired processing steps on any set of input data. Figure 2–5 shows a snapshot
of the computer’s memory at this point. We refer to the figure as a memory
diagram. On the left is a list of all the variable names referenced in the algo-
rithm. The boxes on the right represent the actual values that these variable
names refer to in the computer’s memory. At this point REGSALES and
SALESALES represent values that were input in Step 1. Actually, these two
amounts can be any numbers equal to the values of whatever was sold. In our
example, we will assume that the regular sales amount (REGSALES) was
$1000.00 and the reduced sales amount (SALESALES) was $3000.00. Only
the values of REGSALES and SALESALES are defined to the computer at
this point.
In Step 2 of the algorithm, the regular commission is computed. Because
this step involves arithmetic, it is represented by a process symbol, not by an
I/O symbol. In this step, we are illustrating the use of an important fundamen-
tal statement—the assignment statement. This statement is commonly used

Figure 2–5
Sales Problem—Memory REGSALES 1000
Diagram 1
SALESALES 3000

REGCOM

SALESCOM

PAY
24 Chapter 2

when describing computer processing. An assignment statement must adhere

to the following rules of formation:
1. Only a single variable name may appear to the left of the assignment
symbol, which in our example is = .
2. Only a single variable name, constant, or expression may appear to the
right of the =.
3. Everything to the right of the = must be known (defined) to the
computer.
Step 2 uses an assignment statement to compute the commission on the reg-
ular sales. Because the percentage is always 6 percent, the .06 can be used in
the statement. The .06 is an example of a constant, a value that never changes.
Because .06 is a constant, it can be placed in computer storage when the pro-
gram itself is placed in computer storage. Therefore, it does not have to be
input during processing. The times sign (*) is defined because it refers to a
basic arithmetic operation the computer can perform. The asterisk symbol is
used to show multiplication because the traditional times sign, *, may be con-
fused with the variable name X. The only other item to the right of the = is the
variable name REGSALES. Because the value of this variable was previously
input (Step 1), it is also known at this time. Because everything to the right of
the = is defined, the computer can now do the calculation and assign the result
to the variable on the left of the =. When carrying out an assignment statement,
the computer operates on everything defined to the right of the = first. In this
example, $1000 is multiplied by .06, and the result, $60, is assigned to the vari-
able name REGCOM. REGCOM is now known or defined to the computer (see
Figure 2–6).
Step 3 computes the commission on the sales items (remember 3 percent).
Can you see that everything to the right of the = is defined to the computer?
SALESALES is multiplied by .03, and the result is assigned to SALESCOM
(see Figure 2–7).
Step 4 then adds the two computed commissions to the base pay of $400 to
come up with the salesperson’s total pay. Notice that the base pay is a con-
stant—all salespeople get at least $400. In this assignment statement, values for
the two variables on the right were not input but are still defined to the computer.
Any variable that is the result of a computation (left side) in a previous step is
defined and can be used in subsequent steps. As a result of Step 4, the variable
name PAY is now defined and has a value of $550 (see Figure 2–8).
At this point, the pay for a single employee has been computed, but it is still
inside the computer. Often we want to see that pay on a piece of paper. If so, it

Figure 2–6
Sales Problem—Memory REGSALES 1000
Diagram 2
SALESALES 3000

REGCOM 60

SALESCOM

PAY
 SIMPLE SEQUENCE Control Structure 25

Figure 2–7
Sales Problem—Memory REGSALES 1000
Diagram 3
SALESALES 3000

REGCOM 60

SALESCOM 90

PAY

Figure 2–8
Sales Problem—Memory REGSALES 1000
Diagram 4
SALESALES 3000

REGCOM 60

SALESCOM 90

PAY 550

must be output from the computer to a printer. We show this operation in Step
5, again using an I/O symbol, with the word WRITE indicating output. Words
such as OUTPUT, PRINT, or DISPLAY also can be used. The current value of
a variable can be output, provided it has been defined, either by being input or
by being computed. We see here that PAY was computed in Step 4.
Throughout this process, several variable names have been introduced. Usually,
variable names are chosen by the software developer or development team. It is a
wise idea to choose descriptive names, such as SALES, instead of S. Descriptive
variable names make the algorithm (in flowchart form and later in programming-
language form) much more self-documenting and easier to read.

Design When the developer is satisfied that all processing steps have been identified and
Verification provided for, the solution algorithm should be verified. The objective is to prevent
errors from occurring, or, if some have already occurred, to detect and eliminate
them as soon as possible. In the past, a major portion of a developer’s time was
spent, not in program design and coding, but rather in debugging and testing.
Today, many computer professionals insist that this need not be the case: A pro-
gram can be written correctly, so that it executes properly the first time it is run. A
careful, early verification of the program design, or solution algorithm, is an es-
sential step in achieving this objective.
Under one approach to verification of design, the design documentation is
distributed to selected reviewers, who are asked to study it and respond within a
set time. Each reviewer is directed to note, individually, any required changes,
additions, and deletions. This approach is known as an informal design review.
Another approach is the use of structured walkthroughs. At this point in
algorithm development, the walkthrough is a formal design review. Here, the
design documentation is made available to several people selected to serve as
members of a review team. After the reviewers have had time to prepare, they
meet together with the developer and a moderator for an established period,
usually about two hours. Each reviewer is expected to have studied the design
26 Chapter 2

documentation and is asked to comment on its completeness, accuracy, and

general quality. Then the moderator “walks” the group through each step of the
documentation, covering any points raised by the review team.
How does one start when reviewing a solution algorithm set forth in a pro-
gram flowchart or other form of design documentation? Some reviewers, indi-
vidually or in groups, find that one effective approach is to pretend to be the
computer. Representative values for all types of input are selected: (1) data that
is normally expected; (2) valid but slightly abnormal data (e.g., minimum and
maximum values allowable); and (3) invalid data. The individual or group fol-
lows the problem-solving logic step by step to process the input and determine
what output will be produced. If the output matches predetermined correct re-
sults, the logic within the solution algorithm is upheld. Pretending to be the
computer in this way is called simulation, procedure execution, or desk
checking. While tracing the problem-solving logic, each reviewer must be
careful not to make any assumptions. The computer can do only what it is told;
it is unable to make assumptions.

Sample Problem 2.1 Temperature Conversion Problem

Problem:
The International Broadcasting Company wants a computer program that will
accept a temperature reading expressed in Fahrenheit degrees as input, con-
vert the value to Celsius degrees, and provide both the Fahrenheit value and
the Celsius value as output for its hourly weather report.

Solution:
The system flowchart for this application is shown at the left in Figure 2–9. A
program flowchart representation of the solution algorithm, showing how the
problem is to be solved, is given at the right.
The terminal interrupt symbol containing START identifies the beginning of
the program. First, the Fahrenheit value (FARENHT) is read as input. Figure
2–10 shows a memory diagram assuming an input value of 77 degrees.
In the next step, a familiar mathematical formula is executed to convert this
value from Fahrenheit to Celsius. This formula contains three constants (32,
5, and 9) and several mathematical operators. The computer evaluates mathe-
matical expressions in a specific order. All multiplication and division opera-
tions are evaluated first, in a left-to-right order. Next, all addition and
subtraction operations are evaluated, again from left to right. We can place
parentheses around part of an expression if we want the computer to evaluate
that part first. If there are several sets of parentheses, the innermost parenthe-
ses are evaluated first. Figure 2–11 shows how two expressions, one with
parentheses and one without parentheses, are evaluated. Notice that the
results are different.
In Sample Problem 2.1, parentheses are placed around the expression
FARENHT–32 because the subtraction needs to be done before the multipli-
cation. Without the parentheses, first the 32 would have been multiplied by 5,
then that result would have been divided by 9, and then that result would have
 SIMPLE SEQUENCE Control Structure 27

Figure 2–9
Temperature Conversion SYSTEM PROGRAM
Problem FLOWCHART FLOWCHART

START

FAHREN-
HEIT READ
TEMPERA- FARENHT
TURES

TEMPERATURE CELSIUS =
CONVERSION (FARENHT
PROGRAM – 32) ∗ 5 / 9

CELSIUS WRITE
TEMPERA- FARENHT,
TURES CELSIUS

STOP

Figure 2–10
Temperature Conversion FARENHT 77
Problem—Memory
Diagram 1 CELSIUS

Figure 2–11
Expression Evaluation Expression—no parentheses Expression—with parentheses

3 + 5 * 2 - 8/4 (3 + 5) * 2 - 8/4
3 + 10 - 8/4 8 * 2 - 8/4
3 + 10 - 2 16 - 8/4
13 - 2 16 - 2
11 14

been subtracted from the current value of the variable FARENHT. This
sequence of operations would have produced an incorrect result.
Figure 2–12 shows a memory diagram after the value of CELSIUS has
been computed correctly.

Figure 2–12
Temperature Conversion FARENHT 77
Problem—Memory
Diagram 2 CELSIUS 25

(continued)
28 Chapter 2

The two temperatures, FARENHT and CELSIUS, are then written as output.
Notice that the value of the variable FARENHT is not computed in the algo-
rithm. However, because it is input, it is known to the computer (look again at
Figure 2–10). At this point, the computer provides two numbers as output
without identifying them. In Chapter 3, we will discuss how to label output
values. Finally, program execution is terminated.
When the computer executes this simple sequence of basic operation, it
will provide the solution to this temperature conversion problem.

Sample Problem 2.2 Billing Problem

Problem:
A major department store needs a program to prepare a monthly bill for each
customer. For simplicity, let us assume that each customer purchases (at most)
one type of item each month. For each purchase, there will be four input values:
customer name, item, quantity purchased, and price. The output will be the cus-
tomer’s monthly bill after a 10 percent discount is taken before taxes, and a 5
percent sales tax is added.

Solution:
The system flowchart to represent this billing problem appears in Figure
2–13. The program flowchart for the billing program to provide the solution
appears in Figure 2–14.
Four values are input in the first step on the program flowchart. Figure
2–15 shows a memory diagram after four specific values have been read during
processing.
Notice that both AMTOD and DISCOUNT must be defined before they
can be used on the right-hand side of an assignment statement. The next two
steps on the flowchart compute these values. The results are illustrated in
Figure 2–16.

Figure 2–13
Billing Problem (System
Flowchart) CUSTOMER
BILLING
DATA

MONTHLY
BILLING
PROGRAM

MONTHLY
BILL
 SIMPLE SEQUENCE Control Structure 29

Figure 2–14
Billing Problem (Program
Flowchart) START

READ
NAME,
ITEM, QTY,
PRICE

AMTOD =
QTY *
PRICE

DISCOUNT =
AMTOD
* .10

SUBBILL =
AMTOD -
DISCOUNT

TAXES =
SUBBILL
* .05

BILL =
SUBBILL
+ TAXES

WRITE
NAME,
ITEM,
BILL

STOP

What other variables must be defined? Desk-check the solution algorithm

to verify that each assignment statement operates only on values that are well
defined to the computer. What are the names of the variables that are input?
What are the names of the variables that are output? What constants are used
in this algorithm? (See Exercise 11 at the end of the chapter.)
Before you go on to the exercises, give some thought to the following ques-
tions: Think about why we used constants to represent the discount percent (.10)
(continued)
30 Chapter 2

Figure 2–15
Billing Problem—Memory NAME MR. JOHN LEE
Diagram 1
ITEM SCARF

QTY 2

PRICE 19.50

AMTOD

DISCOUNT

SUBBILL

TAXES

BILL

Figure 2–16
Billing Problem—Memory NAME MR. JOHN LEE
Diagram 2
ITEM SCARF

QTY 2

PRICE 19.50

AMTOD 39.00

DISCOUNT 3.90

SUBBILL

TAXES

BILL

and the tax percent (.05). Could we have represented this data by variables in-
stead? (See Exercise 12.) Also, why do you think the billing data was not con-
stant? Can you think of some general criteria that might determine when data
used in a program should be constant and when it should be allowed to vary, that
is, to be represented by variables?
Finally, think about the following questions: What happens within the com-
puter during the stages of input? Processing? Output? Do you think each stage
is necessary in every algorithm? We answer many of these questions, and
more, in future chapters.

Flowcharting A tool that may be provided for the software developer’s use is a flowcharting
Tools template. The template is a plastic or metallic card containing flowcharting
symbols as cutout forms (see Figure 2–17). The developer can easily trace the
outlines of the symbols needed for both system and program flowcharts. The
flowcharting symbols on the template generally comply with the American
National Standards Institute (ANSI) and International Standards Organization
(ISO) recommendations summarized in Appendix A.
 SIMPLE SEQUENCE Control Structure 31

1 2 3 4 5 6 7 8 9
9

I N CH ES i n te n th s
PROCESS INPUT/OUTPUT DOCUMENT MANUAL INPUT PREPARATION MERGE
8

COMMUNICATION LINK
7

* Offline Storage

* Command annotation
* Predefined Process EXTRACT
6

DIRECTION DISPLAY AUXILARY OPERATION ARROWHEADS

MANUAL INPUT
METRIC (1 milimeter = 0.394 inch)
5

* Sort

* Collate
4

CONNECTOR
* Magnetic Tape * Core

TRANSMITTAL
ONLINE STORAGE KEYING TAPE
3

OFFPAGE
PUNCHED CARD PUNCHED TAPE CONNECTOR

TERMINAL INTERRUPT
2

* Card Deck * Card File * Magnetic Drum * Magnetic Disk

1

*Composite Symbol (see envelope for details) FLOWCHART TEMPLATE GX20-8020-1 UM 010
I N C H ES i n e i gh th s
1 2 3 5 6 7 8 9

Figure 2–17
Flowcharting Template (Source: Reprint Courtesy of International Business Machines Corporation, copyright
© International Business Machines Corportaion)

In recent years, software vendors have developed numerous CASE tools

that can be used to construct and modify system and program flowcharts.
These CASE tools can save the development team many hours of work and,
consequently, have become quite popular. Use of a flowcharting template or of
a CASE tool that generates flowcharts is not only convenient but also encour-
ages uniformity in flowcharting, which in turn provides for better communica-
tion between the developer and others who refer to the developer’s flowcharts.

Enrichment Visual Basic

Windows is a program that creates a graphical user interface on the screen

while managing all applications running on a computer. Visual Basic is used
to create applications that will run in the Windows programming environ-
ment. Visual Basic is an event-driven programming language that incorpo-
rates graphical user interface design and programming code. This section, as
well as the other Visual Basic sections in subsequent chapters, does not at-
tempt to teach you how to program. These sections simply illustrate some of
the program design examples in this book. As you read through these Visual
Basic examples, you should get a sense of what is actually involved in the
creation and execution of a Visual Basic program.
Figure 2–18 illustrates the graphical user interface for the temperature
conversion problem (see Figure 2–9). In Visual Basic, the programmer
creates the interface by placing objects, or controls, on the screen. In this
example, five objects are created: three labels, one text box, and one
(continued)
Exploring the Variety of Random
Documents with Different Content
law in creating the Project Gutenberg™ collection. Despite these
efforts, Project Gutenberg™ electronic works, and the medium
on which they may be stored, may contain “Defects,” such as,
but not limited to, incomplete, inaccurate or corrupt data,
transcription errors, a copyright or other intellectual property
infringement, a defective or damaged disk or other medium, a
computer virus, or computer codes that damage or cannot be
read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU AGREE
THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT
LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT
EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE
THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person
or entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set

forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you
do or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status
by the Internal Revenue Service. The Foundation’s EIN or
federal tax identification number is 64-6221541. Contributions
to the Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact
 Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or determine
the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.