JavaFrames and Related Work

Although heavily influenced by the implementations of design patterns (Chapter 2.4), JavaFrames patterns should not be confused with them — the very essence of design patterns are the informal descriptions, especially the benefits and trade-offs of using the patterns, whereas JavaFrames patterns focus on modeling con-crete source code structures in order to provide tool support for creating them and monitoring their validity. The implementation of a design pattern can often be described as one or more JavaFrames patterns, and the informal description of the modeled design pattern can be linked to the JavaFrames pattern, as can any other arbitrary hypertext document. However, JavaFrames patterns are not re-stricted to describing design pattern implementations. They can also be used for implementing metapatterns, idioms, as well as general naming conventions, for example.

The idea of JavaFrames patterns is close to that of contracts (Chapter 4.1.5).

Contracts aim at specifying reusable program fragments and restricting their be-havior by declaring constraints that are monitored during program execution.

JavaFrames patterns, however, mainly aim at supporting the framework speciali-zation process, and thus the constraint monitoring happens at development time while typing in source code. Therefore the constraints proposed in this thesis are more focused on static, structural specifications. Overall, due to the simplicity of our patterns, they are not too formal and too inflexible to use. Furthermore, the semi-graphical notation and direct tool support facilitate the development of JavaFrames patterns. In [Holland 1992], for instance, a conventional textual rep-resentation is used for specifying contracts.

Several design pattern tools (see, for instance, [Budinsky et al. 1996; Eden et al.

1997, Florijn et al. 1997, Meijler et al. 1997]) have been proposed to ease the definition of design patterns, to allow the incorporation of patterns into specific projects, to instantiate design descriptions, and to generate code. The JavaFrames tool is different from these because of its interactive nature and strong coupling of patterns and source code: constraints are checked constantly as the user types in source code. Also the task-oriented support for instantiating patterns is differ-ent from the previous approaches. Furthermore, we believe that JavaFrames’

strong pragmatic approach is something not very often seen in academic tool pro-totypes. We have worked hard to develop a Java development environment where JavaFrames’ applicability can be evaluated in practice with industry-sized frameworks.

The JavaFrames tool can be seen as an extension of the notion of framework cookbooks (Chapter 4.1.3). Whereas cookbooks allow static and linear step-by-step task lists for framework specialization, the JavaFrames tool introduces a dy-namic approach where the choices made by the user affect the subsequent guid-ance offered by the tool.

Pattern languages (Chapter 4.1.4) have been frequently proposed for document-ing frameworks and guiddocument-ing their specialization. We believe that JavaFrames could be used to further facilitate the use of pattern languages. As an added value for the plain of use pattern languages, JavaFrames offers constraints for validat-ing application code, code generation, dynamic documentation, and bindvalidat-ings be-tween the patterns and the source code.

In [Kirk et al. 2002], the authors identify a central problem with the pattern lan-guage for HotDraw discussed in [Johnson 1992]: Johnson’s patterns describe specific details about the framework, instead of focusing on general qualities that are true for a range of frameworks. Recall from Chapter 2.1 that the latter was in fact the original intention in Alexander’s patterns; he, however, described the properties of buildings instead of software artifacts. We acknowledge the fact that in order to be able to provide concrete support for specializing frameworks, the patterns for the framework documentation must tackle the concrete features of the framework. Unfortunately, this implies a lot of work, if the patterns are to be written from scratch, because there are no high-level patterns to be reused.

This thesis has shown that it is possible to develop extendable generic patterns

that can be reused for implementing framework-specific patterns. This makes pattern writing significantly easier and more controlled.

Active cookbooks (Chapter 4.2.3) seem to offer more dynamic guidance for framework specialization than mere cookbooks. However, we consider active cookbooks as just a proposal for the general principles of such tools, since they leave many key points rather vague, especially the way a task list becomes auto-matically updated as the framework code changes. In [Pree et al. 1995], it says:

“The knowledge base is typically influenced by the evolving framework. Changes in relationships between framework components might imply additional struc-tural or informal relations that modify recipes or add new ones to the knowledge base.” However, this is not explained further. So, the level of activeness of active cookbooks is unclear. In the active cookbook approach the emphasis appears to be on providing higher-level tools for accomplishing particular types of tasks. In JavaFrames, we currently only have two kinds of tools (i.e. wizards) for accom-plishing tasks: others are used for locating existing program elements and others are used for generating code. However, we emphasize the dynamic nature of the tasks list, and propose a clear model of how it is dynamically generated based on the JavaFrames patterns and the role bindings the user makes.

The SmartBooks method (Chapter 4.2.3) reminds the model described in this the-sis. However, we feel that JavaFrames is more pragmatic. The main idea of SmartBooks is that the user is able to precisely specify what kind of application she wants, and then a dynamic list of tasks is generated to obtain the goal. In the approach proposed in this thesis, all the “top level” tasks related to different parts of the framework are available right from the start, and the user can browse the tasks in order to decide what to do next. In other words, the user can view all the different starting possibilities. With SmartBooks, the actual possibilities remain a bit vague for the user. In SmartBooks, the task list generation is based on func-tional rules that are represented in predicate logic. However, the process of de-termining what kinds of rules are needed for different functionalities looks unsys-temized. Also, no list of the available basic predicates is given in [Ortigosa et al.

2000]. Thus, it remains unclear, whether there is a fixed set of predicates, or is the user allowed to create new ones. And, if so, how are they defined? Also, it seems that SmartBooks is not actively checking the validity of the framework specialization: constraints (the availability of a certain class, for example), are apparently checked only when applying a task list in order to provide new func-tionality. However, the effect of changes to code that is generated based on pre-vious tasks remains unclear and we assume that there is no effect whatsoever.

Finally, we argue that the methodology described in this thesis has the following two important advantages over the predicate logics of SmartBooks: (1) Java-Frames patterns are more practical to use for an average software developer and (2) in the JavaFrames approach the role bindings of patterns act as a documenta-tion for the framework and for the applicadocumenta-tion derived from the framework.

SmartBooks does not seem to leave any traces of the work done except the pro-duced source code.

Framework design tools (Chapter 4.2.2) naturally emphasize hot spot design over framework specialization. In [Fontoura et al. 2000], for example, framework spe-cialization is considered a straightforward process if only the hot spots are clearly designed. The authors propose a wizard-like framework specialization tool that executes UML-F descriptions organized in a cookbook. The idea of using a wiz-ard tool for guiding the instantiation is close to this thesis’ vision of what is needed for framework specialization. However, we argue that framework spe-cialization is a more complicated process than stated in [Fontoura et al. 2000].

This is because a tool used for guiding framework specialization must be aware of the dependencies between hot spots, for example. We believe also that the task-list-based approach is more comprehensive and dynamic than what is pro-posed in [Fontoura et al. 2000]: in JavaFrames changes to source code are di-rectly reflected in the task list.

The approach for framework specialization introduced in [Oliveira et al. 2004]

(Chapter 4.1.6 and Chapter 4.2.3) resembles the ideas implemented in the Java-Frames tool. In [Oliveira et al. 2004], framework specialization tasks are repre-sented explicitly by using a scripting language that allows subclassing and method overriding, for instance. However, JavaFrames offers a wider set of con-straints applicable for the application elements. There are, apparently, very lim-ited possibilities for describing the method body contents in [Oliveira et al.

2004]. JavaFrames offers means for controlling method calls, field references, and class instantiation, for example. On the whole, the JavaFrames language al-lows more flexible and dynamic ways to guide the framework specialization process. For example, in JavaFrames the documentation related to specialization tasks can be made adaptive. Moreover, there appears to be no methods for reus-ing the framework annotations in [Oliveira et al. 2004]. Thus, we assume that making the UML-FI descriptions and framework specialization scripts can be rather laborious.