>>>>> On 4 Oct 91 14:29:28 GMT, josh@saifr00.cfsat.honeywell.com (Josh Lam) said:

Josh> I am very new to the field of `Reusability', its concepts, issue,
Josh> propositions and oppositions(if any).

Josh> Could someone give me some guidelines on how to approach the matter.
Josh> Perhaps an introduction or recommendation on some books, articles,
Josh> newsgroups etc.

Uh, oh, that's a BIG question. I can't really try to answer it here,
but it might be possible to point in some directions. Anyway, here goes...

Reuse is, basically, the idea that instead of writing code from
scratch you use code that has already been written. Using the ordinary
C library is an example.

Sadly, however, reusing non-trivial code is made difficult by many
factors.
  - programming languages may not be designed with reuse in mind
    (modularization and so on)
  - software modules should be very general in order to be readily
    reusable, but most software makes assumptions about the
    environment.
  - finding the right code to reuse can be difficult. Take a look at
    the standard Smalltalk class hierarchy -- it's nice, but finding
    your way around is difficult and takes years of experience.
  - understanding the code, once found, can be difficult (love them
    manuals, right?)
  - the code you find might do just what you want, except for this
    little detail. How do you modify it?
  ...

There are a number of success stories in software reuse, most notably
mathematical function libraries such as NAG. What most of these have
in common is that they
  - do things that can readily be understood without looking at the
    code or the manual -- if you know what ANOVA means, you're on.
  - handle data that can be represented as numbers and arrays of
    numbers.
Where reuse tends to become difficult is when you need to have more
complicated data structures. The structures of different modules might
not fit together or fit what you already have, or it might be
difficult to make modifications or to add your own special data to the
structure.

The promise of OO technology in reuse is that OOPLs make it simpler to
provide well defined software components, with clean and well-defined
interfaces. Even more important, *inheritance* makes it possible to
not only use components as is, but to reuse components in situations
that differ from the original design assumptions. Also, inheritance
makes it possible to design generalized components that can later be
generalized for specific needs (we see here that the lack of
inheritance is why Ada and its ilk do not facilitate large-scale
reuse).

Several modern implementations of OOPLs come with class libraries
providing the basic data structures such as stack, queue, collection,
and so on. G++ and Eiffel are examples. This is a good start and is
one of the major benefits of using such languages.

OO does *not* solve the problem of finding the components to reuse --
imagine an Internet component library with hundreds of thousands of
classes. How to find *anything* in there? We clearly need some more
effective tools. It could be argued that we also need a component
industry, akin to the mechanical component industry.

For reuse to work, it is necessary that programmers adopt the approach.
This means accepting choices made by others, spending type searching
for and understanding components instead of banging out your own code,
taking the time to understand the libraries available in your
environment, and so on. This is partly a cultural and partly a
management issue.

It must be said that, to date, reuse is more promise than reality.
Large scale reuse of general components rarely happens. GUI class
frameworks and toolkits have proved to be quite successful, but few
other examples can be found.

Two excellent books that discusses aspects of OOP and reuse are:

@Book{cox:objc:2ed,
  author =  "Brad J. Cox and Andrew J. Novobilski",
  title =  "Object-Orientated Programming - An evolutionary approach",
  publisher =  "Addison-Wesley",
  year =  "1991",
  address =  "Reading, MA, USA",
  edition =  "2nd",
  isbn =        "0--201--54834",
}

@Book{meyer:oo:soft,
  author =  "Bertrand Meyer",
  title =  "Object-Oriented Software Construction",
  publisher =  "Printice-Hall International",
  year =  "1988",
  address =  "London",
  isbn =        "13 629049 3"
}

The following two volumes, also excellent, provides an excellent
survey of the reuse fields, issues, ideas, problems, etc.

@Book{biggerstaff:perlis:i,
  title =  "Software Reusability",
  publisher =  "{ACM} Press",
  year =  "1989",
  editor =  "Ted Biggerstaff and Alan Perlis",
  volume =  "I, Concepts and Models",
  isbn =        "0 201 08017 6",
}

@Book{biggerstaff:perlis:ii,
  title =  "Software Reusability",
  publisher =  "{ACM} Press",
  year =  "1989",
  editor =  "Ted Biggerstaff and Alan Perlis",
  volume =  "II, Applications and Experience",
  isbn =        "0 201 50018 3",
}

Lots and lots of literature exists on reuse. How 'bout:

@Book{gries:encapsulation,
  title =  "Encapsulation, Modularization and Reusability",
  publisher =  "{ACM} Press",
  year =  "1989",
  editor =  "David Gries",
  isbn =        "0 201 17233 X",
}

@Article{johnson:foote,
  author =  "Ralph E. Johnson and Brian Foote",
  title =  "Designing Reusable Classes",
  journal =  "J.\ Object-Oriented Prog.",
  year =  "1988",
  volume =  "1",
  number =  "2",
  pages =  "22--35",
  month =  "June/July",
}

@Article{coomer:comer:rodjak,
  author =  "Coomer, Jr., T. N. and J. R. Comer and D. J. Rodjak",
  title =  "Developing Reusable Software For Military
   Systems---Why It Is Needed and Why It Isn't Working",
  journal =  "{ACM} Software Engineering Notes",
  year =  "1990",
  volume =  "15",
  number =  "3",
  pages =  "33--38",
  month =  "July",
}

@InProceedings{lange:moher,
  author =  "Beth M. Lange and Thomas H. Moher",
  title =  "Some Strategies of Reuse in an Object-Oriented
   Programming Environment",
  booktitle =  "Human Factors in Computing Systems---{CHI~'89}
   Conference Proceedings",
  year =  "1989",
  editor =  "Ken Bice and Clayton Lewis",
  pages =  "69--73",
  organization =  "{ACM}",
  address =  "Austin, Texas",
  month =  "May",
}

@Article{hopkins:knolle:framework,
  author =  "Jon Hopkins and Nancy Knolle",
  title =  "A Framework for Reusability",
  journal =  "J.\ Object-Oriented Prog.",
  year =  "1990",
  volume =  "3",
  number =  "3",
  pages =  "75--78",
  month =  "September/October",
}

@InProceedings{wirfs-brock:johnson:cunningham:linton,
  author =  "Allen Wirfs-Brock and Ralph Johnson and Ward
   Cunningham and Mark Linton",
  title =  "Designing Reusable Designs---Experiences Designing
   Object-Oriented Frameworks",
  booktitle =  "{OOPSLA--ECOOP'90} Proceedings. Conference on
   Object-Oriented Programming: Systems, Languages, and
   Applications. European Conference on Object-Oriented
   Programming.",
  year =  "1990",
  editor =  "Norman Meyrowitz",
  pages =  "234",
  organization =  "{ACM}/{SIGPLAN}",
  address =  "Ottawa, Canada",
  month =  "21--25 October",
  note =  "Panel Report (also in {SIGPLAN} Notices, 25(10))",
}

@Article{lazarev:reusability:samlltalk,
  author =  "Gregory L. Lazarev",
  title =  "Reusability in {Smalltalk}: A Case Study",
  journal =  "J.\ Object-Oriented Prog.",
  year =  "1991",
  volume =  "4",
  number =  "2",
  pages =  "11--20",
  month =  "May",
}

@Article{wasserman:reuse,
  author =  "Anthony I. Wasserman",
  title =  "Objerct-Oriented Software Design: Issues in Reuse",
  journal =  "J.\ Object-Oriented Prog.",
  year =  "1991",
  volume =  "4",
  number =  "2",
  pages =  "55--57",
  month =  "May",
}

@InProceedings{rosson:carroll:sweeney,
  author =  "Mary Beth Rosson and John M. Carroll and Christine
   Sweeney",
  title =  "A View Matcher for Reusing {Smalltalk} Classes",
  booktitle =  "Reaching Through Technology---{CHI'91} Conference
   Proceddings",
  year =  "1991",
  editor =  "Scott P. Robertson and Gary M. Olson and Judith S. Olson",
  pages =  "277--283",
  organization =  "{ACM} {SIGCHI}",
  publisher =  "Addison-Wesley",
  address =  "New Orleans, Louisiana, USA",
  month =  "April 27--May 2",
  isbn =  "0--201--51278--5",
}


@InProceedings{rosson:carroll:sweeney:demo,
  author =  "Mary Beth Rosson and John M. Carroll and Christine
   Sweeney",
  title =  "Demonstrating a View Matcher for Reusing {Smalltalk}
   Classes",
  booktitle =  "Reaching Through Technology---{CHI'91} Conference
   Proceddings",
  year =  "1991",
  editor =  "Scott P. Robertson and Gary M. Olson and Judith S. Olson",
  pages =  "431--432",
  organization =  "{ACM} {SIGCHI}",
  publisher =  "Addison-Wesley",
  address =  "New Orleans, Louisiana, USA",
  month =  "April 27--May 2",
  isbn =  "0--201--51278--5",
}

/Lars
--
Lars Fischer,  fischer@iesd.auc.dk   | It takes an uncommon mind to think of
CS Dept., Univ. of Aalborg, DENMARK. | these things.  -- Calvin

In article <1991Oct4.142928.26139@saifr00.cfsat.honeywell.com>, josh@saifr00.cfsat.honeywell.com (Josh Lam) writes:

> I am very new to the field of `Reusability', its concepts, issue,
> propositions and oppositions(if any).

> Could someone give me some guidelines on how to approach the matter.

First, understand that there are different kinds of reusability.  The main
division I call (not knowing if there are any better terms) essential .vs.
casual.  `Essential' echoes the analysis-design notion of an `essential'
model, that is, a model which captures a characteristic of the real system.
For analysis, we would speak only of the problem; I'll include the solution
in the term.

`Casual' re-use is the sharing of code that happens to be similar.  This
violates the old-and-still-vital notion of `coupling.'  Coupling occurs
when different and unrelated purposes are shared by the same code or coding
decision (or, for that matter, design decision).  The `incremental programming'
that is so useful when prototyping tends to produce poorly-understood
coupling, and so should be avoided for engineered software--unless the
problem/subject analysis reveals that the problem or a `natural' solution
themselves have an incremental structure.

C++ has three tools for re-use.  These are (1) functions and function call
(same as C), (2) inheritance and virtualization, and (3) parameterized
types (Templates) which become available in Release 3.0.  Each fills a
different niche.  Inheritance and virtualization allow many types to
fulfill the obligations of a given type, replacing function, representation,
or implementation as appropriate (but be sure you know WHICH you mean to
replace).  Templates hold the promise of algorithm and data structure
re-use.  (In message-based languages like Smalltalk and Objective C these
can be accomplished by the virtualization mechanisms--but not in a more
strongly compile-time-typed language.)

Finally, always remember that the first and most important target of re-use
is the next release, the next version, the next bug fix.
--

 (This man's opinions are his own.)
 From mole-end    Mark Terribile

I am very new to the field of `Reusability', its concepts, issue,
propositions and oppositions(if any).

Could someone give me some guidelines on how to approach the matter.
Perhaps an introduction or recommendation on some books, articles,
newsgroups etc.

Thanks!

Josh Lam