In this and subsequent columns, I will delve in more detail into several topics that are key to developing a robust component-based reuse program. In this column I stress the reuse of patterns and models. In later columns we will investigate newer component models and tools, metrics and component-oriented software methods.

For some time, reuse experts have suggested that successful reuse must involve more than the use of code components alone. They suggest that a robust reuse program must include a systematic reuse of designs, architectures, test suites, frameworks, and other things. But most reuse programs to date have focused only on simple components in the form of function and class libraries. Some have architected and implemented object-oriented frameworks. Some are building and collecting ActiveX, COM, Corba or JavaBeans component. But few have an explicit or systematic way of capturing and representing reusable designs. While research and practical use of component and architecture specification languages has been promising, there have been no widely used, standard, ways of describing and reuse designs.

It is exciting and important that over the last few years, there have been several developments that promise significant change. In addition to the newer component standards, these are design and architecture patterns, and the emergence of the OMG standard Unified Modeling Language (UML). There is sufficient momentum behind these two movements to have already produced several tools that support combinations of UML modeling and patterns for component-based software development.

My main message is that it is time for most component- and framework-oriented reuse programs to incorporate this trend into their strategic reuse planning, education, and practice.

A large group in the OO community, applying the ideas of the architect Christofer Alexander on "pattern languages" to systematize important principles and pragmatics used in the design of buildings and communities[1], have been actively engaged in defining, collecting and testing a variety of software patterns. This "patterns community" defines a pattern as "a solution to a commonly occurring design problem". There are many books[2-7], papers, conferences and web sites devoted to patterns (see the Patterns Home Page http://hillside.net/patterns/patterns.html).

Many of these design patterns are documented in books of patterns, presented using a standard documentation template. These templates assign a standard name to a pattern, a summary of the problem and the forces/context give rise to it, and a solution in terms of a structure and interactions of a set of collaborating classes and objects. The templates also provide examples of use in some programming language, variants of the pattern, a summary of the benefits and consequences of using this pattern, and references to related patterns. Figure 1, reused from Mowbray [7], illustrates these connections.

The patterns community has also applied the pattern idea, with different document templates, to collect standard solutions to commonly occurring architectural problems[5-7]. Some of these include Layers, Pipes and Filters, Broker, Blackboard, Horizontal-Vertical Metadata and Model-View-Controller. Others have developed patterns to be used during analysis ("analysis patterns")[6], during implementation ("idioms" that map common OO structures onto peculiar aspects of languages such as C++, SmallTalk) and even for effective organizational structures ("organizational patterns"). Typically, design patterns map fairly directly to OO programming languages, and examples are given using C++, Java or SmallTalk, while architectural patterns deal mostly with (sub-)systems and interfaces, and examples do typically not include code.

The effort to develop a standard modeling language for architectures, systems and designs that led to the OMG Unified Modeling Language (UML) had as its goal a "standard software blueprinting language". This could be used to produce reusable architectures and designs, and a variety of tools that can share a common representation. The UML specification defines patterns as a collaboration; more specifically as a "template collaboration". A collaboration specifies a set of classes and objects, playing specific roles with respect to each other. Design patterns then become a template collaboration among classes and instances, with behavior explained by interaction diagrams. Architectural patterns are similar, but focus on the larger-grained structure and interactions of subsystems and even systems. We use template collaborations for patterns, rather than just collaborations, because the solutions are meant to be fairly generic – inheritance, extension and other mechanisms are used to specialize the pattern (such as specifying class names, number of classes, etc.). In many cases, the template collaborations give rise to concrete collaborations that are directly traceable to use cases. Several books including our own [8,9], and new OO methods based on UML explicitly include the development and reuse of architecture and design patterns. Figure 2, adapted from our book [9], shows two patterns for a banking system. The dashed ovals are patterns, suggesting their connection to use cases.

Recently emerging tools provide even more explicit support for the creation, cataloguing and application of standard and organizational patterns. For example, Blueprint Technologies' Framework Studio includes three interacting components; Pattern Builder, Pattern Applicator and Object Miner. These tools augment Rational Rose98 such that a repository of patterns can be built (using Pattern Builder) specifically for reuse across the origination, by using standard design [2], architectural[5] and analysis[6] patterns, by developing new patterns from scratch, or by mining existing UML models and documents for new patterns (using Object Miner). Pattern Applicator is used to insert new patterns (as collaborations of classes and objects) into existing or new software designs.

Frameworks implement key architectural structures and design mechanisms with the intent that it should be easy to independently develop and use components by inheriting from base-classes or plugging the components into the interfaces of the system. Unfortunately, it is not always easy to develop the components without understanding how they interact with the framework or other components. In fact, it is important to document and enforce these constraints, and this is not easy in most cases. An extremely useful tool is to describe the framework and conformance constraints as patterns, or more specifically, collaboration models to which the new components must conform.

Some patterns, such as Broker or Model-View-Controller are themselves the core of a framework, which solve a combined architectural and design problem. For example, the Broker pattern [4] is a generic mechanism for managing object distribution. A Broker allows objects to call other remote objects through a process or service that forwards the call to the appropriate computer that holds the desired component. This forwarding is made transparently (perhaps using the Proxy design pattern) which means that the caller does not have to know whether the called object is remote or not. [7].

There are other architectural patterns that help shape the overall structure of a system. The Layers, Client-Server, Three-Tier and Peer-to-Peer patterns are such examples. These patterns define a structure to the interactions between components, and also suggest how components should be allocated to the computers in the system.

Sometime one pattern in a system is clearly predominant, giving shape to the whole system, while others may be significant but are of lesser importance. For example, in a Layered System, the Layers pattern defines the overall architecture, while Pipes and Filters, or other pattern could be used inside component in one or more layers. Alternatively, a Pipes and Filters System would show the overall architecture as a flow of data or events between filter components. Of course some filters could be explicitly layered..

Work by Garlan and Shaw at CMU [10] has focused on cataloguing standard architectures, and analyzing and classifying them on the basis of the kinds of components, connectors and interactions. Research is directed at formalizing components and connectors, describing connectors as first class entities, and developing a theory, languages and tools for manipulating architectures. This has given rise to what are called architectural styles, such as Dataflow, Pipes and Filters, Hierarchical Layers, Event systems, Rule-based systems, and Blackboards. Such "styles" are similar in spirit to the notion of architectural styles describing buildings, using terms such as Gothic, Neo-Classical, Bauhaus, or Post-Modern.

From a modeling perspective, an architectural style defines the set of all (good) system models that can be built using the chosen modeling language and specific patterns to maximally structure/constrain the model into easily recognizable structures, such as shown in Figure 2. The style, through the patterns and constraints, provides a high-level design vocabulary, leading to designs and architectures with well-understood structure and well-described benefits and consequences. In addition to UML and UML tools, languages such as ACME are being proposed as standards for architecture description.

Architecture and design patterns are important. They capture higher-level system notions for reuse. The UML modeling language and new OO methods based on UML provide direct support for patterns. New tools allow patterns to be more easily identified and reused during the design and implementation of systems. To get full benefit of this trend, an organization must invest in training its project managers and engineers on the importance and techniques of patterns and modeling for reuse and better systems, on teaching them to recognize and use standard patterns, and to identify, define and collect patterns of specific interest to the organization's own systems and applications. Managers must make a strategic investment to succeed in building up this capability.

[1] C. Alexander A Pattern Language, Oxford University Press, 1977

[2] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.

[3] J. Coplien & E. Schmidt, Pattern Languages of Program Design, Addison-Wesley, 1995.

[4] W. Pree, Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995.

[5] F. Buschmann et. al. Pattern-Oriented Software Architecture - A System of Patterns. John Wiley & sons, 1996.

[6] M. Fowler Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997.

[7] T. Mowbray and R Malveau CORBA Design Patterns. John Wiley & Sons, 1997

[8] C. Larman, Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design, Prentice-Hall, 1997.

[9] I. Jacobson, M. Griss, and P. Jonsson, Software reuse: Architecture, Process and Organization for Business Success, Addison-Wesley-Longman, 1997.

[10] D. Garlan and M. Shaw, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996.