Capstone — Applying Discrete Math to Real Programming Problems

Discrete Mathematics Fundamentals

Chapter 10 · Capstone — Applying Discrete Math to Real Programming Problems

One worked system, touching every chapter of this course in the order a real engineer would actually reach for each idea — designing and verifying a small access-control system for a file-sharing tool.

A Full Worked System — Designing an Access-Control Check

1 — The rule itself, as propositional logic (Ch.2)

"A user can access a resource if they're an admin, or they own the resource and it isn't locked" becomes Admin ∨ (Owner ∧ ¬Locked). When access is denied, a good error message needs the negation — applying De Morgan's Law directly: ¬(Admin ∨ (Owner ∧ ¬Locked)) ≡ ¬Admin ∧ (¬Owner ∨ Locked). That's precisely the reasoning a clear denial message would need: "not an admin, and either you don't own it or it's locked."

2 — The specification, as a quantified statement (Ch.3)

"Every admin can access every resource" becomes ∀u ∀r (Admin(u) → CanAccess(u, r)). This is directly testable: all(can_access(u, r) for u in admins for r in resources) is the code-level check of the exact same claim.

3 — Visibility, as a set operation (Ch.4)

The resources visible to a given user are owned_by(user) ∪ (visible_to_admins if is_admin(user) else ∅) — a direct union of two sets, exactly Chapter 4's own operation, not a special case invented separately.

4 — Ownership and teams, two different relations (Ch.5)

"Owns" is a relation between users and resources — but it isn't reflexive or symmetric, and doesn't need to be; not every relation has to be an equivalence relation. "Is on the same team as," by contrast, genuinely is one — reflexive, symmetric, and transitive — and its equivalence classes are exactly the teams themselves, the same GROUP BY connection Chapter 5 made directly.

5 — The user lookup, checked for injectivity (Ch.6)

The system's own get_user(user_id) function needs to be injective — no two different users may ever share an ID — or "the" user identified by a given ID becomes genuinely ambiguous. This isn't a stylistic preference; it's a correctness requirement for the entire system to even make sense, formalized exactly by Chapter 6's own definition.

6 — Proving a recursive permission check correct, by induction (Ch.7, Ch.8)

Folders can be nested — if a user isn't directly permitted on a folder, the check recurses upward to the parent. Proving this recursive check is correct for a folder tree of any depth is exactly structural induction: base case, the root folder (no parent, checked directly); inductive step, assuming the check is correct for a subtree of depth k, it remains correct for depth k+1, since the recursive call on the parent is covered by the inductive hypothesis. Chapter 8's own reasoning, applied directly to a real recursive function.

7 — Estimating the test surface, by counting (Ch.9)

The access rule from Step 1 combines three independent boolean conditions — Admin, Owner, Locked. By the multiplication principle, there are 2 × 2 × 2 = 8 distinct combinations to cover for full test coverage of the rule's own logic — a direct, practical answer to "how many test cases do I actually need here," not a guess.

This is, in essence, exactly what a real authorization system's design review looks like — every step traceable to a specific chapter of this course, none of it abstract math floating free of the actual code.

What This Course Doesn't Cover

In the interest of an honest accounting: Graph Theory, Boolean Algebra & Digital Logic, and Algorithms & Complexity were all named in Chapter 1 as deliberately out of scope, each reserved for its own future course under this same Maths for Programmers subject. Also genuinely out of scope here: formal set theory foundations (the cardinality of infinite sets, axiomatic set theory), abstract algebra (groups, rings, fields), and formal language / automata theory. This course is the direct foundation those subjects will each build on, not a substitute for studying them when their own turn comes.

This Course's Throughline, Restated

Formal notation is precise vocabulary for judgment you already make
Every chapter in this course answered a version of the same question: what's the exact, formal way to say something you'd probably already reason about correctly by instinct? A programmer already knows a dict can't hold two values for one key, already knows an "if it's raining, the ground is wet" claim doesn't reverse cleanly, and already senses that testing a hundred cases isn't the same as proving something for all of them. Discrete math doesn't replace that instinct — it gives it a rigorous, checkable, communicable form, which is exactly what makes the difference between "I think this is right" and "I can show you why this is right."

Where This Course Connects

As the first course under a brand-new subject, this one has no existing site courses built on top of it yet — but it's deliberately the shared foundation for everything else this subject's own bucket list still has planned: Graph Theory will lean directly on Chapter 5's relations, Boolean Algebra & Digital Logic will lean directly on Chapter 2's propositional logic, and Algorithms & Complexity will lean directly on Chapter 9's combinatorics. Nothing here was built in isolation from where this subject is actually headed.

Hands-On Exercises

Exercise 1

A different system's access rule is Admin ∧ (Owner ∨ SharedWith). Apply De Morgan's Law to derive the exact denial condition, showing your work step by step.

📄 View solution
Exercise 2

Suppose the access rule from Step 1 grows to include a fourth independent boolean condition (say, AccountActive). Using this chapter's own combinatorics reasoning, how many test cases are now needed for full coverage, and why?

📄 View solution
Exercise 3

For each of the seven steps in this chapter's own worked system, name the specific discrete math topic it relied on, without looking back at the step labels — just from the description of what each step actually does.

📄 View solution

Chapter 10 Quick Reference

  • Full worked system: propositional logic (Ch.2) → quantified spec (Ch.3) → set operations (Ch.4) → relations (Ch.5) → function injectivity (Ch.6) → structural induction (Ch.7/8) → combinatorial test coverage (Ch.9)
  • Out of scope: Graph Theory, Boolean Algebra & Digital Logic, and Algorithms & Complexity — each reserved for its own future course
  • This course's throughline: formal notation gives already-good programmer instincts a rigorous, checkable form
  • This course is the direct foundation this subject's own future courses will each build on
  • Course complete — Discrete Mathematics Fundamentals, 10 chapters, from propositional logic to combinatorics