Xref: utzoo comp.object:313 comp.software-eng:2271
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ginosko!samsung!gem.mps.ohio-state.edu!apple!rutgers!att!dptg!pegasus!psrc
From: psrc@pegasus.ATT.COM (Paul S. R. Chisholm)
Newsgroups: comp.object,comp.software-eng
Subject: Re: programming design methodologies for object-oriented programming
Summary: object-oriented Jackson System Development, maybe?
Message-ID: <4212@pegasus.ATT.COM>
Date: 29 Oct 89 23:24:58 GMT
References: <910@gorath.cs.utexas.edu> <135300011@p.cs.uiuc.edu>
Organization: AT&T Bell Laboratories
Lines: 59

I've cross-posted to comp.software-eng, where a discussion of
programming methods and methodology is more likely to flourish.

I've been reading a book called SYSTEM DEVELOPMENT (Prentice-Hall
International, 1983, ISBN 0-13-880328-5) by Michael Jackson.  No, not
the pop singer; the author of PRICIPLES OF PROGRAM DESIGN and the
"Jackson method" (what Jackson calls JSP).  His latest development,
JSD, has a *lot* of bits that sound like object-oriented design.  His
first step is to model this system, and to identify "entities" (what
lots of us would call objects) and "actions".  His indictment of
top-down methods (pp. 370-3) might be a revelation to someone who's
just getting started with object-oriented methods.  I'll quote a
paragraph later in this article.

That's *not* to say that JSD is object-oriented.  "Data structures do
not play a central role in JSD), to quote Jackson (page 365).  Clearly,
they do in object-oriented design and programming.  Further, JSD's next
step is to chronologically order the actions in a tree.  As with JSD,
Jackson insists on giving every node in the tree (that is, every
subtree) a distint, meaningful name.  Since the only way to have a loop
or a conditional is to have a subtree, this (I feel) leads to a lot of
nodes to name.  As with other methods (such as Higher-Order Programming
that James Martin touts so highly), the developer seems to end up with
a lot of low-level constructs in the high-level diagrams, in order to
satisfy the simplistic constraints imposed by the method.

But there *is* some value to be gained from this book, and with that
caveat, I recommend it.  Anyone else have opinons on this, or some
other method, that could help us develop an object-oriented method of
developing software?

Paul S. R. Chisholm, AT&T Bell Laboratories
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.

P.S.:  Here's the quote I promised on top-down methods:

> A development method must allow the developer to solve problems to
> which he does not already know the solution, to develop systems
> which he cannot yet see in his mind's eye.  Top-down is the worst
> possible method from this point of view, because it compels the
> developer to make the largest and most far-reaching decisions at the
> beginning, when, one must assume, he knows least about the problem.
> Each step in a top-down development is taken in the context
> determined by the previous higher-level steps; if the first step in
> decomposing A results in three smaller objects . . . then the
> context of the following steps is fixed to that extent; they are
> directed to the decomposition of A1, A2, and A3.  If the first step
> was ill-chosen, nothing can be done at any later step to retrieve
> the error; the developer must press on with a design he now knows to
> be bad, or he must return to the very first step and begin the
> development over again.  The work done at later steps is likely to
> be useless if the top-level decomposition is changed; something will
> have been gained in understanding of the problem, and something of
> the lower levels may survive by sheer good fortune.  But nothing
> more.

One of the things object-oriented design and programming set out to do
is avoid reliance on luck.  --PSRC