Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.software-eng
Subject: Re: Reuse and Abstraction (was: reu
Message-ID: <5122@stpstn.UUCP>
Date: 27 May 90 15:26:34 GMT
References: <4979@stpstn.UUCP> <102100009@p.cs.uiuc.edu> <80449@tut.cis.ohio-state.edu> <19614@duke.cs.duke.edu> <80685@tut.cis.ohio-state.edu> <19760@duke.cs.duke.edu> <80884@tut.cis.ohio-state.edu>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 86

In article <80884@tut.cis.ohio-state.edu> Bruce Weide <weide@cis.ohio-state.edu> writes:
>One of the primary reasons for formal specification is the inherent
>ambiguity of natural language and other informal methods.

My own notions of specification/testing are based on the premise that, when
non-ambiguity really *matters* (such as during a commercial transaction),
mankind goes through a stereotypical, common-sense, and in principle
automatable process whose effect is to remove the ambiguity of natural 
language.

For example, in the commercial transaction signified by the requirement, "I 
want to buy a pound of ten-penny nails", or "I want to buy a Set class",
ambiguity of terms like "pound", "ten-penny", "nail", "Set", and "class" are
eliminated by developing a *common vocabulary* of *tests* that both parties,
producer and consumer, can agree on as determining the meaning of these
terms. For example, "pound" is defined by a test procedure involving a scale,
and "ten-penny" by a test procedure involving shape recognition by the
natural senses. 

Since test procedures based on scales and shape recognition fail to help 
with intangible concepts like "Set", we must become ultra-diligent in
developing and *publishing* test procedures to detect each of the terms
involved in specifying software components, to create the very *basis*
for non-ambiguous producer/consumer dialog.

Then, with a sufficiently large, robust, and widely-accepted library of
such test procedures, we can take the next step of building a 
specification/testing *language* that can compose meaningful sentences,
i.e. *specifications* from these primitive terms, and then compile these
sentences to build go/nogo gauges that can determine whether a putative 
implementation is in fact an actual implementation of that specification.

>Charlie also argues:
>>Actually, it's pretty hard to show a library of reusable components that
>>are generally agreed to be reusable, and non-trivial.

The Smalltalk environment is one; the Objective-C System-building Environment
is another.

>> It s an
>>interesting sort of task, but it's one that academic types are not
>>attracted to because a formal specification of a basically uninteresting
>>library isn't going to make a good publication, and one which industrial
>>types aren't likely to try unless soemone comes up with the money.

Re: academic types, please see Ralph London's formal specification (in Z,
as I recall) of the Smalltalk Set class.

Re: industrial types, please note my previous transmissions about Stepstone's
use of specification/testing for all of our Software-IC products. We do not
view this as an academic matter, but a matter right at the heart of our
business. How will a robust commercial marketplace in fine-granularity
software components even be *thinkable* unless producers and consumers
can develop a way of agreeing on what is to be bought and sold?

>Actually, there are some academic types (e.g., me) who don't think the
>exercise is so trivial, and who don't believe that there are "no
>technical difficulties" in developing a well-designed library of
>reusable components.  Even things like stacks, lists, associate search
>structures, graphs, etc., ar NOT designed properly for reuse as they
>appear in the CS textbooks or in existing component libraries.  In
>fact, though, judging from personal experience, Charlie is right if he
>is suggesting it is hard to convince many people of this.  People
>don't really want to know WHY it's hard to "get it right", nor do they
>want to consider alternative designs even if they come with (so far,
>at least) an irrefutable rationale.  This means it IS difficult to
>publish new designs for things people believe they already understand,
>and almost as difficult to find industrial funding.  We hope, however,
>it does not turn out to be impossible :-).

To be somewhat more controversial here, the academic priesthood is highly
unlikely to make great contributions precisely *because* they're conditioned
to believe that only technical problems are significant. They focus on the
*weapons* (i.e. OO technology), and neglect the *war* (software industrial
revolution).

Please take it from one who *knows*, the costs of building commercially
robust components are *not* in getting the code running. There is at
least a ten-fold greater cost in getting them tested and documented, and
another ten-fold increment in sales/marketing. Both of these latter steps
(100 fold) are unrelated to *implementation*, and closely related to
*specification*.
-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482