Flowcharts

Drawing an Algorithm

A flowchart is a diagram of an algorithm. Instead of a list of steps, you draw symbols connected by arrows — and the algorithm's whole logic becomes visible at a glance.

Flowcharts need no programming language. They are how engineers, doctors, and designers all sketch out processes — from apps to emergency procedures.

The Symbols

Three rules keep flowcharts correct:

1. Exactly one START
2. Every decision diamond has exactly two exits, labelled YES and NO
3. Every path eventually reaches an END (unless a loop is meant to continue)

A Complete Example

Deciding whether a number is big or small:

        ┌─────────┐
        │  START  │
        └────┬────┘
             ▼
      ┌─────────────┐
     ╱ INPUT number ╱
    └───────┬───────┘
            ▼
      ┌───────────┐
      │ Is number │ NO
      │  > 100?   │─────────┐
      └─────┬─────┘         │
            │ YES           ▼
            ▼        ┌─────────────┐
     ┌───────────┐  ╱ OUTPUT      ╱
    ╱ OUTPUT     ╱  │  "Small"    │
    │  "Big"     │  └──────┬──────┘
    └─────┬──────┘         │
          ▼                ▼
        ┌─────────────────────┐
        │         END         │
        └─────────────────────┘

Trace it with input 42: START → input 42 → is 42 > 100? NO → output "Small" → END. Tracing a flowchart with a specific value is the standard way to test it — and a favourite exam question.

Decisions and Loops in Flowcharts

The diamond is where selection lives: one question, two exits.

A loop appears when an arrow points back to an earlier symbol:

   ┌────►┌──────────────┐
   │     │ Ask password │
   │     └──────┬───────┘
   │            ▼
   │     ┌──────────────┐
   │  NO │   Correct?   │
   └─────│              │
         └──────┬───────┘
                │ YES
                ▼
         ┌──────────────┐
         │ Unlock phone │
         └──────────────┘

"Ask, check, ask again until correct" — a condition-controlled loop, visible as a circuit in the diagram.

Why Flowcharts Beat Text

• Missing cases jump out — a diamond with only a YES arrow is an obvious bug
• Dead ends are visible — a path that never reaches END means trouble
• Anyone can read them — teammates, teachers, and non-programmers included

Many programmers sketch a flowchart before writing any code, and debug by tracing their flowchart with the exact input that caused a problem.

Worked Example — A Vending Machine

Design a flowchart for a vending machine that checks whether enough money has been inserted before dispensing a snack:

START → INPUT moneyInserted → INPUT itemPrice
  → Is moneyInserted >= itemPrice?
       YES → Dispense item → Calculate change
             → Is change > 0? 
                  YES → Return change → END
                  NO  → END
       NO  → OUTPUT "Insufficient funds" → Return moneyInserted → END

Notice how this flowchart has two decision diamonds, not one — a decision inside a branch of another decision. This is nesting, and flowcharts make it easy to see: the "change > 0?" diamond only exists inside the YES branch of the first diamond, because change is meaningless until the item has actually been dispensed. If you tried to write this as a plain numbered list instead, the nested structure would be far easier to lose track of — which is exactly why flowcharts are drawn before code, on paper or a whiteboard, while the logic is still being worked out.

From Flowchart to Pseudocode

Flowcharts and pseudocode describe the same logic in two different notations — a diagram versus text — and translating between them is good practice for reading either one fluently. The vending machine flowchart above becomes:

INPUT moneyInserted
INPUT itemPrice
IF moneyInserted >= itemPrice THEN
    dispense item
    change ← moneyInserted - itemPrice
    IF change > 0 THEN
        return change
    ENDIF
ELSE
    OUTPUT "Insufficient funds"
    return moneyInserted
ENDIF

Every diamond became an IF; every rectangle became a line of pseudocode; the arrows became the order the lines are written in. Once you can translate confidently in both directions, you can choose whichever notation suits the moment — a flowchart for planning and communicating with non-programmers, pseudocode for something closer to real code.

Key Words

• Flowchart — a diagram of an algorithm using symbols and arrows
• Terminator — rounded box marking START or END
• Process — rectangle holding an action step
• Decision — diamond holding a yes/no question with two exits
• Trace — following the flow with a specific input to check the logic