Software Engineering Seminar

GT-SARG (Georgia Tech Software Architecture Reading Group)

CS 8112 Winter Quarter 1995
Moderator: Gregory Abowd

Return to GT-SARG topic overview

19 January - What are Patterns?

Moderator: R. Clayton

Among the definitions Webster's Ninth New Collegiate Dictionary gives for "pattern" are "a form or model proposed for imitation" and "a discernible coherent system based on the intended interrelationship of component parts". Although both describe pattern, the two definitions are different. The first is small scale and definite, and describes something utilitarian; the second has a global scale, is open to interpretation, and describes something of indefinite use.

I take these two definitions as the ends of a spectrum of views about software (or architectural or design) patterns, and call the "form or model" end the object-oriented end and the "discernible coherent system" end the Alexander end. The purpose of the discussion was to consider various points along the spectrum and examine the nature of the associated pattern.

Readings

  1. Peter Coad, "Object-oriented patterns," Communications of the ACM, Vol. 35, No. 9, September 1992, pages 152-159.
  2. Richard P. Gabriel, "Pattern languages," Journal of Object-Oriented Programming, January 1994, pages 72-75.
  3. Richard P. Gabriel, "The failure of pattern languages," Journal of Object-Oriented Programming, February 1994, pages 84-88.
  4. David Garlan and Mary Shaw, Chapters one through three of their forthcoming book on software architecture.
  5. Wilf LaLonde and John Pugh, "Communicating reusable designs via design patterns," Journal of Object-Oriented Programming, January 1995, pages 69-71.
  6. Douglas Lea, "Christopher Alexander: An introduction for object-oriented designers," ACM SIGSOFT Software Engineering Notes, Vol. 19, No. 1, January 1994, pages 39-45.
  7. Robert Martin, "Patterns: PLoP, PLoP, fizz, fizz," Journal of Object-Oriented Programming, January 1995, pages 7-12.
  8. Dewayne E. Perry and Alexander L. Wolf, "Foundations for the study of software architecture," Software Engineering Notes, Vol. 17, No. 4, October 1992, pages 40-52.
Garlan (4) and Perry (8) were assigned; Gabriel (2), LaLonde (5), and Martin (7) were recommended; Coad (1), Gabriel (3), and Lea (6) were optional. In attendance at the discussion were books by Christopher Alexander (A Pattern Language, Oxford University Press, 1977), James Coplein (Advanced C++ Programming Styles and Idioms, Addison-Wesley, 1992), and Erich Gamma et. al, (Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995).

The foregoing readings are weighted toward the object-oriented end of the pattern view spectrum. To represent the Alexander end, references to the papers from the Pattern Languages of Programs conference were given but otherwise unmentioned.

Reading Summary

Coad, "Object-oriented patterns"
After presenting some good motivational quotes from Alexander, Coad goes on to describe eight patterns commonly found in object oriented systems.
Gabriel, "Pattern languages"
A motivation for patterns based almost entirely on Alexander.
Gabriel, "The failure of pattern languages"
An analysis of Alexander's post mortem on his Pattern Language for building architecture.
Garlan And Shaw, Chapters one through three
The first chapter examines engineering in general and software engineering in particular, simultaneously trying the make the case that software engineering could be real engineering and trying to figure out how to make it so. The second chapter presents a number of software architectural patterns. The third chapter presents examples of systems being described by architectural patterns.
LaLonde And Pugh, "Communicating reusable designs via design patterns"
An example of how patterns can be discovered by examining existing code. LaLonde and Pugh discover the bridge pattern by generalizing the way IBM SmallTalk implements sets.
Lea, "Christopher Alexander: An introduction for object-oriented designers"
Another introduction to patterns motivated by Alexander, this time for object-oriented programmers and designers.
Martin, "Patterns: PLoP, PLoP, fizz, fizz"
A practitioner attends the Pattern Languages of Programming conference and tells us all about it. Martin also gives an example of how patterns are used to create a software system.
Perry And Wolf, "Foundations for the study of software architecture"
Another object-oriented description of patterns, this time with an eye towards organizing them to make it easy for software designers to search for relevant patterns.

Discussion Summary

The discussion began with Coad's paper and, in particular, the Alexander quotes in the paper. The quotes state that the essence of repetition is not the repeated elements, each of which is usually different from the others, but the repeated relations between the elements. Discussion then went to Gabriel's pattern language paper and his presentation on the way patterns are composed. Also of use was Gabriel's distinction between creation and description and reminder that software development involves both.

The discussion moved along, examining various aspects of what patterns may or may note be when suddenly, without warning, a discussion erupted over what kind of patterns would be useful in reverse engineering. The objective was to take existing code and run it through a program that would try to recognize patterns. The objective of the program would be determine if the code was well structured according to some set of patterns, and to derive some meaning from the code's structure. Discussion focused on determining how it would be possible to recognize pipe and filter and model, view, controller patterns. The dominant issue seemed to be if it were possible to build an entirely syntactic recognizer or whether it would be necessary to add some semantics (by, for example, looking at messages). The defense for syntax only was vigorous, but was outnumbered by those favoring at least some semantics.

A recuring theme through out the discussion was the veracity and validity of the patterns given in the various papers. There was all-around derision for the weak quality of the experiences section of Gamma et al.'s paper and book, but it was noted that the book claims to include only patterns that have been found in at least two software systems. Echoing Martin's paper, there was a general dissatisfaction with hard evidence that patterns improve programmer productivity or software quality.

The discussion then turned to possible analogies between software styles and art styles. The motivation came from an overheard conversation between two engineers talking about some code written in a style they were unfamiliar with. The engineers were having trouble understanding the code, leading to the guess that people schooled in one style would have difficulty when faced with a different style, much as the classically trained audience had trouble with cubism.

The analogy as it stood didn't stir much interest, but seemed worth pursuing and so was presented as an example which might bring it closer to home. A functional programmer writing in Pascal might produce a program that a "classically trained" Pascal programmer would find hard to understand because it might, for example, be heavily recursive and have few if any local variables. There were some questions over the issue of local variables, and while they were being explained a side discussion flared up about whether bowl of spaghetti/stream of consciousness code could be considered a style. It was eventually decided that it was not a style, because the only way to describe it was to present the actual code. By tacit mutual consent, the issue of local variables was not resumed.

In the waning moments of the seminar, the point was raised about the absence of handbooks for programming, echoing the chemical engineer's lament in chapter 1 of Garlan and Shaw. This raised the related question of the utility of such handbooks for programmers. The negative example random number generators was brought up: Knuth wrote the book on random number twenty five years ago, but yet people still write terrible random number generators (see, for example, "Random number generators: good ones are hard to find", by Park and Miller, Communications of the ACM, Vol. 31, No. 10, pages 1192-1201).

The example was not well received, but the reasons for objecting were unclear. Most of the blame seemed to be Knuth's for writing the Art of Computer Programming the way he did, although one person admitted that perhaps education should share part of the blame. It seemed sensible to distinguish between trained and autodidactic programmers, but this distinction was immediately hooted down. Since time was growing short, things were left as they were.