Level-0-, Level-1- und Level-2-Datenflussdiagramme: Wann und wie man jeweils verwendet

Das Verständnis dafür, wie Informationen durch ein System fließen, ist entscheidend für die Entwicklung robuster Software und effizienter Geschäftsprozesse. Datenflussdiagramme (DFDs) bieten eine visuelle Darstellung dieses Flusses. Sie zeigen den Datenverlauf von externen Quellen zu internen Prozessen auf, wobei sichtbar wird, wo Daten gespeichert werden und wie sie verändert werden. Allerdings erfasst ein einzelnes Diagramm selten die Komplexität moderner Systeme. Genau hier wird die Hierarchie der Level-0-, Level-1- und Level-2-DFDs entscheidend.

Die Wahl der richtigen Detailtiefe zum richtigen Zeitpunkt verhindert Verwirrung während der Anforderungserhebung und Systemgestaltung. Dieser Leitfaden untersucht die spezifischen Anwendungen, Komponenten und Regeln für jedes Niveau. Wir werden untersuchen, wann man die Aufteilung eines Prozesses beenden sollte und wie man Konsistenz in Ihrer Dokumentation aufrechterhält.

🔍 Was ist ein Datenflussdiagramm?

Ein Datenflussdiagramm ist eine grafische Darstellung des Datenflusses durch ein Informationssystem. Im Gegensatz zu Flussdiagrammen, die sich auf Steuerfluss und logische Entscheidungen konzentrieren, legen DFDs den Fokus auf den Datenfluss. Sie helfen den Beteiligten, visuell zu verstehen, wie Eingaben in Ausgaben umgewandelt werden.

• Prozess: Eine Aktion, die Daten umwandelt.
• Datenbank: Wo Daten für eine spätere Verwendung gespeichert werden.
• Externes Element: Eine Quelle oder ein Ziel außerhalb der Systemgrenze.
• Datenfluss: Die Bewegung von Daten zwischen diesen Komponenten.

Durch die Aufteilung eines Systems in spezifische Ebenen können Analysten die Komplexität besser handhaben. Sie müssen auf dem ersten Diagramm nicht jedes einzelne Transaktionsdetail darstellen. Stattdessen beginnen Sie allgemein und verfeinern, wenn nötig.

🌍 Ebene 0: Das Kontextdiagramm 🌍

Das Level-0-DFD wird oft als Kontextdiagramm bezeichnet. Es stellt das gesamte System als einen einzigen Prozess dar. Diese Übersichtsebene legt die Grenze zwischen dem System und seiner Umgebung fest.

🎯 Wann man Ebene 0 verwendet

• Anforderungserhebung: Verwenden Sie es früh, um den Umfang mit den Beteiligten abzustimmen.
• Projektstart: Bietet neuen Teammitgliedern einen schnellen Überblick.
• Definition der Systemgrenze: Definiert klar, was innerhalb des Systems und was außerhalb liegt.

⚙️ Wichtige Komponenten

• Ein Prozessknoten: Das gesamte System wird durch einen einzelnen Kreis oder eine abgerundete Rechteck dargestellt. Er wird normalerweise mit dem Systemnamen beschriftet (z. B. „Auftragsbearbeitungssystem“).
• Externe Entitäten: Dies sind Personen, Organisationen oder andere Systeme, die mit Ihrem System interagieren. Beispiele sind „Kunde“, „Zahlungsgateway“ oder „Lagerverwaltungssystem“.
  • Hinweis: Fügen Sie interne Abteilungen nicht als externe Entitäten hinzu, wenn sie zum selben Systemumfang gehören.
• Datenflüsse: Pfeile, die Eingaben und Ausgaben zwischen Entitäten und dem zentralen Prozess anzeigen.

📝 Beispiel-Szenario

Betrachten Sie ein Bibliotheksverwaltungssystem. Das Level-0-Diagramm würde den zentralen Prozess „Bibliotheks-System“ zeigen. Externe Entitäten wären „Bibliothekar“, „Mitglied“ und „Buchlieferant“. Datenflüsse wären beispielsweise „Neue Buchanfrage“ vom Lieferanten und „Buchausleihe“ vom Mitglied.

Diese Ebene beantwortet die Frage: „Was ist das System, und mit wem spricht es?“

🔄 Ebene 1: Die Übersichtsprozesskarte 🔄

Die DFD-Ebene 1 erweitert den einzelnen Prozess der Ebene 0 in seine wichtigsten Unterverfahren. Sie zeigt die internen Abläufe des Systems, ohne sich in feinmechanische Details zu verlieren. Dies ist oft das wichtigste Diagramm für Diskussionen zur Hoch-Level-Architektur.

🎯 Wann man Ebene 1 verwendet

• Phase der Systemgestaltung:Entwickler müssen die Hauptmodule kennen.
• Feature-Planung:Product-Manager nutzen dies, um deutlich abgegrenzte funktionale Bereiche zu identifizieren.
• Schnittstellendefinition:Hilft dabei, wo Daten in das System eintreten und es verlassen, um APIs zu definieren.

⚙️ Wichtige Komponenten

• Hauptprozesse:Zerlegen Sie den einzelnen Prozess der Ebene 0 in 5 bis 9 verschiedene Prozesse. Wenn Sie mehr haben, überlegen Sie, sie weiter zu gruppieren.
• Datenbanken:Ebene 1 ist der Ort, an dem Sie typischerweise Datenbanken (Datenbanken, Dateien, Tabellen) einführen. Dies zeigt, wo Informationen persistieren.
• Konsistenz:Jeder Datenfluss, der in Ebene 0 in das System eintritt oder es verlässt, muss in Ebene 1 erscheinen. Dies wird als Ausgleich.

📝 Beispiel-Szenario

Im Anschluss an das Bibliothekssystem zerlegt das Diagramm der Ebene 1 das „Bibliotheks-System“ in „Mitglied registrieren“, „Buch ausleihen“, „Bußen bearbeiten“ und „Bestand verwalten“. Datenbanken könnten „Mitglieder-Datenbank“ und „Buchkatalog“ sein. Der Fluss „Buch ausleihen“ aus Ebene 0 teilt sich in Flüsse auf, die mit der „Mitglieder-Datenbank“ und dem „Buchkatalog“ interagieren, in Ebene 1.

Diese Ebene beantwortet die Frage: „Was sind die Hauptfunktionen, und wo wird Daten gespeichert?“

🔬 Ebene 2: Die detaillierte Prozessansicht 🔬

DFD-Ebenen 2 tauchen tiefer in spezifische Prozesse ein, die in Ebene 1 identifiziert wurden. Ein einzelner Prozess der Ebene 1 könnte zu komplex sein, um ihn vollständig zu verstehen, daher wird er weiter aufgeteilt. Nicht jeder Prozess benötigt ein Diagramm der Ebene 2; nur solche, die eine detaillierte Spezifikation erfordern.

🎯 Wann man Ebene 2 verwendet

• Detaillierte Spezifikation: Wird verwendet, wenn technische Anforderungen für Entwickler verfasst werden.
• Komplexe Logik: Prozesse, die mehrere Entscheidungspunkte oder Berechnungen beinhalten.
• Modernisierung veralteter Systeme: Abbildung bestehender komplexer Abläufe auf neue Systeme.

⚙️ Hauptkomponenten

• Unterprozesse: Aufteilung der Level-1-Prozesse. Zum Beispiel wird „Buch ausleihen“ zu „Mitglied prüfen“, „Bestand aktualisieren“ und „Beleg generieren“.
  • Beschränken Sie die Anzahl der Unterprozesse, um Überlastung zu vermeiden.
• Eingabe/Ausgabe-Details: Zeigen Sie genau, welche Datenbestandteile zwischen diesen Unterprozessen übergeben werden.
• Steuerlogik: Obwohl DFDs keine Logik wie Code zeigen, deutet Level 2 oft auf Entscheidungspunkte hin (z. B. „Wenn Mitglied gültig, fortfahren“).

📝 Beispiel-Szenario

Im Bibliotheksbeispiel wird der Prozess „Bußen verarbeiten“ aus Level 1 aufgegliedert. Es könnte „Verzögerungstage berechnen“, „Gebührensatz anwenden“ und „Kontostand aktualisieren“ zeigen. Diese Ebene stellt sicher, dass die Logik zur Berechnung von Bußen klar und mit den Geschäftsregeln konsistent ist.

Diese Ebene beantwortet die Frage:„Wie funktioniert genau diese spezifische Funktion?“

📊 Vergleich der DFD-Ebenen

Funktion	Ebene 0 (Kontext)	Ebene 1 (Hochlevel)	Ebene 2 (Detailliert)
Umfang	Gesamtsystem	Wichtige Untersysteme	Spezifische Prozesse
Anzahl der Prozesse	1	5 bis 9	Variable (Tiefenuntersuchung)
Datenbanken	Keine	Hauptdatenbanken	Detaillierte Speicherung
Zielgruppe	Interessenten, Führungskräfte	Architekten, Manager	Entwickler, Analysten
Zeitpunkt	Anforderungsphase	Entwurfsphase	Implementierungsphase
Schwerpunkt	Grenzen	Funktionalität	Logik & Daten

🛠️ Best Practices für die DFD-Modellierung

Die Erstellung genauer Diagramme erfordert Disziplin. Die Einhaltung bestimmter Regeln stellt sicher, dass Ihre Dokumentation während des gesamten Projektzyklus nützlich bleibt.

1. Gleichgewicht beibehalten

Wenn Sie einen Prozess von Ebene 0 auf Ebene 1 zerlegen, müssen Eingaben und Ausgaben übereinstimmen. Wenn Ebene 0 „Benutzeranmeldeanforderung“ als Eingang in das System zeigt, muss Ebene 1 dasselbe Datenpaket als Eingang in den „Authentifizierungsprozess“ anzeigen. Wenn Daten verschwinden oder aus dem Nichts auftauchen, ist das Diagramm ungültig.

2. Namenskonventionen

• Prozesse:Verwenden Sie eine Verb-Nomen-Struktur (z. B. „Bestellung validieren“, nicht „Bestellungsvalidierung“). Dies betont die Aktion.
• Datenflüsse:Verwenden Sie Nomen-Phrasen (z. B. „Kundendaten“, „Rechnung“).
• Entitäten:Verwenden Sie Singular-Nomen (z. B. „Kunde“, nicht „Kunden“).

3. Vermeiden Sie Daten-Spaghetti

Zeichnen Sie keine Datenflüsse, die sich übermäßig überschneiden. Wenn ein Diagramm zu einem Netz aus Linien wird, ist es wahrscheinlich zu komplex. Überlegen Sie, einen Prozess der Ebene 1 in separate Diagramme aufzuteilen.

4. Kein Querverkehr

Externe Entitäten sollten nicht direkt miteinander kommunizieren. Alle Kommunikation muss über den Systemprozess laufen. Wenn das „Lager“ Daten an das „Abrechnungssystem“ sendet, muss dies über den „Auftragsverarbeitungs“-Prozess erfolgen.

5. Datenbanken begrenzen

Zu viele Datenbanken verwirren den Leser. Fügen Sie nur Speicherstellen hinzu, die für die aktuelle Detailtiefe notwendig sind. Wenn eine Speicherstelle nur in Ebene 2 verwendet wird, muss sie möglicherweise nicht in Ebene 1 erscheinen.

🚫 Häufige Fehler, die vermieden werden sollten

Selbst erfahrene Analysten machen Fehler. Die frühzeitige Erkennung dieser Fehler spart Zeit bei Überprüfungen.

• Schwarze Löcher: Ein Prozess ohne Ausgabe. Dies deutet darauf hin, dass Daten verschwinden, was logisch unmöglich in einem funktionierenden System ist.
• Wunder: Ein Prozess ohne Eingabe. Daten können nicht aus dem Nichts entstehen.
• Graue Löcher: Ein Prozess, der Eingaben hat, aber Ausgaben erzeugt, die von den erwarteten abweichen. Dies deutet meist auf fehlende Logik hin.
• Zu viel Detail zu früh: Das Zeichnen von Ebenen-2-Diagrammen, bevor Ebene 1 genehmigt ist, führt zu Nacharbeit. Bleiben Sie bei der Hierarchie.
• Ignorieren von Datenbanken:Das Auslassen der Darstellung, wo Daten gespeichert werden, macht das System flüchtig und unwahr­scheinlich.

📋 Umsetzungsstrategie

Wie sollten Sie bei der Erstellung dieser Diagramme für ein neues Projekt vorgehen? Folgen Sie diesem strukturierten Ablauf.

Phase 1: Abgrenzung des Umfangs

Beginnen Sie mit dem Diagramm der Ebene 0. Identifizieren Sie den Systemnamen und alle externen Entitäten. Machen Sie sich noch keine Gedanken über interne Prozesse. Holen Sie die Zustimmung des Projektsponsors zur Grenze ab.

Phase 2: Funktionale Zerlegung

Erstellen Sie das Diagramm der Ebene 1. Identifizieren Sie die Hauptprozesse. Stellen Sie sicher, dass alle Datenbanken definiert sind. Überprüfen Sie, ob die Datenflüsse aus Ebene 0 hier vorhanden sind. Hier entsteht die Architektur.

Phase 3: Detaillierte Logik

Wählen Sie komplexe Prozesse aus Ebene 1 aus, die Klärung benötigen. Erstellen Sie für diese spezifischen Bereiche Diagramme der Ebene 2. Verwenden Sie dies für die Übergabe an Entwickler und Spezifikationen für Unit-Tests.

Phase 4: Pflege

DFDs sind nicht statisch. Wenn sich das System ändert, müssen die Diagramme aktualisiert werden. Ein veraltetes DFD ist schlimmer als kein DFD überhaupt. Legen Sie eine Regel fest, dass Diagramme mit jedem Release-Zyklus aktualisiert werden müssen.

🤝 Integration mit anderen Techniken

DFDs existieren nicht im Vakuum. Sie arbeiten am besten, wenn sie mit anderen Modellierungsmethoden kombiniert werden.

• Entitäts-Beziehungs-Diagramme (ERD):DFDs zeigen Bewegung; ERDs zeigen Struktur. Verwenden Sie ERDs, um die in Ihren DFDs gezeigten Datenbanken zu definieren.
• Use-Case-Diagramme: Use-Case-Diagramme konzentrieren sich auf die Benutzerinteraktion. DFDs konzentrieren sich auf Daten. Sie ergänzen sich gegenseitig in der Dokumentation von Anforderungen.
• Sequenzdiagramme: Sequenzdiagramme zeigen die zeitliche Abfolge. DFDs zeigen die Struktur. Verwenden Sie Sequenzdiagramme, um die zeitliche Abfolge der Datenflüsse in Prozessen der Stufe 2 zu klären.

📝 Zusammenfassung der Verwendung

Die Auswahl der richtigen DFD-Stufe hängt von der Zielgruppe und dem Ziel der Dokumentation ab.

• Verwenden Sie Stufe 0um Grenzen und Umfang zu definieren.
• Verwenden Sie Stufe 1um Architektur und Hauptfunktionen zu definieren.
• Verwenden Sie Stufe 2um Logik und Implementierungsdetails zu definieren.

Durch strikte Einhaltung der Regeln der Zerlegung und Abstimmung schaffen Sie eine klare Wegleitung für die Systementwicklung. Diese Klarheit verringert Missverständnisse zwischen Geschäftssachverständigen und technischen Teams. Denken Sie daran, dass das Ziel nicht nur darin besteht, Bilder zu zeichnen, sondern sicherzustellen, dass ein gemeinsames Verständnis darüber besteht, wie Daten das Geschäft unterstützen.

Investieren Sie Zeit in die richtige Hierarchiestruktur. Eine gut strukturierte Reihe von Datenflussdiagrammen bringt Gewinne während der Entwicklungs- und Wartungsphasen jedes Softwareprojekts.