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
"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."
"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.
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.
"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.
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.
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.
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
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
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.
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?
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 solutionChapter 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