Logisches vs. Physisches Datenflussdiagramm

Ein logisches DFD konzentriert sich auf das Unternehmen und Geschäftstätigkeiten; ein physisches DFD stellt die Implementierung eines Systems dar. Jedes Datenflussdiagramm stellt den Informationsstrom für einen Prozess oder ein System dar: Das logische Diagramm ist für das „Was“, das physische für das „Wie“ zuständig. Es handelt sich um zwei verschiedene Perspektiven desselben Datenstroms, die jeweils das System visualisieren und verbessern sollen. Das logische DFD beschreibt die Geschäftsereignisse, die stattfinden, und die für jedes Ereignis erforderlichen Daten. Es liefert eine solide Grundlage für das physische DFD, das die Funktionsweise des Datensystems darstellt, darunter zum Beispiel beteiligte Hardware, Software, Akten und Menschen. Zusammen können die logische und die physische Komponente den aktuellen Zustand ebenso vollständig visualisieren wie den Wunschzustand, den es zu implementieren gilt.

Wenn Sie mit einem

logischen Ist-DFD

 beginnen, können Sie den Fluss der Geschäftstätigkeiten zum aktuellen Zeitpunkt darstellen und jegliche Schwächen oder Ineffizienzen ausfindig machen. Vielleicht wissen Sie auch schon, welche Funktionen Sie hinzufügen wollen. Dann hilft Ihnen das logische DFD dabei, Prozessschritte zu finden, die Sie entfernen oder ändern müssen. Wie bei jedem Diagramm sollte auch das logische DFD detailliert genug sein, um sich umsetzen zu lassen. Je nach Umfang kann es seine Zeit dauern, das logische DFD des Ist-Zustands anzulegen. Auch wenn es mühsam erscheint, ist es klug investierte Zeit.

Ein weiterer Vorteil von logischen DFDs ist die bessere Verständlichkeit für Personen ohne technische Kenntnisse. Auch solche, die direkt an den Geschäftstätigkeiten beteiligt sind, können aus solchen Diagrammen schlau werden. Sie dienen als Werkzeug zur Zusammenarbeit und Kommunikation über bessere Informationen und Funktionsabläufe, ohne dass Sie sich jetzt schon um das „Wie“ kümmern müssen. Sie schlagen eine Brücke von den Unternehmensbedürfnissen zu den technischen Anforderungen. Die Darstellung des aktuellen logischen Flusses hilft allen Beteiligten dabei, ein tiefgreifenderes Verständnis zu entwickeln, und deckt falsche Annahmen, Missverständnisse oder Mängel auf. Mit logischen Modellen reduzieren Sie das Risiko, Unternehmensanforderungen zu übersehen, die sonst später im Prozess auftauchen und Verzögerungen und Nacharbeiten verursachen würden.

Mit einem tiefgreifenden Verständnis der aktuellen Geschäftstätigkeiten können Sie anschließend eine bessere Methode mit einem

logischen Soll-DFD

 modellieren, das neue Funktionen und Eigenschaften anhand der Ergebnisse der Geschäftsanalyse zeigt. Dieses neue logische DFD modelliert die Datenflüsse, die zur Entwicklung einer besseren Funktionsweise benötigt werden – unabhängig von der technischen Lösung oder der Implementierung des Systems.

Nachdem Sie das neue logische DFD erstellt haben, können Sie damit die beste Methode zur Implementierung der Geschäftstätigkeiten in einem verbesserten System ermitteln. Dies bildet die Grundlage für das

physische Soll-DFD

, das die physische Implementierung von Geräten, Software, Dateien und Menschen darstellt, welche die Geschäftsprozesse ermöglichen. In diesem Sinne wird das physische DFD zur Anleitung für die Erfüllung der Unternehmensanforderungen. Hier unterstützt das „Wie“ das „Was“. Das physische DFD liefert dann die Grundlage für einen Implementierungsplan für neue Software, Hardware, neues Personal oder andere physische Objekte, die für die Durchführung des Geschäftsprozesses benötigt werden.

Nehmen wir beispielsweise an, dass Ihre Personalabteilung ein veraltetes System zur Verwaltung von Bewerbern verwendet. Anstatt geradewegs neue Software anzuschaffen, stellen Sie zuerst den aktuellen logischen Datenfluss im Diagramm dar. Sie zeichnen detailliert alle stattfindenden Geschäftstätigkeiten auf: Maßnahmen zur Verfassung eines Stellenangebots, für dessen Bewerbung, das Eingeben der Bewerberdaten in die Datenbank, die Benachrichtigung der Personalchefs, die Aktualisierung der Dateien, die Verfolgung der Prozessetappen, die Benachrichtigung der Kandidaten und so weiter. All das erfolgt aus der Perspektive der Geschäftstätigkeiten, nicht der Technologie oder anderer „Wie“-Komponenten. Die Darstellung zeigt den aktuellen Datenfluss und liefert die Grundlage für die Kommunikation und Zusammenarbeit für bessere Funktionen, um die notwendigen Geschäftsmaßnahmen zur Sichtung der Stellenbewerber abzuschließen. Dann zeichnen Sie einen potenziellen neuen logischen Ablauf. Dieser bietet zum Beispiel zeitnahe Benachrichtigungen für Personalchefs, sodass diese einen besseren Überblick haben. Damit können sie vielleicht schneller auf Lebensläufe zugreifen und die Qualifikationen der Finalisten vergleichen. Dieses logische Soll-DFD ist die Diskussionsgrundlage, wenn es um die beste Implementierungsmethode für eine bessere Funktion hinsichtlich Software, Hardware, Ablagesysteme und Mitarbeiter geht. All das kann in einem physischen DFD visualisiert werden. Mit letzterem können Sie dann Software-Lösungen und andere Implementierungskomponenten hinsichtlich der Erfüllung Ihrer Anforderungen bewerten. Sie können zum Beispiel zeigen, wie unterschiedliche Software-Plattformen in verschiedenen Versionen des physischen DFD funktionieren würden, und so die beste Lösung ermitteln.

Datenflussdiagramme bestehen aus vier Elementen: externen Entitäten, Prozessen, Datenspeichern und Datenflüssen. Aber die Elemente stellen in logischen und physischen DFDs jeweils andere Perspektiven dar.

Bei logischen DFDs sind die Prozesse zum Beispiel Geschäftstätigkeiten. Bei physischen DFDs stehen die Prozesse für Software, manuelle Vorgänge und andere Informationsverarbeitungsmethoden. In logischen DFDs sind die Datenspeicher unabhängig von der Speichermethode Informationssammlungen, während sie bei physischen DFDs Datenbanken, Computerdateien und Akten sind.

Logische und physische DFDs in der Softwareentwicklung:

DFDs stammen aus dem Software-Engineering und der Software-Entwicklung. Ein logisches DFD kann aktuelle und erforderliche Aktivitäten für einen Prozess erfassen. Ein logisches Soll-DFD modelliert neue Aktivitäten und Funktionen. Ein physisches Ist-DFD zeigt aktuelle Software, Hardware, Datenbanken und Menschen zur Durchführung der Aktivitäten, wohingegen physische Soll-DFDs eine neue Systemimplementierung darstellen. Diese Analyse kann eine Methode liefern, mit der Sie besser an den Programmcode gelangen, der die Anforderungen erfüllt.

In der Unternehmensanalyse:

Ein logisches DFD reduziert das Risiko, Unternehmensanforderungen zu übersehen, die sonst später im Prozess auftauchen und Verzögerungen und Nacharbeiten verursachen würden. Außerdem dient es als verständliches Kommunikationswerkzeug für Menschen ohne technische Kenntnisse, die an den Geschäftstätigkeiten beteiligt sind. Das gilt sowohl für den aktuellen Informationsfluss als auch für die vorgeschlagene neue Methode. Das physische DFD liefert dem System dann das „Wie“ zur Erfüllung der Anforderungen.

In der Strukturanalyse:

In der klassischen Strukturanalyse mit Top-Down-Ansatz wird ein logisches DFD eines aktuellen Systems entwickelt, um den Ist-Zustand zu zeigen; anschließend wird ein verbessertes System in einem logischen Soll-DFD modelliert. Im Anschluss wird mit physischen Top-Down-DFDs die geplante physische Lösung aus Software, Geräten und anderen Systemkomponenten dargestellt. In der ereignisbasierten Strukturanalyse mit Bottom-Up-Ansatz wird der Projektumfang mit einem Kontext-DFD (Level 0) gezeigt. Die nachfolgenden Level schlüsseln das Ganze in Teilprozesse auf. Dann geben wir Systemereignisse an, die eine Reaktion erfordern, und zeichnen Ereignis-DFDs zur Darstellung der Ereignisverarbeitung im Einzelfall. Diese Ereignis-DFDs können dann zu einem Systemdiagramm zusammengeführt werden.

Im Büro und der Verwaltung:

Ein logisches DFD wird verwendet, um die Geschäftstätigkeiten darzustellen, die ausgeführt werden, damit ein Büro funktioniert. Das logische Soll-DFD kann dann eine bessere Funktionsweise für die Bürodaten modellieren, zum Beispiel Personaldaten oder Kundendaten und Bestellungen. Es bildet die Grundlage, mit der Sie diese Funktionsweise erreichen können. Sie wird anschließend in einem physischen DFD in die Implementierung von neuer Software, neuen Geräten, Dateien oder Datenbanken und Menschen umgesetzt.

In der Gesundheitsversorgung:

Ein physisches Ist-DFD kann das aktuelle Datenflusssystem (bspw. für Patientendaten) darstellen. Daraus lässt sich ein logisches Ist-DFD ableiten, das die Datenfunktionen ohne das „Wie“ zeigt. Diese DFDs helfen dabei, für ein klares Verständnis der Mängel und Anforderungen für ein neues System zu sorgen. Letzteres wiederum bildet die Grundlage für ein logisches Soll-DFD und anschließend ein physisches Soll-DFD, das die neue(n) Software, Geräte, Datenbanken und anderen physischen Elemente darstellt.

Datenflussdiagramme wurden in den späten 1970er Jahren populär, als das Buch Structured Design (Strukturiertes Design) von den Computing-Pionieren Ed Yourdon und Larry Constantine erschien. Das Konzept für strukturiertes Design schlug vor allem in der Software-Entwicklung ein – was auch einen Boom der DFD-Methode zur Folge hatte. Diese Datenflussdiagramme können einfache Darstellungen von Prozessen oder auch komplexe Diagramme mit mehreren Ebenen sein, die schrittweise Einblick in die Verarbeitung von Daten bieten. Sie können für die Analyse vorhandener Systeme oder die Modellierung neuer Systeme verwendet werden. Sie nutzen definierte Symbolsysteme, um die vier Komponenten darzustellen: externe Entitäten, Prozesse, Datenspeicher und Datenflüsse. Die häufigsten Symbolsysteme sind nach Ihren Schöpfern benannt: Yourdon und Coad, Yourdon und DeMarco sowie Gane und Sarson.

Notation	Yourdon und Coad	Gane und Sarson
Externe Entität
Prozess		​
Datenspeicher
Datenfluss

DFD-Ebenen werden mit 0, 1 oder 2 nummeriert und gehen manchmal sogar bis zu Ebene 3 oder noch weiter. Wie detailliert Ihr DFD sein soll, hängt davon ab, was Sie damit erreichen möchten. Das DFD Ebene 0 wird auch als Kontextdiagramm bezeichnet. Es liefert einen grundlegenden Überblick über ein komplettes System oder einen Prozess, das/der analysiert oder modelliert werden soll. Das DFD Ebene 1 bietet eine detailliertere Aufschlüsselung der einzelnen Teile eines Kontextdiagramms. Ein solches Diagramm hebt die wichtigsten Aufgaben, die vom System durchgeführt werden, hervor und spaltet die allgemein dargestellten Prozesse des Kontextdiagramms in untergeordnete Prozesse auf. Das DFD Ebene 2 schlüsselt einzelne Teile der Ebene 1 weiter auf. Hier ist unter Umständen mehr Text notwendig, um den erforderlichen Detailgrad für die Systemfunktionen zu erreichen.

Während DFDs oft für die Prozessmodellierung von Systemen verwendet werden, erfolgt die Datenmodellierung häufig mithilfe von

Entity-Relationship-Diagrammen (ERDs)

, um zu zeigen, was mit den Daten im System passiert. Für die Objektmodellierung beschreibt die

Unified Modeling Language (UML)

am besten die Systemlogik des „Was“ und „Warum“. DFDs unterscheiden sich außerdem von

Flussdiagrammen

, welche die Schritte eines Prozesses (häufig mit einfachen Boxen und Pfeilen) zeigen. Flussdiagramme zeigen keine Eingaben oder Ausgaben von/an externe(n) Quellen und stellen auch nicht den Pfad dar, den die Daten im Prozess durchlaufen.

Möchten Sie noch mehr erfahren? Dann lesen Sie diesen detaillierten Artikel zu Datenflussdiagrammen.