Was ist überhaupt Konfiguration?
Das Stellwerk, so wie es konzipiert ist, wird ein Baukasten. Es enthält Stellwerkselemente, wie Weichen(hebel), Signale(hebel), Fahrstaßen(hebel) oder Blockfelder.
Die Konfiguration sagt aus, welche dieser Stellwerkselemente in einem konkreten Stellwerk vorkommen und auch wo, d.h. in welcher Beziehung ein Stellwerkselement zu anderen steht. Weiterhin sagt die Konfiguration, welchen Elemente im Stellwerk zu welchen Elementen in einer Zusi-Strecke in Beziehung stehen.
Die Stellwerkselemente sind nicht alle gleich. So ist eine Weiche durchaus auch vom stellwerksinternen Verhalten etwas anderes als ein Blockfeld, selbst wenn beide einen binären Zustand repräsentieren. Aus Sicht der Konfiguration aber sind beide Elemente zumindest in Teilen gleich (bzw polymorph). Ein solches für diesen Zweck gleiches Verhalten erreicht man in der OO-Welt durch Vererbung. Alle Stellwerkselemente werden also "Konfigurationsobjekte".
Jedes Konfigurationsobjekt erhält eine automatisch vergebene eindeutige ID.
Wie soll die Konfiguration geschehen?
Dies soll über den Stellwerkseditor erfolgen. Im Stellwerkseditor werden die benötigten Elemente ausgewählt, gesetzt, und verknüpft.
Es gibt hierbei dann Funktionen zum Setzen und Löschen dieser Elemente, und zum Setzen. Löschen und Ändern von Verknüpfungen. Verknüpfungen könnten zumindest teilweise "generisch" verarbeitet werden, also ohne Berücksichtigung konkreter Eigenschaften eines Elementtyps. Das mag sinnvoll sein, wenn es die Bedienung vereinheitlicht, aber soll nicht zum Selbstzweck werden.
(Ob und wie weit ein solcher Konfigurationsvorgang automatisierbar ist, sei dahingestellt. Auch ein (teil-)automatisierter Vorgang änderte nichts am Prinzip der Konfiguration.)
Das Ergebnis der Konfiguration wird in einer Datei gesichert. Überraschenderweise wird es sich wohl um eine XML-Datei handeln werden.
Wie entsteht aus einer Konfiguration ein lauffähiges Stellwerk?
Wenn das Stellwerk hochgefahren wird, muss es sich automatisch konfigrieren, d.h. eine vorgebene Konfiguration umsetzen, mit Leben erfüllen.
Dieses soll in drei Phasen geschehen:
- Der XML-File wird gelesen und verarbeitet. Da wird vermutlich ein SAX-Parser zum Einsatz kommen.
Jedes erkannte Element wird instantiert. Der gängigste Weg der Instantiierung wird über das Factory-Pattern oder velleicht noch einfacher über Reflection (Typbearbeitung zur Laufzeit) sein. Die Verknüpfungen der Objekte sind in dieser Phase nur soweit bekannt, dass Quell- und Zielelemente identifiziert sind, so wie es auch im XML-Files abgelegt ist. - Nachdem alle Objekte erzeugt wurden, aber sich noch freischwebend im Raum befinden, werden nun die Verknüpfungen aufgelöst (missverständlich, besser: Mit Leben gefüllt). Jedes Objekt erhält nun direkte Referenzen auf alle zu ihm verknüpften Objekte.
Die Objekte werden dazu der Reihe nach aufgerufen und suchen sich aus einer zentralen Objekttabelle die Objektreferenzen ihrer eigenen Verknüpfungen. (polymorphes Verhalten).
Die im UML-Modell gezeigten Methodenaufrufe zu verknüpften Objekten sind danach möglich. Im Sinne der OO ist jedes Objekt so autonom wie möglich, ein permanentes "Lookup" zur Laufzeit wird vermieden. - In der dritten Phase wird der Anfangszustand für jedes Objekt gesetzt. Nach der Instantiierung der Objekte befindet sich das Stellwerk zunächst im Grundzustand. Das muss aber aufgrund des aktuellen Geschehens bei Zusi nicht den Tatsachen entsprechen. Deswegen werden jetzt sämtliche tatsächlichen Zustände bei Zusi abgerufen. Danach ist das Stellwerk bedienbar.