Software Design 2e - DIM

None of these points detracts significantly from its importance as a topic for study.As a method it remains highly usable and particularly well documented, and it is alsoone that has influenced many later developments. So within this chapter we will continueto regard this method as employing a largely top-down philosophy and willconfine our examples to this ‘core’ form.The basic problem domain assumed for this method (and hence that which isnormally assumed by most textbooks) is that of data processing. However, the basicstrategy seems to be capable of quite wide application, and it has been extended in anumber of different ways, mostly intended to enhance its usefulness for the real-timeproblem domain (Hatley and Pirbhai, 1988; Ward and Mellor, 1985; Ward, 1986;Gomaa, 1986).Because of this background in the domain of data processing, most of the textbooksdescribing the method concern themselves with problems that involve the use ofonly a single sequential process for their solution. However, this is not a restrictionimposed by the method, apart from the design transformation stages of the StructuredDesign process, and certainly Structured Systems Analysis is well able to cope withproblems that involve concurrent processing of information.259Representation forms for SSA/SD13.2 Representation forms for SSA/SDAll of the many variants of this method make extensive use of two of the forms of diagrammaticalrepresentation encountered in Chapter 7. The Structured Systems Analysistechniques are centred on the use of the Data-Flow Diagram, or DFD (describedin Section 7.2.1), while the Structured Design process makes use of the Structure Chartthat was described in Section 7.3.1.13.2.1 Representations for Structured Systems AnalysisDFDs provide a problem-oriented and functional viewpoint that does not involvemaking any assumptions about ‘hierarchy’ (in the sense that all bubbles on the diagramare ‘equal’). The techniques of Structured Systems Analysis guide the designer (or‘analyst’) in building a model of the problem by using DFDs, elaborating this wherenecessary by using child DFDs in order to provide the necessary levels of detail. (Thisprocess of elaboration is rather confusingly termed ‘levelling’ of the DFD.) Figure 13.1shows a simple example of a DFD, which we previously encountered as Figure 7.2.The functional viewpoint provided through the use of DFDs can be augmented bymeans of more detailed descriptions in the form of ‘process specifications’, or ‘P-Specs’(sometimes termed ‘mini-specs’). A P-Spec is a textual description of the primitive processthat is represented by a bubble in a DFD, and so can be regarded as a subsidiaryfunctional viewpoint. A typical P-Spec will summarize the process in terms of its title,a description of the input/output data flow relating to the process, and the proceduraltasks that it performs, couched in terms of the basic concepts of sequence, selectionand iteration. An example of a simple P-Spec and its form is shown in Figure 13.2.A data dictionary can also be used to record the information content of data flows.This typically includes descriptions of all of the data forms that are mentioned in theDFDs, P-Specs and any other forms of description that might be used. The initial