5 A Model for Software Engineering

5.1 The Engineering System

Having analyzed the software process into a set of parts we can partition the set, without loss of generality, into three groups: "analytical", "design", and "implementation". A process that models the current situation or system, without disturbing it, is "analytical." Processes that directly effect the system are "implementation" process. Processes that do both are be broken up and the parts reclassified. The remaining processes(those that neither effect nor examine the situation) are "design" processes. By grouping software production into three classes of process we get a high level abstraction of what is going on.

==============================

______________________________

==============================

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.

5.2 Software Design

In the systems model of software production (section 4.3) no clear boundary can be drawn between system design and program design. If there is a distinction it is that programs are sequential and systems are concurrent. I have already argued that better software development must permit non-sequential programs. Programs need to be seen as systems.

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:

---

1. (1) They are informal[¥DFD].
2. (2) There are several notations and the ANSI/ECMA standards are out of date.
3. (3) The layout is meaningless but takes time to decide [Protskoetal91].

---

I will propose solutions to these problems in chapter 4 and 7. In chapter 5 I will show how symbolic logic and discrete mathematics contain ideas that make DFDs and ERD mathematical compare [France92].

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 | Index>>