abstraction

modelling abstraction

This paper talks about the issues we have to consider when doing abstraction of any sort.  Abstraction is a key part in any software development process - without there is only hacking (even if it is in an XP way), that invariably leads to brittle systems.

Definition and purpose

Abstract = omitting detail.

We cannot deal with more than a few ideas and their relationships simultaneously. By omitting detail, we make it possible to handle the ideas.

Examples: '42' is an abstraction about sets of cabbages, omitting all detail except the size of the set; "result*result=input" is an abstraction about a function, omitting to mention (amongst other things) how the result is to be found; "a distributed financial settlement system" doesn't tell me how to use it; "I slept at Charlie's" omits to mention when, who else was there, and what you talked about over breakfast.

>> Every description is an abstraction.

Abstractions cover many realisations.

Once you've got the idea of '42' or 'stayed at..', you can make inferences about many such cases.

42+2=44, whether cabbages or kings; sleeping at anyone's involves a toothbrush; though there are many pieces of code that implement "result¥result=input", you know that none of them will help do addition.

Abstract != fuzziness.

An abstraction should not necessarily be imprecise about the detail it does mention.

42.0183 is quite precise; "CORBA-compliant" has a fairly definite meaning; "calls are cheaper after 6" sounds a bit ambiguous, but in this case, approximation is perhaps acceptable; "a/b=c/d±1%" has a deliberate degree of approximation.

Abstractions need appropriate notation.

In order to achieve precision, a suitable language is usually necessary, to avoid fuzziness or ambiguity. A natural language can be stretched, but statements become convoluted and ambiguous where the topic is at all complex.

Examples: the language of numbers was invented to abstract cardinality of sets in everyday life, particularly by traders. As programmers, we need to tell computers what to do, and have invented programming languages. As software engineers, we also need to abstract complex behaviour from the means of achieving it. What language do we use?

>> If it becomes traditional in a field to stretch natural language to express its abstractions, young practitioners are brought up thinking that abstract=fuzzy, and say things like "only the final code tells you the real answers". Which is like keeping your money under the bed because you don't believe in bank statements.

You can work with abstractions

if you have a sufficiently precise and appropriate notation for them.

MCDXLIV ÷ XLII is difficult to work out with the wrong notation, and almost impossible with no precise notation at all. But with the right notation, something pretty miraculous happens: by following rules, you can manipulate the symbols in a way that mimics what happens to the things they represent.

WIth arithmetic, you can tell what share everyone will get; with program specifications, you can tell how a composition of software components will behave - the spec really can tell you some of the answers (and the art is to make it tell the most important ones).

Software abstraction examples

System requirements specification	Generic software component in a library
Subroutine spec	Framework
Type, class	Architecture
Pseudocode	Pattern
Performance criteria	Theory (set of statements) about a class or type

Creating and using abstractions

It don't come easy.

Useful abstraction is a generalisation of several cases, which must be understood first. Successful abstraction comes after some experience of concrete examples. (True both when inventing the abstraction, and when explaining it to others.) The best generic software components appear after the same concepts have been used in several projects.

>>The best abstraction has to happen on a cross-project basis.

Document carefully

in order to pass on the benefit. Abstractions are there to be specialised. The inventor should make it plain how to specialise, and what are the criteria for a correct specialisation.

Terms about abstraction

(You may prefer a different set of terms - but let's use these for now.)

Refinement

is a relation between two descriptions, which may be in the same or a different notation.

The idea is that both describe the same thing or concept, but the abstraction contains less information than the realisation.

A description may be both the abstraction of one refinement and the realisation of another.

Although there is less information in the abstraction, it is all true: nothing you can infer from the abstraction (if you interpret what it is saying correctly) can be contradicted by any correct realisation.

Generalisation

is the creative activity of making a refinement by producing an abstraction of a Description.

Specialisation

is the creative activity of making a refinement by producing a correct realisation of a Description.

(The term "to refine" is sometimes used in a very general way, meaning "to improve". So people talk about "refining a spec", meaning modifying it to suit their aims better - which may actually mean making it either more special or more general, or just different.)

Documenting a refinement

means recording the reasons for choosing this realisation from the alternatives (so those that follow won't fall down the same pits you discovered along the way) and writing down a justification for believing you've done the refinement correctly - that is, that the abstraction really does describe the realisation accurately. (Doing this is an invaluable sanity check and helps reviewers and maintainers.)

Since refinement is a many-many relation, the refinement documentation shouldn't properly attach to either the abstraction or the refinement. (For example, a component you find in a library may be a good realisation of your requirements, but will presumably fit others' as well.)

Views.

An abstraction is chosen for a particular purpose; different purposes omitting or including different details. We say that an abstraction is the view for a given purpose when we wish to emphasise that the complete picture is formed by composing all the views together.

For example, a Book could be considered to have a reader's view: its content, price, author; a distributor's view: its weight, size, popularity, price, size of print run; a printer's view: layout, size, content, colours.

Composition

is the job of the designer who must devise something that is a simultaneous realisation of several views.

complete solutions for process definition
(consultancy, courses, workshops, mentoring, seminars, development)