Modules hierarchy charts and documentation
Download
1 / 60

Modules, Hierarchy Charts, and Documentation - PowerPoint PPT Presentation


  • 201 Views
  • Updated On :

3. Modules, Hierarchy Charts, and Documentation. Programming Logic and Design, Second Edition, Comprehensive. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Modules, Hierarchy Charts, and Documentation' - nerice


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Modules hierarchy charts and documentation l.jpg

3

Modules, Hierarchy Charts, and Documentation

Programming Logic and Design, Second Edition, Comprehensive

Chapter 3


Objectives l.jpg
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


Objectives3 l.jpg
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


Modules l.jpg
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


Advantages modularization allows multiple programmers to work on a problem l.jpg
AdvantagesModularization Allows:Multiple Programmers to Work on a Problem

  • Dissect large task into modules

  • divide the task among various people

Chapter 3


Modularization allows you to reuse your work l.jpg
Modularization Allows:You to Reuse Your Work

  • REUSE YOUR WORK

  • You can find many real-world examples of reusability

Chapter 3


Modularization l.jpg
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


Selection of logic from a payroll program l.jpg
Selection of Logic From a Payroll Program

Chapter 3


Modularized logic from a payroll program l.jpg
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


Another example l.jpg

Modules can better help you determine if your flowchart is structured.

No module

With module

Another Example

Chapter 3


Modularizing a program flowchart symbols l.jpg

Sentinel Symbols structured.

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


Modularize a program naming the module l.jpg
Modularize a Program: structured.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


Another example13 l.jpg
Another Example structured.

Chapter 3


Let s try l.jpg
Let’s try structured.

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


Slide15 l.jpg

Example 1 - Without structured.a module

Chapter 3


Slide16 l.jpg

Example 1 - With a Module structured.

Chapter 3


Modules calling other modules l.jpg
Modules Calling Other Modules structured.

  • A module can be called by both the main program or by another module

  • Modules called by other modules are called submodules.

Chapter 3


Flowchart and pseudocode for averaging program with modules l.jpg
Flowchart and Pseudocode structured.for Averaging Program with Modules

Chapter 3


Flowchart for averaging program with submodules l.jpg
Flowchart for Averaging structured.Program with Submodules

Chapter 3


Another tool creating hierarchy charts l.jpg
Another Tool: structured.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


Hierarchy chart for value averaging program l.jpg
Hierarchy Chart for structured.Value-Averaging Program

Chapter 3


An organizational hierarchy chart l.jpg
An Organizational Hierarchy Chart structured.

Chapter 3


Declaring variables l.jpg
Declaring Variables structured.

  • 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


Declaring variables24 l.jpg
Declaring Variables structured.

  • 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


Declaring variables in a flowchart l.jpg

One of first things done in a program in declaring variables structured.

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


Declaring variables26 l.jpg
Declaring Variables structured.

  • 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


What is documentation l.jpg

All supporting material that goes along with a program structured.

User documentation

Manuals

Training material

Program documentation

used for planning or modifying programs

internal and external program documentation

What is Documentation

Chapter 3


Program input documentation l.jpg
PROGRAM : structured.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


Slide29 l.jpg

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


Input documentation l.jpg
Input Documentation structured.

  • Numeric data are stored with leading zeros

  • Programmers create one variable for each field in the input file

Chapter 3


Input documentation31 l.jpg
Input Documentation structured.

  • Recall the data hierarchy relationship introduced in Chapter 1:

    • Database

    • File

    • Record

    • Field

    • Character

Chapter 3


Input documentation32 l.jpg
Input Documentation structured.

  • 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


Expanded inventory file description l.jpg
Expanded Inventory File Description structured.

  • The file description in Figure 3-21 contains nine fields

Chapter 3


Internal documentation l.jpg

Comments within programming code structured.

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


External documentation l.jpg
External Documentation structured.

  • 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


Output documentation l.jpg
Output Documentation structured.

  • 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


Output documentation designing a report l.jpg
Output Documentation: structured.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


A report design example l.jpg
A Report Design Example structured.

  • This report will track inventory for a company

  • Report Title : ie “Inventory Report”

Chapter 3


Creating column headings l.jpg
Creating Column Headings structured.

  • 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


More on detail lines l.jpg
More on Detail Lines structured.

  • 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


Understanding documentation l.jpg
Understanding Documentation structured.

  • 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


Understanding documentation42 l.jpg
Understanding Documentation structured.

  • 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


Output documentation43 l.jpg
Output Documentation structured.

  • 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


Printer spacing chart l.jpg
Printer Spacing Chart structured.

Chapter 3



Printer spacing chart with title and column headings l.jpg
Printer Spacing Chart with structured.Title and Column Headings

Chapter 3


Output documentation47 l.jpg
Output Documentation structured.

  • 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


Print chart with generic data l.jpg
Print Chart with Generic Data structured.

Chapter 3


Variable data in report heading l.jpg
Variable Data in Report Heading structured.

Chapter 3


Heading with page numbers l.jpg
Heading with Page Numbers structured.

Chapter 3


Print chart with literal in each detail line l.jpg
Print Chart with Literal structured.in Each Detail Line

Chapter 3


Output documentation52 l.jpg
Output Documentation structured.

  • 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


Report with variable data at end l.jpg
Report with Variable Data at End structured.

Chapter 3


Report with constant data at end l.jpg
Report with Constant Data at End structured.

Chapter 3


Report with combined constant and variable data at end l.jpg
Report with Combined structured.Constant and Variable Data at End

Chapter 3


Completing the documentation l.jpg
Completing the Documentation structured.

  • Program Documentation

    • Design outputPlan the logic of the program

    • Code the program

    • Test the program

  • User documentation

    • User documentation instructional materials that nontechnical people use

Chapter 3


Completing the documentation57 l.jpg
Completing the Documentation structured.

  • 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


In summary review modules l.jpg
IN Summary- structured.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


Summary variables l.jpg
Summary- Variables structured.

  • 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


Summary documentation l.jpg
Summary- Documentation structured.

  • 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


ad