SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sat, 3 Jan 2004 08:41:40 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"osfree" <osFree@yahoogroups.com > , "scoug-programming@scoug.com" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Gregory Smith writes:
"No matter how sophisticated your specifications, your
"solution set" is not much good when the "problem set" is ill
defined. And nearly every engineering problem I have
encounted is an incompletely defined "problem set". It is not
"adapting to change"--it is wanting different results from our
ill defined problem. ..."

Greg,

It's hard enough when you do things right. It's simply
impossible when you do them wrong. When your problem set
description doesn't match the problem the mismatch remains
no matter how accurate the translation into specifications.

No matter how frequently this situation occurs it shouldn't
distract us from bringing improvements to situations in which it
doesn't. I do not address the requirements gathering process
as we can use software to assist in it but we cannot use it to
automate it. We cannot even use software to automate the
translation from requirements (good or bad) to specifications.
We can, however, fully automate the process once we have
the specifications. That's the lesson of logic programming.

Now I didn't invent logic programming. I am not its Al Gore. I
had experience with various logic programming tools, e.g. TIRS
in AI, Knowledge Pro in AI, and SQL in IT. They all go from
specifications to executables entirely within software, entirely
automated. When you get within the SDP you have with
imperative languages five manual stages and with declarative
one. It doesn't take a rocket scientist (like someone else), a
process engineer (like yourself) or a dummy (like me) to do
the arithmetic.

At the heart of logic programming lies this two-stage proof
engine: the completeness proof and the exhaustive true/false
proof. A further examination of the completeness proof
shows that it automates analysis, design, and construction
while the exhaustive true/false proof does the same for
testing. The question then becomes, if you can automate
these stages, why continue to do them manually? You have
hundreds, possibly even thousands of logic programming
instances that have operated in this manner for over 30 years.

So why do we continue in our use of imperative languages? If
we insist on continuing their use, why do we not make them
amenable to this two-stage proof approach? What changes
do we have to make to them to allow their complete
automation after specification as well? We won't end up with
all the advantages of declarative languages, but we will end
up with the automation of analysis, design, construction, and
testing.

People get hung up on SL/I and the DA. Instead they should
focus on the possibilities of the two-stage proof engine.
Without it SL/I and the DA have no meaning. With it you can
pick any language and supporting tool interface to achieve
significant gains.

I haven't address the gathering process that results in the
user requirements. I haven't address the translation process
from requirements to specifications. I haven't address the
automated process that takes specifications to executables.
Logic programming has. I have simply pointed to it as a
solution that has worked reliably for over 30 years. I would
think that long enough to convince even the most hardened of
skeptics.

If you have a better solution complete with empirical proof,
then I will quickly switch from mine to yours. Otherwise I
would expect you to extend me the same courtesy.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 03 | January | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.