sprachkonstrukt.de

Ein Routenplaner für Gebäudekomplexe: Softwareprojekt der Uni Ulm

Im Rahmen meines Studiums durfte ich in den letzten beiden Semestern an einem größeren Softwareprojekt mitarbeiten, das in Teams zu […]

Im Rahmen meines Studiums durfte ich in den letzten beiden Semestern an einem größeren Softwareprojekt mitarbeiten, das in Teams zu je 6 Personen durchgeführt wurde.

Die Aufgabenstellung: einen Routenplaner à la Google Maps zu programmieren, der dabei helfen soll, sich in der Uni zurechtzufinden. Inspiriert durch den Artikel eines anderen Teams werde ich das Projekt hier kurz vorstellen und von meinen Erfahrungen berichten.

Das System

Das erste Problem, das es zu lösen galt, war eine grafische Darstellung der Stockwerke. Im Vergleich zu Google Maps liegen hier ja Räume und Wege auch übereinander. Da an der Uni Ulm eine Farbcodierung für die Stockwerke zum Einsatz kommt, lag es nahe, diese auch im Routenplaner zu verwenden.
Die Karte selbst ist natürlich zoom- und verschiebbar, wie man das kennt.
Im Suchfeld kann man dann direkt Räume, Personen (bzw. deren Büros) und „Points of Interest“, etwa Toiletten oder Kaffeeautomaten, eingeben und anschließend direkt zu diesen eine Route berechnen lassen. Natürlich sind mehrere Zwischenziele möglich. Abgerundet wird das System durch eine Druckfunktion und eine Möglichkeit, Permalinks generieren zu lassen und so z.B. einen Link zu einem Büro weitergeben zu können.
Für die Pflege des Kartenmaterials und des Büro-„Adressbuchs“ wurde ein Wartungsinterface für einen Administrator benötigt. In diesem besteht die Möglichkeit, die zugrundeliegenden Karten auszutauschen und den Graphen anzupassen, der festlegt, wo Räume und Wege sind.

Technologie

Der Routenplaner selbst musste natürlich als Web-Anwendung realisiert werden und im Browser laufen. Dabei nutzten wir das Google Web Toolkit (GWT), ein Framework, das Java-Code in JavaScript übersetzt. So konnten wir das ganze Projekt wie eine native Java-Anwendung programmieren, am Ende kam aber eine HTML/JavaScript-Webanwendung heraus. GWT bietet dafür schon diverse vorgefertigte Widgets an, die man einsetzen kann (Buttons, Eingabefelder, Suggest-Boxen, Tabellen, …) – man muss sich also relativ wenig um Browseranpassung kümmern (Randnotiz: ironischerweise traten die größten Probleme im Google-eigenen Browser Chrome auf). CSS-Styling beschränkte sich auf wenige Elemente, beispielsweise die mit box-shadow und abgerundeten Ecken versehenen Stockwerk-Tabs und die Druckansicht.
Das Backend hätte auch als native Anwendung realisiert werden können, wir beschlossen jedoch recht früh, dies ebenfalls als Webanwendung mit GWT umzusetzen – viele Bereiche, wie die Kartenanzeige und der Graph konnten so für Front- und Backend wiederverwendet werden.
Auf Serverseite werden Java-Servlets verwendet. Leider wurde uns kein echter Server zur Verfügung gestellt, und so mussten wir stets mit einem lokalen Server arbeiten. Aber auch hier macht es einem GWT leicht, letztlich müssen nur die generierten Dateien auf den Server geladen werden und alles läuft.
Als Datenbank verwendeten wir MySQL, was vollkommen ausreichend war. Aufgrund der Servlet-Architektur kommt die Anwendung mit sehr wenigen Datenbankabfragen aus, so muss der Routing-Graph nur einmal aus der Datenbank aufgebaut werden und kann dann für eine Vielzahl von Anfragen verwendet werden; erst bei einer Änderung des Routinggraphen wird eine neue Abfrage benötigt.
Wir arbeiteten mit dem von GWT favorisierten Activities/Places-Pattern, das an MVP angelehnt ist. Dessen strikte Aufteilung in Places, die einer Unterseite entsprechen, ermöglicht es, dass der Zurück-Button des Browsers wie erwartet funktioniert (bei Webanwendungen leider keine Selbstverständlichkeit).
Für die Darstellung der Karte wurde die Google Maps API verwendet, das Kartenmaterial, das in Bildform vorlag, wurde mit Zoomify in Kacheln unterteilt (Details).

Projektverwaltung

Der spannendste Teil des Projekts war für mich das Management, mit dem ich als Teamleiter recht viel zu tun hatte.
Zuerst galt es, Technologien für die Zusammenarbeit zu finden. Als Versionierungssystem verwendeten wir Git, das wir bei diesem Projekt kennen und lieben gelernt haben. Komplett verteiltes, paralleles Entwickeln wurde dadurch zum Kinderspiel.
Darüber hinaus legten wir Daten auf Dropbox ab, weil es einfach die schnellste Möglichkeit ist, unkompliziert Daten auszutauschen. Das Projekttagebuch, in dem jede Stunde Arbeit verzeichnet werden musste, verwalteten wir auf Google Docs. Vorteil gegenüber z.B. Git war dabei, dass die Datei wirklich nur einmal existierte und alle gleichzeitig ihre Stunden eintragen konnten. Dabei stellte sich auch heraus, dass Google Docs für große Dokumente ab 50 Seiten noch ungeeignet ist – die Dokumentation wurde zu Beginn auch auf Google Docs gespeichert, und der Download als PDF ging in 4 von 5 Versuchen schief.
Gefehlt hat noch ein Bugtracking-System. Da hätten wir gerne Trac verwendet, mussten aber mangels Entwicklungsserver leider darauf verzichten.
Die Kommunikation und Koordination fand überwiegend in einem Skype-Gruppenchat statt, der dafür erstaunlich gut geeignet ist, da auch Nachrichten, die in Abwesenheit geschrieben wurden, definitiv ankommen.
Einen großen Teil des Projekts stellte die Qualitätssicherung dar, ein Aspekt, auf den in der Uni sonst nur selten eingegangen wird. Code-Reviews sind zwar todlangweilig, aber durchaus sinnvoll – einige Flüchtigkeitsfehler konnten so noch behoben und damit die Gesamtqualität des Projekts gesteigert werden.
Ein weiterer Aspekt, auf den in der Uni kein Wert gelegt wird, ist leider die Sicherheit. Eigentlich ein Skandal, doch in Vorlesungen stehen Kapitel zu Security und Privacy leider meist am Ende des Semesters und fallen dann nicht selten wegen Zeitmangel aus – eine eigene Pflichtvorlesung zu dem Thema gibt es im Informatikstudium an der Uni Ulm nicht. Dafür ganz viel Mathe.
Die Anmeldung des Administrators wollten wir zuerst nach allen Regeln der Kunst absichern, doch unser Betreuer legte uns nahe, das wegzulassen, da darauf nicht der Fokus des Projekts läge. Und so steht das Administratorkennwort im fertigen Projekt unverschlüsselt in einer Konfigurationsdatei auf dem Server und wird natürlich auch unverschlüsselt übertragen. Security ist an der Uni leider keine Anforderung.

Auszeichnung

Leider ist das Softwareprojekt, einer der wichtigsten Teile des Studiums, unbenotet. Immerhin konnte unser Team einen der drei „Awards“ bekommen, den für die beste Usability.
Zusätzlich durften wir als einziges Team unser Projekt dem „echten Kunden“ vorstellen, dem Gebäudemanagement der Uni Ulm, für welches das Institut, das das Softwareprojekt betreute, parallel ein echtes, noch etwas umfangreicheres Einsatzsystem entwickelte.
Die Projekte der einzelnen Teams werden nun leider in der Versenkung verschwinden, schließlich stellen sie ja nur eine etwas größere Übungsaufgabe dar. Das ist natürlich schade. Doch immerhin eines hinterlässt das Projekt bei mir: das Gefühl, mal wirklich etwas produziert zu haben, und viel Gelerntes (ich würde sogar so weit gehen, zu sagen, dass ich in keiner anderen Uni-Veranstaltung so viel gelernt habe).