Abstraction - Another Part of Methods

Abstraction ”Another Part of Methods

Abstraction had a longer genesis. Throughout the 1950s, while subroutines came to be better known, the concept of abstraction was rarely used. There were large systems built in the Western Hemisphere at this time, such as the air defense program Semi-Automatic Ground Environment (SAGE). Eventually, in the early 1960s, computer scientists started to discuss stepwise refinement as a way to reduce complexity.

This was the origin of abstraction. The highest level of a program s development is also its highest level of abstraction. As the program is stepwise refined, the abstractions are closer to reality. As an example, a program may add two numbers. At the next level, two numbers are input, added together, and one is output. Therefore, there are three parts to that abstraction. If we work just on the input part, we can establish a range, verify that range, and so on. If we are doing the adder , we can only worry about how two numbers get to the next abstraction. We do not have to worry about establishing the range, testing the numbers , or any messages. The developer of that abstraction can hide that information from us.

Task  

Look at several textbooks that deal with programming and other books about abstract data types. How do they define abstraction? In what sense is abstraction important in computer science in general?

In the early 1970s, both of these concepts could be formalized . Parnas wrote his article. Barbara Liskov of the Massachusetts Institute of Technology (MIT) first drew attention to abstraction in a formal way [Liskov74].

At about this time, the term software engineering became prevalent . It seems to have first been used by the organizers of the 1968 North Atlantic Treaty Organization software conference in Garmisch, West Germany to spark debate [Naur and Randell69]. There is evidence that Douglas Ross used it earlier in a course at MIT [Ross88]. It is ironic to read the proceedings of this conference nearly four decades later and realize that most attendees went to learn other people s solutions, only to find that everyone had the same problems.

More about abstraction, and especially on its practical aspects, can be found in Chapter 11, Abstraction and Other Heuristics of Software Development.