Just as organization charts can be used to depict the structure of a business, hierarchy charts can be used to show the overall structure of a program. A module is a named collection of code. In Python and C++, functions are examples of modules. A hierarchy chart graphically shows the relationships among modules by depicting the hierarchical connections between modules.

Hierarchy charts can be used both as a design tool and as documentation. Even when used as documentation, and drawn based on existing software, a hierarchy chart often reveals the design process used to create the software. To create a hierarchy chart, start at the top and work your way down, hence the term top-down design. Top-down program design is based on the idea of levels of abstraction becoming levels of modules in a program. One definition of abstract, as a noun, is "a summary." In a sense, this is what each higher level module is -- a summary of subfunctions on lower levels. For example, the abstraction accounts receivable is useful for those who wish to communicate generally, without having to reference specifically: invoicing, cash receipts, sales journal, or customer statements. A term such as invoicing is a lower level of abstraction. These levels of abstraction, then, become the levels of modules in a program.

Because hierarchy charts do not show data flow, order of execution, or when and how often each module will be invoked, there is no order of execution implied by placing modules within a given level. People tend to think in a left-to-right manner, and there is no harm in arranging the boxes in that fashion. The only reason to arrange the boxes in a different order is if it helps in spacing the diagram in such a way as to fit on a page.

If the lines don't show order of execution, what do they show? They show flow of control between modules. Each module is invoked by the one above it and when completed returns to its caller. It is, therefore, subordinate to the module above it and superior to those below it. To draw an analogy with the organization chart, a module is called into action by its boss and reports back to the boss the outcome of its action. To complete that action, it may need to invoke one or more of its subordinate modules before it can report back.

Flow of control proceeds along the vertical lines connecting the modules in the hierarchy chart. This means that any module can invoke another module at a lower level and has control returned to it when the lower level module is completed. Here are some guidelines that will help ensure this vertical movement.

1. A module must return to its caller.

2. The same module may appear more than once in the hierarchy chart at the appropriate levels. (Of course, in the corresponding source program, a module is coded only once.) Reoccurring modules should be identified, typically with vertical lines ("stripes") added to the box, as illustrated below.
   

3. A module may call another module immediately below the level on which it appears; it may not call another module on the same or higher level. (However, a module may call itself, as in the case of recursive programming.) If, for example, module A needs to call module C in the following diagram, then module C can be shown as a reoccurring module:

4. Major decision making should be placed at as high a level as possible. Typically, the top module (root level) contains the main decisions of a program. The top module is a synopsis of the entire program.

The advantage of the hierarchy chart showing functional flow of control is that when it is time to modify a program, it is easier to determine the impact of a program change. For example, in the following chart,

The primary advantage of hierarchy charts, when used as a design and implementation tool, is that once modules have been defined in an hierarchical relationship, they can be coded and tested in a top-down manner. Coding and testing higher-level modules before lower level modules has the advantage of pointing out logic flaws sooner. When used as a documentation tool, hierarchy charts serve as a visual table of contents of a program, thus making reading a program much easier. Finally, as pointed out above, when changing a program, it is easier to pinpoint which modules must be modified if the hierarchy chart is available.