Of course, the process is more complicated than that, but it isn't clear that those complications don't arise from the very way we design OI's. For instance, the examples in the paper are all large, complex systems. But how were the base systems designed in the first place? Were the subpieces of the base systems not open to begin with? Perhaps the current problem that OI solves is in reality a symptom of the real problem. For example, the real problem may be that Software Engineering does not have a model that lets us accurately and precisely predict the effects of combining more primitive programs whose properties are understood.
For contrast, let us look at the following alternative approach (which I'm sure has been discussed many times):
Software Engineering should be more like Civil, Electrical, or Chemical Engineering; there should exist catalogs that contain multitudes of diverse and easily understood components. To build a system, one combines sets of components into larger components to build subsystems, and then combines the subsystems into larger systems until the finished product is produced. Such an implementation then already has a built-in hierarchical decomposition derived from the design itself. This decomposition could be exposed as a separate interface so that parts of the design can be replaced as desired.
This alternative model is appealing, and allows us to build up from pieces we understand, as opposed to building down from large complex systems we may not completely understand. If we know the properties of the subpieces, and we can predict the properties resulting from the combination of those pieces, then by induction we can understand the properties of any large and complex system we build.
However, both the current OI techniques and this alternative approach still suffer from something we don't have; a good model for predicting the properties of the combination of primitive components. One can argue that the only way we currently know how to combine components is via functionality. This is what traditional BBA, structured programming, and language theory give us, for example. What we then need to learn is how to combine components with several different properties so that we are able to predict the properties of the resulting combination. Some of these properties include: functionality, time and space behavior, degree of reliability, amount of available parallelism, real-time behavior, and shared resource requirements. For some applications these properties will matter, and for some they won't.
This combining problem is not new; compiler writers would like to be able to predict the effects of combining different compilation stages in different orders, in networking, one would like to predict the effects of combining different types of protocols on different combinations of communication lines, and in operating systems, one would like to predict the effects of combining different types of policies for managing different combinations of shared resources.
It seems that many current approaches in OI are more directed towards the problem of allowing us to easily adjust implementations, and less directed towards understanding how to design systems so that the effects of adjustments can be easily understood and predicted. Each direction deserves a good share of attention in order to provide us with a solid framework to engineer with.
Back to Alphabetical List of Responses
(Last Revised October 1994)