Capstone 3 — University Management System¶

Scope: a term's work · Prerequisites: Modules 1–15

1. Problem statement¶

A university department runs its own enrolment: students register for courses, courses have prerequisites and capacity limits, and instructors are assigned to sections.

The difficulty is that a university has many kinds of person — undergraduate, postgraduate, exchange, faculty, teaching assistant, administrator — who share some behaviour and differ sharply in others. A single Person class with a kind field is the design that produces the if chain every later requirement has to be threaded through. Getting the hierarchy right is the project's central task, and the one the design report should discuss.

Enrolments also have rules that interact: a student may not take two sections of the same course, may not exceed a credit limit that depends on their kind, and may not enrol without the prerequisites. Fees vary by kind and by residency, and a dropped course with a deadline half-refunds it.

2. Actors¶

Actor	What they do	What the system owes them
Student	Registers, enrols, drops, asks about progress	Clear refusals, correct fees, a transcript that reflects what happened
Instructor	Teaches sections, records grades, asks for a class list	A class list in a defined order, and grades that are auditable
Administrator	Creates courses and sections, sets limits and fees	Configuration without recompiling rules
Registrar	Produces transcripts and enrolment reports	Reproducible output, and a record that survives corrections

3. Use cases¶

Register a person in one of several kinds.
Create a course with prerequisites, and sections with capacities and instructors.
Enrol a student in a section, refusing for: capacity, prerequisites, duplicate course, credit limit.
Drop an enrolment before and after the deadline, with the fee consequence.
Record a grade, and correct one with an auditable change rather than an overwrite.
Produce a class list for a section, in a defined order.
Produce a transcript: courses, grades, credits, and a computed average.
Compute a student's fees for a term, by kind and residency.
Save and load everything; refuse a corrupted file with a line number and no partial state.

4. Suggested classes¶

Class	Responsibility, in one sentence	Notes
`Person`	An identity: name, identifier, contact	Abstract or concrete, but not a kind-holder
`StudentKind`	The rules that differ between kinds of student	An interface: credit limit, fee rate, what may be enrolled
`Student`	A person who enrols, with a kind and a transcript	Composed with a `StudentKind`, or derived from `Person`
`Instructor`	A person who teaches sections	Derived from `Person`
`Course`	A subject with credits and prerequisites	Owns its prerequisite references
`Section`	One offering of a course, in a term, with capacity	Owns its enrolments
`Enrolment`	One student in one section, with a status and a grade	Aggregates both; owns neither
`Transcript`	A student's completed enrolments and computed average	Append-only in effect
`FeePolicy`	Turns a student, a residency and a course load into a fee	Injected; the thing that varies
`Term`	A period with a drop deadline	Boundary object
`Department`	Owns courses and sections	Where the collections live

The class worth the most marks is StudentKind. Model it as a strategy (a StudentKind interface held by Student) or as a subclass hierarchy — and say which you chose and why, because both are defensible and the report's evaluation is what is being marked. The test of the choice: add an "exchange student" kind, and count the files you touched.

5. Relationships¶

   Department ◆── vector<Course>        composition
   Course ◆── vector<Section>           composition: sections belong to the course
   Section ◆── vector<Enrolment>        composition
   Enrolment ────> Student              association: referred to, never owned
   Student ◆── Transcript               composition
   Student ┈┈> StudentKind              dependency: injected, or held as a member
   Enrolment ┈┈> FeePolicy              dependency where fees are computed
   Person <|── Student                  inheritance for substitution
   Person <|── Instructor               inheritance for substitution

Note the two axes: inheritance for what a person is (Person → Student, Instructor) and composition for what a student's rules are (Student → StudentKind). Mixing them produces the kind-field design; keeping them apart is the project's lesson.

6. Design constraints¶

No kind field with an if chain over it anywhere. If a decision depends on what kind of student or person something is, the decision belongs in a type.
Enrolment rules are enforced in one place, and every refusal names its reason: capacity, prerequisites, duplicate, credit limit.
Fees are computed by an injected policy, not by a switch inside the enrolment operation.
A grade correction appends a record rather than overwriting one, so transcripts can be audited.
A student cannot be enrolled twice in the same course, in any section — a rule that spans sections and therefore tests whether the invariant has one owner.
Prerequisites are checked against the transcript, and the check is testable without a database of courses: pass the transcript in.
Format: documented text format, version marker, escape rule, and a round trip preserving every field including an empty enrolment period.

7. Milestones¶

#	Milestone	Done when
1	Design	Diagram; the two axes (is-a, has-rules) separated and justified in writing; every class's responsibility in one sentence
2	People and courses	Registration and course creation, with invariants enforced and no `kind` field anywhere
3	Enrolment	Enrol and drop work, with all four refusals implemented and each named
4	Fees and grades	Fees from an injected policy; grades recorded, corrected by appending, and a transcript computed
5	Persistence	Documented format, round trip including an empty term, three hand-edited corruptions rejected with line numbers
6	Tests and report	Invariants, boundaries and failures asserted; a deliberate bug caught; the exchange-student change counted in files; the reversal named with its cost

8. Minimum requirements¶

[ ] At least three kinds of person, with shared behaviour factored upward and differing rules in types
[ ] Courses with prerequisites; sections with capacities and instructors
[ ] Enrolment refusals for capacity, prerequisites, duplicate course and credit limit — each with a reason
[ ] Dropping before and after a deadline, with the fee difference
[ ] Fees by kind and residency, from an injected policy; money in integer pence
[ ] Grades recorded, and a transcript with a computed average and credit total
[ ] Persistence with a version marker and escape rule, and a round trip preserving every field including an empty term
[ ] Three hand-edited corruptions rejected with line numbers, leaving the loaded state untouched
[ ] At least two patterns, each justified by a named requirement; one declined, with the reason
[ ] Tests with assertions covering invariants, boundaries and failure paths
[ ] No warnings with -Wall -Wextra -Werror

9. Advanced requirements¶

[ ] An exchange-student kind added, with the file count in the report — the measurement that judges the StudentKind design
[ ] Waitlists for full sections, with a documented offer order and notifications
[ ] Instructor workload limits, and a refusal when exceeded
[ ] Prerequisite chains (A requires B requires C), checked transitively, with a cycle refused
[ ] A term-end grade report exported to CSV behind the same interface as the console one
[ ] A provisional and final grade state, with the transition rules stated
[ ] Transcripts preserved across a curriculum change (a course that no longer exists still appears)

10. Testing requirements¶

Invariants: a student is never enrolled twice in a course; section capacity is never exceeded; a transcript's credit total equals the sum of its completed courses; a fee total equals the sum of its components
Boundaries: enrolling exactly at capacity; at the credit limit and one credit over; a prerequisite completed with a bare pass; dropping on the deadline and one day later
Failure paths: enrolling in a full section; enrolling without prerequisites; dropping a course never enrolled; loading a truncated file; a negative credit value
Round trip: populated and empty terms, every field compared, including a course title containing the separator
One deliberate bug, introduced and caught, with the failing assertion kept

11. Extension ideas¶

Timetable clash detection across sections, with the complexity of the check stated.
A graduation audit: required courses versus completed, with missing requirements listed.
Teaching-assistant assignments, and the design question they raise about a person having two roles.
Grade distributions per section, exported as a report.
Scholarship rules that depend on average and kind — another policy object, and a measurement of whether adding it required editing existing code.
Transcript transfer: importing completed courses from another institution, with validation at the boundary.

12. Evaluation checklist¶

[ ] The diagram matches the declarations, including multiplicities
[ ] There is no kind field and no if chain over one — checked by searching the code
[ ] Adding a kind of student touched at most two files, and the count is in the report
[ ] Every enrolment refusal names its reason, and each refusal is tested
[ ] Fees come from an injected policy, and two exist
[ ] A grade correction leaves the original visible — demonstrated, not asserted
[ ] The round trip preserves every field, including an empty term — output pasted
[ ] Three corruptions rejected with line numbers, leaving the loaded state untouched
[ ] The suite fails when a deliberate bug is introduced
[ ] One pattern considered and declined, in writing
[ ] The report names the decision I would reverse and the cost of reversing it