Im Rahmen des Softwarepraktikums soll eine webbasierte Ankunfts- und Abfahrtsanzeige als Teil eines Fahrgastinformationssystems für das Eisenbahnbetriebslabor entwickelt werden. Über die Webseite sollen die Benutzer einen Bahnhof und eine Uhrzeit eingeben und auswählen, ob sie Ankunfts- oder Abfahrtszeiten angezeigt haben wollen. Ausgehend von den Zuggattungen aus dem Fahrplan soll der Benutzer die Anzeige auch nach Zuggattungen filtern können. In den Ankunfts- und Abfahrtsanzeigen sollen zu jedem Zug auch alle nachfolgenden Halte eingeblendet werden und zusätzlich zu jedem Zug noch Echtzeitinformationen angezeigt werden können, wie Verspätungsminuten und Textmeldungen. Als Orientierungshilfe kann von der Online-Abfahrtsanzeige der Deutschen Bahn ausgegangen werden: http://reiseauskunft.bahn.de/bin/bhftafel.exe/
-
Erreichbarkeit unter http://<Hostname-des-Webserevrs>/fis
-
Auswahl des anzuzeigenden Inhalts:
-
Abfahrtstafel
-
Ankunftstafel
-
Zuglauf
-
-
Kopfzeile mit:
-
änderbarem Logo (links)
-
seitenabhängiger Text (mittig)
-
aktuelle Laborzeit (rechts)
-
-
Fußzeile mit:
-
statischem Text (rechts)
-
Verbindungsstatus zum Fahrplanserver (links)
-
Programmversion (links)
-
-
Abfahrts- / Ankunftsanzeige
-
Zeit
-
Zug (Zugtyp und -nummer)
-
Richtung / Zwischenhalte (jeweils mit Ankunfts- bzw. Abfahrtszeit)
-
Gleis
-
Aktuelles
-
-
Zuglaufanzeige
-
Bahnhofsname
-
Ankunftszeit (planmäßig und Verpätung)
-
Gleis planmäßig und tatsächlich
-
Abfahrtszeit (planmäßig und Verpätung)
-
aktuelle Meldungen
-
-
mehrere Tabs möglich
-
muss auf Hard- und Software des Kunden laufen (siehe Randbedingungen)
-
Interaktiver Wechsel zwischen Bahnhofs- und Zuglaufdarstellung durch Klick auf das jeweilige Objekt
-
Verbindung zum Fahrplanserver muss konfigurierbar sein (Hostname, Port, ClientID)
-
Zuordnung von Betriebsstelle und Kürzel über Textdatei (Kürzel=Voller Name)
-
Ausblenden der Uhrzeit, wenn keine Verbindung zum Fahrplanserver besteht
-
Verbindungsstatus (nicht verbunden, Verbindungsaufbau, verbunden)
-
Logo als GIF, PNG oder JPEG
-
Zuglaufanzeige ähnlich einer Perlenschnur
-
Vor- / Zurückfunktion des Browsers korrekt verwendbar
-
keine dauerhafte Speicherung der Fahrplandaten (zum Beispiel in einer Datenbank)
-
Erweiterbarkeit
-
unmittelbare Reaktion auf Benutzerinteraktion
-
Sortierung der Abfahrten/ Ankünfte nach Sollzeit
-
automatisches Aktualisieren der Webseite
-
zusätzliche Auswertung von Koordinaten der Betriebsstellen
-
Visualisierung dieser auf einer passend skalierten Karte inklusive der Zugläufe zwischen diesen
-
Auswahl einer Betriebsstelle über die Visualisierung soll möglich sein
-
derzeit ausgewählte Betriebsstelle soll farbig hervorgehoben werden
| Nutzer | Administrator | Fahrplan-Server |
|---|---|---|
Ankunft/Abfahrt/Zug einstellen |
Konfigurieren |
Telegramme senden |
Bahnhof einstellen |
||
Zug wählen |
||
Anfangszeit wählen |
||
Endszeit wählen |
||
Zielbahnhof eingeben |
||
Ergebnisse abrufen |
||
Ergebnisse filtern |
Der Nutzer hat über einen festen Hostnamen Zugriff auf das Fahrgastinformationssystem. Dabei kann er zwischen einer Ankunftstafel, einer Abfahrtstafel, einer Zuglaufsdarstellung und einer interaktiven Karte der Betriebsstellen wählen. Er hat ebenfalls die Möglichkeit das Ergebnis nach einem bestimmten Zeitrahmen, Zugtypen oder Zielbahnhof zu filtern.
Der Fahrplan-Server ist für die Bereitstellung aktueller Daten verantwortlich. So liefert dieser beispielsweise Telegramme mit Zugläufen oder die aktuelle Laborzeit.
Der Administrator hat die Möglichkeit den Hostnamen, den Port, die Client ID (mit der sich das Fahrgastinformationssystemes am Fahrplan-Server anmeldet), die Zeit (timeTillReconnect), die bestimmt, wann die Applikation nach einem Verbindungsabbruch einen Wiederverbindungsversuch startet, und den Timeout (timeout), der bestimmt nach welcher Zeit die Applikation in den Offline-Modus übergeht, einzustellen. Damit diese Änderungen in Kraft treten, muss das Fahrgastinformationssystem neu gestartet werden. Ebenfalls kann der Pfad zur Fahrplan-XML, der Pfad zur message.csv (der Datei mit der Liste aller Meldungstexte), der Pfad zum Logo un der Benutzertext geändert werden.
Die Klasse TimetableData agiert als "Masterklasse" und hat alle wichtigen Instanzen der Fahrplandaten, wodurch man über die Klasse auf alle Daten zugreifen kann. Die TimetableController-Klasse hat die Aufgabe die TimetableData mit entsprechenden Daten anfangs zu füllen und stellt eine Schnittstelle nach außen für das Timetable-Packege dar. Jede TrainRoute hat eine Liste von Stops, welche wiederrum eine Referenz auf eine TrainRoute und eine Station haben. Die Station-Klasse verhällt sich analog. Dies dient der Verlinkung der Objekte und der Möglichkeit, von einem bestimmten Zuglauf über einen Stop zu dem zugehörigen Bahnhof zu kommen und umgekehrt. In dem GUI hat jeweils die Abfahrts-, die Ankunfts- und die Zuglaufsanzeige jeweils ihre eigene Funktion, da diese auf verschiedene URLs verweisen. Dadurch können Links kopiert und auf anderen Geräten ebenfalls (mit identischem Ergebnis) aufgerufen werden. Die TelegramReceiver-Klasse läuft in einem seperaten Thread, der nur die Aufgabe hat, auf Telegramme zu warten. Die Funktion erstellt bei Erhalt eines Telegramms ein solches und gibt es dann der TimetableController-Klasse weiter. Dabei werden die Daten "gelocked", um einen Zugriff während des Änderungsvorganges zu verhindern. Die XML-Datei, die den Fahrplan für den Offline-Modus liegt im RailML-Format vor. Das railml-Package stellt dafür alle nötigen Funktionen zum Auswerten der Daten bereit.
Das Fahrgastinformationssystem ist mithilfe des Spring-Frameworks in Java 8 implementiert. Grundlegend ist es in Telegrammteil (telegrams), einen Telegrammempfängerteil (telegramReceiver), einen XML-Teil (railmlparser), einen GUI-Teil (web) und einen Fahrplanteil (data) unterteilt.
Der Telegrammteil beinhaltet alle erstellbaren Telegramme, welche durch die TelegramParser-Klasse erstellt werden. Der Telegrammenpfänger kümmert sich um die Interatkion mit dem Fahrplan-Server und gibt erstellte Telegramme an den TimetableController im Fahrplanteil weiter. Dort werden die Telegramme aufgelöst und die Änderung wird an dem entsprechenden Objekten in den Fahrplandaten vorgenommen. Eine Ausnahme davon ist die aktuelle Laborzeit (time in der TimetableData-Klasse), welche sofort vom Telegrammempfänger gesetzt wird. Dies dadurch möglich, dass die aktuelle Laborzeit mit der "@Autowired"-Annotation versehen ist. Falls anfangs keine Verbindung zum Fahrplan-Server hergestellt werden kann, werden die benötigten Daten mithilfe des XML-Teiles geladen und anschließend durch den Fahrplan in die Fahrplandaten übernommen. Die TimetableController-Klasse hat die Aufgabe die Daten des Fahrplanes für das GUI bereitzustellen, welches diese dann filtert und mittels Thymeleaf dann auf der Webseite ausgibt.
Das Spring-Framework orientiert sich bei seiner Implementierung der Nutzerschnittstelle an dem Model-View-Controller-Pattern, wodurch dieses auch in der Web-Applikation wieder zu finden ist in Form der TimetableData-Klasse (Model), der FisController-Klasse (Controller) und in der Thymeleaf implementierten Web-Darstellung (View).
Da die Telegramme unterschiedliche Form haben können und unterschiedliche Daten übermitteln sollen, aber diese jedoch alle Telegramme sind, wurde sich hier für das Strategy-Pattern entschieden. Dadurch lassen sich die Telgramme leicht in Unterkategorien aufteilen und können allgemeine Eigenschaften aus ihren abstrakten Oberklassen erben.
Die TimetableData Klasse stellt eine Fassade zu den Kerndaten wie den Zugläufen und Stationen dar. Die TimetableController-Klasse bildet eine Fassade zum kompletten data-package. Dadurch wird der Zugriff auf die Daten eindeutiger ersichtlich und einfacher zu handhaben.
Auf das Singleton-Pattern wurde bei diesem Entwurf bewusst verzichtet, da sich dies mit der von dem Spring-Framework bereitgestellten "@Autowired" Annotation ähnliches einfacher implementieren lässt.
Die für das Anzeigen der Fahrpläne benötigten Daten werden bevorzugt von dem Fahrplan-Server bezogen und nur bei Verbindungsproblemen aus einer lokal gespeicherten XML-Datei geladen. Weiterhin wird eine Konfigurationsdatei lokal gespeichert in der Hostname, Port, der Pfad zur Fahrplan-XML, der Pfad zur message.csv, der Pfad zum Logo, der Benutzertext, die Zeit bis zur Wiederverbindung (timeTillReconnect) und die Zeit bis zum Verbindungsabbruch (timeout) gespeichert wird.
Es ist möglich und vorgesehen, dass die Anwendung hinter einem als Reverse Proxy konfigurierten Apache Server läuft. Das hat den Vorteil, dass sie einfacher für den Benutzer vom lokalen Netzwerk aus erreichbar ist. Im folgenden Abschnitt wird die Konfiguration eines Apache Servers für FIS angegeben.
Abhängig von der Apache Version und vom Betriebssystem kann die Konfiguration des Webservers eine einzelne Datei (meistens 'httpd.conf') umfassen oder in mehreren Dateien aufgeteilt sein. Bei Unsicherheit fragen Sie Ihren Systemadministratoren. Zuerst müssen die benötigten zusätlichen Module aktiviert werden. Dies geschieht durch das Hinzufügen folgender Zeilen zu der Konfiguration, falls sie noch nicht vorhanden sind:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule headers_module modules/mod_headers.so
LoadModule filter_module modules/mod_filter.so
LoadModule deflate_module modules/mod_deflate.soDann muss das eigentliche Proxy auch konfiguriert werden:
ProxyRequests off # (1)
ProxyPass /fis http://localhost:8080 # (2)
ProxyPassReverse /fis http://localhost:8080
<Location "/fis">
ProxyHTMLEnable On
ProxyHTMLURLMap ^/(.*)$ /fis/$1 R
ProxyHTMLDocType "<!DOCTYPE html>" # (3)
Order allow,deny
Allow from all
</Location>-
Aus Sicherheitsgründen soll diese Einstellung immer
offsein. -
Der erste Parameter bestimmt den Pfad, unter dem die Anwendung erreichbar sein wird (in diesem Fall 'http://<Adresse-des-Apache-Servers>/fis'), und kann nach Belieben verändert werden. Wichtig ist, dass der gleiche Pfad überall in der Konfigurationsdatei benutzt wird. Der zweite Parameter ist die URL des internen Tomcat-Servers und soll nicht verändert werden.
-
Stellt sicher, dass HTML5 korrekt angezeigt wird.
Für den korrekten Betrieb der Applikation werden folgende Dinge benötigt:
-
fis.jar (kann umbenannt werden)
-
Fahrplan-XML (kann umbenannt werden, aber der Name muss in die application.properties übernommen werden)
-
application.properties
-
eine Datei mit den Meldungstexten (siehe Aufbau der Meldungstextdatei)
-
ein Logo (laut Pflichtenheft im .PNG- oder im .JPG-Format)
Mittels der 'application.properties', die im Verzeichnis der Applikation liegt ist es möglich sämtliche Konfigurationen vorzunehmen.
# a development configuration, please replace with application.properties.production
fis.railmlpath = EBL Regelfahrplan.xml # (1)
fis.messagecsvpath = ./messages.csv # (2)
fis.benutzertext = Fubar # (3)
fis.logoPath = logo.png # (4)
# Konfiguration für den Telegrammempfänger (TelegramReceiverConfig)
telegramserver.hostname = 10.2.0.101 # (5)
telegramserver.port = 9910 # (6)
telegramserver.clientID = 42 # (7)
telegramserver.timeout = 1000 # (8)
telegramserver.timeTillReconnect = 5000 # (9)Folgende allgemeine Konfigurationen können vorgenommen werden:
-
gibt den Pfad zur Fahrplan-XML aus, die geladen wird im Falle, dass der Farhplan nicht vom Server bezogen werden kann.
-
gibt den Pfad zu der Datei mit allen Meldungstexten an, die als Information zu einem Halt oder Zuglauf angezeigt werden können.
-
enthällt den Nutzertext, der im Footer auf der rechten unteren Teil der Webseite angezeigt wird.
-
gibt den Pfad zum Logo an, was in der linken oberen Ecke der Webseite zu sehen ist, an. Der Pfad dazu muss auf eine (absolute) Webadresse verweisen und nicht auf eine lokale Datei!
-
gibt den Hostname des Fahrplanservers an.
-
gibt den Port an unter dem der Fahrplanserver erreichbar ist.
-
ist die Client ID mit dem sich die Applikation am Fahrplanserver anmeldet.
-
ist die Zeit bis ein Verbindungsversuch abgebrochen wird.
-
ist die Zeit bis zum erneuten Verbindungsversuch.
Die Konfigurationen <5> bis <9> dienen zur Konfiguration des Telegrammenpfängers.
Die Meldungstexte sind im CSV-Format (Comma seperated values; in diesem Falle werden statt Kommata Semikola verwendet) gespeichert. An erster Stelle steht ein Meldungsindex, der nicht doppelt vorkommen kann. Dieser wird von einem Semikolon und dem Meldungstext gefolgt. Sollte der Meldungstext Semikola enthalten, sollte der Text in Anführungszeichen gesetzt werden.