Re: Request for reuse tool info

[think.com!yale.edu!ira.uka.de!gate.fzi.de!fweber@uunet.uu.net (Franz Web]

In article <1992Dec1.192517.16082@mprgate.mpr.ca>, janzen@lichen.mpr.ca (Martin
 Janzen) writes:
|> In article <1992Dec1.152321.29538@rti.rti.org>, wgr@rti.org (Bucky Ransdell)
 writes:
|> >I am investigating tools supporting software reuse.  I'm interested in both
...
|> 
|> One interesting approach would be to simply use a very fast text retriever.
|> I saw a demonstration recently of something called "Pat", from Open Text
...
|> 
|> I think that a full-text retrieval system would have a number of advantages.
|> It should eliminate much of the need for elaborate classification schemes,
...

Such an approach would IMHO at least require a specific
thesaurus which relates similar technical notions of the application
domains of the components contained in the database. Furthermore, you
have to ensure certain documentation standards for the components. 
Otherwise important informations for the components will be missing.
For example, for each component the resource requirements (time,
storage) have to be specified.

Another problem is the different view of a producer and the consumer
of reusable software. A producer may specify her component performs
searching in linear time. The consumer on the other hand specifies
that he needs a component which is able to search fast. The
specification what kind of software properties fulfil certain
requirements goes beyond traditional thesarus techniques. In this
situation a taxonomy is needed, which describes relations between
properties and requirements.

Probably, we have to distinguish between selecting reusable software
from an open and heterogenous market and selecting specific components
which have to meet very specific requirements in terms of efficiency
and interoperability with other parts of an already existing system.
It is the nature of a market that we cannot ensure certain
documentation standards or classification according a fixed scheme.
In this sitatuation I could imagine that text retrieval is an
interesting approach. 

However, our experience shows that in the second
situation approaches with rigorous classification schemes are
necessary. Typically the second situation occurs when retrieval is
done in an application specific catalogue of components.
This already implies that the specification of the components is
done in uniform notions of the application domain.
The components have to be assembled to form systems. Therefore,
they have to be interoperable. Hence, they all have to follow certain design
principles (e.g. are part of one class hierarchy) and documentation
standards. The retrieval tool for such a catalogue has to support
all these agreements and standards of the catalogue. This naturally
leads to classification schemes for reuasble software.

-- Franz Weber

|> 
|> The usual caveats:  This is based on a two-hour demonstration; I haven't
|> used "Pat" myself, much less built code repositories with it.  But the
|> remarkable speed of this thing offers some interesting new possibilities...
|> 
|> -- 
|> Martin Janzen                     janzen@mprgate.mpr.ca (134.87.131.13)
|> MPR Teltech Ltd.                  Phone: (604) 293-5309
|> 8999 Nelson Way                   Fax: (604) 293-6100
|> Burnaby, BC, CANADA  V5A 4B5