An Object-Oriented Framework for Local Extensions to the WFO-Advanced Forecaster Display Workstation, D2D

This paper describes the D2D extension framework, compares it to other types of frameworks, and discusses its future directions.

• The framework provides default behavior for extensions that performs the correct actions in most cases. Local extension developers augment or replace only as much behavior as necessary.
  
• The framework library provides its own main routine.
  
• The D2D software reads configuration information stored in plain text files; part of this information shows where extensions should appear in the D2D menus. An extension can be added by merely updating these files---there is no need to recompile any of the core D2D software.
  

Interactive depictables are half-objects shared between the core D2D software which draws them and the extension which manipulates their contents. They are indexed either by frame number or by frame time, since each frame in a displayed loop has a time index. Interactive depictables contain editable elements (described in the next section), and are the canvas onto which an extension draws elements, and on which the forecaster interacts with the elements.

The class InteractiveDepictableExt represents the extension half of the half-object. Local extension developers use the method newElement to add or change an editable element in the depictable. There are also methods to query and remove elements, and methods to query the frame and time index of the depictable.

Editable elements may be used to depict any kind of data: isobars may be a series of polylines; storm centroids may be points; warning areas may be polygons; and so forth. Extension developers place editable elements by specifying latitude and longitude, and the D2D software automatically draws them in the correct place in relation to the map background.

 1 class Extension {
 2 public:
 3   virtual ~Extension();
 4   bool isActive() const;
 5   void deactivate();
 6   virtual void activeStateChanged(bool isActive);
 7   short activeIntDepictIndex() const;
 8
 9   virtual void editedPoint(EditablePoint*, bool);
10   virtual void editedLine(EditableLine*, bool);
11   virtual void editedPolygon(EditablePolygon*, bool);
12   virtual void editedPolyline(EditablePolyline*, bool);
13   virtual void deletedElement(EditableElement*) {}
14   virtual void handleIntDepictSeqChanged(
15       SeqOfPtr< InteractiveDepictExt* > deletedDepicts,
16       SeqOfPtr< InteractiveDepictExt* > oldDepicts,
17       SeqOfPtr< InteractiveDepictExt* > newDepicts
18   );
19 protected:
20   Extension( omitted );
21   const SeqOfPtr<InteractiveDepictableExt*>&
22       interactiveDepictables() const;
23   InteractiveDepictableExt* intDepictForTime();
24 };

class SimpleExtension : public Extension {
public:
    SimpleExtension( omitted ) : Extension ( omitted ) {}
};

By overriding the definitions of these functions, the extension can provide any kind of behavior necessary. As an example, the WarnGen extension uses points in a frame sequence to mark the location of a storm. If the forecaster moves a point in one frame, the editedPoint function computes a new storm track and adjusts the locations of points in other frames accordingly, based on computed velocity and frame times.

Line 13 is a method that is called when the forecaster deletes an editable element. As shown, the default behavior is to take no action. Extension developers may override the behavior with any other action they desire.

• about to be deleted. If the forecaster shortens the sequence, the earlier depictables are passed in here. For the auto-update case, it is always the first depictable previously at the beginning of the frame sequence.
  
• old. These are depictables that may have changed their frame index, but were otherwise already known to the extension.
  
• new. These are depictables that just got created. For the auto-update case, it is the latest, new depictable.
  

The reason for all this complexity is that the extension may have to perform some sophisticated processing in light of the new time indices and/or new depictables. As an example, consider again a storm tracking extension using points to locate a storm in each frame. The new depictables will be empty, so the extension will have to compute the new storm location in those frames and create the points in the right places.

class SampleExtension : public Extension {
public:
    SampleExtension( omitted ) : Extension ( omitted ) {}
    virtual void handleIntDepictSeqChanged(
        SeqOfPtr< InteractiveDepictExt* >,
        SeqOfPtr< InteractiveDepictExt* >,
        SeqOfPtr< InteractiveDepictExt* > newDepicts
    ) {
        char buf[20]; // Space to hold annotation
        for (int i = 0; i < newDepicts.length(); ++i) {
            // Put a point in each frame.
            LatLonCoord coord(40 + (i * 3), -100 - (i * 3));
            sprintf(buf, "Point at %f,%f", coord.lat,
                coord.lon); // Make the annotation
            // Create the point and add it to depictable
            newDepicts[i]->newElement(new
                EditablePoint(coord,
                    Marker(Marker::X_ICON), buf));
        }
    }
    virtual void editedPoint(EditablePoint* pt, bool) {
        char buf[20]; // Space for new annotation
        // Get new location
        LatLonCoord newCoord(pt->location());
        sprintf(buf, "Point at %f,%f", newCoord.lat,
            newCoord.lon); // Make new annotation
        pt->setAnnotation(buf); // Update annotation
        interactiveDepictables()[activeIntDepictIndex()]
            ->newElement(pt); // Update point in frame
    }
};

• WarnGen, the most complex extension, generates severe weather warning text. It includes storm tracking and warning area features. The forecaster draws a polygon representing a warning area, and the affected counties are marked. The storm tracker plots the current and predicted path of a storm. From this information, WarnGen automatically creates a text product listing the storm's movement, affected counties or zones, and other (optional) text.
  
• Distance/Bearing displays several editable lines. The forecaster moves the lines between on-screen objects, and the annotation on the lines shows the distance and compass bearing between them.
  
• Points and Baselines are two helper extensions. When requesting vertical or cross-section data from D2D, the forecaster uses these extensions to locate a point or a baseline from which to compute the displayed data.
  

The ASX framework features many classes from which a developer derives classes to implement application-specific behavior, whereas the extension framework uses just one class (class Extension). This is because the D2D extensions are far more limited than distributed systems. In addition, many details, such as reading local datasets, are left to the discretion of the local extension developer. The Conduits+ framework is particularly easy to use because of black-box reuse, a kind of software reuse that relies on composition of objects instead of inheritance from base classes. Inheritance frameworks, such as the D2D extension framework, are instances of white-box reuse: developers tend to need to know about the implementation of the components they are reusing.

A framework allows developers to build extensions faster. Families of extensions are all similar, simplifying software maintenance. However, the choice to use a framework for local extensions is risky because the single architecture imposed by it must work for all possible scenarios. Further, frameworks are hard to design, and, because local extensions depend on the framework, the framework's evolution will affect existing extensions (Gamma et al., 1995).

An alternative is to provide a library toolkit, so that extension developers can use any design they wish, and be able to access any part of the library as needed. However, creating local extensions becomes more difficult because the developers now have to make architectural decisions that a framework would have imposed.

FSL implemented another approach for local functionality, the D2D application interface, which is also described in this volume (Kelly, 1997). It enables programs to send commands to the D2D software and receive responses, but does not provide integrated extensions as the D2D extension framework does.

Future work for the extension framework will likely include a Tcl interface (Ousterhout, 1994), enabling developers to write simple scripts to make extensions instead of having to compile C++ programs. These scripts may include Tcl's user-interface library, Tk.

Other work may include running extension processes on an application server (Grote and Kahn, 1996) instead of on the same host as the D2D display processes. This will help prevent overtaxing the workstations running the core D2D software and improve system responsiveness.