Design Tools, Structured Programming, and Algorithm Documentation

Design Tools Overview

• Programming design commonly employs three complementary visual/textual aids:
  • Flow Chart
  • Best for small, self-contained problems or as the visual for a single module inside a larger system.
  • Pseudocode
  • Hybrid of plain English + program logic.
  • Goal: describe, in precise algorithmic detail, the required behaviour before coding.
  • Uses only the fundamental control-flow constructs: sequence → selection → iteration.
  • Structure Chart
  • Recommended once the problem grows beyond a single algorithm.
  • Depicts execution flow at a functional (module) level, replacing very large flow charts.

Flow Charts

• Visual, node-and-arrow diagram of control flow.
• Advantages for beginners
  • Immediate perceptual feedback.
  • Errors or omissions in branching/loops are easy to spot.
• Core symbols (common convention):
  • Terminator (oval) → START/STOP.
  • Process (rectangle) → statements/assignments.
  • Decision (diamond) → Boolean test leading to labelled TRUE/FALSE branches.
  • Connector (circle) → jump continuation when diagram spans pages.
• Example snippet (from slide 7):
  • START → initialise $oneEven \leftarrow false,\; i \leftarrow 0$.
  • WHILE i < n \;\text{AND}\; oneEven = false.
  • Decision: “ary[i] is even?” → if TRUE set $oneEven \leftarrow true$.
  • Increment $i \leftarrow i+1$.
  • RETURN $oneEven$.

Pseudocode

• More prevalent among professional programmers.
• Can be typed, version-controlled, merged into documentation.
• Recommended style elements (see recurring checklist slides 12, 14, 16, 18, 21, 23, 26):
  • Algorithm Header.
  • Purpose statement.
  • Pre-conditions / Post-conditions.
  • Return value description.
  • Statement numbers (optional – aid traceability).
  • Explicit mention of control constructs (Sequence / Selection / Loop) instead of hidden jumps.
  • Variable glossary.
  • Algorithm analysis (time/space complexity).
  • Companion structure diagrams when multiple modules cooperate.
• Pre/Post example (slide 11):
  • Pre: $ary$ – non-empty integer array; $n$ – current logical size.
  • Post: function returns true if any element is even, else false.

Structure Charts

• Hierarchical, top-down depiction of modules not individual statements.
• Oriented toward functional decomposition (Who calls whom?).
• Example (slide 28):
  • main
  • readList
  • checkEven
  • printResult
• Beneficial when codebase contains dozens/hundreds of separate functions.

Example Problem: “Is There an Even in the List?”

• Data set previewed on slides (indexes 0–7, values 5 7 3 9 10 13 8 1).
• Required: Algorithm returns true if at least ONE element is even.

Straightforward pseudocode (slide 9)

Algorithm checkEven (ary, n)
    oneEven = false
    i = 0
    loop (i < n AND oneEven is false)
        if (ary[i] is even)
            oneEven = true
        end if
        i = i + 1
    end loop
    return oneEven
end checkEven

• Key points
  • Early exit once flag becomes true (short-circuit evaluation in loop guard).
  • Flag variable makes the intent explicit; alternative is direct return inside loop.

Multiple C-like implementations (slides 30–32)

1. Immediate return upon first even:

for(i = 0; i < n; i++)
    if(ary[i] % 2 == 0)
        return 1;
return 0;

2. Maintain flag, do not short-circuit loop:

oneEven = 0;
for(i = 0; i < n; i++)
    if(!(ary[i] % 2))
        oneEven = 1;
return oneEven;

3. Combine flag with loop guard to avoid unnecessary iterations:

for(i = 0; i < n && !oneEven; i++)
    if(!(ary[i] % 2))
        oneEven = 1;
return oneEven;

Complexity analysis

• Loop touches each element at most once.
• Number of primitive operations proportional to $n$ → $O(n)$ time.
• Constant auxiliary space → $O(1)$ space.

Structured Programming Foundations

• 1966: Böhm & Jacopini Theorem – any algorithm can be expressed using only three control constructs:
  1. Sequence (straight-line code).
  2. Selection (if/else).
  3. Iteration (pre/post-tested loops).
• 1968: Edsger Dijkstra wrote “Go To Statement Considered Harmful”, popularising structured programming and discouraging unstructured jumps (goto, break, continue in their unrestricted forms).
• Slides 19–20 show refactoring raw jumps into explicit IF and WHILE constructs.

Algorithm Efficiency & Big-O Notation

• Efficiency modelled as a function $f(n)$ of problem size $n$.
• Big-O gives an upper bound ignoring lower-order terms / constants.
• Example from slide 25 (slightly garbled):
  • Raw count: $f(n) = \frac{n(n+1)}{2}$ operations.
  • Asymptotic classification: $f(n) \in O(n^2)$.
• For the checkEven algorithm: $f(n) = n$ → $O(n)$.

Documentation Checklist Revisited

• Ensure every algorithm write-up includes:
  • Header: name + parameter list.
  • Purpose: one-sentence summary.
  • Pre-conditions: what must be true before call.
  • Post-conditions: what will be true after call.
  • Return: meaning + type.
  • Variables: role / units / ranges.
  • Statement numbers (for educational tracing only).
  • Construct tags (sequence / selection / loop) demonstrating structured style.
  • Analysis: expected complexity.
  • Structure diagrams if part of multi-module system.

Additional Flow-Chart Example (Daily Routine)

• Nodes: Leave home → Check time? → If before 7 am ⇒ Take bus, else ⇒ Take subway → Reach school.
• Illustrates simple selection followed by sequence; no loop.

More Granular Pseudocode Samples (Book “Data Structures: A Pseudocode Approach with C”)

• Algorithm 1-1 sample(pageNumber)
  • Reads file, paginates report, increments counters for lines & pages.
  • Nested loop + if combination; pageNumber passed by reference.
• Algorithm 1-2 deviation
  • Reads series of numbers, computes average, then prints each value alongside deviation: $devFromAve = value - average$.
  • Demonstrates two loops: input accumulation, then output.

Granular Structure Chart Example (C++ text, slide 36)

• Highlights best practice: begin decomposition at top-level module, then recursively expand one module at a time into sub-tasks until each box represents a well-defined responsibility.

Practical / Ethical Implications

• Legibility & Maintenance: Investing time in the design artefacts (pseudocode, flow charts, structure charts) reduces defects and onboarding cost.
• Pedagogical Value: Visual aids lower cognitive load for novices, but senior teams often skip flow charts in favour of written specs & unit tests.
• Repeatability: Formal Pre/Post contracts facilitate automated verification and testing frameworks.
• Historical Perspective: Understanding why ‘goto’ was criticised helps modern developers appreciate disciplined control flow, even when languages allow early exits (break/continue) sparingly.

Key Takeaways

• Mastery of three design tools (Flow Chart, Pseudocode, Structure Chart) provides complementary perspectives: control flow, textual precision, and modular architecture.
• Adhering to structured programming (sequence/selection/loop) yields code that is provably equivalent to any algorithm that could be written with arbitrary jumps.
• Always annotate algorithms with purpose, contracts, and complexity; clarity during design saves orders of magnitude in maintenance later.