Re: Interresting thread in comp.lang.eiffel

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Ken Garlington <Ken.Garlington@computer.org> wrote:
>
> I guess I'd like to see an example that actually captured something
> other than software. It's not perfect, but just by concidence I have
> a dataset that represents something vaguely similar to the parameters
> of interest in the Ariane 5 system. If you go to
>
> http://home.flash.net/~kennieg/yf22/crash.html
>
> and scroll down the page, you will see a figure titled YF-22A Accident
> Sequence. Perhaps if you could post Eiffel code that would detect that
> pilot-induced oscillation would have occured given this test case, I
> could understand your confidence in the DbC tecnique better.

Hmm... I didn't really understand what the report says. It looks like an
oscillation in a self-regulating loop (or whatever this is called in
English cybernetic
theory), with the pilot in the loop somewhere, but I don't know what
parameters should have been detected - I don't now enough about English
aviation terminology and cybernetics to pinpoint what exactly should
have been checked.

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8kl13r$2qd1s$1@ID-9852.news.cis.dfn.de...
> Ken Garlington <Ken.Garlington@computer.org> wrote:
> >
> > I guess I'd like to see an example that actually captured something
> > other than software. It's not perfect, but just by concidence I have
> > a dataset that represents something vaguely similar to the parameters
> > of interest in the Ariane 5 system. If you go to
> >
> > http://home.flash.net/~kennieg/yf22/crash.html
> >
> > and scroll down the page, you will see a figure titled YF-22A Accident
> > Sequence. Perhaps if you could post Eiffel code that would detect that
> > pilot-induced oscillation would have occured given this test case, I
> > could understand your confidence in the DbC tecnique better.
>
> Hmm... I didn't really understand what the report says. It looks like an
> oscillation in a self-regulating loop (or whatever this is called in
> English cybernetic
> theory), with the pilot in the loop somewhere, but I don't know what
> parameters should have been detected - I don't now enough about English
> aviation terminology and cybernetics to pinpoint what exactly should
> have been checked.

So what you're saying is: without specific knowledge in this domain, you're
finding it difficult to understand how to write the proper contract?

Would it be fair to say that if you were a software engineer analyzing an
existing module contract, and you were given this figure, you might also
have difficulties?

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Ken Garlington <Ken.Garlington@computer.org> wrote:
>
> So what you're saying is: without specific knowledge in this domain,
> you're finding it difficult to understand how to write the proper
> contract?

Yes.

> Would it be fair to say that if you were a software engineer analyzing
> an existing module contract, and you were given this figure, you might
> also have difficulties?

Yes. The paper assumes a lot of knowledge that I simply do not have. I'd
be unable to distill this into a specification, whether using assertions
or any other method.

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8kt1cn$38mus$2@ID-9852.news.cis.dfn.de...
> Ken Garlington <Ken.Garlington@computer.org> wrote:
> >
> > So what you're saying is: without specific knowledge in this domain,
> > you're finding it difficult to understand how to write the proper
> > contract?
>
> Yes.
>
> > Would it be fair to say that if you were a software engineer analyzing
> > an existing module contract, and you were given this figure, you might
> > also have difficulties?
>
> Yes. The paper assumes a lot of knowledge that I simply do not have. I'd
> be unable to distill this into a specification, whether using assertions
> or any other method.

Exactly, and this is something that a lot of people have difficulty
understanding in the Ariane 5 case. Not to over-generalize, but a lot of
programmers work in fields where they can have direct understanding of the
domain. For example, if you work on a game program or web site, you probably
have some expertise in the domain - you have played video games or used web
sites before.

It's much more difficult for people working on a big project like Ariane 5.
The problem is that we aren't dealing with a stand-alone system -- a single
domain. We're dealing with a lot of interlocking domains (airframe,
propulsion, flight control, avionics....) which require a number of
engineering specialties (software, hardware, aerospace, mechanical...) to
communicate with each other across a number of organizational and
geographical boundaries. It's extremely easy for information to not be
communicated effectively -- like a changed flight profile.

It occurs to me that people might be interested in similar cases in the
aerospace world where the failure to communicate has led to catastrophic
accidents. Here's a few references:

http://www.flash.net/~kennieg/titan/titan_1996.html

http://www.flash.net/~kennieg/titan/titan_1999.html

http://www.flash.net/~kennieg/x31/x31.htm

Re: Interresting thread in comp.lang.eiffel

[Robert I. Eachus]

Ken Garlington wrote:
  
> Are we sure that there was no contractual arrangement between Arianespace
> and Sextant with respect to the use of the SRI on Ariane 5? The inquiry
> doesn't explicitly say either way, but having nothing at all would certainly
> be an unusual practice in my experience. My vague recollection of the
> Aviation Week & Space Technology articles from July-August 1996 was that
> there was some relationship, but I'll have to go by the library today to see
> for sure.

   As I remember it, there was planned to be a relationship as part of
the full-up
simulation of the flight control system.  When the decision was made not
to use the
SRIs in the simulation, that part of the contract was cut back or
cancelled.  I think
they still had the SRI hardware supplier on contract, but not the
software developers.

   I argee however, that the real lesson that should be drawn from this
is that there
has to be a project library--possibly on-line--that is accessable to all
subcontractors,
and that has at least all the interface specifications and the
operational concept. As
near as I can figure out, the management disconnect occured because
there was an original
test plan which covered all the bases, but changes to that plan were not
communicated to
everyone who needed to know about them.  As a result the lower level
test plans still
allocated test objectives to tests that were not conducted.  (The high
level objectives
were redistributed, but there were lower-level and derived requirements
that were never
reallocated.)

   Incidently, I was just looking at your YF-22 crash data.  The cause
may be called Pilot Induced Oscillation, but the real culprit was lack
of feedback to the pilot.  There was no
direct relationship between the position of the stick and the position
of the stabilators
in the later part of the event due to the rate-limited nature of the
stabilator controls.
I hope that this is fixed in the production F-22.  (The nasty effect of
the change in flight
control mode when the gear went up seems to have been key.  The pilot
was trying to cancel
out the change, but had no direct feedback.)

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Robert I. Eachus" <rieachus@earthlink.net> wrote in message
news:396CA5AD.EE955F7A@earthlink.net...
>    As I remember it, there was planned to be a relationship as part of
> the full-up
> simulation of the flight control system.  When the decision was made not
> to use the
> SRIs in the simulation, that part of the contract was cut back or
> cancelled.  I think
> they still had the SRI hardware supplier on contract, but not the
> software developers.

Actually, I posted the AW&ST articles on my website. They indicate that
Sextant was a full partner in Ariane 5, and in fact that the Ariane 4 SRI
was *not* used "as is". See

http://www.flash.net/~kennieg/ariane5_awst.html

>
>    Incidently, I was just looking at your YF-22 crash data.  The cause
> may be called Pilot Induced Oscillation, but the real culprit was lack
> of feedback to the pilot.  There was no
> direct relationship between the position of the stick and the position
> of the stabilators
> in the later part of the event due to the rate-limited nature of the
> stabilator controls.
> I hope that this is fixed in the production F-22.  (The nasty effect of
> the change in flight
> control mode when the gear went up seems to have been key.

The gains changed abruptly when the aircraft transitioned from
takeoff-and-landing to up-and-away mode. This produced a sudden transient,
triggering the start of the PIO. The transition now occurs more gradually.

Re: Interresting thread in comp.lang.eiffel

[Robert I. Eachus]

(I'm replying directly because it has been a few days, and this is
getting
pretty far from Ada and or Eiffel.  But feel free to quote elsewhere...

Ken Garlington wrote:
> 
> "Robert I. Eachus" <rieachus@earthlink.net> wrote in message
> news:396CA5AD.EE955F7A@earthlink.net...
> >    As I remember it, there was planned to be a relationship as part of the full-up
> > simulation of the flight control system.  When the decision was made not
> > to use the SRIs in the simulation, that part of the contract was cut back or
> > cancelled.  I think they still had the SRI hardware supplier on contract, but not the
> > software developers.
 
> Actually, I posted the AW&ST articles on my website. They indicate that
> Sextant was a full partner in Ariane 5, and in fact that the Ariane 4 SRI
> was *not* used "as is". See

    First, there is a bit of confusion above.  If the software
developers in England
had been involved in the SIMULATION contract, they could have, and
probably would
have noticed the problem.  But they were not on contract for the Ariane
5, they were
contracted to develop a new IRS for the Ariane 4!

    This game playing was AFAIK the idea of CNES. The IRS was upgraded
for Ariane 5,
but--and here the game playing begins.  It was decided to use the "new"
IRS in the
Ariane 4.  To keep the cost overruns on the Ariane 5 down, the
development costs
were moved to the Ariane 4.  So far, no problem.  But then, and I'll
quote the report
on this:

 "It is even more important to note it was jointly agreed [by CNES and
its contractors]
not to include Ariane 5 trajectory data in the IRS' requirements and
specifications."

    There is the disaster in one sentence.  The new IRS for the Ariane
5, was designed
for, and only for, the Ariane 4. And since EASAMS Ltd. was a major
contractor on the
Ariane 4, but a sub to Aerospatiale on the Ariane 5, they were not
directly involved
in the decision not to get the Ariane 5 data, and according to my
sources, the decision
was directly due to the unwillingness by the French to release the data
to a British
firm--even though most of the work was done in Germany.  (I heard the
later after two
German beers.  So while some of this is very well documented, I can't
vouch for that.
I can vouch for the fact that EASAMS never got the Ariane 5 specs.  Not
they were told
not to use them, but they were not permitted to see them.)  And I also
know, and it is
very well recorded, that the issue of horizontal position post launch
was NOT decided
by the programmers.  They objected, and it went to a multi-contractor
review where it
was decided not to protect it.  But this was at an ARIANE 4 meeting, not
an Ariane 5
meeting, because the development of the new IRS was officially part of
the Ariane 4
project.

    I'm sorry to keep harping on this, but system engineering and system
integration
is what MITRE does, and at MITRE I worked on several multi-national
projects.  I was
in a position to gather some of this information first-hand, but MITRE
as such put a
lot of effort into figuring out where the failure occurred, even before
the official
report came out.  We wanted to make sure that we didn't repeat the same
errors, and I
was able to use the Ariane 5 as an object lesson on one project.

    By the way, I am now, as of last week, on long term disability. :-( 
I'm better
than I was in January, but I still haven't been into the office since
then.  Hopefully,
I'll get to finish some books and article while they are trying to
figure out just what
is wrong.
 
> The gains changed abruptly when the aircraft transitioned from
> takeoff-and-landing to up-and-away mode. This produced a sudden transient,
> triggering the start of the PIO. The transition now occurs more gradually.

   That fixes the primary cause, but not the actual failure mode.  Does
the stick now
have tactile feedback?  Or has the rate limit on the stabilator been
changed?  (Yes,
avoiding sudden non-pilot-induced control inputs is a very good thing. 
But tactile
feedback, such as stick shakers for stall warnings have the great
advantage of
focusing the pilot on where the action is needed.

-- RIE

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Robert I. Eachus" <rieachus@earthlink.net> wrote in message
news:397A5CB4.AF5F6B8A@earthlink.net...
> But they were not on contract for the Ariane
> 5, they were
> contracted to develop a new IRS for the Ariane 4!

Bob, could you cite a reference for this? It seems only fair, given that
I've provided references that describe Sextant as an Ariane *5*
subcontractor, as well as part of Ariane 4?

If you've got better information than Aviation Leak, fine -- they've
certainly made mistakes before -- but could you at least give something that
says your information is better?

> the development of the new IRS was officially part of
> the Ariane 4
> project.

Again, if you could cite a contract reference -- anything -- that
contradicts the AW&ST claim that "Ariane 5's IRU is an improved version of
Ariane 4's, and the older Ariane 4 is now also being equipped with the
version modernized *for Ariane 5*"

> > The gains changed abruptly when the aircraft transitioned from
> > takeoff-and-landing to up-and-away mode. This produced a sudden
transient,
> > triggering the start of the PIO. The transition now occurs more
gradually.
>
>    That fixes the primary cause, but not the actual failure mode.  Does
> the stick now
> have tactile feedback?

No -- you don't often get significant tactile feedback from a force-sensor
side stick connected to a FBW system, such as that on the F-16 or F-22. (In
fact, the original F-16 stick didn't move at all!) There are "active" sticks
and throttles, but they tend to be more complicated and therefore more
expensive/less reliable than their passive counterparts.

IIRC, some larger FBW aircraft such as the upgraded F-111 and Airbus series
do have stick shakers, but it's generated by the FBW system when the
aircraft gets close to the computed envelope limit. That kind of feedback
doesn't help much if you get into a PIO loop.

Re: Interresting thread in comp.lang.eiffel

[David Gillon]

Ken Garlington wrote:

> 
> > > The gains changed abruptly when the aircraft transitioned from
> > > takeoff-and-landing to up-and-away mode. This produced a sudden
> transient,
> > > triggering the start of the PIO. The transition now occurs more
> gradually.
> >
> >    That fixes the primary cause, but not the actual failure mode.  Does
> > the stick now
> > have tactile feedback?

> No -- you don't often get significant tactile feedback from a force-sensor
> side stick connected to a FBW system, such as that on the F-16 or F-22. (In
> fact, the original F-16 stick didn't move at all!) 

IIRC, the YF-16 had a PIO incident during the fast taxi trial and was
only saved by the test pilot lifting off before the oscillation about
the roll axis became severe enough to contact the runway with the
wingtips. He managed to dampen it out once in the air, did a circuit and
landed without further incident. The solution lay in the (analogue) FCS,
not the fixed stick.

There is an undeniable advantage to a moving stick, in that it
immediately demonstrates the last control input if the pilot is
hands-off or in a two crew cockpit. However I don't believe tactile
feedback as a solution to PIO is a workable argument for mandating one.
(Stick-shaker operation as a stall warner is a completely separate
issue).

-- 

David Gillon

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"David Gillon" <david.gillon@baesystems.com> wrote in message
news:397C29CA.7B445687@baesystems.com...
>
>
> Ken Garlington wrote:
>
> >
> > > > The gains changed abruptly when the aircraft transitioned from
> > > > takeoff-and-landing to up-and-away mode. This produced a sudden
> > transient,
> > > > triggering the start of the PIO. The transition now occurs more
> > gradually.
> > >
> > >    That fixes the primary cause, but not the actual failure mode.
Does
> > > the stick now
> > > have tactile feedback?
>
> > No -- you don't often get significant tactile feedback from a
force-sensor
> > side stick connected to a FBW system, such as that on the F-16 or F-22.
(In
> > fact, the original F-16 stick didn't move at all!)
>
> IIRC, the YF-16 had a PIO incident during the fast taxi trial and was
> only saved by the test pilot lifting off before the oscillation about
> the roll axis became severe enough to contact the runway with the
> wingtips.

Actually, the wingtips DID contact the runway, although the damage wasn't so
severe as to make the aircraft unflyable.

> He managed to dampen it out once in the air, did a circuit and
> landed without further incident. The solution lay in the (analogue) FCS,
> not the fixed stick.

Correct, although the stick was later changed to move slightly with the
pilot's hand, to give it a better "feel". It doesn't provide any feedback
from the airframe, however.

> There is an undeniable advantage to a moving stick, in that it
> immediately demonstrates the last control input if the pilot is
> hands-off or in a two crew cockpit.

IMO, It tends to be more defensible with respect to throttle, if the FCS can
independently select thrust (autothrottle).

> However I don't believe tactile
> feedback as a solution to PIO is a workable argument for mandating one.
> (Stick-shaker operation as a stall warner is a completely separate
> issue).

Particularly for a relaxed stability aircraft, the whole idea of feedback
gets interesting. Should it move in response to the surfaces, which aren't
necessaily moving in a way the pilot "expects"? Should the FCS -- which is
in the PIO loop -- be synthesizing some sort of artificial feedback? What
does "feedback" mean in the presence of thrust vectoring?

Re: Interresting thread in comp.lang.eiffel

[swhalen]

In comp.lang.ada Ken Garlington <Ken.Garlington@computer.org> wrote:
: "Robert I. Eachus" <rieachus@earthlink.net> wrote in message
: news:397A5CB4.AF5F6B8A@earthlink.net...
:> But they were not on contract for the Ariane
:> 5, they were
:> contracted to develop a new IRS for the Ariane 4!

: Bob, could you cite a reference for this? It seems only fair, given that
: I've provided references that describe Sextant as an Ariane *5*
: subcontractor, as well as part of Ariane 4?
[snip]

I've enjoyed following the Ariane 5 discussion as a long time student
of project failures (hoping to learn from and avoid repeating them on
my projects).

While I know nothing of this failure except what I've read here and on
your and other web pages (thanks for providing yours), I have
certainly seen the budget shifting tactics that Robert speaks of.

Given that everyone seems to agree that Ariane 5 was in budget trouble,
I suspect that what Robert says is probably true _and_ there will
probably NOT be the kind of documentation you request. Since the whole
purpose of that kind of budget game playing is to avoid being obvious
about what is really going on (in this case paying for for Ariane 5's
new IRS on Ariane 4's budget) I doubt the documentation will be very
obvious in this area.

Unfortunately Ariane 5 is not the only project that suffered fatal
flaws that can be pretty directly attributed to a shortage of money.

Steve

-- 
----------------------------------------------------------------------
                Steve Whalen     swhalen@netcom.com
----------------------------------------------------------------------

Re: Interresting thread in comp.lang.eiffel

[David Gillon]

"Robert I. Eachus" wrote:

> > The gains changed abruptly when the aircraft transitioned from
> > takeoff-and-landing to up-and-away mode. This produced a sudden transient,
> > triggering the start of the PIO. The transition now occurs more gradually.
> 
>    That fixes the primary cause, but not the actual failure mode.  Does
> the stick now
> have tactile feedback?  Or has the rate limit on the stabilator been
> changed?  (Yes,
> avoiding sudden non-pilot-induced control inputs is a very good thing.
> But tactile
> feedback, such as stick shakers for stall warnings have the great
> advantage of
> focusing the pilot on where the action is needed.

Tactile feedback from the stick isn't the problem here, it's the rate at
which the feedback loop functions. Even without the stick moving the
pilot is getting sensory feedback from his inner ear and visual cues.
However by the time he's responded the aircraft is already into the
wrong part of the cycle and his actions exacerbate the situation. You
need to change the control laws, not the pilot/aircraft interface. 

-- 

David Gillon

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Marin D. Condic <mcondic-nospam@acm.com> wrote:
>
> It doesn't
> seem to me to be very useful to use Ariane 5 to hawk DbC/Eiffel when
> virtually any other methodology or technology could make the exact
> same claim.

I fully agree, and I don't agree with the Meyer/Jezequel article at all.

My personal claim is at a different angle: I think that DbC would have
saved the day (just like any other method) but without requiring extra
effort (unlike any of the methods that have been proposed in the report,
which all require some extra effort).
I say "no extra effort" because DbC contracts replace a lot of
documentation.

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Marin D. Condic]

Joachim Durchholz wrote:
> My personal claim is at a different angle: I think that DbC would have
> saved the day (just like any other method) but without requiring extra
> effort (unlike any of the methods that have been proposed in the report,
> which all require some extra effort).
> I say "no extra effort" because DbC contracts replace a lot of
> documentation.
> 
Maybe some consensus is beginning to form? :-)

I imagine that DbC is a perfectly fine methodology and probably can be
very helpful in finding problems when considering the reuse of software.
I have absolutely no grief with that. I just found the claim that
DbC/Eiffel would have prevented Ariane 5 from happening to be an
unsupportable claim. Or at least a claim that didn't amount to much. My
understanding of the disaster was that it was caused basically by a
management failure. They never bothered to look. Had they looked, they'd
have found it. When you don't look, any software, documentation,
methodology, etc. won't help.

I feel sorry for the poor bastard who failed to make the decision to
verify the system against the new flight profile, but it was
fundamentally this decision - and not the fault of the software itself
or any methodology surrounding it - that was to blame.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Ken Garlington <Ken.Garlington@computer.org> wrote:
> "Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote:
> > Ken, you're getting unfair.
>
> When you're talking about killing people, or destroying millions of
> dollars worth of property, there is no such thing as "unfair."

This is bullshit. Sorry if I sound harsh, but what you're writing here
is totally unwarranted.

Of course it's important to get such systems right; not incidentally,
the Meyer report uses the term "$500 million dollar mistake" to get the
relevance of the topic properly outlined. But I haven't seen anybody
deny this point, so this aspect (while important) is not the topic of
this debate.

What we're discussing here is whether DbC would have helped or not, how
DbC works at all, and what the cost of using DbC would have been. I
don't see how waving with ethical or financial implications helps us to
find out any of these points.

-Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8kl1lu$2qk4k$1@ID-9852.news.cis.dfn.de...
> What we're discussing here is whether DbC would have helped or not, how
> DbC works at all, and what the cost of using DbC would have been. I
> don't see how waving with ethical or financial implications helps us to
> find out any of these points.

Because that's part of the real-world business environment... and some
aspects of that real-world business environment have some profound
implications for the ability of DbC to work in this context (e.g. having
transparent access to all data related to the module's expected operating
environment).

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Ken Garlington <Ken.Garlington@computer.org> wrote:
> "Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote:
> > In other words: had DbC been applied not only to the software but
also
> > the the software-IRS interface,
>
> What do you mean by a software-IRS interface?

The IRS is a piece of hardware from the point of view of the main
controlling software of the Ariane, right?

> And why is this interface relevant to the Ariane 5 disaster?

The system crashed because the IRS flooded that interface with
meaningless data, right?

-Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Marin D. Condic]

Joachim Durchholz wrote:
> The IRS is a piece of hardware from the point of view of the main
> controlling software of the Ariane, right?
> 
No. The IRS was a pair of MilStd1750a computers that received inputs
from sensors along hardware interfaces. The software in question was
running on both computers. When the software encountered the fault in
question, its behavior was to shut down and transfer control to the
other channel. Because both computers were running identical software,
they both shut down. The IRS was being viewed as an "off the shelf"
part, similar to how you might view an electronic fuel injection
computer purchased for your car. An analogy would be if you took an EFI
computer built for a Dodge Neon and mounted it in a Mack truck without
ever testing it in the Mack truck application to see if it would work.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8kl25k$2q7k0$1@ID-9852.news.cis.dfn.de...
> Ken Garlington <Ken.Garlington@computer.org> wrote:
> > "Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote:
> > > In other words: had DbC been applied not only to the software but
> also
> > > the the software-IRS interface,
> >
> > What do you mean by a software-IRS interface?
>
> The IRS is a piece of hardware from the point of view of the main
> controlling software of the Ariane, right?
>
> > And why is this interface relevant to the Ariane 5 disaster?
>
> The system crashed because the IRS flooded that interface with
> meaningless data, right?

Going back to your original statement, which was:

> In other words: had DbC been applied not only to the software but also
> the the software-IRS interface, then the programmer doing the
> integration would have seen the contract and would have had a chance to
> see the inconsistency between IRS specification and flight trajectory
> data.

Assuming that the IRS-side contract would have been with respect to range,
as in:

-- the contract from the IRS side
IRS_write_value (horizontal_bias: INTEGER) is
      require
         horizontal_bias <= 32767
      do
         ...

      ensure
         written_value <= 32767

      end

and given what the OBC would expect, as in:

OBC_read_value (void) return INTEGER is
  require
  do
     ...
  ensure
       read_value <= 32767
  end

This certainly wouldn't denote any inconsistency as far as I can tell,
particularly since on a MIL-STD-1553 bus it's physically impossible to
violate this contract!

So, once again, you can't simply assert the magic of DbC in the context of
Ariane 5. You have to (for a start) give a specific contract that would have
made it clear that there was a problem. After all: "the official report is
clear and detailed enough to enable software professionals, aerospace
experts or not, to form their own judgment."

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Ken Garlington <Ken.Garlington@computer.org>:
> Assuming that the IRS-side contract would have been with respect to
range,
> as in:
>
> -- the contract from the IRS side
> IRS_write_value (horizontal_bias: INTEGER) is
>       require
>          horizontal_bias <= 32767
>       do
>          ...
>
>       ensure
>          written_value <= 32767
>
>       end
>
> and given what the OBC would expect, as in:
>
> OBC_read_value (void) return INTEGER is
>   require
>   do
>      ...
>   ensure
>        read_value <= 32767
>   end
>
> This certainly wouldn't denote any inconsistency as far as I can tell,
> particularly since on a MIL-STD-1553 bus it's physically impossible to
> violate this contract!

You obviously didn't read (or didn't understand) what I wrote about
modelling the physical world.

It's dead simple: If physical parameters (like a horizontal bias) enter
into the specifications, they must be modelled. Assertion modelling need
not restrict itself to statements on values inside a program, so in the
end you'll get a contract like

  OBC_read_value: INTEGER is
  require
    physical_reality.rocket.horizontal_bias <= some_maximum_value
  ensure
    read_value <= 32767
  end

This is very different from what you write, and clearly spells out what
the parameters are.


This is my last post on this issue. I have just been crossed by Mr.
Meyer and don't wish to defend his thinking in public anymore.

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8kt18p$36aor$1@ID-9852.news.cis.dfn.de...
> It's dead simple: If physical parameters (like a horizontal bias) enter
> into the specifications, they must be modelled.

See, you're already in trouble. Horizonal bias is not a "physical
parameter", in this case. It's an _output_ of the SRI, derived from physical
measurements of the environment, not an input. From the OBC (the flight
control) side, it's a value coming in from a different system, via a bus. If
it's scaled, then range checks are ineffective (as I noted in another post).

> Assertion modelling need
> not restrict itself to statements on values inside a program, so in the
> end you'll get a contract like
>
>   OBC_read_value: INTEGER is
>   require
>     physical_reality.rocket.horizontal_bias <= some_maximum_value
>   ensure
>     read_value <= 32767
>   end
>
> This is very different from what you write, and clearly spells out what
> the parameters are.

It's not clear how you are treating
"physical_reality.rocket.horizontal_bias" here. Is it an input to
OBC_read_value? It shouldn't be, since the purpose of OBC_read_value is to
get this parameter off the bus. So, this makes no sense. Are you saying that
this is an output of OBC_read_value (or a mapping to a memory-mapped
variable)? This is correct, although I thought that the "ensure" statement
was the one that was enforced as a post-condition, whereas "require" was a
precondition. If "require" statements are enforced on output (or on access
to memory-mapped values), then the only problem is that "some_maximum_value"
is ALWAYS 32,767. That's what scaling does: It converts floating-point
numbers to a scaled integer value, typically using the maximum precision
available (that is, the smallest floating point number expected is converted
to -32,768, and the largest expected value is converted to 32,767, at least
for a 16-bit bus as in the case of Ariane 5). Therefore, all your "require"
or "ensure" contract says is that the bus is a 16-bit bus. This is useful if
the architecture changes, and the bus grows (or shinks, although this is
unlikely) in bit width. However, it has absolutely no utility in checking
individual bus parameters. In other words, your contracts will always pass,
so long as the bus stays the same.

If scaling were not used, then your contract would potentially have more
value. However, if scaling weren't used, then the specific error encountered
by the SRI would have been avoided. The SRI was in the act of scaling
horizonal_bias to put it on the bus when the overflow occured. (The word
"expected" in the paragraph above is key to understanding the problem.)

Perhaps if you posted something a little less vague, such as an Ethernet
device driver written in Eiffel, I might be able to see the utility of your
approach...

> This is my last post on this issue. I have just been crossed by Mr.
> Meyer and don't wish to defend his thinking in public anymore.
>
> Regards,
> Joachim

OK, although I would hope that you're defending *your own* thinking as a
rule...

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Ken Garlington <Ken.Garlington@computer.org> wrote:
> "Joachim Durchholz" wrote:
> > It's dead simple: If physical parameters (like a horizontal bias)
> > enter into the specifications, they must be modelled.
>
> See, you're already in trouble. Horizonal bias is not a "physical
> parameter", in this case. It's an _output_ of the SRI, derived from
> physical measurements of the environment, not an input.

Arrrgh... do you *ever* read what I say elsewhere, or do I have to
reiterate the *full* reasoning whenever I deal with you?

I assume that the horizontal bias is a physical property, measured by
the IRS and returned by the IRS.
In that case, the IRS has a contract that relates physical bias and
measured bias. (If the IRS has just paper specifications, it's easy
enough to translate them to contracts.)
The general flight control software somewhere, in some way, retrieves
the measured bias from the IRS. Or the IRS spontaneously sends its data,
then there's an interrupt routine that will receive that data. In any
case, there is some software that uses this data; and the programmer of
that line will very likely see the contract. He will also enter this
contract into the contract of the software that he, in turn, is writing,
so the contract will percolate up the software layers, until it is seen
by somebody at a high level who *also* knows the Ariane-5 trajectories.
*If* that high-level programmer looks at the details of these contracts,
*then* the problem would have been detected.

That's a lot of ifs, though none of them is unreasonable given the care
that obviously was general in the Ariane project. That's the reason why
I say that assertions would have helped to detect the inconsistency,
instead of that they would have automatically detected them

> From the OBC (the flight
> control) side, it's a value coming in from a different system, via a
> bus. If it's scaled, then range checks are ineffective (as I noted
> in another post).
>
> > Assertion modelling need
> > not restrict itself to statements on values inside a program, so in
> > the end you'll get a contract like
> >
> >   OBC_read_value: INTEGER is
> >   require
> >     physical_reality.rocket.horizontal_bias <= some_maximum_value
> >   ensure
> >     read_value <= 32767
> >   end
> >
> > This is very different from what you write, and clearly spells out
> > what the parameters are.
>
> It's not clear how you are treating
> "physical_reality.rocket.horizontal_bias" here. Is it an input to
> OBC_read_value?

No. It's physical reality. Or, rather, the specification of physical
reality.
Not computable (except if you program a simulation - and it's a good
idea to have a physical_reality feature with contracts if you ever want
to write a simulation, this would ensure that the simulation and the
flight control software use the same assumptions).

> Perhaps if you posted something a little less vague, such as an
> Ethernet device driver written in Eiffel, I might be able to see
> the utility of your approach...

Adding assertions is work that's proportional to the code size, and
frankly I have spent much more time on this issue than I care.
So, please stop coming forth with proposals how to spend my free time. I
know full well what I can do in it.

> > This is my last post on this issue. I have just been crossed by Mr.
> > Meyer and don't wish to defend his thinking in public anymore.
>
> OK, although I would hope that you're defending *your own* thinking
> as a rule...

Done.
Though I'm not going to spend more time to convince you. You're one
unusually locked-in individual - I see more interest in tearing down the
ideas of others than in evaluating these ideas for their usefulness. (I
also see an above-average ability to express your own ideas, which is
why I've been taking the time, but the effort-to-effect ratio has been
degrading, and I don't wish to bore the audience with repetitions to get
the points across.)

-Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8l4u3s$3nvvm$1@ID-9852.news.cis.dfn.de...
> Ken Garlington <Ken.Garlington@computer.org> wrote:
> > See, you're already in trouble. Horizonal bias is not a "physical
> > parameter", in this case. It's an _output_ of the SRI, derived from
> > physical measurements of the environment, not an input.
>
> Arrrgh... do you *ever* read what I say elsewhere, or do I have to
> reiterate the *full* reasoning whenever I deal with you?
>
> I assume that the horizontal bias is a physical property, measured by
> the IRS and returned by the IRS.

Arrrgh... again, you assume wrong. Horizonal bias is not a "physical
property", in this case. It's an _output_ of the SRI, *derived* from
physical measurements of the environment, not an input. It's related to the
inputs measured by the IRS (as are most outputs), but it's not a "physical
property" like (for example) roll rate.

> In that case, the IRS has a contract that relates physical bias and
> measured bias. (If the IRS has just paper specifications, it's easy
> enough to translate them to contracts.)

Unfortunately, it's not necessarily a simple relationship between the system
inputs and outputs such as horizonal bias, so it's unlikely that a simple
contract could be written in the form you want. It's usually a complex
series of calculations, lookups to correction tables, etc.

More to the point, the *abstract* relationship between the inputs and the
output (horizontal bias) *prior to scaling* was not violated in the Ariane
5.

The relationship between the values achievable for horizontal bias (produced
by the abstract relationship between inputs and outputs), and those that
could be accepted for conversion (scaling) prior to transmission on the
output communications bus, *was* violated.

> The general flight control software somewhere, in some way, retrieves
> the measured bias from the IRS. Or the IRS spontaneously sends its data,
> then there's an interrupt routine that will receive that data. In any
> case, there is some software that uses this data; and the programmer of
> that line will very likely see the contract.

Actually, it's reasonably unlikely that the OBC (general flight control
software) programmer would see the IRS source code. Of the various flight
control programs I'm familiar with  (F-16, F-111, A-12, F-22, JSF, T-50),
I've never seen a FLCS programmer ask for IRS source code. I have looked at
IRS (and FLCS) source code as part of other activities (IIV&V, etc.) but
never as part of software programming.

What the OBC programmer would likely have been given is an Interface Control
Document (a.k.a. Interface Requirements Specification, Interface Design
Document, etc.). This document would describe the messages on the
communications bus -- the senders, receivers, etc. For the IRS, he would
likely have been given a description that says (roughly):

"The horizontal bias parameter is a scaled value in the range -32768 ..
32767 (one bus word). -32768 is mapped to -5.0, and 32767 is mapped to 3.0."

He would then write a routine to take the integer value and "un-scale" it
appropriately. As mentioned previously, this definition guarantees that you
will never get an out-of-range value (say, 3.5), since there's no way to put
a value greater than 32767 (or less than -32768) in a 16-bit quantity.
However, this approach also makes it useless to do traditional range-based
contracts.

However, let's say for the sake of argument that the OBC programmer looked
at the IRS source code. What would he have seen in the output routine? A
contract that would have said: "require horizontal_bias_prescaled >= -5.0
and horizontal_bias_prescaled <= 3.0". He would have said, "Yep, that's what
my interface document says: the value will represent the range -5.0 .. 3.0,
before it's scaled." The fact that the IRS -- *prior* to the output
routine -- was capable of generating a value outside the range would
probably be overlooked by the OBC programmer, since he doesn't have enough
of a background to know how the IRS computes horizontal bias.

> He will also enter this
> contract into the contract of the software that he, in turn, is writing,
> so the contract will percolate up the software layers, until it is seen
> by somebody at a high level who *also* knows the Ariane-5 trajectories.

Well, we'll have to agree to disagree on this point. I've given specific
examples in my paper and elsewhere as to why this is untrue -- the
aeronautical engineers and managers at the prime would likely neither want
to examine a vendor's source code, nor have the resources to do so if they
did want to. I've never heard a counter-argument advanced for why your
assumption should be considered valid for a project like Ariane 5.

> *If* that high-level programmer looks at the details of these contracts,
> *then* the problem would have been detected.

You seem to believe that these projects are staffed homogenously by
programmers. I obviously can't convince you that there is a world outside of
software engineering on projects such as Ariane 5, so we'll just have to
agree to disagree on this presumption as well. (Said more explicitly - the
guy you describe ain't there.)

But let's go with your thesis that he exists. He looks at the IRS side, and
sees a contract that maps -3.0 to -32768 and 5.0 to 32767. He looks at the
OBC side, and sees a contract that maps -32768 to -3.0 and 32767 to 5.0.
What problem has he just detected? I must not be a sufficiently "high-level"
(acolyte?) programmer, because it looks OK to me!

Again, he would have to have three things to detect the problem by analysis:

(1) The actual flight profile
(2) An understanding of the (non-trivial) relationship between the profile
and a value like horizontal bias
(3) An understanding of the (much simpler) relationship between the
calculated (floating-point) value for horizontal bias and the value expected
by the scaling routine.

As you saw when you looked at the YF-22 profile, that #2 is a toughie for
someone who's not an expert in the particular domain of interest (inertial
measurements). However, if he's an expert, he's probably not also a
"high-level programmer" looking at the IRS, OBC, propulsion system...

On the other hand, you don't necessarily have to have #2 or #3 (or at least,
not a deep understanding of them) if you feed the values from #1 into the
actual IRS. At least with respect to detecting gross failures of the type in
Ariane 5, *testing* the unit (as opposed to analyzing the unit) can be
simpler. I know several projects where these sort of integrated system tests
are done successfully without any detailed examination of the source by the
test team. In test theory, these are called "black box" tests, and they can
be quite powerful, particularly for detecting these sort of
integration-class faults. They are particularly effective when supplemented
by "white-box" analyses and tests that look for internal *inconsistencies*.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8kl25k$2q7k0$1@ID-9852.news.cis.dfn.de...
> Ken Garlington <Ken.Garlington@computer.org> wrote:
> > "Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote:
> > > In other words: had DbC been applied not only to the software but
> also
> > > the the software-IRS interface,
> >
> > What do you mean by a software-IRS interface?
>
> The IRS is a piece of hardware from the point of view of the main
> controlling software of the Ariane, right?

If by "main controlling software" you mean the software in the On-Board
Computer (the flight control computer, in my parlance), the IRS is a bit
stream coming over a bus. If you're talking about the OBC detecting the
invalid data that happened as a consequence of both IRSs going off-line,
here are the likely contracts and their weaknesses:

1. Range check - As I note in my paper, this is typically a poor type of
check for bus related data if the data is scaled. In other words, all
possible bit patterns are in range.

2. Delta check - You can look to see if the value changes within a small
time period at a much faster rate than physically possible. Sometimes works,
but is prone to false alarms and is only valid in a statistical sense (a
failure can easily generate a value that passes a delta check).

2. Redundant data comparison - The data from the active SRI could be
compared with the hot standby SRI. If the data was different, you'd know
there was a problem. This works well to isolate hardware errors (since two
like devices rarely fail simultaneously, at least that's the usual
assumption). However, if there's a common-mode failure (like in this case,
with software), the data is wrong from both sources and this kind of
contract can easily fail.

3. Comparison with unlike data source: We do this with fighter aircraft by
doing sanity checks of IRS data with information derived from air data
sensors, for example. Air data sensors aren't quite as feasible with
rockets, however (something to do with vacuum :). In addition, of course,
you get to pay for the extra hardware.

4. Comparison with internal model: You can write a predictive model that
generates a rough estimate of the correct value, and use that as a sanity
check of the input over time. It sorta works for mechanical devices such as
actuators; I've never seen something like that work for an inertial system.

The right answer, of course, would be for the SRI to set a bit saying it was
off-line. Why this wasn't part of the spec, I don't know, unless they
thought it was useless (see below). This wouldn't require a contract to use.

So, unless you post a _real example_ of how a contact would have helped in
this case, I remain skeptical.

Of course, this may be a moot point. If you're going to wait to detect the
error when it reaches the OBC, you've still got a problem. Now that the OBC
knows it is receiving no data regarding the actual course of the rocket,
what does it do? A slightly-inaccurate, but potentially illuminating example
is: Suppose you're driving your car in rush-hour traffic, and someone
suddenly throws black paint on the windshield, and all the windows. Putting
aside such obvious fixes as breaking or rolling down a window (in other
words, using an alternate sensor), what do you do? You could jam on the
brakes (which a rocket or airplane can't do, unfortunately), or you could
take your last known information and try to guess how to turn the wheel  so
that you get to the shoulder safely (what I usually call standby gains). I
don't know how successful that is with a rocket; it works OK with an
airplane, but it's a much more benign environment.

Re: Interresting thread in comp.lang.eiffel

[Marin D. Condic]

Ken Garlington wrote:
> is: Suppose you're driving your car in rush-hour traffic, and someone
> suddenly throws black paint on the windshield, and all the windows. Putting
> aside such obvious fixes as breaking or rolling down a window (in other
> words, using an alternate sensor), what do you do? You could jam on the
> brakes (which a rocket or airplane can't do, unfortunately), or you could
> take your last known information and try to guess how to turn the wheel  so
> that you get to the shoulder safely (what I usually call standby gains). I
> don't know how successful that is with a rocket; it works OK with an
> airplane, but it's a much more benign environment.

A common FDA strategy for such a situation would be to go fail-fixed.
You hold everything exactly where it is at with the hope that the
sensors will come back on-line before disaster happens. If you're in the
middle of a burn, you keep burning. In the middle of a coast - keep
coasting. If you're in the middle of a transient - you're screwed!

With rockets, the strategy is quite often to do your very best to
continue to press on with the mission as best you can, because
everything else is a total loss. There's no such thing as having the
pilot limp the vehicle on back to the base and let the maintenance guys
take a look at it.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Marin D. Condic" <mcondic-nospam@acm.com> wrote in message
news:396F13B6.9216FFE4@acm.com...
> Ken Garlington wrote:
> > is: Suppose you're driving your car in rush-hour traffic, and someone
> > suddenly throws black paint on the windshield, and all the windows.
Putting
> > aside such obvious fixes as breaking or rolling down a window (in other
> > words, using an alternate sensor), what do you do? You could jam on the
> > brakes (which a rocket or airplane can't do, unfortunately), or you
could
> > take your last known information and try to guess how to turn the wheel
so
> > that you get to the shoulder safely (what I usually call standby gains).
I
> > don't know how successful that is with a rocket; it works OK with an
> > airplane, but it's a much more benign environment.
>
> A common FDA strategy for such a situation would be to go fail-fixed.
> You hold everything exactly where it is at with the hope that the
> sensors will come back on-line before disaster happens. If you're in the
> middle of a burn, you keep burning. In the middle of a coast - keep
> coasting. If you're in the middle of a transient - you're screwed!

Right - it's what a flight control engineer would call "standby" (or fixed)
gains.

> With rockets, the strategy is quite often to do your very best to
> continue to press on with the mission as best you can, because
> everything else is a total loss. There's no such thing as having the
> pilot limp the vehicle on back to the base and let the maintenance guys
> take a look at it.

Exactly. However, I assume your chances of mission success are far from
assured. A much better strategy is to fix the problem at the source -- in
this case, the IRS.

Re: Interresting thread in comp.lang.eiffel

[David K Allen]

Riddle:
    When is a contract not a contract?
Answer:
    When they are two different words representing different concepts but
spelled and/or sounding the same (homonyms).
-----------------------------------------
"Ken Garlington" wrote in separate posts

> Wouldn't both sides have to agree to this contract for it to be legally
> valid?

> You understand, of course, that standard contracts are in fact negotiated?

I think, as Bertrand said earlier, that you two were talking on different
wavelengths.
He was talking "Design By Contract (DBC)" a formal method for designing
reliability into software to faciliate reuse.  It is a method which he knows
very well.
Based on the comments you made above, you were talking business contracts,
which you apparently know very well.
Your remarks are important in the context of business contracts, but they
are confusing in the context of "Design By Contract."
Please don't let the fact that "contract" is used as a metaphor in DBC
confuse you with the true meaning of the method.
Like all metaphors, it simply helps you get started, and adds a certain
flavor to the concepts it describes.  But the concept itself can only be
judged if you understand it accurately.

I certainly welcome your criticism of DBC. You are obviously a clear and
critical thinker with considerable experience in software development.  But
it will be more productive if you base your criticisms on what DBC really is
about rather than what you think it might be.
Instead of reacting to our attempts to explain DBC to you, one piece at a
time, perhaps it will be more useful for you if you read a clear
introduction to DBC which explains what it is really about.
http://www.eiffel.com/doc/manuals/technology/contract/page.html.
Others have tried to explain it, but you counter with examples like those
above which tell me you are criticizing DBC based on the mistaken notion
that it is supposed to perfectly model a business contract.

I can understand the confusion - especially in the context of the Ariane
disaster.  Because, in fact, there are issues of both kinds involved in this
situation.
There is a role for a discussion of "Design By Contract" as Dr. Meyer has
developed it, with the precise meanings of that method.
Then there is also a role for discussing how to design software in the
context of business contracts among multiple contractors and subcontractors
where a conglomerate of different nations are the project sponsors (yikes
what a tough deal!).  Although they can have some relationship, they are not
the same thing.

Applying business principles to the software engineering "Design By
Contract" will not really help much.
Conversely, trying to apply Dr. Meyer's software engineering principles to
the socio-political issues will not help either.
They are two different domains with different principles and techniques.

But the point is that if DBC were a component of the software development
method used to build Ariane, then any attempts to reuse software from a
previous project would force the issue that the new project teams MUST HAVE
the specifications of any modules they intend to reuse.   If that had been
part of the software develoment culture, then the subcontractor would have
required the additional information and the contractor would have gladly
complied and provided it.  This would have reduced, though not eliminated
the "art of guessing how much a contractor must provide to a subcontractor"
which you described earlier.
--
Best Wishes,
David Kreth Allen
Software Consultant
Minneapolis, Minnesota - USA

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"David K Allen" <dkallen@visi.com> wrote in message
news:qe_a5.259$6E.64803@ptah.visi.com...
> I think, as Bertrand said earlier, that you two were talking on different
> wavelengths.
> He was talking "Design By Contract (DBC)" a formal method for designing
> reliability into software to faciliate reuse.  It is a method which he
knows
> very well.
> Based on the comments you made above, you were talking business contracts,
> which you apparently know very well.

Actually, I was talking about the use of code constructs (DbC contracts) as
part of a binding relationship between parties (business contracts). The
words you elided mention this. A previous poster said that DbC contracts
represented a committment between the developer and the reuser. My question
had to do with the seriousness and dependability of that "committment."

> I certainly welcome your criticism of DBC. You are obviously a clear and
> critical thinker with considerable experience in software development.
But
> it will be more productive if you base your criticisms on what DBC really
is
> about rather than what you think it might be.
> Instead of reacting to our attempts to explain DBC to you, one piece at a
> time, perhaps it will be more useful for you if you read a clear
> introduction to DBC which explains what it is really about.
> http://www.eiffel.com/doc/manuals/technology/contract/page.html.

Actually, I have read this. I am also familiar with, and/or have used, other
examples of similar/related approaches: Ada (and GNAT assertions), SPARK,
T-VEC -- and, today, OBLOG (where the contracts are called "quarks").

> Others have tried to explain it, but you counter with examples like those
> above which tell me you are criticizing DBC based on the mistaken notion
> that it is supposed to perfectly model a business contract.

Not at all - I am responding to the suggestion that it is useful to use
constructs written at the level of detail inherent in source code as part of
the process of specifying the requirements of a system between customer and
vendor. These issues are discussed further at

http://www.flash.net/~kennieg/ariane.html

along with a more comprehensive set of issues related to DbC -- specifically
with respect to Ariane 5, by the way.

> Applying business principles to the software engineering "Design By
> Contract" will not really help much.
> Conversely, trying to apply Dr. Meyer's software engineering principles to
> the socio-political issues will not help either.
> They are two different domains with different principles and techniques.

Couldn't agree more.

> But the point is that if DBC were a component of the software development
> method used to build Ariane, then any attempts to reuse software from a
> previous project would force the issue that the new project teams MUST
HAVE
> the specifications of any modules they intend to reuse.

Couldn't *disagree* more (with respect to Ariane 5). The reason, in part, is
because of another homonym you mention - "specification". That term, used in
the sense of traditional acquisitions, means something very different than
it does in DbC. You need both types of specifications to do the required
analysis/test correctly. A "hole" in the procurement specification is not
necessarily revealed by the DbC specification, particularly if the implicit
assumption is that the procurement specification identifies what has changed
from the previous procurement. Information at the source code level of
detail is rarely seen by those who write the procurement specification, so
it will not address their issues. Those who write the source code --
particularly in the context of an element like an IRS -- rarely have
sufficient experience and insight to detect potential system-level
subtleties like the one that was missed in the Ariane 5 program.

I note that this "force the issue" aspect of the DbC argument -- despite the
arguments I provide to rebut it -- tends to be accepted as an article of
faith, accompanied by various personal testamonials (rarely in the context
of an Ariane 5-style environment). Frankly, I almost feel like shouting
"Amen!" I would be much more accepting of this "leap of faith" if it were
accompanied by examples relevant to Ariane 5.

It keeps getting ignored (I suspect because the question can't be answered),
but I'll post this example again. The DbC specification for a module is
given below. I feel fairly confident that this is considered a good quality
example by at least one acknowledged Eiffel/DbC expert.

   convert (horizontal_bias: INTEGER): INTEGER is
      require
         horizontal_bias <= Maximum_bias

If, as you say, this would cause the project team to go get information they
did not already have, then explain what information it would require and
why.

(My analysis of this DbC specification is in the link noted above).


>  If that had been
> part of the software develoment culture, then the subcontractor would have
> required the additional information and the contractor would have gladly
> complied and provided it.

Again, couldn't disagree more.

> This would have reduced, though not eliminated
> the "art of guessing how much a contractor must provide to a
subcontractor"
> which you described earlier.

Not in the context of Ariane 5.  As people on both sides of the issue agree,
Eiffel/DbC is neither necessary nor sufficient to address an Ariane 5-class
failure.

Re: Interresting thread in comp.lang.eiffel

[David K Allen]

"Ken Garlington" wrote
that the Ariane 5 business environment is very different from what I am
assuming, so that the spirit of easy sharing of information  could not have
worked as I suggested.
You may be right. I read some more of your articles on this.
Now that I think about it, the kind of situation you describe is beyond my
experience.
I think I'll stick to small business systems. The social and political
environment is much simpler by comparison <grin>.

I can now see why you reacted to the claim that DBC would have prevented the
disaster.
That is way too simplistic.
But I still think DBC would have helped.  That is all I was trying to say.
I only know what my own experience shows.
I would not claim it would have been the silver bullet.   But it sure has
been useful for me
Oh, and I'll take a stab at that horizontal bias example in another
response.

--
Best Wishes,
David Kreth Allen
Software Consultant
Minneapolis, Minnesota - USA

Re: Interresting thread in comp.lang.eiffel

[David K Allen]

"Ken Garlington"  wrote
> It keeps getting ignored (I suspect because the question can't be
answered),
> but I'll post this example again. The DbC specification for a module is
> given below. I feel fairly confident that this is considered a good
quality
> example by at least one acknowledged Eiffel/DbC expert.

    ;)

>
>    convert (horizontal_bias: INTEGER): INTEGER is
>       require
>          horizontal_bias <= Maximum_bias
>
> If, as you say, this would cause the project team to go get information
they
> did not already have, then explain what information it would require and
> why.
>
> (My analysis of this DbC specification is in the link noted above).

First, I don't think the  authors intended that this one function would have
prevented the entire disaster.
If they meant that, then I must join you in your critique.
I think they were trying to give an illustration that would convey the
approach of DBC in the context of the disaster. But I can see you were not
impressed <grin>.

Second, as you point out in your critique, the error occurred prior to where
this function would have been used (conversion from FP to Integer).  But  if
you accept my previous remark, then that is not the point of their example.
I admit they chose poorly if they were intending to persuade you, who have
such a command of the details.
But for conversation sake,  and to illustrate the usefullness of DBC, let's
assume that the flaw occured within 'convert' above.  Otherwise, I can't
help you see how DBC helps me think and work.

When I am writing a routine that uses a function (like 'convert'), and I see
a precondition (like hb <= Mb), I say to myself:
"As the client (user) of the routine, I better be prepared to honor its
preconditions or I risk failure."
So I take either of two approaches in such a case. I either choose to test
the precondition myself, before calling 'convert', or I choose to ignore it,
and assume that an error MAY occur in the precondition, and I prepare to
trap the exception that may result and handle the failure.
That is a style point for systems where reliability is important.
But this seeems equivalent in my mind to "protecting the variables."
And the inquiry noted (your footnote (6))

    "It is important to note that the decision to protect certain variables
but not others was taken jointly by project partners at several contractual
levels"

Yes, I know - the reason for this jointly agreed decision was cited as
maintaining CPU performance. My only claim is that if DBC were part of the
coding culture, it would have been less likely that that decision would have
been "jointly" agreed to.  If I were working on high-risk stuff with a team
of others trained in DBC, I can't see that we would reach a consensus to
ignore the warning of a precondition.  It just would not be done without
management overriding us.

Without the DBC guidelines or something equally simple and easy to
understand, I fear that such decisions simply degenerate into very fuzzy
gut-level (is it good enough) decisions.  Although all devleopment
ultimately has that anyway.  I really believe that DBC might have tipped the
balance.

Most importantly, in the practical world in which we work and live, I
consider DBC to be easy to understand and powerful at the same time.
Perhaps the language of the original authors you criticize was too bold or
propgandistic for your taste.
But I'm glad it struck you that way.  I learned more about why I like DBC by
reading your criticisms;)
As I read the inquiry, it strikes me how a team that practices DBC routinely
would have probably made different choices.
But I agree that there were a host of other issues, and DBC alone would not
rescue things.
--
Best Wishes,
David Kreth Allen
Software Consultant
Minneapolis, Minnesota - USA

Re: Interresting thread in comp.lang.eiffel

[Howard W. LUDWIG]

David K Allen wrote:

> [snip]
>
> When I am writing a routine that uses a function (like 'convert'), and I see
> a precondition (like hb <= Mb), I say to myself:
> "As the client (user) of the routine, I better be prepared to honor its
> preconditions or I risk failure."
> So I take either of two approaches in such a case. I either choose to test
> the precondition myself, before calling 'convert', or I choose to ignore it,
> and assume that an error MAY occur in the precondition, and I prepare to
> trap the exception that may result and handle the failure.
> That is a style point for systems where reliability is important.
> But this seeems equivalent in my mind to "protecting the variables."
> And the inquiry noted (your footnote (6))
>
>     "It is important to note that the decision to protect certain variables
> but not others was taken jointly by project partners at several contractual
> levels"
>
> Yes, I know - the reason for this jointly agreed decision was cited as
> maintaining CPU performance. My only claim is that if DBC were part of the
> coding culture, it would have been less likely that that decision would have
> been "jointly" agreed to.  If I were working on high-risk stuff with a team
> of others trained in DBC, I can't see that we would reach a consensus to
> ignore the warning of a precondition.  It just would not be done without
> management overriding us.

You seem to be _starting_ to understand the true situation in the aerospace
domain, but you still have a ways to go.  In the business applications world,
most of the time you don't really care much about how long some action takes.
If the program spews out an answer in 0.5 s instead of 0.4 s, the user will
hardly notice.  It's not the end of the world if the time is 15 s versus 10 s.
With existing technology trends, if 15 s is too slow, add 128 megabytes of RAM
and wait a month for a computer that has a 100 MHz higher clock rate, or network

in a second computer today, and just plug it all into the nearest wall socket
in your air-conditioned room--no big deal.  In the space environment, you don't
have any such privilege.  In order to survive the wild temperature extremes
(which make the Saharan summer and Siberic winter weather seem comparable and
mild) and high-energy, highly ionized particles (such as from solar flares,
radiation belts, etc.), processors must be hardened.  There is not a lot of
demand world-wide for such processors, so choice and supply are rather limited.
The most common option is a MIL-STD-1750 16-bit architecture processor--they
run quite a bit more slowly than your Pentiums and PowerPCs (by about a factor
of 10 if I recall correctly).  You have very limited space, power, cooling
mechanism, etc.  Weight is at a premium.  From what I remember in the 1970s
(and it should still be close to true), to add a bank of RAM or a processor
of mass m, you have to add 8m of fuel to achieve the same Earth orbit, or take
m away from your payload (which has already been trimmed way down).  Your
processor is running in a hard-real-time environment.  If you fail to provide
updated guidance commands _every_ 0.01s to 0.02 s (can't miss even one time),
you go into a mission-ending oscillation or a hardware lock-up, and there are
lots of matrix calculations that have to be done in that time.  I have worked on

one processor operating on a 3 600 Hz cycle--that means _all_ your computations
must be completely redone and finished every 0.000 278 s; it's fine (in some
sense) if you get done in 0.000 277 s, but it's fatally flawed if it ever takes
0.000 279 s.  Generally, some margin is required, because things can always
go wrong (such as there being a case worse than what you thought was worst,
or there's a little dither because of IO bottlenecks, cache misses, etc.)--
in the case of Ariane 5, what was believed to be worst case must be completed
in at most 80 % of the maximum allowed time.  Such margins are set up rigidly
at the beginning based on undistracted, rational thinking so that when the
real pressure hits and you are eating into the margin, nobody can rationalize
without a clear, unbiased thought process moving to 81 %, 82 %, 83 %, ...
and creeping on up until you've done something really stupid and crash the
whole system.  (In most systems without an outside agency arbitrarily
directing the margin, engineers will come up with an appropriate value
being somewhere in the 70 % to 85 % range, with 80 % being very common.
When the bureaucrats get involved and impose something from the outside,
such as the USA Dept. of Defense, it was common to allow usage of only
50 % of what is available.)  Given the amount of processing that must
be done, the limitations on processor capability, and the hard timing
deadline, it is hard to get the actual required processing done--
never mind any assertion checking.  We go into projects with ideals
like "With this faster, new processor, perhaps we can finally leave
some run-time checking in the code", but the systems engineers almost
always come up with some additional ways to expend the added throughput
on tighter, better (more calculation-intensive) processing requirements,
so at the end we say "Oh, well, life as usual--take out the run-time
checks."  It's not something we want to do--it's just a fact of life
that we grow accustomed to.  If we don't do it, the system won't
work, so it's _not_ a matter of some managerial bureaucrat directing
us to take out the checks over our dead bodies--we are engineers and
want our systems to work and it just plain _won't_ work with the
checks left in.  Over the last three years I have finally started
seeing processor capability grow faster than systems engineers ability
to use it for endoatmospheric applications (for which the hardness of
the processor is not as much of an issue), so throughput is becoming
rapidly less of a problem in many such projects.  Of course, Ariane 501
was 1996 [for production, and even older design] and both endo- and exo-
atmospheric.

As a sidenote, these very tight timing constraints are why hard-real-time
software developers avoid like the plague languages such as Eiffel in
which garbage collection is mandatorily done in a manner that is "transparent"
to the developer.  If you have only 0.5 ms to spare in each processing cycle
and garbage collection comes along and grabs 2 ms at an uncontrollable time
to clean up memory, you've blown your timeline and crashed the rocket.

> Without the DBC guidelines or something equally simple and easy to
> understand, I fear that such decisions simply degenerate into very fuzzy
> gut-level (is it good enough) decisions.  Although all devleopment
> ultimately has that anyway.  I really believe that DBC might have tipped the
> balance.

And when you have 100 assertions available to check, and throughput available
to do at most 12, how do you choose with DbC which 88 to drop?  This is
the kind of decision that the Ariane 501 people had to make, and, based on
all the evidence they had, they dropped the ones they [erroneously] thought
were least at risk.  Problems with getting more evidence across company and
national boundaries when Dilberts and pointy-haired bosses are involved has
already been discussed elsewhere in this thread.

> Most importantly, in the practical world in which we work and live, I
> consider DBC to be easy to understand and powerful at the same time.
> Perhaps the language of the original authors you criticize was too bold or
> propgandistic for your taste.
> But I'm glad it struck you that way.  I learned more about why I like DBC by
> reading your criticisms;)
> As I read the inquiry, it strikes me how a team that practices DBC routinely
> would have probably made different choices.

And what would "practices DBC routinely" mean in the context I described above?
That if management refused to budge, the engineers quit, even though it is
impossible (even just on technical grounds, never mind the political, etc.
grounds--_can't_ violate physics principles) to fully satisfy DbC?  The rocket
needs built anyway.  I am, nevertheless, in full agreement with the notion
that "blind reuse is worse than no reuse" and the Ariane 501 staff did fall
short.  While DbC looks useful in many ways, I just don't see that lack of
its [or Eiffel's] usage on Ariane 501 is the straw that broke the proverbial
camel's back.  I'm glad you have found something that helps you in your
application domain, but one size doesn't fit all.

> But I agree that there were a host of other issues, and DBC alone would not
> rescue things.
> --
> Best Wishes,
> David Kreth Allen
> Software Consultant
> Minneapolis, Minnesota - USA

Howard W. LUDWIG

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Howard W. LUDWIG <howard.w.ludwig@lmco.com> wrote:
>
> The most common option is a MIL-STD-1750 16-bit architecture
processor--they
> run quite a bit more slowly than your Pentiums and PowerPCs (by about
a factor
> of 10 if I recall correctly).

Indeed that fast? <grin>
My last experience was with a 32 MHz 68000 IIRC. (Hardened etc. - this
is *really* an issue. You simply don't get latest-generation hardened
processors from Intel. You'll always get processors that are a few
generations behind, because the unhardened processors are already
pushing the limits of production technology.)

However, DbC doesn't say that you always use run-time checking. DbC is
documentation as well as run-time checks. If you need run-time checking,
use a faster processor for ground testing with assertions switched on,
for example.
If you really need an assertion check that raises an exception, use a
language that can switch checking on and off selectively.

> As a sidenote, these very tight timing constraints are why
hard-real-time
> software developers avoid like the plague languages such as Eiffel in
> which garbage collection is mandatorily done in a manner that is
"transparent"
> to the developer.  If you have only 0.5 ms to spare in each processing
cycle
> and garbage collection comes along and grabs 2 ms at an uncontrollable
time
> to clean up memory, you've blown your timeline and crashed the rocket.

Oh, another GC myth.
Modern garbage collectors don't come along and uncontrollably grab time.
Usually, you run GC whenever there's spare time - modern garbage
collectors run in parallel (in a coroutine-style fashion) with the
application.
Actually automatic garbage collection is more predictable than smart
pointers. Removing the last smart pointer to an object will trigger a
cascade of object deletions, possibly overrunning the deadline. In a GC
environmnt, removing the last pointer will turn the object into garbage
that will be collected at the next opportunity when the system has room
to breathe.

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

I don't believe the run-time efficiency per se is the most compelling
disadvantage for DbC. As Joachim notes, you can always turn it off.

However, turning off the run-time check (or turning it on for part of the
development process, then turning it off for delivery) does have some
adverse consequences, as I note in my paper. It certainly isn't "free" in
the context of Ariane 5.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"David K Allen" <dkallen@visi.com> wrote in message
news:BRab5.418$6E.94216@ptah.visi.com...
> "Ken Garlington"  wrote
> > It keeps getting ignored (I suspect because the question can't be
> answered),
> > but I'll post this example again. The DbC specification for a module is
> > given below. I feel fairly confident that this is considered a good
> quality
> > example by at least one acknowledged Eiffel/DbC expert.
>
>     ;)
>
> >
> >    convert (horizontal_bias: INTEGER): INTEGER is
> >       require
> >          horizontal_bias <= Maximum_bias
> >
> > If, as you say, this would cause the project team to go get information
> they
> > did not already have, then explain what information it would require and
> > why.
> >
> > (My analysis of this DbC specification is in the link noted above).
>
> First, I don't think the  authors intended that this one function would
have
> prevented the entire disaster.
> If they meant that, then I must join you in your critique.
> I think they were trying to give an illustration that would convey the
> approach of DBC in the context of the disaster. But I can see you were not
> impressed <grin>.
>
> Second, as you point out in your critique, the error occurred prior to
where
> this function would have been used (conversion from FP to Integer).  But
if
> you accept my previous remark, then that is not the point of their
example.
> I admit they chose poorly if they were intending to persuade you, who have
> such a command of the details.
> But for conversation sake,  and to illustrate the usefullness of DBC,
let's
> assume that the flaw occured within 'convert' above.  Otherwise, I can't
> help you see how DBC helps me think and work.

As I note in the paper, you can reasonably generate examples where DbC
helps. However, the examples provided to date are not, IMHO, germaine to the
specifics of the Ariane 5 case. Here's an even more interesting aspect:
Given that the author of the proposed contract appears to be showing an
example specific to the Ariane 5 case, and given that he _knew_ a priori
where the error resided, and given that (he claims) the information provided
in the inquiry was sufficient for him to understand the nature of the
problem, he STILL BLEW IT. He failed to write a contract that addressed the
problem. This should give anyone pause as to the ease of establishing such
contracts.

More to the point, I have yet to see anyone write an Eiffel contract that
_does_ address the Ariane 5 example -- particularly in a portable and
readable manner. Again, this is even after we (apparently) fully understand
the conditions we're trying to denote. I'm not claiming that it's
impossible, but I suspect that it will be more complicated than a one-liner
(as the person who posted the "tangent" contract hopefully also discovered
:).

> Yes, I know - the reason for this jointly agreed decision was cited as
> maintaining CPU performance. My only claim is that if DBC were part of the
> coding culture, it would have been less likely that that decision would
have
> been "jointly" agreed to.

However, you have to consider that at least some of the "joint" decisions
(in particular, the extermely critical one regarding the SRI specification)
were quite likely made by personnel that would have been unaware of the
software team's decision to use DbC, much less used those contracts in their
decision making process.

> If I were working on high-risk stuff with a team
> of others trained in DBC, I can't see that we would reach a consensus to
> ignore the warning of a precondition.  It just would not be done without
> management overriding us.

Again, the part of the statement that reads "a team of others trained in
DbC" is critical to the argument. If you are dealing with a software system
on a standard hardware platform, where the domain of interest is mostly
software-specific, this is reasonably likely. However, the SRI environment
(and, more to the point, the rocket environment containing it) is not likely
to meet this criteria.

Re: Interresting thread in comp.lang.eiffel

[Veli-Pekka Nousiainen]

Hi, Ken !

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:vLub5.16107$7%3.987416@news.flash.net...
> As I note in the paper, you can reasonably generate examples where DbC
> helps. However, the examples provided to date are not, IMHO, germaine to
the
> specifics of the Ariane 5 case. Here's an even more interesting aspect:
X
Does this mean that you otherwise consider DbC a superior
methodology - exept that IYHO in this particular case even DbC
would have been: Not Enough !
?
Asks Veli-Pekka

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Veli-Pekka Nousiainen" <vp.nousiainen@lapinlahden-teknologiakeskus.fi>
wrote in message news:vnZc5.209$2y3.8676@read2.inet.fi...
> Hi, Ken !
>
> "Ken Garlington" <Ken.Garlington@computer.org> wrote in message
> news:vLub5.16107$7%3.987416@news.flash.net...
> > As I note in the paper, you can reasonably generate examples where DbC
> > helps. However, the examples provided to date are not, IMHO, germaine to
> the
> > specifics of the Ariane 5 case. Here's an even more interesting aspect:
>
> Does this mean that you otherwise consider DbC a superior
> methodology -

Superior to what? In solving what problem?

(Coincidences abound: My networks prof asked the class last time: "Which is
the superior LAN protocol: Ethernet, token ring, or token bus?" The answer
to that one is the same as the answer to your question!)

> exept that IYHO in this particular case even DbC
> would have been: Not Enough !

Not Enough, and maybe even Not Superior (for this problem).

Re: Interresting thread in comp.lang.eiffel

[Bob Allen]

> Superior to what? In solving what problem?
>
> (Coincidences abound: My networks prof asked the class last time: "Which
is
> the superior LAN protocol: Ethernet, token ring, or token bus?" The answer
> to that one is the same as the answer to your question!)
>
Everyone knows that 10Base2 is the ultimate LAN.  8>}

> > exept that IYHO in this particular case even DbC
> > would have been: Not Enough !
>
> Not Enough, and maybe even Not Superior (for this problem).
>
For any enterprise/multi-enterprise/large scale/non-trivial/etc. system to
be developed with a high level of quality, due diligence must be made to
ensure consistency, understandability, and compatibility.
From my over 12 years experience doing software development on platforms
from the PIC16F84 to
Mainframes to Distributed objects on various UNIX platforms, I have found
that the principles behind
DbC to provide the most stable implementations. The trick is not to
introduce these principles at code time. For maximum effect they need to be
introduced at requirements time and must permeate the entire enterprise
thought processes. NOT JUST SOFTWARE, but a whole way of thinking and
working.
DbC is not magic, it requires a lot of effort on everyone's part. It does
provide you with a set of tools and
if applied with discipline, can produce software of very high quality.
To be used effectively one must have a solid understanding of the problem
domain. The goals need to be clearly stated, and you have to have support
from upper management.
The question is not whether or not software should have contracts, as all
software does. The real question is do you write them down, and to what
degree of formality do you write them down. Do I express them in 'natural
language', pictures, mathematics, or something else.
Please show me a library that does not have some notion of contracts and I
will show you complete chaos. Because if there were no contracts in place,
then any function could be called at any time with any number and type of
parameters, and do anything it wanted to.

Thanks,
Bob Allen
Bob's Weekend Wonders
Training and Consulting

Re: Interresting thread in comp.lang.eiffel

[David Gillon]

David K Allen wrote:

> Applying business principles to the software engineering "Design By
> Contract" will not really help much.
> Conversely, trying to apply Dr. Meyer's software engineering principles to
> the socio-political issues will not help either.
> They are two different domains with different principles and techniques.

Unfortunately, for the type of project we're discussing here the two
uses of contract (requirements and legal) are likely inseperable, so
Ken's arguments are a criticism based on real-world experience of the
argument that DBC would have automatically solved the coordination
issues (which is where we started). In an ideal world (where software
engineers write the rules), maybe, in the real world, with lawyers,
accountants and non-technical managers to be worked around the issue is
much less clear.

> But the point is that if DBC were a component of the software development
> method used to build Ariane, then any attempts to reuse software from a
> previous project would force the issue that the new project teams MUST HAVE
> the specifications of any modules they intend to reuse.   If that had been
> part of the software develoment culture, then the subcontractor would have
> required the additional information and the contractor would have gladly
> complied and provided it.

But the contracts between the companies were at the 'you provide a black
box to meet this requirement' level, far above the level at which
'software development cultures' function. The need for information
exchange for DBC would first have had to be pursued up multiple levels
of the sub-contractor management tree until a level was reached at which
the release of information could be sought, and then on the contractor
side chased back down the tree until someone was found who could explain
what was wanted. Think Dilbert 1 trying to have a technical discussion
with Dilbert 2 by passing verbal messages through ten layers of pointy
haired bosses each.... The assumption that this would logically result
in the contractor 'gladly complying' doesn't necessarily reflect what
happens in reality. And this is without even considering the security
and clearance issues many such projects have to deal with.

One thing I'm still waiting to hear in this discussion is how Eiffel
would handle a temporal constraint of the type 'Signal A will be updated
with its new value within 2.5 ms of a change to any of its source
inputs'.

-- 

David Gillon

Re: Interresting thread in comp.lang.eiffel

[David Gillon]

David Gillon wrote:

> One thing I'm still waiting to hear in this discussion is how Eiffel
> would handle a temporal constraint of the type 'Signal A will be updated
> with its new value within 2.5 ms of a change to any of its source
> inputs'.

Blast, I meant to ask how DBC would handle than kind of constraint, not
Eiffel specifically.

-- 


David Gillon

Re: Interresting thread in comp.lang.eiffel

[David K Allen]

> David Gillon wrote:
>
> > One thing I'm still waiting to hear in this discussion is how [DBC]
> > would handle a temporal constraint of the type 'Signal A will be updated
> > with its new value within 2.5 ms of a change to any of its source
> > inputs'.

That is easy in theory, there is no magic here. You can do this in any
language, and many probably have.
But there is a cost to the calculation.  In time-sensitive applications, the
cost of calculating the answer may exceed the cost to do the calculation ;)
I have no magic solution for that. Obviously this technique can only be
practical when the cost of calculating the duration is immaterial compared
to the cost of the process being measured.  Although I will say that if
these time-sensitive routines were in an embedded,  real-time situation,
then the 'timer'object shown below, could be a hardware timer that was
dedicated to just such a task, so the measurement apparatus would have a
negligible effect on the overall calculation in many cases.

Also, someone else asked "What if my routine does not like the allowed
duration chosen?  Am I stuck with it failing, even though I might have
wanted the answer even if it came later?"  I will illustrate how to work
around that.
Assume a function 'signal' as follows:
------------------------------
signal (input: REAL): REAL is
            -- return 'signal' based upon 'input'
    require
        input_non_negative: input >= 0
    do
        timer.start
        ....
        timer.stop
    ensure
        signal_valid: (input > 0) implies (Result > 0) and (input = 0)
implies (Result = 0)
        duration_within_tolerance: timer.duration <= Max_Allowed_Duration
    end
-------
This illustrates how DBC can be used in the 'ensure' clause to enforce the
timing constraint
Notice also that the reference point 'Max_Allowed_Duration' is a variable,
to allow flexibility in application.
This addresses the issue someone else raised (I could not find the post, but
it was within the last few days).
For a client to set this allowable duration to a value appropriate for the
application, one merely writes a routine:
-----------------------------------------
set_max_allowed_duration (d: REAL) is
        -- allow client routines to set the 'Max_Allowed_Duration' to suite
their requirements
    require
        duration_valid: d > 0.01
    do
        ...
    ensure
        Max_Allowed_Duration = d
    end
--------------------------------------------
Or you could also have a feature pair 'disable_time_limit', and
'enable_time_limit' where do the obvious.

What do you think of this approach?  Can anyone think of better ways to
model limits to duration in DBC?
--
Best Wishes,
David Kreth Allen
Software Consultant
Minneapolis, Minnesota - USA

Re: Interresting thread in comp.lang.eiffel

[Bob Allen]

Thanks for the response, but I think I threw you off by the example.
The gist of my question is how can you let a supplier off the hook if you
don't care about a particular aspect of the contract.
The method provides a means of doing the opposite, weakening the
pre-condition and strengthen the post-condition. But I don't know how to
allow a class to ignore the parts of the post-condition.

Say for example a restaurant has a breakfast special for $3.99 you get 2
eggs, bacon, hash browns, toast, and grits. I don't particularly like grits,
but the regular price for a breakfast with 3 eggs, bacon, hash browns and
toast costs $5.00. So I order the special. They run out of grits before they
fill my order. How can I let them off the hook for the grits? Remember I
don't run the restaurant and cannot change their contracts.
class POPs_PLACE
feature
breakfast(payment)
Require
payment = $5.00
Ensure
3 Eggs, 1 bacon, 1 hash browns, 1 toast
breakfast_special(payment)
Require
payment = $3.99
Ensure
2 Eggs, 1 bacon, 1 hash browns, 1 toast, 1 grits

Bob Allen
Bob's Weekend Wonders
Training and Consulting
Land O Lakes, FL

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Bob Allen <ballen3@email.msn.com> wrote:
> Say for example a restaurant has a breakfast special for $3.99 you get
2
> eggs, bacon, hash browns, toast, and grits. I don't particularly like
grits,
> but the regular price for a breakfast with 3 eggs, bacon, hash browns
and
> toast costs $5.00. So I order the special. They run out of grits
before they
> fill my order. How can I let them off the hook for the grits? Remember
I
> don't run the restaurant and cannot change their contracts.

Then you're out of luck.
Translated to software terms, your scenario means that some software
module that offers a contract may occasionally be unable to stick with
the contract but the caller doesn't mind anyway. In other words, there's
a bug in the module that doesn't make a difference.
Given the nonlinear effects of software bugs, I don't think that this is
acceptable in a safety-critical environment.

Software contracts are nonnegotiable; if the existing contracts don't
satisfy you, write a new routine with a satisfactory contract.

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Veli-Pekka Nousiainen]

exeption?
retry

VPN

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8kkthk$2nrc9$1@ID-9852.news.cis.dfn.de...
> Bob Allen <ballen3@email.msn.com> wrote:
> > Say for example a restaurant has a breakfast special for $3.99 you get
> 2
> > eggs, bacon, hash browns, toast, and grits. I don't particularly like
> grits,
> > but the regular price for a breakfast with 3 eggs, bacon, hash browns
> and
> > toast costs $5.00. So I order the special. They run out of grits
> before they
> > fill my order. How can I let them off the hook for the grits? Remember
> I
> > don't run the restaurant and cannot change their contracts.
>
> Then you're out of luck.
> Translated to software terms, your scenario means that some software
> module that offers a contract may occasionally be unable to stick with
> the contract but the caller doesn't mind anyway. In other words, there's
> a bug in the module that doesn't make a difference.
> Given the nonlinear effects of software bugs, I don't think that this is
> acceptable in a safety-critical environment.
>
> Software contracts are nonnegotiable; if the existing contracts don't
> satisfy you, write a new routine with a satisfactory contract.
>
> Regards,
> Joachim
> --
> This is not an official statement from my employer or from NICE.
> Reply-to address changed to discourage unsolicited advertisements.
>
>

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Veli-Pekka Nousiainen <vp.nousiainen@lapinlahden-teknologiakeskus.fi>
wrote:
> exeption?
> retry
>
> VPN
>
> "Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote:
> > Software contracts are nonnegotiable; if the existing contracts
> > don't  satisfy you, write a new routine with a satisfactory
contract.

Assertions are applicable independently of whether there are any
exception handling facilities. The point is that a broken contract is
somehow relayed - whether that's debug output on a serial port, an
exception that can be caught, an exception that cannot be caught, or
whatever is relatively irrelevant - assertions can be combined with all
these techniques.
(This thread is on assertions in general, not on assertions in Eiffel.)

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"David Gillon" <david.gillon@baesystems.com> wrote in message
news:396DA53D.19DDBACE@baesystems.com...
>
>
> David Gillon wrote:
>
> > One thing I'm still waiting to hear in this discussion is how Eiffel
> > would handle a temporal constraint of the type 'Signal A will be updated
> > with its new value within 2.5 ms of a change to any of its source
> > inputs'.
>
> Blast, I meant to ask how DBC would handle than kind of constraint, not
> Eiffel specifically.

Well, it depends upon whether you mean "handle" in a run-time sense, or
"handle" in an analytical sense.

The particular description you gave could be interpreted as a thread-level
constraint, not a module-level constraint (if "source input" means a system
input, not a module input). Thread-level analysis tend to be the more
interesting ones, so I'm assuming this is what you meant. There are
certainly analysis techniques to do this, from which you can derive
module-level maximum run-times. (Of course, these run-times will have to be
the worst-case, unless the module has some way to know in what thread it is
currently participating.) You could then use these module-level constraints
in future thread-level analyses.

Coding these into the module as a run-time check might be tricky, since you
probably want only the time the module is actually running, not the time
between the start and end, but it's possible. There are some likely adverse
effects of doing so, such as reusability. Assuming you use some standard
scheduling technique (RMS, EDF) to enforce the assumptions of your
thread-level analysis, you can alternately have your scheduler detect
violations of that analysis at run-time. As a practical matter, it's
probably much preferable to do the temporal run-time checks in the
scheduler.

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

OK, here's a clarification:

Legal contracts between companies are usually negotiated.
Technical (DbC) contracts are negotiated when the callee is written.
They are no re-negotiated when the code is reused (unless the code is
opened up for redesign).
There is a connection between DbC and legal contracts. You can use DbC
contracts to specify the interface of a module (be it hardware or
software). If a failure related to the module occurs, DbC contracts will
tell you whether the error was in the module or outside.

David Gillon <david.gillon@baesystems.com> wrote:
>
> The need for information
> exchange for DBC would first have had to be pursued up multiple levels
> of the sub-contractor management tree until a level was reached at
which
> the release of information could be sought, and then on the contractor
> side chased back down the tree until someone was found who could
explain
> what was wanted. Think Dilbert 1 trying to have a technical discussion
> with Dilbert 2 by passing verbal messages through ten layers of pointy
> haired bosses each.... The assumption that this would logically result
> in the contractor 'gladly complying' doesn't necessarily reflect what
> happens in reality.

Actually DbC helps with this. Dilbert 1 will ask his manager "I need the
contract for this-and-that piece of software/hardware", and there isn't
much that the PHBs can misinterpret. DbC is a very formal tool - it's
just boolean expressions.

> One thing I'm still waiting to hear in this discussion is how Eiffel
> would handle a temporal constraint of the type 'Signal A will be
updated
> with its new value within 2.5 ms of a change to any of its source
> inputs'.

The method to get this type of DbC is always the same:
1) Imagine what you need to verify the constraint in a software that's
rigged for verifying this constraint. If this requires remembering a
series of measurements, do that.
2) Write a boolean-valued function that verifies the constraint.
3) Put that function into whatever assertion you have to check.

There's no magic involved here. It's just the same as ordinary software
instrumentation.

The real difference is that DbC assertions come with clearly defined
guidelines:
1. If a preconditions fails, look for the error in the caller. (If you
find that it's really a problem in the callee, it's time to review your
contracts.)
2. If a postcondition fails, look for the error in the callee. (If you
find that it's really a problem in the caller, it's time to review your
contracts.)
3. If writing code for a subclass, don't require more in your
preconditions than the base class.
4. If writing code for a subclass, don't ensure less in your
postconditions than the base class.
5. Have a software environment that can selectively switch checking on
or off, on a by-class (or even by-routine) basis.
6. Use the assertions to document the assumptions in your code.
7. Write the assertions before you code. You're lazy, so you'll write
shorter assertions as these are done first, and it will be easier for
you to write an extra code of line to support a simpler (and thus more
robust) interface semantics than to first write some code and then
document all the hidden assumptions.
8. Write the assertions by going down the interface specifications of
your software and transforming every specification into a boolean
function that tests whether your software is conforming to the
specification. (Ideally the specifications should already come in the
form of assertions, but you can't have everything.)

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[Veli-Pekka Nousiainen]

"David Gillon" <david.gillon@baesystems.com> wrote in message
news:396C9C7F.D9B20E5F@baesystems.com...
X
ROFLOL
> what was wanted. Think Dilbert 1 trying to have a technical discussion
> with Dilbert 2 by passing verbal messages through ten layers of pointy
> haired bosses each.... The assumption that this would logically result

The software inheritance layers are not what you were talking about?!
VPN
> in the contractor 'gladly complying' doesn't necessarily reflect what
> happens in reality. And this is without even considering the security
> and clearance issues many such projects have to deal with.
>
> One thing I'm still waiting to hear in this discussion is how Eiffel
> would handle a temporal constraint of the type 'Signal A will be updated
> with its new value within 2.5 ms of a change to any of its source
> inputs'.
>
> --
>
> David Gillon

Re: Interresting thread in comp.lang.eiffel

[David Gillon]

Veli-Pekka Nousiainen wrote:

> > what was wanted. Think Dilbert 1 trying to have a technical discussion
> > with Dilbert 2 by passing verbal messages through ten layers of pointy
> > haired bosses each.... The assumption that this would logically result
> 
> The software inheritance layers are not what you were talking about?!

Well yes, that's the fundamental issue, but there's so much noise* in
the communications channels of big multi-national, multi-company,
multi-system projects that the assumption that the need for some
information to do the job will automatically result in a timely and
crystal clear exchange of information between engineers is hopelessly
naive.

* 'noise' in this case could be legal constraints, security constraints,
institutional inertia, liability issues, IPR issues, cross-cultural
misunderstandings, cross-corporate-cultural misunderstandings, arguments
over who pays for the time, etc, etc, etc....

-- 


David Gillon

Re: Interresting thread in comp.lang.eiffel

[Bob Allen]

David K Allen <dkallen@visi.com> wrote in message
news:qe_a5.259$6E.64803@ptah.visi.com...
> Riddle:
>     When is a contract not a contract?
> Answer:
>     When they are two different words representing different concepts but
> spelled and/or sounding the same (homonyms).
> -----------------------------------------
> "Ken Garlington" wrote in separate posts
>
> > Wouldn't both sides have to agree to this contract for it to be legally
> > valid?
>
> > You understand, of course, that standard contracts are in fact
negotiated?
>

You are correct that both sides have to agree to the terms of the contract
for it to be legally valid,
but not all contracts are negotiated, some are take it or leave it.

When first developing a set of classes, you negotiate with the people on
your team, and yourself
to formulate the contract. Then when you publish your terms the people who
may be interested
in using your classes know where they stand.

When you go to X-Mart and see an item that you like, you enter into a
contract with X-Mart where
if you give X-Mart a predetermined amount of money, X-Mart will in turn give
you the item you like.
Most of the time it is a take it or leave it contract, but it is still a
contract. If you do not like the terms
of the contract you can go to Y-Mart and see if they have a better deal. You
expect X-Mart and Y-Mart
to have the items priced so that you know the terms of the contract before
you try and execute it.

The same applies when you go to build a system based in part or in whole of
existing components.
You look at the contract that the components offer and decide if the terms
are acceptable.
If not find a different component. If the component did not tell you its
costs and the benefits how could
you determine if it is what you want. It would be an unmarked grab bag. You
would not know what you
are getting nor what it costs, without having to look inside the bag and
asking a sales person for a price
check.  Both of these activities are time consumming.

Bob Allen
Bob's Weekend Wonders
Training and Consulting
Land O Lakes, FL

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Bob Allen" <ballen3@email.msn.com> wrote in message
news:#flPTbB7$GA.367@cpmsnbbsa07...
> The same applies when you go to build a system based in part or in whole
of
> existing components.
> You look at the contract that the components offer and decide if the terms
> are acceptable.

This is (potentially) true if you are buying software components. However,
the contractor for Ariane 5 was not buying software components. That's why
this model falls apart for Ariane 5.

Re: Interresting thread in comp.lang.eiffel

[Bob Allen]

Ken Garlington <Ken.Garlington@computer.org> wrote in message
news:Yx7b5.13181$7%3.916718@news.flash.net...
> "Bob Allen" <ballen3@email.msn.com> wrote in message
> news:#flPTbB7$GA.367@cpmsnbbsa07...
> > The same applies when you go to build a system based in part or in whole
> of
> > existing components.
> > You look at the contract that the components offer and decide if the
terms
> > are acceptable.
>
> This is (potentially) true if you are buying software components. However,
> the contractor for Ariane 5 was not buying software components. That's why
> this model falls apart for Ariane 5.
>

The Ariane 5 project "bought" software components from Ariane 4 without
knowing exactly what they were getting.
The same applies if the components are one you developed for another
project.
DBC provides a basis for others in your group to use and understand what you
have developed. Moreover years later when CRS kicks in, you have a written
semi-formal document that defines exactly how a particular class is going to
behave.
Once again, there is nothing magic about DBC, effort still needs to be
applied to formulate contracts. The benefits come by reducing postmortem
testing, ability to reuse components with confidence, and consistent
documentation of your system.

If DBC is not a valid method to creating robust reusable software
components, then what is.
I have used many approaches with varying degrees of success and find that
DBC provides the most stable framework for software development. Currently I
do not have the pleasure of implementing systems using Eiffel, I have to use
C, C++, Java, JavaScript. But I do use Eiffel constructs in my analysis and
my implementation. You can implement inheritance with C Structs. You just
have to take on the tedious tasks for enforcing encapsulation.

The Methods/tools I have developed systems professionally using include:
    EBV Software Engineering Object-Oriented Requirements Analysis for Ada
    Booch, when he still used blobs
    Rebecca Wirfs-Brock - Responsibility Driven Design
    OMT
    Fusion
    DBC with BON.

Types of systems developped include:
    Real-Time embeded application for OS-9
    Systems as small as PIC applications written in assembly
    Distributed applications involving real time collection of data from
across the US.
    ATM terminal software running on a VeriFone Omni490/1450.
    Remote management software to access the ATM from a PC
    Global Order Management System for VPNss, current assignment with AT&T.
    Data collection and analysis systems for the US Air Force

Platforms include:
    VME based Single Board Computers running OS-9
    Various Unix platforms<HP, DEX, IBM, and Sun>
    PC platforms from DOS 3.1 through NT 4.0.
    Mainframe systems(IBM, Sperry, Honneywell)
    Vax
    Single chip computers(PIC, MOT 68hc11,680x0)

For me DBC works, but requires thought and planning.  Please share with us
your secret for spontaneous development of Reliable Reusable components.

Bob Allen
Bob's Weekend Wonders
Training and Consulting
Land O Lakes, FL

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Bob Allen" <ballen3@email.msn.com> wrote in message
news:#utiFKO7$GA.280@cpmsnbbsa09...
>
> Ken Garlington <Ken.Garlington@computer.org> wrote in message
> news:Yx7b5.13181$7%3.916718@news.flash.net...
> > "Bob Allen" <ballen3@email.msn.com> wrote in message
> > news:#flPTbB7$GA.367@cpmsnbbsa07...
> > > The same applies when you go to build a system based in part or in
whole
> > of
> > > existing components.
> > > You look at the contract that the components offer and decide if the
> terms
> > > are acceptable.
> >
> > This is (potentially) true if you are buying software components.
However,
> > the contractor for Ariane 5 was not buying software components. That's
why
> > this model falls apart for Ariane 5.
> >
>
> The Ariane 5 project "bought" software components from Ariane 4 without
> knowing exactly what they were getting.

Untrue - Arianespace bought an SRI system (a box - a picture of which is at
http://www.flash.net/~kennieg/sextant.jpg ), not a set of software
components. They probably cared as much about the source language in the SRI
as you care about the source language of the software in your car's
computers.  OTOH, the vendor that delivered the Ariane 5 SRI (Sextant) was
the same vendor who wrote the software for Ariane 4. They knew exactly what
the software was. They just didn't know the characteristics of the total
system (the rocket -- not a software simulation of a rocket -- a real live
fire-belching tube) into which their SRI was to be used.

Brownie points to the first person who can identify those glowing triangles
at the left of the picture (and why they glow!).

Re: Interresting thread in comp.lang.eiffel

[Marin D. Condic]

Ken Garlington wrote:
> Brownie points to the first person who can identify those glowing triangles
> at the left of the picture (and why they glow!).

Ring Laser Gyros?

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Some people think programming Windows is like nailing jello to the 
ceiling... easy with the right kind of nails."

    --  Ivor Horton - Beginning Visual C++ 6
======================================================================

Re: Interresting thread in comp.lang.eiffel

[carr_tom]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

>"Bob Allen" <ballen3@email.msn.com> wrote in message
>news:#utiFKO7$GA.280@cpmsnbbsa09...
>> The Ariane 5 project "bought" software components from Ariane 4 without
>> knowing exactly what they were getting.

>Untrue - Arianespace bought an SRI system (a box - a picture of which is at
>http://www.flash.net/~kennieg/sextant.jpg ), not a set of software
>components. ...

>Brownie points to the first person who can identify those glowing triangles
>at the left of the picture (and why they glow!).

Looks like "Ring Laser Gyros" to me with the lasers turned on.
BTDTGTTS

/Tom
--
Thomas Peter Carr                               | I have a dream, ...
carr_tom@si.com                 (Internet)      |       M L King Jr    08/28/63
616-241-8846 / 616-241-8745 FAX (Telephone)     |
Smiths Industries, MS 3D1; 3290 Patterson Ave SE; Grand Rapids, MI  49512-1991

Re: Interresting thread in comp.lang.eiffel

[Veli-Pekka Nousiainen]

"carr_tom" <carr@falcon.si.com> wrote in message
news:396f0fc2$1@news.si.com...
X
> Looks like "Ring Laser Gyros" to me with the lasers turned on.
> BTDTGTTS
X
Please, Tom, explain both BTDTGTTS and "Ring Laser Gyros"

Veli-Pekka

Re: Interresting thread in comp.lang.eiffel

[Nick Williams]

In article <L6vb5.16117$7%3.988701@news.flash.net>,
Ken Garlington <Ken.Garlington@computer.org> wrote:

>http://www.flash.net/~kennieg/sextant.jpg

>Brownie points to the first person who can identify those
>glowing triangles at the left of the picture (and why they
>glow!).

It's a ring laser gyroscope; and from that description, I guess
it's clear why it's glowing...

Cheers,

Nick.

-- 

[ Nick Williams                                                          ]
[ MSc Computation                                  Mobile - 07957-138179 ]
[ New College, Oxford                     http://www.new.ox.ac.uk/~nick/ ]

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Bob Allen" <ballen3@email.msn.com> wrote in message
news:u6hp4i16$GA.283@cpmsnbbsa07...

> I hate reverting to overly simplistic examples, but I do not want to write
a
> book on
> this subject so here goes.
>
> Given the following methods of some math class, what is the semantics of
> each?
> REAL square_root(X:INTEGER)
> REAL inv(X:INTEGER)
> REAL tan(theta:REAL)
>
> square_root called with X = -1, what happens?
>             exception, return a value indicating an error, return
> 0, -square_root(abs(X)), or somthing else
>             Who should check if X < 0?
> for inv who checks for X = 0
>             is the result an exception or MAX_REAL
> for tan what happens if theta is a mutiple of 90+(180*n) or 270+(180*n)
> degrees?

Just out of curiosity: For "tan", what does the contract look like to
specify...

If theta is in degrees or radians?
The resources (CPU time, memory, etc.) required to use tan?
The precision and range of the result? (given that the contract may be coded
in Eiffel while the implementation is coded in C...)

(and you thought this was an overly simplistic example... :)

Re: Interresting thread in comp.lang.eiffel

[Bob Allen]

> > for tan what happens if theta is a mutiple of 90+(180*n) or 270+(180*n)
> > degrees?
>
> Just out of curiosity: For "tan", what does the contract look like to
> specify...
>
> If theta is in degrees or radians?
> The resources (CPU time, memory, etc.) required to use tan?
> The precision and range of the result? (given that the contract may be
coded
> in Eiffel while the implementation is coded in C...)
>
> (and you thought this was an overly simplistic example... :)
>
>

This is my point exactly, without writting down the contracts, no one knows
what to expect.
If you are going to write it down, why not write it in the class source
rather than in a seperate
text that is most likely going to be forgotten and never updated.

Bob Allen

Re: Interresting thread in comp.lang.eiffel

[Ken Garlington]

"Bob Allen" <ballen3@email.msn.com> wrote in message
news:uRY09RB7$GA.307@cpmsnbbsa07...

> This is my point exactly, without writting down the contracts, no one
knows
> what to expect.
> If you are going to write it down, why not write it in the class source
> rather than in a seperate
> text that is most likely going to be forgotten and never updated.

Because of

(a) the backgrounds of the people typically involved in defining system
requirements,
(b) the procurement process (see earlier post), and in particular the timing
of procurement events,
(c) the limits of expressibility via structured text,
(d) the additional complexity of the generated code (assuming the contracts
are generated as executable constructs).

Re: Interresting thread in comp.lang.eiffel

[David Starner]

On Wed, 12 Jul 2000 11:00:40 -0500, Bob Allen <ballen3@email.msn.com> wrote:
>
>> > for tan what happens if theta is a mutiple of 90+(180*n) or 270+(180*n)
>> > degrees?
>>
>> Just out of curiosity: For "tan", what does the contract look like to
>> specify...
>>
>> If theta is in degrees or radians?
>> The resources (CPU time, memory, etc.) required to use tan?
>> The precision and range of the result? (given that the contract may be
>coded
>> in Eiffel while the implementation is coded in C...)
>>
>> (and you thought this was an overly simplistic example... :)
>>
>>
>
>This is my point exactly, without writting down the contracts, no one knows
>what to expect.
>If you are going to write it down, why not write it in the class source
>rather than in a seperate
>text that is most likely going to be forgotten and never updated.

His point seemed to be that you can't specify those properites
in source code very easily. I can write those in comments easily;
not so easily in code. 

-- 
David Starner - dstarner98@aasaa.ofe.org
http/ftp: x8b4e53cd.dhcp.okstate.edu
It was starting to rain on the night that they cried forever,
It was blinding with snow on the night that they screamed goodbye.
	- Dio, "Rock and Roll Children"

Re: Interresting thread in comp.lang.eiffel

[Peter Amey]

Ken Garlington wrote:
> 
> "Bob Allen" <ballen3@email.msn.com> wrote in message
> news:u6hp4i16$GA.283@cpmsnbbsa07...
> 
> > I hate reverting to overly simplistic examples, but I do not want to write
> a
> > book on
> > this subject so here goes.
> >
> > Given the following methods of some math class, what is the semantics of
> > each?
> > REAL square_root(X:INTEGER)
> > REAL inv(X:INTEGER)
> > REAL tan(theta:REAL)
> >
> > square_root called with X = -1, what happens?
> >             exception, return a value indicating an error, return
> > 0, -square_root(abs(X)), or somthing else
> >             Who should check if X < 0?
> > for inv who checks for X = 0
> >             is the result an exception or MAX_REAL
> > for tan what happens if theta is a mutiple of 90+(180*n) or 270+(180*n)
> > degrees?
> 

Ken, you raise a number of very good points (as you have throughout this
thread).  Some of them, I think,  indicate that contracts (regardless of
whether contracts have any relevance to Ariane 5) are better enforced by
proof than by language-defined executable constraints.  

Proof:
  1. Has greater flexibility over _where_ you enforce the contract. 
  2. Requires no run time overhead for checking constraints. 
  3. Has no need for error handling code to deal with breeches of
contract you have proved can't occur (and which will therefore turn out
to be untestable).
  4. Can express properties not directly visible according to the
programming language rules at the point of check. (e.g. in SPARK we
might define a proof function "NotFull(S : StackType) return Boolean;"
which we can use for proof purposes even if the stack package does not
export an Ada function which can tell us if the stack is full or not).

For your square_root example we could say in SPARK:

function square_root(X : Integer) return Integer;
--# pre X >= 0; --this enforces a precondition proof check at each call
--# return M => ( M * M = X ); --read as "return some M such that ..."

Incidently, we can get the same precondition implicitly by simply making
the parameter Natural instead of Integer (as we could use type Radians,
Degrees or Mils to supply at least part of the contract for your Tan
example).

If we decided that the root operation had to be callable with any
argument and was to return 0 for an invalid one we can remove the
precondition and beef up the postcondition thus:

function square_root(X : Integer) return Integer;
-- no preconditon
--# return M => ( X <  0 -> M = 0) and
--#             ( X >= 0 -> M * M = X );

This removes the obligation of the caller to check the value of X before
making the call but, of course, may complicate what the caller can
safely do with the returned value!

Peter

P.S. Apologies for those who have tried to look up SPARK on our web site
in the last week - we are suffering the after effects of a lightning
strike and it is still down (forgot to put "lighting_strike = false" in
the precondition :-)

-- 
---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/

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

Re: Interresting thread in comp.lang.eiffel

[Peter Amey]

Peter Amey wrote:
 
[snip]

>   3. Has no need for error handling code to deal with breeches of
                                                        ^
                    oops, it's the wrong trousers Grommit

> contract you have proved can't occur (and which will therefore turn out
> to be untestable).

[snip]

sorry,

Peter

-- 
---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/

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

Re: Interresting thread in comp.lang.eiffel

[Joachim Durchholz]

Peter Amey <pna@praxis-cs.co.uk> wrote:
>
> Proof:
>   1. Has greater flexibility over _where_ you enforce the contract.
>   2. Requires no run time overhead for checking constraints.
>   3. Has no need for error handling code to deal with breeches of
> contract you have proved can't occur (and which will therefore turn
out
> to be untestable).
>   4. Can express properties not directly visible according to the
> programming language rules at the point of check. (e.g. in SPARK we
> might define a proof function "NotFull(S : StackType) return Boolean;"
> which we can use for proof purposes even if the stack package does not
> export an Ada function which can tell us if the stack is full or not).

Fully agreed. I'd love to see a prover for Eiffel.

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Interresting thread in comp.lang.eiffel

[cropt]

> If I make an assumption and don't explictly write it down or
> tell someone and conditions which I was not aware of at the
> time occurr that violate my assumption then we have a problem
> which would most likely take a while to track down.

I think the question was about what happens when you make an assumption
and write down something thats not exactly the same as your assumption

Like writing a log function and only writing the contract to prevent
negative numbers {forgetting what happens at 0}

Aspects (Re: Interesting thread in comp.lang.eiffel)

[tom]

"Ken Garlington" <Ken.Garlington@computer.org> writes:
> Unfortunately, all the tool does is eliminate the non-contract part. It
> won't convert something like this:
> 
> convert (horizontal_bias: INTEGER): INTEGER is
>       require
>          horizontal_bias <= Maximum_bias
> 
> into a plot of horizontal bias vs. ascent angle, or into another form that a
> system engineer (as opposed to a software engineer) can understand and use.

I think that's a major problem with Eiffel-style contracts: they are
scattered throughout the code, and they are limited to assertion
checking.  To me, it seems that aspects (www.aspectj.org) are actually
altogether a better approach.

First, aspects let you implement Eiffel-style contracts and separate them
out into a separate file.  This makes it possible for, say, a system
engineer to understand and review them independently.  In fact, you
can even have separate "cleanroom" development of contracts and actual
code, which I would expect to be considerably more robust.

Second, aspects let you implement analysis and code understanding
tools that are more general than contracts.  For example, developing
an aspect that could be used to make plots for system engineers would
be nearly trivial (a few lines expressing the idea "whenever any
method is executed on an instance of this class, note the time, the
horizontal bias, and the ascent angle") and without affecting the main
body of code.  That encourages the development of better testing
tools, and it also makes sure that people don't introduce bugs into
the main branch of code when writing testing code.

Have people in the Eiffel community looked at aspects?  What do you
think?

Tom.

Re: Aspects (Re: Interesting thread in comp.lang.eiffel)

[Steve Merrick]

"tom" <tmb at ncal point verio point com x@x.x> wrote in message
news:pb8k8ersvvs.fsf_-_@aimnet.com...

> Have people in the Eiffel community looked at aspects?
> What do you think?

I've long been interested in Eiffel, but not (yet) had the chance to use it
professionally. :-( The obvious attraction of Eiffel (to me) is DBC. I too
would be very interested to hear the views of the Eiffel community on
aspects. I must admit I hadn't realised that aspects provided DBC, or some
equivalent.

--
Steve Merrick

"First, do no harm."

Re: Aspects (Re: Interesting thread in comp.lang.eiffel)

[Frank Mitchell]

Steve Merrick wrote in message
<8kh89g$si$1@newsfeed.pit.comms.marconi.com>...
>"tom" <tmb at ncal point verio point com x@x.x> wrote in message
>news:pb8k8ersvvs.fsf_-_@aimnet.com...
>
>> Have people in the Eiffel community looked at aspects?
>> What do you think?
>
>I've long been interested in Eiffel, but not (yet) had the chance to use it
>professionally. :-( The obvious attraction of Eiffel (to me) is DBC. I too
>would be very interested to hear the views of the Eiffel community on
>aspects. I must admit I hadn't realised that aspects provided DBC, or some
>equivalent.


I think it's safer to say that aspects can simulate contracts, although I
don't think it's a good idea.  Contracts are meant to be ubiquitous; ideally
every routine should have one.  Aspects, on the other hand, attach to the
"component program" -- the collection of components that express
functionality -- through "join points", such as class and routine names.
Using aspects for all contracts means typing class and routine names twice
... which wasn't a good idea for documentation or method signatures in the
original design of Eiffel (or Java, or other languages).

Aspects express design considerations that transcend and distort normal
programs, such as concurrency, memory usage, and security.  It makes sense
to give aspects contracts that relate to those concerns, or to express those
aspects declaratively as contracts (if that translates to real code, not
assertions) ... but I don't believe all contracts belong in the aspect side
of the program.

Frank

Re: Aspects (Re: Interesting thread in comp.lang.eiffel)

[Jubilation]

A few months ago I gave a talk at Nokia Research Center about generative
programming and one of my demos was to implement DBC with AspectJ.

There are only two differences I can find:
1. syntax, Eiffel in easier to read, AspectJ requires typing names twice.
2. Possibility to do more good and harm with AspectJ.

In other words, I cannot imagine a single thing that you can do with
Eiffel style DBC and you can't do with AspectJ.

Can you?

More comments embedded
Please drop the 1 away from my email address if you reply
--

"Frank Mitchell" <frankm@bayarea.net> wrote in message
news:8ki7ct$8q2$1@news.bayarea.net...
>
> Steve Merrick wrote in message
> <8kh89g$si$1@newsfeed.pit.comms.marconi.com>...
> >"tom" <tmb at ncal point verio point com x@x.x> wrote in message
> >news:pb8k8ersvvs.fsf_-_@aimnet.com...
> >
> >> Have people in the Eiffel community looked at aspects?
> >> What do you think?

I was deeply dissappointed when java came out without DBC, but the
xerox AOP group has done incredible job to fix the situation.

> >
> >I've long been interested in Eiffel, but not (yet) had the chance to use
it
> >professionally. :-( The obvious attraction of Eiffel (to me) is DBC. I
too

Precisely like me!

> >would be very interested to hear the views of the Eiffel community on
> >aspects. I must admit I hadn't realised that aspects provided DBC, or
some
> >equivalent.
>
>
> I think it's safer to say that aspects can simulate contracts, although I
> don't think it's a good idea.  Contracts are meant to be ubiquitous;
ideally
> every routine should have one.  Aspects, on the other hand, attach to the
> "component program" -- the collection of components that express
> functionality -- through "join points", such as class and routine names.

Can you please explain what is the actual difference? I just can't see any.

> Using aspects for all contracts means typing class and routine names twice
> ... which wasn't a good idea for documentation or method signatures in the
> original design of Eiffel (or Java, or other languages).

This is mainly due to our tradition of using files as an implementation
mechanism.
A more versatile source code repository would solve many other problems too.

>
> Aspects express design considerations that transcend and distort normal
> programs, such as concurrency, memory usage, and security.  It makes sense
> to give aspects contracts that relate to those concerns, or to express
those
> aspects declaratively as contracts (if that translates to real code, not
> assertions) ... but I don't believe all contracts belong in the aspect
side
> of the program.

Well, I believe that Eiffel DBC is just a limited subset of AOP,just like a
hard
wired string type in a language is a limited subset of OOP.

>
> Frank
>

Kari

Re: Aspects (Re: Interesting thread in comp.lang.eiffel)

[Frank Mitchell]

Jubilation wrote in message ...
>"Frank Mitchell" <frankm@bayarea.net> wrote in message
>news:8ki7ct$8q2$1@news.bayarea.net...
>>  Contracts are meant to be ubiquitous; ideally
>> every routine should have one.  Aspects, on the other hand, attach to the
>> "component program" -- the collection of components that express
>> functionality -- through "join points", such as class and routine names.
>
>Can you please explain what is the actual difference? I just can't see any.


I guess I didn't emphasize the contrast.  In AOP, as I understand it, there
are two conceptual entities: components, which express the functionality of
the system, and aspects, which express far-reaching design decisions that
would otherwise be scattered all over the code.  In DBC, on the other hand,
the contract is as integral to a routine as its parameters and return type.

Defining the contracts in a separate conceptual entity -- whether defined
using files or some sort of "model database" -- will require either the
person or the tools to juxtapose the two to make sense of the routine.  Just
as the routines to operate on data are colocated with the data fields in OOP
because they are closely related, so the contracts are better left colocated
with the routines and classes they describe.

>Well, I believe that Eiffel DBC is just a limited subset of AOP, just like
a
>hard wired string type in a language is a limited subset of OOP.


You can make virtually anything an aspect, but I don't see the use of doing
so when inheritance of deferred ("abstract" or "interface") classes allows
an equally clean separation of specification and implementation, and when
most contracts concern design decisions which are trivial to localize.

Frank

Re: Aspects (Re: Interesting thread in comp.lang.eiffel)

[Jubilation]

--
Please drop the 1 away from my email address if you reply

> You can make virtually anything an aspect, but I don't see the use of
doing

Actually you can't, for example AspectJ cannot be used for generative
programming as CLOS can.

> so when inheritance of deferred ("abstract" or "interface") classes allows
> an equally clean separation of specification and implementation, and when
> most contracts concern design decisions which are trivial to localize.
>
> Frank
>

I can use AspectJ to define a pre+postcondition check for an
interface method or an abstract method too. This check is executed
in implementing classes, just like Eiffel DBC. Sorry, but I still can't
see why a language needs hard-wired DBC.

Being able to do something what AspectJ does as well as a MOP
for static metaprogramming are my top two wishes for
language extensions.

Kari

Re: Aspects (Re: Interesting thread in comp.lang.eiffel)

[Veli-Pekka Nousiainen]

vp.nousiainen@lapinlahden-teknologiakeskus.fi

"tom" <tmb at ncal point verio point com x@x.x> wrote in message
news:pb8k8ersvvs.fsf_-_@aimnet.com...
> "Ken Garlington" <Ken.Garlington@computer.org> writes:
> > Unfortunately, all the tool does is eliminate the non-contract part. It
> > won't convert something like this:
> >
> > convert (horizontal_bias: INTEGER): INTEGER is
> >       require
> >          horizontal_bias <= Maximum_bias
> >
> > into a plot of horizontal bias vs. ascent angle, or into another form
that a
> > system engineer (as opposed to a software engineer) can understand and
use.
>
> I think that's a major problem with Eiffel-style contracts: they are
> scattered throughout the code, and they are limited to assertion
> checking.  To me, it seems that aspects (www.aspectj.org) are actually
> altogether a better approach.
>
> First, aspects let you implement Eiffel-style contracts and separate them
> out into a separate file.  This makes it possible for, say, a system

Use ISE Eiffel short-form for this. Give it a try !
http://www.eiffel.com/webforms/eiffel_download_ini.html
VPN

> engineer to understand and review them independently.  In fact, you
> can even have separate "cleanroom" development of contracts and actual
> code, which I would expect to be considerably more robust.
>
> Second, aspects let you implement analysis and code understanding
> tools that are more general than contracts.  For example, developing
> an aspect that could be used to make plots for system engineers would
> be nearly trivial (a few lines expressing the idea "whenever any
> method is executed on an instance of this class, note the time, the
> horizontal bias, and the ascent angle") and without affecting the main
> body of code.  That encourages the development of better testing
> tools, and it also makes sure that people don't introduce bugs into
> the main branch of code when writing testing code.
>
> Have people in the Eiffel community looked at aspects?  What do you
> think?
>
> Tom.

Re: Aspects (Re: Interesting thread in comp.lang.eiffel)

[tom]

"Veli-Pekka Nousiainen" <vp.nousiainen@kolumbus.fi> writes:
> > First, aspects let you implement Eiffel-style contracts and separate them
> > out into a separate file.  This makes it possible for, say, a system
> 
> Use ISE Eiffel short-form for this. Give it a try !
> http://www.eiffel.com/webforms/eiffel_download_ini.html

That may be nice for reading, but it doesn't separate concerns when
writing the code.  Aspects essentially give you the "short form"
for both reading and writing of contracts.

Whether that is ultimately better or not remains to be seen.  But it
at least seems attractive a-priori, in particular on larger projects
where responsibilities are distributed among many people.  Time will
tell.

Tom.

Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[David Kristola]

On Tue, 11 Jul 2000 6:14:44 -0700, Ken Garlington wrote
(in message <85Fa5.11419$7%3.818927@news.flash.net>):

> convert (horizontal_bias: INTEGER): INTEGER is
>       require
>          horizontal_bias <= Maximum_bias

I'm not saying that Design by Contract is a bad thing,
but i hope there is a whole lot more to it than this
example seems to say.  I saw a similar example for a
formatted comment in Java that can be checked by a
tool.

Ada does the above by using a subtype that is limited
to Maximum_Bias.  (The Java example had a post condition
contract saying that the out parameter would be
positive, again, the Ada solution is to use a subtype).

What kinds of DbC things could i do in Eiffel that i
can't do in Ada with pragma Assert and good typing?

How can i use the concepts of DbC to make better Ada
code?

Thanks,

-- 
--djk, keeper of arcane lore & trivial fluff
Home: David95036 plus 1 at america on-line
Spam: goto.hades@welovespam.com

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Greg]

David Kristola <David95037@See-My.Sig> wrote:
[snip]

>
>What kinds of DbC things could i do in Eiffel that i
>can't do in Ada with pragma Assert and good typing?
>
In Eiffel, DbC works with inheritance. So a subclass is bound to
the same contract as its parent class automatically. Not being
an Ada guru, I'd guess you would have to copy the parent's
contract into the child, leading to undesirable duplication.


>How can i use the concepts of DbC to make better Ada
>code?

I don't have a short answer to that. Best I can say is read the
relevant chapters in Meyer's "Object Oriented Software
Construction" (2nd Ed.)

>
>Thanks,
>
>--
>--djk, keeper of arcane lore & trivial fluff
>Home: David95036 plus 1 at america on-line
>Spam: goto.hades@welovespam.com
>
>
>



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

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Matthew J Heaney]

Greg <gmc333NOgmSPAM@my-deja.com.invalid> writes:

> In Eiffel, DbC works with inheritance. So a subclass is bound to the
> same contract as its parent class automatically. Not being an Ada
> guru, I'd guess you would have to copy the parent's contract into the
> child, leading to undesirable duplication.

Yes, it's true that Eiffel's contract-checking is more sophisticated
than a simple assertion-check.  However, Eiffel *has* to be this way,
because the idiom in that language is inheritance-based programming.
Abstractions are composed using inheritance.

But in Ada, it's very rare that you have deep inheritance lattices,
because there are language features that allow you to compose
abstractions using aggregation.  So contract checks don't need to be any
more sophisticated than simple assertion checks.

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Eirik Mangseth]

"Matthew J Heaney" <mheaney@on2.com> wrote in message
news:7r66qbf1xw.fsf@butter.albany.duck.com...
> Greg <gmc333NOgmSPAM@my-deja.com.invalid> writes:
>
> > In Eiffel, DbC works with inheritance. So a subclass is bound to the
> > same contract as its parent class automatically. Not being an Ada
> > guru, I'd guess you would have to copy the parent's contract into the
> > child, leading to undesirable duplication.
>
> Yes, it's true that Eiffel's contract-checking is more sophisticated
> than a simple assertion-check.  However, Eiffel *has* to be this way,
> because the idiom in that language is inheritance-based programming.
> Abstractions are composed using inheritance.

Oh god, not again. This is not true at all. In OOSC2 the author asks the
question: "Would you rather buy or inherit" and goes to great length
in discussing the pro and cons of both approaches. As every experienced
Eiffel (and OO programmer knows) inheritance and aggregation are
complementary and their usage depends on the goals you try to achieve.

Instead of stating such claims, why don't you sit down and learn the
language?

>
> But in Ada, it's very rare that you have deep inheritance lattices,
> because there are language features that allow you to compose
> abstractions using aggregation.

In Eiffel as well.

> So contract checks don't need to be any
> more sophisticated than simple assertion checks.
>
>

And all programming can be done in assembly


best regards

Eirik Mangseth
Stockpoint Nordic AS
Lysaker, Norway

"If I can't Eiffel in heaven, I won't go"

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Howard W. LUDWIG]

David Kristola wrote:

> On Tue, 11 Jul 2000 6:14:44 -0700, Ken Garlington wrote
> (in message <85Fa5.11419$7%3.818927@news.flash.net>):
>
> > convert (horizontal_bias: INTEGER): INTEGER is
> >       require
> >          horizontal_bias <= Maximum_bias
>
> I'm not saying that Design by Contract is a bad thing,
> but i hope there is a whole lot more to it than this
> example seems to say.  I saw a similar example for a
> formatted comment in Java that can be checked by a
> tool.
>
> Ada does the above by using a subtype that is limited
> to Maximum_Bias.  (The Java example had a post condition
> contract saying that the out parameter would be
> positive, again, the Ada solution is to use a subtype).
>
> What kinds of DbC things could i do in Eiffel that i
> can't do in Ada with pragma Assert and good typing?
>
> How can i use the concepts of DbC to make better Ada
> code?
>
> Thanks,
>
> --
> --djk, keeper of arcane lore & trivial fluff

I would like to add my own questions--actually add some
specificity to David's questions.  I have never coded in
nor learned Eiffel before, so _some_ of these concepts
are new to me and I am a bit confused.  In particular:

How are the "require" and "ensure" blocks handled--as
executable code at run-time, as compiler-checking, or
simply as comments to support humanoid review or automated
checking by tools other than the Eiffel compiler?  The
reason I ask is that I have read in this thread and in
skimming through OOSC that in a contract, using Eiffel/
DbC principles, a caller is responsible for verifying
the preconditions (the "require" block) and the callee
is responsible for verifying the postconditions (the
"ensure" block).  How does the caller handle the
verification of the preconditions if they are spelled
out in [only] the callee?

I'm interested in the overall DbC philosophy on this
topic of verifying contracts, the Eiffel implementation,
and what and how much can be done similarly in Ada
implementations.  The DbC distribution of responsibility
for satisfying contracts seems to be clean--somewhat
different from what is usually done, and I'm not totally
convinced yet that it is the best way to go, but _at least_
it is a well-defined way, which is better than having no
way and taking a haphazard approach.  Range-checking on
Ada subtypes seems to take the DbC approach in general,
but full-fledged assertions would seem to execute wherever
they are written, which imposes most of the burdens,
whether pre- or post-conditions on the callee.

Any clarification would be most appreciated.

Howard W. LUDWIG

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Greg]

"Howard W. LUDWIG" <howard.w.ludwig@lmco.com> wrote:
[snip]
>
>How are the "require" and "ensure" blocks handled--as
>executable code at run-time, as compiler-checking, or
>simply as comments to support humanoid review or automated
>checking by tools other than the Eiffel compiler?

AFAIK no Eiffel compiler can check require/ensure code at run-
time. Indeed, many of the assertions simply can't be computed
until runtime.

Compiler options can be used to toggle sets of assertions. ISE's
ACE (their makefile language) takes this control down to the
class level. So developers have a degree of control over how
much overhead the assertions add.

The burden of executing 'require' clauses need not be placed on
the callee. In examining the interface to a class, the compiler
has all the information needed to place that burden in the
caller's code. It simply inline's the require clauses before the
feature call. This is one reason that any features referenced by
a require clause have to be public.

For example, in the STRING class the index method (in
SmallEiffel) is declared as:

   item (index: INTEGER): CHARACTER
      --  Character at position index.
      require
         valid_index(index)

Here valid_index is a public feature. When a client of string
executes:
    c := str.item (n)
the compiler may translate this into (pseudo-C code):
    assert (str.valid_index(n))  // inlined require clause
    c := str.item (n)            // actual execution

So in principle one can deliver an Eiffel library as interface
definitions and optimized code, and still get the benefits of
DbC.

(Ensure clauses are a different matter. They can access private
data and have to be compiled into the service object. Ideally,
if one ships an optimized binary library, one's already done a
lot of work to make sure that all the ensure clauses are
redundant.)

The require/ensure clauses are also a great humanoid review tool.
See for example the ongoing ELKS 2000 standardization process,
http://www.egroups.com/group/eiffel-nice-library
Practically all of the discussion focuses on feature names and
the require/ensure clauses supported by the features. Rarely are
implementation details discussed, and comments are used
sparingly. (Try THAT in C++ why doncha!)

[snip]



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

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Eirik Mangseth]

"Greg" <gmc333NOgmSPAM@my-deja.com.invalid> wrote in message
news:07634490.b099171e@usw-ex0107-055.remarq.com...
> "Howard W. LUDWIG" <howard.w.ludwig@lmco.com> wrote:
> [snip]
> >
> >How are the "require" and "ensure" blocks handled--as
> >executable code at run-time, as compiler-checking, or
> >simply as comments to support humanoid review or automated
> >checking by tools other than the Eiffel compiler?

Assertion checking is done at run-time, with the strictness-level
set by the programmer. In addition Eiffel IDE's come with
tools like short and flat/short. The first produces a public
view of the class, i.e. all exported features including
pre- and postcondtions and the class invariant (if present).

The latter (flat/short) produces the same format, but includes
features and assertions from all ancestors of the current class.

This makes for very compact and readily available documentation which,
in the Eiffel IDE I'm using can be output in various formats, including
html (with hyperlinks an all), tex, troff, etc. It is also possible to write
your own pluggable "filters".

Someone in this thread commented that a weakness was that assertions
are scattered throughout the code and that it would be better to have
them in a separate file.

First of all, an assertion is intimately linked to the feature it applies
to.
If it is a so-called business rule it should be declared in only one place,
i.e.
the class that defines the abstraction to which the rule applies. That way,
it
is not "scattered" throughout. Secondly, there's no need to keep assertions
in a separate file e.g. for documentation purposes as the above mentioned
tools will produce the necessary documentation (also from the command line).

>
> AFAIK no Eiffel compiler can check require/ensure code at run-
> time.

A typo here, Greg? Should say compile-time, shouldn't it?

Regards

Eirik Mangseth
Stockpoint Nordic AS,
Lysaker, Norway

"If I can't Eiffel in heaven, I won't go"


> Indeed, many of the assertions simply can't be computed
> until runtime.
>
> Compiler options can be used to toggle sets of assertions. ISE's
> ACE (their makefile language) takes this control down to the
> class level. So developers have a degree of control over how
> much overhead the assertions add.
>
> The burden of executing 'require' clauses need not be placed on
> the callee. In examining the interface to a class, the compiler
> has all the information needed to place that burden in the
> caller's code. It simply inline's the require clauses before the
> feature call. This is one reason that any features referenced by
> a require clause have to be public.
>
> For example, in the STRING class the index method (in
> SmallEiffel) is declared as:
>
>    item (index: INTEGER): CHARACTER
>       --  Character at position index.
>       require
>          valid_index(index)
>
> Here valid_index is a public feature. When a client of string
> executes:
>     c := str.item (n)
> the compiler may translate this into (pseudo-C code):
>     assert (str.valid_index(n))  // inlined require clause
>     c := str.item (n)            // actual execution
>
> So in principle one can deliver an Eiffel library as interface
> definitions and optimized code, and still get the benefits of
> DbC.
>
> (Ensure clauses are a different matter. They can access private
> data and have to be compiled into the service object. Ideally,
> if one ships an optimized binary library, one's already done a
> lot of work to make sure that all the ensure clauses are
> redundant.)
>
> The require/ensure clauses are also a great humanoid review tool.
> See for example the ongoing ELKS 2000 standardization process,
> http://www.egroups.com/group/eiffel-nice-library
> Practically all of the discussion focuses on feature names and
> the require/ensure clauses supported by the features. Rarely are
> implementation details discussed, and comments are used
> sparingly. (Try THAT in C++ why doncha!)
>
> [snip]
>
>
>
> -----------------------------------------------------------
>
> Got questions?  Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Joachim Durchholz]

Howard W. LUDWIG <howard.w.ludwig@lmco.com> wrote:
> David Kristola wrote:
>
> > What kinds of DbC things could i do in Eiffel that i
> > can't do in Ada with pragma Assert and good typing?

Stuff like
  my_parame /= Void
or
  find_minimum_in (h: HEAP)
  require
    not h.is_empty
or
  solve (q: QUADRATIC_EQUATION)
  require
    solvable (q)
or
  sqrt (r: REAL): REAL is
  require
    r >= 0.0
or
  log (r: REAL): REAL is
  require
    r > 0.0
(try to put both the preconditions for sqrt and log into a range type
<g>).

It's just more flexible. In fact Eiffel has no range types; the
understanding is that contracts properly include them. (Personally, I
tend to disagree but I can live well with just contracts.)

> How are the "require" and "ensure" blocks handled--as
> executable code at run-time,

Usually, provided that you have switched run-time checking on (e.g.
because you're testing your code - it's not usually done in production
code).

> as compiler-checking,

In principle, yes. No such tool has yet been built though; it would
require
a) a quite powerful inference engine and
b) some way to allow programmers to help with inferences if the engine
doesn't come up with a proof, or
c) meaningful warnings that pinpoint the problem so that the appliation
programmer either knows what to change in his code or can prove validity
by hand.

It would be an interesting large project to do that. Most inference
engines are built for academic languages.

> or
> simply as comments to support humanoid review or automated
> checking by tools other than the Eiffel compiler?

This usage is always a part of DbC. It tends to be more important than
the checking aspects.

> How does the caller handle the
> verification of the preconditions if they are spelled
> out in [only] the callee?

As David wrote, it's usually done by the compiler which compiles
everything in one large blob (no separately compiled libraries).
But that's just an accident of current Eiffel implementations. For
example, for

  sqrt (r: REAL): REAL is
  require
    r >= 0.0

an Eiffel compiler could emit assembly code like this:

_checked_sqrt:
  <establish stack frame>
  <evaluate "r >= 0.0"
  <jump to _start_sqrt if test came out true>
  <raise exception in caller>
sqrt:
  <establish stack frame>
_start_sqrt:
  <start code for foo's normal body>

That way, it's the caller's choice: if it calls _checked_sqrt, it's
getting the precondition checking, if it calls sqrt, it's getting no
precondition checking.
The code for raising an exception in the caller should just unwind the
stack and raise the exception, while the code for raising a
postcondition exception does not unwind the stack. (The exact details of
exceptions depend on the presence of debuggers etc., so I won't go into
detail here.)

> The DbC distribution of responsibility
> for satisfying contracts seems to be clean--somewhat
> different from what is usually done, and I'm not totally
> convinced yet that it is the best way to go, but _at least_
> it is a well-defined way, which is better than having no
> way and taking a haphazard approach.

I have used DbC in practice, and it is immensely useful. I used to write
"defensive code" in the past, and always had the problem that I never
knew what my code should do if it really detected a problem. Then I had
the same checking in the callers... and lots of trouble whenever the
specifications of the code changed.
Today, I do the same defensive programming and put it into the
preconditions. However, I don't code them in the caller anymore (so the
caller doesn't have to worry whether he really understood the
documentation - the callee should do all the relevant checks), the
caller doesn't have to worry about the inefficiencies of defensive
programming (just switch assertions off for the code that you're
confident in).

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[David Kristola]

On Thu, 13 Jul 2000 11:12:53 -0700, Joachim Durchholz wrote
(in message <8kl0r6$2lp6o$1@ID-9852.news.cis.dfn.de>):

> Howard W. LUDWIG <howard.w.ludwig@lmco.com> wrote:
>> David Kristola wrote:
>> 
>>> What kinds of DbC things could i do in Eiffel that i
>>> can't do in Ada with pragma Assert and good typing?
> 
> Stuff like
>   my_parame /= Void

From later in Joachim's post, it is clear that failure to meet
the precondition causes an exception to be raised (at run time,
i assume that a precondition that can be checked at compile time
would be checked, and the code would not compile if it is violated).
Assuming my_parame is an access type, Ada will raise an exception if
it is void (null).

Ada compilers generally give the user the ability to control
the amount of run-time checking compiled in.

> or
>   find_minimum_in (h: HEAP)
>   require
>     not h.is_empty

Depending on the implementation of the heap, this too would
probably cause some sort of exception to be raised if the
heap were empty.

In the past, i had good reason to implement a FIFO queue
that would pop a "dry FIFO" pattern if it were empty.  I
suppose it might be possible to have a heap class that
returns Integer'LAST or Float'LAST when the minimum value
is requested from an empty heap.

> or
>   solve (q: QUADRATIC_EQUATION)
>   require
>     solvable (q)

I know from recent personal experience that a simple 2x2
matrix inversion routine causes an exception to be raised
when the matrix can't be inverted (divide by zero results
in a Constraint_Error to be raised).

Perhaps i am missing something.  If the only way to know
that the precondition is not met is to work the problem
(solve the quadratic equation, in this case) and find
an impass, then what is the difference between writing
it as a precondition vs. writing it as an exception
when the problem can't be solved?

> or
>   sqrt (r: REAL): REAL is
>   require
>     r >= 0.0
> or
>   log (r: REAL): REAL is
>   require
>     r > 0.0
> (try to put both the preconditions for sqrt and log into a range type
> <g>).

Simple.

   subtype None_Negative_Float_Type is Float range 0.0 .. Float'LAST;
   subtype Positive_Float_Type is None_Negative_Float_Type range
      Float'SUCC(0.0) .. Float'LAST;

   function Sqrt(R : Non_Negative_Float_Type) return Float;
   funciton Log(R : Positive_Float_Type) return Float;

As subtypes of Float, i can call either routines with a Float
variable (without using a type cast), and an appropriate
constraint check will be generated by the compiler.  That
check can be eliminated by telling the compiler to not perform
that checking.

In this particular case, i'm not sure what the subtype
constraint check would add.  Very limited cases could be
checked at compile time.  At run time, if the preconditions
are violated, an excpetion will be raised.

> It's just more flexible. In fact Eiffel has no range types; the
> understanding is that contracts properly include them. (Personally, I
> tend to disagree but I can live well with just contracts.)

It seems to me that contracts can add to the code, but i really
like Ada's robust typing capabilities.

> I have used DbC in practice, and it is immensely useful.

I am going to continue looking into DbC as time permits.  I
wonder if there is a free Eiffel compiler available for the
Mac so that i can play around with it.

Thanks,

-- 
--djk, keeper of arcane lore & trivial fluff
Home: David95036 plus 1 at america on-line
Spam: goto.hades@welovespam.com

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Matthew J Heaney]

David Kristola <David95037@See-My.Sig> writes:

> I am going to continue looking into DbC as time permits.  I
> wonder if there is a free Eiffel compiler available for the
> Mac so that i can play around with it.

Yes, there is.  There's a (free) Eiffel compiler plug-in for
CodeWarrior:

<http://www.object-tools.com/products/eiffel-s/index.html>

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Joachim Durchholz]

David Kristola <David95037@See-My.Sig> wrote:
> On Thu, 13 Jul 2000 11:12:53 -0700, Joachim Durchholz wrote:
>
> > or
> >   find_minimum_in (h: HEAP)
> >   require
> >     not h.is_empty
>
> Depending on the implementation of the heap, this too would
> probably cause some sort of exception to be raised if the
> heap were empty.

The difference is that the exception will happen before the routine is
even called. The responsibility for the exception will clearly be the
caller's. If the exception happens somewhere inside the routine, you
need another analysis stept to find out which part of the code is really
responsible for the problem.

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[David Kristola]

On Sun, 16 Jul 2000 12:12:10 -0700, Joachim Durchholz wrote
(in message <8kt1eb$34jh1$1@ID-9852.news.cis.dfn.de>):

> David Kristola <David95037@See-My.Sig> wrote:
>> On Thu, 13 Jul 2000 11:12:53 -0700, Joachim Durchholz wrote:
>> 
>>> or
>>> find_minimum_in (h: HEAP)
>>> require
>>> not h.is_empty
>> 
>> Depending on the implementation of the heap, this too would
>> probably cause some sort of exception to be raised if the
>> heap were empty.
> 
> The difference is that the exception will happen before the routine is even 
> called. The responsibility for the exception will clearly be the caller's. 
> If the exception happens somewhere inside the routine, you need another 
> analysis stept to find out which part of the code is really responsible for 
> the problem.

Perhaps it is my coding style, but (in this limited case) i would
consider it the responsibility of the caller to handle the exception.
There is nothing find_minimum_in can do if the heap is empty.  To me,
that is even an unstated but obvious contract.  This is not to say
that it is not worth stating obviously and in a way that can be
checked by a compiler.  This particular example is perhaps a little
simple.  Certainly there are plenty of others that are not so
obvious, where a formally stated precondition adds to the understanding.
Unlike some other areas, i can't think of a way to define a subtype
of heap that only contains non-empty heaps.

Ada also does not provide for the inheritance of contracts.  That is
a very interesting aspect of Eiffel.


-- 
--djk, keeper of arcane lore & trivial fluff
Home: David95036 plus 1 at america on-line
Spam: goto.hades@welovespam.com

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Joachim Durchholz]

David Kristola <David95037@See-My.Sig> wrote:
> On Sun, 16 Jul 2000 12:12:10 -0700, Joachim Durchholz wrote
> (in message <8kt1eb$34jh1$1@ID-9852.news.cis.dfn.de>):
>
> > David Kristola <David95037@See-My.Sig> wrote:
> >> On Thu, 13 Jul 2000 11:12:53 -0700, Joachim Durchholz wrote:
> >>
> >>> or
> >>> find_minimum_in (h: HEAP)
> >>> require
> >>> not h.is_empty
> >>
> >> Depending on the implementation of the heap, this too would
> >> probably cause some sort of exception to be raised if the
> >> heap were empty.
> >
> > The difference is that the exception will happen before the routine
> > is even called. The responsibility for the exception will clearly
> > be the caller's.
> > If the exception happens somewhere inside the routine, you need
> > another analysis step to find out which part of the code is really
> > responsible for the problem.
>
> Perhaps it is my coding style, but (in this limited case) i would
> consider it the responsibility of the caller to handle the exception.

Oh, this is not a limited case. The vast majority of failed assertions
is in precondition checks (well, at least during debugging.)
In nearly all cases, the caller needs to be fixed. (There is the rare
occurrence that a precondition was needlessly strict. If we own the
library with the callee, we take the opportunity to weaken the
precondition in this situation.)

> There is nothing find_minimum_in can do if the heap is empty.  To me,
> that is even an unstated but obvious contract.

The difference is that the contract is explicit.
Besides, the contract isn't obvious. The routine could reasonably return
some minimum value if the heap is empty. In that case, we'd have one
precondition less and one postcondition more.

> This is not to say
> that it is not worth stating obviously and in a way that can be
> checked by a compiler.  This particular example is perhaps a little
> simple.  Certainly there are plenty of others that are not so
> obvious, where a formally stated precondition adds to the
understanding.

It's usually the other way round: Writing preconditions can relieve you
of verbiage in the description. Say you have a routine like this in
FILE:

  read (offset, number_of_bytes: INTEGER; target: BUFFER)
    -- Read 'number_of_bytes' bytes into 'target', starting at file
    -- offset 'offset'.
    -- File must be open.
    -- Do not try to read past end-of-file.

This can be rewritten in a more concise and formal way as

  read (offset, number_of_bytes: INTEGER; target: BUFFER)
    -- Read 'number_of_bytes' bytes into 'target', starting at file
    -- offset 'offset'.
  require
    must_be_open: open
    dont_read_past_eof: offset + number_of_bytes <= file_size + 1

where 'open' and 'file_size' are other functions of FILE.

The first interface is what you usually read in some software
description. It leaves much to desire: there is no indication what will
happen if the preconditions aren't fulfilled, and it doesn't tell the
programmer what exactly has to be done to make sure that the call will
not fail.

The second interface is clearer. The reaction to a failed precondition
will always be an exception, or unspecified behaviour if checking is
switched off. This is quite harsh, but people tend to write short
preconditions; if clients of 'read' want a less strict contract (say,
reading past EOF fills the rest of 'buffer' with null bytes or whatever)
then bugger the routine author.
It's also *much* more precise: the preconditions leave no question open.
The caller must make sure that the 'open' query on the FILE returns
True, and he must fulfill some precisely defined numeric inequation on
'offset' and 'number_of_bytes'. The caller can then republish the same
contract on its own interface (if the caller has such a things as
'offset' and 'number_of_bytes'), or it can translate the preconditions
to some higher abstraction. For example, a class that embodies a file
with fixed-length records might have this routine:

  read (record_number: INTEGER; target: FIXED_LENGTH_RECORD)
  require
    must_be_open: open
    dont_read_past_eof: record_number <= number_of_records
  do
    internal_file.read (record_number * record_size, target.size,
target)
  end

  open: BOOLEAN
  do
    Result := internal_file.open
  end

  number_of_records
  require
    must_be_open: open
  do
    Result := internal_file.number_of_bytes div record_size
  end

I'm leaving out details like checking that the file size is an integral
multiple of record_size, a check that will probably be done in the
'open' routine; to ensure that this is always true, we can write this:

  invariant
    integral_records:
      internal_file.number_of_bytes mod record_size = 0

Together, these specifications make sure that FILE's 'read' routine will
never be called with inappropriate parameters.
Well, unless I overlooked something - it's a bit late right now and I
don't have the time to check that the preconditions percolated up
precisely. In a real-life situation, I'd make sure that this really
holds up, either by extensive testing, or by code review; in an ideal
world, I'd ask an inference engine whether the 'read' call guarantees
all its preconditions.

> Ada also does not provide for the inheritance of contracts.  That is
> a very interesting aspect of Eiffel.

Actually this is the main concept in Design by Contract.
It's essentially the Liskov Substitutability Principle applied to
preconditions and postconditions: If you have a variable of type PARENT,
and assign to it an object of type CHILD, then everything should work as
expected - in other words, all routines in CHILD must honor all
contracts that the precursor routines in PARENT offered. (CHILD may
offer more value: its routines may require less of the caller, i.e.
loosen up the precondition, or they may guarantee more, i.e. specify a
stricter postcondition.)

Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
Reply-to address changed to discourage unsolicited advertisements.

Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Richard Riehle]

Having read this thread with interest, I have some views to share that will
probably annoy
people in both the Ada and the Eiffel community.

From everything I have seen, there is no clear picture that Design By
Contract would have
had any benefit for the Arianne V rocket.   Also, there is very little
anyone could have done
with standard Ada 83 to prevent the error.   In both cases, DBC and Ada
exception handling,
run-time checks were turned-off.   As noted by Ken Garlington earlier, even
a constraint error
check (Ada)  or an assertion check (Eiffel)  might have gone undetected in
this situation.

I think the DBC notion is an excellent one for lots of circumstances.  Maybe
not for a system
such as Arianne V.  In a system such as Arianne V, how many pre-conditions,
post-conditions,
and invariants are warranted?    Such a system typically goes through a
rapid series of state
transitions, each one governed by the previous state.   We design each
transition on the basis
of what we can predict about the current state along with what we can know
about the total
state of the system.

Under DBC we need to predict the possible states that need to be checked for
each transition
and guarantee some invariant for certain parts of the system.   We also need
to be sure the
assertion checking does not take longer than the processing required to make
the next state
transition.   In Industrial Engineering and Reliability Theory there is the
notion of 100% checking
for 0.001 % probability of error.    Do we want to do this 100% checking by
placing pre-,
post-, and invariant checks at every transition point or do we try to
predict where the system
is at risk and apply them only at those points.

Unfortunately, we in software have a poor track record for predictability.
In fact, some algorithms
are beyond our ability to predict through ordinary reasoning mechanisms.
For example, consider
Langton's Ant (you can read about it in Terry Pratchett' Science of
Discworld).   An Ant is on a
giant grid.  The squares on the grid can be either white or black.  The
algorthim is simple.  If the
Ant is on a white square, that square turns black and the ant proceeds to
the square on its left.  If
the square is black, the square turns white and the ant proceeds to the
square on its right.  (This is
a good programming exercise for students using a sparse matrix).   We can
easily declare assertions
for the states of each square, but cannot declare assertions for the state
of the entire grid.   Why?

According to Pratchett, it takes about ten thousand iterations of the
algorithm before any pattern begins
to emerge.  And that pattern is not predictable.   After ten thousand
iterations, a patter does emerge, but
there is no guarantee the pattern will not be broken after, say, twenty
million more iterations.

Large-scale software systems are often like this.  We can easily declare
simple little assertions that govern
the state of some part of the system, but it is impossible to cover all the
combinations of circumstances
at this level.   In both Eiffel and Ada we try to manage this complexity by
creating small, well-formulated,
easy-to-understand modules.   Even with that model of development, it is
still difficult to ensure that
the total state of the system (such as a rocket during launch) will not
enter into some odd combination
of circumstances that we could never predict.    We are not talking here
about the evil global variable.
We are talking about a real system in which the complexity requires multiple
engineers who must
communicate with each other and whose communication must make sense in terms
of the total product.

Assertions are not enough.  More important than the assertion is what to do
if the assertion fails.  Often,
we don't know what to do.   Again, Mr. Garlington laid out a list of common
responses to failure, but
there is no gurarantee we have selected the correct response.   No assertion
can guarantee that the
state to which we transition upon failure will be the correct new state.

Someone suggested an assertion based on some timing constraint.  That, of
course, would be very bad news.
The timing for different platforms will vary.  Instead, the assertion would
be based on the current state of
the module currently completing its operation, the postcondition along with
the state of the new module
(precondition) into which it intended to transition.   I raise this point
because it is not always clear how to
declare an assertion for a component.   The Arianne IV component might have
had a perfectly reasonable
"contract" based on its own timing mechanisms and could have failed to
protect Arianne V.  Remember,
assertions are checked at run-time, not at compile-time.   At run-time, in a
hard-deadline, real-time
system, there is very little time for the OOPS!  factor.

Both the Ada and Eiffel contributors to this discussion are endowed, I fear,
with an excess of hubris.  We
are so enamoured with our own notions of how to provide software excellence
that we oversimplify the
real issues related to this kind of software product.   Eventually, Design
By Contract, along with theorem
provers and other advances in computer science will move us all more in the
direction of more reliable
software, but it is not a finished idea yet.  It is a step in the right
direction.   Many of the ideas in Ada
will get better, and eventually Ada (as in the SPARK Examiner model already
in place) will benefit
from Design by Contract.   At present, SPARK is probably the best example of
Design By Contract,
but it is so conservative in its acceptance of contemporary ideas in
object-oriented programming that
many practitioners are reluctant to be so constrained.

One hundred years from now, those of our successors developing the
equivalent of computer software
will look back on our arguments with the same admiration we have for the
mathematicians in the time
of Charlemagne.

Arianne V was a big mistake that neither Eiffel nor Ada would have
prevented.  Let's get on with learning
how to make things work instead of beating up on each other about how much
better we are than the
other guy.

Richard Riehle
richard@adaworks.com

Re: Interesting thread in comp.lang.eiffel

[Veli-Pekka Nousiainen]

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:i4k95.7512$7%3.571616@news.flash.net...
> "Bertrand Meyer" <Bertrand_Meyer/nospam@eiffel.com> wrote in message
> news:39654639.B3760EF2@eiffel.com...
> > I am afraid we are on different wavelengths. Why was it the task of
> > the Ariane 4 software developers to learn about Ariane 5? It's the
> > other way around! If I reuse something, I am responsible for finding
> > out what its contract is and whether it fits *my* needs.
>
> In practice, it's almost impossible for the prime contractor to do an
> analysis at this level of detail (source code) for all the elements in
this
> type of system. They simply don't have the resources or expertise.
> Therefore, it's more cost effective for the prime to write system-level
> specifications -- which in some cases can be implemented with or without
> software -- and let the vendor do the next level of analysis, including
> whether the software meets the system specification (with some oversight
by
> the prime). This "divide and conquer" approach is essential given the
> diversity of systems in a platform of this type.
>
> Consider a relatively simpler system: If you replace the control computer
in
> your automobile (especially if it has ABS), do you insist that your
mechanic
> analyze its source code first? I suspect that you (and he) probably treat
> the control module as a "black box," and that he only reads the system
> "specification" (data sheet) for that module.

What if I'm _designing_ a new control computer (Endaira v.4 -> v.5)
and a new software for it. Maybe I want the contracts from
the earlier HW/SW builders and some test material?
Here we go again: You think I would have used that old
test material right away, don't you?

VPN

> > Any large project has politics.
> > The fights of departments within companies can be as bad
> > as those of cooperating nations. In this case, I think what you
> > write reinforces the understanding that this was a technical
> > and managerial software problem -- a software engineering problem,
> > which would have been prevented by the proper software engineering
> > principles and practices, including Design by Contract.
>
> I don't believe politics was the primary cause of the Ariane 5 accident.
> However, I notice that many people assume that use of proper software
> engineering techniques will overcome political and psychological barriers.
> My personal experience is that if you don't have good human and
> organizational relationships on a project, any technical approach will be
> severely degraded. I suspect this is why the inquiry's recommendations
speak
> more to this issue than to design methodology choices. Of course, it takes
a
> lot more work to understand people vs. methodologies, so maybe it's not
> surprising that a lot of people take this view.
>
> I am glad to see, however, that you now acknowledge that there was a
> managerial dimension to the problem.
>
>

Re: Interesting thread in comp.lang.eiffel

[Ken Garlington]

"Veli-Pekka Nousiainen" <vp.nousiainen@lapinlahden-teknologiakeskus.fi>
wrote in message news:vnZc5.210$2y3.8676@read2.inet.fi...
> What if I'm _designing_ a new control computer (Endaira v.4 -> v.5)
> and a new software for it. Maybe I want the contracts from
> the earlier HW/SW builders and some test material?

Certainly. Sextant had both, and used both (since they *were* the original
builders).

> Here we go again: You think I would have used that old
> test material right away, don't you?

No, you probably would have compared it against your revised requirements.
And, as in the Ariane 5 case, if your requirements had a hole in them (but
were internally consistent), you probably would have ended up with a poor
validation test (as did Ariane 5). Then, if your software was never tested
by someone who had the information that would have filled that hole, they
obviously wouldn't have caught the problem (as in the case of Ariane 5).
Then, if your software were put in the system where the hole WAS filled
(because it's the real system!), and the system executed, it quite possibly
would find the hole (as did Ariane 5 -- with catastrophic results)!

As a simple example -- determine if the implementation below meets the
requirement:

-- Requirement: Set the variable to the value 100

X := 100;

Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Kent Paul Dolan]

For those interested in how to write better software, the language is
not the issue.  Arguably the best software ever written was in some
language "HAL" of which I never heard until reading the case study in
CMU SEI's "The Capability Maturity Model".  Driest thing I've read
since falling to sleep once per page over the OSI seven level
communications model standard years ago, but somewhere in every
software practitioner's workspace should be a sign reading "It's the
_process_, stupid!".

In fact, use mine:

http://www.well.com/user/xanthian/public/rants/process.html

Humans are fallible, the best programming language with the spiffiest
constructs doesn't change that, you need a process that takes human
fallability into account and produces error free software despite it.

The case study in the above book of necessity only follows the project
studied up to the book's publication date.  Later breaking news is the
delivery of a suite of software for space shuttle control with one bug
detected ever in the delivered product.  Not "one bug per KLOC",
_one_bug_.

They got to that point with management science, not computer science.
So should we all.  W. Edwards Demming told us how long ago, and
finally, someone on this side of the Pacific listened.

Cheers!

xanthian.

               ===== random archival quality quote =====

Self Test for Paranoia:
        You know you have it when you can't think of anything that's
        your own fault.
                                -- from a fortune() program greeting

--
Kent Paul Dolan.
<xanthian@well.com> <xanthian@aztec.asu.edu> <kdolan@ebay.com>

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Ken Garlington]

"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:tavg5.2713$ED.161171@news.wenet.net...
> For those interested in how to write better software, the language is
> not the issue.

Certainly, language is not the *only* issue, but it can have an effect on
your defect rates.

> Arguably the best software ever written was in some
> language "HAL" of which I never heard until reading the case study in
> CMU SEI's "The Capability Maturity Model".

Wasn't HAL invented by Intermetrics for the space program?

> The case study in the above book of necessity only follows the project
> studied up to the book's publication date.  Later breaking news is the
> delivery of a suite of software for space shuttle control with one bug
> detected ever in the delivered product.  Not "one bug per KLOC",
> _one_bug_.

Actually, that's typical for safety-critical software -- for example, I
don't think we've ever received a single defect report from the field for
the production F-16 or F-111 digital flight controls.

> They got to that point with management science, not computer science.

Actually, we (Lockheed Martin Aero) did a benchmarking visit with the space
shuttle control team last year. They will be the first to tell you that it's
both "management science" and "computer science" (not that those are
entirely disjoint terms).

However, they will also tell you that their dollars invested per SLOC is
much higher than the industry average (again, typical for safety-critical
software). It may be that using more "computer science" (e.g., using more
COTS) will permit lower costs while still retaining the kinds of defect
rates expected for this type of software.

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Stefan Skoglund]

Ken Garlington wrote:
> Actually, that's typical for safety-critical software -- for example, I
> don't think we've ever received a single defect report from the field for
> the production F-16 or F-111 digital flight controls.

Those are military program with the belonging red-tape. Look up the
Therac-25
failures. In that case it was a purely commercial program with the
correspondingly
lack of red-tape ie that for example the FDA but also the users didn't
implement
some of the measures which is standard issue in military programs for
example
proper reporting of incidents.

In the Therac-25 case it was a classic example of a weakness transfering
in a error
and then into system failure.

Hmm wondering why the Therac-25 debacle wasn't in my real-time
programming tution.

> both "management science" and "computer science" (not that those are
> entirely disjoint terms).

ie what you do before you start project definition and after system
employement.

> 
> However, they will also tell you that their dollars invested per SLOC is
> much higher than the industry average (again, typical for safety-critical
> software). It may be that using more "computer science" (e.g., using more
> COTS) will permit lower costs while still retaining the kinds of defect
> rates expected for this type of software.

I doubt it considering that it will only cut down on amount on coding.
You still
must do proper testing for example.

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Ken Garlington]

"Stefan Skoglund" <stetson@ebox.tninet.se> wrote in message
news:3985D8F7.754A1584@ebox.tninet.se...
> Ken Garlington wrote:
> > Actually, that's typical for safety-critical software -- for example, I
> > don't think we've ever received a single defect report from the field
for
> > the production F-16 or F-111 digital flight controls.
>
> Those are military program with the belonging red-tape.

The same statement can be made for the Boeing 777, as far as I know. More to
the point, we use the same process whether we are required to follow a
specific process by the contract or not.

> Hmm wondering why the Therac-25 debacle wasn't in my real-time
> programming tution.

It wasn't covered in my real-time systems class, either, but it certainly
was included in my Software Engineering I text.

> > However, they will also tell you that their dollars invested per SLOC is
> > much higher than the industry average (again, typical for
safety-critical
> > software). It may be that using more "computer science" (e.g., using
more
> > COTS) will permit lower costs while still retaining the kinds of defect
> > rates expected for this type of software.
>
> I doubt it considering that it will only cut down on amount on coding.
> You still
> must do proper testing for example.

Actually, many of the techniques used in high-integrity software (formal
inspections, simulation, etc.) are not tied solely to the coding phase. We
are using them well before we actually write any code. Note also that the
testing process can be improved considerably by (a) reducing the number of
errors that enter the test process and (b) optimizing the test process to
require fewer tests (e.g., by automatically generating some tests from the
requirements).

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Kent Paul Dolan]

Ken Garlington <Ken.Garlington@computer.org> wrote:
>"Kent Paul Dolan" <xanthian@well.com> wrote:
>> For those interested in how to write better software, the language is
>> not the issue.

>Certainly, language is not the *only* issue, but it can have an effect on
>your defect rates.

Software folk wisdom is that any programmer can write awful code in any
language; I most recently found that reiterated by Bjarne Stroustrup in
his special edition C++ textbook.  I think neglecting language issues
to focus on process issues is going to pay off faster than the opposite
approach, and also that until you have some good process in place, the
best programming language in the world (since this is crossposted, I
won't mention her name right here) isn't going to offer much relief.

>> Arguably the best software ever written was in some
>> language "HAL" of which I never heard until reading the case study in
>> CMU SEI's "The Capability Maturity Model".

>Wasn't HAL invented by Intermetrics for the space program?

Wouldn't surprise me, since the space program was the target application.

>> The case study in the above book of necessity only follows the project
>> studied up to the book's publication date.  Later breaking news is the
>> delivery of a suite of software for space shuttle control with one bug
>> detected ever in the delivered product.  Not "one bug per KLOC",
>> _one_bug_.

>Actually, that's typical for safety-critical software -- for example, I
>don't think we've ever received a single defect report from the field for
>the production F-16 or F-111 digital flight controls.

>> They got to that point with management science, not computer science.

>Actually, we (Lockheed Martin Aero) did a benchmarking visit with the space
>shuttle control team last year. They will be the first to tell you that it's
>both "management science" and "computer science" (not that those are
>entirely disjoint terms).

Happy to hear, since you bought the team from IBM, that you are taking the
time to spread the benefits at least internally!!

I'd rather think of it as a computer specialization of well known
management science approaches.  What I was taught in formal education
as "computer science" had nothing to do with what these people used to
achieve their astonishing software error rate.

>However, they will also tell you that their dollars invested per SLOC is
>much higher than the industry average (again, typical for safety-critical
>software). It may be that using more "computer science" (e.g., using more
>COTS) will permit lower costs while still retaining the kinds of defect
>rates expected for this type of software.

Yep, they spent about four times the industry average per SLOC for that
software.  From my point of view, that just means the industry _way_
underfunds software development, with the results we all know and
detest.

Software _looks_ so simple, and the estimates are _so_ optimistic, that
the old well worn ideas: "you will always build a prototype, some
groups just find that out later than others", paraphrasing Fred Brooks,
get ignored in doing the up front cost estimates.  This group as part
of its mandatory, customer funded process, builds and throws away one
complete prototype, just to assure that they know where the software
problems are going to arise, _before_ starting coding, or finalizing
architecture or design, on the deliverable software.

It's when you find out that software productivity, between competent
practitioners, can vary by 100::1, and that all the testing in the
world lets buggy software out the door, that you begin to realize that
software is not simple, not well understood, not well managed, and not
well accomplished, with vanishingly few exceptions, the one under
review being one of them.

Cheers!

xanthian.

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Ken Garlington]

"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:hwoh5.3977$ED.168424@news.wenet.net...
> Ken Garlington <Ken.Garlington@computer.org> wrote:
> >"Kent Paul Dolan" <xanthian@well.com> wrote:
> >> For those interested in how to write better software, the language is
> >> not the issue.
>
> >Certainly, language is not the *only* issue, but it can have an effect on
> >your defect rates.
>
> Software folk wisdom is that any programmer can write awful code in any
> language; I most recently found that reiterated by Bjarne Stroustrup in
> his special edition C++ textbook.  I think neglecting language issues
> to focus on process issues is going to pay off faster than the opposite
> approach, and also that until you have some good process in place, the
> best programming language in the world (since this is crossposted, I
> won't mention her name right here) isn't going to offer much relief.

There's two bad assumptions here:

(1) "Software folk wisdom" is better than data from controlled case studies.
This is CMM level 2 thinking at best.

(2) Considering languages issues and "process issues" is mutually exclusive.
Not true - you can (and should) consider all sources of error in an
effective software quality program. (For example, although Brooks discusses
a number of process issues, he also notes that "programming productivity may
be increased as much as five times when a suitable high-level language is
used.")


> I'd rather think of it as a computer specialization of well known
> management science approaches.  What I was taught in formal education
> as "computer science" had nothing to do with what these people used to
> achieve their astonishing software error rate.

Certainly, there may be formal computer science programs that don't offer
software engineering courses. However, I'd guess that most programs today do
not consider these as mutually exclusive. I've taken a number of courses in
both management sciences and software engineering. Although there's some
overlap (as there is with many other engineering fields, such as petroleum
engineering and chemical engineering), I don't think you could honestly
consider it as just as "specialization" of management science.

> Yep, they spent about four times the industry average per SLOC for that
> software.  From my point of view, that just means the industry _way_
> underfunds software development, with the results we all know and
> detest.

However, there are groups that get the same results as the space shuttle
program at significantly less cost. Again, when you look at the case studies
vs. "folk wisdom," the results may be surprising.

> Software _looks_ so simple, and the estimates are _so_ optimistic, that
> the old well worn ideas: "you will always build a prototype, some
> groups just find that out later than others", paraphrasing Fred Brooks,
> get ignored in doing the up front cost estimates.  This group as part
> of its mandatory, customer funded process, builds and throws away one
> complete prototype, just to assure that they know where the software
> problems are going to arise, _before_ starting coding, or finalizing
> architecture or design, on the deliverable software.

Interestingly, Brooks withdrew this advice in the 1995 edition of Mythical
Man-Month, as it tends to assume the waterfall model. He suggests in his
revised book that an incremental-build model is better. In fact, one of the
specific models he describes is the Microsoft "build every night" approach!

> It's when you find out that software productivity, between competent
> practitioners, can vary by 100::1, and that all the testing in the
> world lets buggy software out the door, that you begin to realize that
> software is not simple, not well understood, not well managed, and not
> well accomplished, with vanishingly few exceptions, the one under
> review being one of them.

However, CMM level 4 companies are finding that they (a) can control
variation in the software development process, putting the lie to the
"100:1" variation that was seen when there was no attempt to control the
process and (b) can use things such as formal inspections to significantly
reduce error rates earlier in the process than traditional testing.

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Simon Brady]

Kent Paul Dolan wrote:
> 
> The case study in the above book of necessity only follows the project
> studied up to the book's publication date.  Later breaking news is the
> delivery of a suite of software for space shuttle control with one bug
> detected ever in the delivered product.  Not "one bug per KLOC",
> _one_bug_.

A good article on the Shuttle development process and culture is:

   http://www.fastcompany.com/online/06/writestuff.html

Simon Brady                                            sjbrady
Research Assistant, Computer Science Dept.               at
University of Otago, Dunedin, New Zealand            acm dot org

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[John Magness]

I read the document at the link.  There are many things it does not mention.
In 1992 I took an Ada language course from an adjunct professor who was an
IBM employee.
He was a member of the shuttle flight software development team.  He told
the class that NASA had asked IBM to determine the cost of the delivered
code. The result of the study was $5000.00 per line of delivered code.
That's late '80's dollars I think.

    I can not speak to the current practice, but prior to 1990, the flight
software was tested in a systems integration laboratory, then was
transferred to the Shuttle Mission Simulation for further testing & crew
training.  The SMS consisted of two crew trainers, each of which had a full
set of flight computers.  The flight software would have patches added due
to the training requirements i.e. Being able to start training at any point
in a mission time line, etc.  By the completion of mission training, the
flight software had been executed thousands of times, with nominal & off
nominal conditions.  The simulation had several thousand  malfunctions that
the instructors could insert into a training session. Traditionally, the
crew would be trained repeatedly for all crucial phases of a mission:
Takeoff, deorbit & landing, emergency landings,
on orbit maneuvers, payload deployment, etc.  At the end of the training
cycle, the crew would fly a complete mission timeline, takeoff to landing.
Generally, the crew were permitted to return to their homes during the
scheduled sleep cycle.

    During the '80's several flight software errors were found, but I can
not give an actual count.  Mind, that at times the simulators run integrated
with MCC, Cape Canaveral, White Sands, & Redstone. Simultaneously.

    The delivered cost for the flight simulators was over $100 M. In late
1970's dollars.
The flight software development cycle then & now has what could be
considered extensive acceptance testing  prior to actual use.

    By the way, I believe that during one of the Gemini missions the flight
software was patched on orbit.

Simon Brady wrote:

> Kent Paul Dolan wrote:
> >
> > The case study in the above book of necessity only follows the project
> > studied up to the book's publication date.  Later breaking news is the
> > delivery of a suite of software for space shuttle control with one bug
> > detected ever in the delivered product.  Not "one bug per KLOC",
> > _one_bug_.
>
> A good article on the Shuttle development process and culture is:
>
>    http://www.fastcompany.com/online/06/writestuff.html
>
> Simon Brady                                            sjbrady
> Research Assistant, Computer Science Dept.               at
> University of Otago, Dunedin, New Zealand            acm dot org

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Simon Brady]

John Magness wrote:
> 
> In 1992 I took an Ada language course from an adjunct professor who was an
> IBM employee.
> He was a member of the shuttle flight software development team.  He told
> the class that NASA had asked IBM to determine the cost of the delivered
> code. The result of the study was $5000.00 per line of delivered code.
> That's late '80's dollars I think.

What could NASA do to reduce this cost? It seems to me they have three
options:

1. Accept (potentially) lower-quality software and fly with increased
risk.

2. Accept lower-quality software but make system-wide adjustments so
overall risk isn't reduced (e.g. put in more non-software backup)

3. Find a way to produce software of the same quality while using a
cheaper process

(1) is probably the easiest route to take, since risk is hard to
quantify (until it bites you) and "acceptable" risk is a function of all
sorts of malleable social and politcal factors. Of course we have to ask
"acceptable to whom?", and the tradeoffs don't seem at all obvious: how
does one determine the ultimate cost (to national morale, support for
the space program and related industries, etc.) of losing a Shuttle?

Speaking as a software geek, (2) feels like a step backward, yet it
still seems to be an embarressingly appropriate option for many systems
(remember Therac-25). But is it really practical for something as
complex as the Shuttle? Or have we reached a "damned if we do, damned if
we don't" point where we have no choice but to rely on software, creaky
as it may be?

(3) is, IMO, the holy grail of software engineering. If anyone has
realistic suggestions of how it could be done (for the Shuttle or any
similar CMM-5 shop), I for one would be interested to hear them.

Simon Brady                                            sjbrady
Research Assistant, Computer Science Dept.               at
University of Otago, Dunedin, New Zealand            acm dot org

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Ken Garlington]

> 3. Find a way to produce software of the same quality while using a
> cheaper process
>
> (3) is, IMO, the holy grail of software engineering. If anyone has
> realistic suggestions of how it could be done (for the Shuttle or any
> similar CMM-5 shop), I for one would be interested to hear them.

In fact, a true "CMM 5" shop will be generating their *own* ideas on how to
reduce costs (which, in fact, I believe they are doing in Houston). I can't
get into proprietary issues here, but as a general rule there is no process
that can't be optimized -- even a process for high-integrity software.

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Simon Brady]

I wrote:
> 
> 1. Accept (potentially) lower-quality software and fly with increased
> risk.

Now that I think about it, it's wimpy to say "potentially" here.
Software quality isn't just about lack of bugs, it's about _confidence_
that there's a lack of bugs. So if they cut testing (and hence lowered
their confidence in the software), I would argue that they're still
delivering a lower-quality product even if it happened to be bug-free.
Of course, some might say such a purist approach is commercially naive,
but then that's why I'm not a commercial programmer :-)

Simon Brady                                            sjbrady
Research Assistant, Computer Science Dept.               at
University of Otago, Dunedin, New Zealand            acm dot org

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Robert I. Eachus]

Simon Brady wrote:
 
> Now that I think about it, it's wimpy to say "potentially" here.
> Software quality isn't just about lack of bugs, it's about _confidence_
> that there's a lack of bugs. So if they cut testing (and hence lowered
> their confidence in the software), I would argue that they're still
> delivering a lower-quality product even if it happened to be bug-free.
> Of course, some might say such a purist approach is commercially naive,
> but then that's why I'm not a commercial programmer :-)

   There is a very subtle, but insidious fallacy in the above.  Not to
do ANY testing is quite likely to result in catastrophic failure.  On
the other hand, testing should always be one part, and often not the
largest part, of a well planned quality assurance program.  In fact, on
a well managed project, anything found at preliminary design review time
to be potentially difficult or impossible to test should be flagged for
further design effort in an attempt to
reduce overall cost.  Sometimes you need to do those 'expensive' tests,
that would have been cheap at almost any price on Ariane 5.  But if you
can change the design to make testing easier without impacting other
requirements, do so.

   For another example, it is costly to create a thread level model of
control flow in a large system.  But if it is necessary to do so, often
for timing analysis reasons, the model can also be used to do other
analysis of project software.  (Of course, this requires that the model
be kept up to date during development.)  On one project where this was
done, it was determined that there was a race condition that could
transition the system to a subset of states that could not be left. 
(This was done using hierarchical colored Petri nets.)  Fixing this bug,
which could have remained undiscovered for the life of the system, let
alone througout testing, was trivial.  Of course, if it had been
discovered in a fielded system, it would probably have caused a plane to
crash during landing.  No amount of testing could have produced that
level of trust
in the software, even if it had resulted in the discovery of that bug.

Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[Simon Brady]

"Robert I. Eachus" wrote:
> 
> Simon Brady wrote:
> 
> > Now that I think about it, it's wimpy to say "potentially" here.
> > Software quality isn't just about lack of bugs, it's about _confidence_
> > that there's a lack of bugs. So if they cut testing (and hence lowered
> > their confidence in the software), I would argue that they're still
> > delivering a lower-quality product even if it happened to be bug-free.
> > Of course, some might say such a purist approach is commercially naive,
> > but then that's why I'm not a commercial programmer :-)
> 
>    There is a very subtle, but insidious fallacy in the above.  Not to
> do ANY testing is quite likely to result in catastrophic failure.  On
> the other hand, testing should always be one part, and often not the
> largest part, of a well planned quality assurance program.

A valid point well-made, Robert. I was rather sloppily using "testing"
as shorthand for "all that process-related stuff that improves quality".
Thanks for not letting me get away with such hand-waving (which, as you
point out, could have disastrous consequences in a real project).

Simon Brady                                            sjbrady
Research Assistant, Computer Science Dept.               at
University of Otago, Dunedin, New Zealand            acm dot org

Re: Interesting thread in comp.lang.eiffel

[Veli-Pekka Nousiainen]

Hi, Bertrand !
"Bertrand Meyer" <Bertrand_Meyer/nospam@eiffel.com> wrote in message
news:395E5D16.C4D109F1@eiffel.com...
X
2 ? When?
> - With EiffelVision 2, it is possible thanks to
>   agents to have little or no "glue" code (the
>   C in MVC) between the business model of an application
>   (what it actually does), and its GUI clusters.
>   Thanks to agents you can directly associate
>   actions from the business model with events
>   from the graphical interface. This builds on the
>   notion of command, already present in
>   EiffelVision 1, but makes it much simpler
>   to use.
>
> - Regarding assertions, the prospect of a fully
>   contracted EiffelBase -- a set of data structure
>   and algorithms classes equipped with full
>   specifications -- seems attainable.
>
> The current performance overhead, by the way, is not a fatality.
> There will always remain a penalty but it may be possible
> to bring it down considerably if the goal of loop-free programming

It will - eventually.

> becomes paramount to Eiffel users. Outside of iterator-like uses,
> agents have proved to pose no global performance problem.
>
> -- Bertrand Meyer
> ISE Inc.
> http://www.eiffel.com      http://www.tools-conferences.com

VPN