Flowcharts & Visual Algorithm Representation
Pseudocode & Algorithmic Problem-Solving
Chapter 3 · Flowcharts & Visual Algorithm Representation
A flowchart is a second notation for the exact same three building blocks Chapter 2 covered — sequence, selection, iteration — drawn instead of written. It isn't a replacement for pseudocode; it's an alternative view of the identical logic, useful in some situations and genuinely counterproductive in others.
Standard Flowchart Symbols
| Shape | Meaning | Corresponds to |
|---|---|---|
| Oval (terminal) | Start or end of the algorithm | The algorithm's own boundaries — not a pseudocode line at all |
| Parallelogram (I/O) | Input or output | READ / DISPLAY / RETURN |
| Rectangle (process) | A single computation or assignment | A sequence step, e.g. max_val ← list[0] |
| Diamond (decision) | A yes/no branch point | IF...THEN...ELSE |
| Arrow | Direction of flow — including looping back to an earlier point | WHILE/FOR's own repeat behavior |
Converting Pseudocode to a Flowchart — the Exact Same Algorithm as Chapter 2
Below is Chapter 2's own FindMax pseudocode, redrawn as a flowchart using only the five symbols above. Nothing about the underlying algorithm changed — only its notation.
Flowchart for FindMax(list) — every shape maps directly to one line of Chapter 2's own pseudocode
[3, 7, 2, 9, 4, 9, 1] — the exact same test list Chapter 2 used — step by step through every diamond and arrow: max_val starts at 3, updates to 7 at i=1, then to 9 at i=3, and never changes again (9 > 9 is false at i=5, matching strict-greater-than exactly). The flowchart outputs 9 — identical to Chapter 2's own verified pseudocode-and-Python result on the same input. Two different notations, traced independently, agree exactly.
When a Flowchart Helps
- Non-technical stakeholders — a shape-and-arrow diagram is often easier for someone who doesn't read code fluently to follow than the equivalent pseudocode
- A small number of branches — a handful of decision points renders as a compact, genuinely clarifying picture
- Spotting a missing case at a glance — an arrow that visibly goes nowhere, or a decision with no "else" path drawn, is often easier to notice in a diagram than scanning indentation in text
When a Flowchart Hurts — Demonstrated by the Diagram Above
FindMax pseudocode is seven lines long. Its flowchart above needed eleven shapes, a loop-back arrow routed all the way around the left side of the diagram, and careful spacing just to keep the arrows from crossing each other illegibly. This is the real, concrete version of a well-known critique of flowcharts: they don't scale. A loop that's a single line of pseudocode (WHILE...ENDWHILE) becomes a physically large loop-back arrow spanning the whole diagram — and a real algorithm with several nested loops and more than two or three decision points quickly turns into a tangle that's harder to follow than the pseudocode it was meant to clarify.
Flowcharts also handle two things this course will need soon particularly badly: recursion (a flowchart has no natural way to show a process "calling a smaller copy of itself," the subject of Chapter 9) and complex data structures (a single box like max_val ← list[0] hides everything about how list is actually organized — fine for a simple list, unworkable for a tree or graph).
Where This Connects
| This chapter's finding | What it sets up |
|---|---|
| Pseudocode and flowchart verified to represent identical logic | Confirms both notations are interchangeable views of the same design — Chapter 5's translation-to-real-code discipline applies equally to either starting point |
| The loop-back arrow's own visual size, demonstrated concretely | A direct, visual argument for why this course uses pseudocode as its primary notation from Chapter 4 onward, reserving flowcharts for the situations Chapter 3 identified they genuinely help |
| Flowcharts handling recursion poorly | Sets up Chapter 9's own recursive framing, which needs pseudocode's own call-based notation instead |
Hands-On Exercises
Using this chapter's own flowchart, hand-trace it on the list [5, 5, 5] and state the final output. Then explain, using this chapter's own decision-diamond wording (list[i] > max_val?, strictly greater than), why the output is correct even though every element is identical.
Using this chapter's own symbol table, draw (in words — describe each shape and its label in order) a simple three-shape flowchart for the pseudocode IF x < 0 THEN DISPLAY "negative" ELSE DISPLAY "non-negative" ENDIF, including a Start and End terminal.
Using this chapter's own "when a flowchart hurts" argument, explain why an algorithm with three nested loops (a loop inside a loop inside a loop) would be a particularly bad candidate for flowchart representation, connecting your answer to what happened to just one loop in this chapter's own FindMax diagram.
Chapter 3 Quick Reference
- Five standard symbols: oval (start/end), parallelogram (input/output), rectangle (process), diamond (decision), arrow (flow, including loop-back)
- Verified directly: hand-tracing the
FindMaxflowchart on the same test list Chapter 2 used produces the identical result,9— pseudocode and flowchart are interchangeable views of the same logic - Flowcharts help most for non-technical audiences, a small number of branches, and spotting a visibly missing case
- Verified concretely: seven lines of pseudocode required eleven shapes and a full-diagram loop-back arrow — flowcharts genuinely don't scale to larger algorithms, and handle recursion and complex data structures particularly badly
- Next chapter: Problem decomposition — breaking a large, ambiguous problem into the kind of small, well-defined subproblems this chapter's own single-block-per-step diagrams assumed from the start