Systeme verstehen in Theorie und Praxis (4)
In den vorigen Artikeln dieser Reihe haben wir uns mit der Zerlegung von Systemen in handhabbare Teilsysteme, der Analyse einfacher Systeme mit Steuerelementen und Regelkreisen sowie dem Verhältnis von einfachen Teil- und komplexen Gesamtsystemen beschäftigt.
In diesem Teil geht es darum, wie wir die Fülle an Informationen, die wir dabei zusammentragen, so aufbereiten, dass wir sie bei der Lösung eines konkreten Problems oder - falls wir ein neues System bauen wollen - bei der sinnvollen Gestaltung und Zusammensetzung der Komponenten im Kopf behalten können.
Was uns dabei hilft sind Modelle, die die wesentlichen Informationen enthalten und die unnötigen weglassen.
Ich unterscheide dabei drei Arten von Modellen, die unterschiedliche Aufgaben bei der Analyse beziehungsweise Synthese von Systemen haben:
Hierarchische Modelle eignen sich vor allem für die statische Beschreibung von Systemen und der Aufgaben der Teilsysteme.
Topologische Modelle helfen beim Verständnis der Verteilung der Komponenten des Systems.
Dynamische Modelle konzentrieren sich auf zeitliche Änderungen im System.
Hierarchische Modelle
Diese Modelle berücksichtigen die Abhängigkeiten der Teilsysteme und trennen idealerweise Einflüsse verschiedener Ebenen der Hierarchie sauber voneinander ab. Ich kann bei der Betrachtung einer Hierarchieebene von den anderen Ebenen, egal ob über- oder untergeordnet, abstrahieren.
Üblich ist bei hierarchischen Modellen, dass untergeordnete Ebenen Dienste für übergeordnete Ebenen erbringen und dass im Idealfall keine Hierarchieebene übersprungen wird. Sehe ich in der Praxis den Zugriff aus einer sehr hohen Modellebene auf eine sehr niedrige Ebene, so sollte ich hier sehr genau hinsehen.
Beispiele für hierarchische Modelle sind das OSI-Modell für die Beschreibung verteilter gekoppelter Systeme, OBASHI zur Zuordnung von Datenflüssen und Abhängigkeiten von Geschäftsprozessen und IT-Architekturmodelle für komplexe Softwaresysteme.
Topologische Modelle
Diese Modelle müssen nicht topographisch korrekt sein, das heißt sie müssen keine realen Entfernungen zwischen den Teilsystemen abbilden, sondern vor allem aufzeigen, wie Teilsysteme miteinander vernetzt sind und wie die Flüsse zwischen diesen verlaufen.
Üblicherweise werden topologische Modelle durch Graphen dargestellt, deren Knoten die Teilsysteme oder Objekte verkörpern während die Kanten die Beziehungen und Flüsse zwischen diesen beschreiben.
Dabei kann es gerade in hierarchischen Systemen vorkommen, dass ein und dasselbe System auf den verschiedenen Ebenen mit verschiedenen topologischen Modellen beschrieben wird.
Das kann insbesondere bei Computernetzen zu einem Verhalten führen, welches sich nicht aus der Betrachtung einzelner Topologiemodelle der verschiedenen Ebenen erklären lässt.
So kann ein kleines lokales Netz in der Sicherungsschicht des OSI-Modells sternförmig dargestellt werden mit dem Switch im Zentrum. In der Netzwerkschicht hingegen bildet das Gateway das Zentrum, welches auf der tieferliegenden Schicht am Rand positioniert ist.
Bei virtualisierten Systemen, wiederholen sich teilweise die Schichtfolgen, so dass ich mir ganz genau klarmachen muss, auf welcher Hierarchieebene ich mich gerade gedanklich bewege und welches das angemessene Topologiemodell ist.
Dynamische Modelle
Diese Modelle verwende ich, wenn ich das Zeitverhalten oder die Reaktion auf Ereignisse untersuchen will.
Ein sehr mächtiges Modell ist der Zustandsautomat mit dem ich die Reaktion eines Systems auf Ereignisse beschreiben kann. Das System kann immer nur einen aus einer definierten Zahl von Zuständen annehmen, in dem es auf die eintreffenden Ereignisse mit definierten Aktionen und / oder einem Wechsel des Zustands reagiert.
Der Zustand enthält immer auch Informationen über die Vergangenheit, denn einen bestimmten Zustand kann der Automat nur über eine der möglichen Sequenzen von Ereignissen erreicht haben. Und dabei muss er zu einem früheren Zeitpunkt einen Zustand eingenommen haben, von dem aus der Übergang zum aktuellen möglich ist.
Die Übergänge von einem Zustand zum nächsten sind immer vom vorherigen Zustand und dem Ereignis abhängig. Üblicherweise gibt es nur einen Startzustand und keinen, einen oder mehrere Endzustände. Einer der Gründe für das Sprichwort "Reboot tut gut." ist, dass das System dabei mit dem Startzustand beginnt und ein komplexer Wechsel aus einem fehlerhaft eingenommenen Zustand zu einem fehlerfreien vermieden werden kann.
Ich kann einen Zustandsautomat durch einen Graphen, welcher sich oft intuitiv erfassen lässt, oder eine Tabelle, die ich einfach per Programm umsetzen kann, gleichwertig beschreiben.
Beispiele für Zustandsautomaten finden sich in RFC9293 für den TCP-Verbindungsaufbau und -abbau oder in RFC821 für das Simple Mail Transfer Protocol.
Während der Zustandsautomat sich auf einzelne Systeme konzentriert, verwende ich Swimlanes, um die Abfolge von Ereignissen zwischen mehreren Systemen zu veranschaulichen. Dabei reserviere ich für jedes der teilnehmenden Systeme eine eigene Spalte oder Zeile - je nachdem, ob der zeitliche Ablauf vertikal oder horizontal dargestellt ist.
Der oben erwähnte RFC9293 enthält auch Beispiele für Swimlanes beim Auf- und Abbau der Verbindung.
Damit sind wir nun am Ende der kleinen Reihe über die Analyse von Systemen. Wir haben im Teil 1 das Bilanzverfahren als Mittel zur Zerlegung des Systems sowie als Möglichkeit zur Überprüfung des Gesamtzustandes betrachtet. In Teil 2 haben wir mit Steuerelementen und Regelkreisen die elementaren Bausteine von Systemen untersucht. Teil 3 beschäftigte sich mit den Wechselwirkungen zwischen Gesamt- und Teilsystemen und dieser Teil nun mit Modellen, um die Vielfalt an Informationen zu reduzieren und handhabbar zu machen.
Posted 2026-07-15