Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components
Subject: Re: Welcome to comp.sw.components!!!
Message-ID: <6388@hubcap.clemson.edu>
Date: 4 Sep 89 20:22:57 GMT
References: <11329@boulder.Colorado.EDU>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 40

From scotth@boulder.Colorado.EDU (Scott Henninger):
> [a component should provide a generally useful reuseable service]
>
> This is a narrow viewpoint of software reuse that does no justice to the
> difficulty of constructing a good software reuse system.  

   The statement described good characteristics of a software component;
   it did not and was not intended to address the environment in which
   the component was embedded.  However, the topic has arisen in this
   newsgroup; in particular, I posted a favorable review some four to
   six weeks ago of the article "Domain Analysis -- From Art Form to
   Engineering Discipline" (Proceedings of the Fifth International
   Workshop on Software Specification and Design, May 19-20, 1989,
   SEN V14 N3), which views reusers as learning systems and provides
   a framework for assessing the progress of a reuse system.  Around
   early June, there was a discussion of STARS research which was
   directed toward constructing an effective Ada software component 
   retrieval system through the use of a knowledge-based librarian. 

   These topics should probably be included in the welcome message,
   but any implication or inference that these topics have not been
   covered in this newgroup is simply incorrect.
 
> |   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.  [...]
> 
> Unfortunately, this is a misleading analogy.  [...] Although one can
> contrive certain building blocks for software, [...]  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.

   The presently limited extent to which software components cover the
   large number of available domains is largely a consequence of the fact 
   that domain analysis (as described in the cited article) is still an 
   embryonic field.  IMHO, the hardware analogy is very appropriate. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu