Computational Thinking & Design

This is Unit Two of Computer Science: computational thinking, and building from parts. The capstone names the unit's shape, and it is worth having in advance. One half builds understanding from the bottom up — break a problem apart, find what recurs, decide what to ignore. The other half assembles solutions from the top down, out of pieces that already exist. A real build runs both directions simultaneously, and the capstone says so rather than presenting them as rival philosophies. Three error entries, and the first corrects who this is for. Computational thinking is treated as a programmer's skill and it is not — the process solves ordinary problems, works before any machine is involved, and involves people first and computers second. The other two correct confusions that cost real work: mistaking alternation for simultaneity, and forgetting the floor that stops a self-calling process. By the end you will be able to do five things. One: say what computational thinking is, and who it is for. Two: say what an abstraction keeps and discards. Three: tell concurrency from parallelism. Four: say why recursion needs a floor. Five: say what a monolith trades, and what independence demands.

Two entries, and the second is placed early for the same reason Unit One's was — it corrects a belief that would otherwise narrow everything following it.

The process.

CS 0041 Computational Thinking

A problem-solving process from computer science: break a complex problem into smaller manageable pieces and work them. The thinking operates before any machine arrives.

And who it is for.

CS 0042 "Computational Thinking Is for Programmers"

Treating it as a programmer-only skill misses the point — the process solves everyday problems and belongs to anybody. It involves humans first and computers second.

Three entries, and the third contains the idea the rest of the course leans on hardest. Deciding what to ignore is not a simplification for teaching — it is a choice somebody makes, and choices serve purposes.

The first move.

CS 0043 Decomposition

Systematically breaking a complex problem or system into smaller parts. A part left undiscovered does not stay hidden — it returns later as a surprise.

The second.

CS 0044 Pattern Recognition

Identifying similarities within and among problems — structures and relationships that recur. The grouping is the insight; a list of observations is not.

The third.

CS 0045 Abstraction

A simplified representation keeping what matters for the problem and ignoring the rest. What gets ignored is a decision somebody made, and decisions serve purposes — which is worth asking about.

Two entries borrowed from logic, each with a caution attached. One proposes and can be overturned; the other guarantees and still carries forward whatever was wrong in its inputs.

From cases to a rule.

CS 0046 Inductive Reasoning

Moving from specific examples to a general principle, with the observed pattern becoming a hypothesis to test. It proposes — and a counterexample still disposes.

From a rule to a conclusion.

CS 0047 Deductive Reasoning

Conclusions that must hold whenever the premises do. And a guaranteed conclusion still inherits any error present in a premise — the guarantee covers the connection only.

Three entries. A three-phase working rhythm with a phase people drop, the pair of steps that separate a claim from a verified one, and a note about notation.

The rhythm.

CS 0048 The Three As

Three phases: formulating the problem, expressing a solution, and analysing the result. Skipping the third leaves the solution unexamined, which is the phase most often dropped.

Two steps.

CS 0049 Testing and Debugging

Testing uncovers errors in the instructions; debugging finds where each lives and repairs it. Untested instructions are unverified claims rather than working procedures.

And the notation.

CS 0050 Pseudocode and the Flowchart

Written ordered steps mixing plain language with programming ideas, or a diagram of the flow. This course uses the written form throughout, so the choice is declared once.

Two entries on a distinction that matters practically. One genuinely does several things at the same moment. The other alternates fast enough to look identical from outside.

The genuine case.

CS 0052 Parallel Execution

Parts of a task running at the same time on separate resources, finishing sooner than a single sequence could. It requires genuinely separate processors at work.

And the resemblance.

CS 0053 "Concurrent Means Parallel"

Concurrency on a single processor alternates between tasks, sharing one resource by turns. From far enough away alternation resembles simultaneity — and the two make different demands and different promises.

Three entries on a process that calls itself. It has one mandatory ingredient, and the failure when it is missing is unusually informative — the process does not quietly misbehave, it fails loudly.

The technique.

CS 0055 Recursion

A process calling itself on smaller instances of the same problem, shrinking the case each time. The shrinking is mandatory rather than decorative.

The floor.

CS 0056 "Recursion Never Ends"

Without a base case the process never terminates. The base case is the smallest instance answered directly — the floor that lets the chain stop, and its absence fails as an overflow.

One chain, run.

CS 0057 Running a Recursion to the Floor

A recursive sum computed from one rule — the total up to a number being that number plus the total up to the one below. Watching the chain reach the floor is what makes it concrete.

Four entries turning the unit around. Instead of breaking a problem down, assemble a solution from pieces that already exist — and the entries insist the two directions are partners rather than competing philosophies.

The approach.

CS 0061 Adaptive Design Reuse

Building solutions top-down by assembling existing design pieces that need little customisation. Bottom-up analysis and top-down reuse work together rather than against each other.

The piece.

CS 0062 The Design Component

A reusable element serving a specific purpose inside a larger system, requiring little change to fit. How little modification it needs is the qualifying test.

The shape.

CS 0063 The Architectural Pattern

A reusable solution to a recurring architectural problem — a structural shape that has worked before. A pattern fits a class of problems and never every problem.

And the rule of thumb.

CS 0064 The Heuristic

A pattern hardened into guidance that usually works, adopted without a guarantee. Heuristics earn trust statistically and lose it the same way.

Two entries on arranging a system, and both are defined partly by their failure. A layer that leaks has failed at being a layer; a boundary drawn sloppily spreads every repair beyond where it should have stopped.

Stacking.

CS 0065 Layering

Levels of abstraction stacked so each serves the one above and conceals its own workings. A layer leaking its details upward has failed at its job.

Splitting.

CS 0066 Componentization

Separating a system into swappable parts along clean boundaries, so any one can be replaced without rebuilding the rest. The boundaries do the work — sloppy ones spread every repair.

Five entries. What an architecture is measured against, two opposite shapes with an honest account of the trade between them, one widely used pattern, and four views of an organisation's systems.

The measure.

CS 0067 Business Solution Architecture

A structural design addressing the needs of a solution's prospective users, and soundness is measured against those stated needs rather than against novelty.

The first shape.

CS 0068 The Monolith

All components tightly coupled into a single unit — one build and one deployment. Tight coupling is a trade rather than a mistake, and its costs arrive later rather than immediately.

The opposite.

CS 0069 Microservices

Small independent services, each in its own process, communicating by protocol. Independence is both what the approach promises and what it demands of the people building it.

One pattern.

CS 0070 Model-View-Controller

Separating a system into the part holding data, the part presenting it, and the part coordinating between them. The parts staying separate is the whole of the pattern.

And four views.

CS 0076 The Four Architecture Views

An organisation's architecture described from four coordinated angles — business, data, application, and technology — each answering a different question. Full treatment comes later.

One capstone, and its claim is about practice rather than theory. Neither direction is the correct one — a real build runs both, and the entry says so plainly rather than picking a side.

The capstone. Both directions.

CS 0085 Two Directions, One Solution

Computational thinking builds understanding from the bottom and design reuse assembles solutions from the top, and a real build runs both at once. Every concept here returns at full depth later.

Five things you can now do. You can say what computational thinking is and who it is for — not programmers specifically, and it works before any machine is involved. You can say what an abstraction keeps and discards, and that what gets ignored is a decision somebody made for a purpose. You can tell concurrency from parallelism: one genuinely runs at the same moment on separate resources, the other alternates on a single one. You can say why recursion needs a floor — the smallest case answered directly — and that a missing one fails loudly as an overflow. And you can say what a monolithic structure trades, with costs arriving later, and that independence is both what services promise and what they demand.