Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!news
From: news@tut.cis.ohio-state.edu (Usenet News)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Message-ID: <81875@tut.cis.ohio-state.edu>
Date: 3 Jul 90 23:40:15 GMT
References: <30852@cup.portal.com> <102100011@p.cs.uiuc.edu> <31097@cup.portal.c
Organization: Ohio State Univ Computer & Info Science
Lines: 65

edu> <8529@jpl-devvax.JPL.NASA.GOV>
Sender: 
Reply-To: William F Ogden <ogden@cis.ohio-state.edu>
Followup-To: 
Distribution: 
Organization: Ohio State University Computer and Information Science
Keywords: 
From: ogden@seal.cis.ohio-state.edu (William F Ogden)
Path: seal.cis.ohio-state.edu!ogden

In article <8529@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes:

>       ....                                          The issue is "given
>that you can describe a domain, how do [you] build a information repository in
>a cost-effective manner."
>
>As an example, take the domain of data structures.   
  ...
>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.

To a subsequent message about data structure objects in Smalltalk, etc.
he writes:

>I've used these languages before -- having a basic set of objects is not
>the issue.  The issue is that the implementation of a "type" can be done
>in a variety of ways, where each implementation has certain advantages
>and disadvantages in terms of time and space.  A set, for example, can
>be implemented as a bit array, a simple array, a linked list, a hash
>table, and so on.  Smalltalk, Objective-C, etc. generally provide only
>one implementation of an "abstract type".  This one implementation is
>chosen because it works reasonably well for all cases, but it may not be
>optimal for a specific data set; in fact, it may be orders of magnitude
>slower than one tailored for the characteristics of the data set. 
  ...

Part of the solution of the problem of `managing design information for
later reuse' while still admitting myriad implementations is to recognize
commonalities (i.e. seek useful generalizations). For example, when viewed
properly, the description of quicksort factors into a portion which is
common to all sorting components and a portion that is peculiar to 
quicksort. This first portion gives a conceptual description of the
functionality provided by any sorting facility as well as of the most
general types of objects on which it will work. Quicksort, mergesort,
heapsort, etc. are then described as realizations for this concept
rather than as autonomous entities. The descriptive portion of each such
realization of course includes particular realization conventions, 
correspondences to the general concept, performance specifications, etc.
Similarly, one can identify the concept of a general set template which
admits array, linked list, hash table, etc. realizations -- each providing
the functionality specified by the set template, but differing in performance
characteristics.
Finding a suitable reusable component then involves first finding the right
concept, then finding the realization with the most appropriate performance
characteristics. The point is that there are at least an order of magnitude
fewer general concepts for facilities than there are useful realizations --
not to mention porcine ones.
Moreover, most reusable design information involves the general
concepts and not particular realizations, so the concept/realization
separation serves well here.
/Bill