Much has been said about the desireability of Object Oriented program structures that incorporate reuseable program modules. There is also a good deal of evidence that this practice can cause problems. A tried and true stable program module can unexpectedly become a "monster" when it is incorporated in a different program. One of the best known disasters that resulted from a mismatched program module has to be the Arianne rocket disaster that occured some years ago. A program module that had been used successfully in an earlier version of the rocket was incorporated into the program of a new rocket. During launch, the module received a numerical value that it was not equipped to handle. The resulting variable overflow caused the rocket's on board computer to fail. The rocket went out of control and subsequently crashed.

The problem here is that when a program module is transferred to a different program, it is likely that combinations of variables may be passed to it that it never had to deal with in the older program. So a program module that supposedly has been thoroughly tested, receives combinations of inputs that it has never been tested for. So it should not be surprising that sooner or later a certain value or combination of values passed to the the module could cause an error.

Some Things that Can Go Wrong with a Reused Program Module

1. Overflow of a variable, as described above, is one possibility.
   
   
2. The output of a program module, like that of a math function, can be discontinuous, i.e. with certain combinations of input it may generate an imaginary or infinite, or otherwise unuseable number.
   
   
3. The program module may work properly, but still return a value that the calling program can not handle properly.
4. The program module could even have a "Trojan Horse" that under certain circumstances could do mischief.

Suggested Solutions

1. A program module should have associated documentation that declares the range of values over which it was tested, and the range of values that were passed to it by previous programs in which it did function properly. The program that calls it should be similarly documented.
   
   
2. If the code for the module is available, it should be analyzed so that the program engineer will know exactly what the module does. He can then anticipate what conditions could lead to a fault.
   
   
3. The program module should contain code that will test the variables that are passed to it. If the combination of values is not within the range in which the module normally operates, some kind of a fault should be generated, and information about it written to an error file for later analysis.
   
   
4. The program that calls the module should be able to test the output, and generate a fault if it is out of the expected range.