Analysis maintains a model of the system good enough to determine the constraints applying in each problematic area. Design uses the current model to produce plans and blueprints(specifications) plus feedback to analysis [Dasgupta91p170]. The plans and blueprints guide the changes to the system. The picture above is just a way of coping with complexity. The above picture includes the possibility of incremental delivery and disciplined prototyping. It does not require that the pieces occur at different times, operate in different places, or are done by different people. These "who does what when and where" are implementation details of a particular project.
Engineers use diagrams to do design. Programmers use languages. We need better diagrams: Several people have suggested putting diagrams in the source code of a program [Brooks82] [Max89]. Standard flowcharts lead to significantly fuzzier designs than PDL however [RamseyAtwoodVanDoren83]. Dissatisfaction has lead to many notations Summaries in [MartinMcClure85] [Webster88] [Tripp88] [Botting86a] [Botting87b] [ [Botting89 ] [Johnson89], Bibliography in [Tripp89], [Wassermannetal90], . . .. Many have invented structured flowcharts. For instance, Rob Witty took flowcharts, removed the boxes and defined a structured layout giving Dimensional Flow Charts or D-Charts. D-Charts are simple, natural, language independent, automated, and effective [Witty77b]. Four Japanese computer companies used other tree structured, graphic program design systems. They found that diagrams work better than a text based PDL [Aoyamaetal.89]. Ambler and Burnett, in a special issue of the IEEE Computer magazine(October 89), reviewed half a dozen or so visual programming environments. They suggest that these are evolving toward a complete graphical implementation system. Ben Shneiderman's "Direct Manipulation" paradigm, Graphic User Interfaces(GUIs) and Object Oriented Programming(OOP) together make this feasible [ [Shneiderman 83] , Scientific American 84, Kramer Magge & Ng 89].
Engineers need to calculate properties of designs and used engineering drawing to do this. Mathematics already uses two dimensions [MacLennan79], so a diagram can be treated as an element in a formal system. Indeed Warnier borrows from set theory but his diagrams are ambiguous [see LCP, LCS, and DSSD in chapter 9]. Jackson uses diagrams based on EBNF which are usually misunderstood and/or disliked (see chapter 6). Normal DFDs and ERDs have three problems:
An architectural drawing is not a building, a circuit diagram is not a circuit, and a blue print is not a mechanism. In most engineering a "design" is a drawing and the product is not a drawing. As we saw earlier, programmers use the same media, notations, and ideas to express the design of software and the software itself. This lures them from designing to debugging.
. . . . . . . . . ( end of section 5) <<Contents | End>>