Datenflussdiagramme (DFDs) dienen als Bauplan für die Systemlogik und veranschaulichen, wie Informationen durch einen Prozess fließen. Sie sind entscheidende Artefakte bei der Systemanalyse und -gestaltung und schließen die Lücke zwischen Geschäftsanforderungen und technischer Umsetzung. Ein Diagramm ohne Validierung ist jedoch lediglich eine Skizze. Um die architektonische Integrität zu gewährleisten, muss jedes DFD einer strengen Prüfung unterzogen werden.
Diese Anleitung bietet einen umfassenden Rahmen zur Validierung von Datenflussdiagrammen. Sie konzentriert sich auf strukturelle Konsistenz, logische Richtigkeit und Übereinstimmung mit Geschäftsregeln. Durch die Einhaltung dieser Prüfliste können Analysten kostspielige Nacharbeiten im späteren Verlauf des Entwicklungszyklus vermeiden.
📋 Vorbereitung vor der Validierung
Bevor die visuellen Elemente des Diagramms untersucht werden, muss der Kontext festgelegt werden. Eine Validierung kann nicht im Vakuum stattfinden. Die folgenden Voraussetzungen gewährleisten, dass der Überprüfungsprozess wirksam ist.
- Definieren der Systemgrenze:Klärlich festlegen, was innerhalb des Systems und was außerhalb liegt. Externe Entitäten (Quellen und Senken) müssen explizit definiert werden.
- Anforderungen sammeln:Die funktionalen und nicht-funktionalen Anforderungen müssen zur Verfügung stehen. Das Diagramm muss direkt diesen Spezifikationen entsprechen.
- Standards festlegen:Einvernehmen über Notationsstandards (z. B. Gane & Sarson vs. Yourdon & Coad). Die Mischung von Notationen führt zu Mehrdeutigkeiten.
- Datenwörterbuch überprüfen:Sicherstellen, dass eine Masterliste der Datenbestandteile existiert. Ein DFD kann nicht gültig sein, wenn die Datendefinitionen fehlen.
🔄 Hierarchie und Zerlegung
DFDs sind hierarchisch aufgebaut. Sie beginnen mit einem Kontextdiagramm und werden in Ebene 0, Ebene 1 und tiefere Ebenen zerlegt. Die Validierung erfordert die Überprüfung der Beziehungen zwischen diesen Ebenen.
1. Validierung des Kontextdiagramms
Das Kontextdiagramm (Ebene -1) stellt das System als einen einzigen Prozess dar. Es muss genau sein, bevor tiefere Ebenen überprüft werden.
- Einzelner Prozessknoten:Sicherstellen, dass genau ein Prozess das gesamte System darstellt.
- Externe Entitäten:Bestätigen, dass alle externen Quellen und Ziele vorhanden sind. Fehlende Entitäten deuten auf fehlende Datenflüsse hin.
- Datenflüsse:Sicherstellen, dass alle Eingaben und Ausgaben des Systems erfasst sind. Es ist keine spontane Datencreation oder -zerstörung zulässig.
2. Ebene 0 und Zerlegung
Ebene 0 zerlegt den einzelnen Prozess in wesentliche Teilprozesse. Hier beginnt die Komplexität.
- Anzahl der Prozesse:Die Anzahl der Prozesse auf eine handhabbare Menge beschränken (typischerweise 5 bis 9). Zu viele Prozesse verwirren den Leser.
- Prozessnamen:Die Namen sollten handlungsorientiert sein (Verb + Substantiv), beispielsweise „Rechnung berechnen“ anstelle von „Rechnung“.
- Datenbestände: Identifizieren Sie, wo Daten auf dieser Ebene gespeichert werden. Stellen Sie sicher, dass kein Datenspeicher direkt mit einer externen Entität verbunden ist, ohne dass dazwischen ein Prozess steht.
⚖️ Ausgleichsregeln
Eine der häufigsten Fehler bei der Erstellung von DFDs ist die Verletzung der Ausgleichsregel. Diese Regel besagt, dass die Eingaben und Ausgaben eines übergeordneten Prozesses genau mit den Eingaben und Ausgaben seiner untergeordneten Prozesse übereinstimmen müssen.
- Eingabekonservierung: Wenn ein übergeordneter Prozess „Kundenbestellung“ erhält, müssen die untergeordneten Prozesse gemeinsam „Kundenbestellung“ erhalten. Es können keine neuen Eingaben auf der Kind-Ebene erscheinen, die nicht bereits im übergeordneten Prozess vorhanden waren.
- Ausgabekonservierung: Wenn ein übergeordneter Prozess „Rechnung“ sendet, müssen die untergeordneten Prozesse gemeinsam „Rechnung“ senden. Ausgaben dürfen nicht verschwinden oder unerwartet auftreten.
- Flussüberprüfung: Verfolgen Sie jede Linie, die den übergeordneten Prozess betritt. Verfolgen Sie jede Linie, die den übergeordneten Prozess verlässt. Stellen Sie sicher, dass sie im Kind-Diagramm vorhanden sind.
- Speicher-Konsistenz: Datenspeicher, die auf der übergeordneten Ebene zugänglich sind, müssen auch auf der untergeordneten Ebene zugänglich sein, falls dort Daten geschrieben oder gelesen werden.
Ein Ausbleiben des Ausgleichs führt zu einer Diskrepanz zwischen der hochstufigen Sicht und der detaillierten Implementierung. Es führt oft dazu, dass Entwickler Funktionen erstellen, die nicht im Umfang enthalten waren, oder kritische Datenanforderungen ignorieren.
🏷️ Namenskonventionen
Konsistenz bei der Benennung ist entscheidend für Lesbarkeit und Wartbarkeit. Mehrdeutige Namen führen zu falscher Deutung des Systemverhaltens.
- Prozesse: Verwenden Sie stets ein Verb gefolgt von einem Substantiv. Vermeiden Sie Einzelwörter.Richtig: „Bestand aktualisieren.“ Falsch: „Bestand aktualisieren“.
- Datenflüsse: Verwenden Sie Singular-Nomen.Richtig: „Artikel.“ Falsch: „Artikel“.
- Datenspeicher: Verwenden Sie Plural-Nomen.Richtig: „Bestellungen.“ Falsch: „Auftrag“.
Externe Entitäten: Verwenden Sie Eigennamen oder Geschäftstermine. Richtig: „Kunde.“ Falsch: „Benutzer“.
📊 Häufige Fehler und Validierungsrisiken
Selbst erfahrene Analysten begehen Fehler. Die folgende Tabelle zeigt häufige Verstöße und ihre möglichen Auswirkungen auf die Systemarchitektur auf.
| Prüfkategorie | Validierungskriterien | Risiko bei Ignorierung |
|---|---|---|
| Spontane Prozesse | Jeder Prozess muss mindestens einen Eingangsfluss haben. | Daten entstehen aus dem Nichts und verletzen die Systemlogik. |
| Schwarze Löcher | Jeder Prozess muss mindestens einen Ausgangsfluss haben. | Daten werden verbraucht, ohne dass ein Ergebnis entsteht, was auf eine Logiklücke hinweist. |
| Graue Löcher | Der Inhalt der Eingabedaten muss mit dem Inhalt der Ausgabedaten übereinstimmen. | Daten werden transformiert, ohne dass die Transformation klar definiert ist. |
| Direkte Entität-zu-Speicher-Verbindung | Es gibt keinen Datenfluss, der eine Entität direkt mit einem Datenspeicher verbindet. | Umgeht Geschäftsregeln und Validierungslogik. |
| Ungleichgewichtige Flüsse | Eltern- und Kindflüsse müssen übereinstimmen. | Architekturabweichung; die Implementierung stimmt nicht mit dem Entwurf überein. |
| Steuerflüsse | DFDs zeigen Daten, keine Steuersignale. | Verwirrung zwischen Datenbewegung und Systemauslösern. |
📚 Abstimmung mit der Datenwörterbuch
Ein Datenflussdiagramm ist nur so gut wie die Datendefinitionen, die es unterstützen. Das Datenwörterbuch ist die Sammlung von Metadaten, die die Struktur jedes Datenflusses und jeder Datenspeicherung definieren.
- Konsistenz der Datenbestandteile: Überprüfen Sie, ob die in der DFD genannten Datenbestandteile im Datenwörterbuch vorhanden sind.
- Datenstruktur: Überprüfen Sie die Zusammensetzung der Datenflüsse. Enthält „Kundenbestellung“ „Kunden-ID“ und „Bestelldatum“ wie definiert?
- Eindeutige Kennungen: Stellen Sie sicher, dass Primärschlüssel in Datenspeichern identifiziert sind, um die Datenintegrität zu gewährleisten.
- Aliasnamen: Wenn ein Datenbestandteil in der Dokumentation mehrere Namen hat, standardisieren Sie sie, um Verwirrung zu vermeiden.
- Datenarten: Stellen Sie sicher, dass die Datentypen (numerisch, Zeichenkette, Datum) zwischen dem Diagramm und dem Datenbankschema konsistent sind.
🤝 Überprüfung und Freigabe durch die Stakeholder
Technische Genauigkeit reicht nicht aus. Das Diagramm muss von den Geschäftsstakeholdern verstanden werden, die die Anforderungen bereitgestellt haben.
- Geschäftsterminologie: Verwenden Sie keine fachliche Fachsprache in den Beschriftungen. Verwenden Sie die Sprache, die das Geschäft verwendet.
- Durchläufe: Führen Sie eine Durchlauf-Sitzung durch, bei der die Stakeholder den Datenfluss für eine bestimmte Transaktion nachverfolgen.
- Lückenanalyse: Fragen Sie die Stakeholder, ob wichtige Geschäftstätigkeiten im Diagramm fehlen.
- Validierungsbestätigung: Erhalten Sie die formelle Zustimmung. Dies bestätigt, dass das Diagramm die vereinbarten Geschäftslogik korrekt widerspiegelt.
🛠️ Wartung und Versionskontrolle
Systeme entwickeln sich weiter. Anforderungen ändern sich. Ein DFD, der heute gültig ist, kann morgen ungültig sein. Die Wartung ist Teil des Validierungslebenszyklus.
- Änderungsmanagement: Jede Änderung der Prozesslogik erfordert eine Aktualisierung des DFD. Aktualisieren Sie den Code nicht, ohne das Diagramm zu aktualisieren.
- Versionsverwaltung: Kennzeichnen Sie Diagramme mit Versionsnummern und Datumsangaben. Führen Sie eine Historie der Änderungen, um die Entwicklung des Systems zu verstehen.
- Verknüpfung Verknüpfen Sie die DFD mit dem Anforderungsdokument. Wenn sich eine Anforderung ändert, muss der entsprechende Diagrammknoten markiert werden.
- Periodische Prüfung: Planen Sie regelmäßige Überprüfungen der DFDs im Vergleich zum tatsächlichen Systemverhalten. Es tritt im Laufe der Zeit eine Abweichung auf.
🔍 Detaillierte technische Konsistenzprüfungen
Abgesehen von den allgemeinen Regeln müssen spezifische technische Beschränkungen beachtet werden, um sicherzustellen, dass das Diagramm für die Umsetzung bereit ist.
1. Integrität der Datenspeicher
Datenspeicher stellen dauerhafte Speicher dar. Sie sollten nicht temporär sein.
- Lese-/Schreibzugriff:Stellen Sie sicher, dass jeder Prozess, der in einen Speicher schreibt, bei Bedarf auch aus ihm liest. Stellen Sie sicher, dass kein Prozess in einen Speicher schreibt, ohne dass ein Lesebedarf besteht, wenn Datenmodifikationen beteiligt sind.
- Offene/Geschlossene Grenzen:Datenspeicher sollten keine offenen Grenzen haben. Jeder Datenspeicher muss mit mindestens einem Prozess verbunden sein.
- Namensgebung der Speicher:Die Namen sollten den Inhalt widerspiegeln, z. B. „Mitarbeiterdateien“ anstelle von „Datei 1“.
2. Vollständigkeit der Prozesslogik
Prozesse stellen Transformationslogik dar.
- Transformation:Stellen Sie sicher, dass der Prozess die Daten tatsächlich verändert. Ein Prozess, der Daten lediglich durchleitet, ist ein Fluss, kein Prozess.
- Entscheidungspunkte:Obwohl DFDs die Entscheidungslogik nicht explizit darstellen (wie dies bei Flussdiagrammen der Fall ist), sollten die Flussbezeichnungen bei Bedarf Bedingungen implizieren (z. B. „Gültige Bestellung“ gegenüber „Ungültige Bestellung“).
- Externe Abhängigkeiten:Wenn ein Prozess von einem externen System abhängt, sollte er als externe Entität oder als Unterverarbeitung dargestellt werden, nicht als magische Box.
3. Richtungsrichtigkeit der Flüsse
Pfeile zeigen die Richtung der Datenbewegung an.
- Einzelrichtung:Pfeile müssen von der Quelle zur Zielposition zeigen. Verwenden Sie keine doppeltköpfigen Pfeile, es sei denn, der Datenfluss ist in derselben Schritt wirklich bidirektional.
- Klarheit der Beschriftung:Jeder Pfeil muss eine Beschriftung haben. Unbeschriftete Flüsse sind mehrdeutig.
- Keine Kreuzungen:Minimieren Sie sich kreuzende Linien. Wenn Linien sich kreuzen, verwenden Sie ein Kreuzungssymbol oder überarbeiten Sie die Anordnung, um die Lesbarkeit zu verbessern.
🧠 Reduzierung der kognitiven Belastung
Ein gültiger DFD ist nicht nur technisch korrekt; er muss kognitiv zugänglich sein. Wenn das Diagramm zu komplex ist, misslingt seine primäre Aufgabe: die Kommunikation.
- Modularität:Zerlegen Sie komplexe Prozesse in Teilprozesse. Wenn ein Prozess mehr als 7 Eingaben oder Ausgaben hat, sollten Sie ihn zerlegen.
- Visuelle Hierarchie:Verwenden Sie konsistige Formen für Prozesse, Rauten für Datenbanken (abhängig von der Notation) und Rechtecke für Entitäten. Konsistenz verringert die kognitive Belastung.
- Leerraum:Geben Sie zwischen Elementen Platz. Überladene Diagramme verbergen Fehler.
- Farbcodierung:Verwenden Sie Farben, um verschiedene Arten von Flüssen (z. B. Eingabe vs. Ausgabe) zu unterscheiden, falls das Werkzeug dies zulässt, achten Sie jedoch darauf, dass die Ausgabe in Schwarz-Weiß lesbar bleibt.
📝 Abschließende Überlegungen
Die Validierung ist ein iterativer Prozess. Sie gelingt selten beim ersten Versuch. Ziel ist es, ein Modell zu erstellen, das robust, klar und mit der Realität übereinstimmt.
- Iterative Verbesserung:Bereiten Sie sich darauf vor, das Diagramm mehrfach zu überarbeiten. Jede Überarbeitung sollte die Klarheit erhöhen.
- Dokumentenhygiene:Halten Sie das Diagramm mit der Dokumentation synchron. Wenn der Text etwas anderes sagt als das Diagramm, wird das System versagen.
- Schulung:Stellen Sie sicher, dass das Team die Notation versteht. Eine Checkliste ist nutzlos, wenn die Überprüfer die Symbole nicht verstehen.
- Werkzeuge:Verwenden Sie Modellierungswerkzeuge, die Syntaxregeln durchsetzen. Obwohl die Checkliste manuell ist, können Werkzeuge grundlegende Überprüfungen wie das Ausbalancieren automatisieren.
Durch die Einhaltung dieses umfassenden Checklists stellen Sie sicher, dass die Datenflussdiagramme als zuverlässige Grundlage für das System dienen. Sie werden zu einem lebendigen Dokument, das die Entwicklung leitet und die Geschäftslogik validiert. Diese Disziplin reduziert das Risiko, verbessert die Kommunikation und stellt sicher, dass das Endprodukt die vorgesehenen Anforderungen erfüllt.
Denken Sie daran, dass das Diagramm ein Werkzeug zum Denken ist, kein bloßes Ergebnis. Die Validierung des Diagramms zwingt den Analysten, logische Lücken zu erkennen, die sonst bis zum Testbeginn verborgen blieben. Nehmen Sie sich die Zeit, gründlich zu validieren.