Modules, Hierarchy Charts, and Documentation

1. 3 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. AdvantagesModularization 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 • REUSE YOUR WORK • You can find many real-world examples of reusability Chapter 3

7. Modularization : • When you combine several programming tasks into modules, it may be easier for you to identify structures Makes It Easier 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. No module With module Another Example Chapter 3

11. 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” Modularizing a Program- Flowchart Symbols 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. 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

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

19. Flowchart for Averaging Program with Submodules Chapter 3

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

21. Hierarchy Chart for Value-Averaging Program Chapter 3

22. An Organizational Hierarchy Chart Chapter 3

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

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

25. One of first things done in a program in declaring variables Declaring Variables in a Flowchart • 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

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

27. 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 What is Documentation Chapter 3

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

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

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

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

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

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

34. 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 /*************************/ /* Program: Payroll */ /* Author: Dan Dainton */ /* Date: March 2, 1999 */ /*************************/ Internal Documentation /*************************/ /* This module calculates*/ /* tax deductions for */ /* payroll checks. */ /*************************/ Chapter 3

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

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

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

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

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

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

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

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

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

44. Printer Spacing Chart Chapter 3

45. Printer Spacing Chart with First Title Chapter 3

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

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

48. Print Chart with Generic Data Chapter 3

49. Variable Data in Report Heading Chapter 3

50. Heading with Page Numbers Chapter 3