Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!uunet!ncrlnk!ncrcae!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: What should a component library loo
Message-ID: <7095@hubcap.clemson.edu>
Date: 17 Nov 89 03:43:09 GMT
Article-I.D.: hubcap.7095
References: <130200021@p.cs.uiuc.edu>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 63

From johnson@p.cs.uiuc.edu:
> dwiggins> what is the role and task of the "software component librarian"?  
> billwolf> To manage an interface between component producers 
>           and component users.
> 
> I'd like to argue this point.  The interface between component producers
> and users should be designed and managed by the component producer. [...]
> It is possible that I am misinterpreting "manage".  I see the role of a
> librarian as making sure that components have documentation and test suites,
> that they can run their test suites, etc.  The purpose of the librarian is
> simply to reduce the chaos that would happen if everybody could add and
> delete components from the library on their own.  If you only have a
> dozen people, it might not be worth the effort to centralize that task.

   This assumes that everyone can unilaterally decide to produce 
   components which are large enough to justify reuse, which is
   contradictory to the assumed software engineering methodology.   
   
   In order to reduce the chaos which would result if everybody 
   could create components on their own, each required component
   is identified in the detailed design phase and the librarian
   provides information regarding the match (or lack thereof)
   between the component requirements and the component supply.

   If components are required which are not immediately available, 
   then the librarian decides how to acquire the component, either
   by producing and validating it locally or by acquiring it on the
   open market... normally the latter will be the preferred strategy,
   but there may be special factors which dictate otherwise.

> In case I have not made myself clear, the question of which components
> are needed, whether to buy or build them, which versions to buy, etc.
> are NOT the responsibility of the librarian.  These questions are crucial,
> and must be the responsibility of high-level technical and management
> people.  Perhaps you see a librarian as one of those people.  The name
> means something different to me.

   The librarian should not be in the business of deciding which 
   components are needed, but should be in the business of deciding
   whether to buy or build, which versions to buy, etc.

> > Another problem is the existence of languages which are not
> > standardized and for which no compiler validation capability exists.
>  
> There is a great deal of reuse in Smalltalk, which is not standardized 
> and which has no standard compiler validation suite.  

   If it's not standardized, then there are portability problems.

   If there are not portability problems, then it's standardized.

> As far as I am concerned, Ada is no more conducive to reuse than C.
> Good programmers can write reusable components in C.  They can in Ada, 
> too.  However, I wouldn't say that either language PROMOTES reuse.

   This is like saying that since it is possible to write bad code
   in any language, no language promotes the writing of good code,
   or that since all programming languages are Turing-equivalent,
   they are all equally useful.  Face the facts: some languages are
   better at promoting reuse than others, e.g., Ada relative to C.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu