Einleitung

Klingt nicht so spannend, ist es aber. S1000D ist ein (3500-Seiten dicker) Standard zur modularen Dokumentation von Aerospace und Military-Projekten. Modular heißt, da sitzt kein einsamer Redakteur und dokumentiert mal so mit MS-Word einen A380, bis er das als PDF abgeben kann. Sondern alles, was da beschrieben wird, wird auf viele tausend Datenmodule (XML) verteilt, in denen die Struktur, die Reparatur, die Ersatzteile, die Lerninhalte und vieles mehr beschrieben wird - und die natürlich extrem untereinander verlinkt sind. Das ist so komplex, daß es dafür eigene Datenbanken gibt -  Stichwort Common Source Database (CSDB). Aber bevor ein Zulieferer seine Datenmodule einchecken / hochladen kann, sollte er sicher sein, daß diese auch formal korrekt sind. Und da hat jeder Flugzeugbauer oder jede Armee eigenen Vorschriften - in Buchstärke.

Es gibt sogar einen eigenen Englisch-Dialekt (Simplified Technical English), der nur ganz bestimmte Substantive, Verben und grammatikalische Konstrukte zulässt - damit auch nicht-Muttersprachler eine Boeing 747 reparieren können, ohne durch umfangreich verschachtelte Satzungetüme verwirrt die Hydraulik- mit der Treibstoffleitung zu verwechseln.

Die Aufgabe

Wenn ein Zulieferer fehlerhafte Datenmodule abliefert, müssen diese nachbearbeitet werden, was teuer ist und die Abgabefristen gefährden kann. Die Software sollte die Einhaltung der ca. 100 Businessregeln überprüfen und darüber hinaus auch Fehler korrigieren, die beim Checkout aus der CSDB des Zulieferers entstanden waren und für Probleme beim Import in das System des Abnehmers gesorgt hätten.

Umsetzung

Ich habe über einen Zeitraum von mehreren Monaten in einem kleinen Team mit internen und externen Entwicklern eine Grails-Anwendung erstellt, die eine Weboberfläche zum Upload der Daten und die Darstellung der Probleme in syntax-highlighted XML mit Protokollfunktion beinhaltete.

Technologien

  • Grails 1.x
  • XPath für die Regeln
  • MySQL als Datenbank
  • Groovy für programmatische Prüfungen und Fehlerkorrektur.
  • Java 5
  • Saxon XML Bibliothek (kommerzielle Variante)
  • Automatische Integration Tests (in Perl, Test::WWW::Mechanize)
  • Basisfunktionalität für Konformitätstests für Simplified Technical English (STE)

Herausforderungen

  • verteiltes Team (meist aus dem Home-Office)
  • häufig neue Kundenanforderungen und Änderungswünsche
  • mehrere teils willkürliche Deadlines
  • S1000D ist komplex
  • STE prüfen ist noch viel komplexer

Notizen

Eine Analyse von CGM-Dateien (Grafik-Standard) und eine Prüfung der Texte auf Einhaltung der STE-Regeln waren geplant, aber wurde beides nur im Prototypen-Stadium umgesetzt. (CGM-Prüfung wurde später als eigenes Projekt von einem Kollegen umgesetzt).

Mein Anteil: Mitarbeit an der Konzeption, das Projekt-Management und die Implementierung des größten Teils des Server-Codes. Die Business-Regeln wurden gemeinsam mit dem Team umgesetzt, das Design vom Webdesigner entworfen.

Joomla templates by a4joomla