freedman@Encore.COM (Ed Freedman) (06/01/91)
In article 5902, Jim Showalter writes: >I agree wholeheartedly with the points made in your post with one >exception: I think it is fairly straightforward to diagram the STATIC >structure of software. By static, I mean what in Ada is called the >"with" dependency closure: the visibility that each unit has to all >others. It is even easier to diagram the export/import interface >relationships between software subsystems at the architectural level. >These diagrams, particularly the latter, are quite useful. >Unfortunately, they don't represent the dynamic behavior of the >software at all--and the dynamic behavior is typically orders of >magnitude more complex than the static structure. Which inspired me to the following musings: It's an interesting point that pictorial software design methodologies have tried to deal mainly with the syntactic issues of code organization, rather than with the broader behavioral and physical organizational issues of a program or a system. For instance, I don't know of any standard methodology for diagramming the inter-relationships of communicating processes. The nearest thing I know is the real-time extensions used in structured analysis, which is still thinking in terms of analytic functional decomposition, rather than system program design (functional decomposition doesn't directly address the real design and pictorial representation issues related to process organization, though it can be helpful in suggesting what things have to be organized and where some of the boundaries might be). I would like to see a design method that allows me to begin by specifying the several programs of the system I am designing, with their signal and data interfaces (at the "generic" operating system or even physical level), and then lets me show the decomposition of each program into code packages used (or classes, or what have you). Then I want to be able to refer to the design for each of the various packages. So what I am really describing is at least a three-layered approach to design that more accurately reflects the way I suspect people think about systems. Gross-level Organization ---> Package-level Organization ---> Package detail organization Oddly enough, an interesting way to state the gross-level *behavior* of a complex system might be flow-charts (or HZ diagrams, or other equivalent notation). HZ charts are very good at representing sequential and algorithmic behavior, ie, the semantics of the system design. Structure charts and object-oriented design methods (like OOSD) don't really address semantic specification in any canonical fashion. This might get rather messy when it comes to dealing with asynchrony. Perhaps an addition (to HZ or flow-chart notation) for describing guards would be interesting. For that matter, does anyone out there know of any pictorial representations for specifying behavior of asynchronous systems? ----- [ Related musings: I'm not horribly familiar with CAE, so I'm not sure what they do about gross level issues. It does seem to me that the focus their is on circuit design, which in a way is a level below structure charts. It seems to correspond very roughly to putting actual code into module specifications in a design. Another thing that CAE people do is simulation of dynamic physical systems (eg feedback loops) by constructing models of out of relatively simple prepackaged component models (eg op-amps). Although when I looked at such tools it seemed to me that they are very much electrically oriented, I thought they must apply to all types of dynamic systems that can be modelled in terms of simple components. But this seems more like simulation of system behavior at the analysis level, rather than actual detailed circuit design. ] Ed Freedman Encore Computer Corporation uucp: uunet!gould!maxzilla!freedman 257 Cedar Hill St. internet: freedman@encore.com Marlborough, MA 01752 The opinions expressed above are my own and (508) 460-0500 not necessarily those of Encore Computer Corporation.