Date[ August 21, 19]  Recordnr[        ]  Stored[ see library
Who[ Charles W. Krueger
Title[ Software Reuse

Published[ ACM Computing Surveys, Vol. 24, No. 2, June 1992

Keywords[ reuse, abstraction

Comment[ 

Summary[ 
Abstraction:
Abstraction and reuse are two sides of the same coin. Many references 
given for that.
Abstraction occurs in layers. In each layer we can distinguish between 
the abstraction specification, and the abstraction realization 
(contains hidden parts of the abstraction).Specification contains fixed 
part and variable part of the abstraction.

4 facets of software reuse are looked at in the paper, though all build 
on top of abstraction:
- abstraction: what the abstraction is at all
- selection: how users find abstractions, requires consice 
specifications
- speciliations: choosing the abstraction realisations and the correct 
flexible parts
- integration: interface of an abstraction, how are abstractions 
integrated in complete software system

Reuse is being looked at in the following fields:
1) High-level languages:
- reusable artifacts are the language elements, which abstract assembly 
language patterns. 
- variable parts are the statements and conditions we can fill in
- integration is done by compilers, hidden parts (assembler language) 
are never visible
- cognitive distance to a problem at hand is quite large (yet smaller 
than with pure assembler)

2) Design and Code scavenging
- code scavenging: copying small code fragments without changing
- design scavenging: copying larger code fragments containing a design 
pattern, and changing details yet keeping overall design; or making new 
code based on earlier experiences
- very informal, not always worth while
- no hidden parts of abstraction, specialization and integration require 
intimate knowledge of the code
- if large pieces of good code can be reused without looking too much 
into it, the cognitive distance is small

3) Source Code Components
Main contrast to code scavenging: components are build to reuse.
The description here is a little bit outdated. He mentions mathematical 
analysis libraries and ADA-components. Nowadays, we would add JFC, MFC, 
RoqueWafe etc. Integration has been improved by todays OO-languages, 
specialization has been clearly "reduced" to parameters and inheritance. 
Selection is getting better by good browsers, web-pages etc....

4) Software Schemas
Quite outdated, the mentioned tools have not made it.
Schemas seem to be quite similar to templates and design patterns. The 
foculs lies on higher level semantics descriptions of components, and of 
schemas how things work together (just design patterns).

5) Application generators
Whole applications are generated, e.g. parser and compiler generator. 
Only certain rules, modules, elements, diagrams are written. The rest is 
generated. The abstractions come directly from the application domain. 
Cognitive distance is very small.

6) Very High-level Languages VHLL
= executable specification languages
Developing in a VHLL is similar to developing in a HLL (writing program 
that gets compiled). Like application generators, VHLL will generate the 
applications, yet VHLL are general purpose. VHLL want higher levels of 
specification without sacrificing computational generatily.
- VHLLs are often very slow, yet execution efficiency is sacrificed for 
implementation and modification effencency
- VHLLs are often based on some higher level mathematical model
Examples for VHLLs: 
- SETL: based on set theory, good for easy use of abstract data types
- PAISLey: functional programming, .....
- MODEL: declarative constraint language
Main concern: execution speed.

7) Transformational systems

8) Architectural abstractions
- come directly from application domain