* Re: Interresting thread in comp.lang.eiffel [not found] ` <94S95.9936$7%3.667320@news.flash.net> @ 2000-07-13 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Interresting thread in comp.lang.eiffel Joachim Durchholz @ 2000-07-14 0:00 ` Ken Garlington 2000-07-16 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-14 0:00 ` Ken Garlington @ 2000-07-16 0:00 ` Joachim Durchholz 2000-07-16 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-16 0:00 ` Joachim Durchholz @ 2000-07-16 0:00 ` Ken Garlington 0 siblings, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-16 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <slrn8leffq.ebq.gisle@spurv.ii.uib.no>]
[parent not found: <395886DA.CCE008D2@deepthought.com.au>]
[parent not found: <3958B07B.18A5BB8C@acm.com>]
[parent not found: <y1d65.620$7%3.33446@news.flash.net>]
[parent not found: <395A0ECA.940560D1@acm.com>]
[parent not found: <8jd4bb$na7$1@toralf.uib.no>]
[parent not found: <8jfabb$1d8$1@nnrp1.deja.com>]
[parent not found: <SVH65.1596$7%3.129344@news.flash.net>]
[parent not found: <8jt4i0$18ec7$1@ID-9852.news.cis.dfn.de>]
[parent not found: <nSt85.5388$7%3.424540@news.flash.net>]
[parent not found: <8k5a31$1p61t$1@ID-9852.news.cis.dfn.de>]
[parent not found: <qlt95.7824$7%3.596314@news.flash.net>]
[parent not found: <3966D7B0.5D6475E4@earthlink.net>]
[parent not found: <A5J95.9237$7%3.638838@news.flash.net>]
* Re: Interresting thread in comp.lang.eiffel [not found] ` <A5J95.9237$7%3.638838@news.flash.net> @ 2000-07-12 0:00 ` Robert I. Eachus 2000-07-13 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Robert I. Eachus @ 2000-07-12 0:00 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Robert I. Eachus @ 2000-07-13 0:00 ` Ken Garlington 2000-07-23 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 102+ messages in thread From: Ken Garlington @ 2000-07-13 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Ken Garlington @ 2000-07-23 0:00 ` Robert I. Eachus 2000-07-23 0:00 ` Ken Garlington 2000-07-24 0:00 ` David Gillon 0 siblings, 2 replies; 102+ messages in thread From: Robert I. Eachus @ 2000-07-23 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-23 0:00 ` Robert I. Eachus @ 2000-07-23 0:00 ` Ken Garlington 2000-07-24 0:00 ` swhalen 2000-07-24 0:00 ` David Gillon 2000-07-24 0:00 ` David Gillon 1 sibling, 2 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-23 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-23 0:00 ` Ken Garlington @ 2000-07-24 0:00 ` swhalen 2000-07-24 0:00 ` David Gillon 1 sibling, 0 replies; 102+ messages in thread From: swhalen @ 2000-07-24 0:00 UTC (permalink / raw) 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 ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-23 0:00 ` Ken Garlington 2000-07-24 0:00 ` swhalen @ 2000-07-24 0:00 ` David Gillon 2000-07-24 0:00 ` Ken Garlington 1 sibling, 1 reply; 102+ messages in thread From: David Gillon @ 2000-07-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-24 0:00 ` David Gillon @ 2000-07-24 0:00 ` Ken Garlington 0 siblings, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-24 0:00 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-23 0:00 ` Robert I. Eachus 2000-07-23 0:00 ` Ken Garlington @ 2000-07-24 0:00 ` David Gillon 1 sibling, 0 replies; 102+ messages in thread From: David Gillon @ 2000-07-24 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <39688CA2.31B2A7EF@acm.com>]
* Re: Interresting thread in comp.lang.eiffel [not found] ` <39688CA2.31B2A7EF@acm.com> @ 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` Marin D. Condic 0 siblings, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Joachim Durchholz @ 2000-07-13 0:00 ` Marin D. Condic 0 siblings, 0 replies; 102+ messages in thread From: Marin D. Condic @ 2000-07-13 0:00 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <8k8p8m$1upjk$1@ID-9852.news.cis.dfn.de>]
[parent not found: <0cS95.9944$7%3.667682@news.flash.net>]
* Re: Interresting thread in comp.lang.eiffel [not found] ` <0cS95.9944$7%3.667682@news.flash.net> @ 2000-07-13 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Joachim Durchholz @ 2000-07-14 0:00 ` Ken Garlington 0 siblings, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <8jhq0m$30u5$1@toralf.uib.no>]
[parent not found: <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de>]
[parent not found: <3963CDDE.3E8FB644@earthlink.net>]
[parent not found: <8k5alv$1oogm$1@ID-9852.news.cis.dfn.de>]
[parent not found: <Rmt95.7825$7%3.595826@news.flash.net>]
* Re: Interresting thread in comp.lang.eiffel [not found] ` <Rmt95.7825$7%3.595826@news.flash.net> @ 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` Marin D. Condic ` (2 more replies) 0 siblings, 3 replies; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Joachim Durchholz @ 2000-07-13 0:00 ` Marin D. Condic 2000-07-14 0:00 ` Ken Garlington 2000-07-14 0:00 ` Ken Garlington 2 siblings, 0 replies; 102+ messages in thread From: Marin D. Condic @ 2000-07-13 0:00 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` Marin D. Condic @ 2000-07-14 0:00 ` Ken Garlington 2000-07-16 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington 2 siblings, 1 reply; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) "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." ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-14 0:00 ` Ken Garlington @ 2000-07-16 0:00 ` Joachim Durchholz 2000-07-16 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-16 0:00 ` Joachim Durchholz @ 2000-07-16 0:00 ` Ken Garlington 2000-07-19 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 102+ messages in thread From: Ken Garlington @ 2000-07-16 0:00 UTC (permalink / raw) "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... ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-16 0:00 ` Ken Garlington @ 2000-07-19 0:00 ` Joachim Durchholz 2000-07-19 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-19 0:00 ` Joachim Durchholz @ 2000-07-19 0:00 ` Ken Garlington 0 siblings, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-19 0:00 UTC (permalink / raw) "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*. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` Marin D. Condic 2000-07-14 0:00 ` Ken Garlington @ 2000-07-14 0:00 ` Ken Garlington 2000-07-14 0:00 ` Marin D. Condic 2 siblings, 1 reply; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-14 0:00 ` Ken Garlington @ 2000-07-14 0:00 ` Marin D. Condic 2000-07-14 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Marin D. Condic @ 2000-07-14 0:00 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-14 0:00 ` Marin D. Condic @ 2000-07-14 0:00 ` Ken Garlington 0 siblings, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <3963DEBF.79C40BF1@eiffel.com>]
[parent not found: <2LS85.6100$7%3.493920@news.flash.net>]
[parent not found: <8k5aru$1odtq$1@ID-9852.news.cis.dfn.de>]
[parent not found: <Rnt95.7826$7%3.596208@news.flash.net>]
[parent not found: <8k8pk2$20cab$1@ID-9852.news.cis.dfn.de>]
[parent not found: <_dS95.9945$7%3.666180@news.flash.net>]
* Re: Interresting thread in comp.lang.eiffel [not found] ` <_dS95.9945$7%3.666180@news.flash.net> @ 2000-07-12 0:00 ` David K Allen 2000-07-12 0:00 ` Ken Garlington ` (2 more replies) 0 siblings, 3 replies; 102+ messages in thread From: David K Allen @ 2000-07-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` David K Allen @ 2000-07-12 0:00 ` Ken Garlington 2000-07-12 0:00 ` David K Allen 2000-07-12 0:00 ` David K Allen 2000-07-12 0:00 ` David Gillon 2000-07-12 0:00 ` Bob Allen 2 siblings, 2 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-12 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Ken Garlington @ 2000-07-12 0:00 ` David K Allen 2000-07-13 0:00 ` Howard W. LUDWIG 2000-07-14 0:00 ` Ken Garlington 2000-07-12 0:00 ` David K Allen 1 sibling, 2 replies; 102+ messages in thread From: David K Allen @ 2000-07-12 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` David K Allen @ 2000-07-13 0:00 ` Howard W. LUDWIG 2000-07-13 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington 2000-07-14 0:00 ` Ken Garlington 1 sibling, 2 replies; 102+ messages in thread From: Howard W. LUDWIG @ 2000-07-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Howard W. LUDWIG @ 2000-07-13 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington 1 sibling, 0 replies; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Howard W. LUDWIG 2000-07-13 0:00 ` Joachim Durchholz @ 2000-07-14 0:00 ` Ken Garlington 1 sibling, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` David K Allen 2000-07-13 0:00 ` Howard W. LUDWIG @ 2000-07-14 0:00 ` Ken Garlington 2000-07-18 0:00 ` Veli-Pekka Nousiainen 1 sibling, 1 reply; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-14 0:00 ` Ken Garlington @ 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-19 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Veli-Pekka Nousiainen @ 2000-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-18 0:00 ` Veli-Pekka Nousiainen @ 2000-07-19 0:00 ` Ken Garlington 2000-07-19 0:00 ` Bob Allen 0 siblings, 1 reply; 102+ messages in thread From: Ken Garlington @ 2000-07-19 0:00 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-19 0:00 ` Ken Garlington @ 2000-07-19 0:00 ` Bob Allen 0 siblings, 0 replies; 102+ messages in thread From: Bob Allen @ 2000-07-19 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Ken Garlington 2000-07-12 0:00 ` David K Allen @ 2000-07-12 0:00 ` David K Allen 1 sibling, 0 replies; 102+ messages in thread From: David K Allen @ 2000-07-12 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` David K Allen 2000-07-12 0:00 ` Ken Garlington @ 2000-07-12 0:00 ` David Gillon 2000-07-13 0:00 ` Joachim Durchholz ` (2 more replies) 2000-07-12 0:00 ` Bob Allen 2 siblings, 3 replies; 102+ messages in thread From: David Gillon @ 2000-07-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` David Gillon @ 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` David Gillon 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2 siblings, 0 replies; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` David Gillon 2000-07-13 0:00 ` Joachim Durchholz @ 2000-07-13 0:00 ` David Gillon 2000-07-13 0:00 ` David K Allen 2000-07-14 0:00 ` Ken Garlington 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2 siblings, 2 replies; 102+ messages in thread From: David Gillon @ 2000-07-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` David Gillon @ 2000-07-13 0:00 ` David K Allen 2000-07-13 0:00 ` Bob Allen 2000-07-14 0:00 ` Ken Garlington 1 sibling, 1 reply; 102+ messages in thread From: David K Allen @ 2000-07-13 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` David K Allen @ 2000-07-13 0:00 ` Bob Allen 2000-07-13 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 102+ messages in thread From: Bob Allen @ 2000-07-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Bob Allen @ 2000-07-13 0:00 ` Joachim Durchholz 2000-07-18 0:00 ` Veli-Pekka Nousiainen 0 siblings, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Joachim Durchholz @ 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-19 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 102+ messages in thread From: Veli-Pekka Nousiainen @ 2000-07-18 0:00 UTC (permalink / raw) 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. > > ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-18 0:00 ` Veli-Pekka Nousiainen @ 2000-07-19 0:00 ` Joachim Durchholz 0 siblings, 0 replies; 102+ messages in thread From: Joachim Durchholz @ 2000-07-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` David Gillon 2000-07-13 0:00 ` David K Allen @ 2000-07-14 0:00 ` Ken Garlington 1 sibling, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` David Gillon 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` David Gillon @ 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-19 0:00 ` David Gillon 2 siblings, 1 reply; 102+ messages in thread From: Veli-Pekka Nousiainen @ 2000-07-18 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-18 0:00 ` Veli-Pekka Nousiainen @ 2000-07-19 0:00 ` David Gillon 0 siblings, 0 replies; 102+ messages in thread From: David Gillon @ 2000-07-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` David K Allen 2000-07-12 0:00 ` Ken Garlington 2000-07-12 0:00 ` David Gillon @ 2000-07-12 0:00 ` Bob Allen 2000-07-12 0:00 ` Ken Garlington 2 siblings, 1 reply; 102+ messages in thread From: Bob Allen @ 2000-07-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Bob Allen @ 2000-07-12 0:00 ` Ken Garlington 2000-07-13 0:00 ` Bob Allen 0 siblings, 1 reply; 102+ messages in thread From: Ken Garlington @ 2000-07-12 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Ken Garlington @ 2000-07-13 0:00 ` Bob Allen 2000-07-14 0:00 ` Ken Garlington 0 siblings, 1 reply; 102+ messages in thread From: Bob Allen @ 2000-07-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-13 0:00 ` Bob Allen @ 2000-07-14 0:00 ` Ken Garlington 2000-07-14 0:00 ` carr_tom 2000-07-14 0:00 ` Marin D. Condic 0 siblings, 2 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-14 0:00 UTC (permalink / raw) "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!). ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-14 0:00 ` Ken Garlington @ 2000-07-14 0:00 ` carr_tom 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-14 0:00 ` Marin D. Condic 1 sibling, 1 reply; 102+ messages in thread From: carr_tom @ 2000-07-14 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-14 0:00 ` carr_tom @ 2000-07-18 0:00 ` Veli-Pekka Nousiainen 0 siblings, 0 replies; 102+ messages in thread From: Veli-Pekka Nousiainen @ 2000-07-18 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-14 0:00 ` Ken Garlington 2000-07-14 0:00 ` carr_tom @ 2000-07-14 0:00 ` Marin D. Condic 1 sibling, 0 replies; 102+ messages in thread From: Marin D. Condic @ 2000-07-14 0:00 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <Rnt95.78 <L6vb5.16117$7%3.988701@news.flash.net>]
* Re: Interresting thread in comp.lang.eiffel [not found] ` <Rnt95.78 <L6vb5.16117$7%3.988701@news.flash.net> @ 2000-07-14 0:00 ` Nick Williams 0 siblings, 0 replies; 102+ messages in thread From: Nick Williams @ 2000-07-14 0:00 UTC (permalink / raw) 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/ ] ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <396502D2.BD8A42E7@earthlink.net>]
[parent not found: <RSsa5.11075$7%3.784507@news.flash.net>]
[parent not found: <6aHa5.113$6E.23141@ptah.visi.com>]
[parent not found: <396B4A68.458FA3BC@maths.unine.ch>]
[parent not found: <u6hp4i16$GA.283@cpmsnbbsa07>]
* Re: Interresting thread in comp.lang.eiffel [not found] ` <u6hp4i16$GA.283@cpmsnbbsa07> @ 2000-07-11 0:00 ` cropt 2000-07-11 0:00 ` Ken Garlington 1 sibling, 0 replies; 102+ messages in thread From: cropt @ 2000-07-11 0:00 UTC (permalink / raw) > 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} ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel [not found] ` <u6hp4i16$GA.283@cpmsnbbsa07> 2000-07-11 0:00 ` cropt @ 2000-07-11 0:00 ` Ken Garlington 2000-07-12 0:00 ` Peter Amey 2000-07-12 0:00 ` Bob Allen 1 sibling, 2 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-11 0:00 UTC (permalink / raw) "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... :) ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-11 0:00 ` Ken Garlington @ 2000-07-12 0:00 ` Peter Amey 2000-07-12 0:00 ` Peter Amey 2000-07-13 0:00 ` Joachim Durchholz 2000-07-12 0:00 ` Bob Allen 1 sibling, 2 replies; 102+ messages in thread From: Peter Amey @ 2000-07-12 0:00 UTC (permalink / raw) 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/ -------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Peter Amey @ 2000-07-12 0:00 ` Peter Amey 2000-07-13 0:00 ` Joachim Durchholz 1 sibling, 0 replies; 102+ messages in thread From: Peter Amey @ 2000-07-12 0:00 UTC (permalink / raw) 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/ -------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Peter Amey 2000-07-12 0:00 ` Peter Amey @ 2000-07-13 0:00 ` Joachim Durchholz 1 sibling, 0 replies; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-11 0:00 ` Ken Garlington 2000-07-12 0:00 ` Peter Amey @ 2000-07-12 0:00 ` Bob Allen 2000-07-12 0:00 ` David Starner 2000-07-12 0:00 ` Ken Garlington 1 sibling, 2 replies; 102+ messages in thread From: Bob Allen @ 2000-07-12 0:00 UTC (permalink / raw) > > 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Bob Allen @ 2000-07-12 0:00 ` David Starner 2000-07-12 0:00 ` Ken Garlington 1 sibling, 0 replies; 102+ messages in thread From: David Starner @ 2000-07-12 0:00 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interresting thread in comp.lang.eiffel 2000-07-12 0:00 ` Bob Allen 2000-07-12 0:00 ` David Starner @ 2000-07-12 0:00 ` Ken Garlington 1 sibling, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-12 0:00 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <39654639.B3760EF2@eiffel.com>]
[parent not found: <i4k95.7512$7%3.571616@news.flash.net>]
[parent not found: <oqog45g1j0.fsf@premise.demon.co.uk>]
[parent not found: <85Fa5.11419$7%3.818927@news.flash.net>]
* Aspects (Re: Interesting thread in comp.lang.eiffel) [not found] ` <85Fa5.11419$7%3.818927@news.flash.net> @ 2000-07-11 0:00 ` tom 2000-07-12 0:00 ` Veli-Pekka Nousiainen 2000-07-12 0:00 ` Steve Merrick 2000-07-12 0:00 ` Design by Contract (was " David Kristola 1 sibling, 2 replies; 102+ messages in thread From: tom @ 2000-07-11 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Aspects (Re: Interesting thread in comp.lang.eiffel) 2000-07-11 0:00 ` Aspects (Re: Interesting thread in comp.lang.eiffel) tom @ 2000-07-12 0:00 ` Veli-Pekka Nousiainen 2000-07-12 0:00 ` tom 2000-07-12 0:00 ` Steve Merrick 1 sibling, 1 reply; 102+ messages in thread From: Veli-Pekka Nousiainen @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Aspects (Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Veli-Pekka Nousiainen @ 2000-07-12 0:00 ` tom 0 siblings, 0 replies; 102+ messages in thread From: tom @ 2000-07-12 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Aspects (Re: Interesting thread in comp.lang.eiffel) 2000-07-11 0:00 ` Aspects (Re: Interesting thread in comp.lang.eiffel) tom 2000-07-12 0:00 ` Veli-Pekka Nousiainen @ 2000-07-12 0:00 ` Steve Merrick 2000-07-12 0:00 ` Frank Mitchell 1 sibling, 1 reply; 102+ messages in thread From: Steve Merrick @ 2000-07-12 0:00 UTC (permalink / raw) "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." ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Aspects (Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Steve Merrick @ 2000-07-12 0:00 ` Frank Mitchell 2000-07-14 0:00 ` Jubilation 0 siblings, 1 reply; 102+ messages in thread From: Frank Mitchell @ 2000-07-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Aspects (Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Frank Mitchell @ 2000-07-14 0:00 ` Jubilation 2000-07-14 0:00 ` Frank Mitchell 0 siblings, 1 reply; 102+ messages in thread From: Jubilation @ 2000-07-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Aspects (Re: Interesting thread in comp.lang.eiffel) 2000-07-14 0:00 ` Jubilation @ 2000-07-14 0:00 ` Frank Mitchell 2000-07-15 0:00 ` Jubilation 0 siblings, 1 reply; 102+ messages in thread From: Frank Mitchell @ 2000-07-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Aspects (Re: Interesting thread in comp.lang.eiffel) 2000-07-14 0:00 ` Frank Mitchell @ 2000-07-15 0:00 ` Jubilation 0 siblings, 0 replies; 102+ messages in thread From: Jubilation @ 2000-07-15 0:00 UTC (permalink / raw) -- 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Design by Contract (was Re: Interesting thread in comp.lang.eiffel) [not found] ` <85Fa5.11419$7%3.818927@news.flash.net> 2000-07-11 0:00 ` Aspects (Re: Interesting thread in comp.lang.eiffel) tom @ 2000-07-12 0:00 ` David Kristola 2000-07-12 0:00 ` Greg 2000-07-12 0:00 ` Howard W. LUDWIG 1 sibling, 2 replies; 102+ messages in thread From: David Kristola @ 2000-07-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Design by Contract (was " David Kristola @ 2000-07-12 0:00 ` Greg 2000-07-12 0:00 ` Matthew J Heaney 2000-07-12 0:00 ` Howard W. LUDWIG 1 sibling, 1 reply; 102+ messages in thread From: Greg @ 2000-07-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Greg @ 2000-07-12 0:00 ` Matthew J Heaney 2000-07-13 0:00 ` Eirik Mangseth 0 siblings, 1 reply; 102+ messages in thread From: Matthew J Heaney @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Matthew J Heaney @ 2000-07-13 0:00 ` Eirik Mangseth 0 siblings, 0 replies; 102+ messages in thread From: Eirik Mangseth @ 2000-07-13 0:00 UTC (permalink / raw) "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" ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Design by Contract (was " David Kristola 2000-07-12 0:00 ` Greg @ 2000-07-12 0:00 ` Howard W. LUDWIG 2000-07-12 0:00 ` Greg 2000-07-13 0:00 ` Joachim Durchholz 1 sibling, 2 replies; 102+ messages in thread From: Howard W. LUDWIG @ 2000-07-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Howard W. LUDWIG @ 2000-07-12 0:00 ` Greg 2000-07-12 0:00 ` Eirik Mangseth 2000-07-13 0:00 ` Joachim Durchholz 1 sibling, 1 reply; 102+ messages in thread From: Greg @ 2000-07-12 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Greg @ 2000-07-12 0:00 ` Eirik Mangseth 0 siblings, 0 replies; 102+ messages in thread From: Eirik Mangseth @ 2000-07-12 0:00 UTC (permalink / raw) "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 > ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-12 0:00 ` Howard W. LUDWIG 2000-07-12 0:00 ` Greg @ 2000-07-13 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` David Kristola 1 sibling, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-13 0:00 ` Joachim Durchholz @ 2000-07-14 0:00 ` David Kristola 2000-07-14 0:00 ` Matthew J Heaney 2000-07-16 0:00 ` Joachim Durchholz 0 siblings, 2 replies; 102+ messages in thread From: David Kristola @ 2000-07-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-14 0:00 ` David Kristola @ 2000-07-14 0:00 ` Matthew J Heaney 2000-07-16 0:00 ` Joachim Durchholz 1 sibling, 0 replies; 102+ messages in thread From: Matthew J Heaney @ 2000-07-14 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-14 0:00 ` David Kristola 2000-07-14 0:00 ` Matthew J Heaney @ 2000-07-16 0:00 ` Joachim Durchholz 2000-07-17 0:00 ` David Kristola 1 sibling, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-16 0:00 ` Joachim Durchholz @ 2000-07-17 0:00 ` David Kristola 2000-07-19 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 102+ messages in thread From: David Kristola @ 2000-07-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-17 0:00 ` David Kristola @ 2000-07-19 0:00 ` Joachim Durchholz 2000-07-25 0:00 ` Richard Riehle 0 siblings, 1 reply; 102+ messages in thread From: Joachim Durchholz @ 2000-07-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-19 0:00 ` Joachim Durchholz @ 2000-07-25 0:00 ` Richard Riehle 0 siblings, 0 replies; 102+ messages in thread From: Richard Riehle @ 2000-07-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interesting thread in comp.lang.eiffel [not found] ` <i4k95.7512$7%3.571616@news.flash.net> [not found] ` <oqog45g1j0.fsf@premise.demon.co.uk> @ 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-19 0:00 ` Ken Garlington 1 sibling, 1 reply; 102+ messages in thread From: Veli-Pekka Nousiainen @ 2000-07-18 0:00 UTC (permalink / raw) "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. > > ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Interesting thread in comp.lang.eiffel 2000-07-18 0:00 ` Interesting thread in comp.lang.eiffel Veli-Pekka Nousiainen @ 2000-07-19 0:00 ` Ken Garlington 0 siblings, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-19 0:00 UTC (permalink / raw) "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; ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <i4k95.7512$7%3.571616@n <397D8CC3.BB0C9001@ix.netcom.com>]
* Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) [not found] ` <i4k95.7512$7%3.571616@n <397D8CC3.BB0C9001@ix.netcom.com> @ 2000-07-29 0:00 ` Kent Paul Dolan 2000-07-29 0:00 ` Ken Garlington 2000-07-31 0:00 ` Simon Brady 0 siblings, 2 replies; 102+ messages in thread From: Kent Paul Dolan @ 2000-07-29 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-29 0:00 ` Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) Kent Paul Dolan @ 2000-07-29 0:00 ` Ken Garlington 2000-07-31 0:00 ` Stefan Skoglund 2000-08-01 0:00 ` Kent Paul Dolan 2000-07-31 0:00 ` Simon Brady 1 sibling, 2 replies; 102+ messages in thread From: Ken Garlington @ 2000-07-29 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-29 0:00 ` Ken Garlington @ 2000-07-31 0:00 ` Stefan Skoglund 2000-08-01 0:00 ` Ken Garlington 2000-08-01 0:00 ` Kent Paul Dolan 1 sibling, 1 reply; 102+ messages in thread From: Stefan Skoglund @ 2000-07-31 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-31 0:00 ` Stefan Skoglund @ 2000-08-01 0:00 ` Ken Garlington 0 siblings, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-08-01 0:00 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-29 0:00 ` Ken Garlington 2000-07-31 0:00 ` Stefan Skoglund @ 2000-08-01 0:00 ` Kent Paul Dolan 2000-08-01 0:00 ` Ken Garlington 1 sibling, 1 reply; 102+ messages in thread From: Kent Paul Dolan @ 2000-08-01 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-08-01 0:00 ` Kent Paul Dolan @ 2000-08-01 0:00 ` Ken Garlington 0 siblings, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-08-01 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-29 0:00 ` Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) Kent Paul Dolan 2000-07-29 0:00 ` Ken Garlington @ 2000-07-31 0:00 ` Simon Brady 2000-07-30 0:00 ` John Magness 1 sibling, 1 reply; 102+ messages in thread From: Simon Brady @ 2000-07-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-31 0:00 ` Simon Brady @ 2000-07-30 0:00 ` John Magness 2000-08-01 0:00 ` Simon Brady 0 siblings, 1 reply; 102+ messages in thread From: John Magness @ 2000-07-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-07-30 0:00 ` John Magness @ 2000-08-01 0:00 ` Simon Brady 2000-08-01 0:00 ` Simon Brady 2000-08-01 0:00 ` Ken Garlington 0 siblings, 2 replies; 102+ messages in thread From: Simon Brady @ 2000-08-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-08-01 0:00 ` Simon Brady @ 2000-08-01 0:00 ` Simon Brady 2000-08-04 0:00 ` Robert I. Eachus 2000-08-01 0:00 ` Ken Garlington 1 sibling, 1 reply; 102+ messages in thread From: Simon Brady @ 2000-08-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-08-01 0:00 ` Simon Brady @ 2000-08-04 0:00 ` Robert I. Eachus 2000-08-04 0:00 ` Simon Brady 0 siblings, 1 reply; 102+ messages in thread From: Robert I. Eachus @ 2000-08-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-08-04 0:00 ` Robert I. Eachus @ 2000-08-04 0:00 ` Simon Brady 0 siblings, 0 replies; 102+ messages in thread From: Simon Brady @ 2000-08-04 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 102+ messages in thread
* Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) 2000-08-01 0:00 ` Simon Brady 2000-08-01 0:00 ` Simon Brady @ 2000-08-01 0:00 ` Ken Garlington 1 sibling, 0 replies; 102+ messages in thread From: Ken Garlington @ 2000-08-01 0:00 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 102+ messages in thread
[parent not found: <8j7i54$j7d5@news.kvaerner.com>]
[parent not found: <395887EB.8D612FC7@deepthought.com.au>]
[parent not found: <395A190E.FD4D8978@easystreet.com>]
[parent not found: <6Yt65.3417$MS3.72586@news1.online.no>]
[parent not found: <395A7E7E.FE57E036@easystreet.com>]
[parent not found: <8jermi$5cb2@news.kvaerner.com>]
[parent not found: <395BCE66.2BE8EE0A@eiffel.com>]
[parent not found: <wccaeg3gj61.fsf@world.std.com>]
[parent not found: <395D113D.1F654A68@eiffel.com>]
[parent not found: <dus75.5086$MS3.105182@news1.online.no>]
[parent not found: <395E5D16.C4D109F1@eiffel.com>]
* Re: Interesting thread in comp.lang.eiffel [not found] ` <395E5D16.C4D109F1@eiffel.com> @ 2000-07-18 0:00 ` Veli-Pekka Nousiainen 0 siblings, 0 replies; 102+ messages in thread From: Veli-Pekka Nousiainen @ 2000-07-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 102+ messages in thread
end of thread, other threads:[~2000-08-04 0:00 UTC | newest] Thread overview: 102+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <8ipvnj$inc$1@wanadoo.fr> [not found] ` <8j67p8$afd$1@nnrp1.deja.com> [not found] ` <39573CAB.BB90DF92@gecm.com> [not found] ` <8j8ek0$24la$3@ID-9852.news.cis.dfn.de> [not found] ` <3957ED3E.E64E7390@lmco.com> [not found] ` <8k8orn$1tlh9$1@ID-9852.news.cis.dfn.de> [not found] ` <94S95.9936$7%3.667320@news.flash.net> 2000-07-13 0:00 ` Interresting thread in comp.lang.eiffel Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington 2000-07-16 0:00 ` Joachim Durchholz 2000-07-16 0:00 ` Ken Garlington [not found] ` <slrn8leffq.ebq.gisle@spurv.ii.uib.no> [not found] ` <395886DA.CCE008D2@deepthought.com.au> [not found] ` <3958B07B.18A5BB8C@acm.com> [not found] ` <y1d65.620$7%3.33446@news.flash.net> [not found] ` <395A0ECA.940560D1@acm.com> [not found] ` <8jd4bb$na7$1@toralf.uib.no> [not found] ` <8jfabb$1d8$1@nnrp1.deja.com> [not found] ` <SVH65.1596$7%3.129344@news.flash.net> [not found] ` <8jt4i0$18ec7$1@ID-9852.news.cis.dfn.de> [not found] ` <nSt85.5388$7%3.424540@news.flash.net> [not found] ` <8k5a31$1p61t$1@ID-9852.news.cis.dfn.de> [not found] ` <qlt95.7824$7%3.596314@news.flash.net> [not found] ` <3966D7B0.5D6475E4@earthlink.net> [not found] ` <A5J95.9237$7%3.638838@news.flash.net> 2000-07-12 0:00 ` Robert I. Eachus 2000-07-13 0:00 ` Ken Garlington 2000-07-23 0:00 ` Robert I. Eachus 2000-07-23 0:00 ` Ken Garlington 2000-07-24 0:00 ` swhalen 2000-07-24 0:00 ` David Gillon 2000-07-24 0:00 ` Ken Garlington 2000-07-24 0:00 ` David Gillon [not found] ` <39688CA2.31B2A7EF@acm.com> 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` Marin D. Condic [not found] ` <8k8p8m$1upjk$1@ID-9852.news.cis.dfn.de> [not found] ` <0cS95.9944$7%3.667682@news.flash.net> 2000-07-13 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington [not found] ` <8jhq0m$30u5$1@toralf.uib.no> [not found] ` <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> [not found] ` <3963CDDE.3E8FB644@earthlink.net> [not found] ` <8k5alv$1oogm$1@ID-9852.news.cis.dfn.de> [not found] ` <Rmt95.7825$7%3.595826@news.flash.net> 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` Marin D. Condic 2000-07-14 0:00 ` Ken Garlington 2000-07-16 0:00 ` Joachim Durchholz 2000-07-16 0:00 ` Ken Garlington 2000-07-19 0:00 ` Joachim Durchholz 2000-07-19 0:00 ` Ken Garlington 2000-07-14 0:00 ` Ken Garlington 2000-07-14 0:00 ` Marin D. Condic 2000-07-14 0:00 ` Ken Garlington [not found] ` <3963DEBF.79C40BF1@eiffel.com> [not found] ` <2LS85.6100$7%3.493920@news.flash.net> [not found] ` <8k5aru$1odtq$1@ID-9852.news.cis.dfn.de> [not found] ` <Rnt95.7826$7%3.596208@news.flash.net> [not found] ` <8k8pk2$20cab$1@ID-9852.news.cis.dfn.de> [not found] ` <_dS95.9945$7%3.666180@news.flash.net> 2000-07-12 0:00 ` David K Allen 2000-07-12 0:00 ` Ken Garlington 2000-07-12 0:00 ` David K Allen 2000-07-13 0:00 ` Howard W. LUDWIG 2000-07-13 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington 2000-07-14 0:00 ` Ken Garlington 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-19 0:00 ` Ken Garlington 2000-07-19 0:00 ` Bob Allen 2000-07-12 0:00 ` David K Allen 2000-07-12 0:00 ` David Gillon 2000-07-13 0:00 ` Joachim Durchholz 2000-07-13 0:00 ` David Gillon 2000-07-13 0:00 ` David K Allen 2000-07-13 0:00 ` Bob Allen 2000-07-13 0:00 ` Joachim Durchholz 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-19 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` Ken Garlington 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-19 0:00 ` David Gillon 2000-07-12 0:00 ` Bob Allen 2000-07-12 0:00 ` Ken Garlington 2000-07-13 0:00 ` Bob Allen 2000-07-14 0:00 ` Ken Garlington 2000-07-14 0:00 ` carr_tom 2000-07-18 0:00 ` Veli-Pekka Nousiainen 2000-07-14 0:00 ` Marin D. Condic [not found] ` <Rnt95.78 <L6vb5.16117$7%3.988701@news.flash.net> 2000-07-14 0:00 ` Nick Williams [not found] ` <396502D2.BD8A42E7@earthlink.net> [not found] ` <RSsa5.11075$7%3.784507@news.flash.net> [not found] ` <6aHa5.113$6E.23141@ptah.visi.com> [not found] ` <396B4A68.458FA3BC@maths.unine.ch> [not found] ` <u6hp4i16$GA.283@cpmsnbbsa07> 2000-07-11 0:00 ` cropt 2000-07-11 0:00 ` Ken Garlington 2000-07-12 0:00 ` Peter Amey 2000-07-12 0:00 ` Peter Amey 2000-07-13 0:00 ` Joachim Durchholz 2000-07-12 0:00 ` Bob Allen 2000-07-12 0:00 ` David Starner 2000-07-12 0:00 ` Ken Garlington [not found] ` <39654639.B3760EF2@eiffel.com> [not found] ` <i4k95.7512$7%3.571616@news.flash.net> [not found] ` <oqog45g1j0.fsf@premise.demon.co.uk> [not found] ` <85Fa5.11419$7%3.818927@news.flash.net> 2000-07-11 0:00 ` Aspects (Re: Interesting thread in comp.lang.eiffel) tom 2000-07-12 0:00 ` Veli-Pekka Nousiainen 2000-07-12 0:00 ` tom 2000-07-12 0:00 ` Steve Merrick 2000-07-12 0:00 ` Frank Mitchell 2000-07-14 0:00 ` Jubilation 2000-07-14 0:00 ` Frank Mitchell 2000-07-15 0:00 ` Jubilation 2000-07-12 0:00 ` Design by Contract (was " David Kristola 2000-07-12 0:00 ` Greg 2000-07-12 0:00 ` Matthew J Heaney 2000-07-13 0:00 ` Eirik Mangseth 2000-07-12 0:00 ` Howard W. LUDWIG 2000-07-12 0:00 ` Greg 2000-07-12 0:00 ` Eirik Mangseth 2000-07-13 0:00 ` Joachim Durchholz 2000-07-14 0:00 ` David Kristola 2000-07-14 0:00 ` Matthew J Heaney 2000-07-16 0:00 ` Joachim Durchholz 2000-07-17 0:00 ` David Kristola 2000-07-19 0:00 ` Joachim Durchholz 2000-07-25 0:00 ` Richard Riehle 2000-07-18 0:00 ` Interesting thread in comp.lang.eiffel Veli-Pekka Nousiainen 2000-07-19 0:00 ` Ken Garlington [not found] ` <i4k95.7512$7%3.571616@n <397D8CC3.BB0C9001@ix.netcom.com> 2000-07-29 0:00 ` Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) Kent Paul Dolan 2000-07-29 0:00 ` Ken Garlington 2000-07-31 0:00 ` Stefan Skoglund 2000-08-01 0:00 ` Ken Garlington 2000-08-01 0:00 ` Kent Paul Dolan 2000-08-01 0:00 ` Ken Garlington 2000-07-31 0:00 ` Simon Brady 2000-07-30 0:00 ` John Magness 2000-08-01 0:00 ` Simon Brady 2000-08-01 0:00 ` Simon Brady 2000-08-04 0:00 ` Robert I. Eachus 2000-08-04 0:00 ` Simon Brady 2000-08-01 0:00 ` Ken Garlington [not found] ` <8j7i54$j7d5@news.kvaerner.com> [not found] ` <395887EB.8D612FC7@deepthought.com.au> [not found] ` <395A190E.FD4D8978@easystreet.com> [not found] ` <6Yt65.3417$MS3.72586@news1.online.no> [not found] ` <395A7E7E.FE57E036@easystreet.com> [not found] ` <8jermi$5cb2@news.kvaerner.com> [not found] ` <395BCE66.2BE8EE0A@eiffel.com> [not found] ` <wccaeg3gj61.fsf@world.std.com> [not found] ` <395D113D.1F654A68@eiffel.com> [not found] ` <dus75.5086$MS3.105182@news1.online.no> [not found] ` <395E5D16.C4D109F1@eiffel.com> 2000-07-18 0:00 ` Interesting thread in comp.lang.eiffel Veli-Pekka Nousiainen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox