1 / 18

Strukturierter Entwurf Übersicht

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. Strukturierter Entwurf Anforderungen an Module.

palma
Download Presentation

Strukturierter Entwurf Übersicht

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Strukturierter EntwurfAnforderungen an Module • 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) Ein (Software-)Modul ist ein abgeschlossener Teil eines Software-programms, bestehend aus einer Folge von Verarbeitungsschritten und Datenstrukturen mit folgenden Eigenschaften (David Parnas): Kosten Kosten Kosten =f(Größe) Kosten =f(Anzahl) Wachsende Anzahl/geringere Größe

  3. Strukturierter EntwurfAufrufhierarchie bei Modulen Die Benutzt-Hierarchie ist keine strenge und auch keine Baumhierachie, d.h. Ein Modul X benutzt einen Modul Y, wenn eine Funktion von X eine Funktion von Y aufruft. StrengeHierarchie Baumhierarchie Sprünge über Hierarchie-Ebenen sind erlaubt Mehr als ein Vater ist erlaubt

  4. Strukturierter EntwurfModular Design (MD): Structure Chart • 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 Die Aufruf-Hierarchie von Modulen wird in einem Structure Chart (Strukturbild) dargestellt: Modul X Data Item Modul Y Control Item

  5. Strukturierter EntwurfMD:Structure Chart • 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) Es gibt folgende Modultypen:

  6. Strukturierter EntwurfMD: 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 ELSE-Statement) gehören in dasselbe Modul.

  7. Strukturierter EntwurfMD: 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

  8. Strukturierter EntwurfMD: Coupling (Bindung untereinander) Datenbindung Datenstrukturbindung

  9. Strukturierter EntwurfMD: Coupling (Bindung untereinander) Datenbindung Datenstrukturbindung Was ist besser, was ist schlechter?

  10. Strukturierter EntwurfMD:Coupling (Bindung untereinander) Kontrollbindung Ein Modul beeinflusst die Ablaufsteuerung des anderen Moduls.

  11. Strukturierter EntwurfBewertung (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.

  12. Strukturierter EntwurfWartbarkeit: Komplexität verringern • Größe oder auch Anzahl der Komponenten • Anzahl der aufgerufenen Module, fan out (max 7) • Anzahl von Dateizugriffen pro Modul (max 1 Datei) • 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)

  13. Strukturierter EntwurfWartbarkeit: 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))))

  14. 1 4 ... ... 3 2 5 Strukturierter EntwurfWartbarkeit: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 Gn - number of nodes in Gp - number of connected components (if you have subprograms, p=1 in a single program) IF a>b THEN IF b>c THEN p(a,b) ELSE p(b,c); Print(a,b,c); Übung: Berechnen Sie die McCabe Komplexität dieses Programm-beispiels: • v(G) = 8 - 7 + 2*1 = 3

  15. Strukturierter EntwurfWartbarkeit: Verständlichkeit erhöhen • Namenskonventionen • Einheitliche Konventionen, z.B. Consonant Notation (Bsp. nwddrss) oder Writing Notation (Bsp. newAddress) • Modulnamen 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) • Jede Variable • Jeder Absatz • Zentralisierung und Vereinheitlichung des Errorhandlings, der Autorisierung, des Reportings, …

  16. Strukturierter EntwurfErrorhandling 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 Examine-Modul aufrufen, nicht vom Detection-Modul • Mit Fehlernummern statt mit Fehlertexten die Fehler identifizieren DM OM

  17. Strukturierter EntwurfVon SA zu MD (modular design) • 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) From data flow diagrams to a hierarchical modular structure

  18. Strukturierter EntwurfAnhang Z0.. Lösung der Übung auf Seite 14 (Metric of McCabe) Z1 Z2 Z6 Z3 Z9 • v(G) = 9 - 7 + 2*1 = 4 Z13

More Related