The Problem-Solving Lesson

~60–90 min · one worked example throughout · ← Module home

This lesson teaches all twenty fundamentals by using them, once, on a single problem — so you see how the ideas connect instead of memorising twenty disconnected definitions. After the lesson, the 20 scenarios let you run the method yourself (remember the Try It Yourself protocol).

Our running problem. A university cafeteria prints a daily bill: samosas cost 25 rupees each, chai 15 a cup. For every order, the cashier enters how many samosas and how many cups, and the till prints a tidy bill. A 5% service charge is added if the total reaches 500 or more. How do we get from that paragraph to a working C++ program?

Follow the sections in order — each one is a tool, and the tools build.

Table of contents

1–3. Problems, decomposition, IPO · 4–7. Inputs, processing, outputs, requirements, assumptions, constraints · 8–10. Algorithms · 11. Pseudocode · 12. Flowcharts · 13. Decision making · 14. Repetition · 15–16. Dry runs and trace tables · 17–18. Test cases and edge cases · 19. Common mistakes · 20. Translating into C++ · Glossary of the module

1–3. What is a computational problem, decomposition, and the IPO shape

1. What is a computational problem?

A computational problem is any task that can be solved by computing — taking some information, transforming it by precise rules, and producing an answer. Not every problem is computational: “cheer up your friend” isn’t. “Work out what 12 samosas and 5 chais cost” is — information goes in, arithmetic happens, an answer comes out.

The first skill is spotting the difference. Clues that a problem is computational:

• it talks about quantities (how many, how much, how often)
• it has rules that always work the same way (“5% charge at 500 or more”)
• a definite answer exists (a number, a yes/no, a category)

The cafeteria problem is computational because the rules are fixed. If the manager gave discretionary discounts (“be generous if the customer looks hungry”), no computer could follow it — computers need rules, not vibes.

2. Problem decomposition

Real problems arrive as a blob: “print a bill.” Too big to solve in one glance. Decomposition is cutting the blob into pieces small enough to solve immediately — the single most-used skill in programming, used at every scale from a homework exercise to an operating system.

Decompose the cafeteria problem by asking “what must happen, in order?”

"Print a bill"
  ├─ 1. Find out how many samosas and how many cups of chai.
  ├─ 2. Work out the food cost:        samosas × 25
  ├─ 3. Work out the chai cost:        cups × 15
  ├─ 4. Add them:                      subtotal
  ├─ 5. Decide the service charge:     5% of subtotal, but only if subtotal ≥ 500
  ├─ 6. Total:                         subtotal + service
  └─ 7. Print it all neatly.

Seven steps — each one small enough to do instantly. That feeling of “oh, each of those is easy” is the whole reward of decomposition. (If any step still feels big, decompose it — steps may have sub-steps.)

3. The IPO shape

Nearly every program you write this year has three beats — Input → Processing → Output (IPO). It is worth drawing as a picture, because every scenario in this module is first analysed as this box:

            ┌─────────────────────────────┐
  INPUT ──▶ │  PROCESSING                 │ ──▶ OUTPUT
            │  (the rules, step by step)  │
            └─────────────────────────────┘

Here is the key habit: nailing I and O before writing any P. Inputs and outputs are observable — you can test them. Processing is the engine between. Students who start typing “the processing” usually discover halfway that they were solving a slightly different problem; students who write I and O first always know when they’re done.

4–7. Inputs, processing, outputs, requirements, assumptions, constraints

These six words are the vocabulary of understanding the problem precisely — before any algorithm exists.

4. Inputs

The data your solution consumes, decided in advance:

Two early lessons hide here. First, kind matters: quantities of items are whole numbers — you cannot sell 2.5 samosas. Second, inputs have ranges: the till should not be asked for −3 samosas. Noticing that now is cheaper than crashing later.

5. Processing

The rules that transform inputs into outputs, stated so precisely that two different people following them get the same bill:

food   = samosas × 25
chai   = cups × 15
subtotal = food + chai
service  = 0.05 × subtotal   — but only when subtotal ≥ 500, else 0
total    = subtotal + service

If any rule feels ambiguous (“what if it’s exactly 500?” — included, the statement says reaches), this is the moment to notice, not after coding.

6. Outputs

The bill itself, drawn before coding — a target to aim at:

==== CAFETERIA BILL ====
Samosas x 3   :  75
Chai    x 2   :  30
------------------------
Subtotal      : 105
Service (5%)  :   0
------------------------
TOTAL         : 105
========================

7. Requirements, assumptions, constraints

Three different kinds of statement about the problem — keeping them apart prevents real bugs:

Why the fuss? Because mistakes hide in the seams. A program is “wrong” only relative to requirements; it is fragile when assumptions go unspoken (“I assumed nobody types negative numbers”); it is rejected when a constraint is violated (“we said the bill shows whole rupees”). Writing down your assumptions is the cheapest debugging there is — you do it before the bug exists.

8–10. Algorithms

8. What an algorithm is

An algorithm is a finite sequence of precise steps that solves the problem — the decomposition, tightened until it is executable. A recipe is an algorithm; so is long division; so is this:

1. Read samosaCount.
2. Read chaiCount.
3. food     ← samosaCount × 25
4. chaiCost ← chaiCount × 15
5. subtotal ← food + chaiCost
6. If subtotal ≥ 500:  service ← 0.05 × subtotal
   Else:               service ← 0
7. total ← subtotal + service
8. Print the bill lines.
9. Stop.

What makes this an algorithm and not just “a plan”: finiteness (it ends), definiteness (each step is unambiguous), inputs and outputs (defined above), and effectiveness (each step is doable by the machine). The arrow ← means “store into” — step 3 computes 3 × 25 and stores it in food.

9. Where algorithms come from

Not from thin air — from patterns you already know. This course leans on a small set that covers nearly everything:

Recognising which pattern a problem needs is most of the intellectual work — and it happens on paper, before C++ exists.

10. Step-by-step thinking

The final ingredient of algorithm design is a discipline: state steps so dumb that a machine could follow them — then improve them. Test your draft algorithm the way a machine would: take example inputs and execute the steps literally. Step 6 on a subtotal of 500: the If says reaches 500 or more, so service is charged. On 499? Not charged. The algorithm already answers the ambiguity — because the steps are precise. That habit — executing your own plan before coding it — is the difference between students who debug for hours and students who debug for minutes.

11. Pseudocode

Pseudocode is the algorithm written in structured English — half human, half program. It uses sequence, selection, repetition keywords but no language-specific punctuation; there are no official rules, only house style. This course’s conventions:

The cafeteria algorithm in §8 is the pseudocode. Why bother, when C++ is next? Because pseudocode is cheap to change and language-free: you fix the logic while it costs nothing, and you can hand it to a C++, Python, or Java programmer — all would write the same program. Rule of thumb for beginners: no pseudocode, no code. (In the scenarios, every solution shows pseudocode first — but per the Try It Yourself protocol, you write yours first.)

12. Flowcharts

A flowchart draws the algorithm — boxes for actions, diamonds for decisions, arrows for the order. Two symbols carry this whole course:

   ┌─────────┐
   │  START  │
   └────┬────┘
        ▼
 ┌──────────────┐      ┌───────────────┐
 │ READ samosas │      │  (then chais, │
 │      & chais │      │  costs, total)│
 └──────┬───────┘      └───────┬───────┘
        ▼                      ▼
      ╱╲ subtotal ≥ 500? ╲
     ╱  ╲                 ╲
  YES▼    ▼NO
   ┌──────────────┐   ┌──────────────┐
   │service ← 5%  │   │service ← 0   │
   └──────┬───────┘   └──────┬───────┘
          └───────┬──────────┘
                  ▼
          ┌──────────────┐
          │ PRINT bill   │
          └──────┬───────┘
                 ▼
             ┌───────┐
             │ STOP  │
             └───────┘

Use flowcharts the way professionals do: to see structure at a glance — especially where decisions branch and rejoin. Long sequences are clearer as pseudocode; two-way choices are often clearer as a diamond. You’ll never be asked to be an artist — boxes and arrows on paper are the standard tool.

13. Decision making

Decisions give algorithms their intelligence — the same steps behave differently depending on the data. A decision has three parts:

1. a condition — a yes/no question (subtotal ≥ 500)
2. a then-branch — what to do when yes
3. an else-branch — what to do when no (sometimes empty)

Cafeteria pseudocode:

IF subtotal ≥ 500 THEN
    service ← 0.05 × subtotal
ELSE
    service ← 0
ENDIF

Two beginner traps, named now so Unit 04 can defeat them:

• Boundary logic. Is 500 charged? The requirement says reaches 500 — so yes, ≥, not >. Off-by-one-at-the-boundary is the classic logic bug; decide boundaries consciously, on paper.
• Order of checks. If a later problem needs many conditions (marks → grade), check the most specific first and think about what “the rest” falls into. Sets B and D of the scenarios drill exactly this.

Ask of every decision: what data makes this go the other way? If you can’t answer, the condition isn’t understood yet.

14. Repetition

Some tasks need the same steps many times: print 30 bills, total 25 marks, count down from 10. Repetition (a loop) lets the algorithm say “do this again” instead of copying the steps — but it introduces the danger of never stopping. Every loop needs an honest answer to: what makes it stop?

Two shapes, learned on paper here, coded in Units 05–06:

WHILE there is another customer:      FOR each day FROM 1 TO 7:
    read the order                        read that day's sales
    print the bill                        add to the weekly total
    ask: another customer?            ENDFOR
ENDWHILE

• WHILE — repeat as long as a condition holds; the condition is checked first; something inside must eventually make it false (the customer eventually says “no”).
• FOR — repeat a known number of times.

The classic failure, so you recognise it on paper: a WHILE whose condition never changes — infinite loop; the algorithm never reaches STOP. The fix is always the same: make sure something inside the loop moves the world toward the stopping condition. Set C’s scenarios (11–15) are built on this idea; Unit 05 turns it into while statements.

15–16. Dry runs and trace tables

15. Dry runs

A dry run is executing the algorithm by hand — with pencil and values — before any code exists. You are the computer; the algorithm is the program; you keep honest track of every value. It takes two minutes and finds the bugs that otherwise cost an evening: wrong formulas, boundary slips, values never updated.

16. Trace tables

The trace table is the dry run written down — one column per variable, one row per step, updating values as the algorithm touches them. Dry-run the cafeteria algorithm with 3 samosas, 2 chais (no service, since 105 < 500):

The final column is the output — 105, matching the target bill above. Two minutes of pencil replaced an hour of debugging; this is also exactly the table you’ll fill in Set C/D scenarios, and the “predict before you run” habit the whole course runs on.

The professional upgrade — run the boundary too. The decision hides at subtotal = 500: try 20 samosas, 0 chais (subtotal exactly 500) → service = 25 → total 525. And one below: 19 samosas, 1 chai = 475+15 = 490 → service 0. If your paper run disagrees with the requirement at the boundary, you just found a design bug for free.

17–18. Test cases and edge cases

17. Test cases

A test case is a planned check: given this input, the output must be this. Now that trace tables predict behaviour, write the predictions down before coding — the plan, at minimum:

After coding: run all four, compare, and only then declare the program working. “It ran once” is not testing; testing is comparing against predictions you wrote down first.

18. Edge cases

Edge cases are the inputs at the edges of the ranges — smallest, largest, exactly-at-boundaries, and the “nobody would do that” values that users do daily:

That last row is the quiet lesson: an assumption (§7) marks territory your program does not defend; a validation requirement would move it inside (Set D’s Scenario 19 adds exactly that). Knowing which inputs are the program’s problem is part of the design — and saying so on paper is what makes it true.

19. Common problem-solving mistakes

The failure modes this module exists to prevent — every one is cheaper to avoid on paper than in code:

Keep this table for the scenarios: when a scenario resists you, find your row here, apply the defence, and try again before reading its solution.

20. Translating a problem into a C++ solution

Only now — IPO understood, algorithm written, dry run clean, tests planned — do we translate. Each construct has a direct C++ form:

And the cafeteria program:

// cafeteria.cpp — Programming and Problem-Solving Fundamentals, worked example
// Compile: g++ -std=c++17 -Wall -Wextra cafeteria.cpp -o cafeteria
// Run:     ./cafeteria            (Windows: .\cafeteria.exe)

#include <iostream>

int main() {
    int samosas = 0;
    int chais   = 0;

    std::cout << "Samosas: ";
    std::cin  >> samosas;                    // READ samosaCount
    std::cout << "Chai cups: ";
    std::cin  >> chais;                      // READ chaiCount

    int food     = samosas * 25;             // food     ← samosas × 25
    int chaiCost = chais * 15;               // chaiCost ← chais × 15
    int subtotal = food + chaiCost;          // subtotal ← food + chaiCost

    int service = 0;                         // the ELSE branch value
    if (subtotal >= 500) {                   // IF subtotal ≥ 500 THEN
        service = subtotal * 5 / 100;        //     service ← 5% (whole rupees)
    }

    int total = subtotal + service;          // total ← subtotal + service

    std::cout << "\n==== CAFETERIA BILL ====\n";
    std::cout << "Samosas x " << samosas << " : " << food << "\n";
    std::cout << "Chai    x " << chais   << " : " << chaiCost << "\n";
    std::cout << "------------------------\n";
    std::cout << "Subtotal      : " << subtotal << "\n";
    std::cout << "Service (5%)  : " << service << "\n";
    std::cout << "------------------------\n";
    std::cout << "TOTAL         : " << total << "\n";
    return 0;
}

The translation walk-through — notice where every line came from:

• samosas, chais — the inputs (§4); int because counts are whole.
• food, chaiCost, subtotal, service, total — one variable per algorithm step (§8), same names as the pseudocode. Same names = the code is the design, readable.
• if (subtotal >= 500) — the decision (§13); >= because the requirement says reaches 500 — the boundary we dry-ran on purpose.
• subtotal * 5 / 100 — 5% in whole rupees (integer arithmetic keeps the bill in whole rupees — our constraint §7; Unit 02 formalises this).
• the printed bill — the output spec (§6), line by line.
• every test from §17–18 must now pass, run by you:

T1: 3 2   → total 105   ✓   T3: 20 0 → total 525  ✓
T2: 0 0   → total 0     ✓   T4: 19 1 → total 490  ✓

That is the whole pipeline: understand → decompose → IPO → algorithm → pseudocode → dry run → tests → code → test. The 20 scenarios repeat it until it’s reflex — you doing it, per the Try It Yourself protocol.

Glossary of this module

← Module home · Scenarios — Set A · Lab