2.7 Design Patterns

Software architecture is an eclectic practice, combining ideas from many areas of computer science and software engineering. Reusing these ideas and existing knowledge is paramount to the effective practice of the architectural discipline. The popular movement of design patterns has codified and documented a great deal of software knowledge for this purpose. The driving force behind the success of design patterns in the software community has been the on-going work of the Hillside Group, an organization dedicated to improving human communication about computers by encouraging people to codify common programming and design practice [Hillside 2003].

The design patterns community has made reusing lessons learned a popular, trendy approach. Patterns represent a rejection of originality as a technical goal, including an active avoidance of the Not-Invented-Here syndrome. Software architects should also be pattern literate.

Design patterns are a significant addition to software engineering in the object-oriented software development community. Design patterns are documented representations of software engineering knowledge. They are intended to capture expert-level knowledge and important lessons learned. Design patterns are a departure from previous object-oriented guidance in several respects. Patterns document essential design knowledge, transcending original object-oriented notions. Originally, object orientation was based upon modeling the natural world as objects. To design effective software systems, more sophisticated and often abstract structures that are unique to software are needed.

Hillside Group Patterns Home Page "Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge which defines our understanding of good architectures that meet the needs of their users. Forming a common pattern language for conveying the structures and mechanisms of our architectures allows us to intelligibly reason about them. The primary focus is not so much on technology as it is on creating a culture to document and support sound engineering architecture and design." (Hillside Group-http://hillside.net/)

Design patterns have rigorous requirements for documenting knowledge. Design patterns should represent proven solutions, not merely wishful thinking about how software should be done. This concept is embodied in the so-called rule of three. Informally, the rule of three states that: "A single design occurrence is an event, two occurrences are a coincidence, and three occurrences are a pattern." To the design patterns authors, there is a more literal meaning: patterns are proven solutions applied by one or more communities of experts on a recurring basis.

Design patterns also introduce the notion of design force, also called issues or concerns. Design patterns document these forces explicitly and elaborate the solution in terms of resolving the design forces.

Design patterns represent a high-quality movement, focused on proven approaches to development, which has its own conference series and substantial visibility at technology events. The origin of design patterns comes from actual bricks-and-mortar building architecture [Alexander 1977]. The original vision for design patterns included a design-level model that was not observed in other authors' work. Design patterns represent a powerful approach for documenting guidance and solving technical problems in software architecture and system development. Figure 2.8 shows an example of a popular design pattern, called model-view-controller. This pattern applies at the framework level and provides an approach for reusing software objects that contain data and processing that must be viewed and controlled in many different ways.

The model-view-controller pattern includes model objects, view objects, and controller objects. The model object is the reusable component. It represents the data in the system and the encapsulating processes that need to be represented and controlled in several ways. The view objects represent various visualizations of that information, and many simultaneous views may be presented to groups of users. The controller objects represent various business processes or mechanisms for controlling the processing of the data. The model-view-controller pattern has been around at least since the creation of the Smalltalk programming language and has been reapplied at several different scales of software by various groups, including UML's business classes and the OMG business object task force that defines business objects in an analogous set of categories [Mowbray 1997b]. Figure 2.9A shows the overall structure of design patterns. The essence of any design pattern is a problem-solution pair. The problem is explained and expanded in terms of the applicable design forces and any contextual forces that may be present. The solution resolves the design forces in a particular manner. The selection of any solution is a commitment, and a commitment provides some benefits as well as consequences. In addition, selecting a solution may lead to additional problems where other patterns are appropriate.

Design patterns are distinguished from other forms of software literature in that design patterns are presented in terms of a standard outline or template. Several templates that meet the needs of various software design models have been published. Figure 2.9B lists the template developed for the CORBA design patterns [Mowbray 1997a]. In this template, the solution description is separate from the variations of the solution, which may vary by structure and by scale of application. Making this separation allowed the authors to clarify the base solution at a particular scale and then to describe the variations and nuances of applying the pattern in separate sections of the template. The design pattern template is a rhetorical structure that ensures consistent coverage of the key questions that people may need to answer in order to apply the design information. In particular, when justifying the application of a pattern, an understanding of the benefits and potential consequences of the pattern is important if the real tradeoffs in design are to be understood. If the design pattern authors have properly documented the pattern, they have identified those points of debate explicitly so that the users of the pattern do not need to reinvent that information.

Figure 2.10 is an example of a CORBA design pattern that applies in general to technologies beyond CORBA for system building. The problem is that most systems have vertical solutions, where each software module has a unique interface corresponding to each software implementation. The vertical solutions lead inevitably to stovepipe interdependencies between the modules in the system. By adding the common interface pattern to a system, the common interoperability information can be captured so that the software modules can interoperate without explicit dependencies upon particular implementations. The common interface pattern is a fundamental principle that is applied in standardization work and in software architectures in general.

Figure 2.11 shows a related pattern that applies the common interface in a more general and sophisticated context. In this pattern, called the horizontal vertical metadata pattern, a static architecture for a system is defined in terms of a common interface with vertical interface extensions; some dynamic architectural elements are added represented as metadata. A key tradeoff described in the pattern talks about how dynamic architecture and static architecture can be varied to represent different portions of the design. Dynamic architecture is one of the key solutions for implementing variability and adaptability in software architectures.

Figure 2.12 shows how the horizontal-vertical-metadata pattern is actually an instance of a more general concept that is applied across standards organizations and profiling entities all the way down to a system level of deployment. This application of the horizontal-vertical-metadata pattern is directly analogous to the functional and system profiles described in Chapter 5, where the functional profile is a vertical extension of a global standard. A system profile is a vertical extension of a functional profile, and any particular application system is a vertical instance of a system profile.

Figure 2.13A shows an application-level pattern and how it is applied. This example provides a flavor of what is involved. In this case, a UML sequence diagram is shown. Before the pattern is applied, a simple request and return transaction actually causes the client program, or thread, to block while it is occurring. It turns out that this is the default behavior of most distributed computing infrastructures such as remote procedure calls and CORBA. The performance of this configuration can be improved by adding a moderate amount of complexity and, after applying the pattern, returning a reference to the result that will be computed in parallel and retrieved later (Figure 2.13B).

Figure 2.14 shows a table of several examples of design pattern languages. Much of the available pattern documentation addresses a specific software design level. More recent work on CORBA design patterns and pattern-oriented software architectures has addressed several levels of abstraction where these levels are explicit. At the idiom level of design patterns, the guidance is focused on improving individual objects. Idiom documentation has been widely available in the form of programming language guidebooks. Idioms represent expert programming techniques that one would rediscover after substantial use of a language. If software engineers are maintaining software written by other people, it is essential to understand idioms in order to understand the intentions of the programmers applying these sophisticated ideas.

One of the first published design pattern languages described microarchitecture patterns [Gamma 1994]. The goal of the gamma pattern language was to invent a new discipline of variation-centered software design. The gamma pattern language is organized in terms of several categories including creational patterns, structural patterns, and behavioral patterns. When applying the gamma patterns, complexity of design is increased with the benefit of potential support for potential modification of the software. Gamma patterns have become very popular and are applied widely in software engineering organizations today.