dmcintee@netxcom.UUCP (Dave McIntee) (03/29/89)
Does anyone know what became of Higher Order Software, the James Martin- backed company? They had a product called USE.IT which ran under VAX/VMS. Both the company and the product seem to have vanished from the scene. They started in Cambridge, Mass. Their last known address was 35 Medford Street, Somerville, Mass. Any information would be appreciated. Thanks. -- Dave McIntee NetExpress Communications, Inc. Phone: (703)749-2380 1953 Gallows Road, Suite 300 uunet!netxcom!dmcintee Vienna, VA 22180
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (03/30/89)
<"Would you like me to summon Data so he could offer a few dozen synonyms?"> In article <1185@netxcom.UUCP>, dmcintee@netxcom.UUCP (Dave McIntee) writes: > Does anyone know what became of Higher Order Software, the James Martin- > backed company? They had a product called USE.IT which ran under VAX/VMS. > Both the company and the product seem to have vanished from the scene. >Dave McIntee, NetExpress Communications, Inc., uunet!netxcom!dmcintee Don't you love coincidence? I just got Martin's book out of the library again, determined to figure out this time what his fuss was about. Oddly enough, I think I succeeded; odder still, I don't think it's at all what Martin thinks (or thought) it is. Higher Order Software is primarily the work of Margaret Hamilton and Saydean Zeldin, who developed it while they were working on Apollo mission software at the Charles Stark Draper Lab in Cambridge, MA. The seminal papers are "Higher order software techniques applied to a space shuttle prototype program" in Lecture Notes in Computer Science, vol. 19, G. Goos and J Hartmanis, eds., Springer Verlag, 1974, and "Higher Order Software -- A Methodology for Defining Software", IEEE Transactions on Software Engineering, vol. SE.2, #1 (March 1976), pp. 25,32. The more popular description is James Martin's SYSTEM DESIGN FROM PROVABLY CORRECT CONSTRUCTS, Prentice-Hall, 1985, ISBN 0-13- 881483-X. HOS breaks down software into binary trees; well, that's not too amazing, is it? Every node has inputs and outputs. A leaf node generates output from input in some primitive way. Any other node passes its input to, and gets its output from, one or both of its two child nodes. There are three fundamental kinds of non-primitive nodes; one conditional, and two sequence (depending on which nodes get and generate which inputs and outputs). HOS lets you define higher order nodes from the fundamental ones, and the software understands nodes with one child, or more than two children. Looping is done via a sort of recursion (though if I understand things correctly, an HOS user could define WHILE and UNTIL nodes). No, you're not expected to draw these trees by hand; part of the USE.IT software is a graphical tree editor. Another part checks the tree (but not interactively, I think); a third generates code (C, Cobol, Fortran, or whatever the backend's been build for). The system is kind of quirky. Some of the stuff near the leafs is really low level (there's sometimes a need to "clone" a value, and you have to write out the tree for an algebraic expression). A fairly trivial system gets pretty deep and pretty wide pretty fast. The primitive data types are defined axiomatically, in a way that's hidden from the user. Martin never shows an HOS tree that USE.IT complains about, so I'm not quite sure exactly what can be proved correct or incorrect about a tree axiomatically, with two exceptions: HOS can tell if input data is ignored, or output data magically appears from nowhere. What's *really* going on here? I think the big win is that it's a graphic tool to design software, that checks that all the input data gets used, and all the output data comes from somewhere. That doesn't sound like a big deal, but it's far more rigorous than most such design tools. It can be used at both very high and very low levels of abstraction; and code can be generated automatically. HOS is one of the few design methodologies that emphasizes data very early on, and describes data types and flow in ways that can be checked by the computer. Most other methodologies and tools emphasize control flow and actions. Data flow diagrams strongly concentrate on data, but not data types. (We informally used data flow diagrams in my last project, where each bubble really was a UNIX(R) system process; it was very useful.) Structured design diagrams, as described by Yourdon and Constantine in STRUCTURED DESIGN, have a mechanism for showing data and control flow; but it can get messy in a non-trivial graph, and there's no nice way of showing which of a node's data (from that node's "point of view") is being passed to a subnode. Action diagrams (James Martin and Carma McClure, ACTION DIAGRAMS, Prentice-Hall; or most of their other books, including DIAGRAMMING TECHNIQUES FOR ANALYSTS AND PROGRAMMERS and STRUCTURED TECHNIQUES: THE BASIS FOR CASE) can be enhanced to show data flow, but the way Martin and McClure do it leads to diagrams that get very wide. If the data was added to action diagrams differently (in-line, with inputs at the top and outputs at the bottom), an action diagram editor could do most of the checking HOS does, on a text-only display, with a much higher level and natural presentation. (Action diagrams can be decomposed all the way to code, or something code can be generated from.) Martin always seems to emphasize top-down, stepwise refined, tree structures. Reused subroutines are drawn "somewhere else". Yourdon and Constantine suggest that a good program looks like a mosque: it starts at a point on the top, gets fatter, starts to get narrow, and then rests on a flat base. Object-oriented software is *much* more like a mosque than like a tree (if we've written it right!) Paul S. R. Chisholm, AT&T Bell Laboratories, att!pegasus!psrc psrc@pegasus.att.com, AT&T Mail !psrchisholm UNIX(R) is a registered trademark of AT&T, and don't you forget it! I'm not speaking for the company, I'm just speaking my mind.