next up previous
Next: What insights might help Up: 2 Position Previous: What is the problem?

What is the significance for component-based software engineering?

Formal specification, even without the ability to analyze conformance of system behavior, offers a mechanism for succinct and precise descriptions of assumptions about the behavior of framework parameters as well as the capabilities provided by the framework. That those specifications might also be leveraged for testing, e.g., to derive test data or generate test drivers and stubs, or might be used as the goal of automated analyses is a bonus.

Traditional approaches to unit and sub-system level validation rely on testing. This is problematic for parameterized software frameworks since a framework intentionally makes minimal assumptions about parameter behavior and usage context. Thus, the problem of generating stubs and drivers that effectively excercise framework functionality can be a difficult one. Formal specification and automated analysis of frameworks provides an alternative validation technique that operates without difficulty in the presence of weak specifications and can, in fact, provide higher levels of confidence in framework correctness.

Component-based systems are defined in a modular fashion with explicit and well-defined boundaries. Scalable verification techniques must be designed to operate in two modes: they must allow verification within module boundaries and they must allow verification of module consumers without without requiring details hidden behind module boundaries.

Software frameworks are built to enable reuse. Typically, one thinks of the reuse of design or code information encoded in the framework. Another powerful type of reuse is possible, however, if formal specifications are bundled with framework components. We can leverage the efforts spent in validating framework specifications to applications built with those specifications. For example, we might verify that a framework is free of deadlocks if all of its parameters satisfy assumption A. We then need only analyze the parameters defined by an application to determine if they satisfy A, in which case, the instantiation of the framework is known to be deadlock free.

In this way, component-based systems can be validated early in the life-cycle, the specifications used in and results of those efforts can be bundled with components providing useful documentation and the opportunity to export knowledge about framework correctness to framework consumers.


next up previous
Next: What insights might help Up: 2 Position Previous: What is the problem?

Matthew B. Dwyer
Sept. 2, 1997