Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

Introduction: The Failure of the Green Bank Meeting

In February 1992 a workshop was held in Green Bank that had the objective of analysing the requirements for processing radio astronomical data in AIPS, including calibration and imaging. The final report of this workshop is an attempt at an object-oriented analysis of this problem domain along the lines suggested by Coad and Yourdon in [1]. As such it is a dismal failure.

Requirements analysis has several goals (see, for example, [2]).

• It enables the system engineer to specify software function and performance, to indicate the software's interface with other systems elements and to establish design constraints.

• It enables the software engineer to build models of the process, data and behavioural domains that will be treated by the software.

• It provides the software designer with a representation of the information and functions dealt with by the system that can be translated into a design.

The Green Bank report does none of the above. The functions provided by the system are left vague as is the nature of the data that the system can deal with.

Although the authors admit that the analysis is incomplete in many areas¹ they claim suggest that it could be used as a framework for further analysis and design. Examination of their model shows that it is not adequate even for this purpose.

Despite the fact that the operations that can be carried out on data are strongly conditioned by the form of that data the authors of the Green Bank model have gratuitously separated operations from data. This has led to an overly complex model. Consider the steps that must be taken to obtain the calibrated value of an interferometer measurement. We need to make three requests to three different objects.

1.

Send a request to the Measurement² to obtain the Telescope object associated with it.

2.

Send a request to the Telescope object to find the current TelescopeModel.

3.

Send a request to the current TelescopeModel, with the original Measurement as a parameter, to return the calibrated value.

Most experienced object-oriented programmers would have provided the class that represents interferometer measurements with a service that returns a calibrated value. In this case we only need to send one request to a single object. The interferometer measurement will need to request services from other objects in order to provide the calibrated value but this complexity is hidden from us³. Furthermore, this model ensures that the service which is used to calibrate interferometer data is always appropriate to that kind of data (since the service is associated with that class); the Green Bank model appears to provide no mechanisms to prevent attempts to calibrate interferometer data using a telescope model designed for single-dish, total-power measurements.

It is also worth examining the methods by which calibration models are updated in the Green Bank model: this is an outstanding example of confused thinking. The SolveForModel service of TelescopeModel must operate on a collection of measurements but TelescopeModel objects are associated with single measurements and not with collections of measurements: how then do we determine which TelescopeModel should update the calibration model for a given set of data? Perhaps the measurements supplied to SolveForModel should all be associated with the same Telescope. In this case the model needs to ensure that this is the case: the Green Bank model appears to contain no mechanisms to ensure this.

The Green Bank report is so muddled that it serves no useful purpose. It should be discarded in favour of a fresh start.