next up previous
Next: Formal methods for components Up: Introduction Previous: Interface compatibility

Behavioral compatibility

The goal of work in behavioral compatibility for components is to develop support in CBP for behavioral introspection and behavioral adaptability that can be scaled up for constructing large complex component systems. While there is progress in addressing behavioral introspection and adaptability [22,20,23,19,18] there is no progress in dealing with the state explosion problem. The main focus of this work is in addressing the latter in a manner that can be applied to event-based components.

Currently, the introspector reveals only the interface, and adapters are used in an ad-hoc manner relying on names and types only. There are emerging proposals for handling richer interface mechanisms that express contractible constraints on the interface, e.g., the order in which the functions should be called, or the result of a sequence of calls. These methods typically rely on defining finite-state ``behavioral'' automata that express state changes. When two components are connected, the two automata can be tested for compatibility by producing their automata-theoretic product. This fails to provide a practical foundation for software growth, because of sate explosion; computation of the product of behavioral automata, each with states, generates a product automaton of size . We address the challenge of avoiding state explosion. Elsewhere [3,4] we present a pairwise design of an elevator system which, when scaled up to floors, requires an upper bound of only states, instead of the that an approach which computes the product of all components would require. This is well within the reach of current model checkers.


next up previous
Next: Formal methods for components Up: Introduction Previous: Interface compatibility
David H. Lorenz 2003-06-30