Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!jarthur!ucivax!gateway
From: nancy@murphy.ICS.UCI.EDU (Nancy Leveson)
Newsgroups: comp.software-eng
Subject: Re: Reuse, Tolerance, and Tradeoffs (was Re: Tolerance)
Message-ID: <9102070916.aa10917@PARIS.ICS.UCI.EDU>
Date: 7 Feb 91 17:22:24 GMT
Reply-To: nancy@ICS.UCI.EDU
Lines: 45
In-reply-to: Your message of 07 Feb 91 15:46:03 +0000.
             <88102@tut.cis.ohio-state.edu>


	 In what sense is a stack design, in which no particular error is
	 generated when an empty stack is popped, no longer a "pure stack"?  As
	 you point out, this is the RIGHT way to design a most-reusable stack
	 component.  If some client wants an error message upon popping an
	 empty stack, he/she can layer a "defensive stack" design on top of
	 yours.  That way the rest of us don't have to pay for unnecessary
	 tests for emptiness.  (By the way, Bertrand Meyer and our group have
	 been saying this for a long time, but most people still don't buy it.
	 I'm not sure why.)

Perhaps because many people do not feel that tests for emptiness are
"unnecesssary."  Most serious accidents caused by software that I have
heard about result from nonrobust software -- software that makes
assumptions about the environment and those assumptions are incorrect
or the environment changes during use of the software.  At the least,
the software response should be defined (e.g., put out an error message)
rather than random.

This seems to be even MORE important for software that will be reused in
environments where the assumptions about it may be very different than
those made by the developers of the reused code.  Sure, you can write
down all the assumptions made by the developers (e.g., an empty stack
will never be popped) and the user can check for them -- easier for
something like a stack where we have been exploring what those assumptions
are in hundreds of papers for the past 20 years than in other software.

We are not even aware of many (if not most) assumptions we make in
programming.  Formal specifications will help somewhat, but there are
lots of cases of incomplete formal specifications for even simple things
like stacks being written.  We have a paper coming out in the March
issue of IEEE Trans. on Soft. Eng. that attempts to define the
assumptions you need to specify, but it does not completely solve
this problem.  And the amount of specification necessary is VERY large.

When reusing some air traffic control software in Britain that had been
developed in the U.S., it was discovered after it was put into place that
the American developers had not taken 0 degrees longitude into account
(which they did not need to in the U.S.) and also did not warn anyone
about this (perhaps they did not even think about it?).  The software
folded the map of Britain in half along the Greenwich meridian, placing
Warwick on top of Manchester.

If this is the "RIGHT way" to design reusable software, then reusability
is in trouble.