🚀 go-pugleaf

In article <7885@batcomputer.tn.cornell.edu> garry@larch.cadif.cornell.edu writes:
>In a recent article wtwolfe@hubcap.clemson.edu (Bill Wolfe) wrote:
>> $ This newsgroup will facilitate discussions about software components
>> $ and their design, implementation, and utilization...
>
>What, pray tell, is a "software component"? (A library "tool"? A subroutine?
>A flowchart? An algorithm? A programmer?) I have not encountered this
>term of computer jargon before...
>
>garry wiegand   (garry@larch.cadif.cornell.edu - my "Reply-To", not my "From"!)

Grady Booch's `SOFTWARE COMPONENTS WITH Ada - Structures, tools, and Subsystems'
provides a taxonomy which seems to be a reasonable starting point for 
defining components, and reusable design components and common subprograms 
could provide a useful addition to the taxonomy as well.  Is anyone aware of 
better alternatives?

I've seen a lot of talk about storing and retrieving components and it seems
that Booch's naming scheme is appropriate for keywords in a database search.
Are there any plans for an automated components database that may arise soon
out of this newsgroup?

Bob
rjh@purdue.edu

From garry@batcomputer.tn.cornell.edu (Garry Wiegand as guest):
> What, pray tell, is a "software component"? (A library "tool"? A subroutine?
> A flowchart? An algorithm? A programmer?) I have not encountered this
> term of computer jargon before...

   In _Software_Components_With_Ada_, Booch defines a software component
   as "a container for expressing abstractions of data structures and
   algorithms".  A software component is generally expected to be:

      - cohesive; it should denote a single abstraction.  Examples are
                  the stack, queue, list, tree, and graph abstractions.

      - reuseable; it should provide a sufficiently general and useful
                   service to ensure that it will be used over and over
                   again by many different programmers for many diverse
                   application areas.  A primary reason for the existence
                   of software components is that they need only to be
                   written once; once written, the costs of development
                   can be spread over thousands of applications, making 
                   the cost to any particular application trivial.  This
                   certainly is not the case for the alternative, building
                   the same functionality up from scratch for each new
                   application.  

      - secure; it must perform reliably under any reasonable 
                circumstances.  If an insertion into a tree causes
                memory to be exhausted, it is the responsibility of
                the component to see to it that there is no change
                of state (hence, the consequence of the memory being
                exhausted is simply that the insertion does not occur;
                the component is left in whatever state it was in prior
                to the attempted insertion), and to report the failure
                to the user (e.g., by raising an exception along the lines
                of Unable_To_Insert_Due_To_Memory_Exhaustion).  Also,
                advanced languages such as Ada make it possible to 
                simultaneously pound a component with arbitrarily 
                large numbers of service requests from many different
                tasks; the component must service all such requests
                in a serializable manner, without leading to an 
                inconsistent internal state.  A well-written component
                will, furthermore, satisfy such requests in parallel
                (i.e., will not just achieve serializability by simply
                processing requests one at a time, thus causing big delays).
                Finally, it must be impossible for a user to examine
                or alter the internal state of a component, unless the
                user calls a procedure or function designed to provide
                information regarding the component's state (e.g., the
                position of the current item in a linked list); this 
                requirement is typically satisfied by language constructs 
                like the Ada "limited private" clause.
              
   Intuitively, a software component is analogous to the hardware 
   components (e.g., integrated circuits) which have been used by 
   hardware engineers for a very long time.  By adopting their 
   methods, we hope to reduce the costs of software development,
   improve the quality of our software, and accelerate software
   production.  This will lead to lower financial barriers to 
   software development, and thereby accelerate the use of software
   systems throughout the economy, with global economic benefits.

   If you'd like to read more about software components, Booch's
   _Software_Components_With_Ada_ is a good place to start (ISBN
   0-8053-0610-2, Benjamin/Cummings, QA76.73.A35B65).  Also, simply
   keep reading this newsgroup!!  :-)


   Bill Wolfe, wtwolfe@hubcap.clemson.edu