next up previous
Next: Modularity Up: Object-Oriented Experiences with GBT Previous: Introduction

Long Analysis Phase

The most evident feature of the object-oriented approach has been the long analysis phase. In a rigorous design this is as it should be, but it demands that the external requirements for the software be defined early. This has been a weakness in the GBT project, so the designers have been forced to proceed with rough requirements and modify and add to them as the project has progressed. The advantage of early requirements is a more coherent design, and considerable effort has been expended trying to reap this benefit.

Comprehensive requirements are very hard for future users to write. Formal requirements demand a certain amount of abstraction that is quite different from how software is used. It seems fair to say that object-oriented design adds another layer of abstraction and, hence, another language barrier to the communication between user and designer. One of the roles that I have played in this project is translator between the user and software domains. Still, most of the effort of ferreting out requirements has fallen on the designers.

A common method for converging on users' requirements is by building prototypes that the user can comment on and then iterate a number of times until the prototypes are acceptable. On the GBT project this hasn't been very effective because most of the design has remained in software abstractions. It is not clear to me whether this is an inherent practical drawback of the object-oriented approach or whether it is just a weakness in our implementation. It is likely a bit of both. The tension between getting something working and doing a careful design has existed throughout the project. In retrospect, the project might have been divided into smaller units with tangible products at early and mid stages of the project.

Another aspect of the GBT project that has worked against an early design phase is that the software and hardware were built concurrently. In principle, the designs could evolve together, but the difference in design languages was again a barrier. The parts of the GBT that were experimental for most of the construction were quite difficult to fold into the software design. To a certain extent, one could only hope that the design that fit the known part of the hardware would apply without too much modification to the experimental parts when they became production items.

None of this is to say that we would not use an object-oriented design again. Many of the benefits that come with this approach were, in fact, realized.


next up previous
Next: Modularity Up: Object-Oriented Experiences with GBT Previous: Introduction

Mark H. Clark
Thu Mar 26 09:49:56 EST 1998