Table of Contents 
Previous Chapter
CHAPTER 3 Design and Development Methodology
WFO-Advanced is a rather large system, encompassing data acquisition, storage and retrieval to a variety of file formats and to a relational database, user interface and display, and monitoring and control capabilities. No one design method handles all of these problem domains particularly well, so our guiding philosophy has been to use the design method appropriate to the problem at hand.
In general, this has resulted in dataflow design techniques being applied to the data acquisition components of WFO-Advanced, and object-oriented design techniques being applied to the display and user interface components, with a blend of the two being used in the data management area.
No single, formal object-oriented design method was applied to the object-oriented components of WFO-Advanced. Generally, our initial design efforts concentrate on the static aspects of design, establishing well-defined public class interfaces based on responsibility-driven class decompositions, and relying on well-known principles of data abstraction and information hiding. If the dynamic interactions between objects are a particularly important part of a design problem, a representative scenario will typically be introduced as part of the initial design discussions. Generally speaking, we try to avoid complicated inheritance relationships, particularly eschewing all but the most trivial uses of multiple inheritance
The WFO-Advanced design has been influenced by the emerging discipline of design patterns, which provides a language for discussing reusable design components within the context of an object-oriented design. A design pattern is a stylized set of classes, objects, and interactions, working to solve a common problem. The language of design patterns provides a way for designers to discuss designs and reusability at a level of abstraction above that of an individual class.
For example, probably the most common design pattern used throughout WFO-Advanced is the Singleton pattern, which provides a standard way to initialize and provide global access to an object, guaranteed to be unique throughout a process. When a developer identifies a particular class as a Singleton, a large amount of information is summarily transferred to other developers about the use of that class.
The C++ programming language is the primary language of WFO-Advanced. We use C++ both for its support of object-oriented programming, and as a "better C." Our use of inheritance is generally limited to the "forest" approach of using a large number of disjoint base classes, rather than the "tree" approach of having a system-wide set of base classes inherited from a a single class. We rely heavily on the C++ template mechanism, using it as the basis for a set of common container classes.
Particularly for meteorological calculations, we reuse a body of legacy FORTRAN libraries from previous development projects within FSL. Little new development within WFO-Advanced was done in FORTRAN.
Tcl (tool command language) is a scripting language developed by John Ousterhout. In conjunction with a co-developed user-interface tool kit called Tk (tool kit), Tcl/Tk provides a powerful, easy-to-use environment in which to develop user interfaces. The text workstation user interface was developed with Tcl/Tk, and we plan on converting the graphic display interface to Tcl/Tk.
Some parts of WFO-Advanced, particularly startup scripts, and some background processes run as cron jobs, are written in various scripting languages including the Bourne UNIX shell (sh), the Berkeley UNIX shell (csh), and perl.
The development model used by the WFO-Advanced project is one of iterative, incremental development cycles. Our approach is similar to that sometimes referred to as the spiral model of software development, although the spiral model is more risk-driven, while our development cycles are more requirement-driven.
Our normal development cycle is a period of two to four months. For each cycle, a set of requirements is established, generally as a delta set of functionality from the previous development cycle. The requirements are then prioritized, and a set of prioritized task assignments is generated. Design authority is generally delegated fairly early in the process, so that task assignments encompass both design and implementation aspects.
Rather than integrate as a final phase of the development cycle, WFO-Advanced integration is effectively a daily activity throughout the development cycle. When a developer has completed some set of functionality, the associated files are released by the developer from that developer's private staging area to a shared baseline area. A nightly "master build" is done on the baseline, ensuring that at least the interface specifications are consistent, and the syntax correct.
No automated integration testing of the resulting system is done as part of the daily build, but after a clean build, the resulting system is occasionally "pushed" to another system for manual integration testing.
For source code configuration management, WFO-Advanced uses the BCS (Baseline Configuration System) software package. BCS uses RCS for individual file configuration management, but extends RCS to include the management of a shared baseline source directory, with each developer having a private staging area. Files which are locked by a developer are available for modification in that developer's staging area. Files which are not locked are represented in the staging area as symbolic links back to the real version, in the baseline directory.
The extent and depth of unit testing is rather uneven across the project. The developer of a module is responsible for unit testing where feasible. In a number of cases, the interfaces to a module are so numerous or complicated that the development of unit-test scaffolding for that module is deemed too expensive, and testing is deferred to the integration testing level.
In general, there are unit test programs for testing inventory and retrieval for each WFO-Advanced data source. Most data decoders also have test drivers. There is also a suite of unit test drivers for checking the various static info files. There is little unit testing scaffolding in the display and user interface components, due at least in part to the complexity and dynamic nature of the protocols between components.
Integration testing of WFO-Advanced is a manual procedure. In short, someone sits in front of the system and uses it, noting any problems encountered. While this may sound inadequate, and does need be formalized a bit more than it is, it is surprisingly effective. Within FSL, daily weather briefings are given on the system, and new features and capabilities usually receive early attention as part of these briefings.
There is currently no automated integration or regression testing of WFO-Advanced. In a system like this, with flexible user requests and real-time data interactions, significant manual integration testing will always be a necessity, but some significant automated testing could be added. This is one of the anticipated benefits of redesigning the user interface with Tcl/Tk, which should make it easy to add at least some automated testing via scripts.
Table of Contents 
Next Chapter
This document is maintained by Joe
Wakefield. Last updated 9 Jan 97.