Letzte Woche bei Railware

8.6.2003

In Ermangelung besonderer Ereignisse, will ich diesmal ein wenig über die "inneren Werte" von Railware schreiben. Ich hoffe, ich drücke mich allgemeinverständlich aus.

Railware ist in Delphi entwickelt. Dieses Entwicklungssystem hat seinen Ursprung in Turbo Pascal. Derzeit verwende ich noch die Version 5. Das hat seine Ursache darin, dass wegen des hohen Migrationsaufwandes und der Zusatzkosten nicht jeder Sprung mitgemacht werden kann. Die aktuelle Railware Version entsteht aus ca. 320.000 Zeilen Quelltext, die sich auf 335 Dateien (.pas) aufteilen. Dazu kommen zugekaufte Bibliotheken (nur Quellcodelizenzen) für Menüs, Popups, Eingabefelder, Tabellen (Grids), Datenbanken, serielle Kommunikation, Internationalisierung/Lokalisierung, Lizenzverwaltung u.a.

Kurz "gegrebt" gibt es 640 eigene Klassen, davon sind 192 Formulare. Weiter sind 81 Records, 167 Aufzählungstypen und 97 eigene Windows Botschaften deklariert.

Die ISAM- Datenbank besteht aus 70 Tabellen. Dazu kommen weitere 42 für Sonderprogramme. In der Ini- Datei befinden sich bis zu 174 Optionen, die teilweise dynamisch vom System modifiziert werden.

Im Interfaceprogramm befinden sich alle Instanzen, die systemweit nur einmal vorhanden sind. Außer den Treibern mit den Kommunikationsprotokollen der Digitalsysteme, dem RAILstack, den Watchdogs, Sounds mit DirectX, dem Logbuch, Slot-Refreshing und einem Meldermanagement, werden hier auch Züge beschleunigt, gebremst oder angehalten. Dazu existiert für jeden Zug und jede Lok eine Instanz der entsprechenden Klassen. Von hier werden auch die Verbindungen der Netzwerkfunktionen gesteuert. Die Kommunikation zwischen dem Interface und den anderen Applikationen erfolgt über das Windows Nachrichtensystem. Dazu ist eine Vielzahl von eigenen Botschaften definiert.

Jedes Gleisbildprogramm beherbergt einige zentrale Objekte. Es handelt sich dabei um die Zugverfolgung, Zugsteuerung, Zuglenkung, sowie zentrale Klassen zur mehrstufigen Fahrwegreservierung und dem Meldermanagement (Gegenstück im Interface). Jeder Zug im Gleisbild ist ein eigenes Objekt, sein Steuerungspartner sitzt im Interface. Jedes Gleissymbol ist ein eigenes Objekt und die Instanz einer vielfach vererbten Basisklasse. In der Zugsteuerung stecken die aufwändigsten und größten Methoden. Die Meistgenutzte ist aber eher klein und wird zum "durchhangeln" durch die Gleisbildsymbole benötigt. Denn per Definition gibt es (derzeit) keine sich direkt referenzierenden Symbole. Ach ja, noch etwas anderes ist strikt verboten: kein Prozess oder Thread darf auf Ereignisse warten, sondern kann lediglich schlafen. An keiner Stelle werden Semaphoren eingesetzt. Bei einem durchschnittlichen Gleisbild mit Interface laufen dann aber je nach Konfiguration und Situation zwischen 6 und 35 Threads. Pro Lok kommt je einer hinzu. Aber meistens schlafen die alle ganz friedlich vor sich hin. Mehrere sogenannte Zentraltimer teilen sich verschiedenste Aufgaben, die nicht sofort ausführbar waren. Sie heißen intern "Immediate Single", "Delayed Single" und "Repeat". Eine Besonderheit ist die interne Kommunikation zwischen den zentralen Objekten, doch dazu später mehr...

Während der ganzen Jahre hat Railware eine sehr stürmische Entwicklung hinter sich. Und nebenbei bemerkt: ich bin sicher, dass dies auch noch einige Jahre so weitergehen wird. Aber neue Features bringen auch viele neue Probleme mit. So kann aus einem zu einer bestimmten Zeit definierten Design schnell etwas ganz schreckliches und unwartbares werden. Diese Situation war ab Herbst 2001 abzusehen. Die Plattform war ausgereizt und es gab kaum mehr Möglichkeiten für Erweiterungen mit vertretbarem Aufwand. Im Dezember war die Geburtsstunde für das heutige  Design, dessen Ergebnis dann ab Mitte 2002 als Version 4 ausgeliefert wurde. Äußerlich sah es dem Vorgänger noch ähnlich, aber innen werkelte ein völlig reorganisiertes System. Was ist das besondere ? Damals las ich durch Zufall einen Bericht über sogenannte "aspektorientierte Entwicklung". Diese Ideen und Prinzipien fand ich für mich sehr geeignet - aber auch sehr theoretisch. Noch heute haben sie das universitäre Umfeld wenig verlassen und es gibt kaum Entwicklungssysteme, die es unterstützen. So wurde nur die Idee übernommen und mündete in ein eigenes strukturelles Design. Heute wird man das wohl eher als "Subjektorientierung" (SOP) bezeichnen. Letztendlich wurden damit drei Problemfelder gelöst: Funktions- und Parameteränderungen, die Auswirkungen auf eine große Zahl von Klassen hatten und ohne SOP globale Variablen oder Methoden erfordern würden. Die zum Teil sehr schlechte Wiederverwendbarkeit von Codeteilen, die nur durch völlig irrsinnige Methodenkonstrukte aufzufangen wären und die immer länger werdenden Parameterblöcke in Methodenaufrufen. Kommen Ihnen diese Probleme bekannt vor ? Hmmh, ich glaube das dies bei allen umfangreichen und lebenden Projekten der Fall sein wird. Im Moment gibt es in Railware nur noch wenige Klassen, die nicht vollständig umgestellt sind. Aber ich will ja auch morgen noch etwas zu tun haben ...

Ein paar Tools erleichtern mir die Arbeit: so hilft mir ein CVS, was übrigens auch dann eine Hilfe ist, wenn man allein an einem Projekt arbeitet. Ein selbstentwickelter kleiner Profiler hilft bei der Beurteilung der Brauchbarkeit mancher Methoden. Dann gibt es noch einen sehr umfangreichen Anlagensimulator, der auf einem eigenen Server läuft. Er kann mit Gleisbildern von Kunden geladen werden, die jedoch in umfangreicher Arbeit mit zusätzlichen Daten versehen werden müssen. Dafür simuliert er aber ziemlich zuverlässig und vollständig typische Modellbahnanlagen. Um Digitalsysteme und deren Zeitverhalten beurteilen zu können, wurden verschiedene Simulatoren mit üblichen Mikro- Controllern entwickelt. Zwei Laptops mit Protokollanalysatoren für die serielle Kommunikation und verschiedenen Gleisprotokollen, die meist selbstentwickelt wurden, sparen wirklich sehr viel Zeit. Ein UML- Tool gibt es übrigens nicht. Stattdessen verwende ich noch heute eine vor über 25 Jahren selbst ersonnene Meta- Sprache.

Mehrere Kunden, die einen Vergleich zu einem Programm zogen das allgemein als das stabilste gilt, bestätigten mir, das Railware heute ebenso zuverlässig arbeitet. Wenn ich das mit der implementierten Komplexität (die Sie nun wohl erahnen können) vergleiche dann bin ich heute mehr als zufrieden - es ist einfach fantastisch ! Eine gute Basis, um die nun dritte größere Restrukturierung anzugehen - aber das kennen sie ja bereits von einem älteren Bericht.

Hier sitze ich die meiste Zeit so vor mich hin, lasse kostenlos meinen Kopf Röntgen, trinke Tonnen an Kaffee oder Red Bull und träume meinen Traum von intelligenter Software für Modelleisenbahnen.

Schnelle Tests verschiedener Systeme direkt am Platz

Etwas zur Geschichte von Railware:
Vor etwa 9 Jahren erbte ich die Fahrzeugsammlung meines Vaters. Sein Modellbahntraum erfüllte sich nicht und so wollte ich ihn umsetzen. Auf grund beengter Platzprobleme in Berlin verlegte ich meine Aktivität zunächst auf die Steuerung mittels Digitalsystem. Aber alle Programme die ich damals (im Internet) entdeckte, fand ich so grottenschlecht, das ich mich zu einer Eigenentwicklung entschloss. So entstand ein erstes Windows- Programm, das ich "Bahn" nannte und das außer mir niemals jemand zu Gesicht bekam. Es entsprach in weiten Teilen der heutigen Konzeption, war aber auf Grund der mangelnden Arbeitsgeschwindigkeit damaliger Rechner nicht praxistauglich. Gerne hätte ich ein Bild gezeigt, doch leider habe ich nur noch die Quellen und kein "Objekt Pascal für Windows" mehr. Daraus wurde dann "WinBahn", das übrigens auch heute noch viele Nutzer hat. 1997 wurde daraus Railware. Es arbeitete mit der damals üblichen und von Borland mitgelieferten Datenbank "BDE". Doch die Unzulänglichkeiten wurden immer größer und die Performance mit jedem BDE- Update schlechter. Das war die Zeit der ersten umfangreichen Restrukturierung des Systems. Die BDE wurde durch eine zuverlässige und nahezu kompatible ISAM- Datenbank ersetzt, die keine externen Treiber benötigte und die sogar mit SQL bedient werden konnte. Ein Glücksgriff, denn die möglichen Netzwerk- und SQL- Optionen wären sonst nicht so einfach zu implementieren gewesen. Zugriffe auf die Datenbank  werden nun während des Betriebs vermieden.

Weiterhin viel Spaß mit dem Modellbahnhobby wünscht Ihnen

Dieter Hinz

 

© Copyright by Andrea Hinz. Kontakt zum Railware Team
Alle Logos, Hersteller- und Produktnamen sind Warenzeichen ihrer jeweiligen Hersteller.