Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mailrus!cornell!uw-beaver!uw-june!jon
From: jon@cs.washington.edu (Jon Jacky)
Newsgroups: comp.software-eng
Subject: Re: Reuse and Abstraction (was: reu
Summary: Responses to Charlie Martin, Bruce Weide, Brad Cox, others...
Message-ID: <12085@june.cs.washington.edu>
Date: 1 Jun 90 00:21:18 GMT
References: <4979@stpstn.UUCP> <102100009@p.cs.uiuc.edu> <19820@duke.cs.duke.edu>
Organization: U of Washington, Computer Science, Seattle
Lines: 62

I can't resist responding to comments by Charlie Martin, Bruce Weide,
Brad Cox and maybe others too (I can no longer untangle who said what):

> it's pretty hard to show a library of reusable components that are generally
> agreed to be reusable and non-trivial ... how can you demonstrate 
> scientifically that they are `reusable'?

What about libraries of numerical routines for finding roots, solving linear
systems, doing FFT's and all that traditional scientific and engineering work?
Packages like IMSL, LINPACK, EISPACK, NAG and others have been around for
ages and are very heavily used.   You know, the kind of thing you find in
ACM COLLECTED ALGORITHMS and the NUMERICAL RECIPES books.  

It may help that the kinds of objects they
deal with, like matrices, are well understood outside computer science, in
fact they predate computers.

> Political problem: (how can a researcher get credit, publications, tenure,
> by building) a really good reusable non-trivial library?

By providing new, useful solutions to application problems that others are 
trying to solve.  In addition to the numerical stuff mentioned above, there has
been some activity in recent decades in libraries of routines for doing 
graphics and image processing.  There are probably application-specific 
libraries I don't know about.   In these application areas, you get the 
academic (or other) credit for solving the application problem, not for 
crafting the library as such.   Application people think of things at a lot
coarser level of granularity than those with a mostly computer science
bent: they don't think, "What I really need is a good implementation of sets,"
they think, "I need an adaptive histogram equalization image contrast
enhancer".   As a result the application libraries do not get much attention
as computer science artifacts. I believe  William Howden did a systematic
study of errors in the IMSL library quite a while ago and there may have been
some similar European work on the NAG library, but that's about it.

> A specification is "formal" if it ... can be used to verify the correctness
> of ... an implementation ...

Emphasis on verification of implementations excludes a lot of what formal
specifications are about.  Often you need to reason about the properties of
some proposed system, and this is a prerequisite to deciding if you want to
implement the specified behavior at all.  Formal specifications may make it
possible to reason about system behavior by applying rules of inference (as 
opposed to building an implementation and experimenting with it).  For example,
you might want to show that some proposed collection of operations cannot
violate particular assertions about safety.  This is an entirely separate 
issue from verification and is independent of any particular implementation.

> (seeking Reference to paper by London et al on specification of sets)

@inproceedings{softeng:london89,
        author="Ralph L. London and Kathleen R. Milsted",
        title="Specifying Reusable Components Using Z: Realistic Sets
		and Dictionaries",
        booktitle="Proceedings of the Fifth International Workshop on
                Software Specification and Design",
        year="1989",
        publisher="IEEE Computer Society Press",
        address="Washington, DC",
	pages="120--127"}

- Jon Jacky, jon@gaffer.rad.washington.edu