Modeling and verification of component compatibility (D.C. Craig and W.M. Zuberek)

Component-based software engineering (CBSE) has been emerging as a promising approach to the development of large-scale software architectures in which repositories of software components with well-defined interfaces are used to quickly assemble large software systems. The compatibility of components used for such an assembly is of paramount importance for the success of CBSE.

Classical techniques of determining compatibility have focused on compile-time checks such as consistency between the number and types of arguments and an appropriate type of results of invoked operations. While such static consistency checks are obviously important, they are insufficient in establishing the dynamic or behavioral compatibility between two software components. For example, it is possible for a server component to provide operations that exactly match the requirements of the client component, however, if the server component imposes a strict ordering of these operations and the client component does not adhere to this ordering, the two components can still exhibit conflicting behaviors. Such conflicts result in component incompatibility.

The objective of this research is to develop foundations for a formal model of component interactions by representing component interfaces using Petri nets. It can be shown that interface compatibility corresponds to deadlock-free composition of net models of interacting components.

For example, Fig.1 shows Petri net models of a simple database client (requester) and a database server (provider).


Fig.1. Net models of database requester and provider interfaces.

The first operation of requester is labeled by "a" and it could represent a service that "opens" the database and prepares it for queries. The interface than requests a sequence of operations in which each operation "b" is followed by a corresponding operation "c" (these could represent "read" and "write" operations to the database, respectively. Finally, the requester invokes service "d" which could represent the "closing" of the database.

The provider interface (representing the database server) imposes the restriction that the "a" service must be invoked first, followed by any sequence of "b" and "c" services, followed finally by the "d" service.

The composition of interfaces is shown in Fig.2. The composition is deadlock-free, so the interfaces shown in Fig.1 are compatible.


Fig.2. Composition of database requester and provider interfaces.

It can be observed that swapping the roles of "requester" and "provider" in Fig.1 results in incompatible interfaces; the composition shown in Fig.3 contains several deadlocks, the marking in Fig.3 indicates one of them.


Fig.3. Composition of requester and provider interfaces resulting in deadlock.

Efficient methods of deadlock detection are also in the scope of this research.


Up to Project Page

Copyright by W.M. Zuberek, All rights reserved.
Revised: 2005.02.12 :

Notice: Use of undefined constant COUNTNAME - assumed 'COUNTNAME' in /users/cs/faculty/wlodek/.www/research/proj-comp-based-a.php on line 89

Notice: Use of undefined constant COUNTER - assumed 'COUNTER' in /users/cs/faculty/wlodek/.www/research/counter.php on line 21
1099