Hierarchy charts help visualise a program’s structure by breaking it down into manageable modules, clarifying relationships between tasks and aiding in effective planning.
What is a hierarchy chart?
A hierarchy chart, also called a structure chart, is a diagram used in the design phase of a program to represent how the overall task is divided into smaller, more manageable parts. It provides a top-down overview of the system and visually outlines how major tasks are decomposed into subtasks or modules.
The main goal of a hierarchy chart is to reflect the modular structure of a program. This structure helps programmers and designers understand how each component of a system relates to the others. Instead of focusing on the sequence of operations, a hierarchy chart focuses on organisation and relationships between different parts of a program.
Each box or rectangle in the chart represents a module or procedure, and lines connect these boxes to show how tasks are broken down. The chart starts with the main program at the top and shows its various subcomponents below, branching out in layers. This helps developers see the “big picture” of the system they are building.
Hierarchy charts are not intended to show the details of what happens inside each module. Instead, they show how the different parts fit together, which is especially useful during the planning stage of program development.
Purpose of hierarchy charts
Hierarchy charts serve several essential functions in the development of software systems. Their purpose is not to guide the implementation of algorithms or show control flow, but to offer a conceptual map of a program’s architecture. This visual organisation supports efficient planning, collaboration, and future maintenance of code.
Visualising program structure
Hierarchy charts are particularly helpful for visualising the structural layout of a program. They offer a clear and concise representation of the way a program is broken down into its constituent modules. This top-down visualisation makes complex programs easier to understand and manage, especially when there are multiple levels of tasks involved.
Clarifying module responsibilities
Each module shown in a hierarchy chart typically represents a self-contained function or procedure with a specific responsibility. By identifying each module and its relationship to others, a hierarchy chart clarifies what each part of the program is supposed to do. This clarity aids in avoiding duplication of effort and ensures that each part of the system has a well-defined role.
Supporting top-down design
In procedural programming, developers often use a top-down design approach, where the main task is broken down into subtasks, and those are further refined into even smaller tasks. Hierarchy charts naturally support this method, allowing developers to move from general concepts to specific procedures systematically.
Enhancing communication and collaboration
For team-based development, hierarchy charts act as a communication tool, helping team members understand how different parts of a project interconnect. This shared understanding improves collaboration by making it clear who is responsible for which module and how those modules relate to others.
Aiding in planning and maintenance
Hierarchy charts play a valuable role in both initial planning and ongoing maintenance. During development, they help programmers plan how to divide work and develop modules independently. Later, when changes are required, the chart helps identify where updates are needed and how they might affect the rest of the system.
Structure and features of a hierarchy chart
Hierarchy charts follow a specific structure that helps standardise their use and maximise clarity. While their appearance is quite simple, their design reflects important programming concepts.
Basic elements
Top-level module: The main task or control program sits at the top of the chart. It may be called "Main Program" or "Main Module".
Child modules: These are the submodules called by the top-level module. Each child module represents a specific task or part of the larger task.
Connector lines: These lines show which modules are subordinate to others, indicating the calling relationship.
No decision points or loops: Unlike flowcharts, hierarchy charts do not show logical decisions, conditions, or loops.
Organisational principles
Top-down layout: The main module is always at the top, with submodules arranged below. Each level shows increasing levels of detail.
Single direction: The flow is always downwards. There are no arrows—the vertical arrangement indicates control or ownership.
No data flow or control flow: The chart shows structure only, not the flow of data or the sequence of operations.
Hierarchy charts emphasise structure over logic. They provide an outline of what will be done and how tasks are grouped, but not the internal logic of each module.
Differences between hierarchy charts and flowcharts
Although hierarchy charts and flowcharts may appear similar at first glance, they serve very different purposes in program design. Flowcharts are used to model process flow—they show how a program behaves step-by-step. In contrast, hierarchy charts model modular structure, showing how the program is divided into components.
Key distinctions
Purpose:
Hierarchy charts are for structure and modular design.
Flowcharts are for control logic and algorithm flow.
Representation:
Hierarchy charts use rectangles and lines only.
Flowcharts use multiple shapes—rectangles for processes, diamonds for decisions, ovals for start/end points.
Flow direction:
Hierarchy charts always go top-down.
Flowcharts may go in multiple directions depending on conditions and logic.
Contents:
Hierarchy charts do not show loops, decisions, or sequence.
Flowcharts show exact flow of execution, including conditions and branches.
Use case:
Hierarchy charts are used during program planning.
Flowcharts are used during algorithm design or code explanation.
Both tools are useful, but they should be used in complementary ways. A hierarchy chart helps plan the structure, while a flowchart helps develop the logic of each module.
Example: Input-validation-output cycle
To understand how a hierarchy chart can be applied, let’s consider a simple program involving an input-validation-output cycle. This kind of task is common in many applications, from user forms to data processing tools.
Top-level breakdown
Main Program
→ Get Input
→ Validate Input
→ Process Input
→ Output Results
Each of these primary modules can be further broken down:
Get Input
Prompt User
Read User Input
Validate Input
Check Data Type
Check Value Range
Return Validity Status
Process Input
Perform Calculations
Format Data
Output Results
Display Output
Log Output to File
Visualising the hierarchy
In a hierarchy chart, the main program would be shown at the top. It would branch down to four major modules: Get Input, Validate Input, Process Input, and Output Results. Each of those modules would then branch again to show their individual subtasks.
This chart does not show how the input is processed or the details of validation checks. It only shows that these tasks exist as part of the structure and how they are related.
Such a representation makes it easier for a team of developers to divide responsibilities, test individual modules, and maintain the system efficiently.
Constructing hierarchy charts: guidelines
Building a hierarchy chart is a straightforward task if done with clear goals and consistency. The following guidelines help ensure the chart is useful and effective.
Keep it modular
Break down the program into logically distinct tasks.
Ensure each module has a single responsibility.
Use meaningful names
Module names should be descriptive and concise.
Avoid vague terms like "Stuff" or "Thing"—prefer names like "CheckInputRange" or "CalculateTotal".
Maintain a clear hierarchy
Don’t overcomplicate the structure.
Stick to a maximum of 5–7 submodules per parent where possible.
If more are needed, group them into intermediate modules.
Avoid implementation details
Do not include variable names, control structures, or data types.
Focus on structure, not on how things are done.
Review and revise
As the program design evolves, update the hierarchy chart.
Ensure it always reflects the current design accurately.
Benefits of hierarchy charts in program planning and documentation
Hierarchy charts offer numerous advantages in both initial program design and ongoing documentation.
Improved clarity
Offers a bird’s eye view of the system.
Helps understand what the system does without diving into code.
Easier debugging and testing
Bugs can be isolated by identifying the module in which the fault likely lies.
Testing can be done on individual modules independently.
Reusability
Well-structured modules are easier to reuse in other programs.
Promotes the use of libraries and utility functions.
Better collaboration
Different team members can work on separate modules without conflict.
Clarifies module ownership and interdependencies.
Effective documentation
Serves as a reference for future maintenance.
Helps explain system structure to new developers or stakeholders.
Supports scalability
New features can be added by extending the chart, creating new modules that slot into existing structure.
Prevents a program from becoming a monolithic block of code, making future changes manageable.
Real-world examples of usage
Hierarchy charts are used in various fields and industries where structured programming and modular design are critical.
In educational systems
For example, an online learning system may have a top-level module called “LearningPlatform” branching into modules such as:
AuthenticateUser
DisplayContent
TrackProgress
AssessStudent
GenerateReport
Each of these modules can be further decomposed into submodules, making the system easier to design, test, and maintain.
In payroll software
A payroll processing system might start with “ProcessPayroll” at the top, leading to:
RetrieveEmployeeData
CalculateGrossPay
DeductTaxes
GeneratePayslip
This approach ensures clarity and allows different developers to work on tax deduction logic, data input, and payslip formatting independently.
In scientific simulations
Complex scientific software often includes modules like:
InitialiseSimulation
LoadParameters
RunModel
OutputResults
AnalyseData
Using hierarchy charts in such cases ensures the project can be built and maintained by teams with clearly defined responsibilities.
FAQ
Yes, hierarchy charts are very useful during the maintenance phase of a program. Although they are primarily created during the design stage, their value continues well into later stages of software development. When developers revisit existing code for updates, debugging, or adding new features, hierarchy charts provide a quick reference for understanding the overall structure and how modules relate to one another. This is particularly beneficial in large codebases or when the original developers are no longer involved. By examining the chart, a maintainer can identify which module a feature or bug belongs to and assess how changes may impact other parts of the system. This minimises the risk of unintended side effects and saves time otherwise spent navigating unfamiliar code. Additionally, if a hierarchy chart is kept up to date alongside development, it forms an integral part of technical documentation, aiding future revisions, audits, or even migration to new systems.
Hierarchy charts and class diagrams serve different purposes and are used in different programming paradigms. Hierarchy charts are specific to procedural programming and focus on breaking down a program into procedures or functions. They depict how tasks are divided and structured in a top-down manner, showing which modules are responsible for which operations, without representing data or relationships between data entities. In contrast, class diagrams are a core part of object-oriented programming and are used to model the relationships between classes, including inheritance, composition, and association. Class diagrams focus on data—specifically, the attributes and methods of objects, and how they relate to one another in terms of structure and hierarchy. While hierarchy charts emphasise procedural decomposition, class diagrams emphasise object structure and inter-object relationships. Therefore, they are not interchangeable and are suited to fundamentally different approaches to program design. Each supports its respective paradigm’s strengths—modular functionality for procedural, and encapsulated objects for object-oriented.
Yes, hierarchy charts can and often should include error-handling modules, especially when they are treated as distinct and reusable components within the program. However, because hierarchy charts represent structure rather than control or decision flow, error-handling modules should be represented like any other module, provided they are explicitly invoked during normal operation. For example, a submodule like “ValidateInput” might call an “ErrorHandler” module if validation fails. In this case, “ErrorHandler” would be represented as a subordinate module in the chart. The chart would not show the conditions or exceptions that trigger this module—that level of detail is left to flowcharts or pseudocode. The important consideration is whether error handling is modularised; if so, it should be included in the hierarchy. Representing these modules helps with clarity and planning, ensures consistency across different parts of the program, and supports separation of concerns, making it easier to isolate and improve error-handling logic during development or maintenance.
In some cases, yes—hierarchy charts can be generated automatically from source code using specialised tools, particularly in languages or environments that support structured or modular programming. These tools analyse the call relationships between functions or procedures and then visualise those relationships in a format similar to a hierarchy chart. However, automatically generated charts may not be identical to manually designed ones. They often lack the abstraction and clarity provided by human designers, especially if the program contains nested or complex logic. Additionally, auto-generated charts may include implementation-specific modules or utility functions that clutter the diagram and obscure the broader structure. Therefore, while such tools are useful for understanding existing systems, especially during code reviews or audits, manually created hierarchy charts are generally better for the planning and design stages. These hand-drawn charts focus on logical structure and functional decomposition rather than literal function calls, providing a clearer blueprint for development.
The level of detail in a hierarchy chart for a large-scale project should strike a balance between clarity and completeness. It is important not to overwhelm the chart with every minor function or utility routine, as this would make it difficult to read and reduce its usefulness. Instead, the chart should focus on the main program modules and their primary submodules, going down only a few levels deep. If greater detail is necessary, the hierarchy chart can be broken into separate layers or modular segments, each focusing on a specific area of functionality. For example, one section may cover user authentication, while another details report generation. These modular charts can then be linked together conceptually, maintaining overall clarity while allowing room for deeper inspection. Each module shown in the chart should represent a meaningful and distinct task. Overuse of nesting or too many sibling modules at the same level should be avoided, as this can indicate poor modular design and make the chart harder to maintain.
Practice Questions
Explain the purpose of a hierarchy chart in the context of structured programming. Illustrate your answer with a relevant example.
A hierarchy chart visually represents the modular structure of a program, showing how a larger task is divided into smaller, manageable submodules. Its purpose is to support top-down design by identifying each module’s role in the system, improving clarity, planning, and team collaboration. For example, in a payroll system, the top module may be "ProcessPayroll" with submodules such as "CalculateGrossPay", "DeductTax", and "GeneratePayslip". This approach improves readability, testing, and maintainability by isolating tasks and reducing complexity. It also helps with reusability, as each module can be developed and reused independently in other contexts.
Describe two differences between a hierarchy chart and a flowchart, and explain why a programmer might choose to use a hierarchy chart instead.
A hierarchy chart shows the structural organisation of a program, focusing on modular decomposition, while a flowchart illustrates the control flow and logic of processes using decision paths and loops. Secondly, hierarchy charts use only boxes and connectors in a top-down format without representing execution order, whereas flowcharts use multiple symbols to show sequential and branching logic. A programmer may choose a hierarchy chart when planning the overall structure of a program, especially in larger projects, as it helps in assigning responsibilities, improving collaboration, and ensuring a clear separation of tasks without getting into implementation details too early.
