Im Dienst der DB AG rollen rund 50000 Fahrzeuge unermüdlich über Deutschlands Schienennetz - in ständig neuen Kombinationen auf immer wieder anderen Routen. Wer einen Reisezug zusammenstellen will, muß wissen, welche Lokomotiven und Waggons wo zur Verfügung stehen und in welchem technischen Zustand sie sich befinden. Das war bislang leichter gesagt als getan.
Die Mitarbeiter in der Planung und Disposition mußten sich die nötigen Informationen mühsam zusammenklauben - aus unterschiedlichen Dateien oder sogar aus papiergestützten Verzeichnissen. Müßig zu erwähnen, daß damit viele Informationen redundant gehalten und gepflegt wurden. Das kostete nicht nur viel Geld, sondern machte das System auch noch anfällig für Inkonsistenzen. Aufgrund des hohen Arbeitsaufwands befanden sich die Daten so gut wie nie auf dem aktuellen Stand. Oft hinkten sie mehrere Wochen hinter der Realität her.
Darüber hinaus waren die Fachdienste außerstande, die auf unterschiedliche Datenbanken verteilten Fahrzeuginformationen selbst nach übergreifenden Gesichtspunkten auszuwerten. Beispielsweise ließen sich die Bestandsdaten nicht mit der Reparaturplanung in Einklang bringen.
Es war unmöglich, direkt auf alle Daten zuzugreifen. Darunter hatten vor allem die Controller zu leiden, die mit umfangreichen Ausdrucken zurechtkommen mußten.
Last, but not least ließen sich die alten Systeme eigentlich nicht mehr erweitern. Ihre Technik war veraltet und ihre Struktur unübersichtlich. Die zur Jahrtausendwende - infolge der Datumsumstellung - notwendigen Änderungen vorzunehmen wäre einer Sisyphos- Arbeit gleichgekommen.
Ende der 80er Jahre schon waren die schwer zu pflegenden Systeme ein Stein des Anstoßes. Nach 1990 sahen sich die Software-Experten der DB AG einer weiteren Herausforderung gegenüber: Die Fahrzeuge der ehemaligen DDR-Reichsbahn mußten in den Gesamtbestand integriert werden. Da faßte das Unternehmen den Beschluß, eine einheitliche Basis für die technischen Fahrzeugdaten zu schaffen.
Zunächst war eine Lösung auf der Grundlage einer herkömmlichen Host-Umgebung und eines relationalen Datenbanksystems im Gespräch, erinnert sich der Leiter des Dart-Projekts, Manfred Lange. Doch unmittelbar vor Beginn der Realisierungsphase traf der Zentralbereich Informationssysteme die Entscheidung, das Projekt objektorientiert zu entwickeln.
Vor allem die Einsparungsmöglichlichkeiten bei der Wartung und bei der Wiederverwendung hatten die Neugier und Experimentierbereitschaft der Bundesbahner geweckt. Ein gewichtiges Argument waren auch die Forderungen der Anwender nach modernen grafischen Oberflächen.
Aber es gab auch kritische Stimmen. "Viele haben uns gewarnt", erinnert sich Lange. "Sie sagten: Wenn ihr das schon versucht, dann lieber erst einmal mit einem kleineren System."
Aber der Projektleiter ließ sich nicht beirren. Mit einer Handvoll Mitarbeiter am Standort Magdeburg machte er sich daran, ein durchgängig objektorientiertes System aufzubauen. Die Gesamtverantwortung für das Design, die Software-Erstellung und das Projekt-Management legte er in die Hände des Münchner Systemhauses SD&M GmbH & Co. KG. Die beiden Entwicklungsteams in Magdeburg und München setzten sich jeweils aus Mitarbeitern der DB AG und des Software-Unternehmens zusammen, damit die Bahner sich mit der für sie neuen Objekttechnologie vertraut machen konnten. Für die Client-Seite verwendeten die Entwickler das Smalltalk-Tool "Visual Works" von Parcplace Digitalk. Ihre Begründung: Smalltalk erlaubt eine außergewöhnlich hohe Produktivität und eignet sich sehr gut zur Erstellung von grafischen Oberflächen. Ein Argument war laut Lange auch die gute Portabilität der in Smalltalk erstellten Anwendungen.
Für die Programmierung des Servers wurde die Tool-Palette um C++ erweitert. Mit der Hybridsprache lassen sich zwar nicht so leicht objektorientierte Anwendungen erstellen wie mit Smalltalk. Aber neben der besseren Performance im Zusammenspiel mit der Datenbank sprechen auch die Integrationsmöglichkeiten mit konventionellen Systemen - beispielsweise einem Transaktionsmonitor - für C++.
Die Münchner brachten auch das objektorientierte Datenbanksystem "Objectstore" von Object Design in das Projekt ein. Es soll als Infrastruktur für die Dart-Daten dienen. Ebenfalls auf die Initiative von SD & M geht die Installation der Kommunikations-Infrastruktur zurück: des Parcplace-Digitalk-Produkts "Distributed Smalltalk" für die Clients und des Corba-2.0-konformen Object Request Brokers "Orbix" von Iona auf der Server-Seite.
Worauf Lange besonders stolz ist: Dart ist von der Bedienoberfläche über die Client-Server-Kommunikation bis in die Datenbank hinein objektorientiert. In großen kommerziellen Systemen ist eine solche Installation bislang noch selten zu finden.
Lange und seine Mitarbeiter nahmen sich acht Monate - oder fast die Hälfte der Projektdauer - Zeit für die Designphase, in deren Verlauf sie die Architektur und die Produkte sorgfältig evaluierten. Den Gesamtaufwand beziffert Lange mit 25 Personenjahren. Durch teilweise selbstentwickelte Frameworks sowie Design-Patterns hat sich das Projektteam die Arbeit vereinfacht beziehungsweise seine künftige Produktivität sichergestellt.
Seit August dieses Jahres arbeiten die ersten 20 Anwender im Realeinsatz mit der Datenbank. Im Laufe des kommenden Jahres soll die Zahl der Dart-Nutzer sukzessive bis auf 500 steigen. Nach Langes Schätzungen umfaßt das System im Endausbau ein Datenvolumen von 10 GB und verkraftet pro Sekunde 20 bis 30 Lesezugriffe sowie zwei bis fünf Schreibtransaktionen.
Noch befindet sich die Datenbank im Aufbau, aber gegen Ende dieses Jahres sollen die Daten aller Lokomotiven und Reisezugwagen darin enthalten sein. Heute schon lassen sich neue Fahrzeuge flexibel und kostensparend registrieren, da sie nur in einem einzigen System erfaßt werden.
Ihren vollen Nutzen wird die Applikation dann entfalten, wenn die geplanten Schnittstellen zu anderen Systemen realisiert sind. Dann lassen sich zum Beispiel Instandhaltungstermine aufgrund der jeweiligen Laufleistung eines Triebfahrzeugs vorausberechnen. Die Wartungstechniker können sich auf Knopfdruck darüber informieren, welche Teile wann bereits ausgetauscht wurden. Und spezielle Auswertungen müssen die Programmierer nicht mehr tage- oder wochenlang blockieren.
Alle benachbarten Anwendungen sollen schließlich mit einem einheitlichen Datenbestand arbeiten, um dessen Pflege sich vor Ort niemand zu kümmern braucht. Controlling und Management verfügen damit über eine solide Basis für ihre Entscheidungen, die sich ohne viel System-Know-how ausschöpfen läßt.
Die Object Management Group würdigte die Kooperation von DB AG und SD/M, indem sie dem Team anläßlich der diesjährigen "Object World" den Preis für die beste objektorientierte Anwendung im unternehmensweiten Maßstab verlieh. Wie die Jury ausführt, zeichnet sich die Applikation vor allem durch drei Eigenschaften aus: Sie ist komplex, von Anfang bis Ende objektorientiert und bereits in der Praxis erprobt. Alles in allem sei sie ein perfektes Beispiel dafür, wie sich Anwenderprobleme mit Objekttechnologie lösen lassen.
Umgebung
- Als Clients fungieren PCs mit Windows 95.
- Die Oberfläche und der Anwendungskern wurden mit Visual Works 2.0 entwickelt.
- Die Kommunikation erfolgt nach dem IIOP-Protokoll von Corba 2.0.
- Auf der Client-Seite sorgt Distributed Smalltalk 2.0, auf der Server-Seite Orbix 2.1 für den Nachrichtenaustausch zwischen den Objekten.
- Der Host-Rechner, eine Unix-SMP-Maschine, arbeitet mit Solaris.
- Der Server-Teil der Anwendungen wurde mit C++ und Objectstore 4.0 erstellt.