Structured Design

Structured Design • Ziele des Designs • Konstruktion des Sytems • Prozessorgrenzen festlegen • Implementierungstechnologie festlegen • Nachvollziehbare Abbildung vom Analysemodell zum Designmodell

Structured Design • Design behandelt die Aspekte • Machbarkeit • Typen von HW- und SW-Umgebung • Kapazität • Kosten für Beschaffung und Betrieb

Structured Design • Begriffe • Modul • Sammlung von Programmanweisungen bzw. elementaren Funktionen • Er hat einen Namen, aus dem hervorgeht was er tut • er ist aufrufbar • kann Daten übernehmen • kann Daten zurückgeben

Structured Design • Begriffe • Information-Hiding • Die innere Sicht, interne Funktionalität und interne Daten hält ein Modul verborgen • Funktion • Eine Funktion ist die kleinste Gruppe von Anweisungen, die sich als Einheit ansprechen läßt • Ein Modul besteht aus ein oder mehreren Funktionen • Modularisierung • Gliederung eines Systems in überschaubare und pflegbare Teile. • Vermeidung von Coderedundanz • Mehrfachverwendbarkeit von Modulen(besser noch von einer Reihe zusammenarbeitender Module)

Structured Design • Structure Charts • zeigen • Die äußere Sicht der Module • Beziehungen der Module untereinander • zeigen nicht • die innere Sicht der Module • wann und wie oft ein Modul von einem anderen gerufen wird • in welcher Reihenfolge ein Modul andere ruft

Structured Design • Symbole für Structure Charts

Structured Design • Namensvergabe in Structure Charts • Namen für Module und Daten müssen die Bedeutung (Semantik) für den Leser sofort verständlich machen • Bei Modulnamen ist darauf zu achten, daß ein Modul auch die Leistung aller von ihm gerufenen Module enthält, die also im Namen ebenfalls berücksichtigt werden müssen • Namen von Daten müssen im Datenkatalog definiert sein

Structured Design • Beispiel für einen Modulaufruf

Structured Design • Ordnung im Structure Chart • Eingabe-Moduln (Daten nach oben) soweit wie möglich links • Ausgabe-Moduln (Daten nach unten) soweit wie möglich rechts • Ausgabe-Moduln (Daten nach unten) soweit wie möglich rechts • Quellen und Senken (Lesen und Ausgaben von Daten) als Blätter

Structured Design • Beispiel für ein Structure Chart

Structured Design • Die Modulspezifikation • Spezifikation der inneren Sicht • in Modulköpfen • Pseudocode, formale und/oder grafische Spezifikation • Kontrollstrukturen • Entscheidungstabellen • Bei klarer Zuordnung zwischen den Mini-Spezifikationen der SA und den Modulen der SD reicht Kopie oder Verweis.

Structured Design • Qualitätsbewertung eines Designs • Modulkopplung ( Coupling) • Grad der Abhängigkeit von Modulen • lose Kopplung, geringe gegenseitige Beeinflussung • Austauschbarkeit von Modulen mit gleicher Schnittstelle • ein Modul muß keine internen Details anderer Module kennen • Modulbindung ( Cohesion) • Grad der Zusammengehörigkeit der Funktionen • große Bindung, löst genau eine Aufgabe

Structured Design • Qualitätsbewertung eines Designs • Kopplung und Bindung stehen in Beziehung zueinander • Module hoher Bindung besitzen lose Kopplung • lose Kopplung ist nur bei starker Bindung möglich • Überschaubarkeit • quantitativ (Anzahl Statements) • qualitativen (Anzahl von Algorithmen oder Daten)

Structured Design • Kopplung • drei Arten der normalen Kopplung • Datenkopplung (Data Coupling) • Datenstrukturkopplung (Stamp Coupling) • Kontrollkopplung (Control Coupling) • globale Kopplung • Inhaltskopplung

Structured Design • Normale Kopplung • Modul 1 ruft Modul 2 auf • Modul 2 gibt nach Abschluß seiner Aktionen die Kontrolle an Modul 1 zurück • die Kommunikation zwischen Modul 1 und Modul 2 findet über explizit festgelegte Aufrufparameter statt.

Structured Design • normale Kopplung Datenkopplung (Data Coupling) • Übergabeparameter sind elementare Strukturen (Felder oder homogene Tabellen) • keine Daten übergeben, die nicht gebraucht werden • Anzahl der Parameter begrenzen • Gefahr von Tramp Data (vagabundierende Daten)

Structured Design • normale Kopplung Datenstrukturkopplung (Stamp Coupling) • Übergabeparameter sind komplexere Datenstrukturen • Gefahr der Übergabe von Daten, die nicht benutzt werden • Datenstruktur sollte nur benutzte Felder enthalten

Structured Design • normale Kopplung Kontrollkopplung (Control Coupling) • Parameter werden übergeben, die den Ablauf des anderen Moduls beeinflussen, d.h. die Parameter haben den Charakter von Schaltern, mit denen Einfluß auf den anderen Modul ausgeübt wird.

Structured Design • globale Kopplung (Global or Common Coupling) • Module kommunizieren über einen gemeinsamen Speicherbereich • Ein Fehler eines Moduls kann sich über den Speicher auf die anderen Module auswirken • Diese Kopplungsart ist zu vermeiden, da Wissen um andere Module erforderlich (wie werden die Datenfelder genutzt?) • Info-Cluster einführen

Structured Design • Inhaltskopplung (Content Coupling) • ein Modul adressiert das Innere eines anderen Moduls (z.B. in Assembler möglich) • Diese Kopplungsart muß verboten sein • keine Darstellung vorgesehen

Structured Design • Bindung • normale Bindungsarten • funktionale Bindung • sequentielle Bindung • kommunikative Bindung • prozedurale Bindung • zeitliche Bindung • logische Bindung • zufällige Bindung

Structured Design • normale Bindung • Modul enthält inhaltlich eng zusammengehörige Funktionen • die auf gemeinsamen Daten operieren • die entweder als Parameter übergeben werden oder lokal definiert sind

Structured Design • normale Bindungfunktionale Bindung (Functional Cohesion) • die Gesamtheit der Funktionen eines Moduls dienen einer einzigen, geschlossenen Aufgabe

Structured Design • normale BindungSequentielle Bindung (Sequential Cohesion) • Die Funktionen des Moduls bilden eine zusammenhängende Folge von Aktivitäten • die Ausgabedaten einer Funktion sind die Eingabedaten der nächsten Funktion

Structured Design • normale BindungKommukative Bindung (Communicatial Cohesion) • die Funktionen eines Moduls nutzen dieselben Eingabe- oder Ausgabedaten • in Module mit funktionaler Bindung zerlegbar

Structured Design • Prozedurale Bindung ( Procedural Cohesion) • völlig unabhängige Funktionen, die lediglich die Gemeinsamkeit haben, daß zur selben Zeit oder zu einem bestimmten Zeitpunkt in einer festen Reihenfolge ablaufen (z.B. Initialisierung) • Zeitliche Bindung ( Temporal Cohesion) • der Modul besteht aus völlig unabhängigen Funktionen, die nur die Gemeinsamkeit haben, daß sie nacheinander ablaufen.

Structured Design • Logische Bindung ( Logical Cohesion) • Funktionen des Moduls sind programmstrukturell miteinander verflochten und ihre Ausführung wird beim Aufruf über ein Flag gesteuert • Zufällige Bindung ( Coincidental Cohesion) • die Funktionen des Moduls haben keine sinnvolle Beziehung; z.B. willkürliche Aufteilung aufgrund von Platzproblemen

Structured Design • Faktorisierung • logische Zerteilung eines Modells nach den Kriterien Kopplung und Bindung • Ergebnis wird ein System mit minimaler Coderedundanz sein • sollten Module zu klein werden oder sollten Performanceprobleme auftreten, so können Module als in-line-Code verwendet werden oder die Faktorisierung wird rückgängig gemacht

Structured Design • Software-Architektur • eine Funktion vollständig in einem Architekturblock einer Software-Architektur anzusiedeln • bei der Schichtenbildung ist dafür zu sorgen, daß die eigentlichen Verarbeitungsfunktionen nur noch mit Daten arbeiten bei denen keine physikalischen Aspekte zu berücksichtigen sind

Structured Design • Software-Architektur

Structured Design • Decision Split vermeiden • Entscheidung hat einen Erkennungsteil (Bedingung) und einen Ausführungsteil (Aktionen). Beim Dicision Split werden diese beiden Teile auf verschiedene Moduln verteilt. • Auslagerung der Alternative in einen jeweils direkt aufgerufenen Modul ist jedoch vertretbar

Structured Design • Fehlerbehandlung und Prüfungen • Structured Analysis betrachtet keine Fehlerbehandlung • Fehlerreaktionen einschließlich des Administrationsringes (Prüfarbeit) festlegen • Grundsätze: • vollständige Fallunterscheidungen programmieren • Anstoß einer Meldungsausgabe möglichst durch den Fehler erkennenden Modul • Fehlermeldungen über einen Meldungsmodul mit zentraler Haltung der Fehlermeldungen

Structured Design • Fehlerbehandlung und Prüfungen • Prüfung von Daten nach Übernahme in das System so früh wie möglich durchführen • Reihenfolge: • Zeichenprüfung • Feldprüfung • Prüfung von Kombination von Feldern • Plausibilitätsprüfungen gegen Datenbestände • Module sollten Eingabeparameter gegen die Bedingungen prüfen, die zu einem Programmabbruch führen könnten

Structured Design • Weitere Grundsätze • Static Variablen dürfen nur sehr bewußt eingesetzt werden, denn dieses „interne Gedächtnis" kann dazu führen, daß ein Modul sein Verhalten von einem Aufruf zum nächsten ändert • Initialisierungen, speziell von Zählern und Schleifenvariablen, erst vor der tatsächlichen Nutzung, da sonst Code schwerer verständlich ist (wo ist der Initialisierungsmodul ?) • Initialisierung so spät wie möglich und Terminierung so früh wie möglich (besonders bei der Belegung von Betriebsmitteln) • auch nach schweren Programmfehlern muß eine ordnungsgemäße Terminierung und Freigabe aller Betriebsmittel sichergestellt sein (zum Glück leisten das heute die meisten Betriebssysteme)

Structured Design • Wiederverwendbarkeit • keine Restriktionen wie z.B. Dimensionierungsgrenzen • Konstanten über Includes zur Compile-Zeit • Parameter aus Dateien heraus zur Laufzeit • Erreichung von Wiederverwendbarkeit um jeden Preis, auch wenn sie gar nicht erforderlich ist, kostet uns unnötig Geld und hat zu unterbleiben

Structued Design • Meßlatten • Höhe und Breite eines Systems • Anzahl der Ebenen der Aurufhierarchie • maximale Anzahl von Moduln in der Ebene • Höhe = Breite gilt als ausgewogen (abhängig von Aufgabenstellung) • Fan-Out und Fan-In eines Moduls • Fan-In gibt die Anzahl der Module an, die einen Modul rufen. Großer Fan-In bedeutet großer Wiederverwenbarkeit. Erhöhung von Fan-In ist häufig durch weitere Faktorisierung möglich. • Fan-Out ist die Anzahl direkt gerufener Module eines betrachteten Moduls. Bei mehr als 7 +/- 2 leidet die Übersichtlichkeit des Structure Charts. Bei zu hohem Fan-Out schaltet man Manager-Module zwischen.

Structured Design • Wie kommt man von Analyse zum Design ? • Strategie von Yourdon, Constantinetransform analysis oder transform-centered design • Beschreibung des Problems als Datenflußdiagramm • Identifizierung der logischen und der physikalischen Datenelemente und ihrer Umsetzungen • First-Level Faktorisierung • Faktorisierung der Zweige • Daten physikalisch nach logisch • Verarbeitung • Daten logisch nach physikalisch

Structured Design • Beschreibung des Problems als Datenflußdiagramm

Structured Design • Identifizierung der logischen und der physikalischen Datenelemente und ihrer Umsetzungen

Structured Design • First-Level Faktorisierung

Structured Design • Faktorisierungder Zweige

Structured Design • Beispiel für grafische Oberflächen

Structured Design • Structure Chart für grafische Oberflächen

Structured Design • Wie geht`s weiter? • Komponentenspezifikation, Codierung, Test • TodsündeDesign und ggf. auch die Analyseergebnisse werden nicht mehr aktualisiert. Dokumentation und fertiges System haben nur noch vereinzelte Ähnlichkeit. • AbhilfeEinsatz von Case-Tools • CASE/4/0 von microtool • INOVATOR von MID

Structured Design