structured design

Methoden …\m_sa.ppt Folie:113.08.1999

Rainer Kröning

Structured Design

Ziele des Designs

Konstruktion des Sytems

Prozessorgrenzen festlegen

Implementierungstechnologie festlegen

Nachvollziehbare Abbildung vom Analysemodell zum Designmodell


Rainer Kröning

Structured Design

Design behandelt die Aspekte

Machbarkeit

Typen von HW- und SW-Umgebung

Kapazität

Kosten für Beschaffung und Betrieb


Rainer Kröning

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


Rainer Kröning

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)


Rainer Kröning

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


Rainer Kröning

Structured Design

Symbole für Structure Charts

S ym bo l B enennung B edeu tung

Name

M o d u l M o d u le m ü sse n in M o d u lb e sch re ib u n g e n w e ite rsp e z ifiz ie rt w e rd e n , u m d ie in n e re S ich t fü r d ieIm p le m e n tie ru n g fe s tzu le g e n .A ls M a k ro g e s trich e lt.

Name

B ib lio th e k s -M o d u l

M o d u l a u s d e r E n tw ick lu n g s u m g e b u n g o d e ra u s d e m la u fe n d e n o d e r fre m d e n P ro je k te n , d iea llg e m e in zu g ä n g lic h in B ib lio th e ke n a b g e le g ts in d . D ie M o d u lb e sch re ib u n g is t a n a n d e re rS te lle e rs te llt.A ls M a k ro g e s trich e lt.


Rainer Kröning

Structured Design


SymbolBenennungBedeutung

Nam e

DatenModul, der ausschließlich Daten enthält

Modulaufruf

Call

asyn. Call

Hut-Symbol

Die Steuerung geht vom rufenden an dengerufenen Modul.

Rufender und gerufener Modul arbeiten parallelweiter.

Inline Code


Rainer Kröning

Structured Design


S ym bo l B en ennu ng B ed eu tu n g

Data

Control

Hybrid

3 Referenz

Ü b e rg a b e -p a ra m e te r

D a te n e le m e n t, Ü b e rg a b e ric h tu n g

S te u e re le m e n t, Ü b e rg a b e ric h tu n g

H yb rid e le m e n t, Ü b e rg a b e ric h tu n g

a u c h R e fe re n z in P a ra m e te rta b e lle m ö g lic h

L o o p K e n n z e ic h n e t w ie d e rh o lte A u fru fe

D e c is io n N a c h fo lg e n d e M o d u le w e rd e n b e d in g t u n da lte rn a tiv a u fg e ru fe n


Rainer Kröning

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


Rainer Kröning

Structured Design

Beispiel für einen Modulaufruf

Kontonummerprüfen

Prüfzifferberechnen

KontonummerPrüfzifer

Prüfzifer_OK


Rainer Kröning

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


Rainer Kröning

Structured Design

Beispiel für ein Structure Chart


Rainer Kröning

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.


Rainer Kröning

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


Rainer Kröning

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)


Rainer Kröning

Structured Design

Kopplung

drei Arten der normalen Kopplung

Datenkopplung (Data Coupling)

Datenstrukturkopplung (Stamp Coupling)

Kontrollkopplung (Control Coupling)

globale Kopplung

Inhaltskopplung


Rainer Kröning

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.


Rainer Kröning

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)


Rainer Kröning

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


Rainer Kröning

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.


Rainer Kröning

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


Rainer Kröning

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


Rainer Kröning

Structured Design

Bindung

normale Bindungsarten

funktionale Bindung

sequentielle Bindung

kommunikative Bindung

prozedurale Bindung

zeitliche Bindung

logische Bindung

zufällige Bindung


Rainer Kröning

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


Rainer Kröning

Structured Design

normale Bindungfunktionale Bindung (Functional Cohesion)

die Gesamtheit der Funktionen eines Moduls dienen einer einzigen, geschlossenen Aufgabe


Rainer Kröning

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


Rainer Kröning

Structured Design

normale BindungKommukative Bindung (Communicatial Cohesion)

die Funktionen eines Moduls nutzen dieselben Eingabe- oder Ausgabedaten

in Module mit funktionaler Bindung zerlegbar


Rainer Kröning

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.


Rainer Kröning

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


Rainer Kröning

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


Rainer Kröning

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


Rainer Kröning

Structured Design

Software-Architektur


Rainer Kröning

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


Rainer Kröning

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


Rainer Kröning

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


Rainer Kröning

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)


Rainer Kröning

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


Rainer Kröning

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.


Rainer Kröning

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


Rainer Kröning

Structured Design

Beschreibung des Problems als Datenflußdiagramm


Rainer Kröning

Structured Design

Identifizierung der logischen und der physikalischen Datenelemente und ihrer Umsetzungen


Rainer Kröning

Structured Design

First-Level Faktorisierung


Rainer Kröning

Structured Design

Faktorisierungder Zweige


Rainer Kröning

Structured Design

Beispiel für grafische Oberflächen


Rainer Kröning

Structured Design

Structure Chart für grafische Oberflächen


Rainer Kröning

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

structured design

Documents