Douglas C.

Schmidt,

Mohamed Fayad, and

ature engineering disciplines have

M
Ralph E. Johnson,
handbooks that describe successful Guest Editors
s o l u t i o n s t o k n ow n p ro b l e m s . Fo r
i n s t a n c e , a u t o m o b i l e d e s i g n e r s d o n’ t d e s i g n c a r s u s i n g t h e l a w s o f
physics. Instead, they reuse standard designs with successful track
records. The minor percentage in performance value
a s s o c i a t e d w i t h s t a r t i n g f r o m s c r a t c h t y p i c a l l y i s n’ t
worth the cost.
T he theme of this section is patterns, which are attempts to describe suc-

cessful solutions to common software problems. Although no handbooks yet

exist, patterns have proven useful in the short term to help people reuse success-

ful practices. Not only do patterns teach useful techniques, they help people com-

municate 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,

rather they are a collection of interrelated patterns, though they do provide a

vocabulary for talking about a particular problem. Both patterns and pattern lan-

guages 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 tra-

ditionally 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. We must make all these things clear as we describe patterns. Clarity of expression

makes it easier to see when and why to use certain patterns, as well as why not use these patterns. All

solutions have costs, and pattern descriptions should state the costs clearly.
TERESA BERASI

From one point of view, there is nothing new about patterns since, by definition, patterns cap-

ture experience. It has long been recognized that expert programmers don’t think about programs

COMMUNICATIONS OF THE ACM October 1996/Vol. 39, No. 10 37

in terms of low-level programming language elements, of the patterns, share their own experience, and sug-
but in higher-order abstractions [1, 5, 7, 10]. What is gest improvements in content and style. These work-
new is that people are working hard to systematically shops assume that we all can learn from each other.
document abstractions other than algorithms and data
structures. In general, most people working on patterns Recognize the importance of human dimensions in software
are not concentrating on developing formalisms for development. The purpose of patterns is not to replace
expressing patterns or tools for using them. Instead, developer creativity with rote application of rigid design
they are concentrating on documenting the key pat- rules. Neither are we trying to replace programmers with
terns that successful developers use, but that relatively automated CASE tools. Instead, our intent is to recog-
few developers thoroughly understand and consistently nize the importance of human factors in developing soft-
apply in their daily work. ware. This recognition appears in design patterns when
Most of the people documenting patterns are moti- we discuss their effects on the complexity and under-
vated by the following values: standability of software systems. In addition, this recog-
nition shows itself in patterns on effective software
Success is more important than novelty. The longer a pattern process and organization.
has been used successfully, the more valuable it tends to
be. In fact, novelty can be a liability, because new tech- The articles in this section offer a good representa-
niques are often untested. Finding a pattern is a matter tion of the patterns that are currently being written.
of discovery and experience, not invention. A new tech- The first software patterns were written by object-ori-
nique can be documented as a pattern, but its value is ented developers, so they focused on object-oriented
known only after it has been tried. This is why most pat- design and programming [6] or on object-oriented
terns describe several uses. modeling [3]. Although there is still a lot of interest in
object-oriented patterns, a new trend is patterns that
Emphasis on writing and clarity of communication. Most pat- focus on efficient, reliable, and scalable concurrent,
tern descriptions document recurring solutions using a parallel, and distributed programming [2, 4, 8].
standard format. We look forward to the day when we The majority of articles here follow the latter trend.
will have handbooks for software engineers. Therefore, McKenney’s article on “Selecting Locking Primitives
we write our patterns in a form that is like a catalog for Parallel Programs” describes a set of patterns used
entry. In this sense, pattern descriptions are both a lit- to build efficient operating systems for multiprocessor
erary style and technical documentation. platforms. Islam and Devarakonda’s article “An Essen-
The emphasis on clear writing stems from our col- tial Design Pattern for Fault-Tolerant Distributed State
lective experience developing complex software sys- Sharing” discusses a design pattern used to create reli-
tems. In many cases, projects failed because developers able distributed software. Aarsten, Brugali, and Men-
were unable to communicate good software designs, ga’s work on “Designing Concurrent and Distributed
architectures, and programming practices to each Control Systems” presents a pattern language for
other. Well-written pattern descriptions improve com- developing distributed software for large-scale control
munication by naming and concisely articulating the systems.
structure and behavior of solutions to common soft- Another recent trend in the patterns literature
ware problems. focuses on management, sociological, and organiza-
tional issues. Two articles in this section address
Qualitative validation of knowledge. Another part of our these topics. Cockburn’s “The Interaction of Social
ethic is to qualitatively describe concrete solutions to soft- Issues and Software Architecture” describes a pattern
ware problems, instead of quantifying or theorizing language illustrating how social forces affect the
about them. There is a place for theoretical and quanti- decisions that shape the structure of software
tative work, but we feel such activities are more appro- designs. Goldfedder and Rising’s article on “A Train-
priate in a context separate from discovering and ing Experience with Patterns” details the organiza-
documenting patterns. Our goal is to appreciate and tional and sociological aspects of introducing
reward the creative process that expert developers use to patterns into a commercial software development
build high-quality software systems. environment.
The study of patterns is well established in many other
Good patterns arise from practical experience. Every experi- fields including architecture, anthropology, music, and
enced developer has valuable patterns that we would sociology. Early adopters of software patterns were highly
like them to share. We value the experience of all soft- influenced by Christopher Alexander, a researcher at
ware developers, and do not think that a few people University of California, Berkeley, who has written exten-
have the patterns, and everybody else just sits back and sively on patterns found in architecture for houses, build-
learns them. That is why our use of writers’ workshops ings, and communities.
has been so successful at pattern conferences. In a writ- As we have gained experience using patterns to doc-
ers’ workshop, participants discuss the strengths and ument software expertise, new formats and new solu-
weaknesses of each pattern, accentuate positive aspects tions have emerged to meet the unique challenges

38 October 1996/Vol. 39, No. 10 COMMUNICATIONS OF THE ACM

associated with developing software. For instance, many design phases with the concrete realizations of these
developers find it easier to understand design patterns abstractions in the implementation and maintenance
by using software-centric visual aids such as class mod- phases. In the analysis and design phases, patterns help
els and interaction graphs. Therefore, many pattern to guide developers in selecting from software architec-
description formats use popular notations (such as tures that have proven to be successful. In the imple-
Booch models and OMT) to express their structure mentation and maintenance phases, they help
and dynamic behavior concisely. In addition, pattern document the strategic properties of software systems at
descriptions also commonly contain source code exam- a level higher than source code and models of individual
ples, written in the language of choice for the audience. software modules.
Over the next few years, we expect the following aspects
of patterns will receive considerable attention [9]: Ultimately, patterns are successful because people
take the time to read them, learn them, use them, and
Integration of design patterns together with frameworks. Some write them. We encourage you to get involved with oth-
of the most useful patterns describe frameworks. Such ers working on patterns by attending conferences, par-
patterns can be viewed as abstract descriptions of ticipating in the online mailing lists, and contributing
frameworks that facilitate widespread reuse of software your insights and experience. To find out about books,
architecture. Similarly, frameworks can be viewed as online papers, electronic mailing lists, and conferences
concrete realizations of patterns that facilitate direct on patterns, see the Patterns homepage at http://
reuse of design and code. One difference between pat- st-www.cs.uiuc.edu/users/patterns/patterns.html. C
terns and frameworks is that patterns are described in a
language-independent manner, whereas frameworks References
are generally implemented in a particular language. 1. Adelson, B. and Soloway, E. The role of domain experience in software
design. IEEE Trans. on Softw. Eng. 11, 11 (1985), 1351--1360.
However, patterns and frameworks are highly synergis- 2. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and
tic concepts, with neither subordinate to the other. The Stal, M. Pattern-Oriented Software Architecture—-A System of Patterns.
next generation of object-oriented frameworks will Wiley, New York, 1996.
explicitly embody many patterns and patterns will be 3. Coad, P. Object-oriented patterns. Commun. ACM 35, 9 (1992),
widely used to document the form and contents of 152--159.
4. Coplien, J.O., Vlissides, J., and Kerth, N., Eds. Pattern Languages of
frameworks. Program Design, Vol 2. Addison-Wesley, Reading, Mass. 1996.
5. Curtis, B. Cognitive issues in reusing software artifacts. Software
Integration of design patterns to form pattern languages. Much Reusability, Vol II. T. Biggerstaff and A. Perlis, Eds. Addison Wes-
of the existing literature on patterns is organized as ley, Reading, Mass. 1989, pp. 269--287.
6. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns:
design pattern catalogs [2, 6]. These catalogs present a Elements of Reusable Object-Oriented Software. Addison-Wesley, Read-
collection of relatively independent solutions to com- ing, Mass. 1995.
mon design problems. As more experience is gained 7. Linn, M. and Clancy, M. The case for case studies of program-
using these patterns, developers and authors will ming problems. Commun. ACM 35, 3 (1992), 121--132.
increasingly integrate groups of related patterns to form 8. Schmidt, D.C. A Family of Design Patterns for Application-Level Gate-
ways, Theory and Practice of Object Systems. Wiley, New York, (to
pattern languages. These pattern languages will encom- appear 1996).
pass a family of related patterns that cover particular 9. Schmidt, D.C. Using design patterns to develop reusable object-oriented
domains and disciplines ranging from concurrency, dis- communication software. Commun. ACM 38, 10 (1995), 65--74.
tribution, organizational design, software reuse, real- 10. Soloway, E. and Ehrlich, K. Empirical studies of programming
knowledge. IEEE Trans.on Softw. Eng. 10, 5 (1984).
time systems, business and electronic commerce, and
human interface design.
In the same sense that comprehensive application DOUGLAS C. SCHMIDT is an assistant professor of computer sci-
frameworks support larger-scale reuse of design and ence at Washington University in St. Louis, Mo. He also serves as edi-
code than do standalone functions and class libraries, tor-in-chief of C++ Report magazine and is co-editor with Jim Coplien
of the recent book, Patterns Languages of Program Design; email:
pattern languages will support larger-scale reuse of soft- [email protected]
ware architecture and design than individual patterns.
Developing comprehensive pattern languages is chal- MOHAMED FAYAD is an associate professor at the University of Neva-
lenging and time consuming, but will provide the great- da, Reno. He has been actively involved in over 60 object-oriented pro-
jects in several companies using Shlaer-Mellor, Colbert, OMT, use-case
est payoff for pattern-based software development approach, design patterns, frameworks, among others. He also serves on
during the next few years. the editorial board of Communications; email: [email protected]

Integration with current software development methods and soft- RALPH E. JOHNSON is on the faculty of the computer science
ware process models. Patterns help to alleviate software department at the University of Illinois at Urbana-Champaign. He
has helped develop an object-oriented operating system (Choices),
complexity at several phases in the software life cycle. compiler (Typed Small talk), graphics editor framework (HotDraw),
Although patterns are not a software development among others; email: [email protected]
method or process, they complement existing methods
and processes. For instance, patterns help to bridge the
abstractions in the domain analysis and architectural ©ACM 0002-0782/96/1000

COMMUNICATIONS OF THE ACM October 1996/Vol. 39, No. 10 39