The following is the guest editorial for the Communications of the ACM, Special Issue on Patterns and Pattern Languages, Vol. 39, No. 10, October 1996.
Mature engineering disciplines have handbooks that describe successful solutions to known problems. For instance, automobile designers don't design cars using the laws of physics. Instead, they reuse standard designs with successful track records. The extra few percent of performance available by starting from scratch typically isn't worth the cost.
The theme of this issue is ``patterns'' and ``pattern languages'', which are an attempt to describe successful solutions to common software problems. The long term goal is to develop handbooks for software engineers. Though we are a long way from that goal, patterns have proven useful in the short term to help people reuse successful practices. Not only do patterns teach useful techniques, they help people communicate better, and they help people reason about what they do and why. In addition, patterns are a step toward handbooks for software engineers.
A pattern is a recurring solution to a standard problem. When related patterns are woven together they form a ``language'' that provides a process for the orderly resolution of software development problems. Pattern languages are not formal languages, but rather a collection of interrelated patterns, though they do provide a vocabulary for talking about a particular problem. Both patterns and pattern languages help developers communicate architectural knowledge, help people learn a new design paradigm or architectural style, and help new developers ignore traps and pitfalls that have traditionally been learned only by costly experience.
Patterns have a context in which they apply. In addition, they must balance, or trade off, a set of opposing forces. The way we describe patterns must make all these things clear. Clarity of expression makes it easier to see when and why to use certain patterns, as well as when and why not to use these patterns. All solutions have costs, and pattern descriptions should state the costs clearly.
From one point of view, there is nothing new about patterns since by definition patterns capture experience. It has long been recognized that expert programmers don't think about programs in terms of low level programming language elements, but in higher-order abstractions [Adelson and Soloway][Soloway and Erlich][Curtis][Linn and Clancy]. What is new is that people are working hard to systematically document abstractions other than algorithms and data structures. In general, most people working on patterns are not concentrating on developing formalisms for expressing patterns or tools for using them, though a few people are. Instead, they are concentrating on documenting the key patterns that successful developers use, but that relatively few developers thoroughly understand and consistently apply in their daily work.
Most of the people documenting patterns are motivated by the following values:
The longer a pattern has been used successfully, the more valuable it tends to be. In fact, novelty can be a liability, because new techniques are often untested. Finding a pattern is a matter of discovery and experience, not invention. A new technique can be documented as a pattern, but its value is known only after it has been tried. This is why most patterns describe several uses.
Most pattern descriptions document recurring solutions using a standard format. We look forward to the day when we will have handbooks for software engineers. Therefore, we write our patterns in a form that is like a catalog entry. In this sense, pattern descriptions are both a literary style and technical documentation.
The emphasis on clear writing stems from our collective experience developing complex software systems. In many cases, projects failed because developers were unable to communicate good software designs, architectures, and programming practices to each other. Well written pattern descriptions improve communication by naming and concisely articulating the structure and behavior of solutions to common software problems.
Another part of our ethic is to qualitatively describe concrete solutions to software problems, instead of quantifying or theorizing about them. There is a place for theoretical and quantitative work, but we feel such activities are more appropriate in a context separate from discovering and documenting patterns. Our goal is to appreciate and reward the creative process that expert developers use to build high quality software systems.
Every experienced developer has valuable patterns that we would like them to share. We value the experience of all software developers, and do not think that a few people have the patterns, and everybody else just sits back and learns them. That is why our use of writer's workshops have been so successful at pattern conferences. In a writer's workshop, participants discuss the strengths and weaknesses of each pattern, accentuate positive aspects of the patterns, share their own experience, and suggest improvements in content and style. Writer's workshops assume that we all can learn from each other.
The purpose of patterns is not to replace developer creativity with rote application of rigid design rules. Neither are we trying to replace programmers with automated CASE tools. Instead, our intent is to recognize the importance of human factors in developing software. This recognition appears in design patterns when we discuss their effect on the complexity and understandability of software systems. In addition, this recognition shows itself in patterns on effective software process and organization.
The papers in this issue are a good representative of the patterns being written today. The first software patterns were written by object-oriented developers, so they focused on object-oriented design and programming [GOF] or on object-oriented modeling [Coad]. Although there is still a lot of interest on object-oriented patterns, a new trend is patterns that focus on efficient, reliable, and scalable concurrent, parallel, and distributed programming [PLoP2,Schmidt1,SIEMENS].
The majority of papers in this special issue follow the latter trend. McKenney's paper on ``Selecting Locking Primitives for Parallel Programs'' describes a set of patterns used to build efficient operating systems for multi-processor platforms. Islam and Devarakonda's paper on ``An Essential Design Pattern for Fault-Tolerant Distributed State Sharing'' focuses on a design pattern used to create reliable distributed software. Aarsten, Brugali, and Menga's paper on ``Designing Concurrent and Distributed Control Systems: An Approach Based on Design Patterns'' presents a pattern language for developing distributed software for large-scale control systems.
Another recent trend in the patterns literature focuses on management, sociological, and organizational issues. Two papers in this issue address these topics. Cockburn's paper ``On the Interaction of Social Issues and Software Architecture'' describes a pattern language that illustrates how social forces affect the decisions that shape the structure of software designs. Goldfedder and Rising's paper on ``Patterns: A Training Experience'' discusses the organizational and sociological aspects of introducing patterns into a commercial software development environment.
The study of patterns is well established in many other fields including architecture, anthropology, music, and sociology. Early adopters of software patterns were highly influenced by Christopher Alexander, who is a researcher at University of California, Berkeley that has written extensively on patterns found in architecture for houses, buildings, and communities.
As we have gained experience using patterns to document software expertise, new formats and new solutions have arisen to meet the unique challenges associated with developing software. For instance, many developers find it easier to understand design patterns by using software-centric visual aids such as class models and interaction graphs. Therefore, many pattern description formats use popular notations (such as Booch models and OMT) to concisely express their structure and dynamic behavior. In addition, pattern descriptions also commonly contain source code examples, written in the language of choice for the audience.
Over the next few years, we expect the following aspects of patterns will receive considerable attention [Schmidt2].
Some of the most useful patterns describe frameworks. Such patterns can be viewed as abstract descriptions of frameworks that facilitate widespread reuse of software architecture. Similarly, frameworks can be viewed as concrete realizations of patterns that facilitate direct reuse of design and code. One difference between patterns and frameworks is that patterns are described in language-independent manner, whereas frameworks are generally implemented in a particular language. However, patterns and frameworks are highly synergistic concepts, with neither subordinate to the other. The next generation of object-oriented frameworks will explicitly embody many patterns and patterns will be widely used to document the form and contents of frameworks.
Much of the existing literature on patterns is organized as design pattern catalogs [GoF,Siemens]. These catalogs present a collection of relatively independent solutions to common design problems. As more experience is gained using these patterns, developers and authors will increasingly integrate groups of related patterns to form pattern languages. These pattern languages will encompass a family of related patterns that cover particular domains and disciplines ranging from concurrency, distribution, organizational design, software reuse, real-time systems, business and electronic commerce, and human interface design.
In the same sense that comprehensive application frameworks support larger-scale reuse of design and code than do stand-alone functions and class libraries, pattern languages will support larger-scale reuse of software architecture and design than individual patterns. Developing comprehensive pattern languages is challenging and time consuming, but will provide the greatest payoff for pattern-based software development during the next few years.
Patterns help to alleviate software complexity at several phases in the software lifecycle. Although patterns are not a software development method or process, they complement existing methods and processes. For instance, patterns help to bridge the abstractions in the domain analysis and architectural design phases with the concrete realizations of these abstractions in the implementation and maintenance phases. In the analysis and design phases, patterns help to guide developers in selecting from software architectures that have proven to be successful. In the implementation and maintenance phases, they help document the strategic properties of software systems at a level higher than source code and models of individual software modules.
[Adelson and Soloway] B. Adelson and E. Soloway. The Role of Domain Experience in Software Design. IEEE Trans. on Software Engineering, V SE-11, N 11, 1985, pp. 1351-1360.
[Coad] P. Coad, Object-Oriented Patterns. Communications of the ACM, V 35 N 9, Sept 1992, pp. 152-159.
[Curtis] B. Curtis, Cognitive Issues in Reusing Software Artifacts. In Software Reusability, V II. ed. T. Biggerstaff and A. Perlis, Addison Wesley 1989, pp. 269-287.
[GoF] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.
[Linn and Clancy] M. Linn and M. Clancy, The Case for Case Studies of Programming Problems. Communications of the ACM V 35 N 3, March 1992, pp. 121-132.
[PLoP2] J. O. Coplien, J. Vlissides, and N. Kerth, eds., Pattern Languages of Program Design, Vol 2. Reading, MA: Addison-Wesley, 1996.
[Schmidt1] D. C. Schmidt, A Family of Design Patterns for Application-Level Gateways, Theory and Practice of Object Systems, Wiley and Sons, to appear 1996.
[Schmidt2] Schmidt, Douglas, Using Design Patterns to Develop Reusable Object-Oriented Communication Software, CACM, (Special Issue on Object-Oriented Experiences, Mohamed Fayad and W.T. Tsai Eds.), 38, 10, October 1995.
[Siemens] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented Software Architecture - A System of Patterns. Wiley and Sons, 1996.
[Soloway and Ehrlich] E. Soloway and K. Ehrlich, Empirical Studies of Programming Knowledge, IEEE Transactions on Software Engineering V SE-10, N 5, September 1984.