Next: A FITS Image Extension Kernel for IRAF
Previous: PC-IRAF: The Choice of a GNU Generation
Table of Contents --- Search ---
PS reprint
J. J. Travisano
Computer Sciences Corporation, Space Telescope Science Institute,
Baltimore, MD 21218
StarView is the user interface to the HST Data Archive (Williams 1993; Long 1995). It supports the following features:
StarView is currently supported on the following platforms: SunOS 4.1.3; SunOS 5.4 (Solaris 2.4); DEC OSF/1 V3.2 (Digital UNIX); OpenVMS V6.1 (VAX and Alpha).
X11/Motif versions are available for all platforms. CRT/terminal-mode versions exist for SunOS, Solaris, and OpenVMS VAX.
Additional information on StarView and the HST Archive is available through the STScI WWW pages.
The formal design of StarView began in 1992. A few staff members attended training courses in Object-Oriented Analysis and Design (OOA/OOD) methods. We studied Rumbaugh/GE OMT (Rumbaugh 1991), Booch (Booch 1991), and other methods. Then we shared our training experiences and began the process of analysis and design. This process was very long and iterative, and often frustrating. In the end, we settled on a design which is still fairly unchanged.
One of the fundamental concepts used in StarView is the Model-View-Controller (MVC) paradigm, which comes from the Smalltalk world. In an MVC application, models contain data, which are displayed in possibly many formats by the views, all coordinated by the controller.
For example, here are some of the StarView classes:
We used BuilderXcessory and DEC VUIT to prototype various user interface strategies and styles. These tools were used to determine how best to present archive and catalog information to the user. There was no attempt to use these tools, with their automatic code generation capabilities, to develop the actual interfaces or software.
Rational Rose was used to document the design. We constructed Booch diagrams showing classes and their relationships, as well as object diagrams of given scenarios. We did not go much farther than this, mainly because early versions of Rose were primitive. Rose has since evolved into a more full-featured tool with C++ code generation, reverse engineering, and other features. Our purpose was solely to capture the design pictorially.
C++ is the primary implementation language in StarView. The decision to use C++ was based on the desire to map easily from the object-oriented design, rather than trying to adapt the design to a traditional language such as C.
The primary problems with C++ early in the development were the poor quality of compilers (circa 1992) and a number of inconsistencies across compilers and operating systems for some features. To address these problems, until C++ became more widespread and standardized, we developed coding guidelines specifying only the basic language constructs. For example, we did not use templates, exception handling, run-time type identification (RTTI), etc. There is multiple inheritance in the design, but rarely in the code. This conservative approach has served us well in terms of portability.
Beyond compilers and debuggers, we used the CenterLine ObjectCenter C++/C development environment. ObjectCenter was very useful in the early phases of the project. Within this interpretive environment, C++ objects can be instantiated on the fly, making development and debugging very easy. As our system grew and became larger and more interdependent, ObjectCenter was less useful due to memory and speed problems.
In addition to ObjectCenter's run-time error checking, we used Purify to find memory access errors, stack corruptions, and memory leaks. Purify continues to be a useful tool in our ongoing maintenance. We also used a corollary product called PureCoverage, which is a code coverage analyzer. It summarizes which code paths have been exercised while running test suites.
The most critical aspect of managing the development process is the recognition of the highly iterative process when object-oriented techniques are used. It is sometimes referred to as the ``Whirlpool Approach''. The initial analysis/design phase can go around and around with no apparent end in sight. Keeping this phase on track and knowing when the design has solidified enough to move beyond prototyping to serious implementation are very important.
When the implementation is under way, management must track partially completed classes in light of overall functionality of the evolving system. Except for foundation classes with few dependencies, it is not always easy to hand out task assignments where each engineer implements a complete class and then turns it over for testing and general use. More frequently, half-finished classes are integrated with other classes and the cycle repeats.
Some metrics were used to track the StarView implementation. These included counts of the classes and methods (predicted versus actual) and a measure of system functionality called earned value. These were somewhat useful for reporting to higher-level management of our progress, but did not greatly affect the day to day development.
As of December 1995, StarView contains more than 150 classes. It incorporates more than 10 third-party software packages, such as Sybase, Vermont Views, the SIMBAD and NED client libraries, HCOMPRESS, etc.
The original design has remained remarkably stable. However, we continue to iterate---combining and breaking up classes, streamlining classes, reviewing the inheritance hierarchy, etc. Some enhancements are cutting across many classes, spawning interface changes. This indicates a need for reviewing the design to see if more serious structural changes are required. Nonetheless, many fixes and enhancements are localized to a few classes, which is the promise of an object-oriented approach.
We continue to use Purify, PureCoverage, and ObjectCenter in our maintenance. In addition, debuggers are getting better and have improved support for C++, such as the SPARCWorks debugger and FUSE/DECladebug.
The design process is long and very iterative when using an object-oriented approach. The lack of convergence in the beginning can be quite frustrating. However, the basic promise of OO---core classes encapsulate functionality to localize future changes---has largely been realized for StarView.
Good class and interface design is the key to success. When dealing with schedule pressures, there is always the temptation to make sloppy interface changes (e.g., access methods to internal class variables). Knowing when to implement such ``quick fixes'' versus taking the time to review and redesign (if possible) is vitally important.
Development environments such as ObjectCenter are very useful in the early implementation phase of a project. They have been less effective for us during the maintenance phase where tools such as Purify and good debuggers are paramount.
Our decision to use a C++ subset has served us well in terms of portability. Compilers have gotten better and more features are being standardized. We are now in a better position to take advantage of these new features.
We did not focus on code reuse in the beginning; this was a mistake. Some utility classes could be reused easily, but the major StarView classes would require much more work to adapt for other projects.
Long, K., et al. 1995, in Astronomical Data Analysis Software and Systems IV, ASP Conf. Ser., Vol. 77, eds. R. A. Shaw, H. E. Payne, & J. J. E. Hayes (San Francisco, ASP), p. 158
Pollizzi, J. 1994, in Astronomical Data Analysis Software and Systems III, ASP Conf. Ser., Vol. 61, eds. D. R. Crabtree, R. J. Hanisch, & J. Barnes (San Francisco, ASP), p. 88
Rumbaugh, J., et al. 1991, Object-Oriented Modeling and Design (Prentice Hall)
Williams, J. 1993, in Astronomical Data Analysis Software and Systems II, ASP Conf. Ser., Vol. 52, eds. R. J. Hanisch, R. J. V. Brissenden, & J. Barnes (San Francisco, ASP), p. 100