A real-world situation contains an enormous amount of detail.
A computerized system usually needs only part of it.
Choosing which details matter for the current purpose is called abstraction.
Abstraction does not mean making information vague or inaccurate.
It means focusing on the details that help the system accomplish its purpose and intentionally leaving out details that do not.
Imagine that a soccer coach wants a system that answers this question:
Which players can participate in Saturday's match?
The question gives the model a purpose.
Now consider these details about a player:
Some details immediately appear more useful than others.
The player's availability clearly matters because it directly helps answer the coach's question.
The player's name matters because the coach needs to know which person the availability belongs to.
The player's team may matter if the system handles more than one team.
A favorite movie probably does not help answer the question at all.
The important point is not that some information is universally important and other information is universally useless.
Relevance depends on purpose.
Consider a player's jersey number.
For the lineup system, the player's name might be enough to identify the person.
For a match-reporting system, the jersey number could become much more useful because a scorekeeper might see number 7 score a goal before knowing the player's name.
The information did not change.
The purpose changed.
That is why abstraction always begins with the problem the system is trying to solve.
Once the purpose is clear, identify the important things in the situation.
For the lineup example, useful things might include:
Notice that these are not just vocabulary words from the soccer world.
They are things the computerized system may need to distinguish from one another.
A specific player has information of their own.
A specific match has information of its own.
A specific team has information of its own.
That distinction becomes important as models become more structured.
After identifying the important things, consider what the system needs to know about each one.
For a player, the lineup model might need:
For a match, it might need:
For a team, it might need:
This does not mean those are the only possible details.
They are simply examples of information that supports this purpose.
A useful abstraction is selective.
Sometimes the important information is not only about individual things.
It is also about how they are connected.
For example:
Those connections help the model answer questions that isolated facts cannot answer by themselves.
Knowing that Jordan is available is useful.
Knowing which team and match that availability belongs to may be necessary for the information to make sense.
Some systems need to represent what can happen as well as what exists.
A player can report availability.
A coach can review the available players.
An organizer can schedule a match.
At this point, you do not need to design those actions in detail.
Just notice that a system purpose can require information about:
Different models emphasize different parts.
A common modeling mistake is to include information simply because it might someday become useful.
For example:
We should store every player's favorite restaurant because maybe the team will organize a dinner someday.
That future possibility does not automatically make the information relevant to the current lineup system.
Adding unnecessary information creates work.
The system may need to:
Good abstraction resists that pressure.
Represent what the current purpose actually needs.
The model can be revised later if the requirements change.
Abstraction does not mean removing detail until almost nothing remains.
Suppose the model stores only:
Jordan — Available
That might be enough in a tiny one-team example.
But if the system manages several teams and several matches, the information may be ambiguous.
Available for which match?
On which team?
A focused model still needs enough context to support the purpose accurately.
Abstraction is a balance:
Remove irrelevant detail without removing information needed to understand the situation.
When deciding whether a detail belongs in a model, keep asking:
These questions move modeling away from “include everything we can think of” and toward intentional design.
A computer does not automatically know which real-world details matter.
People make that decision.
That means abstraction requires judgment.
Two designers might begin with slightly different models and then discuss which information is actually required.
The strongest argument is not:
I like my version better.
It is:
This detail is necessary because the system must use it to accomplish this stated purpose.
That connection between purpose and represented information is the foundation of useful modeling.
Abstraction is the process of deciding what matters for the current purpose.
A good model does not try to capture everything about the soccer program.
It captures the parts needed to answer the question the computerized system is responsible for answering.