1.3. Design Patterns and Software Architecture

We view software architecture as an eclectic practice, combining ideas from many areas of computer science and software engineering. Reuse of these ideas and existing knowledge is paramount to the effective practice of the architectural discipline. Luckily, the popular movement of design patterns has codified and documented a great deal of software knowledge for this purpose. We believe that software architects should also be pattern literate.

What the design patterns community has done is to make the reuse of lessons learned into a popular, trendy approach. Patterns represent a rejection of originality as a technical goal, including an active avoidance of the Not-Invented-Here (NIH) syndrome.

Design Patterns

Design patterns are a significant extension to object-oriented paradigm. 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 of the natural world as objects. To design effective software systems, more sophisticated structures are needed that are unique to software.

Design patterns have more stringent 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, that 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.

In order to facilitate problem solving, it is useful to find ways to separate design concerns—design elements which are implicitly responsible for resolving all potential concerns, those that are potentially unstable (when subject to scrutiny), and those that may require voluminous documentation to justify the design. Explicit reference models for separation of concerns have been proposed for software engineering and other fields of engineering endeavor.

Figure 1.8 also contains a software design-level model proposed by Shaw and Garlan showing three levels [Shaw 96]. In comparison, the software community does not have a sophisticated view of how to separate design concerns, and it is also not known what the components are that comprise each of these levels. In the software design model, the machine level represents the binary software that is part of the operating system and commercial products that cannot be modified by the application developer. The code represents the program that is the domain of application development, and the third level is the architecture, which provides a model of how the system is partitioned and how the connections between the partitions communicate. The shortcomings of this simple model are that it does not represent any significant separation of concerns and that important properties such as interoperability between systems are not considered.

Software Design-Level Model

Figure 1.9 shows the software design-level model that we propose in our book called CORBA Design Patterns [Mowbray 97a]. This model was originated by one of the founders of the design pattern movement, Richard Helms, and describes in a recursive fractal fashion what the various levels of software design are in terms of objects. At the micro levels we have individual objects, and the design principles that apply to those individual objects are usually object specific. There is a class of patterns called idioms which represent design guidance for language-specific issues. These issues are fairly fine grained.

The next level up is called micro architecture patterns. In micro architectures we have small configurations of objects, generally a handful of objects that give us sophisticated ways of organizing our software structure to support variability in other qualities of design. The framework level then takes a number of micro architecture patterns and combines them into a partially completed application with reusable software. Above the micro level, we have completed applications and systems. The application level represents the application of zero or more frameworks to provide an independent program. We encounter issues such as user interface programming which are significant in software development. At the system level, we take a number of applications which play the role of subsystems and integrate those applications to create a working system environment. The system level is where many of the design forces applicable to programming are changed in terms of their priorities. Management of complexity and change becomes critical at the system level and above.

At the enterprise level, we have a number of different systems which are integrated across an organization or virtual enterprise of organizations working in conjunction. The enterprise level is the longest scale of internally controlled operating environments.

The global industry level is represented by the Internet, the commercial market, and the standards organizations, which comprise the largest scale of software systems. Figure 1.10 represents the separation of design forces which occurs as we move throughout these various levels. Overall, the management of risk is a force which applies at all levels when we make software decisions. At the finer-grained levels, management of performance and functionality issues is very important and perhaps dominates any of the other design forces that apply horizontally across all the levels. Looking at the system level, the key design forces here include the management of change and the management of complexity. We come to this conclusion due to the writings of other authors. In particular Horowitz writes that the adaptability of systems is the primary quality which is missing where the majority of system cost is due to changes in requirements reference [Horowitz 93]. Shaw and Garlan identify the management of complexity as the key design force at the system architecture level [Shaw 96].

Above the system level the environment changes on a more frequent basis. Each system must be modified to support individual business processes; at an enterprise level with multiple systems the change accumulates as people move and the organization evolves on a daily basis. Management of the resources at the enterprise level and of technology transfer to support capabilities such as design and software reuse becomes more significant and important. At the global and industry levels, the management of technology transfer become predominant. When something is published on the Internet, it is instantly accessible on a global basis to virtually any organization or individual. Using the management of technology transfer design force, it is important to manage the information that the enterprise discloses in terms of software intellectual capital as well as the information that the organization exploits.

Figure 1.11 shows the overall priorities for these horizontal design forces as they apply to the coarser-grained levels. Here we show that at the system architecture level the management of change is the predominant force, because it is linked directly to the cost of the system in published work. We also identify as a second priority the management of complexity, because it is a design force that is emphasized by academic authorities in software architecture. Priorities at the other levels are indicated to show how the perspective of each of the architectural designers at these levels varies by the scale of software design. We see these as guidelines for making sure that the appropriate priorities are allocated to decisions that are made at each of these levels. The reference model helps us to organize patterns knowledge and identify priorities for design forces that are horizontal across all the levels. Design patterns are a modern approach to providing technical guidance. The breakthrough that design patterns provide is the capability of applying lessons learned and reusing design information across organizations.

Design patterns represent a high-quality academic research movement that has its own conference series and visibility at most other technology events. The origin of design patterns comes from actual bricks-and-mortar building architecture. The original vision for design patterns included a design level model which we did not discover in other authors' work. We believe that design patterns represent the right approach for documenting guidance and solving technical problems in software architecture and system development. Figure 1.12 shows an example of a popular design pattern called the model view controller. This is a pattern that applies at the framework level and provides an approach for reusing software objects that contain data and processing which 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 which need to be represented and controlled in several ways. The view objects represent various visualizations of that information, and there can be many simultaneous views that 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 invention of Smalltalk 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 which defines business objects in an analogous set of categories [Mowbray 97b]. Figure 11.6 shows the overall structure of design patterns. The essence of any design pattern is a problemsolution pair. The problem is explained and expanded in terms of the applicable design forces and any contextual forces which 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, selection of 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 have been published that meet the needs of various software design models. Figure 1.13 is a listing of the template developed for the CORBA design patterns [Mowbray 97a]. In this template there is a separation between the solution description and 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, it is important to understand the benefits and potential consequences of the pattern to understand the real tradeoffs in design. 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 have to reinvent that information.

Figure 1.14 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, we can capture the common interoperability information 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 1.15 shows a related pattern which applies the common interface in a more general and sophisticated context. In this pattern, called the horizontal vertical metadata pattern, we have a static architecture for a system defined in terms of a common interface with vertical interface extensions; also we are adding some dynamic architecture elements represented 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 1.16 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 that we describe in Chapter 4, 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 1.17 shows an application-level pattern and how it is applied. We present this example to give you a flavor of what is involved. In this case we are showing a UML sequence diagram. Before the pattern is applied, there is a simple request and return transaction which actually causes the client program 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. We can improve the performance of this configuration by adding a moderate amount of complexity and, after applying the pattern, we can return a reference to the result which will be computed in parallel and then retrieved later (Figure 1.17).

Figure 1.18 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 level are explicit. At the idiom level of design patterns we are concerned with individual objects. Idiom documentation has been widely available in the form of programming language guidebooks. Idioms represent expert programming techniques. These are 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 94]. 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.

AntiPatterns

A recent development in the patterns community is called AntiPatterns. An AntiPattern differs from an ordinary pattern in that it is a solution pair rather than a problemsolution pair (Figure 1.19). An AntiPattern starts with a problematic solution. The reason why the solution is there is due to various contextual forces. The AntiPattern solution leads to various kinds of symptoms and consequences, and the consequences can be quite devastating. The AntiPattern proceeds to define a potential solution for migrating the problematic solution to a refactored solution providing improved benefits. AntiPatterns are fundamentally about software refactoring. Refactoring is modification to software to improve its structure or quality. Common examples of AntiPatterns include stovepipe systems, spaghetti code, and analysis paralysis. AntiPatterns are further explained in the book AntiPatterns published by John Wiley & Sons in 1998 [Brown 98].