2.1 Black-Box Specifications Are Insufficient

  The term black box is a metaphor for a specific kind of abstraction. Black-box abstraction means, that none of the internal workings are visible, and that one can only observe output as reaction to some specific input (Fig. 1). Black-box testing, for instance, works this way. Test cases are selected without knowledge about the implementation. They are run, and the delivered results are checked for correctness.

  

Figure 1: Black-box component

For black-box specification of software components, pre- and postconditions are adequate. They describe the circumstances under which a component can be activated and the result of this activation.

Unfortunately, black-box specifications are insufficient for more interactive components. The result of an operation may depend not only on the input, but also on results of operations external to the specified component, which are called during execution (Fig. 2).

  

Figure 2: Black-box component, which makes an external call

The external operation, activated by the component, needs to be specified, too. This specification is not needed to see how the operation is to be applied, but to see how it needs to be implemented. It is a specification of duties, sometimes referred to as required interfaces [AOB97]. Often, such an external operation will depend on the state of the component calling it. As an example of this, in [Szy97] the Observer Pattern from [JV95] is analyzed. To perform its task, the observer needs to request state information from the observed object. If the observed object is a text and the observer a text view component, the observer needs to know whether it sees the old or the new version of the text. In other words, one needs to know, whether the observer is called before or after the data is changed. Specifying the text manipulation operations, such as delete, as black boxes does not reveal when the observer is called and what the state of the caller is at that time (Fig. 3). In this simple example, the intermediate state of the black-box at the time of the call could be described verbally, but in more involved cases this approach usually fails.

  

Figure 3: Black-box specification of observer pattern

One may think, that the above problems occur only, if intermediate state of a black-box operation can be observed, but this not true. If an operation involves more than one external call, the order of these may be important when implementing the called components. Consider the copying of a view with a separate model in the model-view-controller pattern: Has the model already been copied when the view is asked to copy its own state?

Sometimes, programmers will try to retrieve information in addition to the specification by experimenting with the component [PS94]. Of course, such behavioral assumptions might not actually hold and depending on them ruins the possibility of later substitution. However, black-box descriptions often force this additional information gathering to be able to use a component.