Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide
From: weide@elephant.cis.ohio-state.edu (Bruce Weide)
Newsgroups: comp.software-eng
Subject: Re: Reuse and Abstraction (was: reu
Message-ID: <80884@tut.cis.ohio-state.edu>
Date: 25 May 90 15:56:17 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>
Sender: news@tut.cis.ohio-state.edu
Reply-To: Bruce Weide <weide@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 55


Thanks to Charlie Martin for his interesting posting about formal
specification.  Among other things, he writes:

>My suspicion (today, ask me again in a couple weeks, because I may
>change my mind again) is that one of the major advantages of Z and VDM
>is that they are *not* tied to an implementation language, and are not
>intended to be compiled.  Because of this, one can invent terminology
>and new notation on the fly, one can leave out essentially uninteresting
>parts of the specification (like restating over and over again that a
>particular operation works within the bounds of the type's
>architecture-specific values), and in general one can play to the
>audience instead of needing to satisfy a finicky proof-checker.

One of the primary reasons for formal specification is the inherent
ambiguity of natural language and other informal methods.  It's hard
to see how having a "formal" notation that can be augmented "on the
fly" -- whenever the specifier feels a need to say something that the
language wasn't designed for -- can be much better than an informal
specification in this sense.  Maybe a little better, but hardly the
ultimate formal specification language.  I think it is a reasonable
academic exercise to explore the constructs and concepts needed to
develop a more complete (in this sense) specification language than
those offered to date.  Eventually, a better language might even get
used in practice.


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.  Maybe InterViews.
>But I think we may be instanciating "easy" differently: what I mean is
>"there are no technical difficulties (that I can see), so it should just
>be a matter of applying some time and effort to doing so."  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.

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 :-).

	-Bruce