Problem Frames Approach¶
The problem frames approach specifies a machine through its interfaces with world domains so that domain properties and machine behavior jointly satisfy a world-level requirement.
Core Idea¶
Michael Jackson's problem frames approach starts with a requirement about the world, not a program. A machine to be built interacts with given domains through shared phenomena. Its interface specification S and the domains' properties D must jointly imply the world requirement R: S,D⇒R. A problem frame identifies a recurring machine/domain arrangement and its characteristic control, inference or transformation concern.
Scope of Application¶
Jackson's original MIT lecture analyzes a sluice-gate controller as a simple-behavior frame: motor pulses and position sensors must establish a real gate-open/shut schedule. It analyzes a car odometer as a simple-information frame: wheel pulses must support inference of speed and distance shown on visible counters. Larger problems can be decomposed into frames, then require composition checks.
Clarity¶
A Top sensor signal is not itself the gate being fully open; a motor/sensor assumption links them. A wheel pulse is not itself distance; an inference from pulses and car behavior links it to a displayed number. The method makes these bridging assumptions explicit instead of labeling a software output “the requirement.”
Manages Complexity¶
The analyst distinguishes what the machine controls from what the world supplies. The sluice controller controls pulses, while gate/motor behavior is a causal-domain property. The odometer controls counter updates, while travel is autonomous. Frame-specific concerns localize the reasoning, but local solutions must still be composed without interference.
Abstract Reasoning¶
State the desired world phenomenon. Draw the machine, relevant domains and their shared phenomena, including which side controls each. State machine behavior at its interface and the assumptions that connect it to the requirement. If S,D⇒R fails, identify missing observation, actuation, timing or domain knowledge rather than treating the diagram as a proof.
Knowledge Transfer¶
The machine/world/interface skeleton transfers between gate control and odometer display, but the frame concern changes: one must impose a physical state; the other must infer a state and display it. The method presupposes Problem Framing of the world requirement and machine boundary; it is not merely a kind of framing act. Recognizing a familiar frame guides questions; it does not import a solution or make the domain assumptions true.
Relationships to Other Abstractions¶
Current abstraction Problem Frames Approach Domain-specific
Parents (1) — more general patterns this builds on
-
Problem Frames Approach presupposes Problem Framing Prime
Problem frames presuppose a delineated problem and machine/world boundary.
Hierarchy paths (2) — routes to 2 parentless roots
- Problem Frames Approach → Problem Framing → Representation → Abstraction
- Problem Frames Approach → Problem Framing → Boundary
Neighborhood in Abstraction Space¶
Problem Frames Approach sits in a sparse region of the domain-specific corpus (72nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Software & Systems Architecture (29 abstractions)
Nearest neighbors
- Communicating X-machine — 0.84
- Fallacy of One Administrator — 0.84
- Data Model — 0.83
- Software-defined data center — 0.83
- Software Component — 0.83
Computed from structural-signature embeddings · 2026-10-08