Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.sw.components
Subject: Re: Seeing component source code?
Message-ID: <130200016@p.cs.uiuc.edu>
Date: 25 Oct 89 00:11:21 GMT
References: <67790@tut.cis.ohio-state.edu>
Lines: 73
Nf-ID: #R:tut.cis.ohio-state.edu:67790:p.cs.uiuc.edu:130200016:000:3592
Nf-From: p.cs.uiuc.edu!johnson    Oct 22 16:49:00 1989


 weide@elephant.cis.ohio-state.edu said
>Occasionally something goes by on this newsgroup that cries out for a
>response.
Naturally, I was trying to get a response!  I'm glad I succeeded.

There are lots of things I could say in response, such as I disagree
with the idea that it is irrelevant how hard it is to make reuseable
code because the cost will be amortized later.  However, the main
point that I was trying to make was that in practice there is no
real difference between a complete specification of what behavior
a component has and a specification of how it is implemented.
In other words, I think that the generally well accepted idea that
"Formal specifications for a component will in general be abstract and
implementation-neutral, i.e., they will hide both representation data
structures and algorithms used in the component's implementation,
explaining behavior in abstract terms, and admitting of multiple
plug-compatible implementations" is wrong.  It is only correct for
specifying tricky algorithms, i.e. fast, complex algorithms for
problems that also have slow, simple algorithms.  It is certainly
false for most real code, which consists of mostly user interface.
Moreover, to the extent that it is true, it is also true of programs
written in very-high-level languages.

There is certainly a wide semantic gulf between formal specifications
and Pascal programs.  This is irrelevant to the claim that there is a
wide semantic gulf between formal specification languages and ALL
programming languages.  For example, there are many formal specification
languages that are executable.  Thus, these specification languages
are also programming languages.  More to the point I am trying to
make, real high-level languages (i.e. not Pascal or C) can look
very much like specification languages.  For example, compare these
specifications of stacks.

class stack
	sequence elements;
push(elem) = {elements := elements, elem}
pop() = {elements := elements(1:(elements.size-1)}
top() = {return elements.last}
empty() = {return elements.size = 0}

or

pop(push(elem,S)) = S
top(push(elem,S)) = elem
empty(push(elem,S)) = false
empty(newstack()) = true

The second (the "abstract" specification) is shorter, but not much
easier to read.  Most importantly, it is not easier to understand.
Thus, I claim it is no better as a specification than the first.

Stacks are about the easiest component for which one can write a
formal specification.  However, a better example to show the strengths
of formal specifications would be sorting, since the specification is
that the output sequence is a permutation of the input sequence and
that the output sequence is sorted, while most fast sorting algorithms
take a lot of more code to express.  This is an example of a problem
for which there exists both fast complex algorithms and slow simple
algorithms.  The specification I described corresponds to the sorting
algorithm that takes each permutation and checks whether it is sorted.
This simple specification could be represented just as well by a program.

To raise a last point, we probably disagree on what a component is.
I don't believe in the mythology that we will be able to reuse
components without changing them.  It is very hard to predict how
people will want to change components, so it is very hard to know
what information to hide.  Components include abstract classes and
frameworks, which are really just partial programs.  This makes it
even harder to make provide specifications that are different from
the code, significantly simpler, and useful.

Ralph Johnson