Abstraction

The process of establishing the decomposition of a problem into simpler and more understood primitives is basic to science and software engineering. This process has many underlying techniques of abstraction.

An abstraction is a model. The process of transforming one abstraction into a more detailed abstraction is called refinement. The new abstraction can be referred to as a refinement of the original one. Abstractions and their refinements typically do not coexist in the same system description. Precisely what is meant by a more detailed abstraction is not well defined. There needs to be support for substitutability of concepts from one abstraction to another. Composition occurs when two abstractions are used to define another higher abstraction. Decomposition occurs when an abstraction is split into smaller abstractions.

Information management is one of the goals of abstraction. Complex features of one abstraction are simplified into another abstraction. Good abstractions can be very useful while bad abstractions can be very harmful. A good abstraction leads to reusable components.

Information hiding distinguishes between public and private information. Only the essential information is made public while internal details are kept private. This simplifies interactions and localizes details and their operations into well defined units.

Abstraction, in traditional systems, naturally forms layers representing different levels of complexity. Each layer describes a solution. These layers are then mapped onto each other. In this way, high level abstractions are materialized by lower level abstractions until a simple realization can take place.

As Hoare [#!Hoare:1994!#] said,

See Figure C.4 on page .

  

Figure C.4: Abstractions

Abstraction can be accomplished on functions, data, and processes. In functional abstraction, details of the algorithms to accomplish the function are not visible to the consumer of the function. The consumer of the function need to only know the correct calling convention and have trust in the accuracy of the functional results.

In data abstraction, details of the data container and the data elements may not be visible to the consumer of the data. The data container could represent a stack, a queue, a list, a tree, a graph, or many other similar data containers. The consumer of the data container is only concerned about correct behavior of the data container and not many of the internal details. Also, exact details of the data elements in the data container may not be visible to the consumer of the data element. An encrypted certificate is the ultimate example of an abstract data element. The certificate contains data that is encrypted with a key not know to the consumer. The consumer can use this certificate to be granted capabilities but can not view nor modify the contents of the certificate.

Traditionally, data abstraction and functional abstraction combine into the concept of abstract data types (ADT). Combining an ADT with inheritance gives the essences of an object based paradigm.

In process abstraction, details of the threads of execution are not visible to the consumer of the process. An example of process abstraction is the concurrency scheduler in a database system. A database system can handle many concurrent queries. These queries are executed in a particular order, some in parallel while some sequential, such that the resulting database can not be distinguished from a database where all the queries are done in a sequential fashion. A consumer of a query which represents one thread of execution is only concerned about the validity of the query and not the process used by the database scheduler to accomplish the query.