Structured Design Ziele des Designs Konstruktion des Sytems

Präsentation zum Thema: "Structured Design Ziele des Designs Konstruktion des Sytems"—  Präsentation transkript:

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

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

3 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

4 Structured Design Begriffe Information-Hiding Funktion Modularisierung
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)

5 Structured Design Structure Charts zeigen zeigen nicht
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

6 Structured Design Symbole für Structure Charts

7 Structured Design Symbole für Structure Charts

8 Structured Design Symbole für Structure Charts

9 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

10 Structured Design Beispiel für einen Modulaufruf

11 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 Quellen und Senken (Lesen und Ausgaben von Daten) als Blätter

12 Structured Design Beispiel für ein Structure Chart

13 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.

14 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

15 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)

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

17 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.

18 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)

19 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

20 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.

21 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

22 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

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

24 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

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

26 Structured Design normale Bindung Sequentielle 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

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

28 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.

29 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

30 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

31 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

32 Structured Design Software-Architektur

33 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

34 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

35 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

36 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)

37 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

38 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.

39 Structured Design Wie kommt man von Analyse zum Design ?
Strategie von Yourdon, Constantine transform 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

40 Structured Design Beschreibung des Problems als Datenflußdiagramm

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

42 Structured Design First-Level Faktorisierung

43 Structured Design Faktorisierung der Zweige

44 Structured Design Beispiel für grafische Oberflächen

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

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