Weblogs Forum - Programming with Contracts

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Programming with Contracts

15 replies on 2 pages. Most recent reply: Oct 22, 2004 2:44 PM by Todd Blanchard

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 15 replies on 2 pages [ 1 2 | » ]

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Programming with Contracts (View in Weblogs)

Posted: Oct 15, 2004 10:40 AM

Summary
Programming with Contracts is a sofware development technique rapidly gaining in popularity but still somewhat misunderstood. I have been spending a lot of time lately writing about contracts and using them in the Heron standard library.

Programming with Contracts (PwC) is a technique of using contracts in software in order to detect and reduce the number of defects in software. This is done by explicitly stating design specifications in a manner which can be verified by the compiler. This is related to but is not the same thing as Design by Contract ^tm which is a technique for designing software. The difference can be likened to the differences between OOP and OOD, one compliments the other but either one can exist without the other.

The role of a contract is to explicitly express the assumptions, requirements and obligations of a class or function. A contract is made up of one or more clauses. There are three kinds of clauses:

preconditions are clauses that must evaluate to true before entry of a function
postconditions are clauses that must evalute to true after exit from a function
invariants are clauses that must evalute to true before entry and after exit from every public function in a class

A contract should never be violated in correct software. If a clause is ever violated, there is a defect in your software (or possibly your contract).

The sticky point for a lot of people is understanding precisely what constitutes a contractual violation. Exceptional conditions and system failures in of themselves are not bugs but simply error conditions. A bug would occur if the these conditions where not handled in a manner as specified in the design specification. If no specification exists, whether explicit or assumed, that alone in of itself is a defect of the gravest kind.

For more information on contracts I suggest starting with the following:

http://archive.eiffel.com/doc/manuals/technology/contract/ - An excerpt from the eiffel manual
http://www.artima.com/intv/contracts.html - a conversation with Bertand Meyer by Bill Venners

For those interested: keep an eye out for my article Programming with Contracts in C++ in an upcoming issue of Doctor Dobbs Journal.

Roger Alexander

Posts: 6
Nickname: ralexander
Registered: Oct, 2004

Re: Programming with Contracts

Posted: Oct 16, 2004 11:01 PM

> This is related to but is not the same thing as
> Design by Contract tm which is a technique for
> designing software. The difference can be likened to the
> differences between OOP and OOD, one compliments the other
> but either one can exist without the other.
> 

Hmm, in what way are they different? Could you please elaborate. I've been using DBC since 1989, and to my mind, what you describe below fits DBC to a tee. So, how is PBC different from DBC?

> The role of a contract is to explicitly express the
> assumptions, requirements and obligations of a class or
> function.

Yes, but it is much more. Fundamentally, it is the specification of correctness.

> A contract is made up of one or more clauses. There are
> three kinds of clauses:
> <ul>
> <li>preconditions are clauses that must evaluate to true
> ue before entry of a function</li>
> <li>postconditions are clauses that must evalute to true
> ue after exit from a function</li>
> <li>invariants are clauses that must evalute to true
> ue before entry and after exit from every public function
> in a class</li>

Yep, still sounds like DBC.

> </ul>
> 
> A contract should never be violated in correct
> software.

By definition.

>If a clause is ever violated, there is a defect
> in your
> software (or possibly your contract).

You parenthetical comment impkies that the specification is wrong. But were there were a contract violation (i.e. a clause if false, which could only occur during the execution of a method), then the method's implementation is incorrect in the first place. This assumes the contract is specified *before* the method is implemented. If this is not the case, the contract could be incorrect. However, this should only be a possibility when contracts are derived as part of reverse engineering (i.e. they were not specified in the first place or they were lost). The should not be the result of a dysfunctional development practice whereby the code is written first and then the contracts are specified. Sadly, I know this is not an uncommon practice.

> 
> The sticky point for a lot of people is understanding
> precisely what constitutes a contractual violation.
> Exceptional conditions
> and system failures in of themselves are not bugs but
> simply error conditions. A bug would occur if the these
> conditions where
> not handled in a manner as specified in the design
> specification.

Careful here. By definition, a contract violation occurs any time one of the constraints (viz. Precondition or postcondition) is not satisfied (the invariant is a related but distinctly different issue). That is, a precondition violation occurs whenever a client has failed to ensure that the precondition holds prior to making a call; similarly, a postcondition violation occurs whenever the supplier fails to establish the postcondition (given that the precondition held). Yes, the suplier is obligated to preserve state consistency (i.e. the invariant must hold).

You are correct that exceptions and system failures are error conditions, but they are contract violations if they can occur and the specification of a method does not include them include them in its postcondition (assuming the method does not handle the exception or system failure). Putting it differently, if the occurrence of an exception or system failure prevents a method from establishing its postcondition, then a contract violation occurs. Period.

>If no specification exists, whether
> explicit or assumed, that alone in of itself is a defect
> of the gravest kind.

Absolutely, you could not make a more correct statement. However, note that every method has a contract, even if not explicitly specified. However, not specifying them is where the trouble begins.

-- Roger Alexander.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Programming with Contracts

Posted: Oct 17, 2004 8:03 AM

Hi Roger,

DbC is a software design methodology using the abstract notion of concepts, where is PwC refers to the usage of contracts in the software. Designing software is a task separate from implementation. I could use the abstract notion of contracts to express my software design whether or not I actually implement some kind of contract verification in my code. The same thing applies to Object Oriented Design. I can theoertically use OOD and UML to design a C program. I am not arguing these are good ideas, but that design is a separate practice from implementation.

Christopher said:
"If a clause is ever violated, there is a defect in your software (or possibly your contract)."

Roger said: "You parenthetical comment impkies that the specification is wrong. But were there were a contract violation (i.e. a clause if false, which could only occur during the execution of a method), then the method's implementation is incorrect in the first place. This assumes the contract is specified *before* the method is implemented. If this is not the case, the contract could be incorrect. However, this should only be a possibility when contracts are derived as part of reverse engineering (i.e. they were not specified in the first place or they were lost). The should not be the result of a dysfunctional development practice whereby the code is written first and then the contracts are specified. Sadly, I know this is not an uncommon practice."

I agree that DbC specifies that contracts should be written before implementation. It is reasonable though to expect that a contract will occasionally have an error, in the same way that DbC is based on the assumption that code will have errors. I don't see how reverse engineering is neccessary for a contractual error. I commonly mistakenly write contractual clauses that are incompatible with each other.

Roger said: "You are correct that exceptions and system failures are error conditions, but they are contract violations if they can occur and the specification of a method does not include them include them in its postcondition (assuming the method does not handle the exception or system failure). Putting it differently, if the occurrence of an exception or system failure prevents a method from establishing its postcondition, then a contract violation occurs. Period."

I agree with you here. I don't see where there is contention. Perhaps my description was not well worded?

Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: Programming with Contracts

Posted: Oct 17, 2004 1:42 PM

Could you please explain what someone who is currently doing DbC would do differently / additionally if they took up PwC?

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Programming with Contracts

Posted: Oct 17, 2004 2:34 PM

Hi Peter,

The answer is nothing, if they are using DbC correctly and using some kind of representation of the contracts in the source code. If they are not using a contractual representation, then they are probably using defensive programming techniques to make up for the lack of contractual support in their language.

Many people are actually only using PwC (and sometimes defensive programming) and calling it DbC. Up to now, any application of a contract based methodology was called DbC, due to lack of a separate nomenclature, whether or not they were using it is a design methodology. If they aren't designing their software starting by specifying the contracts first and then providing implementations then they are not using DbC.

Is this a satisfactory response?

Roger Alexander

Posts: 6
Nickname: ralexander
Registered: Oct, 2004

Re: Programming with Contracts

Posted: Oct 17, 2004 7:01 PM

> Hi Roger,
>
> DbC is a software design methodology using the abstract
> notion of concepts, where is PwC refers to the usage of
> contracts in the software.

I'm puzzled by this. Are you saying the PwC is the use of assertions to check contracts?

>Designing software is a task
> separate from implementation.

Sadly, this is a misconception held by many. I agree that things such as (for example) creating a UML class diagram and Responsibility Driven Design are high-level design activities and are distinct from implementation (i.e. writing code). However, implementation is itself a design activity, albeit at much lower level of abstraction. Nonetheless, defining the control structure and data flow of a program (procedure,method) are design activities in and of themselves. Unfortunately, both the software industry and academia have forgotten this.

Now as to DbC vs PwC, if the answer to my question posed above is "yes", then I am really puzzled. In particular, what learned as DbC back in the late 80's and into the 90's includes the use of assertions to check contracts, invariants, assumptions, and the like.

> I could use the abstract
> notion of contracts to express my software design whether
> or not I actually implement some kind of contract
> verification in my code.

Agreed, but this is not new. This has always been the case with DbC, so what does PwC offer that is not already in DbC? Or, is PwC simply the result of refactoring DbC into distinct design and programming components?

>The same thing applies to Object
> Oriented Design. I can theoertically use OOD and UML to
> design a C program. I am not arguing these are good ideas,
> but that design is a separate practice from
> implementation.

There is no theory to it. It has been done before. As to being good ideas, why would they not be?

>
> Christopher said:
> "If a clause is ever violated, there is a defect in your
> software (or possibly your contract)."
>
> Roger said: "You parenthetical comment impkies that the
> specification is wrong. But were there were a contract
> violation (i.e. a clause if false, which could only occur
> during the execution of a method), then the method's
> implementation is incorrect in the first place. This
> assumes the contract is specified *before* the method is
> implemented. If this is not the case, the contract could
> be incorrect. However, this should only be a possibility
> when contracts are derived as part of reverse engineering
> (i.e. they were not specified in the first place or they
> were lost). The should not be the result of a
> dysfunctional development practice whereby the code is
> written first and then the contracts are specified. Sadly,
> I know this is not an uncommon practice."
>
> I agree that DbC specifies that contracts should be
> written before implementation. It is reasonable though to
> expect that a contract will occasionally have an error, in
> the same way that DbC is based on the assumption that code
> will have errors. I don't see how reverse engineering is
> neccessary for a contractual error. I commonly mistakenly
> write contractual clauses that are incompatible with each
> other.

I see, you are pointing out that contracts must be self-consistent. That is, their clauses cannot equate to false. You are right, this is certainly a possibility, perhaps a common reality. But, it still is the case that the specification is flawed, and in this type of situation, no program can be written that will satisfy such a specification. Note that this argument assumes that the specification is written before the implementation. Also, I am making the distinction between the contract as specification and use of assertions to verify that contracts hold in a particular implementation. These are distinct.

Also implicit in my argument is that the specification is written first and then the implementation is written to the specification. Yes, I know that this is not always done, that folks often write the code and the specification simultaneously, with the code in effect being the specification.

>
> Roger said: "You are correct that exceptions and system
> failures are error conditions, but they are contract
> violations if they can occur and the specification of a
> method does not include them include them in its
> postcondition (assuming the method does not handle the
> exception or system failure). Putting it differently, if
> the occurrence of an exception or system failure prevents
> a method from establishing its postcondition, then a
> contract violation occurs. Period."
>
> I agree with you here. I don't see where there is
> contention. Perhaps my description was not well worded?

No contention intended, just clarification. I too have experience and knowledge, and am on a quest for truth.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Programming with Contracts

Posted: Oct 18, 2004 3:57 PM

> I'm puzzled by this. Are you saying the PwC is the use of assertions to check contracts?

Not simply using assertions, but any kind of representation of the contract in code. This could be done with assertions.

> In particular, what [sic] learned as DbC back in the late 80's and into the 90's includes the use of assertions to check contracts, invariants, assumptions, and the like.

I am not sure I understand your point, but the usage of assertions, is an implementation detail and has nothing to do with DbC as a design methodology.

> Agreed, but this is not new. This has always been the case with DbC, so what does PwC offer that is not already in DbC? Or, is PwC simply the result of refactoring DbC into distinct design and programming components?

Yes, you have hit the nail on the head. I would call them methodologies rather than components.

> There is no theory to it. It has been done before. As to being good ideas, why would they not be?

It is harder to implement and enforce an object oriented design in a programming language without support for OOP.

> I see, you are pointing out that contracts must be self-consistent. That is, their clauses cannot equate to false. You are right, this is certainly a possibility, perhaps a common reality. But, it still is the case that the specification is flawed, and in this type of situation, no program can be written that will satisfy such a specification. Note that this argument assumes that the specification is written before the implementation.

> Also, I am making the distinction between the contract as specification and use of assertions to verify that contracts hold in a particular implementation. These are distinct.

This is the point of PwC. PwC is the implementation of DbC.

Roger Alexander

Posts: 6
Nickname: ralexander
Registered: Oct, 2004

Re: Programming with Contracts

Posted: Oct 18, 2004 7:45 PM

> > I'm puzzled by this. Are you saying the PwC is the use
> of assertions to check contracts?
>
> Not simply using assertions, but any kind of
> representation of the contract in code. This could be done
> with assertions.

Could you elaborate a bit. What does "...any kind of representation of the contract in code" mean?

>
> > In particular, what [sic] learned as DbC back in the
> late 80's and into the 90's includes the use of assertions
> to check contracts, invariants, assumptions, and the
> like.
>
> I am not sure I understand your point, but the usage of
> assertions, is an implementation detail and has nothing to
> do with DbC as a design methodology.

My point is that, looking back at Meyer's work that he described as DbC includes in its description the use of assertions (e.g. the assertion language of Eiffel). While I do agree that assertions (e.g. the Java assert mechanism, the C/C++ assert macro, the Eiffel assertion language, and so on) are implementation details, they are used in a very specific way with DbC.

>
> > Agreed, but this is not new. This has always been the
> case with DbC, so what does PwC offer that is not already
> in DbC? Or, is PwC simply the result of refactoring DbC
> into distinct design and programming components?
>
> Yes, you have hit the nail on the head. I would call them
> methodologies rather than components.

Okay, "methodologies" if you like. But, what value results from the refactoring? Note that I am not challenging whether this is a good idea or not, Rather, I am asking for the details to support that assessment, one way or another. I'd really like to learn what the differences are.

>
> > There is no theory to it. It has been done before. As to
> being good ideas, why would they not be?
>
> It is harder to implement and enforce an object oriented
> design in a programming language without support for OOP.

Correct, but that does not mean it is a bad idea to do it if you are not fortunate enough to be using an OOP language. My point is that an OOPL is neither a necessary nor sufficient condition for OOD or OOP.

>
> This is the point of PwC. PwC is the implementation of DbC.

So, that being the case, it appears to me that PwC is simply a repackaging of what those of us practicing DbC have done all along, or is it? If not, then what is the value added by PwC not already present in how DbC has been applied all along? It would be helpful if you would provide details. Frankly, I have yet to see any argument that shows what PwC is, how it is different from good'ole DbC as practiced for the last 15+ years, and what the value added is.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Programming with Contracts

Posted: Oct 18, 2004 11:23 PM

What was described by Meyer as "Design by Contract" was really a combination of design methodology and implementation technique. By separating the two parts conceptually into DbC and PwC, it permits us to extend the ideas and apply them in new ways.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Programming with Contracts

Posted: Oct 19, 2004 5:10 AM

> What was described by Meyer as "Design by Contract" was
> really a combination of design methodology and
> implementation technique. By separating the two parts
> conceptually into DbC and PwC, it permits us to extend the
> ideas and apply them in new ways.

I realize you have the best of intentions, but the traditional split of "design" and "implementation" in software has wreaked havoc on development for a long time, and it is really the result of a widespread misunderstanding of the development process. Here is a classic article that presents an alternative view. I'm glad that it has been catching on quite a bit recently:

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Programming with Contracts

Posted: Oct 19, 2004 9:21 AM

I agree it is important to realize that implementation is actually a design process.

The practice of coming up with an abstract representation of software that can not be compiled is what I refer to as a design methodology. This differentiates it from the practice of refining an abstract representation into another representation that can be easily compiled or what is commonly referred to as implementation.

The widespread misunderstanding of the design process I don't think would be rectified by refusing to acknowledge the important practice of coming up with abstract representation of software.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Programming with Contracts

Posted: Oct 19, 2004 1:28 PM

> The widespread misunderstanding of the design process I
> don't think would be rectified by refusing to acknowledge
> the important practice of coming up with abstract
> representation of software.

The problem I've found often, and what others allude to here, is that for whatever reason most people believe the acknowledgement of being able to abstract the representation leads to the false belief that there is a clean line from abstraction down to implementation. Anybody that has done this software thing for any amount of time knows that once you get to implementation you run into things you haven't thought of, limitations in 3rd party components you depend on, winged-monkeys, etc. that should bubble up and have an effect on the abstraction.

For some reason people have ended up believing that software design is a linear process where some select group of architects gets together and puts together a design, then business analysts look at it and figure out how it will work and then it gets passed down to the code monkeys who just magically make it all work. Unfortunately it doesn't work like that.

I think more dangerous than not acknowledging that it is important to be able to abstract your concepts is not acknowledging that the real world of implementation will have an impact on the design. Yet, somehow, that seems to be perfectly ok in many circles. But that is hard. It involves getting your hands dirty and is often hard to quantify until you are waist deep in it.

Roger Alexander

Posts: 6
Nickname: ralexander
Registered: Oct, 2004

Re: Programming with Contracts

Posted: Oct 19, 2004 7:10 PM

> What was described by Meyer as "Design by Contract" was
> really a combination of design methodology and
> implementation technique. By separating the two parts
> conceptually into DbC and PwC, it permits us to extend the
> ideas and apply them in new ways.

Well, it's not that much of a design method. DbC does not lead you to a particular decomposition or to the decision that you need a type, method, proceudre, function, etc. It starts after this kind of decision has already been made, regardless of the process that lead to the decision. At most, DbC is an approach to specifying behavior of individual procedures and abstract data types. Actually, going further back in time, Hoare triples were used to express the behavior of procedures before they were used to express behavior of ADTs (and later, types with inheritance).

Roger Alexander

Posts: 6
Nickname: ralexander
Registered: Oct, 2004

Re: Programming with Contracts

Posted: Oct 19, 2004 7:26 PM

> I realize you have the best of intentions, but the
> traditional split of "design" and "implementation" in
> software has wreaked havoc on development for a long time,
> and it is really the result of a widespread
> misunderstanding of the development process.

I agree completely with this. It is interesting to observe how the notion of design has moved further and further away from what we consider to be the traditional form of implementation (i.e. writing code). The level of abstraction used to express designs keeps moving further and further away from the space where a solution can be expressed. That is, these high-level designs are far removed from any form of machine processable representation that can be translated that can into a solution space executable by a machine (computer) (or a solution space that can be translated [i.e. compiled] into such a representation.

Writing programs is very much a design activity, one that unfortunately is often done in a ad-hoc fashionm though it has not always been done this way.

>Here is a
> classic article that presents an alternative view. I'm
> glad that it has been catching on quite a bit recently:
>
> http://www.bleading-edge.com/Publications/C++Journal/Cpjour
> 2.htm

Thanks for point this out. I read it years ago, but had lost track of it.

Roger Alexander

Posts: 6
Nickname: ralexander
Registered: Oct, 2004

Re: Programming with Contracts

Posted: Oct 19, 2004 7:34 PM

> The problem I've found often, and what others allude to
> here, is that for whatever reason most people believe the
> acknowledgement of being able to abstract the
> representation leads to the false belief that there is a
> clean line from abstraction down to implementation.
> Anybody that has done this software thing for any amount
> of time knows that once you get to implementation you run
> into things you haven't thought of, limitations in 3rd
> party components you depend on, winged-monkeys, etc. that
> should bubble up and have an effect on the abstraction.

Quite correct. This is result of the problem of moving from a general abstraction to more specific abstraction. The nature (and power) of abstraction is such that a given level is independent of the details/percularities of next lower level. However, it is occasionally the case that the two levels are close enough that a formal mapping can made that moves an expression at one level into an expression at a lower level -- of course, this is how a compiler works!).

The problem faced by these higher forms of expressing abstractions (i.e. designs) is that it is often very difficult to define a formal mapping down to a level of abstraction that can ultimately be translated to an expression that can be executed by a machine (i.e. a computer in the conventional sense).

Flat View: This topic has 15 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic