Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mailrus!usenet.ins.cwru.edu!abvax!icd.ab.com!ejp
From: ejp@icd.ab.com (Ed Prochak)
Newsgroups: comp.software-eng
Subject: Re: OOP and software reuse
Message-ID: <1503@abvax.UUCP>
Date: 10 Jul 90 17:59:06 GMT
References: <39400113@m.cs.uiuc.edu> <112789@linus.mitre.org> <JWG1.90Jul9174438@bunny.gte.com>
Sender: news@abvax.UUCP
Reply-To: ejp@icd.ab.com (Ed Prochak)
Organization: Allen-Bradley Company, Industrial Computer Division
Lines: 95

In article <JWG1.90Jul9174438@bunny.gte.com>, jwg1@gte.com (James W.
Gish) writes:
> In article <112789@linus.mitre.org> mitchell@community-chest.uucp
(George Mitchell) writes:
> >
> 
> >	This emphasis on programming and building reflects much of what I think is
> >	wrong about the way we usually view reuse.  The major cost of
software is in
> >	maintenance, not development.  The major cost of development is not
in coding.
> >	To gain the greatest benefit from reuse, we need to have components
that can
> >	be incorporated without alteration, without unit test, and without
subsequent
> >	maintenance.  What needs to be available in the component market
place is not 
> >	only code, but test data, warranties, and life cycle support.
> 
> This may be what we need, but with the possible exception of very
> general pieces of code, I don't think we're going to get very much of
> it.  It is far too difficult as a designer/coder to envision how your
> code is going to be used in the future, either its context or the
> exact requirements imposed on it.  When we write code, we usually do
> it with a particular context or application domain and framework (for
> example, error handling/reporting) in mind.  However, when we go
> looking for code to use/reuse, unless the intended context and
> framework meet our requirements, we will have to adapt that code to
> our needs.  We may want more or less functionality than the code
> provides, we may not be able to satisfy its requirements in one way or
> another.
> 
 [experience with Eiffel deleted]  
> 
> It's easy to say make it right, provide the test cases, documentation
> and everything I need to use it as is, but the reality is that none of
> us is omniscient enough to foresee how our code is going to be used,
> especially in the ever-changing world of computers and their expanding
> domains.  So, for the foreseeable future I believe our best hope is in
> providing intelligent tools for assisting us in adapting code and
> associated artifacts including, for example, documentation and test
> cases, to new uses.
>                                                          
> --
> Jim Gish (jgish@gte.com)
> Principal Investigator
> Software Reusability Project
> GTE Laboratories Inc.


That is exactly why there will be different supliers
of software components.  Each supplier will conform to
a standard interface, but the component from each supplier
will have slightly different characteristics. You then pick
the one that most closely matches you needs. The hardware
analogy shows this: the designer picks

   -a memory chip from hitachi
   -a processor from motorola
   -a digital to analog converter from TI
   -LED's from HP
   -and so on...

Whatever works use it! as my freshman Chemistry professor
always used to say.

To get all this to work in software requires:
 1 documentation that reasonably describes the component
   (interface, performance, "power" requirements)
 2 standard interfaces so replacing the component is possible
   with little or no change in the specific application code.

Finally, let me say that the components catalog that has been
described would contain components for every problem. We need to
start small. And actually in some sense we have already started
with components like:
 operating systems
 drivers and communications protocols
 standard libraries (e.g. stdio in C)
The point being that no one is claiming to have the perfect
components for all occasions.

Hardware designers for embedded systems often have do deal
with more than just digital circuitry. Even analog hardware
has some standard compoments (op-amps, bridge rectifiers,
power transisters,...) A friend, who is a hardware type,
often described what he was doing as editing, whenever he
was building a circuit.) So the hardware analogy is valid when
we remember that hardware is more than just digital.

(Pardon the inconvenience during our remodelling of the signature file)
Edward J. Prochak        (216)646-4663         I think. 
{cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com    I think I am.
Allen-Bradley Industrial Computer Div.       Therefore, I AM!
Highland Heights,OH 44143                      I think?  --- Moody Blues