Strukturierter Entwurf Übersicht

Slides:



Advertisements
Ähnliche Präsentationen
Persistente Domänenmodelle mit JPA 2.0 und Bean Validation
Advertisements

der Universität Oldenburg
Integrations- und Funktionstests im Rahmen des V-Modelles
mit Entwicklungsumgebungen (Eclipse) Software verbessern
Qualitätssicherung von Software (SWQS)
Designing Software for Ease of Extension and Contraction
Dr. Andreas Winter Sommersemester 2007 Einführung in die Software-Entwicklung © Institut für Informatik Programmier-Richtlinien vgl. auch
3. Kapitel: Komplexität und Komplexitätsklassen
Kapitel 4 Datenstrukturen
Objektorientierte Analyse (OOA) Inhaltsübersicht
Objektorientierter Entwurf (OOD) Teil 3: Qualitätsmodell
Systemanalyse In der Systemanalyse wird aus den fachspezifischen Anforderungen das Systemmodell erstellt; im Systemmodell ist spezifiziert, was das System.
On a Buzzword: Hierachical Structure David Parnas.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Was ist Refactoring? Bevor man die Integration angeht, mag es angebracht sein, den.
es gibt (fast) nichts, was nicht anders gemacht werden könnte
Java: Dynamische Datentypen
Anfragesprachen – Dipl. Ing. Ulrich Borchert / FH Merseburg1/7 Datenbanken werden als Anhäufung von Werten eines Wertebereiches aufgefasst und Datenbankabfragen.
1 Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Prof. Dr. Th. Ottmann.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Tobias Lauer.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Prof. Dr. Th. Ottmann.
Praktikum Entwicklung und Einsatz von Geosoftware I - Sitzung 6 Model-View-Controler als Grundlage für Nutzerschnittstellen Sommersemester 2003 Lars Bernard.
Praktikum Entwicklung und Einsatz von Geosoftware I - Sitzung 3 Klassen, Objekte, Arrays und Kontrollstrukturen Sommersemester 2003 Lars Bernard.
Modularisierungstechniken
PKJ 2005/1 Stefan Dissmann Ausblick Es fehlen noch: Möglichkeiten zum Strukturieren größerer Programme Umgang mit variabler Zahl von Elementen Umgang mit.
Zusammenfassung Vorwoche
Grundlegende Analysen & Zwischendarstellungen
Software-Engineering
Prüfkriterien für objektorientierte Systeme
Die Skriptsprache Perl (2) Wolfgang Friebel DESY Zeuthen.
1 Reverse Engineering WS 07 / 08 A. Zündorf. Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University 2 Organisatorisches.
3.+4. Übungsblatt Abstraktion, Modultypen und OO Erweiterung des Entwurfs Benutzbarkeitsbeziehungen 11. Mai 2006 Dipl.-Inform. Christian Fuß.
zur Vorlesung Neuronale Netzwerke
DVG Klassen und Objekte
Mehr Qualität und schnellere Marktreife durch effiziente Softwaretests
Einführung in die Programmierung Wintersemester 2013/14 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Entwurfs- und Implementationsdiagramme
Einführung in die Informatik für Naturwissenschaftler und Ingenieure (alias Einführung in die Programmierung) (Vorlesung) Prof. Dr. Günter Rudolph Fachbereich.
Javakurs FSS 2012 Lehrstuhl Stuckenschmidt
Debugging in Lua Universität zu Köln Re-usable Content in 3D und Simulationssystemen Prof. Dr. Manfred Thaller Referent: Artur Wilke.
BIT – Schaßan – WS 02/03 Basisinformationstechnologie HK-Medien Teil 1, 11.Sitzung WS 02/03.
Einführung in die Informatik für Naturwissenschaftler und Ingenieure
Einführung in die Programmierung Wintersemester 2008/09 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Einführung in die Programmierung Wintersemester 2008/09 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Einführung in die Informatik für Naturwissenschaftler und Ingenieure (alias Einführung in die Programmierung) (Vorlesung) Prof. Dr. Günter Rudolph Fakultät.
Einführung in die Programmierung Wintersemester 2009/10 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Einführung in die Programmierung Wintersemester 2011/12 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Einführung in die Programmierung Wintersemester 2012/13 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
OOP-Begriffe Abstraktion Modellieren Klasse Objekt Attribute Methoden
Allgemeines zu Datenbanken
HORIZONT 1 XINFO ® Das IT - Informationssystem PL/1 Scanner HORIZONT Software für Rechenzentren Garmischer Str. 8 D München Tel ++49(0)89 / 540.
Computerorientierte Physik VORLESUNG und Übungen Vorlesung Zeit: Mo., – Uhr Ort: Hörsaal 5.01, Institut für Physik, Universitätsplatz 5, A-8010.
PRO:CONTROL Ziel des Moduls Arbeitspakete
Clean Code Software-Entwicklung als Handwerkskunst Thomas Nagel, November 2011.
Structured Design Ziele des Designs Konstruktion des Sytems
Algorithmen und Datenstrukturen SS 2005
Algorithmen und Datenstrukturen Übungsmodul 3
Agenda für heute, 7. April, 2005 Bedingte ProgrammausführungBedingte Programmausführung Algorithmische Grundlagen Vergleichsoperatoren, Wahrheitswerte.
Software Engineering Grundlagen
Informatik I : Software höhere Programmiersprachen Java Klassen: hat Methoden (Funktionen) und Daten (Variablen) es kann mehrere Klassen geben nur eine.
Algorithmen und Datenstrukturen 1 SS 2002
Java Syntaxdiagramme Buchstabe A B Z a z ... Ziffer
Software Engineering Strukturierter Entwurf
2 Datenabstraktion Geheimnisprinzip:
OOSE nach Jacobson Sebastian Pohl/ST7 Betreuer: Prof. Dr. Kahlbrandt.
Java-Kurs Übung Besprechung der Hausaufgabe
Objektorientierte (OO) Programmierung
Funktionen. Aufgabe : Eingabe zweier Zahlen ---> Minimum bestimmen Dann nochmals Eingabe zweier Zahlen ---> Minimum bestimmen.
Strukturierter Entwurf Übersicht
Implementieren von Klassen
- moodle – a internet based learning platform
 Präsentation transkript:

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

Strukturierter Entwurf Aufrufhierarchie 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 Baumhierarchie Sprünge über Hierarchie-Ebenen sind erlaubt Mehr als ein Vater ist erlaubt

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 Modul Y Control Item

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)

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

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

Strukturierter Entwurf MD: Coupling (Bindung untereinander) Datenbindung Datenstrukturbindung

Strukturierter Entwurf MD: Coupling (Bindung untereinander) Datenbindung Datenstrukturbindung Was ist besser, was ist schlechter?

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

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.

Strukturierter Entwurf Wartbarkeit: 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)

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

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 p - 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); 1 2 Übung: Berechnen Sie die McCabe Komplexität dieses Programm-beispiels: 3 4 5 v(G) = 8 - 7 + 2*1 = 3 ...

Strukturierter Entwurf Wartbarkeit: 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, …

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

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)

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