Formulating a Model
A model is a simplified representation of a problem that keeps what matters and discards what doesn't.
Real problems carry endless detail. A model is the decision about which details are relevant — and that decision is the heart of computational thinking.
Why simplify at all
Consider modelling traffic on MG Road to estimate journey time. You could include every vehicle's make, colour, and the drivers' moods. All true, all irrelevant. A useful model keeps vehicle count, road capacity, and signal timing, and throws the rest away.
"All models are wrong, but some are useful." — George Box
A model that kept everything would be as complicated as reality and no easier to reason about.
What a model must contain
1. The entities — the things involved. 2. Their attributes — the properties that matter. 3. The relationships — how they connect. 4. The rules — what may change, and how.
Choosing the representation
Once you know the entities, decide how to store them. This choice constrains everything afterwards, so make it deliberately.
| Structure | Suits |
|---|---|
| Single variable | One value — a count, a total |
| List | An ordered collection, duplicates allowed |
| Tuple | A fixed group that shouldn't change |
| Set | Unique items, membership tests, order irrelevant |
| Dictionary | Lookup by key — name to marks |
| 2-D list / array | Grids, matrices, tables |
You'll meet these properly in Module 3. Recognising which one a problem calls for is a modelling decision, not a coding one.
State your assumptions
Every model assumes things. Good practice is to write them down, because an unstated assumption is a bug waiting to happen.
Modelling a queue at the college canteen, you might assume: one queue, first-come-first-served, nobody leaves, service time is constant. Each is a simplification. Each might be wrong. Stating them tells you where the model will fail.
The common student mistake
Jumping straight from problem to code without a model in between. Symptoms: variables invented as you go, no clear idea what the data looks like, and rewriting halfway through because the chosen structure won't do what's needed.
Five minutes deciding "this is a dictionary of student name to list of marks" prevents an hour of restructuring.