Re: Reserve Demobilization System Built Around Reused Ada Code

Re: Reserve Demobilization System Built Around Reused Ada Code

[John Goodenough]

In article Re: Reserve Demobilization System Built Around Reused Ada Code of
30 May 91 18:30:53 GMT chuck@brain.UUCP writes:

> code. It is misleading to the customer and the industry at large to portray
> such development efforts as true reuse. I am NOT demeaning the achievement.
> Let's just call a spade a spade. Maybe "rapid tailoring" or "rapid
reengineering"
> is a more suitable term for this type of approach.

It is my impression that the figures quoted for high levels of software reuse
and productivity in Japan are often based on just this kind of "rapid
tailoring" or "rapid reengineering".  I remember a paper some years ago
concerned with generating process control software by a Japanese company in
which they reported high levels of software reuse because they were tailoring
their standard software to each customer's needs.  Should we call it reuse
when the end user is different, and otherwise call it enhancement?  Depends
on
what techno-political games you want to play...

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Reserve Demobilization System Built Around Reused Ada Code

[Jim Showalter]

>Should we call it reuse
>when the end user is different, and otherwise call it enhancement?  Depends
>on
>what techno-political games you want to play...

My definition of reuse is quite simple: any time you didn't have to write
a line of code, you reused it. This may not be the definition of reuse
people envision when they use the term "reuse", but in the end all that
truly matters is the COST--a line saved is a line earned. If you treat the
entire software development process like a black box, then from the outside
of the box it matters little why the box is more efficient than other
software development boxes--all that truly matters is that it IS more
efficient. If the box is more efficient because of "mere" software
enhancement instead of "pure" reuse, so be it. It degenerates (like so
many things) into an argument over semantics.

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

Re: Reserve Demobilization System Built Around Reused Ada Code

[Piercarlo Grandi]

On 11 Jun 91 06:27:03 GMT, jls@netcom.COM (Jim Showalter) said:

(somebody)> Should we call it reuse when the end user is different, and
(somebody)> otherwise call it enhancement?  Depends on what
(somebody)> techno-political games you want to play...

jls> My definition of reuse is quite simple: any time you didn't have to
jls> write a line of code, you reused it. This may not be the definition
jls> of reuse people envision when they use the term "reuse", but in the
jls> end all that truly matters is the COST--a line saved is a line
jls> earned.

But this does not capture what people "really" mean by reuse. Surely
then using a DBMS, OS, math library, is "reuse" then, by your
definition.

IMNHO "reuse" is so poorly defined, because everybody (but me of course)
does not understand sw development, that any discussion like "using X
means more reuse" is pointless.

For example the use of 4GLs, DBMSes, X windows, and math/GKS/stats/...
libraries to me it is all reuse. Reuse is much more prevalent than
people think, thanks to old fashioned concepts like servers (process
based reuse) and libraries (module based reuse).

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.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

Re: Reserve Demobilization System Built Around Re

[rharwood]

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

Re: Reserve Demobilization System Built Around Re

[Jim Showalter]

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

Re: Reserve Demobilization System Built Around Re

[rharwood]

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

Re: Reserve Demobilization System Built Around Re

[Ralph Johnson]

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.

Re: Reserve Demobilization System Built Around Re

[Eric Wayne Sink]

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.

Re: Reserve Demobilization System Built Around Re

[27126-Joe Niederberger(G030)m000]

>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

Re: Reserve Demobilization System Built Around Re

[James E. Cardow]

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

Re: Reserve Demobilization System Built Around Re

[Ralph Johnson]

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

Re: Reserve Demobilization System Built Around Re

[Jim Showalter]

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

Editing languages (Was: Re: Reserve Demobilization ...)

[Greg Titus]

In article <1991Jun21.015801.25167@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>
> [deleted short reuse discussion]
>
>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.

Somewhat off the subject, but this brought to mind the topic of
editing languages ...

An editing language is a wonderful thing to have in your
toolbox.  Not having to worry about the screen manipulation and
buffering and so on saves boatloads of implementation time.  I
recall writing TECO code for quite a few small interactive data
entry/editing tools in the past, and the Eel language from
Epsilon is highly useful for this sort of thing as well.

TECO was invented at MIT back in the 60's.  I doubt you could
find a running TECO any more, but it was widely available (from
DECUS) on DEC PDP series machines as recently as 1980 at least.
The original EMACS was written in TECO; in fact, the name stands
for Editing MACroS, since EMACS was just a set of TECO macros
for keeping the screen continuously updated.  If you remember
TECO, you're a Pretty Old Programmer (Not Real Old, but Pretty
Old).  Or maybe you just started young ...   ;-)

Epsilon's Eel is also used to implement EMACS, but for MS-DOS
machines.  Eel is mostly C, but with some things not essential
to editing left out and some others that are essential added.
You get most of the Eel source for Epsilon's EMACS when you buy
it, so you can add to or modify the editor's functionality.  The
nice thing is that you can also implement standalone-ish
programs with it.

Jim and I largely agree about Ada's strengths for design and
implementation, I think.  Nevertheless, if you're a fan of
computer languages, ya gotta love the oddities among them, like
editing languages.  And I didn't even mention fun things like
SNOBOL, APL, ...

Speaking of such, my own favorite language name is "PLITS", for
"Programming Language In The Sky".  I heard of this a long time
ago, but I don't know much about it other than the name.  I
believe that it was a research language, and that there was only
one compiler ever built for it.  Can anybody out there enlighten
us about PLITS?

greg
--
--------------------------------------------------------------
Greg Titus (gbt@zia.cray.com)             Compiler Group (Ada)
Cray Research, Inc.                               Santa Fe, NM
Opinions expressed herein (such as they are) are purely my own.

Re: Reserve Demobilization System Built Around Re

[Orville R. Weyrich]

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)
--------------------------------------           ******************************

Re: Reserve Demobilization System Built Around Re

[D. C. Sessions]

  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          -=-=-+

Re: Reserve Demobilization System Built Around Re

[Orville R. Weyrich]

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)
--------------------------------------           ******************************

Re: Reserve Demobilization System Built Around Reused Ada Code

[Jim Showalter]

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>jls> My definition of reuse is quite simple: any time you didn't have to
>jls> write a line of code, you reused it. This may not be the definition
>jls> of reuse people envision when they use the term "reuse", but in the
>jls> end all that truly matters is the COST--a line saved is a line
>jls> earned.

>But this does not capture what people "really" mean by reuse. Surely
>then using a DBMS, OS, math library, is "reuse" then, by your
>definition.

Indeed! And what other term SHOULD we apply to using a DBMS instead of
writing our own? See, that's what's so ironic about reuse--like AI,
as soon as someone achieves a significant SUCCESS in the area of reuse,
people change the rules ("No, THAT'S not really reuse...that's just
using off-the-shelf software..."). The whole IDEA of reuse is to get
to the point where you yank a bunch of preexisting software off a shelf
and lash it together with a bit of glue, in exactly the same way that
any other engineering discipline makes use of preexisting parts, subsystems,
cards, chips, pistons, or what have you. We build software the way people
built flintlock rifles before what's-his-name (damn!--not my day for
Jeopardy questions--what was the name of the guy?) realized that building
N identical triggers as a way to help build N identical rifles might be
a good idea. We're treating software like a custom built item EVERY SINGLE
TIME we build something. This is, not to put too fine a point on it, stupid.

>For example the use of 4GLs, DBMSes, X windows, and math/GKS/stats/...
>libraries to me it is all reuse. Reuse is much more prevalent than
>people think, thanks to old fashioned concepts like servers (process
>based reuse) and libraries (module based reuse).

Well, it appear then that we're in violent AGREEMENT, since that's
exactly how I define reuse too.

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

Again, no argument from me. I'm getting this weird feeling that you
wrote a 50 line post agreeing in total with my original post, and I
just wrote a 50 line post agreeing with yours. Or did I miss something?
-- 
*** 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++.    *

Re: Reserve Demobilization System Built Around Reused Ada Code

[Orville R. Weyrich]

In article <1991Jun15.002253.10735@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>pcg@aber.ac.uk (Piercarlo Grandi) writes:
>
>Indeed! And what other term SHOULD we apply to using a DBMS instead of
>writing our own? See, that's what's so ironic about reuse--like AI,
>as soon as someone achieves a significant SUCCESS in the area of reuse,
>people change the rules ("No, THAT'S not really reuse...that's just
>using off-the-shelf software..."). The whole IDEA of reuse is to get
>to the point where you yank a bunch of preexisting software off a shelf
>and lash it together with a bit of glue, in exactly the same way that
>any other engineering discipline makes use of preexisting parts, subsystems,
>cards, chips, pistons, or what have you. We build software the way people
>built flintlock rifles before what's-his-name (damn!--not my day for
>Jeopardy questions--what was the name of the guy?) realized that building

I'll try Eli Whitney for $0.02.

Funny thing is that his two contributions to science and technology were
the guns that made the Civil War so bloody, and the cotton gin that made
using slave labor so cost-ineffective that slavery would have passed away
of its own accord if given just a little more time. :-(.

>N identical triggers as a way to help build N identical rifles might be
>a good idea. We're treating software like a custom built item EVERY SINGLE
>TIME we build something. This is, not to put too fine a point on it, stupid.
>


--------------------------------------           ******************************
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)
--------------------------------------           ******************************

Re: Reserve Demobilization System Built Around Reused Ada Code

[brian r hanson x6062]

 
|> I'll try Eli Whitney for $0.02.
|> 
|> Funny thing is that his two contributions to science and technology were
|> the guns that made the Civil War so bloody, and the cotton gin that made
|> using slave labor so cost-ineffective that slavery would have passed away
|> of its own accord if given just a little more time. :-(.

According to a book I have just been reading, you are wrong.  Eli Whitney was
not the first to have the idea of building bunches of identical parts and
manufacturing stuff by putting together these parts.  It was used in europe
some years earlier.  It also seems that his parts were not very identical but
he did manage to obtain quite a lot of money from the government for this.

Eli also did not invent the cotton gin but made an improvement to an existing
gin to get it to work with the american cotton plants which was in turn made
workable by yet another person.

Finally, the connection between the cotton gin and the deepening of slavery
is also not quite so clear cut according to this book.  Out side the deep
south the number of slaves per farm was lower in the years after the gin
was introduced.

Brian Hanson

Re: Definition of 'reuse' (was Re: a real long title)

[Norman Diamond]

In article <1991Jun14.103725.2765@dit.upm.es> esink@turia.dit.upm.es (Eric Wayne Sink) writes:
>In comp.lang.ada, Jim Showalter contributes to a discussion on
>software reuse :
>>My definition of reuse is quite simple: any time you didn't have to write
>>a line of code, you reused it.
>
>Anyone like to contribute their definition of 'software reuse' ?

Letting the compiler do the copying instead of doing it in the text editor.

>Jim once again exposes his bias by the mere fact that his posting
>appeared in an ada newsgroup.  I admit that I expose my own bias
>by placing the discussion in comp.object.

He probably just participated in a discussion that he saw going on, and
joined the people who were already talking.  Software reuse would be nice
in any language; does that mean that we should cross-post to comp.lang.*?

>Anyone feeling that a wider discussion involving our friends from
>comp.software-eng is encouraged to invite their participation.

OK, I took up your invitation to invite them.  I didn't put them in the
"Followup-To" line because they're probably bored to death with the topic,
but of course they can edit the followups if they like.
--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Permission is granted to feel this signature, but not to look at it.

Re: Reserve Demobilization System Built Around Reused Ada Code

[Bob Munck]

In article Re: Reserve Demobilization System Built Around Reused Ada Code of
30 May 91 18:30:53 GMT chuck@brain.UUCP  and John Goodenough 
@f98.n250.z1.FidoNet.Org write:

>> Let's call a spade a spade. Maybe "rapid tailoring" or "rapid reengineering"
>> is a more suitable term for this type of approach.
>
> I remember a paper some years ago
>concerned with generating process control software by a Japanese company in
>which they reported high levels of software reuse because they were tailoring
>their standard software to each customer's needs.  Should we call it reuse
>when the end user is different, and otherwise call it enhancement?

Toshiba called it "big profits."  Note that their "Software Factory" was set
up with the help of American consultants (from John G's old company) who 
couldn't sell the ideas in the US because they required planning beyond
the next quarter's P&L statement.


Why is John showing a FidoNet address?  Have the hackers finally taken
over the SEI?

Bob Munck

Re: Reserve Demobilization System Built Around Reused Ada Code

[Chuck Shotton]

In article <1991May30.004737.24473@netcom.COM>, jls@netcom.COM (Jim Showalter) writes:
> >This sounds like a simple enhancement job, not "new" development. 90% code
> >reuse is more like 10% enhancement and maintenance.
> 
> But this is precisely the direction we SHOULD be trying to head when we
> develop software! I can't think of a very strong business case for NOT
> reusing 800KSLOC whenever it is possible to do so, can you? Were that
> MORE projects achieved 90% code reuse, particularly if my taxes are
> paying for them.
> 
I don't disagree one bit. What I hate to see is another contractor horn-blowing
what was ultimately a rehashing of existing code. It was certainly NOT a
properly engineered system that drew on an established repository of reusable
code. It is misleading to the customer and the industry at large to portray
such development efforts as true reuse. I am NOT demeaning the achievement.
Let's just call a spade a spade. Maybe "rapid tailoring" or "rapid reengineering"
is a more suitable term for this type of approach.

-----------------------------------------------------------------------
Chuck Shotton                 Internet:   cshotton@girch1.med.uth.tmc.edu

Re: Reserve Demobilization System Built Around Reused Ada Code

[Jim Showalter]

>I don't disagree one bit. What I hate to see is another contractor horn-blowing
>what was ultimately a rehashing of existing code. It was certainly NOT a
>properly engineered system that drew on an established repository of reusable
>code. It is misleading to the customer and the industry at large to portray
>such development efforts as true reuse. I am NOT demeaning the achievement.
>Let's just call a spade a spade. Maybe "rapid tailoring" or "rapid reengineering"
>is a more suitable term for this type of approach.

Chuck, why do I get the idea that we basically agree on a fundamental set
of core principles, but keep getting wound around the axle because of
semantics? You say tomayto, I say tomahto... (I'm not flaming--it is
just an observation I've made.)

Perhaps in this case the disagreement is simply due to my belief that the use
of code more than once constitutes reuse BY DEFINITION, in contrast with some
other notion you (I THINK) refer to as "true reuse". I guess the problem
I have is I don't know what true reuse is, or how it differs from reusing
(as opposed to rewriting from scratch) 800KSLOC of code on the project
described at the beginning of this thread.

I'm reminded, in fact, of a paper a friend of mine gave on reuse (he got
his PhD in the subject) in which his opening words were "I'm not sure
what reuse means". He went on to explain that it was a lot like the paradox of
AI: every time someone achieves something in the AI domain, people respond
by saying "Oh, well, THAT'S not AI, that's just <some other term>". And
yet, progress keeps getting MADE in the AI field. Is reuse going to be
a victim of the same phenomenon? My personal view of reuse is that it happens
all the time, it happens in great amounts, and we all think there is a 
terrible problem with achieving reuse because we refuse to recognize it
when it is staring us in the face because we were expecting something
else, something more remarkable and harder to grasp.
-- 
**************** 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++.    *

Re: Reserve Demobilization System Built Around Reused Ada Code

[Jerry Callen]

> [In several articles, Jim Showalter and Chuck Shotton debate whether 
>  a recent Ada success should be called "enhancement and maintenance"
>  or "reuse."]

I don't suppose anyone associated with the project is reading this
news group, are they? Don't be shy! :-)

I find it quite easy to believe that some 800K SLOC of Ada could be
"reused" as is; I have a LOT of packages that I reuse all the time,
and I can believe that a large system might be, say, 80% existing
utilities (database management, windowing package, etc.) and 20% glue.

On the other hand, I can also picture "enhancing" a large portion of not
necessarily directly reusable code, making many changes in many places.
Ada makes THAT relatively easy, too.

SO - unless someone on the project can comment, let's admit that we're
all guessing, shall we? :-)

-- Jerry Callen
   jcallen@encore.com

Re: Reserve Demobilization System Built Around Reused Ada Code

[Hoysch]

	I believe it is possible to have 80% reuse and not just be a rehash.
A sister project to the one I am working on released the first version of their
project that had about the same % of reuse.  The project (SMB, mentioned in
AdaIC recent issue and in Ada strategies (the one from the December time frame).
is more than rehash or maintanence because 3 subsystems from 3 other projects 
were extracted (w/ some modifications of course) and with a little
new code to come up with the new product.  Furthermore, the project that I am
currently working on has (only a approximation) between 50 and 60% reuse, not 
counting C code that was converted (and often redesigned for) to Ada (often
not too much savings).

			Dan "hoysch" Heuschele

Re: Reserve Demobilization System Built Around Reused Ada Code

[John Goodenough]

In article Re: Reserve Demobilization System Built Around Reused Ada Code of 30 May 91 18:30:53 GMT chuck@brain.UUCP writes:

> code. It is misleading to the customer and the industry at large to portray
> such development efforts as true reuse. I am NOT demeaning the achievement.
> Let's just call a spade a spade. Maybe "rapid tailoring" or "rapid reengineering"
> is a more suitable term for this type of approach.

It is my impression that the figures quoted for high levels of software reuse
and productivity in Japan are often based on just this kind of "rapid
tailoring" or "rapid reengineering".  I remember a paper some years ago
concerned with generating process control software by a Japanese company in
which they reported high levels of software reuse because they were tailoring
their standard software to each customer's needs.  Should we call it reuse
when the end user is different, and otherwise call it enhancement?  Depends on
what techno-political games you want to play...

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Reserve Demobilization System Built Around Reused Ada Code

[Chuck Shotton]

In article <9105271627.AA29654@grebyn.com>, karl@grebyn.com (Karl A. Nyberg) writes:
> Lt. Gen Jerome Hilmes, director of information systems for command, control,
> communications and computers, said Army programmers were able to design a
> 900,000-line demobilization system in 30 days for about $500,000.  The quick
> programming turnaround was possible because about 800,000 lines of the Ada
> code were borrowed from previously designed systems, he said.
> 
This sounds like a simple enhancement job, not "new" development. 90% code
reuse is more like 10% enhancement and maintenance.

-----------------------------------------------------------------------
Chuck Shotton                 Internet:   cshotton@girch1.med.uth.tmc.edu
"Your silly quote here."      UUCP:       ...!buster!brain!chuck

Re: Reserve Demobilization System Built Around Reused Ada Code

[Jim Showalter]

chuck@brain.UUCP (Chuck Shotton) writes:
>In article <9105271627.AA29654@grebyn.com>, karl@grebyn.com (Karl A. Nyberg) writes:
>> Lt. Gen Jerome Hilmes, director of information systems for command, control,
>> communications and computers, said Army programmers were able to design a
>> 900,000-line demobilization system in 30 days for about $500,000.  The quick
>> programming turnaround was possible because about 800,000 lines of the Ada
>> code were borrowed from previously designed systems, he said.
>> 
>This sounds like a simple enhancement job, not "new" development. 90% code
>reuse is more like 10% enhancement and maintenance.

But this is precisely the direction we SHOULD be trying to head when we
develop software! I can't think of a very strong business case for NOT
reusing 800KSLOC whenever it is possible to do so, can you? Were that
MORE projects achieved 90% code reuse, particularly if my taxes are
paying for them.
-- 
**************** 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++.    *

Reserve Demobilization System Built Around Reused Ada Code

[Karl A. Nyberg]

From Government Computer News, May 13, 1991, p. 63.

The theory that Ada programming will get chaper as the Defense Department
cashes in on the language's potential for reuse apparently has proved true
for at least one Army system.

Lt. Gen Jerome Hilmes, director of information systems for command, control,
communications and computers, said Army programmers were able to design a
900,000-line demobilization system in 30 days for about $500,000.  The quick
programming turnaround was possible because about 800,000 lines of the Ada
code were borrowed from previously designed systems, he said.

The Army will use the new system as it deactivates more than 200,000
reservists called up to support the Persian Gulf war.  The system, which
automates the Army's standard discharge for for the first time, runs on AT&T
Co. 3B2 minicomputers at seven locations.

Hilmes said the system will reduce by a factor of two the time it takes to
send a reservist back to civilian life.  It was designed as part of the
Army's continuing Installation Support Module program.

Under ISM, the Army has standardized about eight servicewide functions
performed at Army bases worldwide.  So far, ISM officials "overall are
getting about 56 percent reuse of the code they generate", he said.

Hilmes spoke at a recent Armed Forces Communications and Electronics
Association budget symposium in Arlington, VA.