1 Introduction & Background

It is an old hope to be able to compose large software systems from prefabricated components, the same way as in other engineering disciplines products are assembled from third-party components. The expected advantages are well-known. Among them are a high degree of reuse to cut down production costs, high flexibility by choosing from different implementations, better adaptability by replacing individual components, reduction of the overall complexity of a system by breaking it down into smaller parts, and many more.

From the analogy to other engineering disciplines we can learn about a very important property components need to have: they need to provide abstractions, or specifications. Deployers of a component want to know what it can do for them and how to use it, but not how it is constructed internally. For instance, computer manufacturers use integrated circuits and compose them according to data sheets, but they do not want to be bothered by all the physics one has to understand to design the integrated circuit itself.

Similar abstraction is needed for software components. If component composition is supposed to be substantially easier than building systems from scratch, components have to be easier to deploy than they are to construct or to understand in full. Further, it has to be abstracted from certain implementation details, to make components replaceable. When one constructs an ActiveX control, one wants it to work in any container. Thus, it must be specified, how to interact with any container, independently of which implementation is used in the end.

On the other hand, abstraction must not go too far. As said in [Weg97], it is insufficient to state a component's input-output behavior. One needs to specify what longer, complex, interactions yield. Wegner speaks about marriage contracts opposed to business contracts.

We have ourselves experienced such problems with insufficiently specified components. A particularly precisely documented component environment, which we and our students use, is the Oberon/F framework [Obe95]. Though Oberon/F component interfaces are well documented with pre- and postconditions, important things are left unclear. As we will see, this is not a matter of poor specification, but a principal limit of the black-box component approach. The problems we experienced become even bigger with only informally specified environments, such as JavaBeans [Sun97] or Microsoft's OLE [Mic97]. When we created reusable or extensible components ourselves (for example in [Wec96]), we also recognized how difficult it is, to describe the essentials of our implementation in terms of relations between input and output only.

Our experience with formal methods, in particular with Ralph Back's refinement calculus [BvW97,BvW90], provided us with some insights, how such specifications could be provided in a form that is easier to write, better understandable, and more complete. The main idea is to provide an operational description of services, rather than a purely descriptional one. This allows us to reveal part of the implementation, one could say in a coarse form. Such specifications can be very detailed where needed, but they can be abstract enough where overspecification is to be avoided. This partial disclosure of implementation forms a middle ground between black-box components, of which only pre- and postconditions are accessible, and white-box components, showing all details. We therefore propose the term grey-box components .

Section 2 explains why we need a middle ground between black-box and white-box components. In Sect. 3 we argue that specification languages should be close to implementation languages in order to widen their acceptance. Given the requirements for component specification, we make a brief survey of different specification approaches in Sect. 4 and state why in our opinion abstract statements are the most promising foundation. Section 5 points to related work, Sect. 6 details our future plans, and Sect. 7 sums up and provides the conclusions.