Applying 'Design by Contract'.

Meyer, B. (1992). Applying 'Design by Contract'. Computer, 25(10), 40-51.

Type

Journal article

Intellectual base

Primary research

Year

1992

Volume

25

Issue

10

Pages

40-51

DOI

10.1109/2.161279

DOI registrant

Institute of Electrical and Electronics Engineers

Link

https://doi.org/10.1109/2.161279

Cited from

computer_science, engineering_design, law_governance, mathematics, military_strategic_studies, philosophy

Cited by

10 citations across 10 artifacts.

Each citation links to the sentence it supports in the citing article.

Primes

• Axiom
  • Software and systems — published contracts, type laws, and maintained invariants that callers are entitled to assume, with violations counting as bugs in the same sense that contradiction is a bug in a logical system.

    Supported in partVerified against the work's full text

    Meyer supports published contracts and class invariants that clients can rely on, and ties reliability to absence of bugs; the analogy to logical contradiction and 'type laws' are not in the text.

    “clients may view the precondition of a routine not just as an obligation but also in part as a benefit, since the con- tract implicitly indicates that a call satisfying the precondition will be serviced correctly”

    Read by an automated reader; not a human review. How support was checked

• Commitment
  • The design-by-contract movement transferred contract-law structure — preconditions, postconditions, invariants, recourse on breach — into programming-language semantics.

    This sourceImports contract-law structure — preconditions, postconditions, invariants, and recourse on breach — into programming-language semantics.

    Supported in partVerified against the work's full text

    Meyer sets out design by contract in Eiffel with preconditions, postconditions, class invariants and exception handling, but does not say these were imported from contract law.

    “clients may view the precondition of a routine not just as an obligation but also in part as a benefit”

    Read by an automated reader; not a human review. How support was checked

• Contract
  • Software interfaces. API contracts, design-by-contract programming, and protocol specifications name the obligations of caller and callee, the legal request shapes, and the failure modes, with the runtime or compiler as the enforcement regime.

    This sourceIntroduces design by contract: preconditions, postconditions, and invariants as caller/callee obligations enforced by the runtime.

    Supported in partVerified against the work's full text

    Meyer supports design by contract as caller and callee obligations monitored at runtime; API contracts, protocol specifications and compiler enforcement are not covered.

    “clients may view the precondition of a routine not just as an obligation but also in part as a benefit, since the con- tract implicitly indicates that a call satisfying the precondition will be serviced”

    Read by an automated reader; not a human review. How support was checked

• Interface
  • It separates two systems (implemented vs. consumer; transmitter vs. receiver; interior vs. exterior) and names the protocol governing interaction, the contractual logic Meyer (1992) articulated as "design by contract."

    This sourceArticulates the interface as a formal contract with preconditions, postconditions, and invariants; establishes contractual obligation as the central mechanism governing inter-module interaction.

    Supported in partVerified against the work's full text

    Meyer's article does articulate design by contract with client obligations and benefits, but the extracted text is fragmentary and does not discuss interfaces between two systems.

    “clients may view the precondition of a routine not just as an obligation but also in part as a benefit, since the con- tract implicitly indicates that a call satisfying the precondition will be serviced correctly.”

    Read by an automated reader; not a human review. How support was checked

• Out Of Distribution Detection
  • Software: precondition checks and design-by-contract systems that throw on out-of-contract inputs rather than producing undefined behaviour.

    This sourceIntroduces preconditions/postconditions/invariants as enforceable contracts; routines reject inputs that violate their precondition (out-of-contract), the software analogue of refusing out-of-scope inputs.

    Supported in partVerified against the work's full text

    Meyer's article presents preconditions as part of enforceable contracts and says an assertion violation raises (an exception); it does not discuss undefined behaviour.

    “effect of an assertion violation is to raise”

    Read by an automated reader; not a human review. How support was checked

• Preparatory Field Conditioning
  • … state is written down as a value, a tolerance and a time at which it must hold, the two halves of the work can decouple: whoever conditions the field owns the obligation to move the state into range and hold it there until the appointed hour, and whoever performs the focal act owns succeeding against a field in range.

Mechanisms

• Contract Check
  • This is the discipline of Design by Contract, making each boundary's obligations explicit and enforceable.

    This sourceDefines Design by Contract through explicit preconditions, postconditions, and invariants that allocate enforceable obligations at software boundaries.

• Design-by-Contract Clause
  • Its distinctive move is the allocation of responsibility: a precondition makes the caller at fault if it is violated; a postcondition makes the component at fault if it is.

    This sourceAllocates contract responsibility by requiring the client to satisfy a routine's precondition and the supplier component to satisfy its postcondition.

• Invariant Checking
  • It is the software-contract discipline of Design by Contract made routine.

    This sourcePresents Design by Contract as a software discipline based on explicit contractual assertions and invariants.

• Postcondition Assertion
  • What the caller does next — retry, fall back, show an error — is governed by the service's contract; the assertion's job is to catch the bad output at the exact point it was produced.

    This sourceUses a postcondition assertion to check the supplier's promised output when the routine returns.

Verification

Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.

Does it back the claim? Read against the text for 5 of 10 citations: 5 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.

Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.

See how references were verified.

Registry ID ref:3ba4939fe574 · see in the full table