A model is a simplified representation of something we want to understand, describe, or build.
The thing being modeled might already exist in the real world, or it might be a system we are planning to create.
A model is not the real thing.
A map is not a city. A floor plan is not a building. A weather forecast is not the weather itself.
Each model represents selected information so that someone can focus on a particular purpose.
Computer systems use the same idea. Before deciding how software should work, it is often useful to create a model of the people, things, information, or activities the software needs to represent.
Imagine a community soccer program.
In the real world, it includes:
Now imagine that the coach wants a computerized system that helps prepare the lineup for Saturday's match.
A model for that purpose might focus on:
The real soccer program contains much more information, but the model does not need to represent everything.
That is one of the most important ideas in modeling:
A useful model includes enough information for its purpose without trying to reproduce the entire real world.
Suppose three people are interested in the same soccer program.
A coach wants to prepare a lineup.
A scorekeeper wants to record goals.
A league organizer wants to schedule fields.
They are looking at the same real-world system, but they need different information.
The coach's model might emphasize:
The scorekeeper's model might emphasize:
The league organizer's model might emphasize:
None of those models is automatically more correct than the others.
Each can be useful if it represents the information needed for its stated purpose.
A model does not have to be a formal diagram.
Early in a design process, the same situation could be represented in several ways.
The Wildcats have a match on Saturday. Jordan and Casey are available. Morgan has not yet responded.
| Player | Position | Saturday availability |
|---|---|---|
| Jordan | Forward | Available |
| Casey | Goalkeeper | Available |
| Morgan | Defender | Unknown |
A quick sketch might show a team connected to several players, with a note beside each player showing availability.
Later, a standardized diagram can represent the same ideas using agreed-upon notation.
The form changes, but the central question stays the same:
What information does this model need to communicate?
A model is easier to understand when you know why it exists and who needs to use it.
Consider a model showing the current position of players during a match.
That model could be helpful to someone analyzing formation and movement.
The same model may be almost useless to someone trying to determine which players still owe a registration fee.
Before evaluating a model, ask:
Those questions prevent a common mistake: judging a model only by how much information it contains.
More detail does not automatically make a model better.
Suppose a player named Jordan has these real-world characteristics:
If the system is helping a coach prepare Saturday's lineup, some of those details are useful.
Others are not.
Leaving out Jordan's favorite music or car does not make the model inaccurate for this purpose.
It makes the model focused.
A model becomes harder to understand when it contains details that do not help answer the question it was created to answer.
Models are not necessarily permanent.
A first model may reveal that an important detail is missing.
A new requirement may make information relevant that did not matter before.
The real system may also change.
For example, a lineup model might begin with player availability. Later, the coach may also need to know whether a player is injured or suspended.
The model can be revised as the purpose becomes clearer.
That is normal technical work.
A model is useful because it helps people reason about a system, discuss decisions, notice gaps, and improve the design before or while the computerized solution is being created.
A model is a purposeful simplification.
It represents selected parts of a system so that someone can understand or work with those parts more clearly.
When you encounter a model in this course, do not begin by asking whether it contains everything.
Begin by asking:
What is this model for, and does it represent the information that purpose requires?