Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!samsung!zaphod.mps.ohio-state.edu!usc!apple!voder!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Message-ID: <34523@athertn.Atherton.COM>
Date: 25 Feb 91 23:02:57 GMT
References: <88744@tut.cis.ohio-state.edu> <88431@tut.cis.ohio-state.edu> <6108@stpstn.UUCP> <87829@tut.cis.ohio-state.edu> <6248@stpstn.UUCP> <1991Feb11.103100.112@skyler.mavd.honeywell.com> <34464@athertn.Atherton.COM>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 120

In article <88744@tut.cis.ohio-state.edu>,
weide@elephant.cis.ohio-state.edu (Bruce Weide) writes:
>
>>The problem is that even if an independent laboratory offers its seal of
>>approval, you still have to certify it yourself anyway.  There are two
>>reasons for this.  First, the possibility that your intended use would be
>>regarded as extreme or abberant by the original designers and laboratory
>>testers, in which case you will have to test just to verify that this
>>special case is correctly handled by the purchased object code.  Second,
>>there is always the possibility that you the purchaser misunderstood what
>>the vendor offered, and that the product you purchased won't suit your
>>needs. Since externally it may seem what you wanted, you may not notice
>>this until you use it... 

> We must be talking about slightly different things.  You're talking
> about some particular programming language or paradigm that you use in
> practice (apparently), while I'm talking about how software reuse
> OUGHT to be done.

Perhaps we are talking about slightly different things.  I am not however
talking about a particular programming language or paradigm.  I am however
concerned about the problems that people face in communicating complex
information--not simply how it OUGHT to be done, but how it ACTUALLY 
IS OR IS NOT POSSIBLE to do it. In particular, in the following
comment, it is suggested that formal specification of behavior is sufficient
to solve the problems of misunderstanding without testing that I
described above. I claim it will not as I will attempt to explain. First
the comment:

> For example, your remarks further highlight why reusable software
> components need to have formal specifications of their behavior as
> ABSTRACT components.  The vendor's specification says what the
> component is supposed to/guaranteed to do; precisely under what
> conditions it works and precisely what it does under those conditions.
> What ordering is used by a sort routine, for example, certainly
> belongs in the specification (or should be a parameter to it).  It's
> not clear why you inherently need source code for the sorting
> algorithm to determine this.

I believe that this does not solve the problem I alluded to, although
it may manifest itself in different ways.  First, we must assume that
the formal specifications of behavior correctly capture the what the
actual code does, and not merely what it was intended by its developers
to do.  This is in fact a dangerous assumption, unless it is automatically
generated from the source code--in which case it is merely a translation
and is logically equivalent to having the source code. But people make
mistakes in creating source code, and so while the formal spec may
exactly describe what the code does, this may not in fact be what was
intended by its creator.  To the extent that the formal spec is comprehensive
and complex, it is quite possible that the error will not be discovered
any more than it was discovered in the original code.   Moreover, to
ensure  a correct map between the users requirement and the reusable code,
both will have to not only be in a logical specifications forms
but they both will have to be testable specs, which can be tested to
see if they are equivalent/congruent.  This just brings us
back to the need to test reused objects anyway (now you can presumably
test the spec instead of the actual module, but this does not seem to
me to be inherently different in any important way).  This also still
overlooks the whole possibility that the user's spec is consistent
but flawed from the standpoint of ultimate use--due to inadequate
understanding of the writer of the user's formal specification.

It also ignores the fact that if specifications are lengthy and must
be read to determine if they are appropriate, then only a small number
will be read, and consequently reused. Perhaps it ought not be this 
way, but observation of human behavior suggests that people do act this
way.  Most people consult a small amount of the relavant books in a
library, software in a software library, etc. in order to solve their
problems.

I am afraid I am belaboring this point, but it is an important one. 
In the end, business decisions can only be effectively grounded on
how the people who implement them actually act, and not merely how they
OUGHT to act. Humans are wonderous and yet imperfect creatures.  Theories
that conveniently ignore their failures overlook critical features that
will affect actual real life experience. People are great at communicating
much succinctly, but unfortunately think often think they have communicated
more accurately than they really have.  This leads to all sorts of
design errors.  To the extent that a particular formal specification
language helps people understand certain aspects that are often miscommunicated
then I believe that it helps address some of the problems that I am
discussing.  But that means that a lot of its value is in the ease with
which people grasp it, rather than its mathematical underpinnings, and 
I think that this is where a number of formal specification languages
have fallen down in the past. 

> Now you're getting into a serious problem.  Inheritance (of code, at
> least, which is what you get in most OO languages) causes major
> technical problems in terms of certifying correctness, either by
> formal verification or by testing.  Code inheritance is inherently a
> "white box" phenomenon... you'd better have source code for the
> inherited component if you expect to use code inheritance for much
> more than name overloading (and you don't really need inheritance for
> this anyway).

I believe that this analysis is correct.  Even in environments where
formal correctness and provability are not required, this sort of
testing seems to dominate the reuse considerations.

> Having -- indeed needing -- source code of reused components for
> subsequent re-testing is no big deal, then, if you assume a paradigm
> in which you need the source code of reused components in any case.
> My comments were directed to programming paradigms in which component
> reuse occurs not as a result of inheritance, but as a result of reuse
> of encapsulated components without violation of abstraction.

I see that you distinguish inheritance from encapsulation of abstractions,
and while I admit they are different, I am not sure that I can detect
any ways in which the latter is likely to be more free from the problems
of human communication that I raise than the former is. Rather, it seems
that both are subject to fundamental human limitations of our memory
and communication systems, which is one reason focus on applications which
can aid these human tasks seems an appropriate one for people interested
in software engineering practice.

Scott McGregor
mcgregor@atherton.com
Atherton Technology

		Better Technology, through Living...


Brought to you by Super Global Mega Corp .com