Strukturierte Analyse nach Tom DeMarco und Edward Yourdon

Die strukturierte Analyse zielt darauf ab, ein logisches Modell des zu entwickelnden Systems durch funktionale Dekomposition zu erstellen, das soll unabhängig von technischen Implementierungsdetails erfolgen. Sie folgt dem Prinzip „Was“ vor „Wie“. Zentrale Modellierungswerkzeuge (die „heilige Dreifaltigkeit“)

KURZ: Das Ziel der SA ist es ALLE benötigten elementaren Funktionen mit deren VOLLSTÄNDIGEN Input und Output zu finden bevor irgendetwas programmiert wird. Mit dieser dann vollständigen Beschreibung aller elementaren Funktionen können diese getrennt durch verschiedenen Entwickler / Teams eineln und isoliert programmiert und später durch das Master-Team zu einem großen ganzen System zusammengesetzt werden… soweit der Wunschgedanke

• Grafische Darstellung der Datenflüsse durch das System.
• Nur vier Modellelemente zulässig
  1. Prozesse (EVA)
  2. Speicher (ruhende Daten / persistente Daten)
  3. Externe Terminatoren (Daten-Quellen/Senken)
  4. und die Datenflüsse (bewegte Daten / aktuelle Daten / temporäre Daten) dazwischen.
• Die DFDs werden schrittweise von der Kontextsicht (Sytem-Überblick / Außenansicht) bis hin zu detailliert DFDs (Level 0, 1, 2 …) zerlegt (funktionale Dekomposition).

Gedanke: DFD und die damit einhergehende Methodik wäre mit SysML IDBs Block + Flow sehr schön nachbildbar wenn Blöcke als logische Funktionsbausteine angesehen werden. Minispec-Level-N erinnert sehr an Parametric Diagram mit den Constraints-Blöcken siehe dazu 3. Prozessbeschreibung, für das Level 0 Diagramm der SA bietet sich auch interconnection overview semantisch an

• Definiert präzise alle Datenelemente, die in den DFDs vorkommen.
• Beschreibt Komposition, Datentyp, Länge, Wertebereich und Beziehungen der Daten
• Kann auch mit einen ERD abgebildet werden

• Detaillierte Beschreibung der Logik jedes elementaren Prozesses (der nicht weiter zerlegbaren Blasen im DFD).
• Verwenden Techniken wie strukturiertes Englisch (üblicherweise PSEUDO CODE), Entscheidungstabellen oder seltener Ablaufdiagramme. Grundprinzipien der Methode
• Trennung von Logik und Implementierung: Zuerst verstehen, WAS das System tun soll.
• Top-Down-Zerlegung (funktionale Dekomposition): Vom Groben ins Detail.
• Konsistenz und Nachvollziehbarkeit: DFDs, Datenwörterbuch und Prozessbeschreibungen müssen miteinander konsistent sein (CASE-TOOL verwenden!).
• Fokus auf Datenfluss und Transformation: Das System wird als Netzwerk von Datenverarbeitungsfunktionen gesehen.

1. Syntaktische Regeln (Notationsregeln / Darstellungsregeln)
   Die Notationsregeln sind in der Strukturierten Analyse essentiell, die Visualisierung in den Datenflussdiagrammen trägt essentiell zum Verständnis des Systems und zur Einhaltung der semantischen Regeln bei!

1. Semantische Regeln (innere Logik, Modellkonsistenz)
   Die innere Logik des gesamten Modells wird durch die semantischen Regeln bestimmt. Deren Einhaltung kann eigentlich nur durch die Anwendung von geeigneten Modellierungswerkzeugen gewährleistet werden.

• in der Kontextebene nur ein Prozess zeigen, das ist das System selbst
• in der Kontextebene keine Speicher zeigen
• nur in der Kontextebene Tereminatoren (ggf. in machen Dialekten auch auf Level-0, letzteres finde ich aber nicht so gut)
• ab Level 0 dürfen Speicher gezeigt werden
• Speicher dürfen in verschiedenen Diagrammen mehrfach gezeigt werden (Prozesse kommunizieren über Speicher)
• PROZESSE müssen IMMER ein VERB enthalten !!! Es muss aus dem namen herforgehen, dass ein Prozess etwas tut und natürchl auch WAS er tut (z.B. „Rechnung erstellen“)
• Speicher und Terminatoren werden nur mit einen SUBSTANTIV (NOMEN) benannt (z.B. „Kunde“, „Finanzamt“)
• Datenflüsse werden mit einem Nomen oder einer Nomenphrase benannt (z.B. „Bestelldaten“, „Geprüfte Rechnung“)
• PROZESSE sollten Nummern erhalten, der Prozess (das System) im Kontextdiagramm erhält die Nummer 0, die Prozesse im Level-0 Diagramm (Teilsysteme) erhalten eine einstellige Zahl von 1-7, in den Weiteren Ebenen wird durchnummeriert nach dem Schema 1.1, 1.2 1.3, 1.1.2, 1.3.1…
• Prozesse (Funktionen) dürfen im gesamten System nur einmal vorhanden sein !!!
  Ein wiederholtes zeigen wie bei Speichern ist nicht statthaft (abstraktion von der Implementation,
  hierachische Dekomposition ist immer logisch gemeint nicht physisch).
• jeder Prozess hat mindestens ein Input und mindestens einen Output (Datenflüsse),
  da es jeden Prozess nur einmal gibt sind alle Inputs und alle Outputs im selben Diagramm zu sehen.
• jeder Speicher hat mindestens ein Input und mindestens einen Output (Datenflüsse),
  diese müssen jedoch nicht zwingend auf der selben Ebene / im selben Diagramm sein.
• VERSCHÄRFTE DATENFLUSS REGEL: Prozesse kommuniziren immer über Speicher, daraus würde folgen, dass kein logische Prozess direkt einen Datenfluss zu einem anderen Prozess haben darf, das macht in Datenbanksystemen und in verteielten Systemen durchaus Sinn, ich wende die verschärfte Datenflussregel nicht an
• VERSCHÄRFTE DATENFLUSS REGEL: Datenflüsse dürfen NICHT aufgesplittet werden. Man kann der Übersichtlichkeit halber komplexere Datenflüsse zu einem aggrigieren zum Beispiel auf der Kontext und Level-0 Ebene und tiefer dann in elementarere Datenflüsse auftrennen. Das macht sehr Sinn, bei der verschärften Form ist das untersagt… ich nutze die Verschärfte Form nur bei kleinen Systemen.
• Pro Diagramm maximal 5 +/- 2 Prozesse das ist eine essenzielle Zerlegungsregel, werden es in einem Diagramm zu viele Prozesse (max 7) dann MUSS zusammengefasst werden, ist eine Diagramm zu wenig los (min 3) muss überlegt werden ob die Zerlegung wirklich sinvoll war
• ein und ausgehende Datenflüsse eines Prozesses in der übergeordneten Ebene MÜSSEN auf darunter liegenden wiederholend gezeicht werden (alle In/Outputs).
• Blatt-Funktionen (nicht weiter verfeinert) MÜSSEN mit MINISPECs beschrieben werden in der Regel Pseudocode. MINISPECs beschreiben wie der Input (eingehender Datenfluss) in Output (ausgehender Datenfluss) zu verarbeiten ist
• Nicht-Blattfunktionen erhalten KEINE MINISPECs
• Speicher und Datenflüsse erhalten MINISPECs in formalisierter maschinenlesbarer Form klassisch als Backus-Nauer-Notation (zur maschinellen Konsistenzprüfung)
• VERBOTEN: Datenflüsse zwischen Terminatoren
• VERBOTEN: Datenflüsse zwischen Speichern
• VERBOTEN: keine Wunder (Spontanerzeuger) Daten aus dem Nichts, alles muss iregndwann/irgendwie von einer äußeren Datenquelle (Terminator) in das System kommen
• VERBOTEN: keine schwarzen Löcher, alle Daten müssen in verarbeiteter Form auch wieder das System verlassen

• Prozesse sind Funktionen, folgen dem Modulkonzept, sind IPO (EVA)
• jeder Output ist immer vom Prozess verarbeiteter Input
• jeder Input wird vom Prozess zu Output verarbeitet
• Ereignisse sind auch Datenflüsse
• Kontext vs. Level-0, beide Diagramme gibt es pro system nur einmal,
  Kontext = Außenansicht, folgt dem Black-Box-Gedanken
  Level-0 = Innenansicht, folgt dem Withe-Box-Ansatz,
  Level-0 zerlegt das System in seine Teilsysteme.
• Speicher sind PERSISTENT diese behalten ihren Inhalt über die Laufzeit des Prozesses / Systemes, Zustände müssen explizit in speichern abgebildet werden
• Prozesse selbst sind ihrem Wesen nach Zustandslos, ein Prozess merkt sich nichts, alles kommt aus dem Input oder dem Speicher
• Minimalprinzip: jedes Elenment mus notwendig sein: überflüssiges muss entfernt werden!!! Kontrollfrage: „Was ändert sich wenn ich das entferne?“

Vertikales und horizontales Balancing sind zwei fundamentale Konsistenzprüfungen bei der Strukturierten Analyse (SA) nach DeMarco/Yourdon. Sie stellen sicher, dass die verschiedenen Modell-Ebenen logisch und vollständig aufeinander abgestimmt sind.

Dies prüft die Vollständigkeit der Zerlegung (Stufenweise Verfeinerung) zwischen aufeinanderfolgenden Ebenen der Datenflussdiagramme (DFDs).

• Regel: Alle ein- und ausgehenden Datenflüsse eines übergeordneten Prozesses (Eltern-Prozess) müssen exakt mit den ein- und ausgehenden Datenflüssen des gesamten untergeordneten DFDs (Kinder-Diagramm) übereinstimmen.
• Grund: Bei der Zerlegung eines Prozesses dürfen keine Datenflüsse „erfunden“ oder „verloren“ gehen. Was auf einer hohen Ebene fließt, muss auf der detaillierten Ebene auch fließen – und zwar genau dort, wo es in die/aus der zerlegten Funktion kommt.
• Analogie: Wenn du eine „Blackbox“ (Eltern-Prozess) öffnest und ihren Inhalt (Kinder-Diagramm) siehst, müssen die Anschluss klemmen (Schnittstellen) genau gleich bleiben.
• Verstoß-Beispiel: Der Eltern-Prozess „Bestellung bearbeiten“ erhält den Datenfluss `Bestelldaten` und gibt `Rechnung` aus. Das zugehörige Kinder-Diagramm erhält plötzlich `Kundenkredit info` (fehlt oben) oder gibt keine `Rechnung` aus (fehlt unten).

Dies prüft die Konsistenz zwischen den verschiedenen Modelltypen auf derselben Detaillierungsebene.

• Regel: Jedes Datenelement, das in einem Datenflussdiagramm (DFD) vorkommt, muss vollständig und konsistent im Datenwörterbuch (Data Dictionary) definiert sein. Umgekehrt sollten keine Datenelemente im Wörterbuch stehen, die nicht in den DFDs verwendet werden. Zudem müssen die Prozess spezifikationen die im DFD gezeigten Ein-/Ausgänge verarbeiten.
• Grund: Die drei Hauptsäulen der SA (DFDs, Datenwörterbuch, Prozessbeschreibungen) bilden ein zusammenhängendes Modell. Inkonsistenzen führen zu Fehlinterpretationen.
• Verstoß-Beispiel:
  • Ein Datenfluss `Kundendaten` im DFD wird im Datenwörterbuch nicht in seine Bestandteile (`Name`, `Adresse`, `Kundennr.`) zerlegt.
  • Eine Prozess spezifikation für „Prüfe Kreditlimit“ verwendet einen Datenwert `Bonitäts score`, der weder im Eingangsdatenfluss des DFD noch im Wörterbuch auftaucht.

* Vertikales Balancing: „Von oben nach unten“ – Stimmigkeit zwischen den Ebenen eines DFDs. (Eltern-Kind-Konsistenz) * Horizontales Balancing: „Auf derselben Ebene“ – Stimmigkeit zwischen den verschiedenen Modell-Artefakten (DFD ↔ Datenwörterbuch ↔ Prozessbeschreibung). (Artefakt-Konsistenz)

Diese beiden Balancing-Aktivitäten sind entscheidend für die Qualitätssicherung des SA-Modells und verhindern Lücken und Widersprüche früh im Analyseprozess.

* SA Regeln von DeepSeek Review und Zusammenfassung