INTRODUCTION

Unidata's transition to platform-independence presents a unique opportunity for users to help shape a new suite of display and analysis applications for the atmospheric sciences. With the guidance of a group of users from the community, Unidata developers are creating prototype meteorological applications in Java. Ultimately, this effort will result in a component-oriented framework that supports the assembly of custom applications. We review lessons learned from the current prototype applications, discuss issues involved in the construction of an application from components, and evaluate the benefits of this kind of software for research and education.

GOALS

The long-term objectives of Unidata's current development effort are to:

• deliver platform-independent software for the analysis and visualization of meteorological data;
• create a component-oriented framework that supports assembly of custom applications;
• maintain, support, and enhance the software for the Unidata community; and
• enlist other developers in enhancing components and developing new components.

 

The software will ultimately deliver capabilities similar to those of other well-known analysis and display packages such as NMAP (formerly GEMPAK), McIDAS, and WXP. The new software will differ from these other packages in one significant respect: it can be installed on any platform that provides the necessary Java support.

These goals are ambitious and will require significant effort over several years. In the short term, prototype applications are being designed and implemented with a user-centered development methodology to help determine the right architecture for the planned components and to tune the process used for their development. The comprehensive data model and advanced visualization capabilities of VisAD are serving as a foundation for some of the prototypes, which include:

• a surface observations viewer that displays archived or current METAR data from NOAAPORT, supporting zoom and pan, changing projections, and map underlays;
• an interactive sounding application that displays a skew-T diagram and a 3-D wind hodograph, and that permits simple editing of the temperature, dew-point, and wind values;
• a satellite data viewer that displays satellite images on a 3D rotatable globe with looping and navigation; and
• a model data viewer that displays model outputs at various levels of the atmosphere.

 

RESOURCES REQUIRED

Considerable effort was required to develop packages such as GEMPAK, McIDAS, or AWIPS to their current level of maturity and functionality. Attempting to develop a similar package with an order of magnitude less resources is both daunting and ambitious. There are several reasons why we believe this effort will succeed.

One reason is our use of the Java programming language, which embodies much of the best practices of software engineering, including object orientation, type safety, multithreading, and garbage collection -- features which, by themselves, increase programmer productivity and code correctness. Additionally, the Java environment promotes increased productivity in other ways. It's standardization and portability frees us from the need to expend resources supporting multiple platforms. Its rich set of class libraries allows our development to "stand on the shoulders of others" (rather than "stand on other's toes" as some have characterized previous reusability efforts). Finally, Java's open source and the large number of open source developers in the Java community promises continued development of substantial, useful class libraries. In this sense we arguably have more resources for our application development than the developers of previous meteorological packages.

Another reason for optimism is our use of component-based software engineering (CBSE) practices. CBSE is a method for developing and packaging software by which independently developed pieces of software can interact with each other, and can be assembled into useful new configurations by third parties. CBSE will enable the Unidata community to share not just data, but also the software needed to visualize and analyze that data.

A final reason for the probable success of this undertaking is the use of VisAD (Hibbard 2000). This package provides a generic model of scientific data and a sophisticated, three-dimensional visualization system. Using this package will bypass several developer-years of effort.

USER-CENTERED DEVELOPMENT

Involving users early and often in the software development process should help to improve the quality of the results. The Unidata Meteorological Applications (MetApps) Task Force is a group of knowledgeable users who have volunteered to participate in distributed collaboration with Unidata developers to help create the new applications and components. The MetApps group has specified what will be in the initial prototype applications by writing use cases. A use case is a way of describing the functional requirements of a software system. However, instead of an abstract description of those requirements, a use case is a concrete, detailed description of a representative task, written using the language and goals of the user. The emphasis is on specifying, specifying what the user wants to do, rather than on how the user would do it.

After MetApps members write use cases, development typically begins with a simple prototype that lacks most of the intended functionality. The MetApps users then offer feedback on the design and what is needed next, and the prototype is subsequently modified in a process of relatively small incremental developments that incorporate user feedback and adapt to changes in user requirements from experience with the prototype.

Development of prototypes supported only for a limited set of knowledgeable users and with no backward-compatibility constraints requires less time than development of polished applications for a broad user community. Developers have an understanding with the MetApps users that the goal of the prototypes is not polished applications, but rather insights into how to best implement the needed capabilities, what user interfaces work best, and what capabilities are candidates for components.

LESSONS LEARNED

The current effort involves about 3 Java developers and 12 users. It is still too early in the project to confidently say whether all the project goals will be accomplished with this level of effort, but it is possible to comment on a few aspects of how well the distributed participatory design and development are working:

• Use cases seem to be an adequate way to represent user requirements for these kinds of applications.
• Email has significant shortcomings as a way to communicate among users and developers. We are now trying a web tool that organizes discussion threads around artifacts such as design documents and prototypes, but getting a high level of participation from developers and users requires significant effort.
• It is necessary to allow extra time for infrastructure development and refiguring of designs, even though these activities may not result in user-visible changes to prototypes.
• Java seems to be a good choice for developing platform-independent applications, but it requires significant developer time to keep up with new Java libraries and interfaces that may be useful.
• Developing useful components of the right granularity is difficult, and requires multiple iterations.

 

Unidata's developers cannot focus solely on developing new applications, but must still dedicate some time to maintenance and support of current application and infrastructure (for example, Unidata's LDM and netCDF software, the Internet Data Distribution system, and new data sources) in the face of rapidly changing data streams and technology.

BENEFITS

It is too early in this project to evaluate its ultimate success, but our experience so far seems to indicate that the development of platform-independent analysis and display applications is now practical and desirable. The possible benefits include reduction of efforts spent porting software, creation of software designed specifically for the Unidata community of educators and researchers, ownership of the software to facilitate maintenance and enhancement, and use of distributed objects and component frameworks to create applications that incorporate the best characteristics of modern software engineering technology.

Building the correct infrastructure for component-based applications will require clear goals and numerous iterations. The pressure to develop and support working, useful applications in the near future may cause premature commitments that would work against our ability to deliver on the promise of component-based software. Fortunately, the Unidata community has always understood the necessity of balancing resources among support, maintenance, and development and of foregoing some short-term developments to make longer-term goals achievable.

REFERENCES

Caron, J., 1999. "Component Based Software for Scientific Application Development," 15th International Conference on Interactive Information and Processing Systems for Meteorology, Oceanography, and Hydrology, Dallas, Texas, Am. Meteor. Soc.

Fowler, M., K. Scott, 1997. "Chapter 3: Use Cases" from "UML Distilled: Applying the Standard Object Modeling Language," Addison-Wesley. <URL: http://www.awl.com/cseng/titles/0-201-32563-2/umldist-chap3.html>

Hibbard, W., 2000. "An Example of Unidata's Future in New Software: the VisAD Component Architecture for Collaborative Data Analysis and Visualization," 16th International Conference on Interactive Information and Processing Systems for Meteorology, Oceanography, and Hydrology, Long Beach, California, Am. Meteor. Soc.

Wright, M., "About UMADA (Unidata MetApps Discussion Area)", October 1999. <URL:http://www.unidata.ucar.edu/community/committees/umada/>