State Machine

Eine State Machine beschreibt ein System, das sich immer in genau einer von mehreren möglichen Situationen befindet. Diese Situationen nennt man Zustände. Ein Fahrkartenautomat ist zum Beispiel entweder im Ruhezustand, oder er wartet auf Geld, oder er druckt gerade. Von einem Zustand in den nächsten kommt man nur durch bestimmte Ereignisse, etwa das Einwerfen einer Münze. Diese Wechsel heißen Übergänge, und alles, was nicht als Übergang vorgesehen ist, kann nicht passieren. Genau darin liegt der Wert des Modells: Es macht sichtbar, welche Abläufe erlaubt sind und welche nicht.

Warum Programmierer damit Chaos verhindern

Software gerät oft in Situationen, an die niemand gedacht hat. Ein Nutzer klickt zweimal auf « Bezahlen », eine Internetverbindung bricht mitten im Vorgang ab, ein Server antwortet doppelt. Ohne klares Modell entstehen dann Fehler, die schwer zu finden sind. Eine State Machine zwingt die Entwickler, vorher alle Zustände aufzuschreiben.

Der praktische Gewinn ist die Vollständigkeit. Wenn man fünf Zustände und drei mögliche Ereignisse hat, gibt es fünfzehn Kombinationen. Für jede muss man entscheiden, was geschehen soll. Vergisst man eine, fällt das beim Aufschreiben auf, nicht erst beim Kunden. Zahlungssysteme, Aufzüge und Ampelsteuerungen werden deshalb fast immer so entworfen.

Ein zweiter Vorteil ist die Prüfbarkeit. Ein Modell mit endlich vielen Zuständen kann ein Computer vollständig durchrechnen. Man kann also beweisen, dass eine Ampel nie beide Richtungen gleichzeitig auf Grün schaltet. Bei normalem Programmcode ist so ein Beweis meist unmöglich, weil die Zahl der möglichen Abläufe ins Unendliche geht.

Zustände, Übergänge und was das Modell nicht kann

Man braucht drei Dinge: eine Liste der Zustände, einen festgelegten Startzustand und eine Tabelle der Übergänge. Die Tabelle beantwortet immer dieselbe Frage: Wenn ich im Zustand A bin und Ereignis X eintritt, in welchem Zustand bin ich danach? Oft hängt an einem Übergang noch eine Aktion, etwa « Ticket drucken ». Mehr Bestandteile gibt es nicht.

Entscheidend ist, dass eine klassische State Machine kein Gedächtnis über den aktuellen Zustand hinaus hat. Sie weiß nur, wo sie gerade ist, nicht, wie sie dorthin kam. Das klingt nach einer Schwäche, ist aber der Grund für die Übersichtlichkeit. Braucht man doch Erinnerung, ergänzt man Variablen, etwa einen Zähler für das eingeworfene Geld.

Ein häufiger Irrtum ist, jedes denkbare Detail zu einem eigenen Zustand zu machen. Dann explodiert die Zahl der Kästchen und das Modell wird unlesbar. Gute Praxis ist, nur die Situationen als Zustände zu führen, in denen sich das Verhalten des Systems wirklich unterscheidet. Alles andere gehört in Variablen.

Von der Ampel bis zum KI-Agenten

Im Alltag steckt das Prinzip in Waschmaschinen, Kaffeeautomaten und Ampeln. Auch Bestellvorgänge in Onlineshops sind so gebaut: « bestellt », « bezahlt », « versandt », « zugestellt », « storniert ». Die Statusanzeige, die man beim Paketverfolgen sieht, ist nichts anderes als der aktuelle Zustand einer State Machine.

In der KI-Welt taucht der Begriff bei sogenannten Agenten auf. Das sind Programme, die ein Sprachmodell mehrere Arbeitsschritte hintereinander ausführen lassen, etwa suchen, zusammenfassen, prüfen. Weil solche Modelle unvorhersehbar antworten können, rahmt man sie oft in eine State Machine ein. Sie legt fest, welcher Schritt auf welchen folgen darf und wo abgebrochen wird.

In Fachartikeln begegnet dir der Begriff auch als « endlicher Automat » oder als Abkürzung FSM für Finite State Machine. Nicht zu verwechseln ist er mit dem « State » in der App-Entwicklung, der einfach die gespeicherten Daten einer Oberfläche meint. Eine State Machine ist mehr als ein gespeicherter Wert: Sie ist die Regelmenge, die bestimmt, wie sich dieser Wert verändern darf.