Designing systems with mental models

Before you wire anything for a lamp you want to control from a browser, you already carry a picture in your head: the browser talks to something, and that something talks to the lamp. That picture is a mental model, and the first claim of this part is that good design starts there, not with code and not with hardware.

The claim is really about order. You do not jump from the problem straight to a solution; you first build a simplified representation of how the system works, and then derive the solution from it. The tool for building that representation is system thinking: describe the problem as parts, the connections between them, and the levels they sit on. A system seen this way is made of components, each one box with a job, and layers, each one a grouping of things that sit at the same level of abstraction.

The problem: a lamp, a browser, and a mysterious arrow

Now make it concrete. Draw Chrome on one side, a light bulb on the other, and one double-headed arrow between them. The browser is the client you already know. The lamp is the device. The arrow is where everything interesting hides. A browser tab cannot switch mains power; it can only send and receive messages over a network. So something must sit between the tab and the bulb, receive those messages, and turn them into electricity flowing or not flowing. The rest of this part is an answer to one question: what is inside that arrow?

The tempting answer: ad hoc

The first answer most people give is a part: "use a sensor", "buy a smart plug", "write a script". That is ad-hoc design, a component chosen before anyone has asked what the system actually is. The phrase comes from Latin ad (to) and hoc (this): for this specific purpose, a sense recorded in English from 1879. An ad-hoc design answers the immediate situation without previous planning.

For one lamp in one room, that can work. Now scale it: 50 lamps, a phone app next to the browser, a monthly energy report. With no named components and no agreed interfaces, each addition is another one-off wire or script, and nothing fits together. Ad-hoc designs may work for small isolated tasks, but they fail to scale or to integrate with larger systems.

The better answer: structured design

Structured design takes the same lamp but fixes the order of work: questions first, components second, code last. Design becomes a process, not a random walk. Notice what comes out of that process. It is not a sensor, a script or a board: it is a system, a named set of parts with defined connections. Named parts are what let a phone app or a second lamp plug in later without rework, and that is why structured design holds up under complexity, scalability and integration.

The structured process in this lecture is not mysterious. It is four questions, asked in a fixed order, and their highlighted words are the whole vocabulary of system thinking.

The order is forced by dependency. You cannot name relationships before you have components to relate, and you cannot group things into layers before you know what the things are. Treat the list as a reusable checklist: your research project architecture section must answer exactly these questions, and so must any exam answer that asks you to design or critique a system. This concept answers the first two for the lamp; the rest of the part answers the other two.

Question one: what is a system?

For the lamp, the boundary is the room plus the network, the parts are the browser and the lamp, and the things that happen between them are "switch on" and "how much energy have you used?". Generalize that and you get the definition: a system is an environment in which interactions occur between components. Three ingredients, each one necessary. The environment draws the boundary. The components are the boxes inside it. Each interaction is an arrow.

Question two: what are the components?

The lamp is decomposed in two refinement steps, and each step adds one idea. First, separate software from thing: browser and bulb become Application and Device, where the application is everything that is software and the device is the physical lamp. Second, split the application in two. The client is the user-facing interface, the part you touch. The server processes client requests and communicates with the device. That second component is the answer to the mystery of the arrow: it is the thing that sits between the tab and the bulb.

Read the visual left to right: the click starts at the client, the server relays it, and only when the path reaches the device does the lamp glow. No box can be skipped.

Why split the application: offloading

Why not let the browser do everything? Because a browser tab is a poor place to keep things. It is not running while the tab is closed, so it cannot record energy readings around the clock, and a phone and a laptop would each hold their own copy of the lamp state. The server is always on and shared, so it can do both.

That is offloading: the client hands functions it cannot or should not perform to the server, because the server has the processing and storage. The server hosts those functions as services, such as "set the lamp state" and "read energy use", and the client simply calls them. Deciding what to offload, and to where, is exactly what the task mapping later in the lecture varies: a task can run on the device, at the edge, in the fog or in the cloud.

Question three asks what connects the components. Start concrete: between client and server the lamp needs at least two exchanges, "set the state" and "read the energy".

Each exchange is one interaction, and the relationship is the whole set of them. In set notation, an interaction d is an element of a relationship R. That framing is useful because it tells you how to specify a relationship: list its interactions, and then say what every one of them has in common.

What they have in common splits into two halves. The protocol is the grammar both sides agree on: message format, order and meaning. For the Web that is HTTP, with its message format, methods, headers and status codes. The interface is the list of operations the server offers: the endpoints, each a method plus a path, that a client may call. Neither half is enough on its own. A shared language with nothing to ask for is useless, and a menu of operations nobody can phrase is equally useless.

The relationship we deliberately ignore

There is a second arrow in the lamp system, between server and device, and the lecture is blunt about it: it is not our concern. That is a design decision, not laziness. You may assume the server runs on a microcontroller board wired to the lamp. Inside that board, the program calls a hardware library; the library switches a pin; the pin drives a relay; the relay switches the lamp. That chain is a separate, lower-level relationship with its own protocol and its own interface.

The web client never sees any of it. It sees only the interface the server exposes. This is the payoff of defining a relationship by protocol and interface: each side can ignore the other side's internals, which is abstraction doing its job. Swap the relay for a smart bulb and the client does not change at all.

A relationship is a set of interactions, so the next step in specifying the lamp is to write that set down. It has two members, and each is a pair: a request from the client and a reply from the server. The client always speaks first.

In the visual, each interaction is a request drawn toward the server followed by a reply drawn back to the client, and the meter inside the server fills once the kilowatt-hour reply lands. The device sits behind the server, never talking to the client directly, exactly as the previous concept required.

One design detail matters more than it looks. Set_on_off should carry the value you want (on, or off), not mean "toggle". If the network drops the reply and the client sends the request again, a toggle flips the lamp back, while "set on" twice still leaves it on. Hold on to that thought: the next concept gives the property a name and shows that HTTP builds it into its methods.

What the energy reply actually means

The read interaction returns energy, and that is where many students slip. A watt measures power, which is a rate: how fast energy is being used. A watt-hour measures energy: power kept up for a length of time. A kilowatt-hour is 1 kW (1,000 W) used for one hour, and the usual appliance formula is wattage times hours, divided by 1000.

So far the interactions are abstract. On the Web they become concrete: set becomes HTTP PUT, and read becomes HTTP GET. The arrows carrying them are the protocol, HTTP, and the set and read operations exposed on the server edge are the interface, a Web API. The formula from earlier now has a real instance.

In the visual, the PUT and GET lines are the protocol, and the two sockets they seat into, set and read, are the interface. Only when both halves meet does the relationship work.

The actual messages

Here is what the two interactions could look like on the wire. Host and paths are illustrative.

The 204 No Content reply is the HTTP form of the abstract ok: RFC 9110 defines it as the server having fulfilled the request with no additional content to send.

Why GET fits read: safe

RFC 9110 calls a method safe when its semantics are essentially read-only: the client does not request, and does not expect, any state change on the server. Reading energy changes nothing, so GET is the natural fit. RFC 9205 adds a practical reason: implementations can and do retry GET requests that fail, so GET handling should not change application state.

Why PUT fits set: idempotent

Recall the toggle problem from the interaction list. HTTP has a name for the property that solves it. A method is idempotent when the intended effect of several identical requests is the same as the effect of one. PUT, DELETE and the safe methods are idempotent. PUT asks for the target resource to be created or replaced with the state enclosed in the request, so sending {"on": true} twice still leaves the lamp on.

This matters on real links. RFC 9110 says an idempotent request can be repeated automatically if the connection fails before the client reads the response, while a client should not automatically retry a non-idempotent request unless it knows the request is actually idempotent, or that the original request was never applied. Edge devices often sit on flaky wireless links, so this choice decides whether a retry is harmless or a bug.

Question four asks for the layers. For this system the answer is a single layer, the one where processing and storage happen: the server layer. Answering it forces you to notice that the word "server" has been doing two jobs.

The server component is the program, for example the Python or C code that answers requests for the lamp state. The server layer is that program together with everything it needs to run: the processor executing it, the network carrying requests, the memory holding the current state, and the disk keeping energy history. The component is what you write; the layer is what you must provision.

The visual starts with just the program lit, which is the component. The resources rise beneath it and the outline closes around all five: that outline is the layer.

The modern names for the server layer

Now the question the whole course answers: what do we call this layer today? Cloud, fog or edge, depending on where it is placed. Close the lamp story with that in mind. If the program runs on a board next to the lamp, the layer sits on the device side of the continuum (mist, or edge on a nearby gateway). If it runs in a distant data center, it is the cloud.

The standard definitions line up with the layer you just built. NIST defines cloud computing as on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications and services, that can be rapidly provisioned and released: the same resources as the server layer, pooled at scale. NIST also describes fog computing as a layered model for access to a shared continuum of scalable computing resources, built from fog nodes that sit between smart end devices and centralized cloud services. Cloud, fog and edge together form the edge-to-cloud (E2C) continuum that the rest of the lecture studies.