Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

The Plan: A Fresh Start

Object-oriented analysis aims to produce a model of the problem domain in terms of classes of objects with the intent that these classes will form the basis for an object-oriented software design. This requires rigour and precision. Both of these qualities are notably lacking from the Green Bank document.

It is clear that we need a fresh analysis of the problem areas involving the handling of astronomical data that will provide a firm foundation for AIPS++. Without this fresh start we will find ourselves with a system that is overly complex. This may not show up in simple prototypes but will exact its price later. The longer the fresh start is delayed the worse matters will become: the more effort that is invested in building a system based on the flawed Green Bank model the harder it will be to throw that model away.

In order to avoid repeating the failure of the Green Bank meeting, I suggest that the following conditions be met.

• It is difficult to produce a rigorous model of a large ill-defined system. We should procede under the working assumption that AIPS++ will be a set of collaborating programs, as was the original AIPS. This is sensible since we require a system that is extensible and such a system is easily extended by adding new programs to it. Each program will carry out a well defined operation on a particular kind of data, either modifying that data or producing some result. Operations should be identified and analysed separately. Since the operations are well-defined it is obviously possible to carry out a full analysis. After a number of operations have been analysed in detail it will be possible to identify recurring class structures. These should be extracted and developed into application frameworks⁴ for AIPS++.

• The analysis team or teams should be small: no more than 3 people should be in any one group. Larger groups, such as that that produced the Green Bank report, are not conducive to rigorous analysis. Given the well-determined nature of many operations one-person teams and may be quite productive.

• Analysis teams should not work in isolation. There is a constant need to consult with working astronomers to clarify what they require. Problems in the analysis should be solved by research rather than guesswork.

• Analysis teams should exercise good taste in developing classes in the model that results from the analysis. Complexity should be hidden behind class walls wherever possible and not exposed to public view.

The first suggestion leads us into the ``fountain'' model of object-oriented software development. This has been demonstrated to work in several programming projects and will lead to early development of a working, if incomplete, system. It is also more likely to uncover flaws in our thinking at an early than the construction of prototypes since we are dealing with real data reduction problems from the outset rather than playing with simplified models.