Previous Next Methods Allocation  
4.39 Elementarmethode "Structured Design" (STRD)  

  4.39 Elementary Method "Structured Design" (STRD)

Inhalt  
  • 1 Identifikation/Definition der Methode
  • 2 Kurzcharakteristik der Methode
  • 3 Grenzen des Methodeneinsatzes
  • 4 Detaillierung der Methodenzuordnung
  • 5 Schnittstellen
  • 6 Weiterführende Literatur
  • 7 Funktionale Werkzeuganforderungen
  • 1 Identifikation/Definition der Methode

    /Page-Jones, 1988/ Kapitel 3, Kapitel 5, Kapitel 6

    2 Kurzcharakteristik der Methode

    Ziel und Zweck

    "Structured Design" (STRD) ist eine Methode, die sowohl zum Grobentwurf als auch zum Feinentwurf der Software angewandt wird. Da der zweite Aspekt bereits durch die Methode PCODE abgedeckt ist, beschränkt sich die Methodenfestlegung von Structured Design auf die angegebenen Kapitel 3, 5 und 6.

    Ziel der Methode im Grobentwurf ist es, sowohl die übergeordneten Steuerungsabläufe als auch die eigentlichen Verarbeitungsfunktionen in Form einer Modulhierarchie zu strukturieren.

    Darstellungsmittel

    Das grafische Ausdrucksmittel der Methode STRD ist die Structure Chart. Die grundlegenden Elemente einer Structure Chart sind Module. Dabei versteht man unter "Modulen" im Fall der SW-Architektur einzelne Unterprogramme. Die Darstellung unterscheidet zwischen Modulen, vordefinierten Modulen, Datenmodulen, Macros und Multiple-entry-point-Modulen.

    Durch Structure Charts wird die Aufrufbeziehung zwischen Modulen (Funktionen, Unterprogrammen) dargestellt. Darstellbar sind Sequenz, Selektion und Iteration bei Modulaufrufen. Bei jedem Aufruf können Daten- und Kontrollflüsse gesondert angegeben werden. Bei Bedarf können die Aufrufparameter in tabellenförmigen Fußnoten genauer spezifiziert werden. Die Structure Charts erlauben zusätzlich die Darstellung von Kommentaren zu Modulen.

    Um eine größere Übersichtlichkeit bei umfangreichen Diagrammen zu ermöglichen, können Beziehungen auch durch Konnektoren dargestellt werden. Diese erlauben die Darstellung von Beziehungen über Seitengrenzen hinweg.

    Zum Aufbau von Structure Charts gibt es einen reichhaltigen Satz an Darstellungsmitteln, siehe auch /Schönthaler, 1990/, Kapitel 7.

    Funktioneller Ablauf

    Ausgangspunkt für die Erstellung der Structure Charts sind die bei den Analysetätigkeiten identifizierten Funktionen. Diese werden zu geeigneten Blöcken zusammengefaßt (hierbei Identifizierung einzelner Modultypen, siehe Darstellungsmittel) und schrittweise in eine hierarchisch gegliederte Modulstruktur überführt. Bei der Bildung der einzelnen Module und Prozeduren werden Prinzipien der "Kopplung" und "Kohäsion" zwischen den Modulen (vgl. /Page-Jones, 1988/, Kapitel 5 und 6) berücksichtigt. Der Regelfall ist es hierbei, die Module untereinander weitgehend zu entkoppeln (low coupling) und den inneren Zusammenhalt jedes einzelnen Moduls möglichst hoch zu gestalten (high cohesion).

    Keinesfalls darf man bei der SW-Architektur die Module der Structure Charts mit Modulen im Sinne der Datenabstraktion gleichsetzen. Bei der Datenabstraktion besteht ein Modul aus einer Sammlung von Unterprogrammen, die auf gemeinsamen Daten operieren (abstrakte Datentypen). Für die Darstellung von Modulen im Sinne der Datenabstraktion gibt es die genannte Sonderform des Structure Chart Moduls, den "Multiple-entry-point"-Modul. Dessen Formgebung eignet sich allerdings nur für Module mit vielleicht drei oder vier Unterprogrammen.

    3 Grenzen des Methodeneinsatzes

    Für die SW-Architektur eignen sich Structure Charts nur bei der Verwendung von Programmiersprachen, die einen funktionsorientierten, klassischen Ansatz mit singulärem Kontrollfluß unterstützen. Für realzeitorientierte Entwicklungen mit nebenläufigen Prozessen ist OBJE die geeignetere Methode.

    4 Detaillierung der Methodenzuordnung

    Nr. Aktivität Beschreibung
    4.1 SE4.1 - SW-Architektur entwerfen Structured Design unterstützt direkt die Modularisierung innerhalb einer SW-Einheit.

    Ab der Evaluationsstufe E5 sind die Entwurfskonzepte hierarchische Dekomposition, Abstraktion und Datenabschottung in verschärftem Maße umzusetzen.

    Die Methode deckt das Teilprodukt "Übersicht der SW-Komponenten, SW-Module, Prozesse und Datenbanken" teilweise ab; die Anbindung von Datenbanken kommt in den Structure Charts nicht zum Ausdruck.

    5 Schnittstellen

    Nr. Schnittstellen Bemerkung Information (Anhang 1)
    5.1 STRD-PCODE Die Methode Pseudocode schließt sich an die Erstellung des Structured Design an und wird für die Spezifikation der SW-Module benutzt. 4.16 Schnittstelle PCODE-STRD

    6 Weiterführende Literatur

    /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 Funktionale Werkzeuganforderungen

    SSD03 - Supporting Architectural Design

    Previous Next This page online  •  GDPA Online  •  Last Updated 08.Oct.2002 by C. Freericks