psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (10/30/89)
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
bsanden@gmuvax2.gmu.edu (Bo Sanden) (11/17/89)
Paul S.R. Chisholm (psrc@pegasus.ATT.COM) started this discussion of Jackson System Development (JSD) and OOD. Matt Atterbury (matt@bacchus.esa.oz) pointed out that JSD entities are time-ordered, while actions on objects should have no time constraints. (Bertrand Meyer sees the operations on a data structure as a "shopping list of available actions without any prescribed order"). Ed Berard (eberard@ajpo.sei.cmu.edu) elaborated on this difference and noted that concurrency is the norm in JSD. I have applied a JSD-like approach to real-time problems with concurrent tasks for a number of years. I refer to it by the more generic name "entity-life modeling". (Refs 1 and 2.) I also use an object-based approach. Some people see a conflict between the time-independent objects ala Booch and Meyer and the time-dependent JSD entities, and feel that we must go for one or the other. I think this is unfortunate. Depending on the problem at hand you need either one, or both. In an interactive application you can get away with mostly time indpendent objects of the shopping list variety, if a human operator defines the overall sequencing and timing by means of commands. In a realtime application without operator, the timing must be built into the software itself usually by means of tasking. As Berard points out, the principles of JSD lead exactly to this, i.e., the time-dependent entities of JSD map naturally onto tasks. On the other hand, even in a real-time application there will be objects without important "time dimensions", which can be operated on in arbitrary order. Applying the JSD apparatus to such objects isn't productive; they don't have any meaningful life histories. I find it very useful to see concurrent programs as networks of tasks operating on objects. In the spirit of JSD, the tasks are based on the behaviors or life histories of some entities. I don't apply JSD to other entities in the problem environment, which do not exhibit a strong time dependency. Bo Sanden, ISSE George Mason University Fairfax, VA 22030-4444 (703) 764-6291 Refs: 1. Bo Sanden, An entity-life modeling approach to the design of concurrent software, CACM 32:3 (March 1989) 330-343 2. -"- Entity-life modeling and structured analysis - comparison of approaches to real-time software design, CACM 32:12 (Dec. 1989)