Software Design 2e - DIM

168Some design representationsnnnPull out ‘language keywords’ in some manner, perhaps by typing them in uppercase or underlined.Try to ‘bracket’ executable blocks such as the body of a loop, or a branch clause ina conditional structure, by using such paired keywords as LOOP and ENDLOOP orIF and ENDIF.Avoid referring to the identifiers of program variables or the values of constants.For example, the line check for the end-of-line character is more abstractand much more easily comprehended than check for #15, which requires aknowledge of the significance of #15.While these practices cannot guarantee better levels of abstraction, they can certainlyhelp to avoid writing pseudocode that is little better than poorly documentedcode!The pseudocode viewpointAs already mentioned, this is basically a functional one, based upon the sequencingof operations, expressed at quite a detailed level. There is also a small constructionalelement, but this is relatively minor in terms of importance.Uses for pseudocodePseudocode is widely used to complement and augment other forms of descriptionused in the later stages of design. It is hard to develop a design using pseudocode alone(one hesitates to say ‘impossible’), but it is certainly undesirable, not least because ofthe restricted viewpoint it provides when making design choices.Pseudocode can be used to complement the Structure Chart by providing thedetails and sequencing information that elaborates on the boxes in the diagram. It canof course be generated directly from a Structure Diagram. Indeed, almost all forms ofdiagram can usefully be augmented with a textual description of this form, since its disciplinedformat can help to maintain the relevant levels of abstraction.Pseudocode will rarely appear in the examples of this book, since we will not betaking any segments of our larger examples down to quite this level of detail.However, its use for detailed design should be taken as assumed, even if it is not mentionedexplicitly in the context of a particular design method.7.4 Developing a diagramHaving considered a range of (largely diagrammatical) forms of design notation, twoobvious and related questions that might arise are ‘how are these diagrams developed?’and ‘how can they be checked for consistency?’. Obviously, there is no one answer toeither of these questions and, for design methods at least, both the tasks of producingand verifying diagrams may be partly driven by the procedures of the method. In thislast section, however, we briefly review one means of checking and producing diagrammaticalforms, namely the use of tabular structures.