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