Re: Use of DBC as "executable SRS": scaling problems

[Al Christians <achrist@easystreet.com>]

Meyer's book seems to allow two kinds of preconditions, those that are
explicitly included in the Require clause, and those that must be
omitted, usually either for reasons of prohibitive redundancy with the
mainline logic or impossiblity of evaluation before the requested
service is actually attempted.  So he does see some use for return codes 
(for example from external database access attempts) and for exceptions
thrown from the middle of a method when the method finally figures out
that it can't do what was requested.  

So despite any suggestions or optimism, putting everything into explicit
preconditions, postconditions, and invariants is not a 100% solution. 
There will often be a buried implicit precondition somewhere.  If DBC is
99% effective, does that make the hidden precondition much more
dangerous because of an illusion of explicitness and reliability
supported by DBC?  

Al




W. Wesley Groleau x4923 wrote:
> 
> card@syr.lmco.com wrote:
> > I do not think that using DBC as an "executable SRS" (SRS == Software
> > (1) In a large and complex system, the number of preconditions and
> >     post-conditions in a complex class hierarchy could get extremely large.
> 
> Although they didn't demand that it be "in the code", the inquiry board
> did note
>   " that the systems specification of the SRI does not indicate
>     operational restrictions that emerge from the chosen
>     implementation. Such a declaration of limitation, which should
>     be mandatory for every mission-critical device, would have
>     served to identify any non-compliance with the trajectory
>     of Ariane 5. "