On Component Interface, Specification, and Contract

Component Interface is a collection of operations that are used to specify services of a component. It is an abstraction of the behavior of a component that consists of a subset of the interactions of that component together with a set of constraints describing when they may occur. The interface describes the behavior of a component that is obtained by considering only the interactions of that interface and by hiding all other interactions. The description of a component interface consists of a signature part, describing the services provided by a component, and a behavior part, describing the component’s external behavior. Each operation has zero or more input and output parameters and a syntactic specification associates a type with each of the parameters including a return type.

The specification of a component is different and composed of many parts. Defining which interfaces the component will offer is just part of the whole component specification. Components can implement (export) one or more interfaces, called provided interfaces, and they can also use (import) interfaces, called required interfaces, from other components. The component interface is used both to implement the services and to describe the services so that to allow clients to find suitable services and to understand their purpose, functionality, usage and restrictions. In short, the interface defines every thing the client needs to know. An interface does not specify how implementations of this interface must interact with other components to fulfill their responsibilities; that is defined in the component specification.

While an interface defines a set of behavior, a component specification defines an implementation and deployment boundary. By specifying a set of interfaces that must be supported, a component specification defines the total sum of capabilities of any component created at run time from the implementation. This component specification can also define how the implementation must interact with other components. Knowledge of such interactions does not form part of the interface specification and so cannot be known directly by the client. We define these interaction constraints somehow in the component specification. Behavior is defined as a set of interfaces and a component specification is realized as a component implementation. The basic goal of component specification is to create a set of models that collectively describe externally visible properties of the component and constraint that are applicable to the proper implementation of the component. This goal makes component specification the ultimate guide for use of the component by clients, and for proper implementation of the component by implementers. Clients will pick and choose components based on the component interface. Component implemented based on a specific component specification should exhibit the same behavior regardless of who implemented it, what language is used to implement it, and in what environment it is installed.

Since components can implement (export) one or more interfaces and they can also use (import) interfaces from other components, at a minimum, component specification should provide a contract that states both the services a component offers and the services that it requires in fulfilling its commitments. Contract is mainly composed of three aspects: pre-condition, post-condition and invariant. Pre-condition is a condition that a client must be sure is true; otherwise, it is not legal for the client to use the service. Post-condition is a condition that should become true when the service is executed. Invariant is an observable property that does not change throughout the component’s life-time. Precisely, an invariant property is a property that always has the same value whenever the property is inspected.


Related Blog: On Software Component

Currently Reading: Confessions of an Economic Hitman by Perkins John