Datenflussdiagramm-Beispiele: Kontextdiagramm, Ebene 0 und Ebene 1

Ein Datenflussdiagramm (DFD) zeigt, wie Informationen durch ein System fließen: woher sie kommen, was sie umwandelt, wo sie gespeichert werden und wohin sie gehen. Über Timing, Schleifen oder darüber, welcher Server was ausführt, sagt es nichts, und genau das ist seine Stärke. Ein DFD ist der schnellste Weg, sich darauf zu einigen, welche Daten ein System verarbeitet. Deshalb taucht es in der Anforderungsarbeit, in Datenschutzprüfungen und in der Bedrohungsmodellierung auf.

Dieser Beitrag behandelt DFD-Symbole in den zwei klassischen Notationen und arbeitet dann ein Beispiel, einen Onlineshop, auf drei Ebenen durch: Kontextdiagramm, Ebene 0 und Ebene 1. Außerdem erklärt er die Namensverwirrung rund um „Ebene 0“, die Balancing-Regel, die Ebenen konsistent hält, und die Fehler, nach denen Reviewer suchen.

DFD-Symbole

DFDs verwenden vier Elemente. Zwei Notationen dominieren, beide aus den Büchern zur strukturierten Analyse der späten 1970er-Jahre: Yourdon und DeMarco sowie Gane und Sarson.

Die Notationen sind gleichwertig; wähle eine und bleib dabei. Viele moderne Tools zeichnen Datenspeicher als Zylinder, die Leser sofort erkennen. Was du auch wählst, füge eine Legende hinzu.

Die Regeln, die ein DFD gültig machen

1. Jeder Prozess hat mindestens einen Eingang und einen Ausgang. Ein Prozess nur mit Eingängen ist ein schwarzes Loch, einer nur mit Ausgängen ein Wunder.
2. Daten bewegen sich nur über Prozesse. Kein Fluss geht direkt von einer externen Entität zu einem Datenspeicher, von einem Speicher zum anderen oder zwischen zwei externen Entitäten.
3. Flüsse tragen Namen, die Daten beschreiben, etwa „Bestelldaten“ oder „Zahlungsergebnis“, keine Aktionen wie „senden“ oder „prüfen“.
4. Prozesse werden mit Verb und Objekt benannt: „Bestellung annehmen“, „Bestellung ausführen“.
5. Jeder Prozess ist nummeriert, und seine Zerlegung wiederholt die Nummer: Aus Prozess 1 werden 1.1, 1.2 und 1.3.

Ebenen und die Verwirrung um Ebene 0

Ein DFD wird von oben nach unten gezeichnet, in Ebenen mit zunehmendem Detail:

• Das Kontextdiagramm zeigt das gesamte System als einen einzigen Prozess, umgeben von allen externen Entitäten und den Flüssen zwischen ihnen. Es definiert die Grenze.
• Die nächste Ebene zerlegt diesen einen Prozess in seine Hauptprozesse, fügt die Datenspeicher hinzu und behält dieselben externen Flüsse.
• Tiefere Ebenen zerlegen einzelne Prozesse weiter, so weit es jemand braucht.

Hier liegt die Verwirrung: Manche Lehrbücher und Tools nennen das Kontextdiagramm „Ebene 0“ und seine erste Zerlegung „Ebene 1“. Andere folgen der älteren Praxis der strukturierten Analyse, behandeln das Kontextdiagramm als eigene Ebene und nennen die erste Zerlegung „Diagramm 0“ oder „Ebene 0“. Beides ist nicht falsch. Dieser Beitrag nutzt die zweite Konvention: Kontextdiagramm, dann Ebene 0, dann Ebene 1. Was auch immer du nutzt, schreib es aufs Diagramm.

Das Beispiel: ein Onlineshop

Ein Onlineshop nimmt Bestellungen von Kunden an, belastet sie über einen Zahlungsanbieter und schickt Picklisten an ein Lager, das die Ware versendet.

Kontextdiagramm

Ein Prozess, „0 Online store“, und drei externe Entitäten:

Das ist das ganze System von außen. Jeder kann es in einer Minute prüfen, und es beantwortet schon wichtige Fragen: Welche Organisationen erhalten Kundendaten, und von welchen Systemen hängen wir ab?

Ebene 0

Zerlege den Onlineshop in drei Prozesse und zwei Datenspeicher:

1. Take order empfängt die Bestelldaten vom Kunden, liest Preise aus D2 Products, schreibt die Bestellung in D1 Orders und reicht eine Zahlungsanforderung an Prozess 2 weiter.
2. Process payment sendet die Zahlungsanforderung an den Zahlungsanbieter, empfängt das Zahlungsergebnis, aktualisiert die Bestellung in D1 Orders und übergibt bezahlte Bestellungen an Prozess 3.
3. Fulfil order liest bezahlte Bestellungen, sendet die Pickliste an das Lager, empfängt den Versandstatus und schickt die Bestellbestätigung an den Kunden.

Jeder externe Fluss aus dem Kontextdiagramm taucht auf Ebene 0 wieder auf, verbunden mit denselben Entitäten. Das ist Balancing, und das Diagramm unten macht es sichtbar.

Ebene 1

Jeder Prozess auf Ebene 0 lässt sich weiter zerlegen. Prozess 1, Take order, auf Ebene 1:

Die Ein- und Ausgänge von 1.1 bis 1.3 müssen zusammengenommen den Ein- und Ausgängen von Prozess 1 auf Ebene 0 entsprechen. Zeichne jede Zerlegung auf Ebene 1 als eigenes Diagramm, mit der Nummer des Elternprozesses im Titel.

Balancing: die Regel, die Reviewer zuerst prüfen

Ein Kinddiagramm ist ausgeglichen, wenn die Datenflüsse, die hinein- und hinausgehen, den Flüssen entsprechen, die in seinen Elternprozess hinein- und aus ihm hinausgehen. Zeigt Ebene 0 einen Fluss „Erstattungsantrag“, den das Kontextdiagramm nicht zeigt, ist eines von beiden falsch: Entweder hat das System eine Schnittstelle, auf die sich niemand geeinigt hat, oder das Kontextdiagramm ist unvollständig. Balancing macht DFD-Ebenen als Satz vertrauenswürdig, und es lässt sich leicht prüfen, indem du die externen Flüsse jeder Ebene nebeneinander auflistest.

Typische Fehler

• Ein Flussdiagramm zeichnen. Entscheidungen, Schleifen und „dann“-Pfeile gehören in ein Flussdiagramm oder ein BPMN-Diagramm. Ein DFD zeigt Daten, nicht den Kontrollfluss.
• Unbenannte Flüsse. Ein Pfeil ohne Beschriftung sagt dem Reviewer nichts; benenne die Daten, die er trägt.
• Zu viele Prozesse pro Diagramm. Mehr als etwa sieben bis neun Prozesse auf einer Ebene sind schwer zu lesen. Gruppiere sie und zerlege die Gruppen auf der nächsten Ebene.
• Datenspeicher, die nur Daten empfangen. Wenn nie etwas aus einem Speicher liest, warum gibt es ihn? Wenn nie etwas hineinschreibt, woher kommen seine Daten?
• Ebenen vermischen. Detaillierte Teilprozesse neben übergeordneten Prozessen im selben Diagramm zu zeigen, bricht die Hierarchie.

DFDs, Flussdiagramme und Architekturdiagramme

DFDs sind der Standard-Input für Threat Modeling: Ergänze ein Diagramm der Ebene 0 um Vertrauensgrenzen, und du hast die Grundlage für ein STRIDE-Review, wie der Beitrag zum Datenflussdiagramm für Threat Modeling zeigt. Für Datenschutzarbeit sind sie genauso nützlich: Das DSGVO-Datenmapping-Diagramm verfolgt personenbezogene Daten durch dieselbe Art von Flüssen.

Das Diagramm der DFD-Ebenen

So liest du es:

• Die externen Entitäten stehen in der Mitte: Customer, Payment provider und Warehouse. Beide Diagramme verbinden sich mit ihnen.
• Der linke Rahmen ist das Kontextdiagramm: ein Prozess, 0 Online store, mit sechs benannten Flüssen zu den Entitäten.
• Der rechte Rahmen ist Ebene 0: Take order, Process payment und Fulfil order, mit den Datenspeichern Orders und Products.
• Balancing ist sichtbar: Jeder externe Fluss links erscheint rechts wieder, jetzt an dem Prozess, der ihn verarbeitet.
• Der Markdown-Block enthält die Legende und die Nummerierungskonvention.

DFDs zeichnen, die ein Review überstehen

• Benenne jeden Fluss mit einem Substantiv. Die meisten Review-Kommentare zu DFDs betreffen unbeschriftete oder vage beschriftete Pfeile.
• Nummeriere Prozesse über alle Ebenen konsistent, damit Leser 1.2 bis zu 1 zurückverfolgen können.
• Lass externe Entitäten auf jeder Ebene an derselben Position; das macht Balancing leicht sichtbar.
• Füge eine Legende für deine Notation hinzu, besonders wenn du klassische Symbole mit Zylindern für Datenspeicher mischst.

Zur Notation anderer Diagrammtypen siehe das Incident-Response-Beispiel im Flussdiagramm-Stil und das BPMN-Diagramm-Beispiel.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge in einer mittleren Spalte drei Kasten-Nodes aus dem Basis-Pack für Customer, Payment provider und Warehouse hinzu.
3. Füge links einen Rahmen aus dem Basis-Pack namens Context diagram hinzu, darin eine Form in der Variante Ellipse aus dem Basis-Pack für 0 Online store.
4. Füge rechts einen zweiten Rahmen namens Level 0 hinzu, darin drei Ellipse-Formen für die Prozesse und zwei Formen in der Variante Zylinder für D1 Orders und D2 Products.
5. Zeichne die Flüsse als beschriftete Kanten, mit denselben Beschriftungen auf beiden Seiten der Entitäten.
6. Füge einen Markdown-Block aus dem Basis-Pack mit der Legende und der Nummerierungskonvention hinzu.

Das Beispiel nutzt 12 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was sind die vier Symbole eines Datenflussdiagramms? Externe Entitäten, Prozesse, Datenspeicher und Datenflüsse. Yourdon und DeMarco zeichnen Prozesse als Kreise und Speicher als parallele Linien; Gane und Sarson verwenden abgerundete Rechtecke und offene Rechtecke.

Was ist der Unterschied zwischen einem Kontextdiagramm und einem DFD der Ebene 0? Ein Kontextdiagramm zeigt das ganze System als einen einzigen Prozess mit seinen externen Entitäten. Die nächste Ebene zerlegt diesen Prozess in Hauptteilprozesse und Datenspeicher. Manche Quellen nennen das Kontextdiagramm Ebene 0, also gib deine Konvention an.

Was bedeutet Balancing in einem DFD? Die Datenflüsse, die in ein Kinddiagramm hinein- und aus ihm hinausgehen, müssen den Flüssen seines Elternprozesses entsprechen. So beschreiben die Ebenen dasselbe System.

Wie unterscheidet sich ein DFD von einem Flussdiagramm? Ein DFD zeigt, welche Daten sich wohin bewegen und wie sie umgewandelt werden, ohne Reihenfolge oder Entscheidungen. Ein Flussdiagramm zeigt die Abfolge der Schritte und die Entscheidungen dazwischen.

Wie viele Ebenen sollte ein DFD haben? So viele, wie Leser brauchen. Die meisten Systeme sind mit einem Kontextdiagramm und Ebene 0 gut beschrieben, mit Diagrammen der Ebene 1 nur für komplexe oder sensible Prozesse.

Kostenlos starten — ein Seat, keine Kreditkarte.