As more and more attention is being focused on software reuse, new problems are emerging. While the majority of these difficulties are rooted in nontechnical issues, it is clear that there are more technical problems than previously anticipated. One of these technically oriented problems arises out of the constructive, or parts based, approach to software reuse1—combining software components as basic building blocks to form larger structures.
Specifically, in practice it can be very difficult to ``compose'' or interlock two apparently general software components. Of course, there are many factors affecting the composability of software components. This paper will concentrate on one of these factors: components are often based on different conceptual models of behavior.
There is no well understood groundwork of common models for component interaction, and the lack of guidelines for applying these models exacerbate the composability problem. This paper will describe how interface models affect composability and how techniques for describing a component's interface requirements affect composability. These problems will be illustrated in the context of common interface properties that are exhibited even in simple abstract data type (ADT) components.