Framework Tools for Different Software Development Phases

So far in Chapter 4 we have discussed framework modeling techniques that could allow us to develop tool support for frameworks. Next we shall look at how this tool support could alleviate the challenges faced during the different phases of a framework-based software development process.

Table 4.1 summarizes our own views on the main challenges related to develop-ing software via utilizdevelop-ing frameworks. The challenges are organized accorddevelop-ing to the typical phases of a software development process.

Table 4.1: Challenges for framework-based software development Framework

The discovery of hot spots (see challenge 1 in Table 4.1) is a key-point when per-forming framework domain analysis. However, the existing general domain analysis techniques (see for example [Prieto-Diaz-Arango 1989]) do not offer help in determining the features of the domain that need to be flexible, and there are no framework-specialized techniques available either. The lack of suitable techniques causes also the lack of proper tools. Clearly, further research in the

area of domain analysis is needed in order to allow us to have more support for frameworks.

Patterns have been widely accepted as means for systemizing framework design.

They allow us to jump over at least some steps in the otherwise obscure and it-erative design process. Tools that are based merely on patterns’ static informal descriptions typically offer simple hypertext functionalities and search facilities for browsing pattern descriptions. Pattern searching is based on string matching just like in general WWW search machines such as Altavista [www.alta-vista.com] and Google [www.google.com]. Good hypertext representation of de-sign patterns connects related patterns and their variations together so that it is easier to analyze the available design alternatives. Generic tools like that offer valuable aid in hot spot design (challenge 2) and, in fact, some researchers think that this is the only tool support needed for using patterns [Chambers et al. 2000].

In order to better manage framework design and the communication between de-signers, we must also have higher-level graphical design methods for document-ing frameworks (challenges 2 and 3). Techniques that extend the general object modeling methods have been suggested for that purpose. In addition to the ventional modeling notations they typically offer some form of the pattern con-cept and the possibility to separate hot spots from the rest of the framework ar-chitecture. Tool support for these techniques usually includes the creation and direct manipulation of the graphical design elements that the particular technique provides, as well as semantic checks for the consistency of the design models.

Some researchers argue that tools like this could also assist in systemizing design decisions [Fontoura 1999; Fontoura et al. 2000], for example in selecting the most appropriate pattern for a hot spot (challenge 2), thus simplifying the job of the framework designer.

Framework implementation includes developing the concrete source code that constitutes the framework, as well as documenting the framework both for its users and its maintainers. In the coding process, special attention must be paid to the implementation of the framework’s hot spots (challenge 4). Patterns contain examples of the concrete hot spot implementation variations, so tools based on them can conveniently represent the examples to the user and thus support hot spot implementation.

Instead of providing mere static descriptions, pattern-based framework tools usu-ally supply representations of the instances of the patterns and their roles that are present in the framework or the application source code. This greatly facilitates the comprehension of the framework in terms of patterns (challenge 5). Further-more, as patterns are typically involved in the specialization interface of the framework, this annotation of frameworks with patterns also assists application implementation (challenge 8). Framework maintenance and application mainte-nance, on the other hand, benefit from the illustration of pattern instances, be-cause based on the patterns one can recall the rationale behind existing design decisions and take them into account when planning changes (challenges 6 and 9).

In order to allow more extensive tool support for using patterns, we need to util-ize some sort of formal patterns or contracts to represent the architectural ele-ments of the framework. Formal patterns allow us to generate code from patterns and check the consistency between the patterns and the source code. This natu-rally further facilitates application implementation and possibly even framework implementation (challenges 8 and 4).

Patterns are a good way of documenting the design decisions used in a frame-work (challenge 5). However, for the frameframe-work user the documentation should be focused differently: the application developer is more concerned with adding features to her application than learning the design rationale of the framework. In addition, she might not be familiar at all with the pattern concept nor the design patterns of, for example, [Gamma et al. 1994].

The approach of cookbooks is often more intuitive to the application developer than patterns: cookbooks offer a problem-based or feature-based “how to” docu-mentation for frameworks (challenges 5 and 8). The simplest form of tool sup-port for cookbooks could depict cookbooks merely as a collection of hypertext pages that document the usage of a framework. However, we believe that tool support for frameworks has a lot more to offer especially in the framework spe-cialization process. Based on the concept of cookbooks and patterns, it is possi-ble to create tools that react dynamically to the framework specializer’s decisions and offer step-by-step instructions on how to complete her application. It is noted in [Fayad et al. 1999] that usually the first specialization of a framework is the hardest, and it is a good idea to make it under the guidance of an expert. We ar-gue that this expert can be an automated tool that assists the framework speciali-zation process, as will be seen in Chapter 6.1 where we present our framework engineering tool, JavaFrames.

Application domain analysis should not depend on whether a framework will be used for implementing the application or not. In that respect, it seems that there are no framework-related challenges in application domain analysis. In applica-tion design, the main concern related to frameworks is how to choose a frame-work that is suitable for the application (challenge 7). At the moment, there are no good methods for describing frameworks in such a manner that a tool could be used to automatically choose a framework that fits the application require-ments. Tools based on cookbooks or patterns that annotate frameworks can ease the process, but they are clearly not optimal for that purpose.

Besides the usual maintenance activities, application maintenance can involve converting an existing legacy application into a more flexible framework. In this process, tools based on formalized patterns could be used in (a) detecting patterns or antipatterns in the source code and (b) converting the existing code to conform to a desired pattern. Besides application maintenance, this kind of tool support is obviously useful for framework maintenance, too (challenges 9 and 6).

In the following chapters we concentrate on the possible tool support applicable for framework design and implementation, framework maintenance, and

applica-tion implementaapplica-tion through framework specializaapplica-tion. We feel that tool support could have the most to offer in those software development phases.

4.2.1 Framework Design and Implementation

Conventional tools for software design mainly include UML case tools such as Together [www.oi.com], Rational Rose [www.rational.com], and Visio Enter-prise [www.visio.com]. These tools provide appealing visual interfaces for edit-ing UML diagrams by direct manipulation. They also offer some semantic checks that may be applied on the design models. However, these tools fail to support design concepts necessary in framework modeling; it is not possible, for example, to represent the hot spots and the frozen spots of the framework differ-ently. (We acknowledge that some UML tools allow the user to specify new graphical symbols that could, for example, be used to represent framework-related concepts.)

Several CASE tool prototypes have been introduced for defining framework hot spots. The Hook Tool [Froehlich et al. 1997] uses an extended version of UML in which the variation point classes are highlighted. This differentiation between kernel and variation points aids framework design and instantiation. Unfortu-nately, the Hook Tool does not completely solve the problem of defining frame-work hot spots: frameframe-work designers still have to provide the solutions for mod-eling each variation point without any means for systemizing their choices. In [Fontoura et al. 2000] the authors claim that it is not only possible to describe the design of a hot spot with UML-F (recall Chapter 4.1.6), but furthermore, it is also possible to develop tool support on top of UML-F for systemizing the selection of an appropriate pattern for the hot spot implementation.

In addition to the dedicated framework design tools, there are a number of UML-based tools for representing design patterns (see for example the UMLAUT tool [Sunye et al. 2000]). These kinds of tools are useful also for framework design.

Similarly, we feel that framework implementation could be best supported with tools for handling different kinds of patterns that cover the flexibility aspects of OO software. As noted in Chapter 2.6, tools are needed especially for organizing patterns and for searching patterns suitable for solving the design or implementa-tion problem at hand.

Publishing pattern catalogs in the form of conventional books is clearly not opti-mal for comparing and searching patterns, especially if you are not familiar with them beforehand. Moreover, as described in Chapter 2.6, because the amount of pattern descriptions is huge by now, it is impossible to be aware of all the pat-terns and their benefits and shortcomings. Obviously, more efficient methodolo-gies and tool support are needed for organizing and searching patterns.

As seen in [Gamma et al. 1994], a good pattern catalog is extensively cross-referenced. Therefore, hypertext [Conklin 1987, Halasz-Schwartz 1994] offers a good medium for organizing pattern catalogs. With hypertext it is possible, for instance, to link related patterns together, to show examples of pattern usage, and to hide technical implementation details from a casual reader.

Navigation and focusing are the main problems in hypertextual systems [Koski-mies-Mössenböck 1996]. That is why, in addition to easy association and move-ment, a hypertext system must contain indices, search facilities, and a navigation history [Pree 1995]. Examples of using hypertext in software development and maintenance include [Paakki et al. 1996] and [Nørmark-Østerbye 1994]. By now the tools and techniques for WWW-based development are quite advanced and it is thus easy to attach pictures, annotations, bookmarks, command buttons, or even animation and sound to hypertext. An example of a tool that uses hypertext to describe patterns is discussed in [Budinsky et al. 1996]. The tool incorporates a hypertextual rendition of [Gamma et al. 1994].

There are many alternative ways for classifying patterns. Therefore tool support for patterns should be able to dynamically generate different views or indices over patterns. Based on this idea we have proposed Pattern Selection Wizard [Hakala et al. 1997] for finding a suitable pattern for the desired purpose (see Figure 4.4). The user can select any of the patterns in the Available Patterns sec-tion and then view the basic intent of the pattern. For each pattern the tool also lists a specific index (Points in Categories) that describes how well the pattern suits the different pattern categories. With the Instantiate button the user can in-stantiate the selected pattern by generating a code template and with the Show HTML Description button she can view its HTML documentation. If the user is not familiar with design patterns or does not immediately know which pattern to instantiate, she can open the Pattern Filter section with the Search Help button.

Figure 4.4: Pattern Selection Wizard

The Pattern Filter section lists all available categories as a tree structure. It al-lows the framework developer to mark the categories from which patterns are to be included into the Available Patterns section. The result of the filtering consists of the matching patterns sorted according to their applicability as expressed by their category values. With the radio buttons the developer can choose whether to display a union or an intersection of the patterns matching different categories.

Category Description shows a short help text concerning the currently selected category. The user can also make text searches to find an individual pattern or a pattern category that might provide help to her design problem. The two text sources available for searching are the HTML documents associated with each pattern and the descriptions of the design pattern categories.

The problem with tools like Pattern Selection Wizard is that the patterns must be classified and organized by hand for different categories, which is a difficult task, especially if the categories are predefined. A promising approach for organizing design patterns is to use information retrieval (IR) techniques as described in [Helm-Maarek 1991]. The IR approach means analyzing a document in order to extract the indices that best characterize the document.

4.2.2 Framework Maintenance

Several re-engineering activities could be applied for framework maintenance:

Pattern mining [Martin 1996] can be used for detecting pattern instances from source code. Refactorings [Fowler et al. 1999] are behavior-preserving transfor-mations that may be applied on the framework design representation as well as on the framework implementation. Unifications [Fontoura 1999] are transforma-tions that alter the framework design structure in order to incorporate new fea-tures or to modify the existing ones. Pattern mining, refactoring, and unification are all part of a wider research area called reverse engineering [Chikofsky-Cross 1996]. For information on tools that support refactoring and unification in framework maintenance, refer to [Roberts et al. 1996; Fontoura 1999], for in-stance. Note also that many commonly used programming IDEs, such as Eclipse [www.eclipse.org], support refactorings: changing method names and moving methods from one class to another, for example.

In addition to actual maintenance tasks, reverse engineering tools can be used to gather statistics about design pattern instances in source code. These tools can also rate OO systems based on loose coupling, shallow inheritance hierarchies, high use of composition, and other similar positive measures of OO software. A pattern-mining-based metrics tool, called MAISA, is described in [Verkamo et al.

2001; Ferenc et al. 2001; Gustafsson et al. 2002].

The main problem in pattern mining is that a reverse engineering tool cannot

“comprehend” the intent of a pattern. However, the structure of a pattern’s im-plementation might be detectable and lead to the identification of the actual pat-tern. In general: “a pattern is detectable if its template solution is both distinctive and unambiguous” [Brown 1996]. In other words, the structure of a detectable pattern is never used in other contexts and the pattern has no alternative struc-tures. The latter requirement is rather demanding, because an

implementation-oriented pattern typically has several different implementation variations. This makes pattern detection troublesome and sometimes impossible [Niere et al.

2002]. If a design pattern relies heavily on semantic descriptions instead of struc-ture, like the Interpreter pattern [Gamma et al. 1994] does, it might be totally undetectable for an automated tool. In contrast, the definition of the Template method pattern [Gamma et al. 1994], for example, is not based on any semantic meaning and the pattern is thus easily detectable. Most patterns reside some-where in between.

Several tools for finding patterns in program source code have been developed.

KT Tool [Brown 1996] detects metapatterns and a subset of design patterns from [Gamma et al. 1994] in commercial-size Smalltalk programs. Brown has chosen metapatterns and the structural design patterns (Composite, Decorator, Template Method, Hook Method, and Chain of Responsibility) for detection, which reflects the fact that the syntactical or structural parts of patterns lend themselves easiest for formal or automatic treatment.

There has also been a considerable amount of research on class retrieval tech-niques that are clearly related to pattern mining tools. An example of such a tool is ClassExpert [Czernecki et al. 1996] that helps to retrieve classes matching a functional specification provided by the user. Formal concept analysis is another method that has been applied to finding patterns without a predefined pattern li-brary (see, for example, [Viljamaa J. 2003, 2004] and [Tonella-Antoniol 1999]).

4.2.3 Application Implementation via Framework Specialization

Framework usability is a problem in part because of the intrinsic complexity of the framework specialization process, but also due to the lack of adequate docu-mentation techniques and tools. In our view, framework specialization is such a complex process that static documentation is not enough to provide sufficient help. Framework specialization is far more difficult than simply plugging com-ponents into hot spots: hot spots might have interdependencies, they might be optional, and frameworks may provide several ways of adding the same func-tionality, and so on. The specialization process should be explicit and unambigu-ous. It should allow the application developers to create valid applications in a straightforward manner.

One approach for making frameworks more understandable for their users is to visualize their static structure and dynamic behavior. The tools that can be used for visualizing the behavior of any OO software are naturally useful for frame-work visualization as well. These tools include, for example, execution-tracing tools, such as SCENE [Koskimies-Mössenböck 1996] that produces animated scenarios over the method calls in the Oberon environment [Reiser 1991]. An-other tool for providing similar tracing functionality is described in [Lange-Nakamura 1995].

In framework visualization, however, the tools should take into account the spe-cial meaning of hot spots in frameworks and emphasize their visualization. Fur-thermore, when documenting the usage of frameworks the focus should be on

how to specialize the framework, not on how the framework is designed or how it works.

Active Cookbooks

Active cookbooks [Pree et al. 1995] introduce the idea of actively guiding the framework specialization process. An active cookbook for a framework includes a knowledge base, a rule interpreter, and a working memory. The knowledge base contains the recipes for specializing the framework. The rule interpreter al-lows the selection of a particular recipe, presents the recipes as hypertext, main-tains temporary information accumulated during the interpretation of a recipe in the working memory, and generates the source code of additional or modified framework classes. The generated classes extend the particular framework.

Recipes provide the appropriate tools for specifying adaptations. When a recipe is interpreted, the developer is guided actively through all the development and configuration steps of a certain task. Typically, the developer just invokes the tool associated with a recipe. The recipe specifies dependencies between steps:

sometimes certain steps have to be accomplished before tools associated with other steps can be invoked.

SmartBooks

Another approach for making cookbooks more dynamic is the SmartBooks method [Ortigosa-Campo 1999; Ortigosa et al. 2000] that is based on logic pro-gramming. Based on this technique, a tool can provide the developer with choices of different high-level activities that can be carried out in order to create a new application from a framework. The activity rules are generated based on the instantiation rules provided by the framework designer.

The focus of the SmartBooks approach is on how a person who is specializing a framework can easily express the objective she wishes to reach next. The user expresses her objective by selecting items from a list of options presented to the user. Based on the selections the tool is able to generate tasks that have to be done to accomplish the objective. A sequence of tasks is called instantiation plan, and the process of plan creation is called planning.

The focus of the SmartBooks approach is on how a person who is specializing a framework can easily express the objective she wishes to reach next. The user expresses her objective by selecting items from a list of options presented to the user. Based on the selections the tool is able to generate tasks that have to be done to accomplish the objective. A sequence of tasks is called instantiation plan, and the process of plan creation is called planning.