Datenflußdiagramme

Datenflußdiagramme sind Modellerstellungswerkzeuge die es erleichtern, das System als Netzwerk funktioneller Prozesse darzustellen. Die Prozesse sind mit Leitungen und Speichern verbunden. Es gibt verschiedene Synonyme für Datenflußdiagramme: Bubble chart, DFD, Bubblediagramm, Prozeßmodell, Arbeitsflußdiagramm, Funktionsmodell. Das DFD wird eingesetzt wenn die Funktion des Systems wichtiger und komplizierter ist als die Daten die darin verwaltet werden. DFD’s wurden zuerst in der Softwaretechnik verwendet und werden mittlerweile auch zur Darstellung anderer Dinge verwendet, wie z.B. zur strategischen Planung und Betriebsplanung oder einfach nur um Unternehmen darzustellen.

1 Komponenten

Zunächst sind drei wichtige Dinge zu beachten beim erstellen eines DFD’s, nämlich erstens, dass das DFD unkompliziert und seine Notation (Darstellung von Informationen durch Symbole) offensichtlich ist, d.h. das ein ahnungsloser Benutzer das DFD auf den ersten Blick versteht. Zweitens, ein DFD soll auf eine Seite passen, damit es den Leser nicht auf den ersten Blick erschlägt. Drittens sollte das DFD mit dem Computer gezeichnet werden, da die Linien sauberer wirken und da sich die Ausbesserung von Fehler einfacher gestaltet.

1.1 Der Prozeß

Dies ist die erste Komponente des DFD welche wir erklären. Sie wird auch als Blase, Bubble, Funktion oder Transformation bezeichnet. Der Prozeß wird im DFD meist als Kreis dargestellt, kann aber auch als Rechteck oder oval dargestellt werden. Man muss dabei beachten das man in einem DFD nur eine Form des Prozesses verwendet. Siehe Abb. A.1. Ein Prozeß wird mit einem Wort, Begriff oder einem einfachen Satz beschrieben. Ein guter Name besteht normalerweise aus einem Verb - Objekt - Begriff z.B.: "berechne Steuersatz". Die Vergabe der Namen wird etwas später noch näher behandelt. Einem Prozeß wird manchmal der Namen einer Person oder eines Geräts, zugewiesen, d.h. er beschreibt manchmal, wer oder was den Prozeß ausführt und nicht was er eigentlich macht.

1.2 Der Fluß

Flüsse werde durch Pfeile dargestellt und repräsentieren die Bewegung der Daten von einem Teil des Systems zum anderen, im Gegensatz zu Speichern die ruhende Daten repräsentieren. Siehe Abb. A.2. Meist stellt ein Fluß tatsächlich einen Datenstrom dar, d.h. das reell Daten durch Bits, Zeichen etc. übertragen werden. Doch DFD’s können auch z.B. zur Darstellung von Fließbändern verwendet werden, in diesem Fall werden über Flüsse tatsächlich Materialien transportiert. Es gibt allerdings auch DFD’s in welchen sowohl Daten als auch Materialien transportiert werden. Der Namen eines Flusses repräsentiert die Bedeutung der Pakete welche über diesen Fluß transportiert werden. Siehe Abb. A.3. Mehrere Datenflüsse können in über einen Bubbel in einen Strom zusammenfließen, aber auch das Gegenteil ist möglich, d.h. Kopien können verschickt werden, ein komplexer Datenfluß kann in kleinere aufgeteilt werden, oder Pakete können durch Bedingungen in verschiedene Flüsse geleitet werden. Es gibt Eingabe - und Ausgabeflüsse, aber auch Dialogflüsse, wobei zu Beachten ist in welche Richtung die Pfeilspitze zeigt. Ein Dialogfluß ist ein Fluß mit zwei Pfeilspitzen, welcher eine Frageantwort Beziehung zweier Bubbles darstellt. Es müssen allerdings beide Richtungen beschrieben werden. Vergl. Abb. A.4., A.5. u. A.6. Fragen wie "Wo kommen die Daten her ?", "In welcher Reihenfolge kommen die Daten an", "In welcher Reihenfolge werde Ausgangspakete erzeugt", "Fließen Daten nur dann wenn sie von einem anderen Teil des Systems angefordert werden ?" oder "Müssen auf allen Eingängen eines Bubbles Pakete kommen um den Prozeß zu starten bzw. alle Ausgangspakete zu generieren ?", können durch ein DFD nicht beantwortet werden. Für solche Fragen ist die Verwendung eines Flußdiagramms empfehlenswert.

1.3 Der Speicher

Ein Gruppe von Datenpaketen, im Ruhezustand, wird als Speicher bezeichnet. Das Symbol für den Speicher sind zwei parallele Linien. Der Name des Speichers ist meist der Plural des Flußnamens, welcher in den Speicher hinein - bzw. herausfließt. Seihe A.7. FOLIE 9.9 179. Speicher können sowohl Datenbanken, als auch Backupmedien wie Lochkarten, Streamerbänder, oder ganz einfach Ablagen oder Ordner sein. Es gibt ebenfalls sogenannte Implemtierungsspeicher, welche zwischen zwei Prozessen, aus folgenden 4 Gründen verwendet werden:

Wenn beide Prozesse auf einem PC ablaufen, dieser allerdings nicht genug Arbeitsspeicher hat und dadurch diese Prozesse zeitversetzt Ablaufen müssen. Die Prozesse laufen auf einem unzuverlässigen Computersystem ab und der Speicher wird als Sicherheitseinrichtung verwendet. Wenn zwei Programmierer diese zwei Prozesse implementieren wird der Speicher zu Fehlersuche verwendet. Wenn der Speicher in die Zukunft vorausschauend implementiert wird, d.h. falls der Anwender später einmal auf diesen Speicher zugreifen will.

Siehe Abb. A.8. u. A.9. FOLIE 9.11(a) 182 (b). Wenn diese Gründe ignoriert werden und man das Modell nur auf die wesentliche Anforderungen konzentriert, so müsste man den Speicher nicht implementieren.

Ein Fluß aus dem Speicher kann Lese oder Zugriffsmöglichkeiten auf die Information im Speicher zur Verfügung stellen. Das heißt man kann einzelne Pakete, mehrere Pakete, Teile eines Pakets, oder Teile mehrerer Pakete aus dem Speicher holen.

Der Speicher ist ein passives Element eines DFD’s, d.h. er gibt nur Information frei, wenn diese von einem anderen Prozeß angefordert werden. Durch diese Lesezugriffe wird der Speicher nicht verändert, d.h. es wird nur eine Kopie der Daten über den Fluß verschickt. Ein Fluß in den Speicher ist ein Schreibzugang, d.h. Daten werden entweder aktualisiert, gelöscht oder hinzugefügt. Die Daten sollten möglichst den Benutzeransprüchen entsprechend implementiert oder geändert werden. Verantwortlich für die Zulieferung der Pakete ist der Prozeß der am Anfang des Zulieferflusses sitzt, dieser kann nur Pakete liefern welche der Speicher auch aufnehmen kann.

1.4 Der Terminator

Siehe Abb. A.10. FOLIE 9.13 186 Der Terminator wird grafisch durch ein Rechteck dargestellt und ist ein externes Objekt welches mit dem System kommuniziert. D.h. eine Person, eine Personengruppe, eine Organisation, oder auch ein externes System welches mit unserem System kommuniziert. Bei Terminatoren gibt es drei wichtige Dinge zu beachten:

Terminatoren befinden sich außerhalb des Systems, d.h. das Flüsse welche mit diesen verbunden sind, stellen Schnittstellen mit der Außenwelt dar. Terminatoren sind außerhalb der Reichweite von Veränderungen, d.h. der Systemanalytiker kann weder den Inhalt, noch Organisation noch die Internen Prozeduren verändern, die mit dem Terminatoren zusammenhängen. Beziehungen zwischen Terminatoren werden im DFD - Modell nicht dargestellt.

2 Richtlinien für den Aufbau eines DFD’s

Bei der Erstellung von DFD’s gibt es folgende Richtlinien welche wir genauer erklären werden:

Aussagekräftige Namen wählen Prozesse numerieren komplexe DFD’s vermeiden so oft als nötig neu zeichnen logisch konsitente DFD’s

2.1 Aussagekräftige Namen wählen

Wenn eine Einzelperson einen Prozeß ausführt, ist es empfehlenswert, anstelle des Namens dieser Person die Funktion anzugeben, die diese Person ausführt. Siehe Abb. A.11. & A.12. Es gibt drei Gründe warum man die Funktion als Name angibt:

Nach einer gewissen Zeit könnten die Aufgaben von einer anderen Person übernommen werden und somit ist das System veraltet.

Wenn diese Person mehrere Tätigkeiten innerhalb eines DFD’s ausführt, ist es nicht sinnvoll drei Bubbles mit dem selben Namen zu zeichnen.

Wenn der Name angegeben wird, wird die Aufmerksamkeit darauf gelenkt, wie derjenige seine Aufgabe durchzuführen beliebt, doch sollte man normalerweise mehr Betonung auf die zugrunde liegende Firmenstrategie legen.

Eine gute Art Prozesse zu benennen ist die Verwendung eines Verbs und eines Objektes, d.h. Sie wählen ein aktives Verb und ein passendes Objekt z.B. "errechne Raketenflugbahn". Man sollte keine Verben verwenden wie mache, bearbeite oder verarbeite, sondern genauere Definition der Tätigkeit verwenden. Man sollte Wörter nehmen, welche aus einem Vokabular stammen, das dem Benutzer gut bekannt ist. Es gibt noch zwei Richtlinien, an die sich Ersteller eines DFD’s halten sollten.

Benutzer neigen dazu, spezifische Abkürzungen zu verwenden, mit welchen Laien wenig anzufangen wissen. Eine gute Methode diesen firmenspezifischen Jargon zu vermeiden, ist Objekte und Verben zu wählen, die Personen der selben Branche ebenfalls verstehen würden.

Wenn ein Programmierer ein DFD erstellt, neigt er dazu, Begriffe wie "Routine", "Prozedur", "Funktion" oder "Untersystem" zu verwenden. Derartige Begriffe sollten allerdings vermieden werden.

2.2 Prozesse numerieren

Um in DFD’s besser auf Prozesse verweisen zu können, ist es vorteilhaft, die Bubbles zu numerieren. Es ergibt sich dabei manchmal das Problem, dass flüchtige Leser, eine Reihenfolge in dieser Numerierung sehen, doch die Numerierung der Prozesse hat nichts mit der Reihenfolge ihrer Ausführung zu tun. Ein weiterer Vorteil in der Numerierung liegt darin, das Bubble direkt mit Bubble 1 ansprechen zu können und nicht die ganze Bezeichnung verwenden zu müssen.

2.3 komplexe DFD’s vermeiden

Man sollte komplexe DFD’s vermeiden, da diese nicht nur vom Systemanalytiker, sondern auch für die Benutzer übersichtlich und leicht verständlich sein sollten. Dazu gibt es eine Richtlinie, die niemals außer acht gelassen werden sollte: erstellen Sie niemals ein DFD mit zu vielen Prozessen, Flüssen, Speichern und Terminatoren. Man sollte sich meistens an folgende Faustregel halten: nie mehr als 6 Prozesse mit den zusammenhängenden Speichern, Flüssen und Terminatoren auf einem Diagramm abbilden. Siehe Abb. A.13.

2.4 Neu zeichnen

Beim Erstellen eines DFD’s wird man merken, dass man viele Veränderungen vornehmen muss, bis das Diagramm technisch korrekt ist, vom Benutzer akzeptiert wird und sauber genug gezeichnet ist. Wie man ein DFD ästhetisch gestaltet hängt natürlich vom persönlichen Geschmack ab, doch haben auch manche Organisationen Normen vorgegeben. Nachfolgend noch drei Hilfen zur Gestaltung eines DFD’s:

Form und Größe der Bubbles

Die Wahl des Symbols ist reine Geschmackssache. Wenn Bubbles in einem DFD unterschiedlich groß sind, werden Benutzer auch leicht irritiert. Diese glauben dann, dass ein größeres Bubble einen wichtigeren Systemteil darstellt.

Gekrümmter oder geradliniger Datenfluß, siehe Abb. A.14. & A.15.

Dies hängt vor allem von den Benutzern ab, welche das DFD lesen. Manche finden gekrümmte, manche geradlinige Datenflüsse schöner. Das heißt, dass es von Vorteil ist, wenn man schon vorher weiß, welche Form für den Benutzer akzeptabler ist.

Handgezeichnete Diagramme oder rechnergenerierte Diagramme

Die meisten Diagramme werden heute bereits mit dem Computer gezeichnet. Es gibt jedoch auch Benutzer, welche handgezeichnete Bilder vorziehen, da sie dann nicht das Gefühl haben, das Diagramm wäre schon endgültig und unveränderbar.

2.5 logisch konsistente DFD’s

Um sicherzustellen, dass das DFD in sich stimmig ist, gibt es einige Richtlinien. Nachfolgend die Hauptkriterien für die Konsistenz eines DFD’s:

Bubbles, welche einen Eingabefluß haben jedoch ohne Ausgabe sind, sollten vermieden werden. Unter den Systemanalytikern ist der Begriff "schwarzes Loch" für diesen Zustand üblich. Ebenfalls sollten Bubbles vermieden werden, welche einen Ausgabefluß haben, jedoch ohne Eingabe sind. Doch gibt es eine Ausnahme, nämlich den Zufallszahlengenerator. Sie sollten unbedingt, alle Flüsse und Prozesse bezeichnen. Ein nichtbezeichnetes Element ist meist ein Zeichen für Nachlässigkeit, kann aber auch auf einen tiefergehenden Fehler hinweisen, wenn z.B. einem Systemanalytiker kein entsprechender Name für einen Datenfluß eingefallen ist, weil mehrere elementare Dateneinheiten willkürlich zusammengepackt wurden. Man sollte nie nur Lese - oder nur Schreibspeicher verwenden. Ein typischer Speicher sollte immer Eingabe - und Ausgabeflüsse haben. Die einzige Ausnahme sind externe Speicher.

3 Erstellung von DFD’s

3.1 Gestufte DFD’s

Was DFD's sind, und wie man mit ihnen umgeht, haben wir jetzt erklärt. Aber was ist, wenn ein Diagramm sehr komplex ist, wenn außer Kreisen und Linien nichts zu sehen ist, und man selbst bei näherem studieren des Diagramms nichts erfährt? Für diesen Fall gibt es gestufte DFD's. D.h., das DFD wird ähnlich einem Atlas immer genauer beschrieben. Zuerst die Weltkarte, dann Europa, jetzt Österreich, danach die Bundesländer und schlußendlich die Bundeshauptstädte.
Wie ist das gestufte DFD aufgebaut? Siehe Abb. A.16.
Die erste Stufe gibt eine Übersicht über das System und die externen Terminatoren. Wenn man die Bubbles numeriert, kann man sie sehr leicht in der nächsten Stufe wiederfinden. Stufe für Stufe wird das System genauer beschrieben, bis es schlußendlich die Funktion, oder den Prozeß darstellt. Zu diesem System der gestuften DFD's müssen wir uns aber folgende sieben Fragen stellen:

Woher wissen wir, wieviele Stufen wir benötigen?

Es sollten nicht mehr als sechs Bubbles und die dazugehörigen Speicher und Terminator pro Stufe vorkommen, um ein überschaubares Bild zu bewahren. Ist es vernünftiger mehr Prozesse auf eine A4 Seite zu geben, weil man dann das Gesamtbild besser versteht, so ist das sicher sinnvoll, solange das DFD nicht zu komplex wird.

Gibt es Richtlinien dafür, wieviele Stufen ein typisches DFD haben sollte?

Einfache Systeme weisen sich durch 2 - 3 Stufen, mittlere durch 3 - 6, und große Systeme durch 5 - 8 Stufen aus. Es ist dabei aber zu bedenken, dass sich die Gesamtzahl der Bubbles von Stufe zu Stufe exponentiell erhöht. Daraus ergibt sich, dass wenn jede Abbildung sieben Bubbles hat, dass in der dritten Stufe bereits 343 Bubbles sind und in der neunten 40.353.607.

Müssen alle Systemteile bis zur gleichen Detailstufe dargestellt werden?

Nein, da es mehr oder weniger komplizierte Teile eines Systems gibt. Wenn sich aber herausstellt, dass ein Teil 2 Stufen benötigt, und ein anderer unter Umständen 7, ist man das Problem falsch angegangen, und sollt das aufwendige Bubble in zwei aufteilen.

Wie präsentieren wir dem Benutzer die Stufen?

Jeweils die Stufe zeigen, die für den Fragenden von Bedeutung ist, (z.B. Angestellter => sein Arbeitsbereich) und maximal noch die darüberliegende Stufe zum leichteren Verständnis.

Wie stellen wir sicher, dass die Stufen des DFD's untereinander stimmig sind?

Hierfür gibt es eine Wichtige Regel: Die Datenflüsse, die in ein Bubble hinein, und heraus fließen, müssen in der nächst niedrigeren Stufe in die Gesamtabbildung hinein oder heraus fließen.

Wie stellen wir die Speicher auf den verschiedenen Stufen dar?

Die Faustregel lautet: Den Speicher immer auf der höchsten Stufe anzeigen, auf der er das erste mal zwischen zwei Bubbles dient. Siehe Abb. A.17.

Wie gehen wir bei der eigentlichen Unterteilung des DFD's vor?

Man muss nicht von oben nach unten vorgehen, da dies Probleme mit sich bringen kann. Sinnvoller ist es, externe Ereignisse, auf die das System reagieren muss, zu identifizieren und eine erste Rohversion das DFD's zu wagen. Wie genau man das macht, kommt erst in den Kapitel 17 bis 20.

3.2 Echtzeit DFD’s Echtzeit

In Echtzeitsystemen benötigt man nicht nur Datenpakete die verschoben werden können, sondern auch Signale oder Unterbrechungen. Auch Steuerprozesse müssen dargestellt werden können. Sie werden mit gestrichelten Linien dargestellt. Siehe Abb. A.18. Dieser Steuerfluß kann nur ein binäres Signal (ON oder OFF) und keine Daten transportieren. Er weckt einen Prozeß der gerade eingefroren oder im Leerlauf war. Ein Steuerprozeß hat die Aufgabe, die Aktivitäten anderer Bubbles im Diagramm zu koordinieren. Es gibt zwei verschiedene Signale, die herauskommenden, die andere Bubbles aufwecken, und die hereinkommenden, die mitteilen, dass ein Prozeß erledigt oder unterbrochen ist.

2309 Worte in "deutsch"  als "hilfreich"  bewertet