Lade Inhalt...

Dynamische Präsentation von XML-Daten

Diplomarbeit 2007 94 Seiten

Informatik - Software

Leseprobe

Inhaltsverzeichnis

1. Einleitung

2. Aufgabenstellung und Projektplanung
2.1. Aufgabenstellung
2.2. Projektplanung

3. Fachliches Umfeld und Lösungsansätze
3.1. Präsentationssoftware
3.2. Technikstudie
3.3. Lösungsansätze
3.4. Fazit

4. Anforderungsdefinition
4.1. Zeitrahmen
4.2. Begrifflichkeiten
4.3. Kostenrahmen
4.4. Betriebsbedingungen
4.5. Zielbestimmung
4.6. Muss-Kriterien
4.7. Soll-Kriterien
4.8. Kann-Kriterien
4.9. Abgrenzung
4.10. Anwendungsszenario
4.11. Funktionalität
4.12. Benutzeroberfläche
4.13. Programmierrichtlinien
4.14. Diagramme

5.Systementwurf
5.1. Entwurf der Modularität
5.2. Paketstruktur
5.3. Klassenübersicht
5.4. Entkopplung der Komponenten

6. Implementierung
6.1. Implementierung der Modularität
6.2. Kommunikation: Event-Driven
6.3. Programming without Assignment
6.4. Modulare XSLT-Dokumente
6.5. Präsentationsanzeige: XHTML
6.6. Assert
6.7. Zentrale Ausnahmebehandlung
6.8. Systemtest
6.9. Eclipse-ClassLoader Problem

7. Benutzeranleitung
7.1. Bedienungsanleitung
7.2. Parametrisierung eines XSLT-Dokuments
7.3. Beschreibung der Programmierschnittstellen

8. Zusammenfassung und Ausblick
A. Ressourcenplanung
A.1. Hardware
A.2. Software
A.3. Computerkonfiguration
B. Multidisplay-Umgebung einrichten

Abkurzungsverzeichni

Literaturverzeichni

Abbildungsverzeichnis

Danksagung

In erster Linie möchte ich mich an dieser Stelle bei meinem Betreuer Herrn Prof. Dr. Solymosi bedanken, der immer einen guten Einfall für die Verbesserung der schriftlichen Ausarbeitung vorweisen konnte.

Insbesondere möchte ich an dieser Stelle Herrn Manuel Bähnisch danken, der die schwierige Aufgabe der Korrektur übernommen hat und auch sonst immer einen guten Rat parat hatte.

Ebenfalls dankbar bin Ich Herrn Clemens Zimmermann und Frau Gisela Krue- ger, die es mir ermöglichten, zu sehr angenehmen Bedingungen, während der Diplomarbeit, als Mitarbeiter der Technischen Universität Berlin weiterzuarbeiten. Ebenso möchte ich mich für das Bereitstellen der Ressourcen für den Druck mei- ner Arbeit bedanken.

Dankbarkeit gebührt auch meiner Familie, die mich seit jeher in meinen Entschei- dungen und Handlungen unterstützt hat und dabei nie an mir zweifelten.

1. Einleitung

In den letzten Jahren hat die Auszeichnungssprache XML durch ihre Flexibilität, Erweiterbarkeit und Plattformunabhängigkeit die Kommunikation zwischen An- wendungen und die Kompatibilität und Portierbarkeit von Daten maßgeblich ver- ändert. Die meisten Webservices oder Informationsdienste die uns heutzutage im Internet mit Informationen, Webmail und Instant Messaging versorgen, wür- den ohne die Extensible Markup Language, kaum noch denkbar sein.

Viele Manager, Dozenten, Angestellte oder Studenten müssen beinahe täglich Präsentationsvorlagen für die Darstellung von komplexen Sachverhalten erstel- len. Die meisten dieser Vorlagen werden mit gängigen Software-Produkten, wie „Powerpoint“ von Microsoft, erstellt.

Ein großer Nachteil vorhandener Präsentations-Software ist die enge Verzah- nung der Daten mit dem Design. Hierdurch können die in der Präsentation ent- haltenen Informationen nur durch einen erhöhten Arbeitsaufwand anderweitig ge- nutzt werden. Erschwerend kommt dazu, dass die erstellten Präsentationen einer Softwareabhängigkeit unterliegen, da die verwendeten Dateiformate nur selten kompatibel sind.

Als Sprache zur Datenauszeichnung geht XML hier einen anderen Weg, denn XML nimmt nur die Daten auf und läßt jegliche Formatierungsanweisungen au- ßen vor. Gleichzeitig wird jedoch mit XSLT eine Möglichkeit der Transformierung von XML-Dokumenten in beinahe jedes beliebige andere Format gegeben.

Ein Teil der oben geschilderten Problematik wird in dieser Abschluss-Arbeit aufgegriffen und es wurde, unter Zuhilfenahme von XML-Technologien, Java und Eclipse-RCP, ein Konzept für das dynamische Präsentieren von XML-Daten er- stellt. Dieses erlaubt dem Benutzer die Vorteile von XML für das Ausrichten einer Präsentation, über eine komfortable GUI die über mehrere Monitore verteilbar ist, zu nutzen.

In den folgenden acht Kapiteln wird Schritt für Schritt das Konzept für die Umsetzung des Themas „Dynamische Präsentation von XML“ dieser Abschluss- Arbeit entwickelt und beschrieben. Es werden Lösungsansätze und Technologien beschrieben, die bei der Umsetzung untersucht wurden und es werden Einblicke in die Funktionsweise des entwickelten Programms vermittelt.

Zuletzt möchte ich noch erklären, warum ich mir dieses Thema für meine Di- plomarbeit ausgesucht habe. Ich arbeite seit ca. zweieinhalb Jahren als System- und Netzwerkadministrator an der Technischen Universität Berlin im IT-Service- Center (tubIT). Mein Hauptaufgabenbereich liegt in der Betreuung von Linux/Unix und Windows Server-Anlagen.

Seit dem Beginn der Umstrukturierung des IT-Services der TU-Berlin im Ok- tober 2006 erreichen mich beinahe täglich neue Informationen per E-Mail, über Änderungen bzw. Erweiterungen des IT-Service. Diese Informationen werden zu- meist als, PDF-Format konvertierte, „Powerpoint-Präsentationen“ den Angestell- ten zur Verfügung gestellt. Auffällig bei diesen Präsentationen ist, dass die ent- haltenen Informationen annähernd unverändert blieben und nur in einem anderen Kontext genutzt wurden.

Daher empfand ich den Vorschlag von Hr. Prof. Dr. Solymosi meine Abschluss- Arbeit über das Thema der „Dynamische Präsentation von XML zu schreiben als sinnvoll, da hierfür ganz deutlich ein praktischer Verwendungsbedarf besteht.

2. Aufgabenstellung und Projektplanung

2.1. Aufgabenstellung

Die Zielsetzung der vorliegenden Diplomarbeit ist es, eine Software für das dy- namische Präsentieren von XML-Daten zu entwickeln, welche die Daten anhand eines XML Schemas validiert, mittels eines gegebenen Templates konvertiert und somit wieder in eine Präsentationsfähige Form überträgt. Damit das Hauptfens- ter weiterhin für die Bearbeitung der Präsentation genutzt werden kann, soll das Anzeigen des Ergebnisses der Konvertierung auf einem zweitem Ausgabegerät erfolgen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.: Konzept für das dynamische Präsentieren anhand von XML

Zusätzlich sollte das für die Konvertierung genutzte Template, zur Laufzeit der Präsentation durch den Benutzer über eine grafische Benutzeroberfläche bear- beitbar sein. Hierbei sollten die Eingaben des Anwenders exportier- und impor- tierbar sein.

Zudem wird die Integration einer Schnittstelle für die Erweiterung des Anzei- gemechanismus angestrebt, so dass die Funktionalität der Software durch das Hinzufügen neuer Komponenten erweitert werden kann. Nach Rücksprache mit dem Betreuer der Abschluss-Arbeit, wurde dieser Aspekt insofern erweitert, dass eine vollständige Modularität der Software angestrebt wird (siehe Kapitel 5.1 auf der Seite 45).

Eine weitere Aufgabe für die Implementierung ist es, Komponenten für die An- zeige und Speicherung einer XHTML-Präsentation bereitzustellen. Ebenso ge- plant ist die Umsetzung einer Komponente, mit der die erzeugte Präsentation als Java-Objekt serialisiert werden kann. Die Abbildung 2.1 auf der Seite 9 visuali- siert hierbei den erörterten Sachverhalt.

Zunächst einmal wird in einer Studie der derzeitig verfügbaren Technologien genau zu erörtern sein, wie die Konvertierung der XML-Daten praktisch erfolgen kann. Des weiteren bedarf es Recherchen nach Techniken, die für die Umsetzung der geplanten Modularität genutzt werden können. Im Rahmen dieser Diplomar- beit sollen als Ergebnis zusammenfassend folgende Punkte erarbeitet werden:

1. Framework:

a) Welche Frameworks gibt es und sind prinzipiell für die Umsetzung ge- eignet?
b) Welches Framework eignet sich für den Aufbau einer verteilten Benut- zeroberfläche?
c) Welches Framework eignet sich für die Umsetzung einer Komponenten basierten Software?

2. Verarbeitung von XML:

a) Welche Konvertierungsverfahren für XML-Dokumente gibt es?
b) Wie lassen sich die XML-Dokumente am effektivsten verarbeiten?
c) Wie lassen sich XML-Daten für das dynamische Präsentieren einfach verarbeiten?

2.2. Projektplanung

Nachfolgend werden die für die Umsetzung des Konzepts benötigten Ressour- cen, wie z.B. die verwendete Hard- oder Software, zusammenfassend aufgeführt und erläutert. Eine detaillierte Beschreibung, der für die Umsetzung bzw. Wei- terführung des Konzepts benötigten Ressourcen findet sich im Anhang A ab der Seite 79.

Am Ende des Kapitels folgt dann ein vorläufiger Arbeitsplan, welcher den ver- mutlichen Arbeitsaufwand pro Projektphase aufzeigt. Während des Bearbeitungs zeitraums dient der Arbeitsplan, als Richtwert und Kontrolleinheit für den Projekt- fortschritt.

2.2. Projektplanung

2.2.1. Hardware

Zur Bearbeitung der Abschlussarbeit wird ein Computer aus der Business-Collection von „Dell“ genutzt, welcher den unteren Eckdaten entspricht

- Intel CPU Dual Core mit 2.8 GHz
- 1024 MB Arbeitsspeicher
- Nvidia PCI-Express Grafikkarte mit zwei Monitorausgängen
- Flachbildschirm 2x 19“
- 80 GB SATA Festplatte

Natürlich läßt sich mit leistungsstärkeren PCs komfortabler arbeiten, aber den- noch steht die Motivation, ein für das Projekt angemessenen Kosten- und Nutzen- rahmen einzuhalten. Im Anhang A ab der Seite 79 wird hierfür eine Konfiguration vorgestellt.

2.2.2. Software

Für das Bearbeiten der Abschluss-Arbeit werden mehrere unterschiedliche An- wendungen genutzt, so wird für die programmatische Umsetzung die Standard Edition des „Java Development Kits“ von Sun Microsystems und die kostenfreie Entwicklungsumgebung „Eclipse-SDK“, in der Version 3.2.2, der Eclipse Founda- tion eingesetzt. Die schriftliche Ausarbeitung der Abschluss-Arbeit wird mit dem Textsatzsystem „Latex“ und der Latex-IDE „MikTex“ durchgeführt. Eine ausführ- liche Auflistung aller verwandten Software-Produkte kann im Anhang A auf der Seite 79 eingesehen werden.

2.2.3. Literatur

Auch im 21. Jahrhundert und der Möglichkeit durch Internet-Recherchen fast je- des Thema zu erschöpfen, halte ich es für erforderlich eine kompakte, ohne Com- puter oder Internet nutzbare Informationsquelle zu Rate ziehen zu können. Die meisten Daten im Internet sind schnelllebig und wenig gepflegt und können die Zuverlässigkeit eines Buches, im Bezug auf die Verfügbarkeit und Glaubwürdig- keit, nicht bieten. Für die Umsetzung der Diplomarbeit wird Literatur zu folgenden Themen benötigt:

- XML
- XML-Schema
- XSLT
- Eclipse
- Eclipse-RCP

Insgesamt entstehen ca. 200e an Kosten für die Beschaffung der benötigten Lite- ratur. Für zusätzliche Literaturanschaffungen werden weitere 100e veranschlagt. Nur die oben aufgeführten Themen müssen Bücher erworben werden, andere verwendete Literatur ist aus Gründen der eigenständigen Weiterbildung bereits vorhanden.

2.2.4. Bürob eda rf

An Bürobedarfsartikeln wird Papier für den Druck der Diplomarbeit benötigt. Hier- bei wird auf Laser-Drucker Papier der Stärke 120g/ m 2 zurückgegriffen. Zusätzlich hierzu entstehen weitere Kosten für das Binden und etwaige Prägen der Diplom- arbeit.

2.2.5. Zeitplan

Der hier dargestellte Zeitplan wurde mit der Projektplanungssoftware „GanttPro- ject“ angefertigt. Dieser gibt eine Übersicht über die einzelnen Projektphasen und ihre Abhängigkeiten zueinander. Die zu einem Abschnitt gehörigen Projektpha- sen wurden farblich markiert und der vermutliche Arbeitsaufwand pro Projektpha- se in Tagen angegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.: Der Zeitplan zeigt die einzelnen Projektphasen und ihr vermutlicher Arbeitsaufwand in Tagen

3. Fachliches Umfeld und Lös ungsans ätze

Dieses Kapitel gliedert sich in zwei Teile. Im ersten Teil werden zwei am Markt verfügbare Präsentationswerkzeuge vorgestellt und ihre Vor- und Nachteile ge- genüber der zu entwickelnden Software aufgezeigt. Vorweg ist anzumerken, dass beide vorgestellten Produkte die Anforderungen, die im Kapitel 2.1 gestellt wur- den, nicht erfüllen. Vollständigerweise wird dennoch auf die Funktionsweise die- ser Produkte eingegangen, um an diesen die Eigenentwicklung eines Präsentati- onswerkzeugs zu rechtfertigen. Im Anschluss hierzu, werden dann die Technolo- gien vorgestellt, welche sich für die generelle Umsetzung des Konzepts anbieten.

3.1. Pr äs entati ons s oft w a re

Zurzeit gibt es zwei bekannte Präsentationswerkzeuge die um den Titel der Stan- dardsoftware im Bereich „Präsentationen“ ringen. Zum Einem wäre dies „Power- point“ von Microsoft und zum Anderen „OpenOffice“, eine Open-Source Software von Sun Microsystems, wobei hier das Modul „Impress“ für das Erstellen einer Präsentation genutzt werden. Die hier vorgestellten Software-Produkte stellen na- türlich nicht die einzigen Anwendungen am Markt da, sind aber charakteristisch für die Funktionsweise dieser Werkzeuge. Der Programmablauf ist bei beiden Software-Produkten nahezu identisch. Die Arbeitsschritte, welche für die Erstel- lung einer Präsentation in „Powerpoint“ oder „OpenOffice“ unternommen werden müssen, sind in der Abbildung 3.1 auf der Seite 16 dargestellt.

Vorteilhaft bei beiden Anwendungen sind die vielfältigen Gestaltungsmöglich- keiten einer Präsentation, so können Video- und Audiodateien, 3D-Modelle oder Animationen zur Veranschaulichung komplexer Sachverhalte genutzt werden. Au- ßerdem verfügen beide Anwendungen über gute und intuitive Elemente für die Steuerung des Ablaufs einer Präsentation.

Die Abbildung 3.1 illustriert bereits einen erheblichen Mangel dieser Anwen- dungen. So ist es nicht möglich die Präsentationsfolien parallel zur eigentlichen Präsentation zu bearbeiten, obwohl beide Anwendungen die Trennung der Prä- sentationsansicht von der Bearbeitungsansicht, auf unterschiedliche Ausgabege-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1.: Arbeitsschritte in OpenOffice und Powerpoint

räte, anbieten. Dadurch ist es nicht möglich, auf die wechselnden Bedürfnisse eines Auditoriums einzugehen, ohne einen Bruch im Vortrag zu verursachen.

Ein weitere Unzulänglichkeit ist, dass keine Daten aus beliebigen XML-Doku- menten für die Generierung einer Präsentation herangezogen werden können. Einen Ansatz hierfür bietet zwar „OpenOffice“, denn mit diesem ist es möglich, einen XML-Filter zu definieren, anhand dessen XML-Daten in das „DocBook- Format“ konvertiert werden können. Jedoch ist „OpenOffice“ nur in der Lage, einen begrenzten Teil der „DocBook-Grammatik“ umzusetzen. Zusätzlich bietet diese Schnittstelle nicht die gewünschte Gestaltungsfreiheit, Flexibilität und Zu- verlässigkeit, welche für die Umsetzung der Software angestrebt wird. Dennoch zeigt es das Potenzial, welches innerhalb der „OpenOffice-Suite“ steckt. Weiter- führende Literatur zu diesem Thema findet sich unter [OOoa] oder [DocBook].

Ein zusätzlicher Mangel ist, dass sich die erstellten Präsentationsfolien nur schwerlich aus den jeweiligen Programmen extrahieren lassen, was die Weiter- verarbeitung dieser erschwert. Sollte eine Portierung der Präsentation möglich sein, so muss nachdem Extrahieren der Präsentationen häufig mit Qualitätsver- lust und/oder Formatierungsfehlern gerechnet werden, welches den Nutzen des Export auf Grund des Nachbehandlungsaufwands gegen null tendieren läßt.

3.2. Technikstudie

Nachfolgend werden die Technologien beschrieben, welche sich zum Umsetzen, der im Kapitel 2.1 auf der Seite 9 geschilderten, Problematik eignen. Hierfür wird das Kapitel in die Bereiche „Framework“ und „Konvertierung“ unterteilt. Da dem Autor umfassendere Erfahrungen in der Arbeit mit der Programmiersprache Java zur Verfügung stehen, beschränken sich die hier recherchierten Technologien auf Java-Implementierungen. Folglich wird ebenso eine Umsetzung des Konzepts in Java angestrebt, da der Aufwand eine neue Sprache zu lernen in keinem Verhält- nis zum Nutzen steht.

3.2.1. Framework

Um die zuvor im Kapitel 2.1 erwähnte Erweiterbarkeit und daraus resultieren- de Flexibilität zu gewährleisten bieten sich so genannte Rich-Client-Plattformen, kurz RCP, an. Durch die modulare Aufbauweise dieser Frameworks ermöglichen diese es, die Funktionalität des Hauptprogramm mittels zusätzlicher Module bzw. Plugins zu erweitern. Zusätzlich liefern diese Plattformen eine Vielzahl von unter- stützenden Komponenten die den Entwicklungsprozess deutlich verkürzen. Ein Beispiel für solche Komponenten sind vorgefertigte Benutzeroberflächen oder gar ganze Programme, die in die eigene Applikation integriert werden können. Für den Einstieg in dieses Thema, wird die Begutachtung des Eintrags [JAaron] im Literaturverzeichnis empfohlen.

3.2.1.1. Eclipse Rich-Client-Platform

Vermutlich jeder Java-Entwickler kennt inzwischen das „Eclipse Software Deve- lopment Kit“ (Eclipse-SDK), welches sich durch seine komfortable Benutzerober- fläche und schiere Erweiterbarkeit auszeichnet. So kann das Eclipse-SDK z.B. durch einen Subversion-Client oder ein UML-Werkzeug erweitert werden.

Jedoch ist in dem Zusammenhang mit der Eclipse-Plattform weniger bekannt, dass sich dessen Eigenschaften zum Entwickeln eigener Softwarelösungen nut- zen lassen. Seit Eclipse 3.0 ist es möglich eigenständige, von der IDE unabhän- gige, Programme auf der Basis der Eclipse-Rich-Client-Platform zu entwickeln.

Hierfür ist es nützlich sich den eigentlichen Aufbau der Eclipse-Plattform näher anzuschauen. Die Abbildung 3.2 zeigt vereinfacht, aus welchen Plugins sich die Eclipse-Plattform zusammen setzt. Hierbei sind die abgerundeten Rechtecke als eigenständige Plugins zu verstehen, welche auf der Eclipse-Plattform zum Ablauf gebracht werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2.: Vereinfachte Darstellung vom Aufbau der Eclipse-Piattform (Quel­ le: [Daum2006a]

Die eigentliche Plattform von Eclipse besteht aus einer relativ kleinen Kern­ Applikation, welche lediglich fOr die AusfOhrung von Plugins zustandig ist. Die gesamte Obrige Funktionalitat von Eclipse wird Ober eigenstandige Plugins inte­ griert. In den haufigsten Fallen bestehen solche Plugins aus einem JAR-Archiv und einem Plugin-Maifest. Das Manifest plugin . xml ist hierbei zwingend erfor­ derlich und beschreibt die Konfiguration und Integration des Plugins in die Platt­ form.

Ein Kernkonzept dieser Plugin-Architektur sind die ,Extension Points". Plug­ ins docken Ober diese Erweiterungspunkte an die Plattform an und stellen die­ ser so ihre Funktionen zur VerfOgung. Plugins selbest wiederum konnen eige­ ne Erweiterungspunkte definieren und somit ihre Funktionalitat teilen oder erwei­ tern. Aile definierten und genutzten Erweiterungspunkte des Plugins werden im Plugin-Manifest eingetragen und beim Starten der Software durch die Runtime der RCP ausgewertet. Die Extension-Points werden anhand eines Dialekts der Sprache ,XML Schema" vom W3C definiert. lm Wesentlichen handelt es sich hierbei urn eine Untermenge von XML Schema, die sich in der Verwendung von Namespaces und der Schreibweise einiger Elemente vom Standard des W3C unterscheidet.

Für die Realisierung einer Benutzeroberfläche stellt Eclipse mehrere Plugins bereit, unter anderem die in der Abbildung 3.2 abgebildeten des „Standard Widget Toolkit“(SWT) und JFace. Hierbei handelt es sich um zwei GUI-Bibliotheken die über das „Java Native Interface“(JNI) Funktionsaufrufe an das Native Windowing- System1 des jeweiligen Betriebssystems weiterleiten. Hierdurch können Anwen- dungen entstehen, die im Aussehen und der Reaktionsgeschwindigkeit dem der Betriebssystem eigenen Benutzeroberflächen entsprechen. Das SWT unterstützt auch das Verteilen einer grafischen Benutzeroberfläche auf mehrere Ausgabege- räte, im folgenden nur noch Multidisplay-Mode genannt.

Hierdurch eignet sich Eclipse als Ablaufplattform für Programme, die selber ein hohes Maß an Flexibilität erfordern und nicht zwingend in den Bereich der Softwa- reentwicklung fallen. Zusätzlich hierzu lassen sich Applikationen, welche auf der Basis von Eclipse-RCP entwickelt wurden, dem Firmen eigenen Marken-Design anpassen oder mit einer Aktualisierungsfunktion ausstatten, welche Programm- Aktualisierungen über die eigene Webseite laden und installieren kann. Aufgrund ihres Funktionsumfanges und beinahe grenzenlosen Erweiterbarkeit stellt Eclipse eine professionelle Plattform für die Umsetzung von Software-Produkten dar.

Für die Umsetzung der Abschluss-Arbeit ergeben sich hieraus interessante Konsequenzen: Aufgrund der nutzbaren Modularen Architektur der Eclipse-RCP eignet sich diese für die Umsetzung der geplanten Modularität der Software. So könnte das Hinzufügen neuer Funktionalitäten zur Software als Plugin erfolgen. Hierfür müsste die Applikation entsprechende Extension-Points bereitstellen. Des weiteren bietet das Framework mit der GUI-Bibliothek SWT eine Möglichkeit für das Umsetzen des geforderten Multidisplay-Mode.

3.2.1.2. Netbeans Platform

Im Juni 2000 wurde die „Netbeans Entwicklungsumgebung“ in der Version 3.0 von Sun Microsystems(SUN) als Open Source deklariert und der Entwicklerge- meinde, als erstes von SUN gesponsertes Projekt übergeben. Mittlerweile liegt die „Netbeans-IDE“ in der Version 5.5 vor und eine Veröffentlichung der Version 6.0 wird für November 2007 erwartet.

Ähnlich wie bei dem Eclipse-SDK erlaubt auch die Netbeans-IDE, dass Soft- wareentwickler Netbeans, genauer die Netbeans-Platform, als Basisbaustein für die Entwicklung eigener Anwendungen nutzen können. Beide Plattformen verfol- gen als Schlüsselprinzip einen modularen Aufbau. Hierbei ist die Kern-Applikation von Netbeans eine generische Desktop-Applikation, welche als Ablaufumgebung für Anwendungen, im weiteren Module genannt, dient. Hierbei sind Module das äquivalent zu den Plugins in Eclipse. Die „Netbeans-Platform“ stellt Komponenten und Dienste, wie z.B. Datei-Speicherung, einen Window-Manager, das Speichern von Einstellungen usw. zur Verfügung. Alle weiteren Funktionalitäten können über separate Module zu der Kern-Applikation hinzugefügt werden.

Hierbei ist ein Modul ein JAR-Archiv, dass alle Java Klassen enthält, die mit den „NetBeans Open API’s“ interagieren sollen. Alle JAR-Archive müssen eine Manifest-Datei enthalten, die beschreibt, wie das Modul in die Netbeans-Platform zu integrieren ist.

Für die Integration von eigenen Benutzeroberflächen bzw. eigenen Modulen bietet die „NetBeans-Platform“ eine Reihe von API’s an. Als Standard-Bibliothek für die Entwicklung von GUI’s kommt die Standard Benutzeroberflächen Biblio- thek „Swing“ zum Einsatz. Hierfür liefert NetBeans auch gleich einen eigenen sehr guten GUI-Builder (namentlich „Matisse“) mit, der es erlaubt, schnell und unkompliziert komplexe grafische Benutzeroberflächen zu erstellen.

Insgesamt verfolgt die NetBeans-Platform den Ansatz dem Benutzer so viel wie möglich Konfigurationsarbeiten an den zahlreichen Manifest-Dateien durch Ein- gabehilfen, wie Assistenten oder Dialoge, abzunehmen. Es entsteht schnell der Eindruck eines virtuellen Baukastens, wo je nach belieben die Elemente ausge- wählt und zusammengesteckt werden können. Solange wie es keine ernsthaften Problemstellungen zu lösen gilt, mag dieses Baukastenprinzip vorteilhaft für den Anwender sein, da sich so schnell Ergebnisse produzieren lassen. Problema- tisch wird es, wenn manuell in die erstellten Manifest-Dateien eingegriffen werden muss, denn hierfür bietet Sun Microsystems bisher sehr wenige, nicht triviale, Do- kumentationen. Ernsthafte Literatur zur Netbeans-Platform ist zurzeit nur in einer kleineren Auswahl vorhanden.

Daher fällt es schwer, die NetBeans-Platform für die Umsetzung des Konzepts einzusetzen. Jedoch wäre bei entsprechender Erfahrung mit dieser Plattform eine generelle Implementierung der Software möglich.

3.2.1.3. Spring Rich Client Platform

Im April 2006 wurde die erste öffentliche Version des „Spring-RCP Frameworks“ (Version 0.1.0) freigegeben und seit September 2006 steht nun die Version 0.2.1 den Entwicklern zur Verfügung. Bisher gibt es nur wenige aussagekräftige In- formationen über dieses Framework. Als Informationsquelle hat sich hierbei die Projektseite des Spring-RCP-Teams angeboten, wo auch anhand eines Beispiels die Funktionsweise dieses Frameworks demonstriert wird. Weitere Informationen zu der Spring-RCP ist im Literaturverzeichnis unter [Spring] zu finden.

Vollständigerweise wurde das Spring-RCP hier aufgeführt, aber auf Grund des frühen Entwicklungsstatus, fehlenden Dokumentationen und Referenzen wird die- ses Framework für die Lösung der Diplomarbeit keine weitere Relevanz zugeord- net.

3.2.2. Konvertierung

Da die Daten, die innerhalb eines XML-Dokuments abgelegt werden, typischer- weise keine Formatierungsanweisungen enthalten, müssen diese Daten für die Anzeige aufbereitet werden. Daher werden nachfolgend zwei Technologien vor- gestellt, mit denen XML-Daten konvertiert werden können.

3.2.2.1. Apache Velocity

Velocity ist eine auf Java basierende „Template-Engine“, die Daten aus Java- Objekten, mittels eines definierten Templates, in beinahe jedes beliebige Format konvertieren kann. Hierbei wird die Velocity Template-Engine unter der Apache- Software-Foundation entwickelt und in der Version 1.5 der Entwicklergemeinde angeboten (der Link zur Velocity-Webseite findet sich im Literaturverzeichnis un- ter [VeloCity]).

Die Abbildung 3.3 auf der Seite 22 zeigt hierbei die generelle Funktionswei- se der Template-Engine. Für die Generierung einer Ausgabe wird der Template- Engine ein Template (in diesem Fall template.vc) übergeben, welches die ge- wünschte Formatierung beinhaltet. Bei dem Konvertierungsprozess werden dann die Daten, des Datenmodells, auf das Template abgebildet und das Ergebniss als Ausgabe präsentiert.

Für das Erstellen eines Templates benutzt Velocity eine eigene Syntax, die Velocity Template Language oder kurz VTL, welche eine Eigenentwicklung des

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3.: Vereinfachte Darstellung der Funktionsweise der Velocity Engine

Apache-Projekts darstellt. Ein Beispiel fOr diese Syntax zeigt das ,Hello World"­ Listing 3.1.

Abbildung in dieser Leseprobe nicht enthalten

lm Listing 3.1 wird die Variable $f oo mit dem Wert , Velocity" vordefiniert, eben­ falls moglich ware eine dynamische Zuweisung des Wertes aus einer Anwendung heraus. HierfOr wird das Template anhand der Template-Engine ausgewertet und mit den Daten eines Java-Objekts versehen. Ein vereinfachtes Beispiel hierfOr zeigt Listing 3.2. FOr die bessere Verstandlichkeit der Funktionsweise wurde auf die Ausnahmebehandlung und Klassendefinition verzichtet.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.2: Zeigt das Zusammenführen der Objekt-Daten mit dem Template

Das Listing 3.2 zeigt wie innerhalb eines Java-Programms der Platzhalter $foo, aus dem Template „template.vc“, durch den konkreten Wert „Velocity“ ersetzt wer- den kann. Durch den Funktionsaufruf template.merge(context, sw); werden die im VelocityContext abgelegten „Key/Value-Pairs“ auf das Template ange- wandt. Die Ausgabe wird hierbei in einen StringWriter-Stream geschrieben.

Die Template-Engine Velocity, könnte bei der Umsetzung des Konzepts für die Formatierung der XML-Daten eingesetzt werden. Jedoch wäre es hierfür nötig, zu erst die XML-Daten anhand eines XML-Parser einzulesen und anschließend programmatisch auf das Template abzubilden. Ein Problem ist hierbei das flexible Handhaben von wechselnden Datenmodellen, denn eine programmatische Abbil- dung der Daten auf ein Template schränkt die Struktur des Datenmodells auf das im Programm festgelegte Format für die Abbildung ein. Dies ist jedoch nicht ge- wünscht. Weiterführende Informationen zur Velocity Template-Engine können im Literaturverzeichnis unter [VeloCity] gefunden werden.

3.2.2.2. XML und XSLT

Wie bereits von Michael Kay in der Einleitung seines Buches so treffend formuliert wurde:

„XML today needs no introduction: as soon as it hit the streets in 1998 it ime- diately gained universal acceptance ...“ 2.

Bereits 1999 wurde vom W3C mit der „Extensible Stylesheet Language: Trans- formation (XSLT)“ eine Sprache für die Manipulation von XML-Daten bereitge- stellt. Anhand von XSLT können XML-Dokumente in die unterschiedlichsten For- mate transformiert werden. So wäre eine Transformation in das PDF- oder RTF- Format denkbar, oder aber eine Transformierung in ein weiteres, für die Verarbei- tung durch ein Programm bestimmtes, XML-Dokument. Diese Vielfältigkeit kann für die Umsetzung der Software eingesetzt werden. Hierbei könnte der XSLT- Prozessor als Engine für die Transformierung der XML-Daten in die Anwendung integriert werden. Aufgrund der hohen Funktionsvielfalt von XSLT, würde dem Anwender der Software so eine mächtige Sprache für die Erstellung von Präsen- tationen zur Verfügung stehen.

Aufgrund der Möglichkeit der Parametrisierung und Modularisierung eines Sty- lesheets, kann Kontinuität, welche durch ein Programm beeinflußbar ist, geschaf- fen werden. So ist es möglich, durch im Stylesheet deklarierte Parameter, die For- matierung der XML-Daten zu beeinflussen. Um die Parameter wieder verwendbar und konstant zu deklarieren, sollten diese in ein eigenständiges XSLT-Dokument ausgelagert werden. Ein Besipiel hierfür zeigen die Listings 3.3 und 3.4.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.3: XSLT-Dokument, das die Parameter für die Formatierung enthält: format.xsl

Das im Listing 3.3 abgebildete XSLT-Dokument deklariert einen Parameter, der den Hexadezimalwert einer Farbe enthält. Das Listing 3.4 zeigt die Benutzung des Parameters als Attribute-Wert des <body>-Elements. Hierfür werden in der Zeile sieben bis neun die Instruktionen <xsl:attribute> und <xsl:value-of> verwandt.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.4: Das Listing stellt ein mögliches Stylesheet dar, wie es von einem Be- nutzer für die Präsentation erstellt wurde: benutzer.xsl

Zur Transformationszeit kopiert der XSLT-Prozessor das in <xsl:import> an- gegebe Modul in den aktuellen Stylesheet (benutzer.xsl). Hierdurch stehen die im format.xsl deklarierten Parameter im XSLT-Dokument benutzer.xsl zur Ver- fügung und es kann mittels einer XPath-Expression auf diese zugegriffen werden (siehe Zeile acht im Listing 3.4). Änderungen, die nun den Parameter „bgColor“ betreffen können zentral vorgenommen werden. Hier kann für die Umsetzung der Software angesetzt werden. Das Umsetzen der dynamischen Präsentation durch die Parametrisierung eines XSLT-Dokuments stellt eine ressourcenscho- nende Alternative zu den direkten und speicherintensiven Operationen auf den Ergebnisbaum der Transformation dar. Dies könnte die Nutzbarkeit der Software auch bei größeren XML-Dokumenten sichern.

Ein weitere, für die Implementierung positive Eigenschaft von XSLT ist, dass die XSLT Spezifikation von einem zentralen Konsortium (W3C) bereitgestellt wird und somit unabhängig gegenüber den Bedürfnissen eines Unternehmens gestaltet wird.

3.2.3. XML-Vearbeitung in Java

Mit der Java Standard Edition 6.0 liefert Sun Microsystems die „Java API for XML Processing“, oder kurz JAXP, in der Version 1.4 aus. Diese ermöglicht es XML- Dokumente zu parsen, transformieren oder zu validieren, unabhängig von einem bestimmten Parser bzw. Prozessor. Es gibt einige Referenzimplementierungen der JAXP, darunter die Standardimplementierung der Apache Group.

Die Implementierung der Apache Group integriert als Parser „Xerces“ und als XSLT-Prozessor „Xalan“. Hierbei entspricht der XSLT-Prozessor „Xalan“ dem XSLT 1.0 Standard. Ein Nachteil von JAXP ist, dass diese API generell keine Unter- stützung für den XSLT 2.0 Standard anbietet. Ein nettes Statement hierzu, hatte Michael Kay im Saxon-Diary veröffentlicht.

„Anyway JAXP, over the years, has become rather a mess. It still doesn’t support XPath 2.0 and XSLT 2.0, ... I felt I could do a better job by starting from scratch.“ 3.

Die XSLT-Implementierung „Saxon“ von Michael Kay unterstützt hier bereits die Neuerungen des XSLT 2.0 Standards und kann ebenfalls anhand der Schnittstel- len der JAXP referenziert werden. Hierdurch ist ein späteres Austauschen des XSLT-Prozessors weiterhin möglich.

Um die neuen Funktionalitäten und die daraus resultierende Vereinfachung in der Erstellung eines XSLT-Dokument dem Benutzer zugänglich zu machen, ist für das Umsetzen der Software die Implementierung von Michael Kay zu nutzen.

3.3. Lösungsansätze

Aufgrund der auf Seite 15 dokumentierten Einschränkungen vorhandener Prä- sentationswerkzeuge, wie z.B. der Mangelhaften Portierbarkeit der erstellten Prä- sentationsvorlagen, ist eine Eigenentwicklung, welche den Anforderungen aus dem Kapitel 2.1 auf der Seite 9 entspricht, gerechtfertigt. Wie bereits in der „Tech- nikstudie“ gezeigt, existieren Technologien, die einzelne Problemstellungen, wie die Erweiterbarkeit oder die Verteilung der Anzeige, abdecken können. Jedoch erst die Kombination mehrerer Technologien ermöglicht das vollständige Um- setzen der Anforderungen. Hieraus lassen sich die im folgenden erläuterten Lö- sungsansätze „ 3.3.1 Java und XSLT “ und „ 3.3.2 Eclipse-Rich-Client-Platform und XSLT “ ableiten. Die Lösungansätze stützen sich hierbei, auf die im Kapitel 3.2.2.2 XML und XSLT erörterte Parametrisierung des XSLT-Dokuments.

3.3.1. Java und XSLT

Bei diesem Lösungsansatz wird eine Implementierung der Software anhand des JDK’s von Sun Microsystems und dem Saxon XSLT-Prozessor angestrebt.

Die Implementierung, der im Kapitel 2.1 beschriebenen Modularität, erfolgt hierbei über das Umsetzen des Dependency-Injection-Patterns, dabei werden die Fassaden-Klassen der Anzeige-Module in die config.xml der Anwendung ein- getragen. Diese ließt die Konfigurationsdatei beim Systemstart aus und leitet die Moduleinträge an den ClassLoader weiter. Der ClassLoader instanziiert die Fassaden-Klassen und legt die Objekte für die weitere Verwendung im System ab (siehe Abbildung 3.4).

Die Verarbeitung der XML-Dokumente erfolgt über einen integrierten Parser und XSLT-Prozessor. Hierbei wird das Ergebnis des Einlesens als DOM-Baum an den Saxon XSLT-Prozessor weitergeleitet.

Für die Interaktion mit dem Benutzer, wird mittels der Bibliothek SWING, eine Benutzeroberfläche in die Software integriert. Über diese können die Parameter

Java-Anwendung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4.: Zeigt als Losungsansatz die Umsetzung als Java-Programm

tor die Formatierung der Prasentation eingetragen werden. Die Ein-/ Ausgabe­ verarbeitung leitet diese Eingaben an den XSLT-Prozessor weiter und startet an­ schlie8end die Transformation. Das Ergebnis der Transformation wird dann, Ober ein vom Benutzer ausgewahltes Anzeige-Modul dargestellt.

Die Verteilung der grafischen Benutzeroberflache konnte hierbei Ober die , Full­ Screen Exclusive Mode API"4 integriert werden. Hiertor mOssten die Anzeige­ Module diese API, dem Beispiel entsprechend, implementieren (das Beispiel kann unter [FuiiScreen] im Literaturverzeichnis nachgeschlagen werden). Die Benut­ zung dieser API, setzt eine, konfigurierte Multidisplay-Umgebung voraus (siehe Anhang B).

3.3.2. Eclipse-Rich-Client-Platform und XSLT

Der folgend beschriebene Losungsansatz stellt die Umsetzung, der im Kapitel2.1 auf der Seite 9 beschriebenen Aufgabe, anhand der Eclipse-Rich-Client-Platform und dem Saxon XSLT-Prozessor dar.

Die gewOnschte Modularitat der Software, wird hierbei mit Hilfe der Plugin­ Architektur von Eclipse umgesetzt. Um die Wartbarkeit und Erweiterbarkeit der Software zu verbessern, sollte die Hauptanwendung (Core-Piugin in der Abbil­ dung 3.5) mehrere Erweiterungspunkte definieren, die von den Plugins, tor das Hinzutogen von Funktionalitaten, genutztwerden konnen (die Abbildung 3.5 zeigt

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5.: Möglicher Lösungsansatz für die modulare Struktur

hierfür ein Beispiel). Für die Eingabe der Formatierungsparameter wird dem An- wender eine auf dem SWT und JFace basierende, grafische Oberfläche angebo- ten. Die Verteilung der grafischen Benutzeroberfläche kann durch die Anzeige- Plugins implementiert werden. Zu diesem Zweck stellt das Standard Widget Tool- kit von Eclipse die Methode getMonitors() und die Klassen Display und Monitor zur Verfügung. Jedoch ist hierfür, wie schon im Kapitel 3.3.1 beschrieben, eine konfigurierte Multidisplay-Umgebung notwendig (siehe Anhang B).

Um die Software zu neuen XML-Standards kompatibel zu gestalten, werden die Programmteile, die für die Verarbeitung der XML-Dokumente zuständig sind, in dem Transformer-Plugin gekapselt (in der Abbildung 3.5 dargestellt). Das Ein- lesen der XML-Dokumente erfolgt hierbei über einen integrierten Parser, der den XML-Baum als DOM in den Speicher der Anwendung lädt. Nachdem Einge- ben der Formatierungsparameter und starten der Präsentation wird dieser DOM- Baum zusammen mit den Parametern an den XSLT-Prozessor übergeben und das Ergebnis der Transformation durch ein Anzeige-Plugin wiedergeben.

Um die Möglichkeit der weiteren Verarbeitung des Transformationsergebnisse zu erhalten, wurde hier auf das DOM zurückgegriffen. So kann der im Speicher liegende Ergebnisbaum von etwaigen Anzeige-Plugins, durch das erneute Trans- formieren oder Manipulieren angepaßt werden.

3.3.3. Ausschlusskriterien

Nicht alle in der Technikstudie erläuterten Technologien fanden für die Konzepti- on der Lösungsansätze Beachtung. Nachfolgend wird genauer darauf eingegan-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.6.: Losungsansatz fOr die Umsetzung des Transformer-Piugins

gen, warum bestimmte Technologien fOr die Ausarbeitung eines Losungsansat­ zes nicht herangezogen wurden.

[...]


1 Hier werden die GUI-Widgets des Betriebssystems genutzt und erst dann eigene Widgets vom SWT emuliert, wenn das Betriebssystem keine Widgets für die Anzeige anbietet.

2 [Kay2004], Seite xxvii, erster Satz

3 [SaxonDiary], dritter Abschnitt

4 wird zusammen mit dem JDK, seit der Version 1.4, ausgeliefert und stellt eine API, fOr das Konfigurieren installierter Anzeigegerate und direktes Schreiben von Bildinformationen in den Video-RAM, zur VerfOgung

Details

Seiten
94
Jahr
2007
ISBN (eBook)
9783668906457
ISBN (Buch)
9783668906464
Sprache
Deutsch
Katalognummer
v462425
Institution / Hochschule
Beuth Hochschule für Technik Berlin – Fachbereich 6
Note
1,3
Schlagworte
Eclipse-RCP Java Software Entwicklung XML XSLT

Autor

Teilen

Zurück

Titel: Dynamische Präsentation von XML-Daten