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.
'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
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.
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
abstraction should not necessarily be imprecise
about the detail it does mention.
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.
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
Software abstraction examples
|System requirements specification
||Generic software component in a library
||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
- 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.)
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.
Is the creative activity of making a refinement
by producing an abstraction of a Description.
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.)
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,
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)