Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!scotth
From: scotth@boulder.Colorado.EDU (Scott Henninger)
Newsgroups: comp.sw.components
Subject: Re: Welcome to comp.sw.components!!!
Message-ID: <11329@boulder.Colorado.EDU>
Date: 4 Sep 89 17:38:09 GMT
References: <6378@hubcap.clemson.edu>
Sender: news@boulder.Colorado.EDU
Reply-To: scotth@boulder.Colorado.EDU (Scott Henninger)
Organization: University of Colorado, Boulder
Lines: 79

|>From: wtwolfe@hubcap.clemson.edu (Bill Wolfe)
|Subject: Welcome to comp.sw.components!!!
|Date: 3 Sep 89 18:19:37 GMT
|
|
|   - 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.

This is a narrow viewpoint of software reuse that does no justice to the
difficulty of constructing a good software reuse system.  If the above
statement were true, then the problem was solved years ago with the advent
of software libraries.  Unfortunately, there are a number of problems with
software libraries that make them less than fully useful:

1. Users do not know what components are available.  I.e. it is easier to
   write a component themselves than to try to look for something in the
   library.  This is an information retrieval problem.

2. Users do not know how to use the available components or what they do. 
   Tools are needed to help the users with these tasks.

3. Library components rarely fit a need exactly.  No matter how hard a
   library developer tries to cover all contengencis, someone will
   eventually need something slightly different than what is offered. 
   Facilities are needed to allow modification so the components can be
   tailored to meet a specific user's needs.

The following article expounds on these viewpoints:

 "Cognitive View of Reuse and Redesign"
     G. Fischer, IEEE Software, July 1987, 4(4), pp. 60-72.

In addition, I have only addressed the reuse of implementation units.  It
may be that we can get a much larger return on investment by reusing
design artifacts or other work products associated with creating a
software system.
             
|   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.

Unfortunately, this is a misleading analogy.  In a canonical sense,
hardware only has to implement one thing - a Von Neumann machine (there
are slight adjustments to this architecture, but the point stands). 
Software is called upon to implement a vastly larger number of abstract
machines.  A DEC VAX and a IBM 3090 are general purpose computing machines
(with different implementations).  You can port programs that run on one to
the other.  A math package and a windowing package perform very different
functions.  You would not think of porting a logarithms functions to a
window system. 

Because of this fact, certain elements, such as an ALU, are universially
necessary in hardware, but do not exist for software.  Although one can
contrive certain building blocks for software, there are no elements
(other than a hardware platform and a compiler/interpreter) that must
*necessarily* exist for a software system to work.  This makes software
and hardware *fundamentally* different, and to use one as an analogy for
the other will only lead to the sort of difficulties being experienced by
those who believe in this approach.  For example, notice that most efforts to
create software components systems are criticized for their limited scope
of applications.  I would argue that this is a direct consequence of the
hardware analogy, which is doing more harm than good.

-- Scott
   scotth@boulder.colorado.edu