We return to the word-processing system example. The information necessary to construct the HIPO diagrams was provided in Sec.2.2.3. The H diagram was shown in Fig.2.3. None that we have called the top level 0.0 and that the functions on the second level are numbered successively from 1.0-8.0. Because of space and time，we have expanded only the Edit Text function to third level ;however, the dotted lines in the figure indicate that the other second-level functions must also be expanded, and a fourth level of text may be required.
In constructing an H diagram ,several practical questions arise; for example how many functions should be represented at each level？This is a matter of judgment;however if there are fewer than three functions at each level below the top, the hierarchy descends very slowly. (Sometimes a breakdown into two functions makes sense at the second or last level.) If a level contains morn than 10 functions, it becomes complex and unwieldy. Thus, 3-10 functions per level is a good rule of thumb.
Another important question is, to what level down does one continue the composition? The answer is to as low a level as one wishes, but not below the code module level (say, 50 lines of higher-level source code ). Since some of the functions will be more complex than other, not all branches of the diagram need to terminate at the some level.
In essence, the H diagram serves as a table of contents for the design. Note that the structure of Fig.2.3 almost implies a top-down approach and the control structure is essentially the program which relates the level-1 task to the lecel-2 functions. But what if we decide to do a bottom-up development for good and appropriate reasons: how should we draw the H diagram? There is no discussion of this question in any of the sources. Thus, this author recommends that the H diagram be drawn in an inverted fashion for bottom-up development. We begin with the lowest level at the bottom and insert branches reaching up (see Fig.2.2).
The IPO diagram is first drawn at an overview level , generally level 1.Most of the information for the IPO diagram at this level was already discussed in SEC.2.2.3 and appears in Fig.2.6. Note that the process part of the IPO is mostly verbs and input and output sections, nouns. In fact, in the previously cited IBM memo (1975), it is suggested that the verbs be chosen from the list given in Table 2.7. Solid arrows are used in the diagram to indicate flow of control, and clear arrows represent data movement.
In addition to the overview IPO, there are detailed IPO diagrams for each block on the H diagram. An example of one such detailed IPO is shown in Fig.2.7. notice that pieces of pseudo-code are beginning to creep into the process block at this stage. Also, the nouns which are used should now begin to correspond to program variables.
HIOP diagram have been successfully used on many project; however , on a large project the amount of detail on documents and graphs becomes difficult to manage. As an example, consider a 250,000-object instruction program with 1000 modules. This represents potentially 1000 detailed IPO diagram plus the overall IPO and the H diagram. Neglecting the H diagram and the overall IPO, and assuming that we are using 1-ft square sheets, we need 1000 ft*ft of wall space to display all these diagrams. These would more than fill all the wall space of a room with 8-foot ceilings and a perimeter of 120 ft(a room 30 ft *30 ft). in fact, the author was shown just such a room of diagrams at RCA some time age which represented all the block diagram for the hardware and software of a large military system. The wall space had been augmented by many swinging panels like the ones used to display prints shops. An attempt was made to computerize the process but the effort was abandoned because of schedule deadlines and the size of the task. The room of documentation was maintained by a full-time engineer and two part-time student draftsmen.
To avoid such problem of size and upkeep complexity, most project draw HIPO diagrams only down to a certain level. In most cases this is still too high a level to begin coding, and either flowcharts or pseudo-code is then used as an intermediate step before code writing.
2.3.5 the Warnier-Orr-Diagram
A technique which has become popular in recent years was begun by Warnier, continued by Orr, and popularized in journal and magazine articles. The technique utilizes nested sets of braces, some pseudo-code,
And logic symbols to indicate the system structure. The main feature of the technique can be appreciated by considering an example.
A high-level flowchart for our illustrative program is shown in Fig.2.8. A pseudo-code representation of this program is this given in Fig.2.9. Note that a set of arrows has been added to the pseudo-code to indicate the nesting and hierarchy of the program. ( the author feels this is useful addition to pseudo-code representation. A Warnier-Orr diagram for the example is given in Fig.2.10. Note that the braces play the as the arrows in Fig.2.9, and that the EXCLUSIVE OR symbol, replaces the THEN ELSE structure of the pseudo-code. The numbers in parentheses represent the number of times each structure is executed.
In general, pseudo-code is a little more compact than a flowchart, and a Warnier-Orr Diagram is most compact of the three. Thus, the Warnier-Orr technique may save 25 percent on documentation , which is helpful but not that significant. A study of Figs.2.9 and 2.10 shows that the addition of arrows and indention to pseudo-code results in a pseudo-code structure which looks much like a Warnier-Orr diagram.
In each of the design representations, elements S1 to S11 and A to J may represent modules with many sequential statements or nested control structures. Thus, the example may represent the entire structure of a modest-sized problem or the upper-level structure of a very large problem.
The following section discusses the author is personal preferences regarding the use of design-representation techniques.
2.3.6 Recommended Design-representation Techniques
A large number of design-representation techniques exist, and many of these have been mentioned in this section. Four techniques, high-level flowcharts, HIPO diagram, pseudo-code, and Warnier-Orr diagrams, were described in some detail. In the author is opinion, no one technique dominates over the other either in utility or pervasiveness of use.
More important than which technique should be used is the necessity for using some design technique. Without proper management controls (see Chop6),there are always be a certain percentage of projects and individual software designers who will use virtually no design representation and will keep all the design in their heads. The real problem is ensuring that the design is documented adequately using some technique(s), and the choice of an optimum technique is a second-order consideration-actually a matter of personal preference. A summary of the benefits and drawbacks of the four design representation is giver in Table 2.8.
The author is own personal preferences are for a composite method:
1. An H diagram is drawn and major subprograms are identified.
2. High-level flowcharts are drawn for the control structure and each major subprogram
2.4 STRUCTURED PROGRAMMING
2.4.1 Introduction
The digital computer was born in the 1940s and became a tool of widespread use in business, government, and universities during the 1950s. Extensive use of higher-level language began with Fortran, which was initially proposed in 1954 but did not reach popularity until the decade. Initially, the main focus of programming was to learn machine or assembly language and write some sort of program that worked. Gradually the emphasis become programming cleverness in which tricks or convoluted logic was used to write a more concise or faster program . this helped to minimize memory and compensate for slow execution speeds. The developers of higher-level languages catered to such a concept of superior programming and incorporated great flexibility into new languages. Only in the late 1960s and early 1970s did the consequences of such an approach become clear. Many of the programs were unreadable, incomprehensible, and unmodifiable. The average computer programmer was believed to be a master architect the worth of sir Christopher Wren. A more realistic comparison would be with the architect responsible for the design of a modern high-rise office building. Thus, in retrospect the 1970s might be described as “back to programming basics “; however, professionals were still unsure what the basics of programming really were.
In studying what was wrong with contemporary programming, it was observed that program control structure was often vastly complicated by GO TO statements. The program was that indiscriminate use of GO TO statements generally led to an unduly complicated control structure. One way to correct this problem was to eliminate GO TO statements completely, and to rely on a single decision structure and a single repetition structure. Bohm showed that any program control structure could be synthesized in terms of IF THEN ELSE and DO WHILE control structures. This became the basic philosophy behind structured programming, which has to a large part been developed and popularized in this country by Mills.
2.4.2 Rules of Structured programming
The structured programming philosophy aims to provide a well-defined, clear, and simple approach to program design. Such a method be easier to understand, evaluate, and modify than any arbitrary method conceived by the designers on the spur of the moment. Structured programming requires the use of single-entry and single-exit control structures. The classical technique used to implement these principles is to restrict all control constructs to one of the three statements shown in Fig.2.11 above and on the following page.
The first structure. The SEQUENCE (Fig.2.11a), merely indicates that if there is no intervening control structure, the flow of control naturally passes from one instruction to the next in sequence. This author knows of no modern higher-lever language which does not possess this feature.
The second control structure, the IF THEN ELSE (Fig.2.11b), is a two-way selector common in a number of modern programming languages (PL/1,Algol,Pascal, etc.). Whenever the expression (exp) is true, THEN branch of the statement is executed. When the expression is false, the ELSE branch of the statement is executed. In either case control is transferred subsequently to the statement following the END statement. In some cases the expression may itself be very complex, or may be preceded by a complex assignment statement which sets the value of the expression. In general, one may omit the ELSE statement, in other languages (PL/1, for example) if we wish A or B to be a group of statements, we must enclose them by a “parenthesizing type” of structure such as a BEGIN END block or a DO GROUP.
The third basic control structure is the DO WHILE (Fig.2.11c), which controls repetition (looping). The expression is tested, and if it is true, the body of the structure, A, is performed. As soon as the expression becomes false, repeated performance of A is terminated, and control transfers to the instruction following the END statement. As before, the entity A can be either a single instruction or a group of instructions. Note that if the expression in the DO WHILE is initially false, then entity A is not performed even once.
It is clear that the structured programming restriction of a single entry of control into the beginning of a module and a single exit of control from the end of the module fits in very well with top-down design principles. The novice may have to practice program design using the three basic control structures given in Fig.2.11 before agreeing that loss of the GO TO instruction does not excessively handicap creativity. Before we begin any structured design examples, it is useful to outline some of the issues regarding structured programming which are treated in subsequent sections of this chapter.
Some of the questions which arise when one begins to consider the implications of structured programming are |
收藏
点赞!
反对!