Capstone 9 — Restaurant Management System¶

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

1. Problem statement¶

A restaurant takes orders at tables, sends them to the kitchen, serves courses, and bills the table. The menu changes, prices change, dishes become unavailable when an ingredient runs out, and tables are turned over several times an evening.

The central difficulty is that an order has a state and a history: placed, sent to the kitchen, partly served, amended (a guest changes their mind), voided (a dish is cancelled), and paid. Each transition has rules — you cannot add a dish to a paid order, you cannot void a dish that has been served, and an amended order must tell the kitchen what changed rather than re-sending everything.

Orders are also shared between stations: the grill, the cold larder and the bar each need their own list, in the order the dishes were ordered. That is a notification problem with a real operational consequence.

2. Actors¶

Actor	What they do	What the system owes them
Waiter	Takes orders, amends them, serves, bills	An order that reflects the table's current wish, and an itemised bill
Kitchen	Sees what to cook, in order, per station	A station list that updates when an order changes, and never misses an amendment
Bar	Sees drinks to make	The same, for its own station
Manager	Sets the menu, marks dishes unavailable, voids with a reason	Control without breaking an open order
Cashier	Takes payment, splits bills	Totals that reconcile, and a closed order that cannot be edited

3. Use cases¶

Define a menu: dishes with prices, categories and stations.
Open a table, and take an order.
Send the order, which tells the kitchen and bar what to do.
Amend an order: add, remove or change a dish before it is cooked.
Void a dish with a reason, refused if it has already been served.
Mark dishes served, per course.
Print a station list: everything outstanding for one station, in order.
Bill a table: an itemised total, with payment and change.
Close the table, after which no edit is possible — demonstrated by a refusal.
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
`Money`	An exact amount in pence	A value type
`Dish`	A menu item: name, price, category, station, availability	Availability changes during service
`Menu`	The dishes, searchable by category, with availability	Owns dishes
`OrderLine`	One dish, a quantity, a state and a station	The state is per line, not per order
`Order`	A table's lines, with a state and a guard on every transition	Refuses edits once paid
`OrderState`	What is allowed now: open, sent, partly served, paid, closed	Guarded transitions, with refusals that name the state
`Station`	A production area: grill, larder, bar	The observer's subscriber
`StationBoard`	The outstanding lines for one station, in order	A projection, recomputed or maintained
`Amendment`	What changed in an order, so the kitchen can be told	The difference, not the whole order
`Bill`	An itemised total for a table, with payments	Owns its payment lines
`Table`	A physical table and its current order	Owns at most one open order
`Restaurant`	Coordinates operations and owns the menu and tables	Where an order is a transaction

The class worth the most marks is Order and its state guards. This is the course's only project where a state machine is the centre of the design, and it is where the bool paid version breaks down: an amendment after payment, a void of a served dish, a send of an already-sent order. The report should show what the naive version made expensive.

5. Relationships¶

   Restaurant ◆── Menu               composition
   Menu ◆── vector<Dish>             composition
   Restaurant ◆── vector<Table>      composition
   Table ◆── Order                   composition: the table owns its open order
   Order ◆── vector<OrderLine>       composition
   OrderLine ────> Dish              association: refers to a menu dish it does not own
   Order ────> OrderState            association to the current state
   Order ◆── Bill                    composition, created at billing
   StationBoard ◇── OrderLine        aggregation: it indexes lines it does not own
   Station <|── StationBoard?        no: a station HAS a board — composition, not inheritance
   Order ┈┈> StationBoard            dependency: the order notifies the boards it affects

6. Design constraints¶

Order state transitions are guarded in one place, and every refusal names the current state and what is allowed. bool paid is not an acceptable design; say so in the report if you started there.
An amendment notifies the affected stations with the difference, not with a re-send. The kitchen list must never double a dish because an order was amended elsewhere.
A void requires a reason and a permission, and both are recorded.
A served dish cannot be voided, and an unpaid order cannot be closed — demonstrate each.
Station boards are projections, either recomputed on request (and you state its cost) or maintained (and you test that they agree with the orders).
Availability is per dish and changes during service; a dish marked unavailable cannot be added to a new line, but existing lines are unaffected — a nice boundary case.
Prices are frozen on the line when it is sent, so a menu change mid-service does not reprice an open order — demonstrated.
Format: documented text format with a version marker and an escape rule; open orders and their line states preserved exactly; a later-version file refused, not misread.

7. Milestones¶

#	Milestone	Done when
1	Design	Diagram; the order's states and allowed transitions written out; the board/order relationship decided
2	Menu and table	Menu with dishes and availability; tables with an open order; prices frozen on a line
3	Order lifecycle	Send, amend, void, serve and bill, each with named refusals; station boards update correctly
4	Boards and notifications	Each station's outstanding list is correct after amendments — demonstrated by a scripted sequence with a change mid-order
5	Persistence	Documented format; round trip preserving open orders and line states; three hand-edited corruptions rejected with line numbers
6	Tests and report	Boundaries and failures asserted; a deliberate bug caught; the state-model evaluation; the reversal named with its cost

8. Minimum requirements¶

[ ] A menu with dishes, prices, categories and stations; availability that changes during service
[ ] Tables that own at most one open order
[ ] An order with per-line states and guarded transitions, refusing: an edit after payment, a void of a served dish, a send of an already-sent order — each naming the state
[ ] Amendments that notify the affected stations with the difference, not a re-send
[ ] Station boards, with the outstanding lines for one station in order
[ ] Prices frozen on a line when sent, unchanged by a later menu change — demonstrated
[ ] A bill: an itemised total in integer pence, with payment and change
[ ] Closing a table, after which no edit is possible — demonstrated by a refusal
[ ] Persistence with a version marker and escape rule; a round trip preserving open orders and line states, including no open orders
[ ] 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¶

[ ] Course ordering: starters before mains, with a rule for when a line may be sent
[ ] Split bills: a table's lines divided between two or more payments, with totals that reconcile
[ ] A fourth station added with no edits to existing code — the file count in the report
[ ] Kitchen timing: a "gone" timestamp per line, and an outstanding-time report
[ ] Menu versioning: a dish's price history, so an old closed order can be re-printed identically
[ ] A second output format for station lists (a printer-ready layout) behind the same interface
[ ] Board consistency check: recompute every board from the orders and report disagreements

10. Testing requirements¶

Invariants: a paid order cannot be edited; a served line cannot be voided; a bill's total equals the sum of its lines; a table has at most one open order; a board agrees with the orders it projects
Boundaries: an empty order; a send with nothing outstanding; a void of the last line; payment of exactly the total and one penny short; a dish marked unavailable between two adds
Failure paths: billing an empty order; amending after payment; adding an unavailable dish; loading a truncated file; a line with a negative quantity
Round trip: open orders, line states and frozen prices preserved exactly, including no open orders
One deliberate bug (for example, notifying stations on every amendment instead of with the difference), caught by the board test, with the failing assertion kept

11. Extension ideas¶

Reservations and a waiting list for tables, with notifications when a table frees.
Inventory behind the menu: marking a dish unavailable when an ingredient runs out.
Daily sales reports by dish and by station, exported to CSV behind the same interface.
Discounts and service charges as composable policies, with the itemised effect printed.
Multiple floors with tables belonging to sections, and one waiter per section.
A "specials" menu that changes daily, and the design question about whether a dish still exists after the specials period.

12. Evaluation checklist¶

[ ] The diagram matches the declarations, including multiplicities
[ ] Every order transition is guarded, and each refusal names the state
[ ] No bool paid-style flag decides anything — search the code and record the result
[ ] An amendment informs stations with the difference — demonstrated by a board with no duplicate line
[ ] A menu price change does not reprice a sent line — demonstrated
[ ] A board agrees with the orders — checked by the program, not by eye
[ ] A closed table cannot be edited — demonstrated by a refusal
[ ] The bill reconciles, and split payments reconcile too
[ ] The round trip preserves open orders and line states, including none — 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