Schlanke Dokumenten-Templates mit OpenOffice.org und FreeMarker

JODReports

JODReports

Schlanke Dokumenten-Templates mit OpenOffice.org und FreeMarker

JODReports


Das Erstellen von Reports oder ähnlichen Dokumenten, die ausgedruckt und an einen Kunden ausgehändigt werden können, ist eine häufige Anforderung an ein Softwaresystem. JODReports ist eine Open-Source-Bibliothek, mit der sich solche Anforderungen realisieren lassen. Der folgende Artikel erläutert, welche Vorteile JODReports aus der Sicht eines Businessanalysten, Entwicklers oder Projektmanagers zu bieten hat.

JODReports [1] bietet im Vergleich zu seinen Konkurrenten (JasperReports [2], ReportWeaver [3]) gute Möglichkeiten, Dokumenten-Templates testgetrieben zu erstellen und im Rahmen von Continuous Integration auch automatisch Regressionstests durchzuführen. Das dadurch erreichte schnelle Feedback erlaubt es, die im Lebenszyklus einer Anwendung notwendigen Refactorings sowohl am Datenmodell des Reports als auch am Dokumenten-Template ohne Risiko durchzuführen. JODReports kombiniert das OpenDocument-Textformat (.odt) [4] mit dem gesamten Sprachumfang der bekannten FreeMarker Template Engine [5]. Auf dieser Grundlage können die JODReports Templates sowohl aus Desktop- als auch aus Webanwendungen heraus zur Reportgenerierung verwendet werden. Erstellung, Wartung und Deployment der Templates fügen sich dabei sehr harmonisch in die übliche Werkzeugumgebung eines Java-Entwicklers ein.

Warum Entwicklungsteams JODReports einsetzen wollen

In der Softwareentwicklung sind agile Vorgehens­modelle wie XP, Scrum oder Kanban längst „state of the art“. Alle Modelle haben ein gemeinsames Ziel: die Entwicklung qualitativ hochwertiger Software sicherzustellen. Eine Schlüsselrolle wird in agilen Prozessen dem funktionsübergreifenden (cross-functional) Team zugesprochen. Ein funktionsübergreifendes Team übernimmt die Verantwortung für das gesamte Produkt von der Konzeption über die Entwicklung bis zum Betrieb des Produkts. Außerdem liegen der Entwicklungsprozess und die Auswahl der richtigen Technologien zur Umsetzung der Anforderungen in den Händen des Entwicklungsteams. Die Technologie muss zum Entwicklungsprozess des Teams passen und sich so gut wie möglich in die vorhandene Infrastruktur integrieren. Bei der Wahl einer Technologie zur Erstellung von Dokumenten-Templates gibt es verschiedene Argumente, die gegen den Einsatz von Konkurrenzprodukten und für den Einsatz von JODReports sprechen. Gegen Konkurrenzprodukte sprechen aus unserer Sicht die folgenden Punkte:

  • Für das Erstellen von Dokumenten wird in der Regel Spezialsoftware benötigt. Der zeitliche und finanzielle Aufwand für die Schulung aller Softwareentwickler in der Nutzung der Spezialwerkzeuge ist zu hoch.

  • Die Spezialwerkzeuge lassen sich nicht oder nur schwer in Entwicklungsumgebungen oder Build-Prozesse und Build-Werkzeuge integrieren. Softwareentwickler benutzen diese Werkzeuge daher nur ungern.

  • Die Dokumenten-Templates können nicht testgetrieben entwickelt werden, da es keine oder nur ungenügende Werkzeuge gibt, um die Templates zu testen und die Tests in den Continuous-Integration-Prozess einzubinden.

  • Im Falle von ReportWeaver muss zum Erstellen der Dokumenten-Templates das Spezialwerkzeug TemplateStudio verwendet werden. Es ist nur für die Windows-Plattform verfügbar. Das grenzt Softwareentwickler aus, die auf anderen Plattformen wie OS X oder Linux arbeiten.

Dem gegenüber steht eine Reihe von Punkten, die unserer Meinung nach für den Einsatz von JODReports sprechen:

  • Der Einarbeitungsaufwand in JODReports ist verhältnismäßig klein, da mit OpenOffice und FreeMarker bekannte Werkzeuge zum Einsatz kommen.

  • JODReports ist eine Java-Bibliothek, die in jeder Java-Anwendung benutzt werden kann. Es gibt keinen Bruch in den verwendeten Technologien.

  • Es gibt ein Modul von JODReports, das es ermöglicht, mithilfe von Java Assertions auf den Inhalt von Dokumenten zuzugreifen, die im OpenDocument-Textformat vorliegen. Dadurch wird die testgetriebene Entwicklung von Dokumenten-Templates möglich. Mehr dazu im Abschnitt „Wie Entwickler Projektmanagern und BAs diesen Wunsch erfüllen“.

  • Mit OpenOffice steht ein Template-Editor zur Verfügung, der für alle gängigen Plattformen (Windows, Linux und OS X) verfügbar ist.

JODReports lässt sich damit grundsätzlich in eine Java-Entwicklungsinfrastruktur einbinden. Dokumenten-Templates können auf allen gängigen Plattformen erstellt und bearbeitet werden. Ein weiterer Pluspunkt von JODReports besteht darin, dass es sich auch harmonisch in bestehende Entwicklungsprozesse einbinden lässt. Der folgende Abschnitt zeigt, wie wir in unserem Team diese Prozesseinbindung konkret vorgenommen haben.

Unser Prozess zur Erstellung von Dokumenten-Templates mit JODReports

Wie in Abbildung 1 illustriert, entstehen die Ideen für Dokumente beim Kunden. Gemeinsam mit einem Businessanalysten erarbeitet er unter Verwendung von OpenOffice den ersten Entwurf des zu generierenden Dokuments. Dabei werden bereits viele gestalterische und inhaltliche Details festgelegt. Es werden Entscheidungen über Schriftart, -größe, Überschriften, Aufzählungen, Seitenränder, Kopf- und Fußzeilen getroffen und im Entwurf verankert. Weiterhin wird definiert, welche Textpassagen variabel sein sollen und mit welchen Daten sie zu befüllen sind. Statische Textpassagen können bereits vollständig erstellt und exakt so formatiert werden, wie sie später im Dokument auftauchen sollen. Bis auf die dynamischen Anteile entspricht dieser Entwurf bereits dem von der Anwendung zu generierenden Dokument. Damit ist ein signifikanter Teil der zur Herstellung eines Dokumenten-Templates notwendigen Arbeit bereits erledigt.

fahrenkrug_jodreports_abb_1.tif_fmt1.jpg Abb. 1: Unser Prozess zur Entwicklung von Dokumenten-Templates

Beim Einsatz von Konkurrenzprodukten wird dieses häufig als Blaupause (Blueprint) bezeichnete Dokument nun als Spezifikation für ein zu erstellendes Dokumenten-Template in das Entwicklungsteam gegeben. Die Spezifikation wird dort mithilfe der gewählten Dokumententechnologie in ein Template übersetzt. Ein Großteil der Arbeit, die bereits in das Erstellen des Layouts, die Erstellung der statischen Textelemente und die Definition der variablen Textpassagen im Blueprint geflossen ist, muss mit der gewählten Technologie wiederholt werden. Diese Arbeit ist häufig sehr monoton und damit fehleranfällig.

Unnötige Arbeit vermeiden!

In agilen Softwareentwicklungsprozessen wird besonderer Wert darauf gelegt, unnötige Arbeit zu vermeiden (avoid waste). Im hier vorgestellten Prozess wird daher der Blueprint in OpenOffice erstellt, sodass er ohne Änderungen bereits als erste Version des Dokumenten-Templates dienen kann. Für die Weiterentwicklung wird er in ein Versionskontrollsystem eingecheckt und gemeinsam von Entwicklern, Businessanalysten (BAs) und, soweit möglich, auch vom Kunden gepflegt. Die Aufgabenteilung bei der weiteren Entwicklung sieht dabei folgendermaßen aus:

  • Die BAs tragen die Verantwortung für die statischen Textelemente und das Layout.

  • Die Entwickler sind verantwortlich für die Definition und Wartung des Eingabedatenmodells und für die Umsetzung aller dynamischen Textpassagen. Dazu gehört sowohl die Instrumentierung des Dokumenten-Templates mit FreeMarker-Skripten als auch die Sicherstellung der Korrektheit dieser Skripte durch automatische Tests im Rahmen eines Continuous Integration (CI) Builds.

  • Das Sicherheitsnetz aus automatischen Tests erlaubt es, dass BAs und der Kunde jederzeit während der Entwicklung ohne Risiko Änderungen an statischen Texten und dem Layout vornehmen können. Spätestens nach dem Check-in in die Versionsverwaltung liefert der CI Build Feedback darüber, ob das Tem­plate noch korrekt funktioniert.

Modularisierung erlaubt Parallelisierung bei der Erstellung!

Arbeitsteiliges Umgehen mit ein und derselben OpenDocument-Textdatei ist schwierig, weil OpenOffice komprimierte Binärdateien erzeugt. Gleichzeitig durchgeführte Änderungen an einer Datei lassen sich daher schwer zusammenführen (mergen). Es ist zwar theoretisch möglich, zwei Versionsstände mithilfe der OpenOffice...