Module/function structure chart
For procedural code: which function calls which, and what is passed.
What it explains and when it is useful
A structure chart shows a procedural program as a hierarchy of modules or functions: each box calls the boxes below it. Small arrows (couples) show the data and flags passed down and returned.
When to use it: Solutions built from functions and modules rather than classes, in Python, JavaScript, C or any language.
Worked example
Illustrative: PracticePal is a fictional project used throughout this guide.
Scroll sideways to see the whole diagram.
Companion: function specifications
For the important functions, a specification states the contract precisely: what goes in, what comes out and what must be true before and after.
| Function | Parameters | Returns | Precondition | Postcondition |
|---|---|---|---|---|
make_booking | student_id: int, room: str, start: datetime, loud: bool | (booking_id, None) or (None, reason: str) | student logged in; start on :00 or :30 | if booking_id is returned, exactly one booking exists for (room, start) and no rule is broken |
check_cap | student_id: int, week: ISO week | count: int (0+) | – | no data changed |
offer_next | room: str, slot: datetime | student_id or None | slot is free | the front WAITING entry (if any) is OFFERED with offered_at = now |
usage_report | week: ISO week | path of CSV file | user is head of music | one row per room; percentages between 0 and 100 |
Notation and legend
| Symbol or part | Meaning |
|---|---|
| Box | A module or function |
| Line from above | The upper box calls the lower one |
| ○→ | Data couple: a value passed in the arrow's direction |
| ●→ | Control flag: a true/false result that decides what the caller does |
| Shared box | A function called from more than one place, designed once |
Design decisions it communicates
A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:
- Each rule is its own function, so each can be unit-tested and reported with its own reason.
- check_clash and check_adjacent return flags, but check_cap returns a count, so the message can say how many bookings the student has.
- offer_next is shared by cancel and the scheduler.
Common mistakes
- Drawing the order of execution (that is a flowchart).
- No couples, so the interfaces between functions are invisible.
- Using it for an OOP program, where a class diagram fits better.
Checklist for your own version
Ticks are saved in this browser only, so you can use the list while you draft.