4.39 Elementary Method "Structured Design" (STRD)

  4.39 Elementarmethode "Structured Design" (STRD)

Contents		1 Identification/Definition of the Method 2 Brief Characteristic of the Method 3 Limits of the Methods Application 4 Specification of the Methods Allocation 5 Interfaces 6 Further Literature 7 Functional Tool Requirements

1 Identification/Definition of the Method

2 Brief Characteristic of the Method

"Structured Design" (STRD) is a method that can be applied both for the preliminary and for the detailed design of the software. Since the second aspect has already been covered in the methods standard by the basic method PCODE - Pseudocode, the method definition of STRD is limited to the listed chapters 3, 5, and 6.

The objective of STRD in the preliminary design is to structure both the higher ranking control sequences and the actual processing functions in form of a module hierarchy.

Means of Representation

The structure chart is the graphic means of representation for STRD. The basic elements of a structure chart are modules. In the case of the SW architecture, modules refer to individual subprograms. The representation differentiates between modules, predefined modules, data modules, macros, and multiple entry point modules.

By means of structure charts, the calling structure between modules (functions, subprograms) can be represented. These representations include sequence, selection, and iteration in connection with module calls. With each call, data and control flows can be listed separately. If required, the call parameters may be better specified in table-like footnotes. The structure charts also permit comments to the modules. In order to improve the arrangement of large diagrams, relations can also be represented by means of connectors. These make a representation of relations beyond the page margins possible.

To generate structure charts, a great variety of representation means are available, also see /Schönthaler, 1990/, Chap. 7.

Operational Sequence

The starting point for the generation of structure charts are the functions identified during the analysis activities. They are combined into suitable blocks (in this connection identification of individual module types, see Means of Representation) and transformed gradually into a hierarchical module structure. When specifying the individual modules and procedures, principles of module "coupling" and "cohesion" are taken into consideration (compare /Page-Jones, 1988/, chapters 5 and 6). As a rule, the modules must be decoupled as far as possible (low coupling) and the inner strength of each individual module must be as high as possible (high cohesion).

In connection with the SW architecture it is not permitted to equate modules of the structure charts with modules in the sense of the data abstraction. When abstracting data, a module consists of a collection of subprograms operating on shared data (abstract data types). In order to represent modules in the sense of the data abstraction, the mentioned special form of the structure chart module, i. e. the multiple entry point module, can be used. This form is only recommended for modules with up to three or four subprograms, though.

3 Limits of the Methods Application

4 Specification of the Methods Allocation

5 Interfaces

6 Further Literature

7 Functional Tool Requirements

GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster