Programming by contract
James C. McKim
Abstract
James C. McKim
Abstract
"Why can't software be more like hardware?" has been the software engineer's lament for nearly as long as there have been large software systems. In particular, why isn't there a software components industry to rival the existing hardware components industry? Hardware components come with the following attributes: an interface that hides detail that would only confuse or at least distract me; an unambiguous interface specification written in a language I can understand (in the case of the integrated circuit, this may be a fairly complex language, but it's one I expect to learn if I'm going to work with that hardware); a guarantee-the component has been tested and/or validated against its specification. All three items-especially the last one-are notably lacking for software components. Indeed, software tends to come with an antiguarantee, otherwise known as a disclaimer. All of the above points rely on a rigorous specification of the hardware component's interface. In a nutshell, programming by contract is about providing just such specifications for software components (that is, classes), and it provides the best hope of a basis for a true software component industry. The discussion focuses on object oriented software.
OpenAlex reports 14 citations for this work. Citation counts describe recorded attention and do not establish research quality.
A contribution statement is not available in the OpenAlex record.
Method details are not available in the OpenAlex metadata.
Findings are not separately available in the OpenAlex metadata.
Limitations are not available in the OpenAlex metadata.
Application details are not available in the OpenAlex metadata.
"Why can't software be more like hardware?" has been the software engineer's lament for nearly as long as there have been large software systems. In particular, why isn't there a software components industry to rival the existing hardware components industry? Hardware components come with the following attributes: an interface that hides detail that would only confuse or at least distract me; an unambiguous interface specification written in a language I can understand (in the case of the integrated circuit, this may be a fairly complex language, but it's one I expect to learn if I'm going to work with that hardware); a guarantee-the component has been tested and/or validated against its specification. All three items-especially the last one-are notably lacking for software components. Indeed, software tends to come with an antiguarantee, otherwise known as a disclaimer. All of the above points rely on a rigorous specification of the hardware component's interface. In a nutshell, programming by contract is about providing just such specifications for software components (that is, classes), and it provides the best hope of a basis for a true software component industry. The discussion focuses on object oriented software.
Key concepts: Computer science, Component-based software engineering, Software engineering, Programming language, Interface (matter), Disclaimer, Software, Software construction