Path: utzoo!utgpu!watmath!iuvax!cica!tut.cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide
From: weide@elephant.cis.ohio-state.edu (Bruce Weide)
Newsgroups: comp.sw.components
Subject: Seeing component source code?
Message-ID: <67790@tut.cis.ohio-state.edu>
Date: 20 Oct 89 21:35:00 GMT
Sender: news@tut.cis.ohio-state.edu
Reply-To: <weide@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 80


Occasionally something goes by on this newsgroup that cries out for a
response.  Case in point: Recently Ralph Johnson made an argument that
in order to reuse a software component, one must be able to see its
source code.  The essence of his case seemed to be: (1) Writing formal
behavioral specifications for components is hard.  (2) A complete
formal specification IS a program.  (3) Smalltalk programs he has
written look a lot like specifications he has seen.  Therefore, why
not just stick with source code and forget formal specifications?  Or,
perhaps, why not write formal specifications but still provide source
code just in case?  (I couldn't tell for sure what the conclusion was.
These seemed likely candidates.)


(1) Writing formal behavioral specifications for components is hard.

Here there is no disagreement.  Fortunately, one of the nice things
about reusable components is that relatively few people need to be
able to WRITE specifications.  Lots of people need to be able to read
them.  This suggests that, while writing specifications is presently
difficult, we really ought to be working on specification methods and
languages that also emphasize ease of understanding.  Of course it
will also help to improve the ease with which specifications are
written.  Both areas call for further work.  But one should not
conclude from the fact that specs are hard to write NOW that it must
always be so.  Nor should one conclude that they are necessarily hard
to understand.  In fact I think we already have the concepts necessary
to write comprehensible formal specifications of non-trivial
components, and plenty of anecdotal evidence that both CS students and
practicing software engineers in industry can understand them; I have
previously commented on such techniques in this forum.  (By the way, I
don't think Ralph was really claiming that formal behavioral
specifications are INHERENTLY IMPOSSIBLE to write or INHERENTLY
DIFFICULT to read and understand, which seems to be what is needed to
support his argument.  If that is the claim it's going to be difficult
to defend.)


(2) A complete formal specification IS a program.

On this point there may be some grounds for disagreement.  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.  Specifications say WHAT the
component does, not HOW it does it.  Now there's a hell of a gap
between such specifications and the source code for an implementation
in an algorithmic language.  To claim that this is "only" a compiler
technology issue -- that a smart compiler can invent an acceptable (in
performance) implementation from such abstract specifications -- is a
remarkable leap of faith that flies in the face of reality.


(3) Smalltalk programs Ralph has written look a lot like
specifications he has seen.

Perhaps Ralph's real claim in (2) is that one might simply consider
the specifications to BE the source code.  I can only suggest that
such "specifications" are inappropriately named.  If they reveal any
representational or algorithmic details of HOW the component works
they are not specifications by the above definition.  I'm not fluent
in Smalltalk, and maybe Ralph's programs look a lot different from
Smalltalk code I've seen.  But those samples don't look much like
formal specifications to me.


SUMMARY - Can we agree on the general definition, the nature/purpose
of formal "specifications": to say WHAT the component does?  Can we
agree on the nature of "source code": to say HOW it does it?  Can we
agree that these are not the same thing?  If so, I think we ought to
be able to agree on something about the nature of reusable components
in a (future?) software components industry: There is no reason in
principle that a client programmer should need to examine component
source code in order to understand what the component does.

If we can't agree on the above definitions, we'd better move the
discussion back to that issue.

	-Bruce