Erfahrungen mit dem System TROSS beim DRK Part 2

Seite

Textversion

somit auch nicht neu sortiert. Die Folge davon ist, dass ein Eintrag bei binärer Suche nicht mehr gefunden werden kann. Beim Löschen dieses Eintrags wurde dieser dann nicht gefunden und auch keine Fehlermeldung zurückgegeben. Die falsche Sortierung der Daten ist nicht aufgefallen, da die Daten vor der Anzeige immer nochmals sortiert werden.

Betroffen von diesem Problem waren beinahe alle Daten: Mitarbeiter, Kunden, Institutionen, Qualifikationen, Fahrzeuge, Fahrzeugtypen, Essensarten, Hilfsmittel, ArbeitszeitProfile und TourSzenarien.

Die einfache Lösung wäre gewesen, die Daten nicht mehr sortiert zu speichern. Der Aufwand für die Suche nach einem Eintrag wäre dann zwar größer (im Mittel n=2 statt log(n) bei binärer Suche), jedoch wären das einfache Zeiger- Vergleiche und nicht Vergleiche von Zeichenketten (der Listentext), die jedes Mal neu erstellt werden müssen. Diese Möglichkeit schied jedoch aus, weil die eingegebenen Daten, die mit der Serialisation von Java gespeichert wurden, dann nicht mehr verwendbar wären. Daher werden die Daten jetzt nach Änderung eines Schlüssels mit Shaker-Sort neu sortiert. Dies passiert in maximal 2n Schritten, wobei n die Anzahl der vorhandenen Daten des jeweiligen Typs ist. In unserer Anwendung ist n <= 1000.

3.4 Leere Ausdrucke

Zum Teil waren die Ausdrucke ziemlich leer. Zum Beispiel erschien beim Versuch, die angezeigte Kundenliste auszudrucken, nur ein Rahmen mit dem Titel \Kunden". Das liegt am Menüpunkt Ausgabe-Angezeigten Plan drucken.... Dieser schickt einfach das aktuelle Hauptfenster, z.B. den angezeigten Plan, an den Drucker. Jedoch wurde hier die Methode print anstatt printAll verwendet, wodurch immer nur die oberste Komponente in der Fenster-Hierarchie angezeigt wurde. Bei einem Fenster mit Rahmen ist das eben nur der Rahmen. Es sei auch noch erwähnt, dass der Menüpunkt Ausgabe-Angezeigten Plan drucken... eigentlich nur zum Ausdrucken von Plänen aus dem Ausgabe-Menü gedacht ist und nicht für beliebige Fenster, wie z.B. die Liste der Kunden. Beim Ausdrucken von Tourplänen erschienen Blätter, die nur eine Zeile enthielten:

Tour 1 Schule 1

Das ist zwar nicht besonders schön aber richtig so, da die \Tour 1" noch keine Untertouren hat. Hätte die Tour Untertouren, würden diese im Ausdruck folgen.

3.5 Sanduhr-Cursor bleibt stehen

Gelegentlich blieb der Sanduhr-Cursor auch nach dem Beenden einer Aufgabe noch stehen, so dass man den Eindruck hatte, das Programm arbeitet noch. Weshalb es dazu kommt, war nicht genau festzustellen. Das System wurde so abgeändert, dass beim Zurücksetzten der Form des Mauszeigers nicht mehr die vorher gespeicherte Form, sondern direkt der normale Cursor (Pfeil) angezeigt wird.

Seite 10 Seite Textversion Grafikversion Übersicht

Seite 11 Seite Textversion Grafikversion Übersicht

3.6 Abstürze des Systems

Diese waren nicht reproduzierbar, was vieleicht daran gelegen hat, dass Java unter verschiedenen Betriebssystemen verwendet wurde. Jedoch darf ein Java- Programm auch nicht mit der berühmten Windows-Meldung \Fehler in Anwendung" abstürzen. Dies ist nur durch Fehler in der Java-Maschine möglich.

3.7 Falsche Eingaben

In den eingegebenen Daten war zwar wie geplant eine benannte Station für die Schule vorhanden, jedoch wurden in verschiedenen Dienstwünschen neue Stationen nur mit dem Straßennamen der Schule angegeben. Wenn man aber nicht immer die gleiche (benannte) Station wählt, geht das Programm beim Aufbau von Untertouren von verschiedenen Stationen aus und fügt diese dann auch mehrfach in die Untertour ein. Zur Behebung muß zunächst in den Dienstwünschen die benannte Station ausgewählt werden. Dann kann die Untertour erneut angelegt werden.

Schöner für den Anwender wäre es natürlich, wenn TROSS bei gleichen Strassennamen nachfragt, ob die schon vorhandene Station verwendet werden soll. Solche Mechanismen wurden während der Entwicklung von TROSS als Eingabehilfen oder \nice" bezeichnet, dann aber aufgrund von Zeitnot nicht implementiert.

4 Ein zweiter Anlauf

Die vom DRK-Mitarbeiter eingegebenen Daten wurden bereinigt und zusammen mit einer neuen Version von TROSS beim DRK installiert. Es wurde eine Tour komplett mit ihren vier Untertouren angelegt. Dabei entdeckte die Konsistenzprüfung nicht eingehaltene Forderungen eines Dienstwunsches, die dann aber vom DRK-Mitarbeiter akzeptiert wurden.
Auch die Ausgabe von Dienstplänen (Abb. 8) und Analysedaten wie z.B. die Mitarbeiterauslastung (Abb. 10) funktionierten einwandfrei.

5 Oberfläche und Navigation

Die Navigation im System TROSS funktionierte reibungslos, die Anordnung der Oberflächenelemente ist stellenweise jedoch nicht optimal. Ein Beispiel ist der Dienstwunsch-Dialog (Abb. 9): Die wichtigsten Informationen zu einem Dienstwunsch, die Rhythmen, die die Wiederholungsrate und die Termine festlegen, befinden sich erst auf der zweiten Seite und auch dort erst ganz unten. Das ist vermutlich auch der Grund dafür, dass der DRK-Mitarbeiter in seinen Daten nie Rhythmen eingegeben hat.

6 Funktionalität

Ein Problem kann sich aus dem Zusammenspiel von Untertouren und der Entfernungstabelle ergeben: Wird die Fahrzeit zwischen zwei Stationen einer Untertour verändert, so wird die neue Fahrzeit auch in der Entfernungstabelle gespeichert, die für alle Stationen aller Untertouren gilt. Diese Änderung wirkt sich

Seite 11 Seite Textversion Grafikversion Übersicht

Seite 12 Seite Textversion Grafikversion Übersicht

Abbildung 8: Dienstplan für einen Mitarbeiter

dann auch auf andere Untertouren aus, jedoch erst, wenn diese selbst bearbeitet werden. Das gilt nicht nur für die Untertouren einer Tour, sondern für alle Touren. Diese Anpassung zu einem späteren Zeitpunkt ist für den TROSS-Benutzer überraschend und nicht nachvollziehbar. Sinnvoller wäre es, die Veränderungen entweder sofort oder überhaupt nicht an andere Untertouren weiterzugeben. Diese Entscheidung sollte der Benutzer für jede betroffene Untertour selbst treffen können.

Ein weiteres Problem ist die fehlende Unterstützung für geplante geringfügige Veränderungen. Es ist z.B. nicht vernünftig möglich, einen Kunden ab einem bestimmten Datum in eine Tour aufzunehmen. Die Dienstwünsche der anderen Mitfahrer müsste man an diesem Tag aufspalten. Da es keine Funktion \Aufspalten" gibt, muss dazu der zukünftige Teil des Dienstwunsches neu eingegeben werden. Dann könnte man die Untertouren auf ähnliche Weise aufspalten. Hier fehlt ein Konzept zur Behandlung von Gültigkeitszeiträumen von Touren und Untertouren.

7 Kritik

Auf dem Rechner beim DRK Stuttgart, ein Pentium Pro 350 mit 32MB RAM und Windows 95, kann man mit dem Programm vernünftig arbeiten. Beide Mitglieder der Projektgruppe, die das Programm dort erlebt haben, waren von der Geschwindigkeit überrascht. Die Befürchtung bei der Wahl der Implementierungssprache, Java sei zu langsam, hat sich somit nicht bestätigt. Ein Grund für den zurückhaltenden Einsatz des Programms beim DRK ist

Seite 12 Seite Textversion Grafikversion Übersicht

Seite 13 Seite Textversion Grafikversion Übersicht

Abbildung 9: Der zweite Teil des Dienstwunschdialogs

die aufwendige Eingabe. Da zudem noch keine Optimierungsalgorithmen implementiert sind, ist der vom Benutzer erwartete Nutzen eher gering. Die einzigen neuen Erkenntnisse für ihn sind die Analysedaten wie Mitarbeiterauslastung (Abb. 10) und Fahrzeugbesetzungsgrad (Abb. 11).

Bei zukünftigen Projekten (mit externen Kunden) sollte auch darauf geachtet werden, dass der Einstieg für den Benutzer stärker unterstützt wird und nicht nur von einem laufenden Betrieb ausgegangen wird. Die Eingabe und Veränderung einzelner Daten ist in TROSS zwar vernünftig machbar, aber das Eingeben der vorhandenen Touren ist sehr aufwendig: zunächst die Kunden mit ihren Dienstwünsche eingeben, dann Touren und schließlich Untertouren erzeugen. Hier wäre eine direkte Eingabe der Tour und die Erzeugung von Dienstwünschen, Touren und Untertouren schön gewesen. Damit hätte sich der DRK-Mitarbeiter auch mit anderen Teilen des Systems befassen können. Unter der stundenlangen Eingabe der Daten und den dabei aufgetretenen Problemen hat die Motivation des DRK-Mitarbeiters stark gelitten.

8 Ausblick

Ein Problem für die Wartung und Erweiterung des Programms ist die Verwendung der Serialisation von Java zur Speicherung der Daten. Das war zwar sehr einfach zu implementieren, Veränderungen an der Struktur der Klassen machen die gespeicherten Daten jedoch unlesbar. Bei einer neuen Version sollte deshalb die Anbindung an eine Datenbank eingeplant werden.

Seite 13 Seite Textversion Grafikversion Übersicht

Seite 14 Seite Textversion Grafikversion Übersicht

Abbildung 10: Auslastung der Mitarbeiter

Eine andere Erweiterung besteht darin, dem \O" in TROSS wieder zu seiner ursprünglichen Bedeutung zu verhelfen. Eigentlich stand es für \Optimierung", als der Projektgruppe dann aber die Zeit ausging, wurde daraus \Organisation". Interessant ist hier vor allem die automatische Zusammenstellung und Optimierung von Touren und Untertouren. Eine Optimierung der Fahrten, zum Beispiel bei Ausfällen von Mitarbeitern, ist zumindest beim DRK eher nicht sinnvoll, da die Kundschaft großen Wert auf Kontinuität legt.

Die Übertragung von TROSS auf andere Fahrdienste mit ähnlichen Aufgabenstellungen wäre sicher auch interessant (Schulbussysteme, Essensservice). Eine Erweiterung und Anpassung des Datenmodells und der Randbedingungen ist dann entsprechend erforderlich.

Literatur

[1] Balzert, Helmut: Lehrbuch der Softwaretechnik, Band 1: Software- Entwicklung. Spektrum-Verlag, 1996.

[2] Booch, G.: Objektorientierte Analyse und Design. Addison-Wesley, 1994.

[3] Fleischmann, Jörg, Hermes, Lars, Spribille, Tobias und Wagner, Frank: Zwischenbericht der Projektgruppe Transportoptimierung. Universität Stuttgart, Fakultät Informatik, Bericht Nr. 1998/06, 1998.

Seite 14 Seite Textversion Grafikversion Übersicht

Seite 15 Seite Textversion Grafikversion Übersicht

Abbildung 11: Fahrzeugbelegung

[4] Fleischmann, Jörg, Hermes, Lars, Spribille, Tobias und Wagner, Frank: Endbericht der Projektgruppe Transportoptimierung. Universität Stuttgart, Fakultät Informatik, Bericht Nr. 1998/10, 1998.

[5] Ottmann, T. und P. Widmayer: Algorithmen und Datenstrukturen. BI Wissenschaftsverlag, 1993.

Seite 15 Seite Textversion Grafikversion Übersicht