Contract-checking wrappers for C++ classes

Two kinds of interface contract violations can occur in component-based software: A client component can fail to satisfy a requirement of a component it is using, or a component implementation can fail to fulfill its obligations to the client. The traditional approach to detecting and reporting such...

Full description

Saved in:
Bibliographic Details
Published in:IEEE transactions on software engineering 2004-11, Vol.30 (11), p.794-810
Main Authors: Edwards, S.H., Sitaraman, M., Weide, B.W., Hollingsworth, E.
Format: Article
Language:English
Subjects:
Assembly systems
binary components
Binary system
C plus plus
class invariants
coding techniques
Computer programming
Computer science
Computer Society
Contracts
Debugging
debugging aids
design by contract
Design engineering
Index Terms- Assertion checkers
Interfaces
Investments
Modular construction
postconditions
preconditions
Runtime
Software engineering
Software systems
specification
Studies
Testing
Violations
Citations: Items that this one cites
Items that cite this one
Online Access:Get full text
Tags: Add Tag
No Tags, Be the first to tag this record!
Description
Summary:Two kinds of interface contract violations can occur in component-based software: A client component can fail to satisfy a requirement of a component it is using, or a component implementation can fail to fulfill its obligations to the client. The traditional approach to detecting and reporting such violations is to embed assertion checks into component source code, with compile-time control over whether they are enabled. This works well for the original component developers, but it fails to meet the needs of component clients who do not have access to source code for such components. A wrapper-based approach, in which contract checking is not hard-coded into the underlying component but is "layered" on top of it, offers several relative advantages. It is practical and effective for C++ classes. Checking code can be distributed in binary form along with the underlying component, it can be installed or removed without requiring recompilation of either the underlying component or the client code, it can be selectively enabled or disabled by the component client on a per-component basis, and it does not require the client to have access to any special tools (which might have been used by the component developer) to support wrapper installation and control. Experimental evidence indicates that wrappers in C++ impose-modest additional overhead compared to inlining assertion checks.
ISSN:0098-5589
1939-3520
DOI:10.1109/TSE.2004.80