Path: utzoo!attcan!uunet!jarthur!elroy.jpl.nasa.gov!jpl-devvax!ai-jupiter!kandt
From: kandt@ai-jupiter.JPL.NASA.GOV (Kirk Kandt)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Message-ID: <8529@jpl-devvax.JPL.NASA.GOV>
Date: 28 Jun 90 18:26:21 GMT
References: <30852@cup.portal.com> <102100011@p.cs.uiuc.edu> <31097@cup.portal.com> <1568@oravax.UUCP> <8488@jpl-devvax.JPL.NASA.GOV> <81688@tut.cis.ohio-state.edu>
Sender: news@jpl-devvax.JPL.NASA.GOV
Reply-To: kandt@AI-Cyclops.JPL.NASA.GOV
Organization: NASA/Jet Propulsion Laboratory
Lines: 81

In article <81688@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu
(William F Ogden) writes:
|> In article <8488@jpl-devvax.JPL.NASA.GOV>
kandt@AI-Cyclops.JPL.NASA.GOV writes:
|> 
|>   ...
|> >Various mathematical software libraries are successful because
|> >components are reliable and easily identifiable.  This same success can
|> >be had in other domains too!  Someone just has to buy into the high
|> >start-up costs in the belief that the long-term benefits are there. 
|> >Unfortunately, the procurement process of American society does not
allow this
|>  
|> It should be noted that mathematicians spent several hundred wall
clock years
|> and countless man-years exploring the domains in which these libraries work.
|> This produced a relatively small yet powerful conceptual basis for these
|> domains together with an elegant notation for the concepts. The notation
|> was validated in innumerable applications, and the theory was elaborated
|> in great detail. Most importantly perhaps, the notation (and the most useful
|> part of the theory) was taught to most engineers and scientists. When
|> creating these libraries, programmers didn't have to discover the utility
|> of log, arctan, eigenvector, etc. Moreover, prospective users already
|> know the terminology used to identify and describe components in
statistical 
|> or linear algebra packages, for example.

I claim that anything that we build -- a command and control system, a
flight reservation system, an operating system, and so on -- has a
conceptual basis; if they didn't we couldn't build them.  The notation
for each of these domains can be described by a language which would
provide the syntax, semantics, and even pragmatics for the modeled
domain.  Individuals can be easily taught this new "notation", it would
not be any more difficult to learn than another programming language, or 4GL.

|> The lack of a well developed and widely known formal basis for many other
|> computing domains may well prove to be a serious impediment to the
development
|> of reusable software.

True, but if a domain is that misunderstood then we are not building
implementations of them anyway.

I reassert that any artifact that we build can provide components for
later reuse.  I also assert that if we have built a component we can
adequately describe it in a formal or informal notation so that its
complete behavior is understandable by a human.  I also know that
providing such information for later reuse requires much labor at great
cost.  This is the impediment to software reuse.  The issue is "given
that you can describe a domain, how do build a information repository in
a cost-effective manner."

As an example, take the domain of data structures.  It is a relatively
simple domain.  It is well understood.  There are both formal and
informal methods for describing modeling representations and storage
structures.  We understand the complexity of them all, including special
cases and programming tricks.  Yet to date, there is not one reusable
data structure depository.  Why is that?  Because the costs of putting
all the knowledge contained in existing data structure books and
articles would be incredible.

My thesis work was on managing design information for later reuse.  I
took a couple of toy problems -- the Dutch National Flag algorithm and
quicksort -- and described them so that they could be later reused.  The
amount of information obviously was subjective.  But in each case it
took approximately 5-10 pages to describe them so that I felt someone
else could understand and reliably reuse them.  After working on these
simple problems I came to the conclusion that the amount of effort
required to document complex components would be much greater that the
actual construction of said components.

As a result, I concluded that software reuse should only be attempted if
you are producing the same type of artifact over and over again.  For
example, if you write 25 Ada compilers for different machines then
software reuse is feasible, but if you only write 3 of them then it
probably isn't.  I also concluded that software reuse as many people
envision it is impossible unless some manner of automating the
acquisition of information is achieved.  If someone is looking for a PhD
thesis, here it is.

Kirk