Worth a Thousand Words
James O. Coplien, Bell LabsC++ Report 10(5), May/June 1998, ff. 54
Introduction
In my March column, I underscored the geometric nature of patterns, and pointed out that Nature of Order [Alexander1997A]--Alexander's forthcoming work--underscores this aspect of patterns that has been there all along. And Alexander has always emphasized the importance of a sketch as the essence of a pattern, a point I've emphasized in many past columns.
Many contemporary patterns lack pictures or, if they do have sketches, they are cast in standard design notations. These design notations can't communicate what Alexander wants to communicate in a sketch--that's one of the points we'll address in this column.
Pictures portray structure. Some early software patterns are about little more than data structure. But patterns are more than that--they are also a process that tells us how to make the thing in the picture, that tells us what problem it solves.
So every pattern sketch comes with a process--a text that tells us when we must build the thing depicted in the sketch, and how to build it. There are some principles behind these processes, deeper, more general processes of piecemeal growth. Those, too, were described in the March column.
It's process that distinguishes useful patterns from patterns that we simply observe in the world around us. The process part of these pictures is the first step to generativity, and generativity is a first step to solving difficult problems. The sketches of a pattern language combine to build emergent structures we can't foresee in individual patterns. The sketches, and the processes that combine them, are tied closely together. So it was in Alexander's early work; we'll look at that below, too.
But first, we need to look at sketches and geometry, motivated as important system elements in the March column. Let's start there.
The sketch
Alexander emphasizes again and again the importance of the sketch for a pattern, a point I've emphasized in this column many times. Alexander's concern for geometry helps bring this emphasis into focus. The sketch shows not only the major relationships between parts--which is the facet of patterns that perhaps most interested the object-oriented software community--but it relates directly to our sense of aesthetics. People share the cognitive processes by which they appreciate beauty, and the sketch appeals to that universal sense of aesthetics.
The software designer is no stranger to design diagrams using standard notations. How are Alexander's sketches different from OMT or UML or Booch notation? My colleague Joe Davison has an interesting theory: he notes that OMT diagrams don't easily compose, whereas sketches do. (Try composing OMT diagrams for two patterns you use together.) Such composition is fundamental to piecemeal growth, and I think our current notations are antithetical to such an approach to software. I recently evaluated an OOA/OOD course from a prominent vendor: software maintenance was conspicuous by its absence.
Alexander's early work [Alexander1984] portrayed system structure in a simple set of composable diagrams. Each element not only captured a geometric structure, but encoded requirements addressed by the element. For example, in his work on Indian villages, the element:
is a demonstration farm that embodies requirements such as getting the best cotton and cash crop, the best food grain crop, a good vegetable crop, that reflects the fact that crops must be brought home from the fields, that improves the quality of fodder available, demonstrates projects that spread by example, that gives more power and respect to the Panchayat, etc. This element:
is a water distribution system for the fields; it captures requirements such as the need to divide land among sons of successive generations, the desire of people to own land personally, cooperative farming, maintenance of irrigation facilities, and abolition of Zamindari and uneven land distribution. And the element:
is a water collection unit built in the highest corner of the village at right angles to the terrain. It's designed to reclaim uncultivated land, develop horticulture, to accommodate full collection of underground water for irrigation and monsoon water for use, to drain the land to prevent waterlogging; to support a healthy plant ecology, to address road and dwelling erosion, etc. The small filled circles are springs or wells.
These elements can be combined into a village:
Each drawing isn't just a sketch, but has behind it a set of requirements that come together in the structure representing it. The structure of a village brings together these elements to minimize conflict between requirements. Alexander guides this integration by making a graph of the dependencies between requirements; the village structure emerges from the graph. That is, there is a process for assembling these elements in meaningful ways, a process that is germane to the elements themselves.
Note that, at a fundamental level, this is analogous to principles deep beneath the object paradigm. Parnas' original work on modularity emphasized that modules hid "design secrets," which strikes me as similar to the way Alexander's pictures emobody design constraints [Parnas1978].
This formative work of Alexander led to patterns and later to his theory of centers; the same themes recur in each of these manifestations. For example, we see a foreshadowing of forces in the encapsulation of requirements dependencies in each of these elements, and we see the geometric groundwork that would play out to a degree in patterns and more strongly in Nature of Order. And we see a strong process presence in each stage of development. One factor common to the above notation and to patterns is the cultural sensitivity of the design elements. The theory of centers is more universal in scope.
I thought a long time about what it would mean to carry these recurring themes into software, particularly with the emphases brought forth in the theory of centers. Alexander postulated criteria to judge whether such a theory for software would capture what he wanted to capture in architecture:
In effect, the core software issue is this, I think: I have been wondering what kind of entity there is--if one had to choose a type of entity of which it could be said that it is the only component, the essential and single component of all computer programs, what is it?Is it a function?
Is it a list?
Is it (probably) something else?
Could one say that every successful program is a function of functions?
Could one say that every successful program is a list of lists (lambda calculus)?
In architecture, anyway, there is such a thing because one can say, accurately and truthfully, that every building is a center made of centers. That is one of the key insights in Nature of Order. Indeed in 3-D space, every living structure is a center made of centers. But software structures do not live in 3-D space.
So for software structures one must ask: What kind of x is there that makes it true to say that every successful program is an x of x's?
That is the only question which will let us find out what the equivalents of centers in software--really are. It is only when we begin to identify such an x, that the whole domain of possible programs would become visible, in a meaningful way. [Alexander1997B]
Might it be reflection? Instantiation (including recursion)? Recursion itself? I thought about this for a while, focusing on Alexander's earlier suggestion to me that a theory of beauty in software would parallel the theory of centers only if the "space" on which it were based comprised dimensions with homogeneous units. It couldn't be time in one dimension, space in another, features in another, and so forth. I conceded that geometry itself--the space of the code on the page--was a good starting point. A great program is a center of centers, and the centers are geometric.
And then I took things a step further to deal with the predominate computer science models that are preoccupied with time and space. Data structures are spatial, but functions are temporal (follow the bouncing program counter through time). Program visualization techniques have long portrayed the temporal dimension of program in spatial renditions. I theorized that functional languages might provide a good formalism to fold the time dimension back into space.
That's where I was at when I wrote the March column. Alexander responded:
I found your article, and your idea about the spatial structure of a computer program rather amazing. At first I thought, this cannot be, it seemed trivial--and then it began to dawn on me that it might be true, there was more structure than I had expected, visible in that form--and it might indeed give real clues as to the goodness of the program. Your report on Dick Gabriel's work is also very enlightening in this regard and I am delighted he is getting such good results... [Alexander1997C]
And that brings us up to this column, where we scrutinize geometry a bit more and consider the relationship between sketches, patterns, and the theory of centers.
Beyond HOPP
After I wrote my last column, I went back and revisited the sketches in Gerard Meszaros' HOPP [Meszaros1996]. You'll remember that I portrayed HOPP like this:
What's missing in this diagram? If you look at the picture, the place where the two HalfCalls interact is itself a latent center. This makes sense from an application perspective: the coordination of the activities of two half calls is an activity--a center--in its own right. In the text of HOPP, Gerard chose to use the word "between" (instead of, for example, "connecting") to describe the Protocol that is the final "P" in HOPP. And the original picture begs to make the center explicit.
My colleague Warren Montgomery took a look at this and noted:
Half objects are 1-1 and almost always asymmetric in responsibilities and initiative. Call models can have grouped relationships and be symmetric.
Let's rework the picture to emphasize these geometric properties of the pattern. We apply a structure-preserving transformation that increases the wholeness of the system; in this case, we do so by making the latent center explicit. We might better depict HOPP like this:
I've also added the objects (the black blobs) that interact with the HalfCalls as Gerard shows in the original version of HOPP. And the model is now more symmetric about "call." This is important; in his mail, Warren went on to point out:
Making the model symmetric, if you can, leads to great simplifications. [A system I worked on] started out symmetric, no notion of originating and terminating terminal processes, just terminal processes. The call protocols were all symmetric. This made it very easy to take the next step of going to multi-party calls......
...the hardware...defined something called a tiepoint and everyone connected to a tiepoint was magically conferenced together... No worrying about adding bridges and re-doing connections, just add people to tiepoints and the call goes from 2-way to 3-way to n-way automagically...
...
Communication among the half calls on the same terminal started out being implemented through variables in terminal data structures, which was ad-hoc, and asymmetric with respect to the communication with half calls on the same call. The limitations quickly became apparent as we started to do more features that caused 3 or more calls to appear on a terminal at one time. The terminal multicast also formed a symmetry with respect to the tiepoint multicast that satisfied some sense of a need for closure...
...
...I... drew the conclusion that
The result again has symmetry, wildcarding in both dimensions, actions on enter and leave, state and input equally... [Montgomery1998]
- state machines are best handled by double dispatch from one reception point;
- State machines need ways to wildcard on both state and input...
- The utility of enter/leave actions that take place always on entering or leaving a state no matter how you get there became obvious as well.
As a practical consideration, you need a Call center between the HalfCall centers. Why? For the same reason that airlines have hub cities--it makes call routing more straightforward while reducing the need for complete network connectivity. This is called three-part call processing or global call processing, a common pattern of telecommunications software architecture. Each HalfCall handles the "half" of a call for a particular subscriber, and Call itself provides the communication between them. In feature-rich systems, Call may be more than a connection between two HalfCalls, functioning much like the human operator in antique telephone systems.
When one brings these considerations of symmetry down to the nuts and bolts of telecom software, patterns emerge. Patterns are just culturally sensitive centers. Bob Hanmer in Lucent Technologies has written up this pattern:
Name: 3 Part Call ProcessingAlias: Add A Switch
Problem: Efficient interfacing between many signaling types.
Context: Toll switching where each switching center must communicate with many various signaling types.
Forces: Want flexibility to interwork between any signaling types.
More signaling types are being developed constantly.
There are some common functions that are signaling type independent.
It is expensive to make changes to every existing signaling type to add new functions.
Want centralization and standardization, for ease of maintenance and to facilitate understanding.
Solution: Distribute call processing into something that can be processed by three separate pieces: Incoming trunk handling, Outgoing trunk handling, and non-trunk specific (common) pieces.
Resulting Context: The parts of the software that know about signaling types only need to know about the ones that they process. They have been isolated from all other signaling types.
Non signaling specific types of functions are concentrated into separate modules for ease of maintenance.
Sketch
Rationale: Easily extensible. To add new signaling types, add the trunk handlers and make minor changes to some common functions.
This pattern applies for the same reason that we have telephone switches--the complexity of direct connections between each node in a network.
Author: Robert Hanmer, 5/9/1995
Reference: P. D. Carestia, F. S. Hudson. No. 4 ESS: Evolution of the Software Structure, BSTJ, Vol 60, No. 6, Part 2. [Carestia+1981]
With an explicit Call center, we can easily add more HalfCalls onto the call. Each HalfCall still handles the interactions with its own subscriber, while the Call center again functions like the operator. For a three-way call, we might have a picture like this:
Here, I've reshaped Call to more explicitly show how it connects the HalfCalls together (who says objects have to be round?) The call as a whole emerges as a center.
The parts are composable. Some of them, like Call, carry important design meaning. The figure emerges as a result of several processes--the process of design, and the process of three phone subscribers setting up a three-way call.
Should we call this some kind of notation? Maybe. I'm proposing we hold a "centers painting workshop" at EuroPLoP this year with the guidance of our Lateral Thinking Coordinator, George Platts. It seems a useful way to put down on paper the way we think about programs. Maybe it's an avenue to give dignity to the chalkboard diagrams we all do, whose folk semantics are discarded in the translation to most formal notations.
Can we see this structure in the source code? Unfortunately not, or at least not easily, for most programming languages and environments. But perhaps there is a programming paradigm, or language, where this structure is visible in the source. It's crucial to make the symmetries visible. Such an environment might provide a radical departure from the common patterns of contemporary software development. Such an environment might also fold aspects of process into the geometry of the program as well, as Alexander intended that his Indian village diagrams should communicate requirements and intent. I believe that one research challenge for the pattern community today is to explore what such an environment would look like. I'll talk more about that in the July/August C++ Report.
Signposts
Well, that's it for this month. C++ Report asked me to start limiting my columns to about 2000 words each (they usually run about 5000 words). But with this article, you get nine pictures worth the proverbial 1000 words each.
In the next article, I'll further explore the concepts of recursion, iteration, instantiation, and other ideas important to software geometry.
See you at EuroPLoP, July 9-11. Start polishing up your papers for U. S. PLoP, August 11-14.
References
- Alexander, Christopher. The Determination of Components for an Indian Village. In Nigel Cross, ed., Developments in Design Methodology. Chichester: John Wiley and Sons, ©1984, 33-56.
- Alexander, Christopher. The Nature of Order, draft.
- Alexander, Christopher. Personal correspondence of December 11, 1997.
- Alexander, Christopher. Personal correspondence of December 28, 1997.
- Carestia, P. D., and F. S Hudson. No. 4 ESS: Evolution of the Software Structure. Bell System Technical Journal 60(6):1167-1201, July/August 1981.
- Meszaros, Gerard. "Pattern: Half-Object + Protocol (HOPP)". In [PLoP1995].
- Personal correspondence with Warren A. Montgomery, 9 January 1998.
- Parnas, David L. Designing Software for Ease of Extension and Contraction. Proc. 3rd Int. Conf. Soft. Eng., May 1978.
- Vlissides, John, Norm Kerth and James Coplien, eds. Pattern Languages of Program Design--2. Reading, MA: Addison-Wesley, ©1996.
