Home Topic 4 Last Next


Distinguish between a real-world entity and its abstraction.


Teaching Note:

TOK The map as an abstraction of the territory.


Sample Question:


JSR Notes:


The real-world entity is the real-world entity. The abstraction is the representation of it. So our decomposition of ISB people into groups and sub-groups is the abstraction. Or the classes of a certain project are the abstraction of a larger real-world problem, which we needed to decompose. And the methods within certain classes are a further abstraction to group parts of the program that can be looked at and worked on via abstraction; i.e. ignoring the other details of the class/project.


Important Abstraction Point (Repeated)

Later on in the middle of 4.3, a sub-section titled "Use of Programming Languages" the curriculum makes a really important point that actually isn't reinforced properly in one place, though it's the whole gist of modular programming - programming divided up into functions. So here's the point and I'm going to make it really really big, so that we make sure we acknowledge all these important "why" of abstraction, i.e. dividing a program up into classes and classes into functions:

Sub-programmes and objects support abstraction, which facilitates: ease of debugging and maintenance, reuse of code, modularity.

This - and the IB CS take on abstraction in general - focuses in more on the basics of dividing a big program up into classes, and dividing a class up into functions - rather than than the subtly different true meaning of abstraction which is filtering out unnecessary information. But that's OK at an introductory level, because it's the dividing a complex system up into classes and methods which allows the filtering away of everything else.

So even at this first introduction of the concept of abstraction, it is important to note these three things. And I'll paste this all again at then end of the official "abstraction" section of the curriculum. And again paste it some place after you fully appreciate how to make different classes, and different functions within them.

- Debugging is easier because you can comment out a function and re-run your code and if the bug goes away, you know part of the problem at least must be in that function. And by the same token you can run a multi-class program, and not use one of the classes, and if the problem no longer exists, you have isolated it to be associated with that class.

- Maintenance is easier, simply because you can work with small chunks of a program rather than working with the whole thing. You can focus in on one particular task and work with it, to greater and lesser extents, in isolation from the distraction of everything else.

- Reuse of Code is facilitated simply because you don't have to write the same code over and over again, rather, in the case of functions, you just call them by name, and in the case of classes (of the "template" kind), you can simply make new instances of them.

- Modularity - basically this is the same thing as abstraction, but by using functions and classes, you can move around them between programs and projects, similarly the way you can install various generic car parts on various models of cars.








From the linked video to this assessment statement, this can be looked at in a very straight-forward way; the sheep is the real-world entity, and the Sheep class, with attributes color, isForWool, and age is its ***particular*** abstraction.

But this is the one thing that it does makes sense to expand upon with this assessment statement a little: that an abstraction is a ***particular*** abstraction; an abstraction depends on the view-point. Because an abstraction is only a representation, or a model, of the real thing, and "unnecessary information" has been filtered away, there's an important question to ask: what unnecessary information has been filtered away? And the answer to that depends on the particular problem being addressed.

In the general example above of map and territory, much was seen as unnecessary; the only things seen as necessary were things like the shape of the territory, the roads, the street names of the territory, and perhaps some of the geographic features of the territory. But another abstraction of the territory might be a Wikipedia article on it. Same territory, very different abstraction of it.

Other examples besides the map example above:

But the point of the examples above in this assessment statement is that the real-world entities are the directory, with all details of each staff, and the whole soccer league; millions of pieces of information. And the abstractions were the particular filtered sets of data pulled from the overall data.


One More Full Example of How Abstraction is up to the "Abstractor" (not so necessary)

Here's one other full example of how the abstraction you choose is based on our viewpoint, the problem you are trying to solve, and so the details you can ignore.

If we were to take the cafeteria full of people at lunch, it's just a mass of noisy humanity, it is not necessarily easily understandable - try to imagine making sense of it if you were an alien who landed and looked around.

Yet, we do make sense of it, and we do so through abstraction. We use our own way of breaking down the individuals somehow, and focusing in on what we want to focus in on. To the cleaner it may be simply by numbers sitting at each table, and the tables with the most numbers will have to have most time spent there cleaning up. And to a teacher, what we could see - i.e. the way we create an abstraction which makes sense to us, is where the various grade groupings are, so we can try to spot if certain kids seem to be left out. Whereas another way to make an abstraction of it would be to look over the collected individuals and simply spot your own friends. The complex situation has thus potentially been understood by abstraction the following ways:

- groups by table, with some tables having more people than others, and the number at each table being the necessary piece of information
The problem to be solved - getting ready to clean tables
how to decompose, i.e. properties - (array of) tables, (int) number of people at each table, (boolean) spoiled ninth grade boys
behaviors - picking up after themselves (or not)
interface - what is seen and heard - generally the more noisy, the more likely to leave a mess; nothing else matters

- groups by grade, so the number of tables and the numbers of people at those tables does not make the difference, rather it's the divisions between the grade groups which is the essence of the organization
The problem to be solved - keeping an eye on grades in general, looking for kids being left out
how to decompose, i.e. properties - (array of) groups of tables, (int) number of people per grade group
behaviour - socializing with each other (which defines the groups)
interface - groups seen, individuals outside of groups seen; nothing else is really interesting

- groups by friends or not - potentially defined by one boolean consideration only: friends or not.
The problem to be solved - finding friends and spending time with them
how to decompose, i.e. properties - individuals who are friends, and everyone else
behaviors - student arriving in cafeteria moving to their friend group
interface - friends are seen - nothing else, whether neat or not students, or students grouped by grade, or anything else is of importance