FSL in Review

IFPS

Scalable Modeling System

GFESuite

Software Approaches

Smart Tools

GFESuite Software

Designing Digital

Deriving Sensible Weather Elements

Rapid Prototype Project

Forecast Methodology

Mt. Washington

Etcetera

Recent Publications

Contact The Editor

Design:
Wilfred von Dauster

GFESuite Software By Tracy Hansen

Introduction

The FSL development team investigated many software options and have tried to exercise utmost discretion in selecting the appropriate software for the Graphical Forecast Editor Suite (GFESuite). This article covers our approach to software design and several important technical decisions regarding application of Object-Oriented design and Extreme Programming concepts, and the use of Python, an interpreted programming language as an adjunct to C++.

Object Oriented Design

In the Object-Oriented design approach to software development (Figure 1), the data objects and classes (thought of as software modules) can be abstracted or identified from the real-world application. Then the operations to be performed on these objects are identified. For example, the forecast grid is the central data object in the Interactive Forecast Preparation System (IFPS), and grid values would be retrieved and modified in typical forecast operations.

Figure 1

Figure 1. Object-Oriented design using Rational Rose software, showing software classes and how they relate to and interact with each other.

An Object-Oriented approach minimizes the coupling or interdependence between classes so that the software is easier to develop, modify, and maintain. The cohesion within a class, on the other hand, is maximized to ensure one clear purpose and interface. This allows components to be more readily reused, reduc- ing future development time.

Visual modeling is another important aspect of Object-Oriented design, because it helps the developers see the classes that are being created and how they will interact. The diagram in Figure 1 was created with Rational Rose, a software package that supports visual modeling of Object-Oriented design. It illustrates software classes, or components, and how they relate to and interact with each other. As we use Rational Rose to help us keep our bearings when developing and designing software, the old addage "A picture is worth a thousand words" rings loud and clear. Figure 2 shows another type of diagram used in Object-Oriented design. The Sequence Diagram shows the sequence of events involving several software components, interactions between components, what methods are called, and what actions are taken at each step.

Figure 2

Figure 2. Sequence Diagram, created using Rational Rose software, showing the sequence of events involving software components.

In our software development experiences using Object-Oriented design concepts, each individual uses this methodology as needed rather than in a regimented manner. This avoids unnecessary overhead in the development process. However, when a design becomes too complicated to mentally track, we turn to Rational Rose and the design process. Thinking through the design in advance saves precious recoding time later. Another safeguard is to maintain good communication lines with other team members who may be involved in reviewing, modifying, or interacting with each design project.

Visual modeling is useful not only for the software itself, but also for the task which the software implements. Several forecast procedures are being modeled in order to get a better understanding of how our software can be useful in the field. The FSL team enforces continued communication and shares knowledge of Object-Oriented design with other developers working on other projects.

Extreme Programming

The concepts of Extreme Programming meshes well with planning for the IFPS Rapid Prototype Project. Its philosophy is to quickly determine the scope of the next software release and combine customer priorities with technical estimates. As with Object-Oriented design, this approach has not been applied formally, yet many of its core concepts are integral to the IFPS project. Software releases occur on a very short cycle, every 6 to 8 weeks, and monthly management meetings are scheduled to set priorities based on forecaster needs and technical feasibility.

The Extreme Programming approach suggests a full-time on-site customer, in our case, the National Weather Service. Since the Rapid Prototype Project is collocated with the NWS Boulder Forecast Office, the FSL development team is able to maintain constant personal interaction with the forecasters. Figure 3 shows an example of a software design change after consultation with the Boulder and other forecasters. When designing the GFE menu bar, we originally arranged it according to function, but then rearranged it according to the forecast process. The new arrangement is easier for experienced forecasters to follow, and also helps guide the trainee when learning the new IFPS approach to forecasting.

Communication is frequent with other forecast offices as well via a dedicated Web-based "listserver" for answering questions and for feedback.

Figure 3

Figure 3. An example of a redesigned Graphical Forecast Editor menu bar after consultation with NWS forecasters.

Another philosophy of Extreme Programming is that the system be designed as simply as possible, and that extra complexity be removed when it is discovered. The code is to be "refactored" or restructured when it becomes too cumbersome to add new functionality. Our team goal is to always maintain simplicity, while keeping an eye on future customer needs. Often the simplest solution is the most flexible and accommodates further enhancement very easily.

Intensive testing, both unit and functional, is recommended. Our top priority is adequate testing, and, indeed, historically this has been FSL's philosophy over the last decade of workstation development.

Extreme Programming also suggests that all programming be done in pairs of developers and collective ownership of the code. Although our group adheres to coding standards and there is some overlap of code ownership, we have not adopted the practices of pairs programming and collective ownership. (For more information, refer to Extreme Programming Explained–Embrace Change by Kent Beck.)

Python

The Python language is similar to Perl and other scripting languages, but provides a more integrated Object-Oriented approach. In our project, we deploy two Object-Oriented languages – C++ and Python. Since C++ is commonly used, we will describe the less familiar Python, which is an interpreted language, not precompiled, but translated line by line. The Python interpreter is implemented in C++. Python has dynamic typing and binding that allows variables to "metamorphose" or change their type at runtime. Also, all objects are treated as variables, even functions.

Python has very powerful data structures. Besides the usual text and numeric types, objects such as lists, tuples, and dictionaries are built into the language and are very easy to construct and to access. It also has a syntax that is simple and easy to read.

We have chosen to use Python heavily in our system for many reasons. Since it is interpreted line by line, the edit-test-debug cycle is much faster than when using C++. Whenever the interpreter finds an error, it provides a traceback, and simple print statements are usually sufficient to track down the problem.

Python's readability makes code extremely easy to maintain and modify. Because it is interpreted, it tends to run slower than Java or C++ for code involving heavy computation. As machines become faster this will be of lesser importance, but in this situation, Python works very well as a "glue" language to compose applications using lower level components. We use Python as a glue language in the GFE, writing the computationally intensive software in C++ and the user interface in Python.

We also use Python as a run-time interpreter for queries and Smart Tools (see separate article) allowing us to create bits of code "on the fly." These features give the system a lot of flexibility and power.

Python allows us to dramatically increase productivity, a very important factor when working against deadlines for the next software release. From our experience and that of others, it is not an exaggeration to say that it is 10 times faster to code in Python than in C++.

(Tracy Hansen can be reached at hansen@fsl.noaa.gov, or phone (303)497-6569.)


FSL Staff