Knowledge abstraction. (bringing software into the problem domain) (includes related article on research in knowledge abstraction problems)

KNOWLEDGE ABSTRACTION It is easy to think of computer science as the study of how to write software programs that will result in computations that solve problems. In other words, computer science answers the questions, what is a computer, and how do you write programs to get it to do what you want?

Aconsequence of such a perspective is that programs are seen as being tied very closely to computers, since their job is to guide computers to behave in particualr ways. Yet an important thread in the history of software development has been the continuing abstraction of programs away from the computer and toward the problem. To track this progression, we first examine the legitimization of programs as objects independent of both the computers they are guiding and the problems they are solving. This will lead to what we claim to be the current step in abstraction--knowledge abstraction.

A HISTORICAL PERSPECTIVE

In tracing the history of software abtraction, such as was done in [53] and [54], it is not possible to pinpoint exactly when an abstraction crystallized from a rough idea. In most cases, people were vaguely aware of the notions behind an abstraction before the abstraction itself was noticed explicitly. So, when we talk about the emergence of an abstraction as if it were an event, we are rally tryning to isolate the point when the under-pinnings for that abstraction were first brought together and found expression as a coherent thought. For a more complete history of the evolution of software design ideas, see Koepke [38], from which many of the historical references have been taken.

Programs were initially written in machine/assembly languages and were thought of as little more than ways of making computers behave as the programmer desired. Programs made general-purpose computers into special-purpose computers, and it was only economic grounds that prevented the equivalent special-purpose computers from actually being built. (It is worth noting that in automata theory, which is the heart of computer science thory, there is no disctinction between machine and programs.)

With programs as little more than behavioral harnesses for computers, it became the job of the programmer to construct such harnesses, that is, to write programs that would lead computers to exhibit the desired problem-level behaviors. The consequences were twoforld: problem information was generally not visible in the program. By the time the problem-level information had been translated into the computer-level instructions of the program, the intent of the instructions with respect to the problem was no longer visible. This lack of visibility of the problem led to programs that were virtually impossible to understand on their own. the software engineering revolution that began in the 1960s was a reaction to this visibility deficit.

Second, programs were not recognized as legitimate intermediate points between the problem and the computer. Like today's microcode, rpgrams at the machine level were seen as little more than a means for tailoring a general-purpose computer to perform problem-specific actions. Like phonograph records, machine-language programs are useful to make a computer "play the tune" that one wants, but not to express the desired tune symbolically.

The first software abstraction, now called the "procedural" abstraction, grew directly out of this pragmatic view of software. Procedural abstraction is the isolation, either as subprograms or macros, of useful sequences of possibly parameterized computer instructions. subprograms were invented prior to 1950 [37, 38, 58, 59], but were not fully appreciated as abstrations at the time.

[I do not] remember from those days [1951] subroutines as objects to be conceived and constructed by the user to reflect his analysis....[24]

Instead, they were originally seen as labor-saving devices.

The labor of drawing up a program for a particualr problem is often reduced if short, ready-made programs for performing the more common computing operations are available. These short programs are usually called subroutines, and may be incorporated as they stand, thus reducing the amount of work which has to be done....[58]

Very quickly though, subprograms were appreciated as a way to abstract program functions [4, …