|
6.1 Einleitung
Das Datenflußdiagramm zeigt die Prozesse und den Fluß der Daten durch diese Prozesse.
Es gibt verschiedene Möglichkeiten es einzusetzen, von schwierigen Geschäftsbeziehungen bishin zu Softwareprogrammabläufen oder gar nur einzelner Unterprogramme.
Man bezeichnet ein Datenflußdiagramm auch als erste Stufe eines strukturierten Softwaredesigns, da es den gesamten Datenfluß durch das System bzw. Programm zeigt.
Es ist in erster Linie ein System-Analyse-Werkzeug, welches man für die Darstellung der Grundbestandteile und den Datenfluß durch diese benötigt.
6.2 Definition und Komponenten eines Datenflußdiagramm
Bestandteile eines Datenflußdiagramm (4 Grundkomponenten):
1) Datenfluß:
Pfeil mit Name darüber, zeigt den Datenfluß durch das System
2) Prozeß:
Abgerundetes Rechteck mit Namen des Prozesses (sprechender Name!)
Keine andere Information über den Prozeß in Datenflußdiagramm
3) Data Store:
Name zwischen zwei waagrechten Strichen, repräsentiert ein lokales File in das entweder Daten eingelesen werden, oder von dem Daten gelesen werden.
4) Terminator:
Rechteck mit Namen, gibt die Herkunft (Source) bzw. den Empfänger (Sink) der Daten an. Doch sie werden meistens nicht in die Datenflußdiagramme eingezeichnet.
Auf der Folie sehen wir ein Beispiel eines Datenflußdiagrammes für den Ablauf einer Kundenbestellung.
Zur Folie:
Wenn ein Auftrag einlangt, wird der Kunde überprüft (Existenz, Kontostand, ...).
Nun werden alle Produkte auf der Bestellung überprüft, ob sie verfügbar oder lieferbar sind. Treten hier Unzulänglichkeiten auf, wird ein Lieferrückstand erzeugt. Schlußendlich wird eine Bestellung erzeugt und der Kundenauftrag mit dem Lieferdatum versehen.
Ein Datenflußdiagramm zeigt den Datenfluß in einem konkreten Prozeß, der wieder aus mehreren Unterprozessen besteht, die man wieder in eigene Datenflußdiagramme zerlegen kann.
So kann man ein System bis in die tiefsten Ebenen zerlegen. Also ein Datenflußdiagramm gibt uns keine Detaile über den Datenfluß in den Unterprozessen die nur als abgerundetes Kästchen dargestellt werden, doch dies kann man wieder zerlegen und so mehr über den Datenfluß erfahren.
Aber wie genau soll man ein System zersplitten?
Man soll so weit zersplitten, bis ein Prozeß durch Worte auf einer Seite vollständig beschrieben werden kann, ohne das Informationen verloren gehen.
Auch in einem Datenflußdiagramm sollte man Einschränkungen treffen, es sollten nie mehr als 12 Prozesse dargestellt werden, da es sehr schwer zu lesen wird und die gewünschte Übersichtlichkeit verloren geht. Die ideale Anzahl wären 6-7 Prozesse.
6.3 Prozeßspezifikation
Wenn ein Datenflußdiagramm während der Strukturanalyse entwickelt wird, entwickelt man auch eine Prozeßspezifikation um zusätzliche Information über das System unterzubringen.
Sie definiert wie die Daten in und aus dem Prozeß fließen und was für Operationen mit ihnen durchgeführt werden.
Eine Variante ist eine Aktionsliste, die ähnlich einem Programm aufgebaut ist.
Data dictionary AUSLASSEN
Gane and Sarson AUSLASSEN
6.4 Schlußkommentar
Ein Datenflußdiagramm ist ein sehr wertvolles Werkzeug für die Prüfung des Dokumenten- bzw. Datenflusses in komplizierten Systemen. Es gibt jedoch auch viele Fälle, wo ein Datenflußdiagramm falsch eingesetzt wird bzw. immer wieder Fehler auftreten, besonders bei Querverbindungen (Cross-Checking), da der Input und der Output eines Datenflußdiagrammes oft inkonsistent ist. Und ist das Programm einmal geschrieben, so ist es sehr umständlich, die Fehler auszubessern. Doch heute gibt es schon die Möglichkeit ein Datenflußdiagramm mit dem Computer zu erstellen, der das System auf Inkonsistenz überprüft.
6.5 Control Flow Model
Im Gegensatz zum Datenflußdiagramm hat man beim Control Flow Model die Möglichkeit den Datenfluß ereignisorientiert zu gestalten.
Ereignisse sind wie Boolean Variablen (true or false), oder ein konkretes Ereignis (leer, verstopft, voll).
6.6 Funktionale Dekomposition
Funktionale Dekomposition ist eine Strategie, Probleme in Unterprobleme (Sub-Components) zu zerstreuen. Diese Unterprobleme werden wieder in Unterprobleme, also in Unter-Unterprobleme (Sub-Sub-Components), zerlegt. Dies wird solange fortgesetzt bis das unterste Level der Detailierung erreicht wurde.
Konkretes Beispiel:
Lies eine Serie von Spannungen ein und bilde das Maximum, Minimum und den Durchschnitt.
Da die ersten zwei Punkte schon auf der niedrigsten Stufe sind, können sie nicht mehr in noch einfachere Bestandteile zerlegt werden.
Somit kann man nur mehr den Durchschnittswert noch weiter zerlegen.
Das ergibt folgendes Design:
einlesen einer Serie von Spannungen
errechne das Max
errechne das Min
errechne die Summe
dividiere die Summe durch die Zahl der eingelesenen Spannungen.
Am Ende werden die einzelnen Teillösungen der Teilprobleme wieder zu einem Gesamtproblem und somit auch zu einer Gesamtlösung zusammen gefügt.
Beispiel:
6.7 Abschlußbeispiel
Dies soll die Beziehung zwischen ERD, CDUR-Matrix, Funktionale Dekomposition und
dem Datenflußdiagramm zeigen.
6.8 Ergänzung
Datenseite Prozeßseite
mit welchen Daten was macht man mit den Daten
ERD (Entity-Relationship-Diagramm) DfD (Datenflußdiagramm)
Dekomposition
|
