Writing Correct Software Assertion and exception techniques can aid in class correctness Bertrand Meyer y aim in designing Eiffel was barring the occurrence of a major ca­ to produce a major program­ tastrophe resulting from faulty software, ming language for the 1990s, sooner or later someone will call the catering to the needs of those software engineers' bluff and ask them . software engineers willing to exactly why they think their systems Mdo what it takes to produce high-qual­ will perform as announced. It is diffi­ ity software. A key aspect of Eiffel, cult to answer that question convinc­ which makes it original in the world ingly given the current state of the art. of object-oriented languages, and in Eiffel won't provide the magical key the world of programming languages to the kingdom of software reliability. at large, is its strong emphasis on tech­ No existing method or tools wilL I do niques that help produce highly reli­ believe, however, that the EiffeI tech­ able software. niques are an impOItant step in the Although, there are many more as­ right direction. pects to Eiffel (including those described If you are expecting a sermon wliing in my book Object-Oriented Software you to improve your software's reli­ Construction, Prentice-Hall, 1988) the ability by adding a lot of consistency reliability features deserve a presenta­ checks, you are in for a few surprises. tion of their own. That is the focus of I suggest that one should llstl:.tlly check this article. I will show how it is possi­ less. According to conventional soft­ ble to write software that programmers ware engineering wisdom, "dett.>I1sive . (and users) can place a much higher programming" is considered to be a degree of confidence in than that writ­ programmer's best shot at reliability. I ten with traditional techniques. In par­ flexible software that is easy to build believe that defensive programming is ticular, I will discuss the all important and easy to maintain, but we also need a dangerow; practice that defeats the notion of assertion - the specification to be concerned that the software does velY purpose it tries to achieve. To element included within the software what it is supposed to do. program defen!'iively i!'i one of the worst itself. This will lead to a systematic From reading most of the object­ pieces of advice thm can be given to a view of exception handling, and a look oriented literature, one would think this programmer. at techniques (such as those offered is not a problem. Correctness concerns That more checking l'ttr1 make soft­ by Ada) that I find somewhat unsafe. are hardly ever mentioned. Actually, it ware less reliable may seem foolish. is unfair just to pick on object-oriented Remember, though, that in science cmu­ Why All the Fuss? programming. Take any standard text­ mon sense is not al\vays the best gUide. The issue is simple. It is great to have books you have on programming, al­ If YOli have ever hit a \\'(}otk~n table gorithms, data structures, and similar with your fist, you probably found it Bertrand is the preSident ofInteractive topics. See how many of them list "cor­ hard to believe rhe physics protf.:ssur Software Engineering and is the main rectness," "reliability," "invariant," or who told you rhar mattl'r is a !'et Df tiny designer ofthe Eiffellanguage. His book, "assertion" in their indexes. I have quite atoms with mostly nothing in-IX'twt,'(.~n. Object-Oriented Software Construction, a few textbooks on my shelves, but waspublished by Prentice Hall in 1988. could not find many that passed this Expressing the Specification He can be reached at 805-685-1006, simple test. 111e ideas that hdp achieve corr(.·t'ml';~s.s or through e-mail as Bertrand at This apparent disregard for correct­ in EitTd are mtK~h ()kk~r than EithA it,· Eiffel.com. ness issues cannot last forever. Even (continued Wl!UIJ{{' 52} 48 < EIFFEL (continued from page 48) ware element is correct or incorrect per may still publish the manuscript, but self. They come from work on program se; it is correct or incorrect only con­ does not have to. The situation is out­ proving and fonnal specification. Oddly cerning a particular specification, or side of the contract's bounds. enough, research on these topics has statement of its purpose. Correct ele­ remained estranged from most "real­ ments cannot be written unless the time Routine as Contract world" software development. Part of is taken to express all or part of this Specifying a routine is based on the the reason, at least in the United States, specification. transposition of these observations to is the widespread view that fonnal speci­ Writing the specification will not guar­ software. First, we need the equivalent fication and verification are specialized antee that it is met. But the presence of the contract document. It bewilders research topics whose application is of a specification, even one that is only me that no such concept exists in stan­ mostly relevant to "mission-critical" soft­ partially spelled out, goes a surpris­ dard approaches to software construc­ ware. Correctness, however, should be ingly long way toward helping pro­ tion. a universal concern. Eiffellooked at speci­ duce elements that satisfy their correct­ The specification consists of two fication and verification work to see ness requirements. parts: how much of it could be made part of This idea was captured by the title a standard programming methodology. of an article by Harlan Mills, then of • The precondition of a routine states Eiffel is a production language and IBM, published in 1975: "How to Write the obligations of clients, which are environment. It is not a research vehi­ Correct Programs and Know Why." If also the benefits for the routine itself. cle. Eiffel relies on the technology of you are a serious software engineer, • The postcondition states the obliga­ the last part of the twentieth century. you don't just want to hope that your tions of the routine, which are also It has to work now. This means that no programs are correct because you have the benefits for the clients. miracles can be expected. In fact, the been careful, and done a lot of testing, techniques are modest and almost naive. and so on. You need precise argu­ The precondition is a set of initial con­ They are the result of an engineering ments that document the correctness ditions under which the routine oper­ trade-off between what is desirable in of your software. ates. Ensuring the precondition at the an ideal world and what can realisti­ In Eiffel, such arguments are ex­ time of any call to the routine is the cally be implemented today. But they pressed as assertions -:- elements of for­ clients' responsibility. make a big difference and I can't un­ mal specification that can be attached The postcondition is a set of final derstand why no widespread language, to software components, classes and conditions the routine is expected to other than Eiffel, has made any signifi­ their routines. ensure. Ensuring the postcondition at. cant attempt in a similar direction. return time (if the precondition was The basic idea is rather trivial. Cor­ The Contract met on entry) is the routine's responsi­ rectness is a relative notion. No soft- Let's look at routines first. A routine is bility. the description of some computation The concept of a contract is one of the on the instances of a class, made avail­ most useful aids to understanding Eif­ able by that class to its clients (to other fel programming. The role of contracts Bring in manuscript Get published telC! classes relying on its services). How in Eiffel can be compared to what mes­ before March 1st before May 1st do we specify the purpose of a routine? sage passing represents in Smalltalk. The view I find most helpful is that Publish before No need to do Figure 3 illustrates this idea. The func­ May 1st anything if no a routine provides clients with a way tion intersect1 in a class CIRCIE (as­ manuscript is received before to contract out for a certain task that sumed to be part of some graphic pack­ March 1st the client's designer finds advantageous age) returns one of the two intersecting not to implement within the text of the points of two circles (see Figure 2). client. This is the same way that we We will look at how to associate the Figure 1: Contract between a humans at times contract out for part precondition and the postcondition to publisher and an author or all of a task that we need to perfonn. the text of the function in the actual Human contracts have two impor­ Eiffel class. In this example: tant properties: • The precondition is that the two rec­ • Each party expects some benefits and tangles should intersect. is prepared to incur some obligations • The postcondition is that the function in return. What is an obligation for result is a point that is on both circles. one party is a benefit for the other. • The obligations and benefits are Contract Variants spelled out in a contract document. This is not the only possible specifica­ Figure 2: Circle intersection tion. Programmers may feel uneasy Figure 1 illustrates an example of a about the just mentioned "demanding" contract between a publisher and an fonn of the routine, which only works Obligations Benefits author. The author's obligation is to in some cases. Instead, a tolerant ver­ Client Call the routine on ObtaIn as result of bring in a manuscript before March 1st.