Abstraction

Information management is the goal of abstraction. Good abstractions can be very useful while bad abstractions can be very harmful. A good abstraction system architecture leads to reusable components.

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 [Hoa94] said,

The major achievement of modern science is to demonstrate the links between phenomena at different levels of abstraction and generality, from quarks, particles, atoms and molecules right through to stars, galaxies, and (more conjecturally) the entire universe. On a less grand scale, the computer scientist has to establish such links in every implementation of higher level concepts in terms of lower. Such links are also formalized as equations or more general predicates, describing the relationships between observations made at different levels of abstraction.

The general technique for crossing a level of abstraction is to define the way in which an observation at one level of abstraction corresponds to one or more observations at the other level. This relationship can itself be described by a predicate (often called a linking invariant) which relates an abstract observation a (in the alphabet of the specification) to a more concrete observation c (in the alphabet of the implementation).

See Figure  on page  .

  [IMAGE ]
Figure: Layers of Abstraction

Abstraction naturally forms views representing different ways in which the solution can be presented. Each view describes a solution. These views coexist. One view is not layered on top of another view but rather a language expresses one view in terms of another view.

One view becomes the physical representation and the bases for all other views. The other views are then expressed by using a language. See Figure  on page  .

  [IMAGE ]
Figure: Views of Abstraction

For example, consider a relational database. There is one physical table architecture. With the aid of SQL you can express views of these tables. The view table is not physical but logical. In some sense, it coexists with the other tables.

There is not just one view of abstraction in a system, but many views. Each view describes the solution from a particular perspective. A view language maps one view onto another. See [Com95a], [Com95b], [Com95d], [Com95c].

• Enterprise View
• Information View
• Computational View
• Infrastructure View
• Technology View