abstraction (n) - the quality of work with ideas, not events
- source: Oxford English Dictionary
Stroustrup does not apply to abstract classes or other specific ideas in programming. Rather, he refers to the word abstraction itself.
Abstractions are mental helpers. They help us think in "theory", rather than direct application. Mathematics is the art of abstraction. Programming is the art of applied abstractions.
Abstractions help us form mental models, such as hierarchies, to help us think about things. Polymorphism is possible due to abstractions. Consider an example.
Example

I have Oleksiy Dobrodum. I relate to him as the Icy Good, I treat him as Icy Good, and all that he will ever be is Alexey Dobrud. All I do with it is for him. We are now at the first level of abstraction, or the most specific we will ever work with this Oleksiy Dobrodum.
I recently purchased Zach Latta, so now I have both Alex Dobrudum and Zach Latta.

I could apply to them both individually and to Oleksiy Dobrodum and as to Zach Latta, but this would quickly increase and turn out to be not flexible. Instead, we can simply unite Alexei Dobromum and Zach Latta and call them people. Now we have reached the level of abstraction 2. Instead of dealing with each person individually, we can refer to them as people. In doing this, we distracted the "implementation" or specific details of each person and began to focus on ideas, so we now think abstractly.

Of course, we can abstract it further, but I hope you begin to understand the idea of ββabstractions. The key conclusion from this is that abstraction hides details (or implementation). Hiding the details in the abstraction of our People, we allow ourselves to speak in general terms. We will briefly talk about how this applies when programming in the next section.
The use of abstractions
Now that we have touched on what abstraction is, apply it. Polymorphism is possible due to abstractions. Following the model of the previous example, let's say we have the following two classes:
class OleksiyDobrodum name = "Oleksiy Dobrodum" smarts = :mega-smart mood = :happy favorite_candy = :chocolate end class ZachLatta name = "Zach Latta" smarts = :so-so mood = :indifferent hair_color = :brown end
If I want to interact with an instance of ZachLatta , I must refer to it specifically. The same goes for instances of OleksiyDobrodum .
zach = new ZachLatta print zach.name oleksiy = new OleksiyDobrodum print oleksiy.favorite_candy
If I create an abstract class called Human and inherit OleksiyDobrodum and ZachLatta from it, then I can abstract the implementation of both classes and simply refer to both instances of them as Human .
class Human name smarts mood end class OleksiyDobrodum < Human name = "Oleksiy Dobrodum" smarts = :mega-smart mood = :happy favorite_candy = :chocolate end class ZachLatta < Human name = "Zach Latta" smarts = :so-so mood = :indifferent hair_color = :brown end
Our class diagram now looks like this:

I could pounce on implementation forever, but let me move on to our key take-outs.
Key takeaway
- abstractions are ideas, not specific events.
- to abstract from something, you need to move away from its implementation and think about big ideas.
- abstractions can be used to efficiently manage code (and many others)
- object-oriented programming is completely dependent on abstractions. see the above marker point.