1. Modules, Hierarchy Charts, and Documentation3
Modules, Hierarchy Charts, and Documentation
Programming Logic and Design, Second Edition, Comprehensive
Chapter 3

2. 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

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

4. 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

5. Advantages Modularization Allows: Multiple Programmers to Work on a Problem
Dissect large task into modules
divide the task among various people
Chapter 3

6. Modularization Allows: You to Reuse Your Work
You can find many real-world examples of reusability
Chapter 3

7. 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

8. Selection of Logic From a Payroll Program
Chapter 3

9. 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

10. Modules can better help you determine if your flowchart is structured.
Another Example
No module
With module
Modules can better help you determine if your flowchart is structured.
Chapter 3

11. 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

12. 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

13. Another Example
Chapter 3

14. Let’s try
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

15. Example 1 - Without a module
Chapter 3

16. Example 1 - With a Module
Chapter 3

17. Example 2
Create a flowchart showing the logic needed to accept a series of numbers, print each number when it is read, and print the total after all the numbers are read.
An example run 28
of the program: 10 15 53
Chapter 3

18. Example 2 - Without a Module
Chapter 3

19. Example 2 - With a Module
Chapter 3

20. 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

21. Averaging Program with Submodules
Chapter 3

22. Flowchart and Pseudocode for Averaging Program with Modules
Chapter 3

23. Flowchart for Averaging Program with Submodules
Chapter 3

24. 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

25. Hierarchy Chart for Value-Averaging Program
Chapter 3

26. An Organizational Hierarchy Chart
Chapter 3

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. Input Documentation Numeric data are stored with leading zeros
Programmers create one variable for each field in the input file
Chapter 3

35. Input Documentation
Recall the data hierarchy relationship introduced in Chapter 1:
Database
File
Record
Field
Character
Chapter 3

36. 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

37. Expanded Inventory File Description
The file description in Figure 3-21 contains nine fields
Chapter 3

38. Internal Documentation
/*************************/
/* Program: Payroll */
/* Author: Dan Dainton */
/* Date: March 2, */
Comments within programming code
Lines of code that do not effect the running of the program.
Written so programmers can
understand what the program is doing
why the program is doing it
/*************************/
/* This module calculates*/
/* tax deductions for */
/* payroll checks */
Chapter 3

39. 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

40. 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

41. Output Documentation: 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

42. A Report Design Example
This report will track inventory for a company
Report Title : ie “Inventory Report”
Chapter 3

43. 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

44. 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 lines in your print chart. Why?
Chapter 3

45. 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

46. 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

47. 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

48. Printer Spacing Chart
Chapter 3

49. Printer Spacing Chart with First Title
Chapter 3

50. Printer Spacing Chart with Title and Column Headings
Chapter 3

51. 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

52. Print Chart with Generic Data
Chapter 3

53. Variable Data in Report Heading
Chapter 3

54. Heading with Page Numbers
Chapter 3

55. Print Chart with Literal in Each Detail Line
Chapter 3

56. 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

57. Report with Variable Data at End
Chapter 3

58. Report with Constant Data at End
Chapter 3

59. Report with Combined Constant and Variable Data at End
Chapter 3

60. 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

61. 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

62. IN Summary- Review 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

63. 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

64. 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