Transcript Modules, Hierarchy Charts, and Documentation Programming Logic and Design, Second Edition, Comprehensive Chapter 3

3
Modules, Hierarchy Charts, and
Documentation
Programming Logic and Design,
Second Edition, Comprehensive
Chapter 3
1
3
Objectives
• After studying Chapter 3, you should be able to:
• Describe the advantages of modularization
• Modularize a program
• Understand how a module can call another
module
• Explain how to declare variables
Chapter 3
2
3
Objectives
• After studying Chapter 3, you should be able to:
• Create hierarchy charts
• Understand documentation
• Create print charts
• Interpret file descriptions
• Understand the attributes of complete
documentation
Chapter 3
3
3
Modules
• Large programs are never written as one huge
series of steps.
• Programs are broken down into units called
modules.
• Modules are also referred to as:
– subroutines
– functions
– procedures
– methods
Chapter 3
4
3
Advantages
Modularization Allows:
Multiple Programmers
to Work on a Problem
1. Dissect large task into modules
2. divide the task among various people
•
Chapter 3
5
3
Modularization Allows:
You to Reuse Your Work
• REUSE YOUR WORK
• You can find many real-world examples of
reusability
Chapter 3
6
3
Modularization :
Makes It
Easier to Identify Structures
• When you combine several programming tasks
into modules, it may be easier for you to identify
structures
Chapter 3
7
3
Selection of Logic
From a Payroll Program
Chapter 3
8
3
Modularized Logic
from a Payroll Program
•The single program segment
shown in Figure 3-2
accomplishes the same steps as
the two program segments
shown together in Figure 3-3;
both programs are structured
Chapter 3
9
3
Another Example
No module
Modules can better help you
determine if your flowchart is
structured.
Chapter 3
With module
10
3
Modularizing a
Program- Flowchart
Symbols
Sentinel Symbols
• A module has it own
sentinel symbols (Start
and End)
• The Start symbol has the
name of the module
• The End symbol has the
word “RETURN”
Chapter 3
11
3
Modularize a Program:
Naming the MODULE
• In this text, module names will follow the
same two rules used for variable names:
– Module names must be one word
– Module names should have some meaning
– Additionally, in this text module names will be
followed by a set of parentheses
Chapter 3
12
Another Example
Chapter 3
3
13
Let’s try
3
Example 1 Write a flowchart showing the logic to calculate the volume of an
undetermined amount of rooms. (Volume = Length * Width *
Height)
Think about what your logic needs – Input
– Processing (for more than one room)
– Output
Create a flowchart first without and then with a module.
Chapter 3
14
3
Example 1
- Without
a module
Chapter 3
15
3
Example
1 - With
a Module
Chapter 3
16
3
Modules Calling Other Modules
• A module can be called by both the main program or
by another module
• Modules called by other modules are called
submodules.
Chapter 3
20
3
Flowchart and Pseudocode
for Averaging Program with Modules
Chapter 3
22
Flowchart for Averaging
Program with Submodules
Chapter 3
3
23
3
Another Tool:
Creating Hierarchy Charts
• You can use a hierarchy chart to illustrate
modules’ relationships
• A hierarchy chart does not tell you what tasks
are to be performed within a module; it does
not tell you when or how a module executes
• The hierarchy chart for the last version of the
value-averaging program looks like Figure 3-7
Chapter 3
24
3
Hierarchy Chart for
Value-Averaging Program
Chapter 3
25
3
An Organizational Hierarchy Chart
Chapter 3
26
3
Declaring Variables
• Declaring a variable provides a name for a
memory location
– where computer stores variable values
– notifies computer of data type
• Programming languages declare variables
differently, but minimally you must
– give the variable a name
– give the variable a data type
Chapter 3
27
3
Declaring Variables
• An annotation symbol or annotation box is simply
an attached box containing notes
• You can use an annotation symbol any time you
have more to write than conveniently fits within a
flowchart symbol
• Programmers sometimes create a data dictionary,
which is a list of every variable name used in a
program, along with its type, size, and description
• When a data dictionary is created, it becomes
part of the program documentation
Chapter 3
28
3
Declaring Variables in a Flowchart
• One of first things done in a
program in declaring variables
 Next to the process
symbol “Declare
Variables” is an
annotation box stating
the names and types of
the variables
 Annotation boxes can be
used anytime text does
not fit in a symbol
Chapter 3
29
3
Declaring Variables
• Languages including COBOL, C++, C#, Java,
and Pascal require declaration of variables with
name and type
• Modern programming languages: variables are
declared within each module that uses them.
Such variables are known as local variables
• We will use global variables—variables that are
given a type and name once- used in all
modules of the program
Chapter 3
30
3
What is Documentation
• All supporting material that goes along with
a program
– User documentation
• Manuals
• Training material
– Program documentation
• used for planning or modifying programs
• internal and external program documentation
Chapter 3
31
3
PROGRAM :
Input Documentation
• A file description describes the data contained in
an input file
• File’s description as part of an organization’s
information systems’ documentation;
Chapter 3
32
3
Input
The inventory file description in Figure 3-20 shows that each items’
name occupies the first 15 characters of each record in the file
• The price of any item in the inventory file is allowed five
positions, 16 through 20
• Two of the positions are reserved for decimal places
• Typically, decimal points themselves are not stored in data
files; they are implied or assumed
Chapter 3
33
3
Input Documentation
• Numeric data are stored with leading zeros
• Programmers create one variable for each field in
the input file
Chapter 3
34
3
Input Documentation
• Recall the data hierarchy relationship
introduced in Chapter 1:
– Database
– File
– Record
– Field
– Character
Chapter 3
35
3
Input Documentation
•
The programmer needs to know is:
– What is the name of the file?
– What data does it contain?
– How much room does the file and each of its fields take
up?
– What type of data is each field—character or numeric?
Chapter 3
36
3
Expanded Inventory File Description
•The file description in Figure 3-21 contains nine fields
Chapter 3
37
3
Internal Documentation
• Comments within
programming code
• Lines of code that do not
effect the running of the
program.
/*************************/
/* Program: Payroll
*/
/* Author: Dan Dainton
*/
/* Date: March 2, 1999
*/
/*************************/
• Written so programmers can
– understand what the
program is doing
/*************************/
/* This module calculates*/
– why the program is doing it
/* tax deductions for
*/
/* payroll checks.
*/
/*************************/
Chapter 3
38
3
External Documentation
• All supporting paperwork a programmer develops
before writing a program.
• External documentation can describe
– Input
– Processing
– Output
• Output documentation is developed first. Why?
Chapter 3
39
3
Output Documentation
• Generally, the reason you would write a program
in a business environment is because particular
information is needed.
• Can the programmer decide what information is
needed and how it’s designed? Can the user
requesting the information?
Chapter 3
40
Output Documentation:
3
Designing a Report
• Printed reports are the most common type of output.
• Reports are designed on printer spacing charts.
– Looks like a grid
– One character per box
Chapter 3
41
3
A Report Design Example
• This report will track inventory for a company
• Report Title : ie “Inventory Report”
Chapter 3
42
3
Creating Column Headings
• Report column : heading
– constant that appear on every page of the report
• Because the headings remain the same throughout the report, they
are written on the print chart literally.
Chapter 3
43
3
More on Detail Lines
• Detail lines
– have variable data
– probably have a variable amount of detail lines on the report
• All the detail lines look the same, but you need to show 2 - 3
lines in your print chart. Why?
Chapter 3
44
3
Understanding Documentation
• Documentation refers to all of the supporting
material that goes with a program
• Two broad categories of documentation are
intended for the programmer and for the user
• People who use computer programs are called
end users, or users for short
• When programmers begin to plan the logic of a
computer program, they require instructions
known as program documentation
Chapter 3
45
3
Understanding Documentation
• Program documentation falls into two categories:
internal and external
• Internal program documentation consists of
program comments, or nonexecuting statements
that programmers place within their code to
explain program statements in English
• External program documentation includes all the
supporting paperwork that programmers develop
before they write a program
Chapter 3
46
3
Output Documentation
• Output documentation is usually the first to be
written
• The most common type of output is a printed
report
• You can design a printed report on a printer
spacing chart, which is also referred to as a print
chart or a print layout
• The title and column headings will be constant on
every page of the report so they are written on the
print chart literally
Chapter 3
47
3
Printer Spacing Chart
Chapter 3
48
3
Printer Spacing Chart with First Title
Chapter 3
49
3
Printer Spacing Chart with
Title and Column Headings
Chapter 3
50
3
Output Documentation
• The exact spacing and use of upper- or lowercase
make a difference
• Notice that the constants used within a report do
not need to follow the same rules as variable
names
• A print layout typically shows how the variable
data will appear on the report
• Each line with its Xs and 9s representing data is a
detail line because it contains the data details
Chapter 3
51
3
Print Chart with Generic Data
Chapter 3
52
3
Variable Data in Report Heading
Chapter 3
53
3
Heading with Page Numbers
Chapter 3
54
3
Print Chart with Literal
in Each Detail Line
Chapter 3
55
3
Output Documentation
• Detail lines typically appear many times per
page, as opposed to heading lines, which
usually appear only once per page
• Besides header lines and detail lines, reports
often include special lines at the end of a report
• Even though lines at the end of a report don’t
always contain numeric totals, they are usually
referred to generically as total lines
Chapter 3
56
3
Report with Variable Data at End
Chapter 3
57
3
Report with Constant Data at End
Chapter 3
58
3
Report with Combined
Constant and Variable Data at End
Chapter 3
59
3
Completing the Documentation
• Program Documentation
– Design output
Plan the logic of the program
– Code the program
– Test the program
• User documentation
– User documentation
instructional materials that nontechnical people
use
Chapter 3
60
3
Completing the Documentation
• The areas addressed in user documentation may
include:
– Description of input for the program
– Who needs the output
– What output should look like
– How to interpret and react to any error message
generated by the program
– How frequently the program needs to run
Chapter 3
61
3
IN SummaryReview Modules
• Programming using modules
• Module is given a name- that name is CALLED
by the calling program
• A module can call other modules
Chapter 3
62
3
Summary- Variables
• To Declaring a Variable:
providing a name for the memory location where
the value is stored
• Identify the data type
You can use a hierarchy chart to illustrate
modules’ relationships
• Documentation refers to all of the supporting
material that goes with a program
• Output documentation is usually written first
Chapter 3
63
3
Summary- Documentation
• File description: lists the data in a file
( description, size, and data type)
• Program documentation – file descriptions,
printer spacing charts etc
•
User Documentation
manuals or other
instructional materials that nontechnical people
use as well as the operating instructions that
computer operators and data-entry personnel
may need
Chapter 3
64