A Pattern
Definition
Software Patterns
by James O. Coplien
Bell Laboratories
Naperville, Illinois
Patterns are a recent software engineering problem-solving discipline
that emerged from the object-oriented community. Patterns have roots in
many disciplines, including literate programming, and most notably in
Alexander's work on urban planning and building architecture. (Alexander,
1977).
The goal of the pattern community is to build a body of literature to
support design and development in general. There is less focus on
technology than on a culture to document and support sound design.
Software patterns first became popular with the object-oriented
Design Patterns book (Gamma et. al., 1995). But patterns have been
used for domains as diverse as development organization and process,
exposition and teaching, and software architecture. At this writing, the
software community is using patterns largely for software architecture
and design.
Here is a pattern used in Lucent telecommunication products such as the
Switching System® (extracted informally from Adams, 1996).:
Description
Name: Try All Hardware Combos
Problem: The control complex of a fault-tolerant system can
arrange its subsystems in many different configurations. There are many
possible paths through the subsystems. How do you select a workable
configuration when there is a faulty subsystem?
Context: The processing complex has several duplicated subsystems
including a CPU, static and dynamic memory, and several busses. Standby
units increase system reliability. 16 possible configurations (64 in the
4 ESS) of these subsystems give fully duplicated sparing in the 5ESS.
Each such configuration is called a configuration state.
Forces: You want to catch and remedy single, isolated errors. You
also want to catch errors that aren't easily detected in isolation but
result from interaction between modules. You sometimes must catch
multiple concurrent errors. The CPU can't sequence subsystems through
configurations since it may itself be faulty. The machine should recover
by itself without human intervention, many high-availability system
failures come from operator errors, not primary system errors. We want
to reserve human expertise for problems requiring only the deepest
insights.
Solution: Maintain a 16-state counter in hardware called the
configuration counter. There is a table that maps that counter
onto a configuration state. The 5ESS switch tries all side 0 units (a
complete failure group), then all side 1 units (the other failure group),
seeking an isolated failure. When a reboot fails, the state increments
and the system tries to reboot again. The subsequent counting states
look for multiple concurrent failures caused by interactions between
system modules.
Resulting Context: Sometimes the fault isn't detected during the
reboot because latent diagnostic tasks elicit the errors. The pattern
Fool Me Once solves this problem. And sometimes going through all the
counter states isn't enough; see the patterns Don't Trust Anyone and
Analog Timer.
Rationale: The design is based on hardware module design failure
rates (in Failures in a trillion (FITs)) of the hardware modules. The
pattern recalls the extreme caution of first-generation developers of
stored program control switching systems.
This is a good pattern because:
- It solves a problem: Patterns capture solutions, not just
abstract principles or strategies.
- It is a proven concept: Patterns capture solutions with a
track record, not theories or speculation.
- The solution isn't obvious: Many problem-solving techniques
(such as software design paradigms or methods) try to derive solutions
from first principles. The best patterns generate a solution to
a problem indirectly--a necessary approach for the most difficult
problems of design.
- It describes a relationship: Patterns don't just describe
modules, but describe deeper system structures and mechanisms.
- The pattern has a significant human component (minimize human
intervention). All software serves human comfort or quality of
life; the best patterns explicitly appeal to aesthetics and utility.
A pattern language defines a collection of patterns and the
rules to combine them into an architectural style. Pattern languages
describe software frameworks or families of related systems.
Today, the pattern discipline is supported by several small conferences,
by a broad spectrum of activities at established software engineering
conferences, and by a rapidly growing body of literature.
From Dick Gabriel
Various people write things like this:
"A pattern is a proven solution to a problem in a context."
I suppose I cannot argue with the actual words, because they are not
obviously false, but I fear that among the software crowd, especially
the CS-oriented ones, this represents a misconception.
Alexander writes:
Each pattern is a three-part rule, which expresses a relation between
a certain context, a problem, and a solution.
I'm sure that because he wrote this many feel that the rewording
above is a fair copy. I don't think it is. Alexander is capable of
writing simple sentences when the thought he wishes to express is
simple. He could easily have said "a pattern is solution to a
problem in a context" - he uses most of these words already.
But, instead he wrote the paragraph above and he went on to explain:
As an element in the world, each pattern is a relationship between a
certain context, a certain system of forces which occurs repeatedly in
that context, and a certain spatial configuration which allows these
forces to resolve themselves.
As an element of language, a pattern is an instruction, which shows
how this spatial configuration can be used, over and over again, to
resolve the given system of forces, wherever the context makes it
relevant.
If you walk into a room and you ask Alexander to list all the patterns
he sees, he will not look for sheets of paper with patterns written on
them, he will look at the room and tell you the ones he sees in the
spatial configuration. Similarly, if asked what patterns there are in
a software system, an astute patterns person will look at the code and
try to list them off.
Each pattern is both a statement in a pattern language and a
configuration in a program. I don't think the words in the first quote
above capture that. For example, according to it a pattern might be:
Problem: How do you allocate objects in memory?
Context: A large OO system in a virtual memory computer.
Solution: Run some typical problems and figure out which
objects communicate frequently in a time locale
and put them on the same page.
This is not a pattern. It is merely a solution to a problem in a
context. It can be made into a pattern by talking about configurations
of objects that communicate according to a particular definition of
efficiency in a virtual memory system. One can imagine other things
that might be a pattern according to the over-simple definition, such
as the way to figure out the number of things in a "this many sets of
this size" problem is to use multiplication.
Alexander could have written a 1-sentence definition of what a pattern
is, or an essay, but instead he wrote a 550-page book to do
it. Because the concept is hard.
I would prefer to see a definition that was more mysteriously worded
with a reference to a longer piece, such as
Each pattern is a three-part rule, which expresses a relation between
a certain context, a certain system of forces which occurs repeatedly in
that context, and a certain software configuration which allows these
forces to resolve themselves. [See "A Timeless Way of Hacking."]
|