• Patterns are applicable only in the design phase. Many people know only design patterns—specifically, the patterns described in the Gang-of-Four book ( Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison- Wesley, 1994). However, currently, most new patterns are documented outside of software design.
• Patterns are UML templates. Many people notice only the solution structure when they look at a pattern—they tend not to look at the problem section, the forces, or the trade-offs. For them, the concrete UML diagram is the pattern. They fail to see that the participants depicted in the UML diagram are just roles, just an example solution structure; they don't see that the pattern is also about interactions, forces, when to use the pattern, and what the consequences and trade-offs of using the pattern will be. Unfortunately, this often leads to using patterns in the wrong places. Even among the submissions to this special issue, many articles fell into the trap of conceiving patterns as UML templates. For us, this was reason enough to reject them.
• Pattern application can be automated. Based on the prior misconception, people tend to put patterns into UML tools ("Our tool supports patterns—all 23!"). Of course, this again misses the point. To find out whether and how to use a given pattern in a given context, tools that work with patterns would have to be able to semantically understand your design as well as the patterns' trade-offs. Sure, it can be useful to generate some aspect of a pattern implementation, but this isn't the important aspect of patterns. In today's CASE tools, users must decide whether and how to use a pattern in their design. Tools merely automate some of the coding, which is arguably the least complex step in using a pattern.
Michael Kircher is a senior software engineer in the Corporate Technology Department for Software and Engineering, Architecture at Siemens. He supports the Siemens business units in software architecture and software product line engineering as a consultant and technical lead. He coauthored Pattern-Oriented Software Architecture, Volume 3: Patterns for Resource Management and Remoting Patterns: Foundations of Enterprise, Internet, and Real-time Distributed Middleware, both published by John Wiley in 2004. He's also a team member of Software Engineering Radio ( http://se-radio.net). Contact him at Siemens, Otto-Hahn-Ring 6, 81739 Munich, Germany; email@example.com; www.kircher-schwanninger.de/michael.
Markus Völter is an independent consultant and coach for software technology and engineering. He has worked in projects ranging from embedded to enterprise to scientific systems as a developer, consultant, and architect. He focuses on software architecture, middleware, and model-driven software development. He coauthored Server Component Patterns (John Wiley, 2002), Remoting Patterns (John Wiley, 2004), and Model-Driven Software Development (John Wiley, 2006). He's also the founder and editor of Software Engineering Radio ( http://se-radio.net), one of the leading podcasts for software developers, and a member of IEEE Software's Advisory Board. Contact him at Grabenstrasse 4, 73033 Goeppingen, Germany; firstname.lastname@example.org; www.voelter.de.