Path: utzoo!attcan!uunet!aplcen!samsung!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!hacgate!ashtate!atsun!dwiggins
From: dwiggins@atsun.a-t.com (Don Dwiggins)
Newsgroups: comp.sw.components
Subject: Re: What should a component library loo
Message-ID: <DWIGGINS.89Nov20154941@atsun.a-t.com>
Date: 20 Nov 89 23:49:41 GMT
References: <130200021@p.cs.uiuc.edu> <7095@hubcap.clemson.edu>
Sender: dwiggins@ashtate.UUCP
Organization: Ashton-Tate, Inc.
Lines: 43
In-reply-to: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu's message of 17 Nov 89 03:43:09 GMT

In article <7095@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:

      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.

The highlighted words imply a particular scenario for the library and the
software development environment that it's imbedded in.  I can envision a
number of reasonable organizational and procedural arrangements that would
lead to different degrees of "coupling" between the producers, librarian,
and consumers.  Could you elucidate your assumptions in the above statement?

Having made this request, I guess it's only fair to expose the model that
I'm assuming.  I'm thinking of a software development organization that
produces "products" (where the consumers may be outside customers or
internal users), and has several projects going on at once (some of which
may be related).  Rather than having a separate group of "component
producers", components would be produced as spinoffs of normal development
activity.  This would, of course, involve some overhead (from the point of
view of the project manager) to either plan or retrofit the desired
qualities into the component.  I'm not advocating this as the only way to
go, but it seems like a reasonable initial goal for a multi-project
organization.

Unfortunately, I haven't received Johnson's message, and I'd rather not
comment on an excerpt out of context, but I will say that having more than
one implementation for a given spec can be useful for more than performance
reasons (portability to radically different environments, for example).


--
Don Dwiggins				"Solvitur Ambulando"
Ashton-Tate, Inc.
dwiggins@ashtate.a-t.com
dwiggins@ashtate.uucp