Visual Paradigm Desktop | 
Visual Paradigm Online
Die Erstellung eines Datenflussdiagramms (DFD) ist ein bedeutender Meilenstein in der Systemanalyse. Es zeigt die Bewegung von Daten durch ein System und definiert, wie Informationen verarbeitet, gespeichert und übertragen werden. Ein Diagramm, das optisch ansprechend wirkt, ist jedoch nicht zwangsläufig funktional korrekt. Die Validierung ist die entscheidende Phase, in der überprüft wird, ob das Diagramm die Systemanforderungen ohne logische Fehler korrekt darstellt. Dieser Prozess stellt sicher, dass die Datenflüsse konsistent sind, die Prozesse ausgewogen sind und die Struktur die vorgesehene Geschäftslogik unterstützt.
Die Validierung ist kein einzelner Schritt, sondern eine disziplinierte Überprüfung. Sie erfordert einen systematischen Ansatz, um jedes Element anhand festgelegter Regeln zu prüfen. Durch die Einhaltung eines strukturierten Überprüfungsprozesses beseitigen Sie Mehrdeutigkeiten und stellen sicher, dass das Diagramm als zuverlässiger Bauplan für die Entwicklung und die Kommunikation mit Stakeholdern dient. Diese Anleitung beschreibt die umfassenden Schritte, die erforderlich sind, um Ihr DFD effektiv zu validieren und so Genauigkeit und Konsistenz im gesamten Systemdesign zu gewährleisten.
Bevor Sie in die konkreten Schritte einsteigen, ist es entscheidend, zu verstehen, was die Validierung im Kontext der Systemgestaltung bewirkt. Die Verifikation fragt: „Bauen wir das Produkt richtig?“ Die Validierung fragt: „Bauen wir das richtige Produkt?“ Im Kontext von DFDs schließt die Validierung die Lücke zwischen abstrakten Anforderungen und konkretem Systemverhalten.
Ein validiertes DFD stellt sicher:
Das Überspringen dieser Phase führt oft zu kostspieligen Nacharbeiten im Entwicklungsstadium. Probleme wie fehlende Datenflüsse oder undefinierte Datenbestände sind teuer zu beheben, sobald der Code geschrieben wird. Ein strenger Überprüfungsprozess mindert diese Risiken frühzeitig.
Stellen Sie vor Beginn der formellen Überprüfung sicher, dass das Diagramm einer gründlichen Prüfung zugänglich ist. Ein unübersichtliches oder schlecht strukturiertes Diagramm erschwert die Validierung. Verwenden Sie die folgende Checkliste, um Ihre Arbeit vorzubereiten:
Das Kontextdiagramm ist die höchste Abstraktionsstufe. Es zeigt das System als einen einzigen Prozess und seine Interaktion mit externen Entitäten. Dies ist die erste Verteidigungslinie bei der Validierung.
Externe Entitäten stellen Quellen oder Ziele von Daten außerhalb der Systemgrenzen dar. Stellen Sie sicher, dass jede dargestellte Entität notwendig und eindeutig definiert ist. Stellen Sie die folgenden Fragen:
Der einzelne Prozess, der das System darstellt, muss alle internen Logik enthalten. Stellen Sie sicher, dass keine Datenströme die Grenze überschreiten, ohne diesen Prozess zu passieren. Wenn Daten von einer externen Entität zu einer anderen gelangen, ohne das System zu betreten, sollte dies nicht im Kontextdiagramm dargestellt werden, da es außerhalb des Umfangs liegt.
Überprüfen Sie jeden Pfeil, der mit dem zentralen Prozess verbunden ist. Jeder Eingang muss einer entsprechenden Ausgabe oder Speicheraktion entsprechen. Wenn ein Datenstrom das System betritt, aber kein Datenstrom verlässt, könnte dies auf einen „Schwarzen Loch“-Prozess hindeuten, bei dem Daten ohne Zweck verschwinden.
Der Level-0-DFD zerlegt den einzelnen Prozess des Kontextdiagramms in Hauptunterkomponenten. Die wichtigste Regel hier istAusgleich. Die Eingänge und Ausgänge des Elternprozesses müssen genau mit den Eingängen und Ausgängen der Kindprozesse übereinstimmen.
Für jeden Datenstrom, der in den Prozess des Kontextdiagramms eintritt, muss ein entsprechender Datenstrom in das Level-0-Diagramm eintritt. Das Gleiche gilt für Ausgänge. Dies wird als Datenkonservierung bezeichnet. Wenn das Kontextdiagramm „Kundenbestellung“ zeigt, die in das System eintreten, muss das Level-0-Diagramm „Kundenbestellung“ zeigen, die in mindestens einen der Hauptprozesse eintreten.
Level 0 enthält typischerweise zwischen 3 und 7 Prozessen. Wenn Sie mehr als 7 haben, könnte das Diagramm für eine einzelne Ansicht zu komplex sein. Wenn Sie weniger als 3 haben, müssen Sie möglicherweise weiter zerlegen. Stellen Sie sicher, dass jeder Prozess eindeutig ist und eine einzelne logische Funktion ausführt.
Stellen Sie sicher, dass jeder Datenbestand im Level 0 notwendig ist. Ein Datenbestand sollte nur existieren, wenn Daten für eine spätere Verwendung aufbewahrt werden müssen. Stellen Sie sicher, dass Datenströme in und aus Beständen korrekt beschriftet sind. Datenbestände sollten nicht direkt mit externen Entitäten verbunden sein; alle Daten müssen durch einen Prozess laufen.
Level-N-Diagramme liefern weitere Details zu spezifischen Prozessen, die im Level-0 identifiziert wurden. Die Validierung auf dieser Ebene konzentriert sich auf die Konsistenz mit dem Elternprozess.
Genau wie beim Level 0 müssen die Eingänge und Ausgänge eines Elternprozesses mit den aggregierten Eingängen und Ausgängen seiner Kinder übereinstimmen. Wenn der Prozess 1.0 im Level-0-Diagramm „Anmeldeinformationen“ entgegennimmt und „Zugriffstoken“ ausgibt, muss die Level-1-Zerlegung des Prozesses 1.0 ebenfalls „Anmeldeinformationen“ entgegennehmen und „Zugriffstoken“ erzeugen.
Stellen Sie sicher, dass die Zerlegung logisch ist. Erklärt das Kinddiagrammwiewie der Elternprozess funktioniert? Vermeiden Sie, in einem Kinddiagramm neue externe Entitäten oder Datenbestände einzuführen, die im Elterndiagramm nicht impliziert waren. Wenn ein neuer Datenbestand eingeführt wird, muss dies durch die Notwendigkeit zur Datenspeicherung gerechtfertigt werden.
Beschriftungen von Datenströmen in Kinddiagrammen müssen mit den Beschriftungen im Elterndiagramm übereinstimmen, wo anwendbar. Wenn ein Strom in einem Kinddiagramm verfeinert wird (z. B. „Daten“ wird zu „Benutzerdaten“), muss die Änderung mit dem Datenwörterbuch konsistent sein. Unklarheiten führen hier zu Verwirrung bei der Implementierung.
Es gibt bestimmte strukturelle Anomalien, die auf Fehler in der DFD-Designs hindeuten. Diese häufigen Muster müssen bei der Validierung erkannt und korrigiert werden.
Ein Schwarzes Loch-Verfahren ist eines, das Eingaben hat, aber keine Ausgaben. Daten betreten das Verfahren und verschwinden. Dies deutet normalerweise auf einen fehlenden Ausgangsfluss oder eine unvollständige Prozessdefinition hin. Jeder Prozess muss ein Ergebnis erzeugen, entweder Daten, die gespeichert werden sollen, Daten, die an einen anderen Ort gesendet werden sollen, oder ein Entscheidungsergebnis.
Ein Wunder-Verfahren ist eines, das Ausgaben hat, aber keine Eingaben. Es erzeugt Daten aus dem Nichts. Dies ist logisch unmöglich bei der Systemgestaltung. Jede Ausgabe muss aus Eingabedaten generiert oder aus gespeicherten Daten abgeleitet werden.
Ein Graues Loch tritt auf, wenn die Eingaben logisch nicht mit den Ausgaben übereinstimmen. Zum Beispiel, wenn die Eingabe „Kundenadresse“ ist und die Ausgabe „Zahlungsdetails“ lautet, führt der Prozess mehr als nur eine Transformation durch; er erzeugt Daten, die nicht aus der Eingabe abgeleitet werden können. Dies deutet auf fehlende Datenflüsse oder fehlende Datenbanken hin.
Stellen Sie sicher, dass Datenflüsse nicht direkt von einer externen Entität zu einem Datenbank-Speicher gehen. Alle Daten, die in einen Speicher eintreten oder ihn verlassen, müssen durch einen Prozess gehen. Dadurch wird sichergestellt, dass Integritätsregeln für Daten und Geschäftslogik vor der Speicherung angewendet werden.
Verwenden Sie diese Tabelle als schnellen Referenzpunkt während Ihrer Überprüfungsphasen. Sie fasst die wichtigsten Regeln und die spezifischen Überprüfungen für jedes Element zusammen.
| Element | Überprüfungsregel | Häufiger Fehler |
|---|---|---|
| Prozess | Muss mindestens eine Eingabe und eine Ausgabe haben | Schwarzes Loch- oder Wunder-Prozess |
| Datenbank-Speicher | Muss mit einem Prozess verbunden sein, nicht mit einer Entität | Direkter Fluss von Entität zu Speicher |
| Datenfluss | Muss mit einem Substantiv-Phrasen beschriftet werden | Verben als Beschriftung oder fehlende Beschriftung |
| Externe Entität | Muss außerhalb der Systemgrenzen liegen | Entität innerhalb der Systemgrenze |
| Konsistenz | Eltern- und Kind-Eingaben/Ausgaben müssen übereinstimmen | Ungleichgewogene Datenflüsse |
| Zerlegung | Das Kind muss erklären, „Wie“, nicht „Warum“ | Hinzufügen von Logik außerhalb des Umfangs |
Validierung ist nicht nur eine technische Prüfung; sie ist ein Kommunikationsinstrument. Sobald die technischen Regeln erfüllt sind, muss das Diagramm von den Stakeholdern überprüft werden, um sicherzustellen, dass die geschäftlichen Anforderungen erfüllt werden.
Stellen Sie das Diagramm nicht isoliert vor. Bereiten Sie eine Erklärung vor, die den Datenfluss erläutert. Geben Sie Kontext dafür, warum bestimmte Datenbanken existieren und wie die Prozesse miteinander interagieren. Stellen Sie sicher, dass alle Stakeholder Zugriff auf das Datenwörterbuch haben, um die Fachbegriffe zu verstehen.
Ermuntern Sie die Stakeholder, den Fluss zu hinterfragen. Stellen Sie spezifische Fragen wie:
Notieren Sie alle Rückmeldungen und vorgeschlagenen Änderungen. Wenn ein Stakeholder einen neuen Datenfluss vorschlägt, prüfen Sie ihn vor der Annahme auf Übereinstimmung mit den Ausgleichsregeln. Aktualisieren Sie das Diagramm und das Datenwörterbuch gleichzeitig, um die Synchronisation aufrechtzuerhalten. Die Versionsverwaltung ist entscheidend; führen Sie Aufzeichnungen über den Zustand des Diagramms in jeder Überprüfungsphase.
Die Validierung ist selten ein einmaliger Vorgang. Während sich die Anforderungen entwickeln, muss auch das DFD sich weiterentwickeln. Dieser Abschnitt beschreibt, wie Änderungen während des Projektlebenszyklus verwaltet werden können.
Wenn eine Änderung beantragt wird, analysieren Sie deren Auswirkung auf die gesamte Hierarchie. Wenn sich ein Prozess auf Ebene 1 ändert, beeinflusst er dann Ebene 0? Ist ein neuer Datenbestand erforderlich? Beeinflusst es andere Prozesse, die denselben Datenfluss teilen? Die Durchführung einer solchen Auswirkungsanalyse verhindert kaskadenartige Fehler.
Führen Sie eine klare Historie der Diagrammänderungen. Verwenden Sie Versionsnummern (z. B. v1.0, v1.1) und Änderungsdaten. Dadurch kann das Team verfolgen, wie sich das Systemdesign entwickelt hat, und Änderungen bei Bedarf rückgängig machen. Obwohl spezifische Werkzeuge nicht erforderlich sind, ist eine disziplinierte Namenskonvention für Dateien unerlässlich.
Führen Sie nach der Umsetzung von Änderungen den Validierungsprozess erneut durch. Nehmen Sie nicht an, dass eine kleine Änderung die Integrität des Gesamten bewahrt. Überprüfen Sie erneut die Ausgleichsregeln, die Namenskonventionen und die strukturelle Integrität. Eine kleine Ergänzung kann manchmal das Gleichgewicht eines bereits validierten Diagramms stören.
Das Datenwörterbuch ist die Grundlage Ihres DFD. Es definiert die Struktur jedes Datenelements. Die Validierung muss über die visuelle Darstellung hinausgehen und die textlichen Definitionen umfassen.
Stellen Sie sicher, dass die Bezeichnungen für Datenflüsse im Diagramm exakt mit den Einträgen im Datenwörterbuch übereinstimmen. Wenn das Diagramm „Rechnungs-ID“ und das Wörterbuch „Rechnungs-Identifikator“ sagt, kann diese Unstimmigkeit während der Datenbankgestaltung zu Verwirrung führen. Standardisieren Sie die Terminologie in allen Dokumenten.
Überprüfen Sie, ob jedes Datenlager im Wörterbuch eine definierte Struktur hat. Listen Sie die Attribute, Datentypen und Schlüsselbeschränkungen auf. Wenn ein Datenlager im DFD referenziert wird, aber kein Eintrag im Wörterbuch hat, ist die Gestaltung unvollständig. Diese Lücke führt oft später zu Datenbankfehlern.
Stellen Sie sicher, dass die impliziten Datentypen im Diagramm den Geschäftsregeln entsprechen. Wenn beispielsweise ein Datenfluss „Geburtsdatum“ darstellt, darf er im Wörterbuch nicht als Textzeichenkette behandelt werden. Er sollte ein Datumsformat haben. Diese Detailgenauigkeit stellt sicher, dass die technische Umsetzung mit dem konzeptionellen Design übereinstimmt.
Sogar erfahrene Analysten stoßen während des Validierungsprozesses auf spezifische Fallen. Die Kenntnis dieser häufigen Fehlerhilfen hilft Ihnen, die Überprüfung effektiver zu meistern.
Sobald die Validierung abgeschlossen ist, muss die Dokumentation für die Übergabe an das Entwicklerteam finalisiert werden. Dazu gehören die Zusammenstellung der Diagramme, des Datenwörterbuchs und des Validierungsberichts.
Sammeln Sie alle Level-0-Diagramme, Level-N-Diagramme und das Kontextdiagramm in einem einzigen Paket. Stellen Sie sicher, dass die Hierarchie eindeutig gekennzeichnet ist, damit Entwickler die Aufteilung nachvollziehen können. Fügen Sie den Datenwörterbuch als Begleitdokument hinzu.
Erstellen Sie einen Zusammenfassungsbericht des Validierungsprozesses. Listen Sie alle während der Überprüfung gefundenen Probleme und deren Lösungen auf. Dieses Dokument dient als Nachweis dafür, dass das Design geprüft wurde. Es bietet auch Kontext für zukünftige Wartende, die möglicherweise nicht Teil der ursprünglichen Überprüfung waren.
Definieren Sie den Prozess für die Übergabe der validierten DFDs. Dazu gehört ein Treffen, bei dem das Design dem Entwicklerteam erklärt wird. Klären Sie Fragen zu mehrdeutigen Flüssen oder komplexen Datenbeständen. Stellen Sie sicher, dass das Team versteht, dass das DFD die Quelle der Wahrheit für die Datenanforderungen ist.
Die Arbeit endet nicht mit der Validierung. Das Diagramm muss genau bleiben, während sich das System weiterentwickelt. Legen Sie ein Governance-Verfahren für zukünftige Änderungen fest.
Durch die Einhaltung dieser Validierungsschritte stellen Sie sicher, dass Ihre Datenflussdiagramme robust, genau und im gesamten Systemlebenszyklus nützlich sind. Diese Disziplin reduziert Mehrdeutigkeiten, verhindert kostspielige Fehler und legt eine solide Grundlage für den erfolgreichen Systementwicklung.