DbC question - duplicated contracts

[streborg]

Hi, I am trying to introduce DbC to our developers (albeit using
Java...one step at a time ! ;) ) ...and am finding that there is
resistance at a certain level, that applying it in what I think is a
rigorous manner is seen as needless, and going too far.

A typical situation is when a function calls a "lower level" function
which does the "real work". It is thought that we are just
duplicating contracts needlessly.

For example, we have various layers in our software - domain,
application, UI, data. At the application level, say, we have
a "store" function (which stores some kind of object to the
database). To achieve its goal, it calls a corresponding data
layer "store" function. The application layer store function
basically does some transforming of the object to an appropriate
format (from a DTO do a domain object), and then calls the data layer
store function.

So, to my way of thinking, the contracts (just concentrating on
postconditions here) are quite straightforward. The application layer
store method will guarantee that the object gets stored. The data
layer store method pretty much also guarantees the same thing. (There
will be various differences too, as well as in the preconditions, eg,
dealing with the different formats).

So, if we have similar postconditions at these 2 levels, it is seen
as pointlessly duplicating them.

However, the way I see it is that is is perfectly ok to do this.
After all, they do in fact do similar things. Also, contracts are for
specifying WHAT is done, not HOW. So, for writing contracts, we
should be oblivious to how the function is fulfilling its
postconditions (in this case by calling the lower level store
function) and simply concentrate on WHAT should be true after the
function has done its job.

Also, "duplicating" the postconditions is building up internal
consistency within the application.

Colleagues are arguing that we should look at what the function is
doing, ie calling the lower level store function, and because it has
the postcondition that it will store the object, then we
should "trust" it to do its job, and not bother duplicating the
postcondition at the application layer.

To me this totally goes against the idea that the contracts are
stating WHAT should be done, not HOW. We might think that it's all ok
now, because we can see that our current implementation calls the
lower level function, but if that changed (perhaps accidently) then
we would never know that the higher level function is not fulfilling
its contract, because we have totally left this out of its contract.

I hope this makes some sense ?
Sorry to have rambled on a bit !

So, can anyone advise me at to how we really should be setting up our
contracts in this kind of situation ?
duplicate, or not ?

thanks very much ! :)



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Colin LeMahieu]

You're 100% right, the contracts should be duplicated.

The very simple reason is, a function doesn't know who its caller is,
so it's an error to say "If this function is called, this was checked
by it's parent function and is correct"  You see this *All the time*
in code comments and it will bite them, especially in highly changing
projects.

The opposite side related to reuse, you don't know how your low level
functions will be reused in the future so even though right now there
is a 1-1 relationship between high level and low level function, it
may become 2-1 or more in the future and if the low level contract is
gone, you have a bug that DbC was designed to fix.

Good job bringing DbC to work, we need more correct programs out there.

--- In eiffel_software@..., "streborg" <streborg@...> wrote:

>
> Hi, I am trying to introduce DbC to our developers (albeit using
> Java...one step at a time ! ;) ) ...and am finding that there is
> resistance at a certain level, that applying it in what I think is a
> rigorous manner is seen as needless, and going too far.
>
> A typical situation is when a function calls a "lower level" function
> which does the "real work". It is thought that we are just
> duplicating contracts needlessly.
>
> For example, we have various layers in our software - domain,
> application, UI, data. At the application level, say, we have
> a "store" function (which stores some kind of object to the
> database). To achieve its goal, it calls a corresponding data
> layer "store" function. The application layer store function
> basically does some transforming of the object to an appropriate
> format (from a DTO do a domain object), and then calls the data layer
> store function.
>
> So, to my way of thinking, the contracts (just concentrating on
> postconditions here) are quite straightforward. The application layer
> store method will guarantee that the object gets stored. The data
> layer store method pretty much also guarantees the same thing. (There
> will be various differences too, as well as in the preconditions, eg,
> dealing with the different formats).
>
> So, if we have similar postconditions at these 2 levels, it is seen
> as pointlessly duplicating them.
>
> However, the way I see it is that is is perfectly ok to do this.
> After all, they do in fact do similar things. Also, contracts are for
> specifying WHAT is done, not HOW. So, for writing contracts, we
> should be oblivious to how the function is fulfilling its
> postconditions (in this case by calling the lower level store
> function) and simply concentrate on WHAT should be true after the
> function has done its job.
>
> Also, "duplicating" the postconditions is building up internal
> consistency within the application.
>
> Colleagues are arguing that we should look at what the function is
> doing, ie calling the lower level store function, and because it has
> the postcondition that it will store the object, then we
> should "trust" it to do its job, and not bother duplicating the
> postcondition at the application layer.
>
> To me this totally goes against the idea that the contracts are
> stating WHAT should be done, not HOW. We might think that it's all ok
> now, because we can see that our current implementation calls the
> lower level function, but if that changed (perhaps accidently) then
> we would never know that the higher level function is not fulfilling
> its contract, because we have totally left this out of its contract.
>
> I hope this makes some sense ?
> Sorry to have rambled on a bit !
>
> So, can anyone advise me at to how we really should be setting up our
> contracts in this kind of situation ?
> duplicate, or not ?
>
> thanks very much ! :)
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Colin LeMahieu]

It also might help to point out that contracts will not be in the
system once finalized.  Their purpose is for development for the
reasons stated before.  When the system is finalized the trust is
established that the low levels will do their jobs correctly, not
during development.

--- In eiffel_software@..., "streborg" <streborg@...> wrote:

>
> Hi, I am trying to introduce DbC to our developers (albeit using
> Java...one step at a time ! ;) ) ...and am finding that there is
> resistance at a certain level, that applying it in what I think is a
> rigorous manner is seen as needless, and going too far.
>
> A typical situation is when a function calls a "lower level" function
> which does the "real work". It is thought that we are just
> duplicating contracts needlessly.
>
> For example, we have various layers in our software - domain,
> application, UI, data. At the application level, say, we have
> a "store" function (which stores some kind of object to the
> database). To achieve its goal, it calls a corresponding data
> layer "store" function. The application layer store function
> basically does some transforming of the object to an appropriate
> format (from a DTO do a domain object), and then calls the data layer
> store function.
>
> So, to my way of thinking, the contracts (just concentrating on
> postconditions here) are quite straightforward. The application layer
> store method will guarantee that the object gets stored. The data
> layer store method pretty much also guarantees the same thing. (There
> will be various differences too, as well as in the preconditions, eg,
> dealing with the different formats).
>
> So, if we have similar postconditions at these 2 levels, it is seen
> as pointlessly duplicating them.
>
> However, the way I see it is that is is perfectly ok to do this.
> After all, they do in fact do similar things. Also, contracts are for
> specifying WHAT is done, not HOW. So, for writing contracts, we
> should be oblivious to how the function is fulfilling its
> postconditions (in this case by calling the lower level store
> function) and simply concentrate on WHAT should be true after the
> function has done its job.
>
> Also, "duplicating" the postconditions is building up internal
> consistency within the application.
>
> Colleagues are arguing that we should look at what the function is
> doing, ie calling the lower level store function, and because it has
> the postcondition that it will store the object, then we
> should "trust" it to do its job, and not bother duplicating the
> postcondition at the application layer.
>
> To me this totally goes against the idea that the contracts are
> stating WHAT should be done, not HOW. We might think that it's all ok
> now, because we can see that our current implementation calls the
> lower level function, but if that changed (perhaps accidently) then
> we would never know that the higher level function is not fulfilling
> its contract, because we have totally left this out of its contract.
>
> I hope this makes some sense ?
> Sorry to have rambled on a bit !
>
> So, can anyone advise me at to how we really should be setting up our
> contracts in this kind of situation ?
> duplicate, or not ?
>
> thanks very much ! :)
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[streborg]

Thanks for your help, much appreciated :)

Yes, we've been implementing the contracts via the Java "assert"
statement, which can be turned on or off via a switch on the JVM -
so, efficiency shouldn't be an issue. Plain Java isn't anywhere near
as nice or functional as Eiffel when it comes to DbC (obviously !),
so I have to save old values if required etc, when coming into the
routines. There are some packages available which add DbC support,
but we wanted to try DbC with plain Java, without adding any
dependencies, and see how we go with it.

Actually, in terms of turning the contracts off in production, I've
usually taken the position that it's like most other optimisation
issue - ie, optimise when and if it becomes a problem. So, I'm
inclined to leave them on, even in production, if there is no
efficiency problems.

(I've just downloaded EiffelStudio 6.1 to play around with at
home...pity not enough places take quality seriously enough to use
Eiffel (or DbC at least !))


--- In eiffel_software@..., "colinlema" <clemahieu@...>
wrote:
>
> It also might help to point out that contracts will not be in the
> system once finalized.  Their purpose is for development for the
> reasons stated before.  When the system is finalized the trust is
> established that the low levels will do their jobs correctly, not
> during development.
>
> --- In eiffel_software@..., "streborg" <streborg@>
wrote:
> >
> > Hi, I am trying to introduce DbC to our developers (albeit using
> > Java...one step at a time ! ;) ) ...and am finding that there is
> > resistance at a certain level, that applying it in what I think
is a
> > rigorous manner is seen as needless, and going too far.
> >
> > A typical situation is when a function calls a "lower level"
function

> > which does the "real work". It is thought that we are just
> > duplicating contracts needlessly.
> >
> > For example, we have various layers in our software - domain,
> > application, UI, data. At the application level, say, we have
> > a "store" function (which stores some kind of object to the
> > database). To achieve its goal, it calls a corresponding data
> > layer "store" function. The application layer store function
> > basically does some transforming of the object to an appropriate
> > format (from a DTO do a domain object), and then calls the data

layer
> > store function.
> >
> > So, to my way of thinking, the contracts (just concentrating on
> > postconditions here) are quite straightforward. The application
layer
> > store method will guarantee that the object gets stored. The data
> > layer store method pretty much also guarantees the same thing.
(There
> > will be various differences too, as well as in the preconditions,
eg,
> > dealing with the different formats).
> >
> > So, if we have similar postconditions at these 2 levels, it is
seen
> > as pointlessly duplicating them.
> >
> > However, the way I see it is that is is perfectly ok to do this.
> > After all, they do in fact do similar things. Also, contracts are
for

> > specifying WHAT is done, not HOW. So, for writing contracts, we
> > should be oblivious to how the function is fulfilling its
> > postconditions (in this case by calling the lower level store
> > function) and simply concentrate on WHAT should be true after the
> > function has done its job.
> >
> > Also, "duplicating" the postconditions is building up internal
> > consistency within the application.
> >
> > Colleagues are arguing that we should look at what the function

is
> > doing, ie calling the lower level store function, and because it
has
> > the postcondition that it will store the object, then we
> > should "trust" it to do its job, and not bother duplicating the
> > postcondition at the application layer.
> >
> > To me this totally goes against the idea that the contracts are
> > stating WHAT should be done, not HOW. We might think that it's
all ok
> > now, because we can see that our current implementation calls the
> > lower level function, but if that changed (perhaps accidently)
then
> > we would never know that the higher level function is not
fulfilling
> > its contract, because we have totally left this out of its
contract.
> >
> > I hope this makes some sense ?
> > Sorry to have rambled on a bit !
> >
> > So, can anyone advise me at to how we really should be setting up
our
> > contracts in this kind of situation ?
> > duplicate, or not ?
> >
> > thanks very much ! :)
> >
>



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[rfo]

Howdy!

All good points, well stated.

Another important aspect of contracts is that they constitute a (verifiable) specification.  No doubt when your coworkers hear "specification", the flinch a little but perhaps you can explain that good contracts in the code will free them of separate (unmaintainable) specfication chores (everybody loves a bargain).  As teams grow and separate, contracts remain and serve to specify the interface between teams as much as between components.  Most organizations will have different groups working on different layers (or components) and so having contracts at each layer and in each component provides a built-in mechanism for reducing inter-team management overhead.  The upper-layer teams become clients (in real world terms) of the lower-layer teams and so the in-code contracts serve to specify and enforce the human-layer contracts, making for a much smoother relationship.  The lower-layer teams can choose any implementation method they desire, as long as it fulfills their customer's (the upper-layer team's) defined requirements (the contracts).

Contracts' value as "finders" w/r/t implementation flaws is huge of course, but let's also remember their net effect on system complexity.  A well balanced contract (as elegantly illustrated in Jim McKim's and Brian Henderson-Sellers's "Contracting - What's in it for the Supplier?") results in the minimal complexity.  Your team might have bought into this notion already, but a gentle reminder every once in a while can't hurt.

It might also be helpful to note that the belief that a given contract is superfluous is seen by some (me) as irrefutable proof of "POOP" (procedure-oriented object programming).  "I know that this is the sequence of instructions, so I need not do this again" is a sound observation in a truly procedural system (it's what allows us to build optimizers).  The problem is that component systems are not procedural even if individual components are.  Engineers love to criticize Marketing types every time they say "all you have to do is ...", but that seems to be exactly what engineers are saying when dimissing the need/value of contracts at every layer.  Save the "all you gotta do is" for within the loop or function, but don't paint the whole system with the same brush.

As for the turn-off-later approach, it too can be layered to match your system architecture.   If you arrange you layers into a cluster-like grouping, then the compile-time and run-time switches can be turned off at each layer as needed or desired.

Now that you have introduced DbC, you've opened up a world of possibilities for product and process improvement.  DbC will in time allow you to streamline your operations and give back to your developers more high-quality time.  They'll become more productive and more personally satisfied with their work (really).  They won't believe this until they see it of course (none of us would).

Keep up the good work

     R

==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460

> -------- Original Message --------
> Subject: [eiffel_software] Re: DbC question - duplicated contracts
> From: "colinlema" <clemahieu@...>
> Date: Sat, May 17, 2008 1:34 am
> To: eiffel_software@...
>
> It also might help to point out that contracts will not be in the
> system once finalized.  Their purpose is for development for the
> reasons stated before.  When the system is finalized the trust is
> established that the low levels will do their jobs correctly, not
> during development.
>
> --- In eiffel_software@..., "streborg" <streborg@...> wrote:
> >
> > Hi, I am trying to introduce DbC to our developers (albeit using
> > Java...one step at a time ! ;) ) ...and am finding that there is
> > resistance at a certain level, that applying it in what I think is a
> > rigorous manner is seen as needless, and going too far.
> >
> > A typical situation is when a function calls a "lower level" function
> > which does the "real work". It is thought that we are just
> > duplicating contracts needlessly.
> >
> > For example, we have various layers in our software - domain,
> > application, UI, data. At the application level, say, we have
> > a "store" function (which stores some kind of object to the
> > database). To achieve its goal, it calls a corresponding data
> > layer "store" function. The application layer store function
> > basically does some transforming of the object to an appropriate
> > format (from a DTO do a domain object), and then calls the data layer
> > store function.
> >
> > So, to my way of thinking, the contracts (just concentrating on
> > postconditions here) are quite straightforward. The application layer
> > store method will guarantee that the object gets stored. The data
> > layer store method pretty much also guarantees the same thing. (There
> > will be various differences too, as well as in the preconditions, eg,
> > dealing with the different formats).
> >
> > So, if we have similar postconditions at these 2 levels, it is seen
> > as pointlessly duplicating them.
> >
> > However, the way I see it is that is is perfectly ok to do this.
> > After all, they do in fact do similar things. Also, contracts are for
> > specifying WHAT is done, not HOW. So, for writing contracts, we
> > should be oblivious to how the function is fulfilling its
> > postconditions (in this case by calling the lower level store
> > function) and simply concentrate on WHAT should be true after the
> > function has done its job.
> >
> > Also, "duplicating" the postconditions is building up internal
> > consistency within the application.
> >
> > Colleagues are arguing that we should look at what the function is
> > doing, ie calling the lower level store function, and because it has
> > the postcondition that it will store the object, then we
> > should "trust" it to do its job, and not bother duplicating the
> > postcondition at the application layer.
> >
> > To me this totally goes against the idea that the contracts are
> > stating WHAT should be done, not HOW. We might think that it's all ok
> > now, because we can see that our current implementation calls the
> > lower level function, but if that changed (perhaps accidently) then
> > we would never know that the higher level function is not fulfilling
> > its contract, because we have totally left this out of its contract.
> >
> > I hope this makes some sense ?
> > Sorry to have rambled on a bit !
> >
> > So, can anyone advise me at to how we really should be setting up our
> > contracts in this kind of situation ?
> > duplicate, or not ?
> >
> > thanks very much ! :)
> >

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/eiffel_software/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:eiffel_software-digest@...
    mailto:eiffel_software-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    eiffel_software-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/