Strukturierter Entwurf

BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Übersicht
• Anforderungen an Module
• Modular Design (MD):
– Structure Chart
Cohesion
– Coupling
• Bewertung des Entwurfs
– Wartbarkeit
• Komplexität
• Lesbarkeit und Verständlichkeit
• Errorhandling
• Von SA zu MD
–
Seite 1
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Anf orderungen an Module
Ein (Software-)Modul ist ein abgeschlossener Teil eines Software-programms,
bestehend aus einer Folge von Verarbeitungsschritten und Datenstrukturen mit
folgenden Eigenschaften (David Parnas):
•
•
•
•
Information hiding: Kapselung
(encapsulation) durch die Trennung von
Schnittstelle und Implementierung
Module sind separat bearbeitbar, testbar,
kompilierbar und eindeutig einer(!) Person
zugeordnet
Modulaufrufe sind hierarchisch strukturiert
Ein guter Modulentwurf ist
gekennzeichnet durch:
–
–
–
Geringe Komplexität
Starke Bindung untereinander (strong
cohesion)
Lose Kopplung zu anderen Modulen
(loose coupling)
Kosten
Kosten
Kosten =
f(Größe)
Kosten =
f(Anzahl)
Wachsende Anzahl/geringere Größe
Seite 2
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Auf ruf hierarchie bei Modulen
Ein Modul X benutzt einen Modul Y, wenn eine Funktion von X eine Funktion von
Y aufruft.
Die Benutzt-Hierarchie ist keine strenge und auch keine Baumhierachie, d.h.
Strenge
Hierarchie
Sprü
n
Hier ge übe
a
r
Ebe rchien
erla en sind
ubt
Baumhierarchie
ein
s
l
hr a st
e
M er i
Vat ubt
erla
Seite 3
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Modular Design (MD): Structure Chart
Die Aufruf-Hierarchie von Modulen wird in einem
Structure Chart (Strukturbild) dargestellt:
•
•
•
•
•
Alle Module mit ihrer Hierarchie sind
sichtbar
Jedes Modul als Rechteck gezeichnet
hat einen sprechenden Namen
Der Aufruf wird durch einen Pfeil
repräsentiert
An den Pfeilen können die
Aufrufparameter (data couples)
eingegeben werden
Das Strukturbild zeigt nicht, ob ein
Modul aufgerufen wird, die Reihenfolge
der Aufrufe und die Inhalte der Module
Modul X
Data Item
Control Item
Modul Y
Seite 4
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
MD: Structure Chart
Es gibt folgende Modultypen:
• Funktionsmodul /Steuermodul (kein
Unterschied in der Darstellung)
• Datenmodul (enth. keinen Code, nur
Daten
• Bibliotheksmodul (gut dokumentiert,
ausreichend getestet, i.d.R. nicht
selbst erstellt)
• Objektmodul (ADT=abstrakter
Datenyp) mit lokalem Speicher
(Daten und Code)
Seite 5
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
MD: Cohesion (Zusammenhalt)
Zu empfehlen sind Modulstrukturen, deren Funktionen folgendermaßen zusammen
gehalten werden:
• Funktional: alle arbeiten an derselben Aufgabe
• Informationsbezogen: alle arbeiten auf derselben Datenstruktur
• Sequentiell: Der Output der einen ist der Input der anderen
• Kommunikativ: sie erzeugen oder benutzen dieselbe Datenstruktur
Nicht zu empfehlen sind Modulstrukturen, deren Funktionen folgendermaßen zusammen
gehalten werden:
• Temporär: werden häufig nacheinander aufgerufen
• Logisch: Sammlung von ähnlichen Funktionen, z.B. eine mathematische Bibliothek
Decision Split ist zu vermeiden!
Bedingungsausdruck (IF-Statement) und zugehörige Maßnahmen (THEN- und ELSEStatement) gehören in dasselbe Modul.
Seite 6
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
MD: Coupling (Bindung untereinander)
Zu empfehlen sind Strukturen, bei denen die Module folgendermaßen untereinander
gekoppelt sind:
• Datenbindung (data): Aufruf mit Übergabe der direkten Parameter
• Datenstrukturbindung (stamp): Aufruf mit Übergabe indirekter Parameter
• Kontrollbindung (control): Aufruf mit Übergabe von Parametern die zur Steuerung der
Programme verwendet werden
Nicht zu empfehlen sind Strukturen, bei denen die Module folgendermaßen
untereinander gekoppelt sind:
• Inhaltsbindung (content): unkontrollierter Sprung in einen Code-Abschnitt
• Gemeinschaftsbindung (common): Kopplung über einen COMMON-Bereich, der allen
Modulen zur Verfügung steht
Seite 7
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
MD: Coupling (Bindung untereinander)
Datenbindung
Datenstrukturbindung
Seite 8
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
MD: Coupling (Bindung untereinander)
Datenbindung
Datenstrukturbindung
Seite 9
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
MD: Coupling (Bindung untereinander)
Kontrollbindung
Ein Modul beeinflusst die Ablaufsteuerung des anderen Moduls.
Seite 10
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Bewertung (Evaluierung)
Nach Abschluss des strukturierten Entwurfs wird in der Regel die
Wartbarkeit bewertet!
Und gute Wartbarkeit erreicht man, indem man:
• die Komplexität verringert und
• die Lesbarkeit und Verständlichkeit erhöht
Ein System ist umso leichter wartbar, wenn es lesbar ist, wenig komplex, modular
aufgebaut, durchgängig beschrieben, möglichst selbsterklärend und allgemein
verständlich.
Insbesondere führt die funktionale oder auch strukturelle Komplexität zu einer kognitiven
Komplexität und somit zu erhöhten Schwierigkeiten beim Software-Entwurf, d.h.
Fehleranfälligkeit als externes Qualitätsmaß steigt. Komplexitätsmetriken dienen dazu, die
Wartbarkeit eines IT-Systems quantitativ zu bewerten, wobei im wesentlichen interne und
externe Beziehungen zwischen Komponenten (Klassen, Module, Statements) gemessen
werden.
Seite 11
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Wartbarkeit: Komplexität verringern
• Größe oder auch Anzahl der Komponenten
– Anzahl von Aufrufparametern (max. 10)
– Anzahl von Zeichen pro Zeile (max. 80)
– Anzahl von Codezeilen in einem Modul (max. 500)
• Boolesche Ausdrücke
– Default ist „TRUE“
– Schachtelungstiefe (max. 4)
• Abhängigkeiten
• Schachtelungstiefe, DIT (depth of inheritance tree)
• Zyklomatische Zahl (nach McCabe)
• Cohesion
• Coupling, CBO (coupling between objects), fan-out
Seite 12
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Wartbarkeit: Komplexität verringern
Beispiele:
• Anzahl der Parameterübergabe
• Art der Parameterübergabe (direkt, indirekt, unüblich, global)
• Schachtelungstiefe für Distance = SQRT ((Y1 - Y0)2 + (X1 - X0)2)
Call Distance ( X0, Y0, X1, Y1, DSTNC)
Call Distance ( SOURCE, TARGET, DSTNC)
Call Distance ( XKOOR, YKOOR, DSTNC)
Call Distance
Call SQRT (X)
Call SQRT (X,Y)
Call SQRT (X,Y,Z)
Hohe Komplexität
Distance = SQRT(SUM(SQ(DIFF(Y1,Y0)),SQ(DIFF(X1,X0))))
Seite 13
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Wartbarkeit: Komplexität verringern
Metric of McCabe: Cyclomatic Number v(G) is the maximum
number of independent paths in a flowgraph G: v(G) = e - n + 2p
e - number of edges in G
n - number of nodes in G
1
p - number of connected components
(if you have subprograms, p=1 in a single program)
...
IF a>b
THEN IF b>c
2
Übung:
Berechnen Sie
die McCabe
Komplexität
dieses
Programmbeispiels:
3
4
THEN p(a,b)
ELSE p(b,c);
Print(a,b,c);
5
...
Seite 14
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Wartbarkeit: Verständlichkeit erhöhen
Objekte der Betrachtung: betreffen oft die Erwartungskonformität
• Namenskonventionen
– Einheitliche Konventionen, z.B. Consonant Notation (Bsp. nwddrss)
oder Writing Notation (Bsp. newAddress)
– Klassennamen beginnen mit einem Großbuchstaben
– Konstante bestehen aus Großbuchstaben, Ziffern und Unterstrichen
• Einheitlicher Modulheader
– Titel und Zugehörigkeit zum Gesamtsystem
– Funktionelle Kurzbeschreibung
– Versionsangabe mit Datum und Historie
– Verantwortlichkeit
• Einsatz von Kommentaren (DC = Kommentardichte = 0,25)
• Zentralisierung und Vereinheitlichung des Errorhandlings, der Autorisierung,
des Reportings, …
Seite 15
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Errorhandling
Beim Errorhandling unterscheiden wir drei Arten von Moduln:
DM• (Detection-)Modul, das den Fehler
entdeckt
(Examine-)Modul, das den Fehler
bewertet und Gegenmaßnahmen
initiiert
(Output-)Modul, das die Fehlermeldung
ausgibt
•
EM
OM•
EM
Regeln beim zentralen Errorhandling:
•
•
•
Fehlermeldungen möglichst nicht
durch das System tragen
Output-Modul vom ExamineModul aufrufen, nicht vom
Detection-Modul
Mit Fehlernummern statt mit
Fehlertexten die Fehler
identifizieren
DM
OM
Seite 16
BA Stuttgart, Technische Informatik, SW-Engineering, Strukturierter Entwurf
Februar 2006
Strukturierter Entwurf
Von SA zu MD (modular design)
From data flow diagrams to a hierarchical modular structure
• identify central transformation by tracking the input and output data
flows
• if any process not suitable for central transformation, add new
module called central transformation
• create hierarchy
• chose module names related to its functionality
• add modules for writing and reading
• add modules for initialization and termination the application system
• check if library modules are available
• add flags for controlling tasks
• add error handling
• if necessary divide modules in separate (sub)modules (factorizing)
Seite 17