Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25436 — Software Engineering: Eiffel Analysis and Design
Design by Contract methodology for building trustworthy software systems
ISO/IEC 25436 defines the Eiffel method for software analysis and design — a disciplined, contract-driven approach to constructing object-oriented systems. Developed by Bertrand Meyer and formalized through decades of industrial application, the Eiffel method places Design by Contract (DbC) at its core: every software element explicitly specifies its obligations and benefits through preconditions, postconditions, and class invariants.
The Eiffel method treats contracts as executable documentation. Unlike comments, which can drift out of sync with code, contracts are enforced at runtime and at compile time, providing a single source of truth for component behavior.
The Design by Contract Framework
Design by Contract draws an analogy with commercial contracts: a routine (the supplier) guarantees a result provided the caller (the client) satisfies certain conditions. This framework is codified through three mechanisms:
| Contract Element | Role | Example | Violation Consequence |
|---|---|---|---|
| Precondition (require) | Obligation on the caller | “stack.count > 0” before pop | Caller is at fault — exception raised in caller |
| Postcondition (ensure) | Obligation on the routine | “Result = old stack.top” after pop | Routine is at fault — exception raised in routine |
| Class Invariant | Always-true condition for all instances | “stack.count >= 0” for all STACK objects | Class implementation is inconsistent |
ISO/IEC 25435 extends DbC beyond implementation into analysis and design phases. During analysis, contracts capture domain rules without committing to implementation details: “A withdrawal transaction must not exceed the current account balance.” During design, contracts are refined into software component interfaces: “The withdraw(amount) routine requires balance >= amount and ensures balance = old balance – amount.”
Teams using Design by Contract report that 60-80% of integration bugs are caught at the contract boundary during unit testing, dramatically reducing downstream debugging effort.
Class Clustering and the BON Notation
The Eiffel method introduces Business Object Notation (BON) for visually representing class clusters — groups of classes that collaborate to fulfill a system responsibility. Unlike UML’s relatively flat class diagrams, BON emphasizes cluster-level relationships: reused clusters, client-supplier dependencies, and inheritance hierarchies are rendered as first-class visual elements.
A BON cluster diagram organizes classes into rounded rectangles (clusters) connected by labeled edges representing client-supplier or inheritance relationships. Each cluster carries an explicit contract summary showing the combined preconditions and postconditions of its public routines. This enables architects to reason about system properties at the cluster level without descending into individual class details.
The standard recommends a maximum cluster size of 7-12 classes, following Miller’s Law for human information processing. Clusters exceeding this size should be decomposed into subclusters, each with its own contract summary. This hierarchical decomposition mirrors the composition rules of primitive control operations in ISO/IEC 25435, creating a consistent intellectual framework across analysis, design, and implementation.
A common mistake is to treat BON diagrams as mere documentation artifacts. In the Eiffel method, cluster diagrams are design specifications — they should be kept in sync with the codebase and used as input for automated verification tools, not drawn post-hoc for presentations.
Engineering Insights for Adoption
Adopting ISO/IEC 25436 in a development organization requires changes across three dimensions: tooling, process, and culture.
Tooling: The Eiffel method is supported by EiffelStudio, which provides integrated contract compilation, runtime assertion monitoring, and automatic documentation generation. For teams using other languages, DbC can be implemented through libraries (Contracts for Java, PyContracts for Python, Code Contracts for .NET) but without the same level of language integration.
Process: Contract writing should be integrated into the definition of done for every user story. A story is not complete until the preconditions, postconditions, and invariants of all affected routines are specified. This rule prevents the common pattern where contracts are deferred indefinitely under schedule pressure.
Culture: The Eiffel method requires a shift from defensive programming to contract-based programming. In defensive programming, every routine checks everything; in DbC, each side checks only its own obligations. This reduces code bloat by eliminating redundant checks and clarifies responsibility boundaries, but it requires organizational trust that suppliers will honor their contracts.
Do not apply DbC retrospectively to legacy code without automated contract verification. Adding preconditions to a system that was never designed with contracts can surface hundreds of latent violations. Plan a staged adoption: start with new modules, add contracts to the most critical existing modules under test harness protection, and only then expand to the rest of the codebase.
Frequently Asked Questions (FAQ)
Q1: How does the Eiffel method differ from UML-based analysis and design?
While UML focuses on graphical notation with multiple diagram types, the Eiffel method centers on executable contracts as the primary specification vehicle. UML can be used alongside Eiffel, but the Eiffel method considers contracts — not diagrams — to be the definitive representation of system behavior.
While UML focuses on graphical notation with multiple diagram types, the Eiffel method centers on executable contracts as the primary specification vehicle. UML can be used alongside Eiffel, but the Eiffel method considers contracts — not diagrams — to be the definitive representation of system behavior.
Q2: Is the Eiffel method tied to the Eiffel programming language?
No. ISO/IEC 25436 defines the method independently of any specific language. While EiffelStudio provides the most comprehensive tool support, DbC principles can be implemented in Java, C#, Python, C++, and many other languages through libraries and coding conventions.
No. ISO/IEC 25436 defines the method independently of any specific language. While EiffelStudio provides the most comprehensive tool support, DbC principles can be implemented in Java, C#, Python, C++, and many other languages through libraries and coding conventions.
Q3: What is the learning curve for adopting Design by Contract?
Most developers grasp the basic concept of preconditions and postconditions in a few hours. Writing good invariants and designing cluster-level contracts takes 2-4 weeks of guided practice. Full organizational adoption, including culture shift from defensive to contract-based programming, typically requires 3-6 months.
Most developers grasp the basic concept of preconditions and postconditions in a few hours. Writing good invariants and designing cluster-level contracts takes 2-4 weeks of guided practice. Full organizational adoption, including culture shift from defensive to contract-based programming, typically requires 3-6 months.
Q4: Can DbC replace unit testing?
No. Contracts and unit tests serve complementary roles. Contracts verify component-level semantics continuously (at compile time and runtime), while unit tests validate end-to-end scenarios and edge cases. Both are necessary for a comprehensive quality assurance strategy.
No. Contracts and unit tests serve complementary roles. Contracts verify component-level semantics continuously (at compile time and runtime), while unit tests validate end-to-end scenarios and edge cases. Both are necessary for a comprehensive quality assurance strategy.
