Completing Hot Spot Specifications

After specifying the cores for the basic concept patterns we typically continue (1) by adding support for default method implementations, (2) by modeling data fields accessed by the methods, and (3) by specifying constructors required to initialize the fields. In this process we can usually utilize patterns ClassInstantia-tion, MethodCall, and FieldReference, as well as the bean patterns.

As an example, we look at the creation of the initialization pattern for the JHot-Draw framework. Figure 6.28 depicts the core of this pattern. The pattern con-tains three framework roles — DrawingEditor, DrawApplet, and DrawApplica-tion — as well as three roles for the applicaDrawApplica-tion-side entities: UserDrawApplet, UserDrawApplication, and UserDrawingEditor. All these roles utilize the Meth-odOverriding pattern in their implementation. The figure does not contain the method roles available in the pattern. The cores for the method roles are, how-ever, made similarly as we did in our example of patterns for the Figure sub-classes. The full version of the Initialization pattern is available in Appendix B.

Figure 6.28: Class roles for the initialization pattern of JHotDraw

Figure 6.29 shows a more detailed view on the structure of the DrawApplication and UserDrawApplication roles. The figure represents what we consider a typical example of how the contents of an overriding method role in a framework hot spot are implemented. The example shows how the pattern specifies a policy for overriding the framework method createTools in the application-side subclasses.

Method createTools is declared in the framework class DrawApplication. An im-plementation of that method should instantiate the application tools and add them

DrawingEditor User-

DrawingEditor

«pattern»

Initialization

* «inheritance»

MethodOverriding, Method, Class, Con- structor, Field, ClassInstantiation

DrawApplet

UserDraw-Applet

* «inheritance»

DrawApplication

UserDraw-Application

* «inheritance»

to the tool palette. The framework calls the method upon application initializa-tion.

Three patterns are shown in Figure 6.29: MethodOverriding, ClassInstantiation, and Initialization. Only those parts of the patterns that are relevant to the create-Tools application role in the Initialization pattern are shown in the figure.

Figure 6.29: Example of making a method body template for overriding a hot spot hook method

The framework annotator has used the MethodOverriding pattern to create the core for the Initialization pattern in the same manner as we saw earlier (recall Figure 6.26). During that process she has bound the framework roles DrawAppli-cation and createTools to the corresponding framework-side program elements;

these roles extend roles Base and method from the MethodOverriding pattern,

«pattern»

tool = new <#:/Tool.i.longName>(this, new <#:/Figure.i.longName>());

tool.setUsable(true);

respectively. Also, the annotator has created the application roles UserDrawAp-plication and createTools to represent apUserDrawAp-plication-specific entities. These roles extend roles Sub and method from the MethodOverriding pattern, respectively.

After creating the basic structure for Initialization by extending MethodOverrid-ing, the annotator has focused on implementing the contents of the createTools application role. Since the main purpose of a method bound to role createTools is to instantiate certain classes, the framework annotator has utilized the stantiation pattern for the implementation. The Instantiator class role in ClassIn-stantiation represents a class that instantiates another class. The Class role repre-sents a class that gets instantiated. Role method models a method that instantiates a class and the code fragment role ClassInstantiationCode does the actual instan-tiation. The pattern also contains a class instantiation constraint ensuring that a Java method bound to role method actually instantiates the proper class. The con-straint is indicated by the «class instantiation» stereotype in the figure.

In the Initialization pattern, roles Instantiator and method from pattern ClassIn-stantiation are extended by roles UserDrawApplication and createTools, respec-tively. Thus, in pattern Initialization, role createTools models a method that in-stantiates a class. In addition, roles createTool and Tool extend roles ClassInstan-tiationCode and Class, respectively. The framework annotator has created those roles by task postponement. However, the defaultTemplate scripts that were in-herited from the extended patterns to roles createTools and createTool were not sufficient to describe how tools are instantiated. That is why the framework an-notator has expanded and changed the default scripts. The finished scripts are shown inside the parchment symbols in Figure 6.29.

Figure 6.30 shows how the framework annotator uses JavaFrames to expand a script inherited from a generalization role. The top left frame shows the proper-ties of role createTools before changing the defaultTemplate script. In order to indicate that the script is inherited from a generalization role, the script is drawn with a light-grey color. In the next frame, the annotator has chosen to edit the script. In the edit dialog, the annotator pushes the Super button to view how the defaultImplementation script has been declared in the generalization role. The upper-half of the Copy Script from a Super Role dialog shows all the generaliza-tion roles of createTools, recursively. The lower half shows how the defaultTem-plate script declared in the selected generalization role would look like when it is expanded into the context of the createTools role. The expansion changes the role references in the script so that they refer to the roles declared in the speciali-zation role. In the generalispeciali-zation role, reference /DrawApplication/createTools.i.

overridingSignature is /Base/method.i.overridingSignature, for instance. This is because DrawApplication extends Base and createTools extends method. The lower-left window shows the final version of the script expanded from the gener-alization role: the user has kept the formal Java comment and the method signa-ture as-is, but altered the method body. Especially, the method body now con-tains a tag #addTool that is used as the insertion point for tool instantiation code fragments as they are generated from the createTool role. (Look again at Figure 6.29.)

In Figure 6.29, the framework annotator has overridden the defaultTemplate script of the createTool role in a similar manner as she did with the script for the createTools role. Note that by using the createTool code fragment role together with the createTools method role, we have split the method body template defini-tion into two parts. The createTools method role contains the first part (see the lower parchment in Figure 6.29) where a super class call and a local variable are generated together with the #addTool comment tag. The tag is used for locating the position for additional code segments generated based on the createTool code fragment role.

The code fragment role createTool specifies the second part of the method body template (see the upper parchment in Figure 6.29). This fragment contains code that creates a tool, sets it “usable”, creates a tool button, joins the button and the tool, and adds the button into the tool palette. In order to implement this default-Template script, the annotator has created additional roles: Tool, Figure, and toolImageDir.

Figure 6.30: Expanding a script in a specialization role

Role Tool represents the tool classes the application developer wants to instanti-ate. Figure models the figure classes manipulated with the tools, and toolImage-Dir describes a field that contains the file path to the directory where the tool icon files are stored in. The mandatory class role Tool depends on the create-Tools method role, so if the application developer chooses to override the method, she also has to locate at least one tool for it. The Figure role, on the other hand, depends on the Tool role, so for each tool the application developer

has to locate a figure, too. Similarly, toolImageDir depends on Figure, meaning that the application developer must also specify the location of the icon for the tool. For a complete example of a generated createTools method, refer to Appen-dix D, lines 72 – 89.

Generally, there can be many code fragment child roles created for one method role. These code fragments can represent different implementation variations for the method. Examples of how a method should be implemented can typically be found from the framework source code and the source codes of the applications that specialize the framework.

General Guidelines for Making Method Body Templates

The pattern developer must always try to think through the possible sequences in which tasks are generated for the application developer. The dependencies must be designed so that following the resulting task list feels logical. A good design principle is to develop patterns so that each time the user has done all the manda-tory tasks, she can compile, run and test a working version of her application.

With optional tasks she can then add new features to the application. The op-tional tasks may, naturally, cause new mandatory tasks to appear.

In the previous example we arranged the dependencies so that a single optional solution — “I will override the createTools method” — forces the user to follow a chain of mandatory tasks in order to complete a clearly separated piece in the complete framework specialization process.

The pattern role dependencies made when building the cores for the basic con-cept patterns concern only class inheritance and method overriding, so handling those dependencies during pattern development is usually quite easy. On the other hand, dependencies designed during the modeling of method body contents usually get more complicated. Consequently, we suggest utilizing the introduced graphical notation for patterns in order to better manage the dependencies. The notation helps the designer to form a general understanding of the patterns and alleviates the reasoning about the task list that results from the patterns.

Documenting the Patterns

Patterns must be documented before they are ready to be used. The documenta-tion is mainly intended for an applicadocumenta-tion developer. Each pattern has a general description that should clearly state the purpose of the pattern and the dependen-cies to other patterns. This information helps the application developer to deter-mine whether the pattern at hand provides assistance for accomplishing the de-sired task. Especially, the initialization pattern should be clearly identified as be-ing the suggested startbe-ing point for application development.

As noted earlier, each role in a pattern has two document scripts attached to it.

The taskTitle script is typically a short one-line note, where as the taskDescrip-tion script can contain more detailed instructaskDescrip-tions. They both should guide the user in binding the role to a Java element. JavaFrames interprets the evaluated taskDescription script as HTML, so that script can contain pictures and

hyper-links to other documents that may, for example, contain information about possi-ble design patterns and metapatterns in the framework reuse interface.

Testing and Debugging Patterns

Because of the highly dynamic nature of the JavaFrames patterns, we can test them during development. By creating a test pattern that extends the pattern under

implementation, we can check how tasks are created from the pattern. This is especially useful as we are trying to build a logical path of tasks for the application developer.

Figure 6.31 shows how the framework annotator is testing the Initialization pat-tern for the JHotDraw framework. In the figure we can see that the task title for a task generated from the createTool code fragment role has an error in it: the in-terpreter for the taskTitle script is unable to interpret a tag, and an error message is displayed instead. The error message indicates that the script refers to an un-known feature, i.e. a script function or a script role, called /Tooli. In order to fix the error, the framework annotator has chosen the action Show Task Originator Role that allows her to view the erroneous script. When looking at the script, it is obvious that the developer has accidentally misspelled the role name Tool.

Figure 6.31: Testing and debugging patterns

Easy navigation between roles and tasks helps the framework annotator to de-velop and test her patterns. For the same reasons, it is very important to be able to navigate up and down the pattern hierarchies. As noted earlier, this is possible via the Hierarchy tab in the Pattern view.

137

Chapter 7 Case Studies

For this thesis, I have completed a series of case studies in order to test the appli-cability of JavaFrames (recall Chapter 6.1) and the use of hierarchical patterns for reducing the work needed for developing patterns (recall Chapter 6.2).

As the first case study, I annotated the framework reuse interface of the 5.1 ver-sion of the JHotDraw framework (recall Chapter 3.2.3). The annotation was done by using an older version of JavaFrames (i.e. Fred 1.3). At that time JavaFrames did not implement hierarchical patterns. The case study was reported in my licen-tiate thesis [Viljamaa A. 2001]. The results of the case study were considered positive: it was possible to specify the reuse interface of a well-known real-world framework with JavaFrames and use JavaFrames for providing significant help in making applications from the framework. However, the downside was that speci-fying the reuse interface required a lot of work and the resulting patterns were considerable large.

After the initial case study it was clear that the focus of improving JavaFrames had to be on making the framework reuse interface specification easier and faster. Inside the JavaFrames development team two paths were taken to over-come this problem. Firstly, Jukka Viljamaa started to investigate possibilities to create the framework reuse interface specification patterns based on analyzing the framework source code and the source code of the existing applications. The results of this work are reported in Jukka Viljamaa’s PhD thesis [Viljamaa J.

2004]. I decided to try an alternative approach and develop the reuse capabilities of JavaFrames patterns through pattern inheritance and reusable pattern libraries.

By using the experiences gained from the earlier case studies I started developing a generic library of patterns that would help to reduce the mechanical work in-volved in making framework reuse interface specifications. I started with the core library of reusable patterns and continued gradually towards the lower-level patterns by reusing the properties of the higher level patterns. Developing the pattern library was an iterative process: the requirements at the lower levels propagated changes to the upper levels. In this way the usability of the higher-level, more general, patterns was constantly tested during the development proc-ess.

The first level of patterns included the patterns in the Generic OO Patterns archi-tecture. These patterns model the basic OO program elements and their relation-ships. Recall from Figure 6.17 (page 114) that the patterns in the Generic OO Patterns architecture are hierarchically built on each other.

As the first phase of testing the usability of these generic patterns, I utilized them in implementing the JavaFrames patterns for the JavaBeans architecture. From there I continued to implementing Pree’s metapatterns. By definition, Pree’s metapatterns describe all the possible ways of arranging a hook and a template method in an OO program. Being able to model the JavaBean patterns and the metapatterns with generic JavaFrames patterns gave confidence of the usability and comprehensiveness of the generic patterns. Also, the JavaFrames patterns for the metapatterns became nicely hierarchical themselves (recall the high-level structure of the patterns in Figure 6.22, page 119.)

The patterns in the Design Patterns architecture were developed based on the previous pattern layers. The intention was not to cover all the possible design patterns, but rather to test the upper pattern layers with selected representative design patterns that have a clear implementation structure. The design patterns I chose to model were AbstractFactory, Composite, Singleton, and Observer (re-call Figure 6.23, page 120).

7.1 JavaFrames Patterns for JHotDraw and Struts

The experiments with metapatterns and design patterns provided a way to try out the idea of creating patterns by extending one pattern from another. After that it was time to move on to building reuse interface annotations for real frameworks.

As a combined case study with Jukka Viljamaa, we annotated the reuse interface of the Struts servlet framework (recall Chapter 3.2.3) by using the library of hier-archical patterns. After that, Jukka Viljamaa created another annotation for the Struts framework by using his semi-automatic Pattern Extractor. In his PhD the-sis, Jukka Viljamaa compared the results of the semi-automatically made patterns to yet another “flat” annotation of Struts where he had removed the pattern hier-archies. The hierarchies were removed because Pattern Extractor does not pro-duce hierarchical patterns.

I, in turn, chose to re-annotate the JHotDraw framework that I had already used in my licentiate thesis. There were two reasons for this. Firstly, I wanted to make a case study with a more traditional OO framework; Struts is a bit exceptional, since it heavily utilizes XML and JSP instead of subclassing. Also, by re-annotating a framework that was tested with the earlier (Fred 1.3) version of JavaFrames I was able to get more material for comparing “flat” and hierarchical framework reuse interface annotations.

For the JHotDraw framework I picked the latest stable version (5.3) from [www.jhotdraw.org]. Similarly, the Struts case study involved the latest version (1.1) of the Struts framework available at [struts.apache.org]. Recall the descrip-tions on the sizes and characteristics of the frameworks in Chapter 3.2.3.

In the case studies with the JHotDraw and Struts frameworks I managed to spec-ify the reuse interfaces of the frameworks nicely by specializing new framework-dependent patterns from my library of reusable patterns. The following figures provide a high-level view to the patterns. The full versions for the patterns are available in Appendix B.

Figure 7.1 shows the top-level of the reuse interface annotation for the JHotDraw framework. At the highest level, the JHotDrawFramework architecture contains one pattern (Initialization) and nine inner architectures: ConnectionFigure, Con-nectorBasics, FigureBasics, FigureChangeListener, FigureConnections, Han-dleBasics, HandlesForFigures, Storable, and ToolBasics. The Initialization pat-tern is used for specifying the main class for the application and for instantiating the central application objects. Note that all the patterns recursively inside the JHotDrawFramework architecture extend patterns from the reusable pattern li-brary; in this top-level figure the extensions are only shown for the Initialization pattern.

Figure 7.1: The top level of the of JHotDraw reuse interface specification

Figure 7.2 shows the ToolBasics pattern. It is used for creating and restricting the properties of classes that represent JHotDraw tools. Tools will be visible in the program’s tool bar. Tools are employed for creating, selecting, and manipulating figures and connectors. The patterns in the ToolBasics architecture are based on each other: AbstractTool extends Tool and the other patterns, in turn, extend Ab-stractTool.

The HandlesForFigures architecture (Figure 7.3) is used for attaching handles to figures. The ConnectorBasics pattern, on the other hand, is used for creating and restricting the properties of connectors. They connect figures to each other.

The patterns in the FigureBasics architecture (Figure 7.4) are used for creating and restricting the properties of classes that represent figures drawn in JHotDraw applications. The FigureChangeListener pattern is used for adding listener be-havior into classes. The listener receives notifications about changes in figures.

«architecture»

Figure 7.2: JHotDraw reuse interface specification — ToolBasics

Figure 7.3: JHotDraw reuse interface specification — HandlesForFigures and Connec-torBasics

Figure 7.4: JHotDraw reuse interface specification — FigureBasics and

Figure 7.4: JHotDraw reuse interface specification — FigureBasics and

In document Specifying Reuse Interfaces for Task-Oriented Framework Specialization (sivua 138-0)