Previous Next Methods Allocation  
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

    /Page-Jones, 1988/ chap.3, chap.5, chap.6

    2 Brief Characteristic of the Method

    Objective and Purpose

    "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

    For the SW architecture, structure charts are only suited when applying programming languages supporting a function-oriented, traditional approach with singular control flow. For realtime-oriented developments with concurrent processes, ODT - Object Design Technique is the more appropriate method.

    4 Specification of the Methods Allocation

    No. Activity Description
    4.1 SD4.1 - SW Architecture Design Structured Design directly supports the modularization within one SW Unit.

    Starting with the evaluation level E5 the design concepts hierarchical decomposition abstraction, and information hiding have to be strictly applied.

    The method partly covers subproduct SW Architecture.Overview of SW Components, SW Modules,Processes and Databases; the integration of databases is not represented in the Structure Charts.

    5 Interfaces

    No. Interface Observation Information in Annex 1
    5.1 STRD-PCODE The basic method Pseudocode follows after the generation of the Structured Design and is applied for the specification of the SW Modules. 4.16 Interface PCODE-STRD

    6 Further Literature

    /Page-Jones, 1988/ The Practical Guide to Structured System Design
    /Peters, 1988/ Advanced Structured Analysis and Design
    /Raasch, 1991/ Systementwicklung mit Strukturierten Methoden
    /Schönthaler, 1990/ Software Entwicklungswerkzeuge: Methodische Grundlagen
    /Yourdon-Constantine, 1979/ Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design

    7 Functional Tool Requirements

    SSD03 - Supporting Architectural Design

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