Systematic Approach to Problem Solving
Once a systematic approach has defined the logic, it must be documented using either Flowcharts or Pseudocode.
| Feature | Flowcharts | Pseudocode |
|---|---|---|
| Format | Visual/Graphical using standard symbols | Text-based using structured English |
| Best For | Visualizing logic flow and decision paths | Mapping logic closely to actual code |
| Complexity | Can become cluttered for large systems | Scales well for complex logic and loops |
Flowcharts use specific shapes: Ovals for Start/Stop, Rectangles for Processes, Diamonds for Decisions, and Parallelograms for Input/Output.
Trace the Logic: When presented with an algorithm, always use a trace table to track variable values step-by-step. This helps identify 'off-by-one' errors in loops.
Refinement is Key: Examiners often ask you to 'refine' an algorithm. This usually means adding more detail, such as including a user's name in an output or adding a validation check to an input.
Check the Bounds: Always verify the start and end conditions of your systematic searches. For example, ensure a search through a list starts at index 0 and ends at the final element without going out of bounds.
Ignoring Abstraction: A common mistake is including too much detail (like the color of a UI button) in the algorithm logic. This makes the algorithm harder to read and implement.
Confusing Decomposition with Sequencing: Decomposition is about breaking the problem into parts, while sequencing is about the order of steps. You must decompose the problem before you can determine the correct sequence.
Missing the 'Stop' Condition: In systematic approaches like searching, failing to define what happens if an item is not found leads to infinite loops or logical crashes.