Design patterns [Gamma, Helm, Johnson and Vlissides 1994], commonly occurring collections of interacting classes, have been proposed as a means for both designing and documenting the design of frameworks. As a design aid, the use of design patterns can lead to more flexible and extensible frameworks. Johnson [1992] proposed that the experience and knowledge of the framework developers about how the framework can be used should be captured by a series of patterns. Beck and Johnson [1994] used design patterns as a means for design documentation, to illustrate the architecture of the HotDraw framework and the decisions that led to it. Lajoie and Keller [1995] called these patterns motifs in order to avoid confusion with design patterns. Each motif contains the following elements: name, problem description, solution description, and solution summary. Motifs provide a high-level narrative of how to solve various problems that application developers may encounter when using the framework. The descriptions are informal and easy to read, but often leave out detailed information that a user may require.
The notion of a cookbook has been around almost as long as patterns. A tutorial style of cookbook description was introduced by Krasner and Pope [1988] for describing the basics of the Model-View-Controller framework in Smalltalk. Their cookbook description contains a general description of the framework, followed by specific parts of the framework and concluded with several examples using the framework. A second style uses a recipe form of description for various patterns of solutions used in the framework. Each recipe consists of i) a strategy part, which describes the problem the recipe is meant to solve plus some of the limitations of the solution, ii) the basic steps, which are the sequence of steps necessary to carry out the solution, and iii) the variants part, which present some of the alternative or advanced uses of the framework.
Each framework has hot spots [Pree 1995], the elements of the framework that are intended by the framework designer to be adapted to produce an application. One cannot use a framework without understanding the hot spots. Our own work on hooks [Froehlich et al, 1997] has focused on describing these aspects of the framework design that have the greatest implications in its use. Each hook addresses a well-defined requirement, and describes how to employ the framework to meet the requirement. Particular elements of a hook description include: name, intended requirement, type, area of the framework affected, use of other hooks, participants (both existing and new components), changes (steps to be enacted to carry out the intended requirement), preconditions/postconditions for hook invocation, constraints, and general comments. We have initially identified three categories of hooks that range from the simplest (option) to the most complex (open) form of framework extensions. Option hooks identify a set of predefined components that are provided with the framework. These components can be selected and easily attached to the framework as part of the application development. In pattern hooks, components are configured with parameters and/or connected together in predefined ways. Open hooks generally provide framework extensions through the creation of new components and connecting them in well-defined ways, typically involving inheritance or aggregation.
The hooks approach is the most structured and defined of the framework documentaion alternatives described above, and provides the basis for answering all three critical assumptions of framework reuse that were identified. By matching the requirements of the application to the hooks provided with a framework, the application developer can decide to use this framework and be relatively certain in advance that the application will not "break" the framework. Furthermore, the framework hooks guide the specific adaptations that the framework user has to make to develop his application. Finally, in the process of adapting the framework, the application developer may recognize the need to evolve the framework, if the given hooks cannot be sufficiently adapted to meet the precise application requirements. However, developers should be aware that they surrender a lot of design control when using a framework. The requirements of the application must be mapped to the capabilities of the framework, as primarily expressed in the hooks, in order to use the framework effectively. The framework may fulfill the requirements in a different way than the developers originally conceived of or are accustomed to; this way may possibly be better, or it may imply some compromises in the application requirements. Further research is required in order to extend the hooks model to more explicitly communicate these fairly subtle design decisions, so that developers can better evaluate the trade-offs of framework reuse in the context of each individual application. The specific short- and long-term research objectives outlined in the next section reflect our efforts to that end.