An interface is a description of services offered by a system to
external clients. Interfaces have been in use for a long time,
starting with C standard header files that describe the services
(system functions) provided by the C standard library. As
object-oriented systems are becoming popular, interface design
has become an integral part of system design since every object
has an interface.
An interface defines a type, and objects of this type can be created
and used just like objects of other types.
In this sense, interfaces
have the same status as types,
especially classes
in systems such as JAVA and C++ [4,15].
This view of interfaces allows hiding
implementations of objects from their use, providing restricted
hooks to clients for their use. For example, abstract classes of
C++ can be considered as interfaces. Even though
interfaces have been closely tied to their respective
implementation languages, in recent years, interface languages
have been developed [3,6] independent of programming
languages, to facilitate language interoperability.
The basic structure of an interface has remained largely unchanged: an interface is simply a set of function (method or message) declarations or signatures. A signature specification consists of specifying the argument types, return types and exception types for each message. (In more modern languages such as ISL [6], additional attributes for messages like asynchronous can also be specified to indicate that clients need not wait for those messages to finish and return.) A signature specification thus gives the typing rules for the messages with very little semantic information. Because of this, interfaces are used mainly to facilitate compiler type-checking in implementation languages.
A main advantage of interfaces is that they can facilitate language interoperability. For this purpose, it is inadequate for interfaces to merely support message declarations, which specifies types of arguments and results. Clients and servers also need to understand the behavior of the underlying system (or object) being interfaced. At the same time, it is desirable that interfaces not expose state information to the clients. Because of these restrictions, it becomes difficult for clients to infer anything about the behaviors of interfaces.
This paper proposes a methodology and a language IBDL, Interface Behavior Description Language for extending interface signatures to include semantic information using the message passing framework. Client programs send messages to objects via their interfaces and expect results back. Any message of the interface can be sent at any time if a handle to the object is available. But sending a message sometimes may not be appropriate because of the messages previously received by the server (in the case of multiple client/single server). For this purpose, we identify two distinct types of behavior of a message - normal and abnormal. Abnormal behavior is further distinguished using exceptions.
One way for clients to know the behavior of the underlying object is to understand the interactions between various messages. In the proposed methodology, this interaction is specified in terms of normal termination of subsequent invocations of messages by enumerating messages enabled and/or disabled by a given message invocation. The next step in associating the semantic information is also to restrict return values from a client by specifying the relationship between the return values, and input parameters as well as with input of the previous relevant messages. Special primitives on sequences of messages are supported in IBDL to extract information about earlier messages relevant to the behavior of the message under consideration. Information about the state of the object is thus accessed through these constructs in a disciplined and restricted manner.
A main advantage of the proposed methodology is that semantic information can be included in an incremental fashion based on need and resources available for developing behavior specification.
As evidenced by examples described in the next section, it is often easier to specify the interactions among messages in terms of enables/disables than to develop complete specifications including interpretations. We believe this flexibility will encourage practitioners to write specifications along with signatures as they design interfaces. We have deliberately kept the language simple (and perhaps less expressive) to facilitate this. In particular, our methodology is very well-suited for shallow objects like GUI components. We are aware of its limitations, particularly that the simplicity of the language makes difficult and awkward to specify arbitrary collection type of objects like stacks and queues.
One of the important benefits writing IBDL specifications is that
implementations can be tested against these,
especially using sequence-testing.
In IBDL one explicitly specifies how the completion of a
message affects the behavior of the subsequent messages.
In a sequence test,
messages can be sent one after the other and checks can be made
to ensure that the behavior of the implementation satisfies the
specification after the completion of every message in the sequence.
This provides a sound basis for validating sequence tests, unlike
the traditional way of manually inspecting test results for determining
success or failure of a test.
In fact, we came up with the proposed methodology while working on
extending ADL/C++[17] for specifications for
sequence-testing; ADL/C++ is a
a specification language developed at Sun Microsystems Laboratories
for unit-testing of C++ programs.
Another benefit of this methodology is that specifications can be developed in cases where clients do not have access to state information, especially in a multi-client environment. For example, a check clearing house usually does not have access to the balance in a bank account. In these cases the main concern for the clients is to understand the result of sending a message to the server, and have an idea about what messages can be sent next that will exhibit their expected behavior.
The paper is organized as follows. Section 2 informally introduces the methodology and the language by three examples of increasing complexity. Section 3 is a detailed discussion of the methodology and IBDL with intuitive semantics. In section 4, we describe the scheme for validating sequence tests. In section 5, we discuss some related work. Section 6 concludes with a brief discussion of ideas for future work.