Pages: pp. 28-30
Patterns have become part of the software development mainstream (see the sidebar " What Is a Pattern?" for a short definition). They're available for all development phases, including analysis, documentation, design, testing, and configuration management, to name a few. In addition to documenting the current status of software patterns, our goal for this special issue is to reflect critically on and discuss the achievements of the pattern community.
While selecting the articles for this issue, we learned more about both the field's achievements and misconceptions than we expected. Unfortunately, a significant number of submissions were based on misconceptions about patterns.
We condensed these misconceptions into three themes:
To establish a common direction, the pattern community has found writers' workshops highly valuable. At these workshops, which take place at the pattern conferences, patterns undergo massive review and discussion to ensure their correctness and usefulness. See " The Patterns Community" sidebar in this introduction for explanations of shepherding, writers' workshops, and the pattern conferences.
This issue's article "Past, Present, and Future Trends in Software Patterns," by Frank Buschmann, Kevlin Henney, and Douglas C. Schmidt, gives a brief history of patterns in the context of software development and discusses today's software patterns landscape. You'll learn how more and more individual patterns are grouped and organized into larger contexts such as pattern collections, systems, and languages. The article concludes by looking at the domains for which patterns will be documented in the future. We hope this motivates you to follow up on this vision and help to make it real.
To give a strong positive example of how to use patterns, "Using Patterns to Capture Architectural Decisions" by Neil B. Harrison, Paris Avgeriou, and Uwe Zdun shows how to understand and use patterns for building and documenting architectures. Using patterns in the context of software architecture is a proven yet somewhat unknown area today. The authors discuss the similarities between classical ways of documenting software architectures and using a pattern-oriented approach, which the authors prefer.
Now that we've seen how we can use patterns to document architecture and design knowledge, it becomes interesting to see how patterns are documented in the first place. Writing good patterns isn't necessarily simple, and it's not without pitfalls. Finding the right level of granularity and a suitable abstraction level when describing a given problem is a central challenge for pattern writers. In "Understanding the Power of Abstraction in Patterns," Linda Rising shares her personal insights gained from documenting patterns in the area of change management. It's exciting to see what kind of cross-relations you can discover while digging into the domain you derived your pattern from.
Every discipline, after a period of rapid expansion, needs some time for consolidation or it risks disintegration. The expansion of software patterns has produced a large body of work that now needs organization. "Organizing Security Patterns" by Munawar Hafiz, Paul Adamczyk, and Ralph E. Johnson documents early efforts to consolidate and organize a subset of software patterns in the security domain. Lessons learned through this process can help people trying to organize patterns for other domains.
We round out our selection of articles with "The Growing Divide in the Patterns World" by Dragos Manolescu, Wojtek Kozaczynski, Ade Miller, and Jason Hogg. They report on their study of patterns use in the software development industry. Based on this, they issue a call for action to the pattern community in order to bridge discovered gaps.
The final piece is a Point-Counterpoint discussion by Peter Sommerlad and James Noble on the pros and cons of design patterns as proposed in the Gang-of-Four book. We invite you to follow Sommerlad's and Noble's arguments about whether the original 23 design patterns lead to better or worse design.
We hope you find this special issue interesting and fun to read. If you want to learn more about patterns or become more involved with the community, consider going to one of the Pattern Languages of Programs conferences.
A pattern is a well-working solution to a problem that occurs repeatedly in a given context. In addition to describing this best-practice solution, a pattern also contains a rather extensive discussion of when it's appropriate to use one and what the consequences—positive and negative—are if you do. Often patterns contain a number of typical variations. Finally, each pattern comes with a set of "known uses." Since patterns aren't invented but rather mined from existing systems, these known uses serve as proof that the pattern is actually derived from real systems.
The best place to meet and interact with people who are highly interested in pattern writing is a Pattern Languages of Programs conference. The PLoP conferences happen at different places around the globe, including PLoP in the US, EuroPLoP in Germany, SugarLoafPLoP in South America, and VikingPLoP in Scandinavia.
All PLoP conferences have three things in common. They use shepherding to allow each author—the "sheep"—to improve his or her work before the conference under the guidance of another, experienced author—the "shepherd." Second, they run writers' workshops, where authors review each other's work and exchange their ideas. Finally, they are organized by members of the Hillside Group, a nonprofit organization that encourages people to codify common programming and design practices. Links to all the PLoP conferences are at Hillside's Web site ( http://hillside.net).
We thank the reviewers for devoting their time and expertise to help us review all the submissions and select the articles in this issue.