Reusable software: the Base object-oriented component libraries
Reusable software: the Base object-oriented component libraries
Object-oriented software construction (2nd ed.)
Object-oriented software construction (2nd ed.)
Design by contract, by example
Design by contract, by example
Computer
The .NET Contract Wizard: Adding Design by Contract to Languages Other than Eiffel
TOOLS '01 Proceedings of the 39th International Conference and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS39)
Dynamically discovering likely program invariants
Dynamically discovering likely program invariants
Precondition inference from intermittent assertions and application to contracts on collections
VMCAI'11 Proceedings of the 12th international conference on Verification, model checking, and abstract interpretation
Inferring specifications for resources from natural language API documentation
Automated Software Engineering
Component contracts in eclipse - a case study
CBSE'10 Proceedings of the 13th international conference on Component-Based Software Engineering
Diagnosys: automatic generation of a debugging interface to the Linux kernel
Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering
What should developers be aware of? An empirical study on the directives of API documentation
Empirical Software Engineering
| Hi-index | 4.10 |
Software contracts take the form of routine preconditions, postconditions, and class invariants written into the program itself. The design by contract methodology uses such contracts for building each software element, an approach that is particularly appropriate for developing safety-critical software and reusable libraries. This methodology is a key design element of some existing libraries, especially the Eiffel software development environment, which incorporates contract mechanisms in the programming language itself. Because the authors see the contract metaphor as inherent to quality software development, they undertook the work reported here as a sanity check to determinewhether they see contracts everywhere simply because their development environment makes using them natural or whether contracts are intrinsically present, even when other designers don't express or even perceive them.