1.1.2: The building blocks of a model#
Before you can critique a model, debug it, or choose the right technique to build it, you need to see what it is made of and what kind of thing it is. Whatever approach a modeller takes, a model is built from a few general ingredients and can be expressed at different levels of formality. This section introduces the core elements that every model shares, and the main types of model distinguished by how they represent a system. These are the foundations on which the specific modelling techniques later in the book are built. We begin with the elements every model shares.
1.1.2.1: Core elements of a model#
Most models can be described in terms of three elements: the things being represented, the connections between them, and the simplifications that bound the whole [1].
Entities are the things the model represents, the components or units of the system: people, firms, vehicles, cells, regions, and so on. Each entity has attributes that describe its current state, such as a person’s age or a region’s population [1].
Relationships are the connections between entities, the ways in which they influence one another or depend on one another. Relationships may be spatial, structural, or functional, and they are usually where a system’s behaviour comes from [1].
Assumptions are the simplifications that define the model’s scope, what it includes and what it deliberately leaves out. Every assumption is, in effect, a hypothesis: by excluding something, the modeller is claiming it does not materially affect the behaviour in question [2].
Fig. 2 Figure 1.2 The three core elements of any model. Entities are connected through relationships, and both are bounded by the assumptions that define the model’s scope and limits.#
Because each assumption is a hypothesis, the assumptions are where a model is most often right or wrong. When a model fails to match reality, the first and most useful question to ask is which assumption was wrong? [2]. Making the assumptions explicit, rather than leaving them buried in intuition, is what allows that question to be asked at all.
The activity below puts these three elements into practice: you build a small model of a coffee-shop morning rush from its entities, relationship, and assumption, and see how changing a single assumption can reshape the whole system.
1.1.2.2: Types of models#
Models can also be grouped by how they represent a system. Sayama distinguishes three broad types, which form a progression from the qualitative to the fully executable [1].
A conceptual model describes a system qualitatively. It identifies the important components and the relationships between them, often as a diagram or a narrative, without fixing precise quantities. It is where the modeller works out what the system is before committing to any numbers [1].
A mathematical model expresses relationships as equations linking variables. When such a model can be solved, it gives general, exact insight into how the quantities relate. Many classic models, from population growth to physics, are of this kind [1].
A computational model expresses the system as rules or algorithms that a computer executes step by step. When a system is too complex to solve mathematically, a computational model lets the modeller explore its behaviour by simulation instead [1].
Fig. 3 Figure 1.3 The three types of model by representation. A conceptual sketch is often made precise as a mathematical model, or implemented as a computational model when an exact solution is out of reach.#
These types are not rivals; most projects move through them. A conceptual sketch is made precise, either as equations or as a computer program, and the work of moving from one to the next, and back again when a problem appears, is the modelling cycle that the next section examines in detail.
The short activity below puts that progression into practice, from the most qualitative sketch to the fully executable simulation.
Reading the three types as one progression, rather than as competing options, is what lets a modeller move from a rough sketch to a runnable model, and back again, as the work demands.
A computational model comes in two flavours, and the distinction matters for how you read its output. A deterministic model has no chance in it: run it twice from the same starting point and it traces exactly the same path every time. A stochastic model builds randomness in, so each run wobbles differently around the underlying trend and no two runs are identical.
The activity below holds one system fixed, a small population growing towards the limit its environment can support, and shows it three ways side by side: as a Conceptual sketch, a Mathematical curve, and a Computational simulation of individual births and deaths. It also lets you switch the computational model between deterministic and stochastic. Before you run it, predict whether the jagged computational line will land exactly on the smooth mathematical curve, and whether two runs will look the same or different.
Names the parts: a population that births add to and deaths remove from. No numbers yet.
One equation gives one smooth curve. Population is a continuous quantity, so it can read 42.7. Same every time.
The same system simulated individual by individual. The count moves in whole steps (dots) and, with randomness on, wobbles around the curve.
Reflection questions
Pick a system you know well. What are its main entities, what are the key relationships between them, and what is one simplifying assumption you would make to model it?
When is a conceptual model on its own enough, and when do you need a mathematical or computational model instead?
Suggested answers
There is no single right answer. For traffic on a stretch of motorway, the entities might be the individual vehicles and the lanes they occupy; the relationships are cars following the one ahead and changing lanes to overtake; and a simplifying assumption might be that every driver reacts to the car in front after the same fixed delay. Naming these forces you to decide what matters for your question and what can be left out [1].
A conceptual model is enough when the goal is to communicate a mechanism or to scope a problem, and precise numbers are not yet needed. A mathematical model becomes worthwhile when the relationships can be written as equations and you want general, exact results. A computational model is needed when the system is too complex, heterogeneous, or interaction-driven to solve exactly, so its behaviour has to be explored by simulation [1].
With a model’s parts and its representational type now in hand, the next section turns to how a modeller actually moves between these types in practice: the modelling cycle.
Key takeaways#
Key takeaways
Most models can be described by three elements: entities, the relationships between them, and the assumptions that bound them.
Every assumption is a hypothesis, so when a model is wrong, the assumptions are the first place to look.
Models come in three types by representation, conceptual, mathematical, and computational, and most projects move through all three.
A computational model can be deterministic (no chance, so it repeats the same path every run) or stochastic (randomness built in, so each run differs), and which one you use shapes how its output should be read.