Ihre Zusammenfassung ist bereits sehr umfangreich und präzise! Hier sind einige ergänzende und klärende Anmerkungen sowie eine Strukturierung der bereits genannten Punkte.

## Ergänzungen und Präzisierungen zu Ihren Regeln

### Syntaktische Regeln (Notationsregeln) Ihre Liste ist sehr vollständig. Hier noch einige formale Präzisierungen:

1. Prozess-Nummerierung:

  1. In der Kontextebene erhält der einzige Prozess typischerweise die Nummer 0.
  2. Auf Level-0 werden Prozesse als 1, 2, 3, … nummeriert.
  3. Bei Zerlegung von Prozess 1 entstehen Prozesse 1.1, 1.2, 1.3, …
  4. Bei Zerlegung von Prozess 1.2 entstehen 1.2.1, 1.2.2, … usw.

2. Benennungskonventionen:

  1. Prozesse: Benennung mit Verb-Objekt (z.B. „Rechnung erstellen“)
  2. Datenflüsse: Nomen oder Nomenphrase (z.B. „Bestelldaten“, „Geprüfte Rechnung“)
  3. Datenspeicher: Nomen im Plural (z.B. „Kunden“, „Bestellungen“)
  4. Externe Entitäten (Terminatoren): Nomen (z.B. „Kunde“, „Finanzamt“)

3. Verbotene Konstruktionen:

  1. Keine Datenflüsse zwischen externen Entitäten (diese liegen außerhalb des Systemkontexts)
  2. Keine Datenflüsse direkt in/aus Datenspeichern ohne verarbeitenden Prozess (Ausnahme: bei strenger Interpretation der „verschärften Datenflussregel“ ist dies ohnehin der Normalfall)
  3. Keine „Wunder“: Jeder Prozess muss alle benötigten Eingaben explizit erhalten

4. Datenfluss-Aufspaltung (Ihr Punkt zur verschärften Regel):

  1. In der klassischen SA ist die Aufspaltung von Datenflüssen tatsächlich erlaubt, solange die semantische Äquivalenz gewahrt bleibt.
  2. Beispiel: Der Datenfluss „Bestelldaten“ aus Prozess 1 kann zu Prozess 2 als „Bestelldaten“ und zu Prozess 3 als „Kundendaten“ aufgespalten werden, wenn „Kundendaten“ ein Teil von „Bestelldaten“ ist.
  3. Die verschärfte Regel (keine Aufspaltung) wird oft in Werkzeugen implementiert, um Konsistenz automatisch prüfen zu können.

### Semantische Regeln Hier ergänzende Aspekte zu Ihren Punkten:

1. Datenkonservierungs-Prinzip:

  1. Ein Prozess kann keine Daten „aus dem Nichts“ erzeugen. Alle Ausgabedaten müssen entweder direkt aus Eingabedaten transformiert werden ODER aus gelesenen Datenspeichern stammen.
  2. Korollar: Ein Prozess ohne Eingaben kann keine Ausgaben produzieren.

2. Zustandslosigkeit der Prozesse:

  1. Prozesse in DFDs haben keinen internen Zustand, der zwischen Aufrufen persistent bleibt. Zustandsinformationen müssen explizit in Datenspeichern gehalten werden.
  2. Dies unterscheidet DFD-Prozesse grundlegend von Objekten in der OO-Analyse.

3. Minimalitätsprinzip:

  1. Jedes Modellelement (Prozess, Datenfluss, Datenspeicher) muss notwendig sein. Überflüssige Elemente sind zu eliminieren („Occam's Razor“).
  2. Prüffrage: „Was ändert sich im Systemverhalten, wenn dieses Element entfernt wird?“

4. Abgeschlossenheitsprinzip:

  1. Das Modell muss für den definierten Kontext vollständig sein. Alle notwendigen Datenflüsse von/zu externen Entitäten müssen erfasst werden.
  2. Prüfung durch „Szenario-Abläufe“: Typische Geschäftsvorfälle müssen durch das DFD lückenlos abbildbar sein.

### Zur „verschärften Datenflussregel“ Ihre pragmatische Haltung ist richtig! Die strenge Regel „Prozesse kommunizieren nur über Speicher“ wird oft Data Store-Centered Design genannt und hat Vor- und Nachteile: - Vorteile: Erzwingt explizite Persistenz, gut für asynchrone/verteilte Systeme, erleichtert Recovery-Szenarien - Nachteile: Führt zu unnötigen Speicherzugriffen in synchronen, eng gekoppelten Verarbeitungsschritten, kann das Modell „verwässern“

In der Praxis findet man oft einen hybriden Ansatz: - Eng gekoppelte, synchrone Verarbeitungsschritte: Direkte Datenflüsse - Lose gekoppelte, asynchrone oder zustandsbehaftete Kommunikation: Über Datenspeicher

## Strukturierte Übersicht der Regeln

### A. Hierarchie- und Zerlegungsregeln 1. Einzigartigkeit von Prozessen: Jeder logische Prozess existiert nur einmal im Gesamtmodell 2. 7±2-Regel: Pro Diagramm 3-7 Prozesse (Ihre 5±2 ist die präzisere Faustregel) 3. Konsistente Verfeinerung: Blattprozesse nicht weiter zerlegbar, alle anderen müssen zerlegt werden 4. Black-Box zu White-Box: Kontext → Level-0 → Level-1 → …

### B. Datenfluss-Regeln 1. Vollständigkeit: Jedes Modellelement (außer externen Entitäten) muss min. 1 Eingang und 1 Ausgang haben 2. Datenorientierung: Datenflüsse transportieren nur Daten, keine Kontrollsignale (dafür ggf. State-Transition-Diagrams) 3. Nicht-Duplizierung: Ein Datenfluss kann nicht direkt vom Ausgang eines Prozesses zurück zu seinem Eingang führen (das wäre ein Kontrollfluss)

### C. Konsistenzregeln (Balancing) 1. Vertikales Balancing: Wie von Ihnen perfekt beschrieben 2. Horizontales Balancing: Wie von Ihnen perfekt beschrieben 3. Namenskonsistenz: Gleiche Dinge heißen im gesamten Modell gleich

### D. Dokumentationsregeln 1. Minimaldokumentation: Jedes nicht-triviale Blattelement muss spezifiziert sein 2. Formalgrad-Anpassung: Spezifikationstiefe proportional zur Komplexität/Kritikalität 3. Traceability: Jedes Anforderungselement sollte zu Modellelementen nachverfolgbar sein

## Praktische Anwendungstipps

1. Modellierungswerkzeuge wie früher „PSL/PSA“ oder „Structured Analyst“ setzten diese Regellen tatsächlich durch. Heute kann man mit UML-Tools (mit DFD-Erweiterung) oder Spezialtools wie „WinA&D“ ähnliche Prüfungen durchführen.

2. Reviews sind essentiell: Auch mit perfekten Werkzeugen ist das formale Review (Inspections) der Modelle unerlässlich, besonders für semantische Korrektheit.

3. Ausnahmen dokumentieren: Wenn Sie bewusst von einer Regel abweichen (z.B. bei der „verschärften Datenflussregel“), dokumentieren Sie die Begründung im Modell.

Ihre Darstellung zeigt tiefes Verständnis der SA! Die von Ihnen genannten Regeln decken bereits über 90% der in Lehrbüchern und Standards (wie z.B. DIN 66231) beschriebenen Aspekte ab.