Datenflussdiagramme (DFD): Ebenen, Symbole und praktische Beispiele
Lernen Sie, wie Sie Datenflussdiagramme mit der richtigen Notation erstellen. Behandelt DFD-Ebenen 0–2, Yourdon-DeMarco- vs. Gane-Sarson-Symbole und praxisnahe Beispiele.
Wenn ein System ausfällt oder ein Prozess falsche Ausgaben produziert, lautet die erste Frage meist: „Wo sind die Daten schiefgelaufen?" Datenflussdiagramme (DFDs) beantworten diese Frage, indem sie die Datenbewegung explizit machen — sie zeigen genau, woher Daten stammen, wohin sie gehen, wie sie transformiert werden und wo sie gespeichert werden.
Im Gegensatz zu Flussdiagrammen, die den Kontrollfluss modellieren (was als nächstes passiert), modellieren DFDs den Datenfluss (welche Daten sich wohin bewegen). Dieser Unterschied macht sie zum richtigen Werkzeug für die Systemanalyse, den Software-Entwurf und die Dokumentation komplexer Datenintegrationen.
Was ist ein Datenflussdiagramm?
Ein Datenflussdiagramm ist eine visuelle Darstellung davon, wie Daten durch ein System fließen. Es zeigt:
- Externe Entitäten — Quellen und Ziele von Daten außerhalb des Systems
- Prozesse — Transformationen, die Eingabedaten in Ausgabedaten umwandeln
- Datenspeicher — Orte, an denen Daten im Ruhezustand gehalten werden
- Datenflüsse — die Bewegung von Daten zwischen den oben genannten Elementen
DFDs zeigen keine zeitliche Abfolge, Entscheidungslogik oder wer Aufgaben durchführt. Sie zeigen ausschließlich Datenbewegungen. Dieser fokussierte Umfang macht sie nützlich, um Systeme zu verstehen und zu entwerfen, ohne sich in Implementierungsdetails zu verlieren.
DFD-Symbole
Zwei Notationen dominieren: Yourdon-DeMarco und Gane-Sarson. Sie stellen dieselben Konzepte mit unterschiedlichen Formen dar.
Yourdon-DeMarco-Notation
Die ursprüngliche Notation für strukturierte Analyse, weit verbreitet im Software-Engineering:
| Element | Symbol | Beschreibung |
|---|---|---|
| Prozess | Kreis (Blase) | Transformiert Daten; mit einem Verb beschriftet |
| Datenspeicher | Offenes Rechteck | Speichert Daten; mit einem Substantiv beschriftet |
| Externe Entität | Rechteck | Quelle oder Ziel außerhalb des Systems |
| Datenfluss | Pfeil mit Beschriftung | Benannte Daten, die zwischen Elementen fließen |
┌──────────┐ ╭──────────╮ ┌═══════════════╗
│ Kunde │───────→ │Bestellung│───────→ ║ D1: Bestellungen║
└──────────┘ Bestellg│ prüfen │ Gültige ╠═══════════════╣
╰──────────╯ Bestellg║ ║
Gane-Sarson-Notation
Verbreitet in Informationssystemen und der Unternehmensanalyse:
| Element | Symbol | Beschreibung |
|---|---|---|
| Prozess | Rechteck mit abgerundeten Ecken (geteilter Kopf) | Mit ID und Prozessname beschriftet |
| Datenspeicher | Links offenes Rechteck | Mit D-Nummer und Name beschriftet |
| Externe Entität | Rechteck | Quelle oder Ziel außerhalb des Systems |
| Datenfluss | Pfeil mit Beschriftung | Benannte Daten, die zwischen Elementen fließen |
┌──────────┐ ┌────────────────┐ ┌═══╦════════════╗
│ Kunde │───────→ │ 1.0 │───────→ ║D1 ║ Bestellungen║
└──────────┘Bestellg.│Bestell. prüfen │ Gültige ╚═══╩════════════╝
└────────────────┘Bestellg.
Welche Notation verwenden?
Beide vermitteln dieselben Informationen. Wählen Sie basierend auf Ihrem Kontext:
- Yourdon-DeMarco: bevorzugt im Software-Engineering, in der Wissenschaft und bei der Verwendung strukturierter Analysemethoden
- Gane-Sarson: verbreitet in betrieblichen Informationssystemen und Unternehmenskontexten
Wählen Sie eine und bleiben Sie in allen Diagrammen eines Projekts konsistent.
DFD-Ebenen
DFDs sind hierarchisch organisiert. Diagramme auf höherer Ebene bieten einen Überblick; Diagramme auf niedrigerer Ebene bieten Details. Jede Ebene zerlegt einen einzelnen Prozess der darüber liegenden Ebene in seine internen Teilprozesse.
Ebene 0: Kontextdiagramm
Das Kontextdiagramm zeigt das gesamte System als einzelnen Prozess, umgeben von externen Entitäten. Es definiert die Systemgrenze und zeigt, welche Daten diese Grenze überqueren.
Kundenbestellung
┌──────────┐ ────────────────────→ ╭──────────────────────╮
│ Kunde │ │ │
└──────────┘ ←─────────────────── │ Bestellverwaltungs- │
Bestellbestätigung │ System │
│ │
┌──────────┐ ────────────────────→ ╰──────────────────────╯
│Lieferant │ Lageraktualisierung │
└──────────┘ ↓
┌──────────────┐
│Zahlungsverarbeit.│
└──────────────┘
Ein Kontextdiagramm sollte auf eine Seite passen und nur grenzüberschreitende Datenflüsse zeigen — keine internen Details. Wenn Sie sich dabei ertappen, interne Prozesse hinzuzufügen, befinden Sie sich auf der falschen Ebene.
Ebene 1: Übersichtsdiagramm
Das Diagramm auf Ebene 1 zerlegt den einzelnen Kontextprozess in seine wichtigsten Teilprozesse. Dies sind die primären Funktionsbereiche des Systems.
┌──────────┐ ╭──────────╮ ╭──────────╮
│ Kunde │───────→ │ 1.0 │───────→ │ 2.0 │───┐
└──────────┘Bestellg.│Bestellung│Geprüfte │Zahlung │ │
│ erhalten │Bestellg.│verarbeiten│ │
╰──────────╯ ╰──────────╯ │
│ ↓
↓ ╭──────────╮
┌════════════════╗ │ 3.0 │
║D1: Bestellungen║────────────→ │Bestellung│
╚════════════════╝ Bestelldaten │erfüllen │
╰──────────╯
│
↓
┌──────────┐
│Versand- │
│partner │
└──────────┘
Diagramme auf Ebene 1 haben typischerweise 3–7 Prozesse. Wenn Sie mehr haben, erwägen Sie die Gruppierung in weniger übergeordnete Prozesse.
Ebene 2: Detaildiagramm
Ebene 2 zerlegt jeden Prozess von Ebene 1 in seine Teilschritte. Jede Blase aus Ebene 1 erhält ihr eigenes Ebene-2-Diagramm.
Zum Beispiel die Erweiterung des Prozesses 1.0 „Bestellung erhalten" von oben:
┌──────────┐ ╭──────────╮ ╭──────────╮
│ Kunde │──────────→ │ 1.1 │──────────→ │ 1.2 │
└──────────┘ Roheingabe │Format │ Gültige │ Bestand │
│prüfen │ Daten │ prüfen │
╰──────────╯ ╰──────────╯
│ │ │
Ungültige │ Vorhanden
Bestellung Nicht │
↓ vorh. ↓
┌──────────┐ ╭──────────╮
│ Kunde │ │ 1.3 │
└──────────┘ │ Artikel │
│reservier.│
╰──────────╯
│
↓
┌════════════╗
║D1: Bestellungen║
╚════════════╝
Wie tief sollte man gehen?
Hören Sie mit dem Zerlegen auf, wenn ein Prozess:
- Einfach genug ist, um in wenigen Sätzen beschrieben zu werden
- Von einer einzelnen Person oder einer atomaren Systemfunktion ausgeführt wird
- Bereits auf dem für die Implementierung benötigten Detailniveau ist
Die meisten Systeme benötigen nicht mehr als Ebene 2. Ebene 3 ist selten und deutet oft darauf hin, dass das System zu komplex ist oder die Zerlegung nicht gut strukturiert ist.
DFD vs. Flussdiagramm
Diese werden häufig verwechselt, weil beide Kästchen und Pfeile verwenden. Sie beantworten jedoch unterschiedliche Fragen.
| Aspekt | Datenflussdiagramm | Flussdiagramm |
|---|---|---|
| Zeigt | Wie Daten durch ein System fließen | Wie der Kontrollfluss durch einen Prozess läuft |
| Hauptfrage | Welche Daten gehen wohin? | Was passiert als nächstes? |
| Zeit/Reihenfolge | Nicht modelliert (nur Datentransform.) | Zentral — die Reihenfolge ist die Hauptstruktur |
| Entscheidungslogik | Nicht dargestellt | Explizit (Entscheidungs-Rauten) |
| Wer führt aus | Nicht gezeigt | Kann mit Swimlane-Format gezeigt werden |
| Datenspeicherung | Explizites Datenspeicher-Symbol | Nicht dargestellt |
| Am besten für | Systemanalyse, Datenarchitektur | Prozessdokumentation, Verfahrensleitfäden |
Ein Flussdiagramm zeigt die Schritte in einem Kreditgenehmigungsprozess. Ein DFD zeigt, welche Daten das Kreditantragssystem empfängt, wo sie gespeichert werden und welche Ausgaben es produziert.
Verwenden Sie ein DFD, wenn Sie ein System analysieren oder entwerfen. Verwenden Sie ein Flussdiagramm, wenn Sie ein Verfahren dokumentieren.
Schritt für Schritt: Ein DFD erstellen
Schritt 1: Systemgrenze definieren
Identifizieren Sie, was sich innerhalb und außerhalb Ihres Systems befindet:
- Innen: Prozesse, Datenspeicher und Datenflüsse, die Sie kontrollieren
- Außen: Externe Entitäten — Kunden, Partner, externe Systeme
Alles außerhalb der Grenze ist eine externe Entität. Daten, die die Grenze überqueren, erscheinen als Flüsse im Kontextdiagramm.
Schritt 2: Kontextdiagramm zeichnen (Ebene 0)
- Platzieren Sie das gesamte System als einzelnen beschrifteten Kreis in der Mitte
- Identifizieren Sie alle externen Entitäten und platzieren Sie sie außen herum
- Zeichnen Sie Datenflüsse, die die Grenze mit beschreibenden Beschriftungen überqueren
- Vollständigkeit prüfen: Gibt es Daten, die das System ein- oder verlassen, die unbeschriftet sind?
Schritt 3: Hauptprozesse identifizieren (Ebene 1)
Zerlegen Sie das System in 3–7 Hauptprozesse:
- Benennen Sie jeden Prozess mit einem Verb-Phrase („Bestellung prüfen", „Zahlung verarbeiten")
- Nummerieren Sie sie (1.0, 2.0, 3.0)
- Identifizieren Sie, welche Datenflüsse sie verbinden
Schritt 4: Datenspeicher hinzufügen
Identifizieren Sie, wo Daten zwischen Prozessen gehalten werden:
- Datenbanken: Kundendaten, Bestellhistorie, Lagerbestand
- Dateien: Log-Dateien, Konfiguration
- Externe Daten: Daten, die an/von externen Systemen übergeben werden (oft als Grenzflüsse dargestellt, nicht als interne Speicher)
Benennen Sie jeden Datenspeicher mit einem Substantiv und weisen Sie eine D-Nummer zu (D1, D2).
Schritt 5: Mit Datenflüssen verbinden
Zeichnen Sie beschriftete Pfeile zwischen Elementen:
- Flüsse müssen beschreibende Namen haben („Kundenbestellung", „geprüfter Datensatz", „Rechnung")
- Flüsse verbinden Prozesse mit Prozessen, Prozesse mit Datenspeichern und externe Entitäten mit Prozessen
- Datenspeicher verbinden sich nicht direkt mit externen Entitäten (Daten müssen einen Prozess durchlaufen)
Schritt 6: Auf Ebene 2 zerlegen
Zeichnen Sie für jeden Hauptprozess in Ebene 1 ein separates Ebene-2-Diagramm, das seine internen Teilprozesse zeigt. Die Datenflüsse, die den Ebene-1-Prozess ein- und verlassen, werden zu den Grenzflüssen des Ebene-2-Diagramms.
Schritt 7: Konsistenz überprüfen
Prüfen Sie, dass:
- Jeder Datenfluss, der einen Prozess eingibt, von diesem Prozess verwendet wird
- Jeder Datenfluss, der einen Prozess verlässt, aus diesem Prozess stammt
- Auf Datenspeicher nur über Prozesse zugegriffen wird (nicht direkt von externen Entitäten)
- Die Ebene-1-Grenzflüsse mit den Kontextdiagramm-Flüssen übereinstimmen
Praxisbeispiel: E-Commerce-Bestellsystem
Ebene 0: Kontextdiagramm
┌──────────┐ Bestellanfrage ╭──────────────────────╮
│ Kunde │ ─────────────────→ │ │
└──────────┘ │ E-Commerce- │
↑ Bestellstatus │ Bestellsystem │
└─────────────────────── ─ │ │
╰──────────────────────╯
┌──────────┐ Zahlungsergebnis │ ↑
│Zahlungs- │ ──────────────────→ │ │
│ gateway │ ←────────────────── │ Versand-
└──────────┘ Belastungsanfrage ↓ daten
┌──────────────┐
│ Versand- │
│ partner │
└──────────────┘
Ebene 1: Hauptprozesse
Kunde ─── Bestellanfrage ──→ ╭──────────╮
│ 1.0 │ ──→ D1: Bestellungen
│Bestellung│
│ prüfen │
╰──────────╯
│
Geprüfte Bestellung
↓
Zahlungsgateway ←── Belastungs- ── ╭──────────╮ ── Zahlungs- ──→ D2: Zahlungen
anfrage │ 2.0 │ datensatz
Zahlungsgateway ── Ergebnis ──→ │Zahlung │
│verarbeiten│
╰──────────╯
│
Bestätigte Bestellung
↓
╭──────────╮
D1: Bestellungen ─ Bestelldaten ─→ │ 3.0 │ ── Versandanfrage ──→ Versand-
D3: Produkte ─── Bestandsdaten ──→ │Bestellung│ partner
│ erfüllen │
╰──────────╯
│
Versanddaten
↓
╭──────────╮
│ 4.0 │ ── Statusaktualisierung ──→ Kunde
│Verfolgen │
│& Benachr.│
╰──────────╯
Ebene 2: Zerlegung von Prozess 1.0 (Bestellung prüfen)
Kunde ─── Roheingabe ──→ ╭──────────╮
│ 1.1 │ ── Ungültig ──→ Kunde (Fehler)
│ Format │
│ prüfen │
╰──────────╯
│
Formatierte Bestellung
↓
╭──────────╮
D3: Produkte ─ Bestandsinfo─→│ 1.2 │ ── Nicht verfügbar ──→ Kunde
│ Bestand │
│ prüfen │
╰──────────╯
│
Verfügbare Bestellung
↓
╭──────────╮
D4: Kunden ─ Authentifiz. ─→│ 1.3 │ ── Nicht verifiziert ──→ Kunde
│ Kunden │
│prüfen │
╰──────────╯
│
Geprüfte Bestellung
↓
D1: Bestellungen (gespeichert)
Häufige DFD-Fehler
Externe Entitäten direkt mit Datenspeichern verbinden. Datenspeicher sind intern; externe Entitäten können nicht direkt auf sie zugreifen. Alle Daten, die die Systemgrenze überqueren, müssen einen Prozess durchlaufen.
Unbeschriftete Datenflüsse. Jeder Pfeil muss einen beschreibenden Namen haben. „Daten" oder „Info" sind nicht beschreibend. Ein Fluss sollte nach dem benannt werden, was die Daten darstellen: „Kundenbestellung", „Zahlungsbestätigung", „Lagerbestand".
Prozesse ohne Ein- oder Ausgaben. Ein Prozess muss mindestens einen Eingangsfluss und einen Ausgangsfluss haben. Ein Kreis ohne eingehende Daten „erschafft" Daten aus dem Nichts — das ist kein Prozess, das ist eine externe Entität. Ein Kreis ohne ausgehende Daten verwirft alles — modellieren Sie das als Datenspeicher-Schreibvorgang oder entfernen Sie den Prozess.
Kontrollfluss mit Datenfluss vermischen. Entscheidungen, Reihenfolge und Steuerungslogik gehören nicht in DFDs. Wenn Sie sich dabei ertappen, Entscheidungs-Rauten zu zeichnen, erstellen Sie ein Flussdiagramm, kein DFD. DFDs zeigen nur Datenbewegungen.
Zu viele Details auf Ebene 1. Ebene 1 sollte 3–7 Hauptprozesse haben. Wenn Sie 15 Prozesse auf Ebene 1 zeigen, haben Sie die hierarchische Zerlegung übersprungen. Gruppieren Sie verwandte Prozesse in übergeordnete Blasen und verwenden Sie Ebene 2, um Details zu zeigen.
Inkonsistente Ebenen. Die Datenflüsse, die in Prozess 2.0 im Ebene-1-Diagramm eingehen, müssen mit den Grenzflüssen im Ebene-2-Diagramm für Prozess 2.0 übereinstimmen. Inkonsistenz bedeutet, dass die Diagramme nicht dasselbe System darstellen.
Datenspeicher ohne Erklärung über Subsysteme hinweg geteilt. Wenn mehrere Prozesse auf denselben Datenspeicher zugreifen, stellen Sie sicher, dass dies beabsichtigt ist und dass der Zugriff sinnvoll ist. Die übermäßige Verwendung eines einzelnen „Haupt-Datenbank"-Datenspeichers verbirgt wichtige Datenarchitekturentscheidungen.
Datenflussdiagramme mit Flowova erstellen
Datenflüsse manuell zu kartieren ist mühsam — alle Grenzflüsse zu identifizieren, Prozesse konsistent zu nummerieren und Ebenen synchron zu halten erfordert erheblichen Aufwand.
Der Datenflussdiagramm-Ersteller von Flowova generiert DFD-Strukturen aus Systembeschreibungen in natürlicher Sprache. Beschreiben Sie die Eingaben, Ausgaben und Hauptprozesse Ihres Systems und erhalten Sie ein Entwurfsdiagramm, das Sie verfeinern können. Dies ist besonders nützlich, um schnell Kontextdiagramme und Ebene-1-Übersichten zu erstellen und dann für die Prozesse, die es benötigen, in Ebene-2-Details einzutauchen.
Fazit
DFDs sind das richtige Werkzeug, wenn Sie verstehen oder kommunizieren müssen, wie Daten durch ein System fließen — nicht was Schritt für Schritt passiert, sondern woher Daten stammen, was sie transformiert, wo sie gespeichert werden und wohin sie letztendlich gehen.
Beginnen Sie mit einem Kontextdiagramm, um die Systemgrenze festzulegen. Zerlegen Sie auf Ebene 1, um Hauptprozesse zu identifizieren. Gehen Sie nur für Prozesse, die weitere Klärung benötigen, auf Ebene 2. Benennen Sie Datenflüsse spezifisch, vermeiden Sie das Einmischen von Steuerungslogik in das Diagramm und überprüfen Sie die Konsistenz über alle Ebenen hinweg.
Verwandte Ressourcen
- Flussdiagramm-Symbole und ihre Bedeutung — Standardnotations-Referenz
- BPMN-Diagramm-Leitfaden — Standard für die Geschäftsprozessmodellierung
- Datenflussdiagramm-Ersteller — DFDs mit KI erstellen
- Systemarchitektur-Vorlagen — Sofort einsetzbare Architekturdiagramm-Vorlagen
