[comp.software-eng] Reserve Demobilization System Built Around Re

rharwood@east.pima.edu (06/15/91)

In article <PCG.91Jun14183250@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo
Grandi) writes:

> Usually, I suspect, reuse is meant to be applied to the narrow case
> where one does custom sw development, which is no longer the case in
> most commercial installation; nearly everybody nowadays is using DBMSes
> and enjoying the benefits of not reimplementing from scratch data
> management programs.

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).  A major rewrite would be
excluded frp

Ray
-----
Ray Harwood           |Data Basix           |Associate Faculty,    
Voice: (602)721-1988  |PO Box 18324         |   Pima Community College
FAX:   (602)721-7240  |Tucson, AZ 85731     |Instructor in Ada and Pascal
CompuServe: 76645,1370|AppleLink: DATA.BASIX|Internet: rharwood@east.pima.edu

paul@hal.com (Paul Sander) (06/15/91)

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!).

Sounds like an old debate firing up again...

>My Personal Opinion:  Calling a DBMS or GUI or math routine is NOT reuse. 

Why?  Suppose you write a generic quicksort routine, and include it in a new
product.  Since you just wrote this, obviously it was not reused.  But later
you use it in another product.  Is this reuse?  Certainly.  Then you change
jobs and add that routine to the runtime library of a new operating system
so others don't need to rewrite it.  When those other customers call your
quicksort routine, is this reuse?  At this point, your quicksort routine has
fallen into the same category of a DBMS or GUI or math routine.

>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).  A major rewrite would be
>excluded frp

I should hope that simply copying source code is not what we consider to be
"code reuse."  As I've said before, "my code reuse tool of choice used to be
the editor, until I inherited 60,000 lines of code from somebody else who
thought the same way."  Now my code reuse tool of choice is the linker.

Simply duplicating source code and tweaking it to fit a new application
oftentimes is not a good way to reuse code, as it opens up a debugging
nightmare.  (Oops, there's a bug.  Fixed it.  Now where are all those copies
I made?)

I would like to suggest that code reuse be defined at the object code level,
in the form of libraries and header files (in the case of C and C++ and
assembler), or generics in Ada.  After all, reuse is precisely what these
tools were invented for.

The trick, then, is to figure out how to write libraries that are generic
enough to be used by a wide variety of applications without being rewritten.
Ada's generics provide a way of doing this, and pointers in other languages
provide the opacity needed to hide the details on both sides of the interface.
-- 
Paul M. Sander  (408) 379-7000  |  I just started here, and haven't thought of
HaL Computer Systems            |  a new witty quotation yet.
1315 Dell Avenue                |
Campbell, CA  95008  USA        |

jls@netcom.COM (Jim Showalter) (06/15/91)

>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.

What is it, then? "use-again"? "repeated-use"? "use-more-than-once"? Sounds
like reuse to me...

>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;

When one makes use of a DMBS or a GUI or a set of math routines, is this
not PRECISELY what you just described? Okay, I will concede one point: people
do seem to think that reuse spans projects. Fine--doesn't a DBMS span projects?
Over multiple project lifetimes, mechanisms that keep coming up (that "haven't
we built this already?" feeling of deja vu) eventually get turned into highly
reusable componentry--such as a DBMS, a GUI, or a set of math routines did at
some point in the distant (or not so distant) past. The
only possible distinction I can see between this and the rather loose notion
people seem to have of reuse is that when one reuses a DBMS/GUI/math routine
one is reusing some software component that has become common currency. Perhaps
people think of reuse as being the repeated use of some kind of software that
has yet to become common currency? In that case, the only clear distinction
is one of TIME.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

rharwood@east.pima.edu (06/15/91)

In article <1991Jun15.010746.12768@netcom.COM>, jls@netcom.COM (Jim Showalter)
writes:

>>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.
> 
> What is it, then? "use-again"? "repeated-use"? "use-more-than-once"? Sounds
> like reuse to me...

COTS (commercial off-the-shelf) software could indeed be defined as "software
reuse".  And if that's the case, then everyone who's ever purchased
WordPerfect (<=insert the name of whatever word processor you like) instead of
WRITING THEIR OWN word processor has indeed REUSED software.

I guess what I'm proposing is that software REUTILIZATION be broken into three
distinct categories, with words and definitions similar to the following:

(1) Commercial Off-the-shelf (COTS) software:  executable machine instructions
written, compiled, and distributed by an organization as a primary market item. 
Includes word processors, spreadsheets, desktop publishing, and run-time-only
DBMS licenses, and I suppose also includes operating systems.

(2) Library routines: object code provided by someone other than the
end-product programming organization, generally without source code,
incorporated into a distinctly separate software "entity" with a purpose
greater than that of any individual library routine.  Includes mathematical
function libraries, matrix manipulation, file handling (such as an indexed file
system for PCs which have no inherent indexed file capability), DBMSs with
callable interfaces, network interfaces (like APIs?), and specialized "glue
routines" in one language designed to interface to the underlying operating
system or other COTS software.

(3) Reused/reusable Source Code: 3rd or 4th generation source language
statements provided by anyone (including within and outside of the end-product
programming organization) which is compiler by the programming staff and used
with little or no modification.  If you've got to run it through your own
compiler to use it, and you didn't write it, it's reused.

Summary:  COTS = executable, Libraries = object, Reuse = source.

Again, these terms & definitions are just my impressions of what many people
seem to mean when they talk about "not writing it yourself."  I suppose this
discussion is a lot like "recycling", a lot depends on your definitions! 
Driving alone in your own car every day ISN'T recycling dinosaur energy...

> Over multiple project lifetimes, mechanisms that keep coming up (that "haven't
> we built this already?" feeling of deja vu) eventually get turned into highly
> reusable componentry--such as a DBMS, a GUI, or a set of math routines did at
> some point in the distant (or not so distant) past.

Without belaboring the origins of any one DBMS, I'd say "Yes, Oracle (<=insert
name of any DBMS) was AT SOME POINT IN ITS DEVELOPMENT composed of reuseable
source code, but once it was compiled into an executable module and sold "as
is", then it became COTS software; and the linkable calls are a part of your
library of routines; but it's NOTp
suit your particular needs."

Indeed, Oracle Corp REUSED it's own code when porting the SOURCE code to create
executables for other platforms... but YOU can't take your own "reusable" copy
of Oracle and modify it to run on a 2MB Nintendo (without losing a LOT in the
translation!).

Ray

orville@weyrich.UUCP (Orville R. Weyrich) (06/16/91)

In article <1991Jun14.152529.1@east.pima.edu> rharwood@east.pima.edu writes:
>In article <PCG.91Jun14183250@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo
>Grandi) writes:
>
>> Usually, I suspect, reuse is meant to be applied to the narrow case
>> where one does custom sw development, which is no longer the case in
>> most commercial installation; nearly everybody nowadays is using DBMSes
>> and enjoying the benefits of not reimplementing from scratch data
>> management programs.
>
>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).  A major rewrite would be
>excluded frp

On the contrary, I would say that Calling DBMS, GUI, IMSL libraries, etc
are important examples of reuse. If these facilities were not available,
then people would be constantly re-implementing them. Perhaps these mundane
examples of reuse are taken for granted because they work so well.

This is not to say that there isin't great untapped potential for greater reuse.There is still a long way to go. There are several challenges involved in
increasing reuse:

	1) How to determine what is a candidate for reuse, and how to
	   package and describe it.

	2) How to find things that are available for reuse and which are
	   applicable to the problem at hand.

	3) How to glue together reusable fragments to form a coherent whole.

	4) How to create and use language features which facilitate reuse. 
	   (Examples include Ada generics, C++ multiple inheritance, ...).

	5) Legal questions like how to assure return on investment for those
	   who prepare software for reuse, and how to protect the initial
	   client from paying the entire development cost of a new reusable
	   component.

The current examples of reuse have successfully met these challenges. The
question remains, "what can we do for an encore?"



--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

orville@weyrich.UUCP (Orville R. Weyrich) (06/16/91)

In article <1991Jun15.010746.12768@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>
>When one makes use of a DMBS or a GUI or a set of math routines, is this
>not PRECISELY what you just described? Okay, I will concede one point: people
>do seem to think that reuse spans projects. Fine--doesn't a DBMS span projects?
>Over multiple project lifetimes, mechanisms that keep coming up (that "haven't
>we built this already?" feeling of deja vu) eventually get turned into highly
>reusable componentry--such as a DBMS, a GUI, or a set of math routines did at
>some point in the distant (or not so distant) past. The
>only possible distinction I can see between this and the rather loose notion
>people seem to have of reuse is that when one reuses a DBMS/GUI/math routine
>one is reusing some software component that has become common currency. Perhaps
>people think of reuse as being the repeated use of some kind of software that
>has yet to become common currency? In that case, the only clear distinction
>is one of TIME.

And the goal of software reuse then becomes synonymous with the goal of
recognizing a common pattern and formalizing it in the form of a new
abstraction which can be accepted as common currency?

I'll accept that as PART of what reuse is all about. See my previous post
for a list of other aspects of reuse.



--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

dc@sci.UUCP (D. C. Sessions) (06/17/91)

  Another $0.02:

  It only *FEELS* like reuse if I thought I might have to do it 
  myself.  Some of us old-timers still appreciate that compilers 
  represent a kind of reuse because we once expected to do that sort 
  of thing by hand.  (compilers? Hell, assemblers!)

  Do you think of a 6-32 screw as reuse?  Only if you've spent some of 
  your life far from hardware stores.  Same with software.  Some of us 
  have managed to preserve a sense of wonder that the assembler works; 
  others take math libraries, DBMSs, and such for granted.  Not 
  surprisingly, the latter group doesn't count these things as reuse.
-- 
| The above opinions may not be original, but they are mine and mine alone. |
|            "While it may not be for you to complete the task,             |
|                 neither are you free to refrain from it."                 |
+-=-=-    (I wish this _was_ original!)        D. C. Sessions          -=-=-+

johnson@cs.uiuc.EDU (Ralph Johnson) (06/17/91)

In article <1991Jun14.231725.1@east.pima.edu>, rharwood@east.pima.edu writes:
|> 
|> COTS (commercial off-the-shelf) software could indeed be defined as "software
|> reuse".  And if that's the case, then everyone who's ever purchased
|> WordPerfect (<=insert the name of whatever word processor you like) instead of
|> WRITING THEIR OWN word processor has indeed REUSED software.
|> 
...

|> (1) Commercial Off-the-shelf (COTS) software:  executable machine instructions
|> written, compiled, and distributed by an organization as a primary market item. 
|> Includes word processors, spreadsheets, desktop publishing, and run-time-only
|> DBMS licenses, and I suppose also includes operating systems.

There is a world of difference between a word processor or a desktop
publisher and a spreadsheet or a DBMS or an operating system.  The
first two are usually systems that are not programmable and can not
be used with other software.  Most DBMSs can be linked to application
programs, and let those programs reuse all the file access and search
routines.  Operating systems let application programs reuse I/O and
file system routines.  A spreadsheet (when treated as reusable software,
and not just a fancy calculator) provides a user interface, a constraint
solver, and a library of math and database routines.

EMACS is more reusable than vi because it comes with an extension
language and can be completely reprogrammed.  Lots of people use it
as a user interface manager.  Similarly, DBMS's, spreadsheets, and OS's
differ in reusability.  Nevertheless, they can all be considered
reusable software.

Almost nobody who gets published equates reuse with making the source
code available.  In fact, most people consider it a liability to have
to distribute source code.  I guess I do to, though I consider it a
necessary liability, because the systems I've seen that offered the
most reuse all came with source.  It is bad to require people to look
at source, but the ability to change the source adds an extra degree
of reuse.

While I am at it, some people think that reuse occurs ONLY when you do
NOT change the source.  I disagree with this opinion.  It is best when
you do not have to change the source because that makes it easiest to
see what is reused and what is new.  However, if you can reuse 1,000,000
lines of code and only have to change 100 lines then it seems to me to
be a great success.  It is impossible for the designers of reusable
software to predict every use to which it might be put.  Access to source
lets the reusers take paths that the designers did not forsee.

Ralph Johnson -- U. of Illinois at Urbana-Champaign, Dept. of C.S.

esink@turia.dit.upm.es (Eric Wayne Sink) (06/18/91)

In article <1991Jun17.145146.5307@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes:
>
[stuff deleted]
>EMACS is more reusable than vi because it comes with an extension
>language and can be completely reprogrammed.  Lots of people use it
>as a user interface manager.  Similarly, DBMS's, spreadsheets, and OS's
>differ in reusability.  Nevertheless, they can all be considered
>reusable software.
[more stuff deleted]
>
>Ralph Johnson -- U. of Illinois at Urbana-Champaign, Dept. of C.S.

What irks me about some of this is the rapidly graying distinction
between 'reuse' and 'use'.  From a research perspective, most people
will agree with the idea that reusable software is hard to make.
Some would even say that USABLE software is hard to make.  But where
are we going to draw the line between these two ideas ?  If we make the
idea of 'reuse' too wide, it ceases to be quite so interesting.  For
example, I'm using a terminal program called Telex to access a Sun
to write this message.  Come to think of it, I used Telex yesterday too.
Actually, I've used Telex EVERY day for months !  However, I consider
this to be software USE, certainly not reuse.  On the other end,
a linkable library of routines offers me reuse.  A collection of well
written routines with source offers me reuse.  It's the middle ground
that bugs me.  Is there a fine line between use/reuse when talking about
a spreadsheet ?  Is Emacs REUSABLE just because it has a programming
language built in, or is it just a whole lot more USABLE than vi ?

I'll admit I don't know how to put this distinction into a well worded
definition.  Perhaps USE is associated with a USER ?  Therefore, REUSE
occurs when software is used by a non-USER ? (ugly definition)
Perhaps, REUSE occurs when software is employed to develop more
software (but what do you call a compiler then ?)

I honestly don't know, but I haven't seen a definition I like yet.
That's why I ask questions. :-)

Eric W. Sink                     | "If no one is criticizing |Opinions
Departamento de Telematica       | your work, it is possible |mine -
Universidad Politecnica de Madrid| that you are not doing    |all of
esink@turia.dit.upm.es           | anything." -George Verwer |them.

jgn@nvuxe.uucp (27126-Joe Niederberger(G030)m000) (06/18/91)

>What irks me about some of this is the rapidly graying distinction
>between 'reuse' and 'use'.  From a research perspective, most people
>will agree with the idea that reusable software is hard to make.
>Some would even say that USABLE software is hard to make.  But where
>are we going to draw the line between these two ideas ? 

<stuff deleted>

>Is there a fine line between use/reuse when talking about
>a spreadsheet ?  Is Emacs REUSABLE just because it has a programming
>language built in, or is it just a whole lot more USABLE than vi ?
>
>I'll admit I don't know how to put this distinction into a well worded
>definition.  Perhaps USE is associated with a USER ?  Therefore, REUSE
>occurs when software is used by a non-USER ? (ugly definition)
>Perhaps, REUSE occurs when software is employed to develop more
>software (but what do you call a compiler then ?)

It seems to me that software reuse is a (albeit fuzzy) proposed method
for creating software (a) faster (b) with less bugs (c) with lots of
other nice qualities...

Given that, does trying to pin down precise definition for "Software
Reuse" really help? The "problem" (timeliness, bugs, etc.) remains --
finding *new* ways to reuse software helps chip away the boundaries of
the "problem". It seems that old triumphs (OS, DBMS, Compilers, etc.)
become less interesting to someone trying to chip away at the current
boundares of the problem, rather than the boundaries that existed ten or
twenty years ago. Likewise, novel concepts of reuse today will be boring
ten years from now. 

Can an abstract definition of "Software Reuse" capture the ever shifting
focus of attention? Its like trying to define art -- artists tend to
care the least about any academic definitions.

Just my 2 cents.

Joe Niederberger

jcardow@afit.af.mil (James E. Cardow) (06/19/91)

esink@turia.dit.upm.es (Eric Wayne Sink) writes:


>What irks me about some of this is the rapidly graying distinction
>between 'reuse' and 'use'.  From a research perspective, most people
>will agree with the idea that reusable software is hard to make.
>Some would even say that USABLE software is hard to make.  But where
>are we going to draw the line between these two ideas ?  If we make the
>idea of 'reuse' too wide, it ceases to be quite so interesting.  For
>example, I'm using a terminal program called Telex to access a Sun
>to write this message.  Come to think of it, I used Telex yesterday too.
>Actually, I've used Telex EVERY day for months !  However, I consider
>this to be software USE, certainly not reuse.  On the other end,
>a linkable library of routines offers me reuse.  A collection of well
>written routines with source offers me reuse.  It's the middle ground
>that bugs me.  Is there a fine line between use/reuse when talking about
>a spreadsheet ?  Is Emacs REUSABLE just because it has a programming
>language built in, or is it just a whole lot more USABLE than vi ?

>I'll admit I don't know how to put this distinction into a well worded
>definition.  Perhaps USE is associated with a USER ?  Therefore, REUSE
>occurs when software is used by a non-USER ? (ugly definition)
>Perhaps, REUSE occurs when software is employed to develop more
>software (but what do you call a compiler then ?)

>I honestly don't know, but I haven't seen a definition I like yet.
>That's why I ask questions. :-)

I agree that there is considerable confusion over the boundary lines.  In fact,
I've used that in classes to make the students think about their preconceived
notions of what constitutes reuse.  In looking for a good definition of
reuse I came across the following by Spencer Peterson:

  Software Reuse  (1)  The process of using pre-existing software during the 
  	development of implementing new software systems and components.  (2)
	the results of the process in (1).

I usually fall back to something I believe comes from Tracz, that nothing
is reusable until it has been used successfully three times.  Trouble is, 
that doesn't account for packages (i.e. a wordprocessor).  Peterson's definition
takes care of that by limiting the use of reuse to construction activities.

Anyone else have a good definition or distinction?


	Jim Cardow, Capt, USAF
	Air Force Institute of Technology
	Instructor in Software Engineering
	Professional Continuing Education Program
		E-mail:  jcardow@blackbird.afit.af.mil

johnson@cs.uiuc.EDU (Ralph Johnson) (06/21/91)

In article <1991Jun18.115820.18363@dit.upm.es>, esink@turia.dit.upm.es (Eric Wayne Sink) writes:
|> 
|> What irks me about some of this is the rapidly graying distinction
|> between 'reuse' and 'use'. 

Reuse is always associated with programming.  Reuse is reducing the
amount of programming needed by using an existing piece of software
to provide some of the functionality of the system you are building.

EMACS is reusable software because you can use it as the front-end of
a tree editor, of a syntax-directed program editor, of a theorem prover,
and of a news reader.  Each of these projects was implemented much faster
because it was able to reuse a lot of software built into EMACS.

This is entirely different from using EMACS to increase productivity
by editing programs faster, or by using its automatic invokation of
makefiles.  EMACS is a nice editor, but that is not what I am talking
about.  EMACS can be thought of as a large subroutine library.

If EMACS were designed from the beginning as a large subroutine library
then it is quite likely that it would have been designed differently.
It is not as reusable as it might be.  However, it seems to me that it
is definitely reusable software in ANY sense of the word.

Word processing software is usually not reusable software.
There is no way for another application to invoke its functions.
The various microcomputer operating systems seem to be going
toward an "inter-application interface" that will let any program
makes calls on any other program.  This might lead to the day when
word processing software is reusable, too.

Ralph Johnson -- University of Illinois at Urbana-Champaign

jls@netcom.COM (Jim Showalter) (06/21/91)

>Reuse is always associated with programming.  Reuse is reducing the
>amount of programming needed by using an existing piece of software
>to provide some of the functionality of the system you are building.

I like this definition.

>Word processing software is usually not reusable software.
>There is no way for another application to invoke its functions.

The Rational text editor can, believe it or not, be invoked programmatically
because all of its operations are exported out of a package called Editor,
so you can do stuff like:

    Editor.Cursor.Up (Lines => 4);
    Editor.Char.Insert_String ("This is done by magic.");
    etc.

Comes in handy sometimes, and is great for automating demos.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *