Previous Table of Contents Next


The default is require. This is particularly interesting in connection with the Eiffel method’s insistence on using libraries: With libraries such as EiffelBase that are richly equipped with preconditions expressing terms of use, an error in the client software often leads, for example through an incorrect argument, to violating one of these preconditions. A somewhat paradoxical consequence is that even an application developer who does not apply the method too well (out of carelessness, haste, indifference, or ignorance) still benefits from the presence of assertions in someone else’s library code.

During development and testing, assertion monitoring should be turned on at the highest possible level. Combined with static typing and the immediate feedback of compilation techniques such as the Melting Ice Technology, this permits the development process mentioned in section 9.3.6, where errors are exterminated at birth. No one who has not practiced the method in a real project can imagine how many mistakes are found in this way; surprisingly often, a violation turns out to affect an assertion that was just included for goodness’s sake, the developer being convinced that it could not “possibly” fail to be satisfied.

By providing a precise reference (the description of what the software is supposed to do) against which to assess the reality (what the software actually does), design by contract profoundly transforms the activities of debugging, testing, and quality assurance.

When releasing the final version of a system, it is usually appropriate to turn off assertion monitoring, at least down to the require level. The exact policy depends on the circumstances; it is a tradeoff between efficiency considerations, the potential cost of mistakes, and how much the developers and quality assurance team trust the product. When developing the software, however, one should always assume that monitoring will be turned off in the end (to avoid loosening one’s guard).

9.8.5. The Short Form of a Class

Another application of assertions regards documentation. Environment mechanisms—such as clicking the short button of a class tool in ISE’s EiffelBench—produce, from a class text, an abstracted version, the short form, which only includes the information relevant for client authors. Here is the short form of class ACCOUNT in its latest version:

   indexing
       description: “Simple bank accounts”
   class interface
       ACCOUNT
   feature  -- Access
       balance: INTEGER
                -- Current balance
       deposit_count: INTEGER
                -- Number of deposits made since opening
   feature  -- Element change
       deposit (sum: INTEGER)
            -- Add sum to account.
           require
               non_negative: sum >= 0
           ensure
               one_more_deposit: deposit_count = old deposit_count + 1
               updated: balance = old balance + sum
   invariant
       consistent_balance: balance = all_deposits.total
   end  -- class interface ACCOUNT

The words class interface are used instead of just class to avoid any confusion with actual Eiffel text because this is documentation, not executable software. (It is in fact possible to generate a compilable variant of the short form in the form of a deferred class, a notion defined in section 9.9.5.)

Compared to the full text, the short form keeps all the elements that are part of the abstract interface relevant to client authors:

  Names and signatures (argument and result type information) for the exported features.
  Header comments of these features, which carry informal descriptions of their purpose (hence the importance, mentioned in section 9.4, of always including such comments and writing them carefully).
  Preconditions and postconditions of these routines (at least the subclauses involving only exported features, which may exclude certain postcondition subclauses).
  Class invariant (at least the subclauses involving only exported features, which may exclude certain postcondition subclauses).

The following elements are removed, however: any information about non-exported features; all the routine bodies (do clauses, or the external and once variants in sections 9.5.6 and 9.10.1); assertion subclauses involving non-exported features; and some keywords not useful in the documentation, such as is for a routine.

In accordance with the uniform access principle (section 9.6.2), the short form does not distinguish between attributes and argument-less queries. In the preceding example, balance could be one or the other, as it makes no difference to clients, except possibly for performance.

The short form is the fundamental tool for using supplier classes in the Eiffel method. It protects client authors from the need to read the source code of software on which they rely. This is a crucial requirement in large-scale industrial developments.


Previous Table of Contents Next