Visual Paradigm Desktop | 
Visual Paradigm Online
Datenumlaufdiagramme (DFDs) dienen als visuelle Baupläne für Informationssysteme. Im Gegensatz zu Code, der Logik durch Syntax beschreibt, beschreibt eine DFD Logik durch Bewegung. Sie zeigt, wie Daten in ein System eintreten, durch verschiedene Prozesse transformiert werden und als Ausgabe oder Speicherung verlassen. Dieser Leitfaden bietet einen umfassenden Überblick über die Erstellung dieser Diagramme ohne Abhängigkeit von proprietären Werkzeugen und konzentriert sich auf die grundlegenden Prinzipien der Systemanalyse.
Unabhängig davon, ob Sie Anforderungen für eine neue Anwendung definieren oder ein bestehendes Legacy-System auditieren, ist das Verständnis der Datenflüsse entscheidend. Ein gut strukturiertes DFD beseitigt Mehrdeutigkeiten. Es zwingt die Beteiligten dazu, sich darauf zu einigen, wo die Informationen entstehen und wo sie enden. Dieses Dokument untersucht die Struktur von DFDs, die Regeln für ihre Erstellung und die Methoden zur Zerlegung komplexer Systeme in überschaubare Ansichten.
Ein Datenumlaufdiagramm ist kein Steuerflussdiagramm. Es zeigt weder die Zeitpunkte noch die Reihenfolge von Ereignissen. Stattdessen konzentriert es sich auf die Daten selbst. Stellen Sie sich vor, es sei eine Karte eines Flusssystems. Sie interessieren sich nicht für die Geschwindigkeit des Wassers oder das Wetter, sondern für die Nebenflüsse, die Stauseen und die Mündungen der Flüsse.
Beim Modellieren eines Geschäfts-Systems beantwortet die DFD drei zentrale Fragen:
Durch die Beantwortung dieser Fragen erstellen Sie eine logische Darstellung des Geschäfts. Diese Darstellung bleibt unabhängig von der verwendeten Technologie-Stack gültig. Es ist eine Abstraktionssprache, die die Kluft zwischen geschäftlichen Anforderungen und technischer Umsetzung überbrückt.
Jedes Datenumlaufdiagramm wird mit vier spezifischen Symbolen erstellt. Obwohl die Notationen zwischen Methoden leicht variieren, bleiben die zugrundeliegenden Konzepte konsistent. Die Beherrschung dieser Elemente bildet die Grundlage für eine genaue Modellierung.
Externe Entitäten stellen Quellen oder Ziele von Daten dar, die außerhalb der Grenzen des modellierten Systems liegen. Sie sind oft Personen, Abteilungen oder andere Systeme, die mit dem Hauptsystem interagieren.
In Diagrammen werden sie typischerweise als Quadrate oder Rechtecke dargestellt. Sie müssen immer mit einem Prozess verbunden sein; Daten können nicht einfach aus dem Nichts auftauchen oder in Luft zerfließen.
Ein Prozess transformiert Eingabedaten in Ausgabedaten. Er ist die Triebkraft des Systems. In einer DFD werden Prozesse meist als Kreise oder abgerundete Rechtecke dargestellt. Ein Prozessname sollte immer eine Verben-Nomen-Phrase sein, um eine Handlung anzuzeigen.
Jeder Prozess muss mindestens eine Eingabe und eine Ausgabe haben. Wenn ein Prozess Eingaben, aber keine Ausgaben hat, handelt es sich um ein „Schwarzes Loch“. Wenn er Ausgaben, aber keine Eingaben hat, ist es ein „Wunder“. Beide stellen Modellierungsfehler dar.
Datenbanken stellen Orte dar, an denen Informationen für eine spätere Abrufung gespeichert werden. Dazu können eine Datenbank, ein Dateisystem, ein physischer Aktenordner oder ein temporärer Puffer gehören. Im Gegensatz zu Prozessen verändern Datenbanken die Daten nicht; sie halten sie lediglich bereit.
Sie werden typischerweise als offene Rechtecke oder zwei parallele Linien gezeichnet. Sie verbinden sich über Datenflüsse mit Prozessen und zeigen Lese- oder Schreibvorgänge an.
Datenflüsse sind die Pfeile, die die Komponenten verbinden. Sie stellen die Bewegung von Daten zwischen Entitäten, Prozessen und Speichern dar. Eine Pfeilspitze zeigt die Richtung der Bewegung an.
Komplexe Systeme können nicht auf einer einzigen Seite dargestellt werden. Um die Komplexität zu verwalten, werden DFDs in verschiedene Detailstufen zerlegt. Dieser hierarchische Ansatz ermöglicht es Analysten, in die Systemarchitektur hinein- und herauszumikroskopieren.
Das Kontextdiagramm ist die höchste Ebene der Darstellung. Es zeigt das gesamte System als eine einzelne Prozessblase. Es veranschaulicht, wie das System mit externen Entitäten interagiert.
Ebene 1 erweitert den einzelnen Prozess aus dem Kontextdiagramm in wichtige Unterverarbeitungen. Diese Ebene identifiziert die primären funktionalen Bereiche des Systems.
Ebene 2 zoomt auf spezifische Prozesse aus Ebene 1 ein. Sie zerlegt komplexe Funktionen in kleinere, ausführbare Schritte. Auf dieser Ebene suchen Entwickler oft nach spezifischen Logikanforderungen.
Es gibt zwei dominierende Notationen, die in der Systemanalyse verwendet werden. Während die Logik gleich bleibt, unterscheidet sich die visuelle Darstellung. Die Wahl der richtigen Notation hängt von der Vertrautheit des Teams und den Standards der Organisation ab.
| Funktion | Yourdon & DeMarco | Gane & Sarson |
|---|---|---|
| Prozessform | Abgerundetes Rechteck | Abgerundetes Rechteck |
| Entitätsform | Quadrat | Quadrat |
| Datenspeicherform | Offenes Rechteck | Offenes Rechteck mit dickerer Ober- oder Unterseite |
| Datenflussform | Gekrümmter Pfeil | Gerader Pfeil |
| Position des Flussbeschriftungs | Unter der Linie | Oben oder unten |
Die Wahl zwischen Gane & Sarson und Yourdon & DeMarco ist im Wesentlichen kosmetisch. Allerdings ist Konsistenz entscheidend. Das Mischen von Notationen innerhalb eines Dokuments erzeugt Verwirrung und verringert die Klarheit der Dokumentation.
Die Erstellung eines DFD ist ein systematischer Prozess. Er erfordert Iteration und Validierung. Folgen Sie diesen Schritten, um Genauigkeit und Vollständigkeit zu gewährleisten.
Bevor Sie eine einzige Linie zeichnen, identifizieren Sie, was sich innerhalb des Systems und was außerhalb befindet. Dies wird oft durch den Umfang des Projekts bestimmt. Alles, was Eingaben liefert oder Ausgaben empfängt, ist eine Randbedingung.
Listen Sie alle Quellen und Zielorte auf. Befragen Sie die Stakeholder, um festzustellen, wer mit dem System interagiert. Vergessen Sie nicht automatisierte Systeme; sie sind Entitäten wie Menschen.
Beginnen Sie mit dem Überblick. Zeichnen Sie das System als eine einzige Blase. Verbinden Sie die externen Entitäten mit Pfeilen. Beschriften Sie die Pfeile mit den ausgetauschten Daten. Dies dient als Anker für alle nachfolgenden Diagramme.
Erweitern Sie die einzelne Blase zu Ebene 1. Identifizieren Sie die Hauptfunktionen. Zerlegen Sie das System in logische Abschnitte. Stellen Sie sicher, dass die Eingaben und Ausgaben des Diagramms der Ebene 0 mit den aggregierten Eingaben und Ausgaben der Prozesse der Ebene 1 übereinstimmen.
Identifizieren Sie, wo Daten persistiert werden müssen. Wenn ein Prozess Informationen aus einer vorherigen Transaktion speichern muss, ist eine Datenbank erforderlich. Verbinden Sie diese Speicher mit den entsprechenden Prozessen.
Dies ist eine entscheidende Regel. Die Eingaben und Ausgaben eines übergeordneten Prozesses müssen der Summe der Eingaben und Ausgaben seiner Kindprozesse entsprechen. Wenn das Kontextdiagramm „Bestellung erhalten“ zeigt, muss das Diagramm der Ebene 1 ebenfalls „Bestellung erhalten“ an irgendeiner Stelle zeigen, wo sie das System betritt.
Gehen Sie das Diagramm durch. Verfolgen Sie ein Stück Daten von Anfang bis Ende. Fließt es logisch? Gibt es verwaiste Prozesse? Sind alle Datenflüsse beschriftet?
Sogar erfahrene Analysten begehen Fehler beim Aufbau dieser Modelle. Die Kenntnis häufiger Fehler kann erhebliche Zeit während der Überprüfungsphase sparen.
Es ist wichtig, zwischen der logischen Sichtweise des Systems und der physischen Sichtweise zu unterscheiden. Das logische DFD beschreibtwasdas System tut. Das physische DFD beschreibtwie wie das System es macht.
Beginnen Sie mit dem logischen Modell. Führen Sie technische Einschränkungen nicht zu früh ein. Die zu frühe Einführung von Technologie kann die Gestaltungsmöglichkeiten einschränken und Verzerrungen in der Analyse erzeugen. Sobald das logische Modell genehmigt ist, kann das physische Modell abgeleitet werden, um die Entwicklung zu leiten.
Um sicherzustellen, dass die DFDs während des gesamten Projektzyklus nützlich bleiben, halten Sie sich an diese Standards.
Warum Zeit in das Zeichnen dieser Diagramme investieren? Textbasierte Anforderungen sind anfällig für Missverständnisse. Ein Satz, der einen Prozess beschreibt, kann auf verschiedene Weisen gelesen werden. Ein Diagramm ist visuell und räumlich.
Wenn ein Stakeholder ein Diagramm sieht, kann er sofort fehlende Flüsse erkennen. Er kann sehen, wo Daten dupliziert werden. Er kann die Komplexität des Systems auf einen Blick verstehen. Diese visuelle Bestätigung verringert das Risiko, das falsche System zu bauen.
Darüber hinaus dienen DFDs als Kommunikationsinstrument zwischen Geschäfts- und Technikteams. Business Analysten nutzen sie, um Anforderungen zu verstehen. Entwickler nutzen sie, um die Architektur zu verstehen. Durch die Pflege eines gemeinsamen Artefakts verringert die Organisation Silos und verbessert die Ausrichtung.
Die Implementierung einer Datenflussdiagramm-Methode erfordert Disziplin. Es reicht nicht aus, nur Linien zu zeichnen; Sie müssen die Regeln der Datenkonservierung und -dekomposition verstehen. Je mehr Sie üben, desto natürlicher werden die Diagramme zu einer Erweiterung Ihres Denkprozesses.
Beginnen Sie klein. Modellieren Sie eine einfache Transaktion. Erweitern Sie dann auf eine Abteilung. Schließlich modellieren Sie das gesamte Unternehmen. Bei jeder Ebene vertieft sich Ihr Verständnis des Systems. Das Ziel ist nicht, eine perfekte Zeichnung zu erstellen, sondern eine klare Karte der Informationsbewegung zu erstellen, die die Entwicklung robuster Softwarelösungen leitet.
Denken Sie daran, dass das Diagramm ein Werkzeug zum Denken ist, nicht nur ein Dokument zur Archivierung. Nutzen Sie es, um Annahmen zu hinterfragen, Lücken zu identifizieren und Logik zu überprüfen. In der Landschaft der Systemgestaltung bleibt Klarheit die höchste Form der Präzision.
Durch Einhaltung dieser Prinzipien stellen Sie sicher, dass die Datenbewegung innerhalb jedes Geschäfts-Systems präzise dokumentiert und von allen am Projektzyklus beteiligten Stakeholdern verstanden wird.