Computer Science (9645) | Structured approach to programming

Hello future Computer Scientist! This chapter is super important. We are moving away from just writing code, and learning how to *design* programs like professional software engineers. The "Structured Approach" is the fundamental technique for building large, reliable, and understandable software. Think of it as organizing your coding toolkit so you can build skyscrapers, not just simple sheds!

Don't worry if these terms sound formal; we'll break them down using simple examples.

3.3.1 The Structured Approach to Programming

The structured approach is a program design philosophy. It means we build programs using a limited set of logical control structures (like selection and iteration) and, most importantly, by breaking the program down into smaller, self-contained blocks.

Key Concepts Underlying Structured Design

Two essential concepts from the Program Design section help us use the structured approach effectively:

1. Decomposition (Syllabus 3.3.2)
Analogy: Preparing a large meal.

Decomposition is the process of breaking a complex problem down into a number of smaller, more manageable sub-problems (or tasks). Each sub-problem should perform an identifiable, specific task. In programming, these tasks are typically implemented using subroutines.

2. Abstraction (Syllabus 3.3.2)
Analogy: Using a remote control.

Abstraction is about removing unnecessary details from a problem to facilitate its solution. When writing a subroutine, you only need to know what it does, not necessarily how it performs every internal calculation. This simplifies the larger program structure.

3.3.1.1 Modularised Programming

Modularised programming is the practical application of decomposition. Instead of writing one giant block of code, we create separate, reusable blocks called modules or subroutines (procedures or functions).

A subroutine is a named 'out of line' block of code that can be executed (called) by simply writing its name in a program statement (Syllabus 3.1.2.7).

Advantages of Modularisation

• Easier to Debug: If a program fails, you know the error is contained within a specific small module, making it easier to isolate and fix.
• Reusability: Once a module is written (e.g., a function to calculate tax), it can be used many times in the same program or even in entirely different programs.
• Maintainability: If requirements change, you only need to update one specific module, without altering the rest of the system.
• Teamwork: Multiple programmers can work on different modules simultaneously, speeding up development.

3.3.1.2 Controlling Flow and Data: Parameters and Scope

For modules to work together effectively in a structured way, we need strict rules about how they exchange data and how variables are managed.

A. Parameters and Return Values

Modules use parameters to receive input data from the calling routine and return values to send back results.

• Parameters: Data passed into the subroutine when it is called.
• Return Values: Data calculated by the subroutine and sent back to the routine that called it.

Example: If you have a module called CalculateArea, the parameters might be (Length, Width), and the return value would be Area.

B. The Use of Local and Global Variables

The concept of scope defines where a variable can be accessed or modified within a program. Controlling scope is essential for structure, as it prevents modules from accidentally interfering with each other's data.

1. Global Variables (Syllabus 3.1.2.7)

• Definition: Variables declared outside of any subroutine that are accessible and changeable throughout the entire program.
• Risk: If multiple modules can change a global variable, it becomes very difficult to trace *why* and *when* an unexpected value occurs. This is bad structure!

2. Local Variables (Syllabus 3.1.2.7)

• Definition: Variables declared within a specific subroutine (or block of code).
• Accessibility: They are accessible only while the subroutine is executing and accessible only within the subroutine.
• Advantage (Good Practice): Limiting the scope of a variable to the local level is good practice. It ensures that the actions inside one module do not have unintended side effects on other parts of the program.

Did you know?
Local variables "die" once the subroutine finishes running, freeing up memory. Global variables exist until the entire program terminates.

3.3.1.3 Designing the Structure: Hierarchy and Structure Charts

When using the structured approach, we need tools to visualize the decomposition and relationships between modules before we write code. This is where charts come in.

A. Hierarchy Charts

A Hierarchy Chart (or H-Chart) shows the relationship between modules in a program in a top-down manner. It shows who calls whom.

• The topmost box represents the main program.
• Each level below shows the sub-modules that are called by the module above them.
• They focus purely on control flow (the order of execution).

Analogy: A company's organizational chart. The CEO (Main Program) delegates tasks to managers (Module A, Module B), who delegate to staff (Sub-modules).

B. Structure Charts

Structure Charts are more detailed than Hierarchy Charts. They show not only the control flow (who calls whom), but also the data flow between the modules.

• They use arrows with labels to indicate which data (parameters and return values) are passed between modules.
• These charts help designers ensure that modules are truly independent and only communicate via defined interfaces (parameters).

Key Takeaway for Design Charts:
Hierarchy charts show the modular breakdown and control. Structure charts add detail about the specific data being exchanged between those modules.