NassiShneidermanDiagrams ''(from VisualProgrammingBook)'' Nassi-Shneiderman (N-S) Diagrams are "structured flow charts" drawn as boxes-within-boxes. N-S diagrams restrict the programmer to using only valid StructuredProgramming constructs by representing the flow of control through procedural code with nested boxes and sequential (top-to-bottom) placement. ----- '''Sequence:''' +----------+ | First | +----------+ | Second | +----------+ | Third | +----------+ '''Condition:''' +-------------------+ |\ test condition /| | \______ ______/ | | True \ / False | +---------+---------+ | Code to | Code to | | execute | execute | | when | when | | TRUE. | FALSE. | +---------+---------+ : ''(It's hard to get the diagonal lines right in AsciiArt. ;-)'' '''Repetition:''' +-----------------------+ | While loop condition | | +--------------------+ | | Body of code to | | | execute multiple | | | times. | +--+--------------------+ '''Example code snippit:''' +--------------------------------------------+ | Open input file. | +--------------------------------------------+ | While there are more lines to read... | | +-----------------------------------------+ | | Read next line into buffer. | | +-----------------------------------------+ | |\ If record type = 'X' /| | | \_________________ _________________/ | | | True \ / False | | +--------------------+--------------------+ | | Add inventory to | Flush buffers. | | | master record. +--------------------+ | +--------------------+ Increment count of | | | Increment count of | 'Y' records. | | | 'X' records. | | +--------------------------------------------+ | Close input file. | +--------------------------------------------+ ''In block structured code, this would be...'' Open input file. While there are more lines to read... Read next line into buffer. If record type = 'X' Then Add inventory to master record. Increment count of 'X' records. else Flush buffers. Increment count of 'Y' records. end if Close input file. ----- Use of N-S diagrams on large projects is probably infeasible without automated tool support. Tools that can do round-trip "forward and reverse engineering" -- diagrams-to-code and code-to-diagrams -- would be feasible and desirable. ----- ----- Opinion: As an experiment, in the late 1980's, I made an N-S diagram of a relatively complex function. Placing the code and the diagram side-by-side, I found that I preferred the code, as more expressive and more readable than the N-S diagram. Aside from the high cost of creating and maintaining N-S diagrams without special-purpose tools, I found that the horizontal division of the page that occurs with "if" statements leaves an inadequate space to fit very many characters per line. This results in excessive line wrapping, or a severe need to abbreviate. Also, reasonable indention of source code blocks does a good job of revealing the code's structure anyway. So, I found N-S diagrams to provide practically no additional value, and to have a high cost. I suspect that N-S diagrams would be useful for teaching structured programming concepts to students learning a procedural language, like FORTRAN. ''(...but then you'd have to teach them to '''stop''' using them, once they understand the concept. ;-)'' -- JeffGrigg ----- It's been five years since I last used an NS diagram (which means they survived into the 90's, at least), and that was as an n-dimensional truth table to help ferret out problems with a requirements statement. Drawn horizontally, it took up the better part of a large whiteboard. It took no more than 15 minutes, including some redrawing, and the resulting, ''"oh yeah, we didn't consider that case."'' saved at least a person-week of development. The same result could have been reached through some other visualization. --DaveSmith I wrote an editor for these things once. You could fly into or out of the logic with details surfacing much like with modern mapping software. Subroutine calls would be expanded in place so the terrain could be quite rich. It didn't seem to help programming much though. I consider a good SystemOfNames far more valuable. -- WardCunningham ---- ''"Aside from the high cost of creating and maintaining N-S diagrams without special-purpose tools, I found that the horizontal division of the page that occurs with "if" statements leaves an inadequate space to fit very many characters per line."'' This is easily fixed. Each internal rectangle can be replaced by a reference ("see box 5") which then gets its own page. I once had a rather complex page of output to put together in code. NS diagrams immediately broke it down into easy pieces. I wouldn't use them everywhere, of course, but they can be a very useful tool. -- David Wolff ---- http://rdrop.com/~cary/html/psd.html has some links to NassiShneiderman editors. ---- From a software engineering perspective, NS diagrams are not much helpful to solve real problems. Though these diagrams might be useful to document and maintain systems written in old languages like lisp/fortran where lanuages are not as clean as the newer languages. Now languages like python may be more useful, since we can write code which nearly looks like a NS diagram and with a little more effort is also executable. ( The view projected here are from a programmers prespective). -- Suman Karumuri