1 Funktionsorientiertes Software-Design (Fortsetzung) Vorlesung 6 Prof. R. Mall Abt. Von CSE, IIT, Kharagpur. Präsentation zum Thema: 1 Funktionsorientiertes Software-Design (Fortsetzung) Vorlesung 6 Prof. R. Mall Abt. Von CSE, IIT, Kharagpur. Präsentationstranskript: 1 1 Funktionsorientiertes Software-Design (Fortsetzung) Vorlesung 6 Prof. R. Mall Abteilung der CSE, IIT, Kharagpur 2 2 Beispiel 3: Handelshaus-Automatisierungssystem (TAS) Ein großes Handelshaus möchte, dass wir ein Software: Automatisieren Buchhaltung Aktivitäten mit seinem Unternehmen verbunden. Es hat viele Stammkunden: Wer Platz Bestellungen für verschiedene Arten von Rohstoffen. 3 3 Beispiel 3: Handelshaus-Automatisierungssystem (TAS) Das Handelshaus unterhält Namen und Adressen seiner Stammkunden. Jedem Kunden wird eine eindeutige Kundennummer (CIN) zugewiesen. Nach derzeitiger Praxis beim Kundenauftrag: Die Buchhaltung prüft zunächst die Kreditwürdigkeit des Kunden. 4 4 Beispiel: Trading-House Automation System (TAS) Die Kreditwürdigkeit eines Kunden wird bestimmt: Durch die Analyse der Geschichte seiner Zahlungen an die Rechnungen, die ihm in der Vergangenheit zugesandt wurden. Wenn ein Kunde nicht kreditwürdig ist, werden seine Aufträge nicht weiter verarbeitet. Für den Kunden wird eine entsprechende Ablehnungsnachricht erzeugt. 5 5 Beispiel: Trading-House Automation System (TAS) Wenn ein Kunde kreditwürdig ist: Gegenstände, die er bestellt hat, werden mit der Liste der Gegenstände, mit denen sich das Handelshaus befasst, überprüft. Die Gegenstände, die vom Handelshaus nicht behandelt werden, werden nicht weiterverarbeitet. Für diese Gegenstände wird eine entsprechende Meldung für den Kunden erzeugt. 6 6 Beispiel: Handelshaus-Automatisierungssystem (TAS) Die Positionen eines Kundenauftrags, mit dem sich das Handelshaus befasst: Wird auf Verfügbarkeit im Inventar überprüft. Wenn die Positionen im Bestandsverzeichnis in den gewünschten Mengen vorhanden sind, wird eine Rechnung mit der Weiterleitungsadresse des Kunden ausgedruckt. Ein Materialausgabebeleg wird gedruckt. 7 7 Beispiel: Trading-House Automation System (TAS) Der Kunde kann die Materialausgabe im Lagerhaus produzieren: Die Lieferung der Artikel nehmen. Inventurdaten angepasst, um den Verkauf an den Kunden widerzuspiegeln. 8 8 Beispiel: Handelshaus-Automatisierungssystem (TAS) Wenn ein bestellter Artikel im Inventar nicht in ausreichender Menge vorhanden ist: Um ausstehende Aufträge zu speichern, können Sie Details in einer Auftragsdatei speichern. Out-of-stock-Artikel zusammen mit der bestellten Menge. Kunden-Identifikationsnummer 9 9 Beispiel: Trading-House Automation System (TAS) Die Einkaufsabteilung würde regelmäßig Befehle ausgeben, um Einrückungen zu erzeugen. Bei der Erstellung des Befehls gener indent: Das System sollte die Pending Order-Datei untersuchen. Die anstehenden Aufträge ermitteln Die Gesamtmenge, die für die einzelnen Posten benötigt wird. 10 10 Beispiel: Handelshaus-Automatisierungssystem (TAS) TAS sollte die Adressen der Lieferanten, die die benötigten Positionen liefern, herausfinden: Prüfen Sie die Datei mit den Lieferantendetails (ihre Adresse, Positionen, die sie liefern usw.) 11 11 Beispiel: Trading-House Automation System (TAS) TAS sollte auch beantworten Management-Abfragen: Statistiken der verschiedenen Artikel verkauft über einen bestimmten Zeitraum Entsprechende Menge verkauft und der Preis realisiert. 12 12 Kontextdiagramm Trading - Haus - Automation - System 0 Manager CustomerPurchase - Abfrage - statistik Bestell - antwort Generieren - indent indent 13 13 Level 1 DFD Accept - order 0.1 Prozess - order 0.2 Handle - indent - request 0.4 Hand - ling 0.3 pending-order Vertriebsstatistik Inventur Lieferantenliste Kundendatei Objektdatei Kundenhistorie Einrückung Einrückungen Eingetragene Aufträge Auftragsstatistik Auftrag Material-Emissionsschein 14 14 Beispiel: Data Dictionary-Antwort: Stücklisten-Materialausgabe, Ablehnungsnachricht Abfrage: Periodenabfrage vom Manager in Bezug auf Verkaufsstatistik Zeitraum: datedate, month, year, day date: year month day year: integer month: integer day: integer Reihenfolge: customer-id accept-order: bestellte Artikel in der Inventory-Ablehnungsnachricht bestellen : Bestellnachricht Ablehnungsnachricht Ausstehende Aufträge: Kunden-ID Kundenadresse: namehousestreetcitypin 15 15 Beispiel: Data Dictionary item-name: string Haus: String Strasse: String Ort: String Pin: Integer Kunden-ID: Integer-Rechnung: Gesamtbetrag Kunden-Adresse Material-Emissionsprospekt: Meldungsposition Menge Kundenadresse Meldung: Stringstatistik: Umsatzstatistik: Menge: Integer 16 16 Beobachtung Aus den Beispielen ist zu erkennen, dass DFDs helfen: Datenmodell Funktionsmodell 17 17 Observation Als DFD Wird in größere Detailstufen verfeinert: Der Analytiker führt eine implizite funktionale Zerlegung durch. Gleichzeitig finden Verfeinerungen der Daten statt. 18 18 Richtlinien für die Konstruktion von DFDs Das Kontextdiagramm sollte das System als eine einzige Bubble darstellen: Viele Anfänger begehen den Fehler, mehr als eine Bubble im Kontextdiagramm zu zeichnen. 19 19 Richtlinien für den Aufbau von DFDs Alle externen Entitäten sollten im Kontextdiagramm dargestellt werden: Externe Entitäten sollten auf keiner anderen Ebene von DFD auftreten. Es sollten nur 3 bis 7 Blasen pro Diagramm zugelassen werden: Jede Blase sollte auf 3 bis 7 Blasen zerlegt werden. 20 20 Richtlinien für den Aufbau von DFDs Ein häufiger Fehler, den viele Anfänger begangen haben: Versuch, Steuerinformationen in einer DFD darzustellen. z. B. Um die Reihenfolge darzustellen, in der verschiedene Funktionen ausgeführt werden. 21 21 Richtlinien für den Aufbau von DFDs Ein DFD stellt keine Steuerinformationen dar: Wenn oder in welcher Reihenfolge unterschiedliche Funktionen (Prozesse) aufgerufen werden Die Bedingungen, unter denen verschiedene Funktionen aufgerufen werden, werden nicht dargestellt. Beispielsweise könnte eine Funktion eine Funktion oder eine andere Funktion abhängig von einer bestimmten Bedingung aufrufen. Viele Anfänger versuchen, diesen Aspekt darzustellen, indem sie einen Pfeil zwischen den entsprechenden Blasen zeichnen. 22 22 Beispiel-1 Eingangswert prüfen: Wenn der Eingabewert kleiner oder größer ist als eine Fehlermeldung generieren sonst nach der Nummer suchen Chec k er er Generator Fehler Searc h Nummer Meldungsnummer gefunden, nicht gefunden 23 23 Richtlinien For Konstruieren von DFDs Wenn eine Blase A Blase B oder Blase C abhängig von einigen Bedingungen aufruft, stellen sie die Daten dar, die von Blase A zu Blase B und Blasen A bis C fließen, nicht die Bedingungen, die davon abhängen, auf welchen ein Prozess aufgerufen wird. 24 24 Beispiel-2 Eine Funktion akzeptiert den Buchnamen, der vom Benutzer gesucht werden soll Ist der eingegebene Buchname kein gültiger Buchname Erzeugen einer Fehlermeldung, wenn der Buchname gültig ist, Sucht den Buchnamen in der Datenbank. Get-book - name Print-err - message Such - buch Fehler - meldung Buch - name Good - book - name Buch - details 25 25 Richtlinien für die Erstellung von DFDs Alle Funktionen des Systems müssen im DFD-Modell erfasst werden: Keine Funktion angegeben in Sollte das SRS-Dokument übersehen werden. Es sollten nur die im SRS-Dokument angegebenen Funktionen dargestellt werden: Nehmen Sie keine zusätzliche Funktionalität des vom SRS-Dokument nicht spezifizierten Systems an. 26 26 Gemeinsam gemachte Fehler Unausgeglichene DFDs Vergessen, die Namen der Datenflüsse zu erwähnen Nicht repräsentierte Funktionen oder Daten Externe Einheiten, die auf höheren Ebenen erscheinen DFDs Versuchen, Steueraspekte darzustellen Kontextdiagramm mit mehr als einer Blase Eine Blase, die in zu viele Blasen in der nächsten Ebene zerlegt wird Beendigung der Zerlegung zu früh Nomen, die bei der Namensgebung von Blasen verwendet werden 27 27 Defizite des DFD-Modells DFD-Modelle leiden unter mehreren Mängeln: DFDs lassen reichlich Spielraum, um ungenau zu sein. In einem DFD-Modell, schlussfolgern wir über die Funktion von einer Blase aus seinem Label durchgeführt. Ein Label kann nicht alle Funktionen einer Blase erfassen. 28 28 Defizite des DFD-Modells Eine Blase namens find-book-position hat beispielsweise nur intuitive Bedeutung: Legt nicht mehrere Dinge fest: Was passiert, wenn einige Input-Informationen fehlen oder nicht korrekt sind. Vermittelt nichts darüber, was passiert, wenn Buch nicht gefunden wird oder was passiert, wenn es Bücher von verschiedenen Autoren mit dem gleichen Buchtitel gibt. 29 29 Unzulänglichkeiten der DFD-Modellsteuerinformation ist nicht dargestellt: Beispielsweise wird die Reihenfolge, in der die Eingänge verbraucht und die Ausgänge erzeugt werden, nicht angegeben. Accept - order Process - Order Kunden-File Item-File Kundenhistorie Accepted - Bestellen Inventar bestellen 30 30 Defragmentierung des DFD-Modells Ein DFD gibt keine Synchronisationsaspekte an: Beispielsweise spezifiziert das DFD im TAS-Beispiel nicht: Kann der Auftrag warten, bis die Annahme-Bestellung Daten erzeugt. Ob Annahme-Bestellung und Handle-Reihenfolge gleichzeitig mit einigen Puffermechanismen zwischen ihnen erfolgen können. 31 31 TAS: Level 1 DFD Akzeptieren - order Prozess - bestellung Handle - indent - anfrage Hand - habung anhängig Verkaufsstatistiken Inventur Kreditorenliste Kundendatei Objektdatei Kundenhistorie Einrückung Einrückungen Akzeptiert - Bestellstatistiken bestellen 32 32 Defizite des DFD-Modells Die Art und Weise, wie die Zersetzung durchgeführt wird, um die aufeinanderfolgenden Ebenen eines DFD zu erreichen, ist subjektiv. Der letzte Grad, zu dem die Zersetzung durchgeführt wird, ist subjektiv: Abhängig von der Wahl und Beurteilung des Analytikers. Auch für das gleiche Problem sind mehrere alternative DFD-Darstellungen möglich: Oft ist es nicht möglich zu sagen, welche DFD-Darstellung überlegen oder vorzuziehen ist. 33 33 Mängel der DFD-Modell-DFD-Technik gibt es nicht: Jede klare Anleitung, wie genau eine Zerlegung einer Funktion gehen sollte: Man muss subjektives Urteil verwenden, um Zersetzung durchzuführen. Strukturierte Analysetechniken geben nicht an, wann ein Zersetzungsprozess gestoppt werden soll: Zu welcher Länge Zerlegung durchgeführt werden soll. 34 34 Erweiterung der DFD-Technik auf Real-Time-Systeme Für Echtzeit-Systeme (Systeme mit zeitlichen Begrenzungen auf ihre Aktionen) Weit akzeptierte Technik: Ward und Mellor Technik. Eine Art von Prozeß (Blasen), der nur Steuerflüsse behandelt, wird eingeführt. Diese Prozesse werden durch gestrichelte Kreise dargestellt. 35 35 Strukturiertes Design Ziel des strukturierten Designs Umwandlung der Ergebnisse einer strukturierten Analyse (d. H. Einer DFD-Darstellung) in ein Strukturdiagramm. Ein Strukturdiagramm stellt die Softwarearchitektur dar: Verschiedene Module, aus denen sich das System zusammensetzt, Modulabhängigkeit (d. H. Welches Modul die anderen Module aufruft), Parameter, die an verschiedene Module übergeben werden. 36 36 Strukturdiagramm Strukturdiagramm Einfache Implementierung über Programmiersprachen. Schwerpunkt eines Strukturplans: Definieren der Modulstruktur einer Software, Interaktion zwischen verschiedenen Modulen, Prozedurale Aspekte (z. B. wie eine bestimmte Funktionalität erreicht wird) werden nicht dargestellt. 37 37 Grundbausteine des Strukturdiagramms Rechteckige Box: Eine rechteckige Box repräsentiert ein Modul. Mit dem Namen des Moduls versehen, das es repräsentiert. Prozess-Reihenfolge 38 38 Pfeile Ein Pfeil zwischen zwei Modulen impliziert: Während der Ausführung wird die Steuerung von einem Modul zum anderen in Richtung des Pfeils geführt. Process-orderHandle-indent root Handle-Abfrage 39 39 Datenfluss-Pfeile Datenfluss-Pfeile repräsentieren: Daten, die von einem Modul zum anderen in Richtung des Pfeils übergehen. Auftragsreihenfolge 40 40 Bibliotheksbausteine Bibliotheksbausteine repräsentieren häufig aufgerufene Module: Ein Rechteck mit doppelten Seitenkanten. Vereinfacht die Zeichnung, wenn ein Modul von mehreren Modulen aufgerufen wird. Quick-sort 41 41 Auswahl Das Diamantsymbol steht für: Ein Modul aus mehreren Modulen, die mit dem Diamantsymbol verbunden sind, wird abhängig von einer Bedingung aufgerufen. Process-orderHandle-indent root Handle-Abfrage 42 42 Repetition Eine Schleife um Kontrollfluss-Pfeile zeigt an, dass die betroffenen Module wiederholt aufgerufen werden. Process-orderHandle-indent root Handle-Abfrage 43 43 Strukturdiagramm Es gibt nur ein Modul an der Oberseite: das Root-Modul. Es gibt höchstens eine Steuerbeziehung zwischen zwei Modulen: Wenn Modul A Modul B aufruft, kann Modul B Modul A nicht aufrufen. Hauptgrund für diese Einschränkung: Überlegen Sie Module in einem Strukturdiagramm, die in Ebenen oder Ebenen angeordnet werden sollen. 44 44 Strukturdiagramm Das Prinzip der Abstraktion: erlaubt es nicht, Module auf höherer Ebene aufzurufen. Aber zwei übergeordnete Module können das gleiche untergeordnete Modul aufrufen. 45 45 Beispielwurzel Get-good-data Berechnungslösung Display-Lösung Get-data Validierungsdaten Gültigkeitszahlen rms 47 47 Mängel des Strukturdiagramms Mit einem Strukturdiagramm können wir nicht sagen, ob ein Modul nur einmal ein anderes Modul aufruft Oder viele Male. Auch können wir anhand eines Strukturdiagramms die Reihenfolge nicht ermitteln, in der die verschiedenen Module aufgerufen werden. 48 48 Flußdiagramm (beiseite) Wir alle kennen die Flußdiagrammdarstellungen: Flußdiagramm ist eine bequeme Technik, um den Fluß der Steuerung in einem System darzustellen. AB, wenn (c 100) P20 sonst p 80 während (p20) Druck (Schülermarke) AB P20P80 Druck ja nein Dummy ja nein 20) Druck (Studentenmarkierung) AB P20P80 Druck ja nein Dummy ja nein 49 49 Flußdiagramm versus Strukturdiagramm A Struktur-Diagramm unterscheidet sich von einem Flussdiagramm in drei Hauptformen: Es ist schwierig, Module einer Software aus ihrer Flußdiagrammdarstellung zu identifizieren. Der Datenaustausch zwischen den Modulen ist in einem Flussdiagramm nicht dargestellt. Die sequentielle Reihenfolge der in einem Flussdiagramm enthaltenen Aufgaben wird in einem Strukturdiagramm unterdrückt. 50 50 Umwandlung eines DFD-Modells in Strukturdiagramm Für die Umwandlung eines DFD in ein Strukturdiagramm gibt es zwei Strategien: Transformationsanalyse Transaktionsanalyse 51 51 Transformationsanalyse Der erste Schritt der Transformationsanalyse: Teilen Sie den DFD in 3 Teile: Eingabe, logische Verarbeitung , Ausgabe. 52 52 Transformationsanalyse Eingabebereich im DFD: Prozesse, die Eingabedaten von physikalischer in logische Form umwandeln. z. B. Zeichen aus dem Terminal lesen und in internen Tabellen oder Listen speichern. Jeder Eingabebereich: ein afferenter Zweig. Möglich, mehr als einen afferenten Zweig in einem DFD zu haben. 53 53 Transformationsanalyse Ausgabeabschnitt eines DFD: transformiert Ausgabedaten von logischer Form in physische Form. z. B. Aus der Liste oder dem Array in Ausgabezeichen. Jeder Ausgabeabschnitt: genannt efferent Zweig. Die verbleibenden Teile einer DFD, die als zentrale Transformation bezeichnet werden 54 54 Transformationsanalyse Ableiten des Strukturdiagramms durch Zeichnen einer funktionalen Komponente für: die zentrale Transformation, jeden afferenten Zweig, jeden efferenten Zweig. 55 55 Transformationsanalyse Identifizieren der höchsten Eingangs - und Ausgangstransformationen: erfordert Erfahrung und Geschick. Einige Richtlinien: Verfolgen Sie die Eingaben, bis eine Blase gefunden wird, deren Ausgang nicht allein von den Eingängen abgeleitet werden kann. Prozesse, die die Eingabe validieren, sind keine zentralen Transformationen. Prozesse, die Eingangs - oder Filterdaten sortieren, sind. 56 56 Transformationsanalyse Erste Ebene des Strukturdiagramms: Zeichnen Sie eine Box für jede Eingabe - und Ausgabeeinheit Eine Box für die zentrale Transformation. Als nächstes verfeinern Sie das Strukturdiagramm: Addieren Sie Unterfunktionen, die von jedem High-Level-Modul benötigt werden. Es können mehrere Module erforderlich sein. 57 57 Factoring Der Prozess der Unterbrechung von Funktionskomponenten in Unterkomponenten. Factoring beinhaltet das Hinzufügen: Lesen und Schreiben von Modulen, Fehlerbehandlungsmodule, Initialisierungs - und Terminierungsmodule usw. Endgültig überprüfen: Ob alle Blasen auf Module abgebildet sind. 58 58 Beispiel 1: RMS-Berechnungssoftware Berechnen-RMS 0 Benutzerdatenfelder Ergebnis Kontextdiagramm 59 59 Beispiel 1: RMS-Berechnungssoftware Aus einer flüchtigen Analyse der Problembeschreibung lässt sich leicht erkennen, dass das System ausführen muss: Akzeptieren Sie die Eingabedaten Vom Benutzer bestätigen, die Zahlen berechnen, das Wurzelquadrat der eingegebenen Zahlen berechnen, das Ergebnis anzeigen. 60 60 Beispiel 1: RMS-Berechnungssoftware Datenfel - der Ergebnis Read-Zahlen 0.1 Validierungs - zahlen 0.2 Rechen - werte 0.3 Anzeige 0.4 RMS-Nummern Valid-Number-Fehler 61 61 Beispiel 1: RMS-Berechnungssoftware Durch Betrachten des Level 1 DFD: Anzahl und Validierungszahl Blasen als afferent Zweig Anzeige als efferent Zweig. 62 62 Beispiel 1: RMS-Berechnungssoftware root Get-good-data Berechnungslösung Display-Lösung Get-data Validate-Daten Gültige Zahlen rms 63 63 Beispiel 2: Tic-Tac-Toe Computerspiel Sobald der Mensch Spieler ist Oder der Computer gewinnt, sollte eine Nachricht gratulieren den Sieger angezeigt werden. Wenn kein Spieler gelingt, drei aufeinander folgende Markierungen entlang einer geraden Linie zu erhalten, Und alle Quadrate auf dem Brett werden oben gefüllt, Dann wird das Spiel gezeichnet. Der Computer versucht immer, ein Spiel zu gewinnen. 65 65 Level 1 DFD-Karte Anzeigetafel Check - Sieger Validieren - verschieben Spiel - verschieben Ergebnis bewegen 66 66 Struktur Diagramm Wurzel Get-good-moveCompute-gameDisplay Get-move Validieren - Verschieben des Play-Movs Check-Gewinner 67 67 Transaktionsanalyse Nützlich Zum Entwerfen von Transaktionsverarbeitungsprogrammen. Transform-zentrierte Systeme: Gekennzeichnet durch ähnliche Verarbeitungsschritte für jedes Datenelement, das von Input-, Prozess - und Outputbubbles verarbeitet wird. Transaktionsgetriebene Systeme, Einer von mehreren möglichen Pfaden durch den DFD wird abhängig vom Eingangsdatenwert durchlaufen. 68 68 Transaktionsanalyse Transaktion: Beliebiger Eingabedatenwert, der eine Aktion auslöst: Beispielsweise können ausgewählte Menüoptionen verschiedene Funktionen auslösen. Repräsentiert durch ein Tag, das seinen Typ identifiziert. Die Transaktionsanalyse verwendet dieses Tag zur Unterteilung des Systems in: Mehrere Transaktionsmodule Ein Transaktionszentrummodul. 69 69 Transaktionsanalyse Transaktionszentrum trans 1 trans 2 trans 3 Typ 1 Typ 2 Typ 3 70 70 Ebene 1 DFD für TAS Auftragsannahme Prozessauftrag Handle - indent - Anforderung Hand - lung anhängig Verkaufsstatistik Inventur Lieferantenliste Kunden - Datei Artikeldatei Kundenhistorie Einrückung Einrückungen Auftragseingänge Auftragsstatistik 71 71 Struktur Diagrammwurzel Handle-orderHandle-indentHandle-Abfrage Get-order Accept-orderProcess - order order query indent 72 72 Zusammenfassung Als erstes diskutierten wir eine strukturierte Analyse von a Größeres Problem. Wir haben einige allgemeine Richtlinien für den Aufbau eines zufriedenstellenden DFD-Modells definiert. Die DFD-Modell zwar einfach und nützlich hat einige kurze Kommen. Wir begannen dann, strukturiertes Design zu diskutieren. 73 73 Zusammenfassung Ziel des strukturierten Designs: Umwandlung einer DFD-Darstellung in ein Strukturdiagramm. Strukturdiagramm: Modulstruktur Interaktion zwischen verschiedenen Modulen, Prozedurale Aspekte werden nicht dargestellt. 74 74 Zusammenfassung Das strukturelle Design bietet zwei Strategien zur Umwandlung eines DFD in ein Strukturdiagramm: Transformationsanalyse Transaktionsanalyse 75 75 Zusammenfassung Wir diskutierten drei Beispiele für strukturiertes Design. Es braucht viel Übung, um ein guter Software-Designer zu werden: Bitte versuchen Sie, alle Probleme, die in Ihrem Zuordnungsblatt aufgelistet sind, zu lösen. Nicht nur die, die Sie einreichen müssen. Funktionsorientiertes Software-Design (Fortsetzung): Vortrag 6 Dr. R Mall 2 Organisation dieser Vorlesung zBragen Überprüfung der bisherigen Vorlesungen zA größeres Beispiel der Strukturierten Analyse zStrukturiertes Design yEin Hauptziel dieser Vorlesung ist, dass Sie in der Lage sein sollten, strukturiertes Design aus jedem DFD-Modell zu entwickeln. ZExamples zSummary 3 Review der letzten Vorlesung zLast-Vortrag Wir begannen die Diskussion über die strukturierte Analyse (SASD) - Technik: yincorporates-Features aus einigen wichtigen Design-Methoden. ZSASD besteht aus zwei wichtigen Teilen: ystructured Analyse ystructured Design. 4 Rückblick auf die letzte Vorlesung zDas Ziel der strukturierten Analyse: yperform funktionale Zersetzung. Die mit Datenflussdiagrammen (DFDs) verwendet werden. ZDFDs sind ein hierarchisches Modell: yWe untersucht, warum jedes hierarchische Modell ist leicht zu verstehen ynumber 7 heißt die magische Zahl. 5 Rückblick auf die letzte Vorlesung zDuring Strukturierte Analyse: yFunktionelle Zerlegung erfolgt yin Zusatz, Datenzerlegung findet statt. ZAt die abstrakteste Ebene: ycontext Diagramm yrefined zu detaillierteren Ebenen. ZWe diskutierten zwei kleine Beispiele: yRMS Berechnungssoftware ytic-tac-toe Computerspielsoftware 6 Rückblick auf die letzte Vorlesung zSeveral CASE-Tools stehen zur Verfügung yhelp in Design-Aktivitäten: yhelp pflegen das Daten-Wörterbuch, ycheck, ob DFDs ausgeglichen sind, etc. zDFD-Modell: ydifficult Zu implementieren mit einer Programmiersprache: Yneeds, um in strukturierte Design umgewandelt werden. 7 Beispiel 3: Handelshaus-Automatisierungssystem (TAS) zA Großes Handelshaus will, dass wir eine Software entwickeln: yto automatisieren Buchhaltung Aktivitäten im Zusammenhang mit seinem Geschäft. ZIt hat viele Stammkunden: ywho Ort Bestellungen für verschiedene Arten von Rohstoffen. 8 Beispiel 3: Handelshaus-Automatisierungssystem (TAS) Das Handelshaus unterhält Namen und Adressen seiner Stammkunden. Jeder Kunde erhält eine eindeutige Kundennummer (CIN). ZAs pro laufenden Praxis, wenn ein Kunde einen Auftrag erteilt: Die Buchhaltung überprüft zunächst die Kreditwürdigkeit des Kunden. 9 Beispiel: Trading-House Automation System (TAS) zDie Kreditwürdigkeit eines Kunden wird bestimmt durch die Analyse der Geschichte seiner Zahlungen an die Rechnungen, die ihm in der Vergangenheit gesendet wurden. ZIf ein Kunde ist nicht kreditwürdig: yhis Aufträge werden nicht weiter verarbeitet yan entsprechende Auftrag Ablehnung Nachricht für den Kunden generiert wird. 10 Beispiel: Handelshaus-Automatisierungssystem (TAS) zIf ein Kunde ist kreditwürdig: yitems heshe bestellt werden, werden mit der Liste der Artikel verglichen, mit denen sich das Handelshaus befasst. ZDie Elemente, die das Handelshaus nicht behandelt: yare nicht weiter verarbeitet yan entsprechende Nachricht für den Kunden für diese Elemente erzeugt wird. 11 Beispiel: Handelshaus-Automatisierungssystem (TAS) zDie Positionen eines Kundenauftrags, die das Handelshaus behandelt: y werden auf Verfügbarkeit im Inventar geprüft. ZIst die Positionen im Bestandsverzeichnis in den gewünschten Mengen zur Verfügung stehen: ya Rechnung mit der Weiterleitungsadresse des Kunden wird ausgedruckt. Ya Material Ausgabedruck wird gedruckt. 12 Beispiel: Handelshaus-Automatisierungssystem (TAS) z Der Kunde kann die Materialausgabe im Lagerhaus produzieren: Lieferung der Artikel. Yinventory Daten angepasst, um den Verkauf an den Kunden widerzuspiegeln. 13 Beispiel: Handelshaus-Automatisierungssystem (TAS) zIst eine bestellte Position im Inventar nicht in ausreichender Menge zur Verfügung: um die ausstehenden Bestellungen in einer Auftragsdatei zu erfassen. Xout-of-stock items zusammen mit der bestellten Menge. Xcustomer Identifikationsnummer 14 Beispiel: Trading-House Automation System (TAS) zDie Einkaufsabteilung: In regelmäßigen Abständen werden Befehle zum Erzeugen von Einrückungen ausgegeben. ZBei der Erstellung des Befehls "Einrückungen" wird Folgendes ausgegeben: Das System sollte die Datei "Ausstehende Aufträge" untersuchen, um festzustellen, welche Aufträge für die einzelnen Elemente anhängig sind. Beispiel: Das Handelshaus-Automatisierungssystem (TAS) zTAS sollte die Adressen der Lieferanten, die die benötigten Positionen liefern, herausfinden: yexamine die Datei, die die Lieferantendetails enthält (ihre Adresse, Artikel, die sie liefern usw.) 16 Beispiel: Trading-House Automation System (TAS) zTAS sollte auch beantworten Management-Abfragen: ystatistics der verschiedenen Posten verkauft über einen bestimmten Zeitraum ycorresponding Menge verkauft und der Preis realisiert. 17 Kontextdiagramm Trading-House - Automation - System 0 Manager CustomerPurchase - Abfrage - statistik Auftrags - antwort Generating - indent indent 18 Level 1 DFD Accept - order 0.1 Prozess - order 0.2 Handle - indent - request 0.4 Hand - ling 0.3 auftrags - Statistik Inventar Kreditorenliste Kundendatei Objektdatei Kundenhistorie Einzugsermittlung Einzugsermittlung Akzeptierte Auftragsanfragen Abfragestatistik Order Material-Issue-Slip-Rechnung 19 Beispiel: Data Dictionary ZAntwort: rechnung material-issue-slip, reject-message zquery: period Abfrage vom Manager in Bezug auf Verkaufsstatistiken zperiod: datedate, month, year, day zdate: Jahr Monat Tag zyear: integer zmonth: integer zday: integer zorder: Kunden-ID zaccepted-order: Bestellen der bestellten Artikel im Inventar zreject-message: order message Beispiel: Data Dictionary zitem-name: string zhouse: string zstreet: string zcity: string zpin: integer zcustomer-id: integer zbill: Gesamtzahl der Kundenadresse z Material - Ausgabeschlüssel: Meldungsteilmenge Kunden - adresse zmessage: string zstatistics: zsales-Statistik: zquantity: integer 21 Beobachtung zBei den Beispielen, yobserve, die DFDs erzeugen: xdata modell xfunktionsmodell 22 Beobachtung zAs wird ein DFD in größere Ebenen verfeinert Detail: Der Analytiker führt eine implizite funktionale Zerlegung durch. Gleichzeitig findet eine Verfeinerung der Daten statt. 23 Richtlinien für die Konstruktion von DFDs zContext-Diagramm sollte das System als eine einzige Blase darstellen: yDie Anfänger begehen den Fehler, mehr als eine Blase im Kontextdiagramm zu zeichnen. 24 Leitfaden für den Aufbau von DFDs zAll externe Entitäten sollten im Kontextdiagramm dargestellt werden: jene Einheiten sollten nicht auf einer anderen Ebene von DFD erscheinen. ZOnly 3 bis 7 Blasen pro Diagramm sollte erlaubt werden: yeach Blase sollte auf zwischen 3 und 7 Blasen zerlegt werden. 25 Richtlinien für den Aufbau von DFDs zA häufiger Fehler, den viele Anfänger begehen: Sie versuchen, Kontrollinformationen in einer DFD darzustellen. D. h. Um die Reihenfolge darzustellen, in der verschiedene Funktionen ausgeführt werden. 26 Richtlinien für den Aufbau von DFDs zA DFD stellt keine Steuerinformationen dar: ywhen oder in welcher Reihenfolge unterschiedliche Funktionen (Prozesse) aufgerufen werden, die Bedingungen, unter denen verschiedene Funktionen aufgerufen werden, werden nicht dargestellt. Y Beispielsweise könnte eine Funktion je nach Bedingung eine oder mehrere Funktionen aufrufen. Viele Anfänger versuchen, diesen Aspekt darzustellen, indem sie einen Pfeil zwischen den entsprechenden Blasen zeichnen. 27 Beispiel-1 zCheck der Eingangswert: YIF der Eingangswert kleiner oder größer ist als eine Fehlermeldung generiert yotherwise für die Nummer Chec k taub er suchen Gener ate h Nummer Meldungsnummer Fehler Searc gefunden, 28 Richtlinien nicht gefunden Für DFDs Constructing zWenn eine Blase A entweder Blase B oder Blase C abhängig von bestimmten Bedingungen ruft: die Daten yrepresent, die Blase B von Blase A fließt und Blasen A bis C in Abhängigkeit der Bedingungen ynot, auf dem ein Prozess aufgerufen wird. 29 Beispiel-2 Die zA-Funktion akzeptiert den zu durchsuchenden Buchnamen vom Benutzer. ZIst der eingegebene Buchname kein gültiger Buchname y erzeugt eine Fehlermeldung, zIf der Buchname gültig ist, y den Buchnamen in der Datenbank durchsuchen. Get-Book-Name Print-Err - Nachricht Search - Buch Error - Nachricht Buch-Name Good-Book-Name Buch-Details 30 Richtlinien für DFDs Zäll Funktionen des Systems Konstruktion muss im DFD-Modell erfasst werden: yno Funktion in der angegebenen SRS-Dokument sollte übersehen werden. ZOnly sollten die im SRS-Dokument spezifizierten Funktionen dargestellt werden: ydo nehme keine zusätzliche Funktionalität des Systems an, die nicht durch das SRS-Dokument spezifiziert ist. 31 Häufig gemacht Fehler zUnbalanced DFDs zForgetting die Namen der Datenflüsse zUnrepresented Funktionen oder Daten zExternal Einheiten erscheinen auf einer höheren Ebene DFDs zTrying zu erwähnen Kontrollaspekte zContext Diagramm darstellen mehr als eine Blase zA Blase in zu viele Blasen in der nächsten Ebene zTerminating zerlegt haben Zerlegung zu früh ZNouns bei der Benennung von Blasen 32 Defizite des DFD-Modells zDFD-Modelle leiden unter mehreren Mängeln: zDFDs lassen reichlich Spielraum, um ungenau zu sein. YIn einem DFD-Modell, schlussfolgern wir über die Funktion von einer Blase aus seinem Label durchgeführt. YA-Label kann nicht alle Funktionen einer Blase erfassen. 33 Unzulänglichkeiten des DFD-Modells Beispielsweise hat eine Blase namens find-book-position nur intuitive Bedeutung: ywird nicht mehrere Dinge angeben: xwas passiert, wenn einige Input-Informationen fehlen oder nicht korrekt sind. XDoes vermitteln nichts darüber, was passiert, wenn das Buch nicht gefunden wird, oder was passiert, wenn es Bücher von verschiedenen Autoren mit dem gleichen Buchtitel gibt. 34 Unzulänglichkeiten des DFD-Modells zControl-Informationen werden nicht dargestellt: yDie Reihenfolge, in der Eingaben verbraucht und Ausgänge erzeugt werden, ist nicht spezifiziert. Accept bestellen Process - bestellen Kundendatei Artikel-Datei Kunden Geschichte Akzeptierte-Bestellungen Inventar 35 Mängel des DFD Modell zA DFD bestellen keine Synchronisation Aspekte angeben: yFor Beispiel die DFD in TAS Beispiel nicht festgelegt: xwhether Prozess Ordnung Kann warten, bis die Annahme-Reihenfolge Daten erzeugt, obwohl Annahme-Reihenfolge und Handle-Reihenfolge gleichzeitig mit einem Puffermechanismus zwischen ihnen vor sich gehen können. 36 TAS: Stufe 1 DFD Accept bestellen Process - bestellen Handle - indent - Anfrage Handle - Abfrage anstehenden Ordnung Verkaufsstatistik Inventar Vendor-Liste Kunden-Datei Artikel-Datei Kunden Geschichte einrücken-Anfrage Einzüge Akzeptierte-Bestellungen Abfragestatistiken 37 bestellen Defizite des DFD-Modells Die Art und Weise, wie die Zersetzung durchgeführt wird, um auf den aufeinanderfolgenden Ebenen eines DFD zu kommen, ist subjektiv. Z Der letzte Grad, zu dem die Zersetzung durchgeführt wird, ist subjektiv: hängt von der Wahl und Beurteilung des Analytikers ab. Für das gleiche Problem sind mehrere alternative DFD-Darstellungen möglich: Manchmal ist es nicht möglich zu sagen, welche DFD-Darstellung überlegen oder vorzuziehen ist. 38 Unzulänglichkeiten des DFD-Modells Die zDFD-Technik bietet nicht: eine eindeutige Anleitung, wie genau eine Zerlegung einer Funktion gehen soll: yone muss das subjektive Urteil zur Zersetzung verwenden. ZStrukturierte Analysetechniken geben nicht an, wann ein Zerlegungsprozess gestoppt werden soll: yto, zu welcher Länge Zerlegung durchgeführt werden soll. 39 Erweiterung der DFD-Technik auf Real-Time-Systeme zF für Echtzeitsysteme (Systeme mit zeitlichen Begrenzungen ihrer Aktionen) YWidely akzeptierte Technik: Ward und Mellor Technik. Es wird ein Typ von Prozeß (Blasen) eingeführt, der nur Steuerflüsse behandelt. XDiese Prozesse werden durch gestrichelte Kreise dargestellt. 40 Strukturiertes Design z Das Ziel des strukturierten Designs ist es, die Ergebnisse einer strukturierten Analyse (d. H. Einer DFD-Darstellung) in ein Strukturdiagramm umzuwandeln. ZA-Strukturdiagramm stellt die Softwarearchitektur dar: yvarious Module, die das System bilden, y Modulabhängigkeit (d. h. welches Modul die anderen Module aufruft), yparameters, die zwischen verschiedenen Modulen geführt werden. 41 Strukturdiagramm zStrukturdiagrammdarstellung mit Programmiersprachen realisierbar. ZMain-Fokus eines Strukturdiagramms: ydefine die Modulstruktur einer Software, yinteraction zwischen verschiedenen Modulen, yprocedural Aspekte (z. B. wie eine bestimmte Funktionalität erreicht wird) nicht dargestellt werden. 42 Grundbausteine des Strukturdiagramms zRectangular box: y Eine rechteckige Box repräsentiert ein Modul. Yannotated mit dem Namen des Moduls, das es darstellt. Prozessreihenfolge 43 Pfeile zAn Pfeil zwischen zwei Modulen impliziert: Die Ausführungssteuerung wird von einem Modul zum anderen in Richtung des Pfeils geführt. Process-orderHandle-indent root Handle-Abfrage 44 Datenfluss-Pfeile zData-Flusspfeile repräsentieren: ydata, die von einem Modul zum anderen in Richtung des Pfeils übergehen. Prozessreihenfolge 45 Bibliotheksmodule zLibrary-Module repräsentieren häufig aufgerufene Module: y ein Rechteck mit doppelten Seitenkanten. Y Vereinfacht die Zeichnung, wenn ein Modul von mehreren Modulen aufgerufen wird. Quick-sort 46 Selection zThe diamond symbol represents: yone module of several modules connected to the diamond symbol is invoked depending on some condition. Process-orderHandle-indent root Handle-query 47 Repetition zA loop around control flow arrows denotes that the concerned modules are invoked repeatedly. Process-orderHandle-indent root Handle-query 48 Structure Chart zThere is only one module at the top: ythe root module. zThere is at most one control relationship between any two modules: yif module A invokes module B, ymodule B cannot invoke module A. zThe main reason behind this restriction: yconsider modules in a structure chart to be arranged in layers or levels. 49 Structure Chart zThe principle of abstraction: ydoes not allow lower-level modules to invoke higher - level modules: yBut, two higher-level modules can invoke the same lower-level module. 50 Example root Get-good-dataCompute-solutionDisplay-solution Get-data Validate-data Valid-numbers rms 52 Shortcomings of Structure Chart zBy looking at a structure chart: ywe can not say whether a module calls another module just once or many times. zAlso, by looking at a structure chart: ywe can not tell the order in which the different modules are invoked. 53 Flow Chart (Aside) zWe are all familiar with the flow chart representations: yFlow chart is a convenient technique to represent the flow of control in a system. zAB zif(c 100) z P20 zelse p 80 zwhile(p20) z print(student mark) AB P20P80 Print yes no dummy yes no 20) z print(student mark) AB P20P80 Print yes no dummy yes no 54 Flow Chart versus Structure Chart zA structure chart differs from a flow chart in three principal ways: yIt is difficult to identify modules of a software from its flow chart representation. yData interchange among the modules is not represented in a flow chart. ySequential ordering of tasks inherent in a flow chart is suppressed in a structure chart. 55 Transformation of a DFD Model into Structure Chart zTwo strategies exist to guide transformation of a DFD into a structure chart: yTransform Analysis yTransaction Analysis 56 Transform Analysis zThe first step in transform analysis: ydivide the DFD into 3 types of parts: xinput, xlogical processing, xoutput. 57 Transform Analysis zInput portion in the DFD: yprocesses which convert input data from physical to logical form. ye. g. read characters from the terminal and store in internal tables or lists. zEach input portion: ycalled an afferent branch. yPossible to have more than one afferent branch in a DFD. 58 Transform Analysis zOutput portion of a DFD: ytransforms output data from logical form to physical form. xe. g. from list or array into output characters. yEach output portion: xcalled an efferent branch. zThe remaining portions of a DFD ycalled central transform 59 Transform Analysis zDerive structure chart by drawing one functional component for: ythe central transform, yeach afferent branch, yeach efferent branch. 60 Transform Analysis zIdentifying the highest level input and output transforms: yrequires experience and skill. zSome guidelines: ytrace the inputs until a bubble is found whose output cannot be deduced from the inputs alone. yProcesses which validate input are not central transforms. yProcesses which sort input or filter data from it are. 61 Transform Analysis zFirst level of structure chart: ydraw a box for each input and output units ya box for the central transform. zNext, refine the structure chart: yadd subfunctions required by each high-level module. yMany levels of modules may required to be added. 62 Factoring zThe process of breaking functional components into subcomponents. zFactoring includes adding: yread and write modules, yerror-handling modules, yinitialization and termination modules, etc. zFinally check: ywhether all bubbles have been mapped to modules. 63 Example 1: RMS Calculating Software Compute - RMS 0 User Data - items result Context Diagram 64 Example 1: RMS Calculating Software zFrom a cursory analysis of the problem description, yeasy to see that the system needs to perform: xaccept the input numbers from the user, xvalidate the numbers, xcalculate the root mean square of the input numbers, xdisplay the result. 65 Example 1: RMS Calculating Software Data - items result Read - numbers 0.1 Validate - numbers 0.2 Compute - rms 0.3 Display 0.4 RMS numbers Valid - numbers error 66 Example 1: RMS Calculating Software zBy observing the level 1 DFD: yidentify read-number and validate-number bubbles as the afferent branch ydisplay as the efferent branch. 67 Example 1: RMS Calculating Software root Get-good-dataCompute-solutionDisplay-solution Get-data Validate-data Valid-numbers rms 68 Example 2: Tic-Tac-Toe Computer Game zAs soon as either of the human player or the computer wins, ya message congratulating the winner should be displayed. zIf neither player manages to get three consecutive marks along a straight line, yand all the squares on the board are filled up, ythen the game is drawn. zThe computer always tries to win a game. 70 Level 1 DFD board Display - board Check - winner Validate - move Play - move move result game 71 Structure Chart root Get-good-moveCompute-gameDisplay Get-move Validate - move play-move Check - winner 72 Transaction Analysis zUseful for designing transaction processing programs. yTransform-centered systems: xcharacterized by similar processing steps for every data item processed by input, process, and output bubbles. yTransaction-driven systems, xone of several possible paths through the DFD is traversed depending upon the input data value. 73 Transaction Analysis zTransaction: yany input data value that triggers an action: yFor example, selected menu options might trigger different functions. yRepresented by a tag identifying its type. zTransaction analysis uses this tag to divide the system into: yseveral transaction modules yone transaction-center module. 74 Transaction analysis Transaction - center trans 1 trans 2 trans 3 type 1type 2type 3 75 Level 1 DFD for TAS Accept - order Process - order Handle - indent - request Handle - query pending-order Sales-statistics inventory Vendor-list Customer-file Item-file Customer-history Indent-request Indents Accepted-orders query order statistics 76 Structure Chart root Handle-orderHandle-indentHandle-query Get-order Accept-orderProcess - order order query indent 77 Summary zWe first discussed structured analysis of a larger problem. zWe defined some general guidelines yfor constructing a satisfactory DFD model. zThe DFD model though simple and useful ydoes have several short comings. zWe then started discussing structured design. 78 Summary zAim of structured design: ytransform a DFD representation into a structure chart. zStructure chart represents: ymodule structure yinteraction among different modules, yprocedural aspects are not represented. 79 Summary zStructured design provides two strategies to transform a DFD into a structure chart: yTransform Analysis yTransaction Analysis 80 Summary zWe Discussed three examples of structured design. zIt takes a lot of practice to become a good software designer: yPlease try to solve all the problems listed in your assignment sheet, y not only the ones you are expected to submit.
No comments:
Post a Comment