SCOUG-Programming Mailing List Archives

Date:	Fri, 12 Sep 2003 17:47:38 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Getting there from here

Content Type: text/plain

First, I have to publicly apologize to Ben Archer for misnaming
him in a previous response. It seems like I got through the
"Ar" okay and then blew the rest big time. No excuse. No
repeats.

I received the October 2003 issue of C/C++ Users Journal
today. It came with a pullout inset on UML, complete with
advertising. it's a four-page foldout, which means eight
pages total. I found Allan Holub's one page write-up
interesting, enough initially to copy it here for everyone to
read. Instead I will let you review his webpages at
http://www.holub.com/goodies/uml/.

Now we stand on the shoulders of giants. We have Jim
Backus of IBM with Fortran and BNF (Backus-Naur Form). We
have John McCarthy with LISP (1960). Then we have Ken
Iverson with APL(1962). We had others of course. Looking
back now some forty years later we may find it difficult to
really appreciate their contributions.

For example, Iverson intended APL as a replacement for
flowcharting, to replace it with something concise in space
occupied and succinct in expression. Now some forty years
later we have come to a design form so complex as to make a
flowcharter blush.

Now APL didn't replace flowcharting. It also didn't remain as
Iverson intended as a pure specification language. An
enterprising team at Stanford implemented it as a
programming language on an IBM 1620 ( a not so tiny biny),
where it went to an IBM 1130 (somewhat tinier). From there
to full flower on an IBM 360/40, providing one of the most
powerful and popular interactive programming environments.

Flowcharting itself fell into disuse with the advent of
Constantine's "Structured (Analysis/)Design" using dataflows
(analysis) and structure charts (design) with a heuristic to
transform the former (analysis) into the latter (design).

Actually flowcharting required that you draw specific
graphical symbols inside of which you wrote the logic.
Technically you could do this to a level of detail down to an
individual statement. In effect it meant that you actually
wrote the program twice. Of course, you used one form for
documentation and the other as the actual program. Of
course, you perform maintenance on both simultaneously.

One of the earliest best software sellers was the flowcharting
program. This allowed you to write the program once and
from that source provide its flowcharting form as
documentation. Of course, in so doing you have conveniently
skipped analysis and design, allowing the programmer to
engage in them as part of the process of writing the program.

Now analysis and design appear as a bottleneck in the
software development process, a two-stage chokehold as it
were standing between specification (where you say what
you want) and construction (where you say how you're going
to do it). "Real" programmers did "real time" analysis and
design as part of construction. They had no love for analysts
or designers, whom for the most part they regarded as
incompetent.

Analysis and design encompass both drawing (and redrawing)
and writing (associated with drawing). Manually drawing and
the frequent redrawing gave rise to CASE (Computer Aided
Software Engineering). It made the drawing and redrawing
easier. Somehow its vendors gave the impression that it also
gave the user some automated means of doing analysis and
design, that it was a skill provided by the tool and not one
necessary to know before its use.

In analysis you verify the "completeness" of the specifications.
In design you organized the "completed" pieces to specify
their order of implementation (construction). Whether you do
the three stages of analysis, design, and construction
separately or not (mix them during construction) they get
done. They get done manually. They get done manually
because you have no other choice in using "imperative" (first,
second, and third generation) programming languages.

If you don't want to do them manually, then you don't use an
imperative programming language period. UML simply
increases the upfront manual effort in analysis and design. So
object-oriented (at least its current instantiation--take that
OO) jacked up (deliberately) the cost (in time and effort) of
software development and maintenance. So when Alan Holub
states "Every hour I spend working with a design in UML,
typically saves me three hours of coding.", it doesn't take
much arithmetic to see that on a 1:3 ratio you can bring actual
coding time down to zero, providing you know how much
coding occurs without using UML.

So leave imperative, use declarative. Easy for me to say. Of
course, like you I get confused when the declarative people
use the OO paradigm and with it UML. So we free ourselves of
manual analysis and design. In the next step we re-introduce
it. Go figure.

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

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 [ 12 | September | 2003 ]

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.