Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!mimsy!jogger.cs.umd.edu!straub
From: straub@jogger.cs.umd.edu (Pablo A. Straub)
Newsgroups: comp.software-eng
Subject: Re: Reserve Demobilization System Built Around Reuse
Message-ID: <35728@mimsy.umd.edu>
Date: 17 Jun 91 14:04:49 GMT
References: <1991Jun14.152529.1@east.pima.edu>
Sender: news@mimsy.umd.edu
Reply-To: straub@cs.umd.edu (Pablo A. Straub)
Organization: U. of Maryland, Dept. of Computer Science, College Park, MD 20742
Lines: 41

In article <1991Jun14.152529.1@east.pima.edu> rharwood@east.pima.edu writes:
>
> OK... maybe we can LIGHTLY (read  as:  "without  flame")  discuss  and
> subsequently define what reuse really IS (or ought to be!).
>  
> My Personal Opinion: Calling a DBMS or GUI  or  math  routine  is  NOT
> reuse.   Libraries  of  complex  mathematical  subroutines  have  been
> available to FORTRAN  programmers  since  ENIAC,  I  suppose.  Perhaps
> "reuse"  is  truly  short-hand  for  "source code reuse"? The term has
> mostly come to represent the ability to incorporate  software  written
> for  or funded by "some other" project with little or no modification;
> perhaps some customization (specifically, the instantiation of an  Ada
> GENERIC unit for the target elements).
> 
> Ray Harwood

I hope reuse is not seen only with respect to code.  The  prospects  are
much wider.

First, most people informally reuse all sorts  of  documents,  including
specifications,  design,  code,  test  suites,  end-user  documentation,
estimates, you name it. For a more effective reuse of  documents  people
invest   in   reuse,   for   example  creating  parameterized  documents
(parameters for a subroutine, generic parameters, macros for  documents,
etc.), designing for reuse, training for reuse, etc.

Second,  you  most  people  reuse  the  processes  that  created   those
documents,  simply  by  learning  from  experience. For a more effective
reuse of processes few :-( people actually record their process (e.g., a
developer's manual for their organization). If the process is  extremely
well  structured,  then  it  can  recorded as a program whose parameters
represent particular instantiations of the  development  process--and  a
brand new software generator is born. :-)

Hence we can view the use of a 4GL as reuse of some development process.

BTW, it's nice to have part of your product funded by other project, but
if that's the only way we are to reuse there won't be much investment in
software.

Pablo Straub