Kompendium Medieninformatik: Medienpraxis GERMAN

Roland Schmitz (Hrsg.) Kompendium Medieninformatik Medienpraxis Mit Beiträgen von: Michael Burmester, Bernhard Eberhar...

Author: Roland Schmitz (Editor)

194 downloads 1071 Views 8MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Roland Schmitz (Hrsg.)

Kompendium Medieninformatik Medienpraxis Mit Beiträgen von: Michael Burmester, Bernhard Eberhardt, Ansgar Gerlicher, Martin Goik, Jens-Uwe Hahn, Marko Hedler, Oliver Kretzschmar und Jörg Westbomke

Mit 123 Abbildungen

123

Roland Schmitz Hochschule der Medien Nobelstr. 10 70569 Stuttgart [email protected] www.medieninformatik.hdm-stuttgart.de

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. ISSN 1439-3107 ISBN-13 978-3-540-36629-4 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz und Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3180 YL – 5 4 3 2 1 0

Einleitung

„The medium is the message“ – treffender und kürzer, als es Herbert Marshall McLuhan in den 60er Jahren des letzten Jahrhunderts auf den Punkt gebracht hat, kann man die wechselseitige Beziehung zwischen dem Inhalt einer Kommunikation und ihrer Präsentationsform auch heute nicht beschreiben. Versucht man davon ausgehend, den zugrunde liegenden Sachverhalt etwas präziser zu fassen, so stellt man fest: Die Techniken zur Erzeugung, zum Transport, zur Speicherung und zur Darstellung einer Botschaft sind ebenso entscheidend für ihre Wahrnehmung wie ihr eigentlicher Inhalt. Damit wird klar, was der viel benutzte (und strapazierte) Begriff der „Medien“ eigentlich bedeutet: Medien sind dem Wortsinn nach „Vermittler“. Sie dienen der Speicherung, Darstellung und Übermittlung von Informationen. Im heutigen Sprachgebrauch meint man mit Medien aber häufig auch die Informationen selbst und unterscheidet nicht deutlich zwischen der Information und ihrem Träger. Die übertragenen Informationen können in unterschiedlich strukturierter Form und Codierung vorliegen. Eine Strukturierung in Medien kann auf unterschiedliche Arten herbeigeführt werden, etwa mittels ergänzender Informationen, so genannter Metadaten, oder durch Eingliederung in eine Ordnungsstruktur, etwa eine hierarchische Gruppierung. Die Medieninformatik beschäftigt sich speziell mit digitalen Medien, das sind zum einen digital (also in Form von Bits) codierte Arten von Informationen, zum anderen die Träger dieser Informationen. Die Art der Codierung, das heißt die Vorschrift, wie die ursprünglichen Informationen in Bitform darzustellen sind (und wie umgekehrt die Bits als Information zu interpretieren sind), bestimmt über den Medientyp, wie zum Beispiel Text, Dokument, Bild, Audio oder Video. Die Digitalisierung stellt dabei einen entscheidenden Schritt dar: Durch sie wird es möglich, die Informationen von ihrem physikalischen Träger zu trennen. Diese Trennung trägt maßgeblich zur immer weiter wachsenden Mobilität unserer Kommunikation und unseres

Einleitung

Medien

Medieninformatik

■ ■ ■

V

Das Buch

VI

■ ■ ■

Arbeitslebens insgesamt bei. Die Informatik stellt hierfür die theoretischen Grundlagen und Methoden der Informationsverarbeitung auf Rechnersystemen zur Verfügung. Die Medieninformatik zeigt, wie diese Methoden speziell auf digitale Medien anzuwenden sind. Damit prägt die Medieninformatik unseren Alltag, weil sie letztlich darüber mitentscheidet, was und wie viel aus der täglichen Informationsflut in unseren Köpfen ankommt. Die Beherrschung ihrer Konzepte und Techniken ist für unser aller Zukunft maßgebend. Aus diesem Grund versteht sich die Medieninformatik auch nicht nur als rein technische Disziplin, sondern umfasst auch gestalterische, psychologische und ökonomische Aspekte. Diese Vielfalt spiegelt sich auch in den unterschiedlichen Inhalten der vielen verschiedenen, an deutschen Hochschulen angebotenen Studiengängen mit dem Namen „Medieninformatik“ wider. Das „Kompendium der Medieninformatik“ befasst sich vor allem mit den technischen Aspekten der Medieninformatik und bildet damit den Schwerpunkt der Lehrinhalte im Studienbereich Medieninformatik an der Hochschule der Medien in Stuttgart ab. Trotz dieses Schwerpunkts auf den Informatik-Aspekten der Medieninformatik unterscheidet sich das Kompendium der Medieninformatik inhaltlich deutlich von klassischen Lehrbüchern der Informatik. Die Grundlagen der Informatik werden nur insoweit behandelt, als sich durch die Anwendung auf Mediendaten neue und spezifische Gesichtspunkte ergeben. In allen anderen Fällen gehen wir davon aus, dass der Leser mit den Grundlagen der Informatik bereits vertraut ist. Zielgruppen dieses Buches sind somit Studenten der Informatik und Medieninformatik im Hauptstudium sowie Praktiker, die bereits Erfahrung mit den Anwendungen der Informatik in der Industrie gesammelt haben und sich nun speziell über Anwendungen in den Medien informieren wollen. Der vorliegende zweite Teil des Kompendiums Medieninformatik mit dem Titel „Medienpraxis“ behandelt ein weites Themenspektrum aus der praktischen Informatik und ihren Anwendungen bei der Erzeugung und Verarbeitung digitaler Medien. Wie schon beim ersten Teil „Mediennetze“, der sich mit dem Transport und der Verpackung von Multimedia-Daten beschäftigt, orientiert sich auch im zweiten Teil die Stoffauswahl an den an der Hochschule der Medien in Stuttgart vertretenen Lehrgebieten: Wir beginnen bei der Erzeugung von Content mit einer Einführung in die Computergrafik, danach folgt das wichtige Feld der Strukturierung von Informationen mit Hilfe von Markup-Languages. Mit den Kapiteln Computer-Supported Cooperative Work (CSCW) und Content-Related-Technologien betreten wir das weite Feld der Anwendungen von Informatik-Methoden in der Medienverarbeitung,

Einleitung

bevor das Kapitel „Usability und Design“ an der Schnittstelle zum Endanwender den zweiten Teil abschließt. Die Autoren des Kompendiums sind allesamt ausgewiesene Experten ihres Fachs und stehen (oder standen) in aktiver Lehrtätigkeit an der Hochschule der Medien Stuttgart. Die Inhalte dieses Buches basieren auf Lehrveranstaltungen, die von den Autoren im Rahmen der Studiengänge Medieninformatik (Bachelor/Master) und Information Systems (Bachelor/Master) gehalten werden. Wir danken unseren Studenten für zahlreiche wertvolle Kommentare und Verbesserungsvorschläge zu diesen Lehrveranstaltungen. Ohne diese Anregungen wäre dieses Buch nicht realisierbar gewesen.

Einleitung

■ ■ ■

VII

Inhaltsverzeichnis

1

2

Computergrafik und Virtual Reality ......................................... 1.1 Modellierung virtueller Welten........................................ 1.1.1 Objektmodellierung, -repräsentation und ihre Datenstrukturen ..................................... 1.1.2 Kurven ..................................................................... 1.1.3 De-Boor-Algorithmus für B-Splines.................... 1.1.4 Flächen..................................................................... 1.1.5 Anschlüsse von Bézier-Tensorproduktflächen .. 1.2 Bildberechnung – vom Modell zum Bild ........................ 1.2.1 Die Beleuchtungsgleichung................................... 1.2.2 Farben in der Computergrafik ............................. 1.2.3 Lokale Beleuchtungsmodelle und Shading......... 1.2.4 Verdeckungsrechnung .......................................... 1.2.5 Mapping-Techniken .............................................. 1.2.6 Globale Beleuchtung .............................................. 1.2.7 3D-Grafik-Programmierung und GPU-unterstütztes Rendering ...................... 1.3 Virtual Reality (VR) – Holodecks?................................... 1.3.1 Stereoskopie............................................................ 1.3.2 Ein- und Ausgabegeräte ........................................ 1.3.3 Ausblick ................................................................... Literatur ........................................................................................

1 1

81 84 85 91 94 96

Einsatz von Markup-Languages ................................................. 2.1 Einleitung ............................................................................ 2.2 Voraussetzungen................................................................ 2.3 Publishing ........................................................................... 2.3.1 Dokumente und ihre Struktur.............................. 2.3.2 Modellierung........................................................... 2.3.3 Datenherkunft ........................................................ 2.3.4 Verarbeitung........................................................... 2.3.5 Druckbare Ausgabe................................................

99 99 100 101 102 105 106 108 113

2 9 32 38 43 49 50 52 52 59 61 68

Inhaltsverzeichnis

■ ■ ■

IX

2.4 XML-gestützte Anwendungsentwicklung ....................... 2.4.1 Austauschformate................................................... 2.4.2 Serialisierung von Objekten .................................. 2.5 Trennung der Implementierungslogik und Präsentation einer Anwendung ........................................ 2.5.1 Servlets und XSL ..................................................... 2.5.2 Eine Beispielapplikation ........................................ 2.5.3 Die Implementierung der Anwendungslogik ..... 2.5.4 Serialisierung des Servlets als DOM-Baum ......... 2.5.5 XSL-Stylesheets für die Zielformate HTML und PDF ................................................................... 2.5.6 Servlets und Filter ................................................... 2.5.7 Die Java-Implementierung des Filters ................. 2.5.8 PDF-Ausgabe........................................................... 2.5.9 Weitere Möglichkeiten........................................... Literatur......................................................................................... 3

X

■ ■ ■

Computer-Supported Cooperative Work (CSCW) – kollaborative Systeme und Anwendungen............................... 3.1 Begriffsdefinition CSCW ................................................... 3.2 CSCW in der Medieninformatik....................................... 3.3 Groupware- und Workgroup-Computing-Systeme ...... 3.3.1 Zielsetzung der Groupware-Systeme ................... 3.3.2 Werkzeuge und Anwendungen ............................ 3.4 Versionsverwaltungssysteme............................................ 3.4.1 Zielsetzung der Versionsverwaltungssysteme .... 3.4.2 Anforderungen an Versionsverwaltungssysteme ................................ 3.4.3 Architektur von Versionsverwaltungssystemen.............................. 3.5 Kollaborative Mehrbenutzer-Editoren ............................ 3.5.1 Zielsetzung der Mehrbenutzer-Editoren ............. 3.5.2 Probleme des „Echtzeit“-Editierens..................... 3.5.3 Mehrbenutzer-Editoren in der Praxis.................. 3.6 Nebenläufigkeitskontrolle in CSCW Systemen .............. 3.6.1 Nebenläufigkeitskontrolle ohne CSCW-System................................................ 3.6.2 Sperrverfahren ........................................................ 3.6.3 Zeitstempelverfahren ............................................. 3.6.4 Operational Transformation ................................. 3.7 Architektur kollaborativer Systeme ................................. 3.7.1 Zentralisierte Architektur...................................... 3.7.2 Replizierte Architektur........................................... 3.7.3 Hybrid-Architektur ................................................

Inhaltsverzeichnis

116 117 122 126 126 127 129 130 133 135 137 138 140 140

143 145 147 148 148 149 159 159 161 162 162 162 164 168 170 171 171 177 178 181 181 183 184

4

3.8 Awareness in kollaborativen Systemen .......................... 3.8.1 Workspace Awareness........................................... 3.8.2 Usability und Privatsphäre ................................... 3.9 Fazit und Ausblick ............................................................. Literatur ........................................................................................

186 186 188 189 191

Content-Related-Technologien................................................... 4.1 Grundlegende Begriffe ...................................................... 4.1.1 Informationen, Daten, Medien, Content, Asset und Wissen.............................................................. 4.1.2 Formatierung und Strukturierung von Content............................................................. 4.1.3 Dokumente früher und heute............................... 4.1.4 Geschäftsprozesse und Workflow........................ 4.2 Nutzenbetrachtungen........................................................ 4.2.1 Primäre Vorteile ..................................................... 4.2.2 Mehrfachverwertung von Content als Strategie ............................................................. 4.2.3 Wirtschaftliche Überlegungen.............................. 4.3 Überblick über CRT-Systeme........................................... 4.4 Technische Bausteine ........................................................ 4.4.1 Schematische Systemarchitektur ......................... 4.4.2 Erfassung, Beschaffung und Validierung von Content............................................................. 4.4.3 Ablage von Content................................................ 4.4.4 Strukturierung von Content ................................. 4.4.5 Retrieval und Anzeige von Content..................... 4.4.6 Beziehungsmodelle für Content........................... 4.4.7 Steuerung und Kontrolle von Content-Workflows ............................................... 4.4.8 Content-Aggregation, -Delivery und -Publishing ...................................................... 4.4.9 Personalisierung von Content .............................. 4.4.10 Archivierung und Revisionssicherheit................ 4.4.11 Integration für Nutzer, Content, Funktion und Prozesse ........................................................... 4.4.12 Administration ....................................................... 4.5 Ausblick............................................................................... Literatur ........................................................................................

197 197 197 199 201 203 204 204 205 208 209 211 211 213 217 219 220 222 224 226 232 234 236 240 241 242

Inhaltsverzeichnis

■ ■ ■

XI

5

Usability und Design..................................................................... 5.1 Usability ............................................................................... 5.1.1 Mensch und Computer .......................................... 5.1.2 Usability als Qualität der Nutzung ....................... 5.1.3 Nutzen von Usability.............................................. 5.2 Theoretische Grundlagen .................................................. 5.2.1 Überblick.................................................................. 5.2.2 Ein Modell zur Nutzung interaktiver Systeme.... 5.2.3 Information Foraging – die Suche nach Informationen................................................ 5.2.4 Persuasive Aspekte ................................................. 5.2.5 Attraktivität ............................................................. 5.3 Design................................................................................... 5.3.1 User Centred Design............................................... 5.3.2 Nutzungskontextanalyse........................................ 5.3.3 Entwurf und Gestaltung......................................... 5.3.4 Prototyping.............................................................. 5.3.5 Evaluation – Prüfung und Inspiration................. 5.3.6 Dokumentation ....................................................... 5.4 Integration von Usability-Engineering und Software-Engineering................................................. 5.5 Abschlussüberlegungen..................................................... Literatur.........................................................................................

245 245 245 246 249 253 253 255 260 262 264 268 268 271 276 281 283 287 288 291 292

Autorenverzeichnis................................................................................. 303 Index .......................................................................................................... 307

XII

■ ■ ■

Inhaltsverzeichnis

1 Computergrafik und Virtual Reality Bernhard Eberhardt, Jens-Uwe Hahn

Virtuelle Welten und künstlich erzeugte Bilder haben mit steigender Rechenleistung und mit der Ausreifung der eingesetzten Verfahren und Techniken zunehmenden Einfluss auf unser tägliches Leben. Die Einsatzgebiete sind dabei vielseitig und reichen von Werbeund Kinofilmen über Computerspiele bis hin zu Virtual-Reality(VR-) Anwendungen, die es erlauben, virtuelle Prototypen von Gebäuden, Flugzeugen, Fahrzeugen und vielen anderen Produkten in Echtzeit zu betrachten, zu bewerten und weiterzuentwickeln. Dieses Kapitel bietet eine Einführung und einen Überblick über die Verfahren, die dabei zum Einsatz kommen. Das erste Unterkapitel befasst sich mit der Modellierung virtueller Welten und den dafür eingesetzten Datenstrukturen. Das zweite Unterkapitel behandelt die Erzeugung von Bildern solcher virtuellen Welten. Das dritte Unterkapitel gibt einen Überblick über die Techniken, die in interaktiven VRUmgebungen zum Einsatz kommen.

1.1 Modellierung virtueller Welten Obwohl Kameramann und Fotograf häufig Bilder realer Gegenstände zeigen, die wir aus unserer Umgebung kennen, überraschen uns die Künstler dieser Fächer immer wieder mit neuen Ein- und Aussichten in ihren Einstellungen. Aber stellen Sie sich einen Fotografen vor, der etwas fotografiert, das gar nicht da ist. Gerade in der Computergrafik und -animation besteht aber zu Beginn immer das Problem, dass selbst der Gegenstand oder das Objekt, von dem man gerne Bilder produzieren möchte, nicht realer Natur ist. Objekte, Szenerie und Darsteller existieren nur in unserer Phantasie, sie müssen erst mathematisch beschrieben und erzeugt werden. Sie bleiben aber bis zuletzt künstlich, virtuell.

1.1 Modellierung virtueller Welten

■ ■ ■

1

Doch gerade in dieser Problematik kann auch der Reiz und Schatz von Virtual-Reality-Anwendungen oder Computeranimationen liegen, denn nur die menschliche Vorstellung begrenzt die Produktion. Diesem Problem, d. h. der Beschreibung und schnellen Verarbeitung virtueller Modelle, werden wir uns in diesem Kapitel zuwenden. Wir wollen Datenstrukturen entwickeln, die für Virtual-RealityAnwendungen und Computeranimationen eingesetzt werden können, und ihre jeweiligen Vor- und Nachteile besprechen.

1.1.1 Objektmodellierung, -repräsentation und ihre Datenstrukturen Erster Schritt der „technischen“ Produktionspipeline ist es also, dreidimensionale Gegenstände, Szenen oder virtuelle Darsteller in ihrer Form und Eigenschaft zu beschreiben – das Modellieren. Wie und wodurch beschreiben wir (dreidimensionale) Objekte? Eine erste Antwort auf diese Frage ist schnell gefunden, nämlich durch die Angabe der geometrischen Form, welche durch die Angabe der (dreidimensionalen) Punkte und Flächen gegeben ist. Diese Punkte und mathematischen Formulierungen dienen dazu, die Objekte beschreiben zu können. Zunächst betrachten wir einfache Randrepräsentierungen, welche eine Objektoberfläche durch geschicktes und genaues Zusammenfassen von Polygonen, die wiederum aus Punkten und Kanten beschrieben werden, als Näherung darstellen. Dann folgt die Beschreibung durch Kurven und Flächen höherer Ordnung, sogenannte Freiformflächen. So entstehen mehrere Möglichkeiten, dreidimensionale Objekte zu beschreiben, und je nach beabsichtigter Anwendung, d. h. technischer Konstruktion, Animation oder wissenschaftlicher Simulation, besitzen diese Vor- und Nachteile. Es ist also eine sorgfältige Wahl der verwendeten Datenstruktur zu treffen. 1.1.1.1 Randrepräsentierungen Dreidimensionale Objekte werden in ihrer Form durch ihre (sichtbare) Oberfläche beschrieben. Punkte sind durch Kanten verbunden, die zu ebenen Polygonflächen zusammengefasst werden. Eine erste Datenstruktur, wie man sie z. B. in OpenInventor, Java3D und Wavefront obj-Formaten wiederfindet, ist einfach gehalten. Sie trennt aber schon die Lage der Punkte (Geometrie) von der Verbindung zu Flächen (Topologie).

2

■ ■ ■

1 Computergrafik und Virtual Reality

Definition: Explizite Darstellung eines Polygonnetzes (vgl. Java 3D, VRML ...) i i i i • Facette: Pi = (V 1, V 2, ... ,V n), mit V j∈ ℝd • Netz: P=(P0,P1,...,Pm-1)

Polygonnetz

Dieses Vorgehen wird an folgendem Beispiel deutlich: Wir wollen einen einfachen (Einheits-)Quader darstellen: Abb. 1.1: Beispiele für die Darstellung eines Polygonnetzes

Sie sehen in Abb. 1.1 bereits zwei mögliche Datenstrukturen für einen einfachen dreidimensionalen Einheitswürfel. Datenstruktur 1 besteht aus einer Liste der im Modell vorkommenden Punktkoordinaten und einer davon getrennten Liste der das Modell definierenden Polygonflächen. Datenstruktur 2 hingegen definiert die Polygonflächen direkt durch die Angabe der Koordinaten der Punkte unter der Vereinbarung, dass jeweils vier (oder drei) aufeinander folgende Punkte eine geschlossene Fläche bilden. Datenstruktur 1 besitzt einige Vorteile: Zuerst ist sie sehr einfach und intuitiv. Durch die Trennung von Topologie und Geometrie sind bei einer Lageänderung eines oder mehrerer Punkte nur die neuen Koordinaten der Punkte neu zu setzen bzw. zu übertragen. Der innere Zusammenhang, d. h. die Gitterstruktur der Kanten oder besser die Topologie des Körpers, ändert sich nur dann, wenn der Körper auseinanderbrechen würde.


■ ■ ■

3

Der Nachteil dieser sog. knotenbasierten Datenstrukturen wird sofort deutlich, wenn man Anwendungen programmieren möchte, bei denen sich die Form und Geometrie der Körper ändert. Will man die Geometrie ändern, so muss der entsprechende Eintrag in der Vertexliste geändert werden bzw. muss in allen Flächen, welche diesen Punkt enthalten, entsprechend die Koordinate abgeändert werden. Aufwendige Suchfunktionen sind dafür notwendig. Noch schwieriger wird es, wenn die Topologie des Körpers verändert wird, wie z. B. bei einer booleschen Differenz oder Summe in einem CAD-Modellierer. Diese knotenbasierten Datenstrukturen sind deswegen häufig dort im Einsatz, wo es schlicht um eine Visualisierung und kleine Datenformate bei der Übertragung geht. All die Schwierigkeiten kreisen um ein und dasselbe Problem. Wie können Nachbarschaftsinformationen, die wir für eine Verarbeitung des Modells benötigen, schnell bereitgestellt werden? Aber überlegen wir zunächst, was das für Informationen sind und wie viele es gibt? Alles, was wir brauchen, um Oberflächenmodelle von Körpern darzustellen, sind Punkte (Vertices) V, Kanten (Edges) E und Flächen (Faces) F. Will man nun Informationen zusammenstellen, so ergeben sich genau neun verschiedene Fragen: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Vertex Vertex Vertex Edge Edge Edge Face Face Face

alle benachbarten Vertices alle benachbarten Edges alle benachbarten Faces alle benachbarten Vertices alle benachbarten Edges alle benachbarten Faces alle benachbarten Vertices alle benachbarten Edges alle benachbarten Faces

bzw: Abb. 1.2: Nachbarschaftsbeziehungen in Oberflächenmodellen

4

■ ■ ■


VV VE VF EV EE EF FV FE FF

Schnell wird klar, dass nicht alle 9 Informationen in einer Datenstruktur abgelegt werden können, wenn diese Datenstruktur noch mit einem erträglichen Aufwand verwaltet und gespeichert werden soll. Betrachten wir noch einmal die beiden knotenbasierten Datenstrukturen. Die Information, welche Fläche welche Vertices besitzt, ist explizit abgelegt. Will man jedoch alle zu einem Vertex benachbarten Flächen wissen, so muss die komplette Flächenliste nach diesem Vertex durchsucht werden. Diese Abfrage ist also von der Größe des abgespeicherten Modells abhängig und kann unter Umständen lange dauern. Es stellt sich also die Frage, welche dieser 9 Nachbarschaftsinformationen bestmöglich ausreichen, um einen möglichst kleinen Aufwand bei der Suche nach den anderen Informationen zu haben. Die Vielzahl der Datenstrukturen unterscheidet sich also in der Zahl der explizit abgelegten (Nachbarschafts-)Informationen. Datenstrukturen können daher bezüglich Speicheraufwand und Komplexität der Algorithmen zur Nachbarschaftssuche klassifiziert werden. Wir gehen hier auf die wichtigsten Datenstrukturen ein. Eine genauere Untersuchung ist in [NB94] zu finden. 1.1.1.2 Kantenorientierte Datenstrukturen Bei einer Suche nach einem Ausweg beobachten wir, dass die wesentliche Information über die Form von Körpern in den Kanten des Polygonnetzes steckt. Eine Fläche ist z. B. genau durch einen geschlossenen Kantenzug gegeben. Es liegt also nahe, dreidimensionale Objekte durch eine Datenstruktur zu definieren, die als wesentliche Einträge Kanten nutzt. Im Jahre 1975 stellte Bruce G. Baumgart [Bau75] eine solche kantenorientierte Datenstruktur vor. Folgende Überlegungen führen zu dieser Winged-Edge-Datenstruktur:

Winged-Edge-Datenstruktur

• Jede Kante besitzt genau 2 Nachbarflächen. • In der Orientierung der Fläche gibt es für jede Kante genau eine vorhergehende und nachfolgende Kante. • Deswegen der Name dieser Datenstruktur: An jeder Kante hängen zwei „Flügel“ ncw (next clockwise) und nccw (next counterclockwise). • Sind die Flächen konsistent orientiert, kommt jede Kante einmal + und – vor.


■ ■ ■

5

Abb. 1.3: Winged-Edge-Datenstruktur

Für unser Würfel-Testmodell ergeben sich die in Abb. 1.4 dargestellten Einträge in die abzuspeichernde Datenstruktur. Die Vorteile dieser Datenstruktur werden sofort klar, wenn man sich z. B. die Aufgabe stellt, eine beliebige Fläche aus dem obigen Datensatz zu zeichnen. Wir wollen versuchen, die fünfte Fläche (Index 4 der Facelist) zu zeichnen: Beginnen werden wir wie angegeben mit Kante e11, die wir positiv, d. h. von Vstart (Vertex 7) zu Vend (Vertex mit Index 4) durchlaufen. Der Eintrag ncw, für die Kante 11, ist mit e4 angegeben (ncw beim positiven Durchlauf), welche Vstart 0 und Vend 4 besitzt. Da wir nun aber mit der ersten Kante bei Vertex 4 angekommen sind, müssen wir, um e4 zu zeichnen, diese Kante in negativer Richtung, d. h. von Vend nach Vstart, durchlaufen. Also folgt als nächste zu zeichnende Kante nccw e3 usw. Nach Durchlaufen der vierten Kante stellen wir fest, dass wir wiederum als folgende Kante e11 zeichnen müssten, die jedoch schon zu Beginn verwendet wurde. Wir sind also einen geschlossenen Kantenzug abgelaufen und haben somit die Fläche f4 durch „lokales Umrunden“ gezeichnet. Damit haben wir gleichzeitig die Nachbarschaftsinformation FE (die zu einer Fläche inzidenten Kanten) bereitgestellt. Die Abfrage dauert also so lange, wie man braucht, um einmal die Fläche zu umrunden, ist damit nur von der lokalen Eigenschaft abhängig und hängt somit nicht Abb. 1.4: Beispiel für Winged-Edge-Datenstruktur

6

■ ■ ■


Abb. 1.5: Bestimmung der benachbarten Kanten einer Fläche durch lokales Umrunden

von der Größe des gesamten Polygonnetzes ab. Die Antwort dieser Nachbarschaftsabfrage ist also in konstanter Zeit zu erwarten! Jedoch sind die anderen Nachbarschaftsabfragen wie z. B. FF oder EF leider noch immer nur mit Durchsuchen der gesamten Flächen und Kantenliste zu lösen. Um diese letzten Nachbarschaftsbeziehungen auch noch in konstanter Zeit abfragen zu können, betrachten wir die folgend beschriebene Full-Winged-Edge-Datenstruktur. Die Winged-Edge-Datenstruktur kann auf interessante Weise erweitert werden: Jede Kante besitzt genau zwei Nachbarflächen. Anders herum wird eine Kante bezüglich einer Fläche nur in einer Richtung durchlaufen. Daher konnten wir in der Winged-Edge-Datenstruktur + oder – (ein Bit) nutzen, um genau die Fläche anzugeben. Legt man diese Information nun noch in die Kantenliste, so kann auf das Bit in der Flächenliste verzichtet werden: Wir erhalten die sog. Full-WingedEdge-Datenstruktur, bei der die Kanten zusätzlich Information über die zugehörige Fläche bei positivem und negativem Durchlauf enthalten. Bei der Full-Winged-Edge-Datenstruktur können alle Nachbarschaftsinformationen durch lokales Umrunden, d. h. in konstanter Zeit O(1), berechnet werden. Die Abfragen E* sind jedoch wesentlich langsamer als F*.

Full-Winged-Edge-Datenstruktur

Abb. 1.6: Full-Winged-Edge-Datenstruktur


■ ■ ■

7

Abb. 1.7: Beispiel für Full-Winged-Edge-Datenstruktur

Trotz der großen Vorteile der Full-Winged-Edge-Datenstruktur existiert noch ein gravierendes Problem: Die bisher beschriebenen Edge-Datenstrukturen gehen davon aus, dass eine Fläche durch nur eine Randkuve (d. h. eine Folge von Kanten) definiert ist. Es gibt aber viele Körper, die Flächen mit Löchern haben, wie im folgenden Beispiel. Die obere Fläche, mit aufgesetztem kleinerem Quader, besitzt zwei Randkurven: Abb. 1.8: Fläche mit Loch

Eine mögliche Lösung ist, eine zusätzliche Kante einzufügen. Diese Kante hat nun die gleiche Fläche in den Einträgen fcw und fccw. Eine zweite Möglichkeit ist in obigem Beispiel dargestellt. Die obige Fläche hat zwei Randkurven, jedoch mit unterschiedlichen Umlaufrichtungen (zwei Einträge in der Flächenliste). Einen dritten Ausweg bietet die Einführung von sogenannten Halbkanten [Mä88]. Eine Kante kann prinzipiell in zwei Richtungen durchlaufen werden. Eine Halbkante ist also definiert durch zwei Punkte und eine Durchlaufrichtung. Daher braucht man 2 Halbkanten

8

■ ■ ■


für eine volle Kante. Eine Darstellung von Halbkantendatenstrukturen findet man in [ES97, Mä88].

1.1.2 Kurven Sind die Oberflächen der darzustellenden Objekte nicht eben und eher krummliniger, organischer Natur, so braucht man eine hohe Anzahl von Geradenstücken oder ebenen Flächen, um diese gut zu approximieren. Ihre weitere Bearbeitung wird dadurch langsam und aufwendig. Jedoch ist dies nicht der alleinige Nachteil: Wo kommen die vielen Punkte der Annäherungskurven und -ebenen zu liegen, d. h., wie ermitteln wir deren Koordinaten? Nehmen wir das einfache Beispiel einer exakten Kreislinie in der Ebene. Annäherungen wären ein Quadrat, ein Sechs-, Acht- oder n-Eck. Einige Koordinaten der Linienpunkte können mit Zirkel und Lineal konstruiert werden. Sollen jedoch die Punkte von einem 1000Eck angegeben werden, brauchen wir eine „Formel“ zur Berechnung. Diese Formel kann leicht mit den „Kreisfunktionen“ Sinus und Kosinus ausgedrückt werden. Geraden- und Ebenenstücke reichen also nur eingeschränkt aus, um dreidimensionale Objekte zu gestalten. Besser wäre es, wenn ein paar wenige Punkte (sog. Kontrollpunkte) genügen würden, um den Verlauf der Fläche mit seinen vielen Punkten zu steuern. Zwei Herangehensweisen finden sich in der Computergrafik: Zum einen sind dies parametrisierte Kurven und Flächen und zum anderen eine Beschreibung der Objektoberfläche durch Angabe von Punkteigenschaften (implizite Flächen) der Oberfläche. 1.1.2.1 Monome und parametrisierte Kurven Wir wollen uns zuerst auf den einfacheren Kurvenfall beschränken. Was ist nun eine sog. parametrisierte Kurve? 3 Definition: Sei I=[a,b] ⊂ ℝ ein Invervall. Eine Abbildung g:I→ℝ heißt parametrisierte Kurve: ⎛ x(t ) ⎞ ⎜ ⎟ g (t ) = ⎜ y(t ) ⎟ ∈ ⎜ z(t ) ⎟ ⎝ ⎠

3

Parametrisierte Kurve

, für alle t ∈ [a,b ]

Eine parametrisierte Kurve g heißt n-mal stetig differenzierbar, falls jede Koordinatenfunktion x(t), y(t) und z(t) n-mal stetig differenzierbar


■ ■ ■

9

ist, und man schreibt g ∈ C n (I , heißt regulär (in t0), falls

3

)lim . Eine parametrisierte Kurve x→∞

⎛ x ′(t 0 ) ⎞ ⎜ ⎟ g ′(t 0 ) = ⎜ y ′(t 0 ) ⎟ ≠ 0 ⎜ z ′(t ) ⎟ 0 ⎠ ⎝

Der Gradient g´(t)∈ ℝ ist die Tangente in t an g und gibt die Momentangeschwindigkeit (in Betrag und Länge) beim Durchlaufen der Kurve an. Die (Bogen-)Länge einer Kurve kann durch 3

u

S(u) = ∫ g ′(s) ds a

berechnet werden. 3 3 Zwei reguläre Kurven, g1: [a,b]Æ ℝ und g2: [s,t] Æ ℝ , heißen äquivalent, wenn es eine bijektive differenzierbare Abbildung ϕ:[a,b]Æ[s,t] mit ϕ ´(u)>0 gibt, so dass g1(u)= g2(ϕ (u))

Parametrische Stetigkeit

gilt. Wir sagen in diesem Fall auch, dass g2 durch ϕ reparametrisiert wurde, und nennen ϕ einen richtungserhaltenden Parameterwechsel oder eine Reparametrisierung von g1. Zwei Kurven können aneinandergefügt werden. Zwei n-mal stetig 3 3 differenzierbare reguläre Kurven g1: [a,b]Æ ℝ und g2: [s,t] Æ ℝ n schließen an der Stelle b, s C -stetig aneinander (parametrisch stetig), genau dann, wenn g 1( k ) (b) = g 2( k ) (s) für alle 0 ≤ k ≤ n.

Abb. 1.9: Zwei äquivalente Kurven

10

■ ■ ■


Für Animationen und sonstige Anwendungen der Computergrafik ist diese Definition des parametrisch stetigen Übergangs zu strikt. Es zählt vielmehr der visuell-glatte Übergang. Daher definieren wir (Geon metrisch stetiger Anschluss oder G -stetiger Übergang): Zwei n-mal 3 3 stetig differenzierbare reguläre Kurven g1: [a,b]Æ ℝ und g1: [s,t]Æ ℝ n schließen an der Stelle b, s G -stetig aneinander, falls es eine zu g1 äqui3 n valente Kurve r: [a1,b1]Æ ℝ gibt, so dass r0 und g2 an der Stelle b1, s C stetig aneinanderschließen. Also existiert eine bijektive differenzierbare Abbildung ϕ:[a, b]→ [a1, b1 ] mit ϕ´(.)≥0, so dass r= g1°ϕ. Damit ergibt sich mit der Kettenregel für die Ableitungen:

Geometrische Stetigkeit

g 2 (s) = r (b1 ) = g 1 (ϕ (b)) g 2′ (s) = g 1′(ϕ (b))ϕ ′(b) g 2′′(s) = g 1′′(ϕ (b))ϕ ′(b)2 + g 1′(ϕ (b))ϕ ′′(b) 0

1

Also heißt G - und G -Stetigkeit: • G -Stetigkeit entspricht der C -Stetigkeit. 1 • G -Stetigkeit: Der Übergang ist stetig und beide Tangentenvektoren haben am Übergang die gleiche Richtung. 0

0

Der dreidimensionale Raum ℝ steht hier stellvertretend für allged mein d-dimensionale Räume ℝ . Es sind dann natürlich entsprechend mehr oder weniger Koordinatenfunktionen zu definieren. Man sieht, dass zur Angabe einer parametrisierten Kurve neben dem Intervall die Angabe von Koordinatenfunktionen genügt, wie in dem in Abb. 1.10 dargestellten Beispiel einer ebenen parametrisierten Kurve. Im Prinzip darf man für die Koordinatenfunktionen jede mögliche Funktion wählen, jedoch besitzen vor allem die Polynomfunktionen besonders schöne (aber auch schlechte) Eigenschaften. Insbesondere, und das ist in der Informatik besonders wichtig, sind sie sehr schnell 3

Abb. 1.10: Beispiel einer ebenen parametrisierten Kurve


■ ■ ■

11

auszuwerten. Dies ist ein Grund, dass man sich in der Computergrafik vor allem diesen Funktionsarten verschrieben hat. Definition: Die Menge ⎧ n ⎫ P n ([a, b]) = ⎨∑α it i , für α i ∈ R3 und t ∈ [a, b ]⎬ ⎩ i=0 ⎭

Monombasis Taylorbasis

aller Polynome vom Grad n ist ein endlich dimensionaler Unterraum 3 von C([a,b], ℝ ), dem Raum der stetigen, parametrisierten Kurven. Die Vektoren αi heißen Taylorkoeffizienten des Polynoms. n Der Unterraum P [a,b] hat Dimension n+1 und die Menge der Mo2 n nome {1,t,t ,..., t } bildet eine Basis, die sog. Monom- oder Taylorbasis. Wie man leicht sehen kann, ist es egal, ob man drei polynomielle Koordinatenfunktionen mit reellen Koeffizienten oder vektorielle Koeffizienten wählt: Ein Beispiel: ⎛ 1 + t + 1.5t 2 − 3t 3 ⎞ ⎛ 1 ⎞ ⎛ 1 ⎞ ⎛ 1.5 ⎞ ⎛ −3 ⎞ ⎜ ⎟ ⎜ ⎟ ⎜ ⎟ ⎜ ⎟ 2 ⎜ ⎟ 3 2 p(t ) = ⎜ 1.5 − t + 3t ⎟ = ⎜ 1.5 ⎟ + ⎜ −1 ⎟t + ⎜ 3 ⎟t + ⎜ 0 ⎟t ⎜ 3 + 6t − t 2 + 6t 3 ⎟ ⎜ 3 ⎟ ⎜ 6 ⎟ ⎜ −1 ⎟ ⎜6⎟ ⎝ ⎠ ⎝ ⎠ ⎝ ⎠ ⎝ ⎠ ⎝ ⎠

Hornerschema

Polynomfunktionen sind besonders schnell auszurechnen, d. h., ein Funktionswert an einer vorgegebenen Intervallstelle t0 kann durch das sog. Hornerschema ausgewertet werden. Das vollständige Hornerschema erlaubt sogar die Berechnung der Ableitungen: Ist ein Polynom in Monomdarstellung p(t ) = α nt n + α n−1t n−1 +

+ α 2t 2 + α1t + α 0

gegeben, so errechnet sich leicht der Funktionswert p(t0) an der Stelle t0 nach folgendem Schema (Hornerschema): Von oben nach unten wird mit t0 multipliziert − von links nach rechts. Der Funktionswert steht rechts in der Tabelle.

αn + ·t0

0

αnt0

αn-1 αnt0 (αn-1+αnt0) t0

αn-2

… … …

α0 **t0

p(t0)

Das vollständige Hornerschema sei an einem Beispiel demonstriert: Gesucht sei der Funktionswert des folgenden Polynoms an der Stelle t0 = 2 p(t ) = t 4 + 2t 3 − 3t 2 − 7

12

■ ■ ■


Dann ergibt sich:

1 + 0 ⋅2 1 + 0 ⋅2 1 + 0 ⋅2 1 + 0

2 2 4 2 6 2 8 2

−3 0 −7 8 10 20 5 10 13 = p(2) 12 34 17 44 ⋅ 1!= p′(2) 16 33 ⋅ 2!= 33 ⋅ 2 ⋅ 1 = p′′(2)

⋅ 2 1 10 ⋅ 3!= 10 ⋅ 3 ⋅ 2 ⋅ 1 = p′′′(2) + 0 ⋅ 2 1 ⋅ 4!= 1 ⋅ 24 = p (4 ) (2) Die Auswertung eines Polynoms mit dem Hornerschema ist effektiver als die Auswertung nach Funktionsvorschrift. Wie ist aber unser Programm der Objektmodellierung zu realisieren? Gegeben sei eine komplexe Form und diese soll als parametrisierte Kurve dargestellt werden, am besten noch als Polynomfunktion. Dadurch könnte eine komplexe, kontinuierliche Form durch ein paar wenige Punkte, d. h. die Koeffizienten αi, vollkommen definiert werden. Schnell stellt sich die Frage, ob das überhaupt möglich ist und, falls ja, wie die Koeffizienten αi zu berechnen sind? 1.1.2.2 Interpolationsaufgabe, Monominterpolation

Wir kennen jedoch ein positives Resultat, welches uns auf unserem Weg bestärkt. Zunächst noch einmal die Aufgabe: Gegeben: Eine Reihe von (Mess-)Punkten (ui,Pi), i=0,...,n, mit ui∈R 3 und Pi ∈ ℝ . Gesucht: (Interpolationsaufgabe IA) Eine Funktion f, welche der Bedingung genügt, dass f(ui)= Pi für alle i=0,...,n die Kurve f also zu den vorgegebenen Parameterwerten ui durch die vorgegebenen Punkte Pi verläuft. ui heißen Stützstellen, der Vektor (u0, ..., un) Stützstellenvektor und Pi heißt Stützpunkt. Die Paare (ui, Pi) heißen Knoten der IA.


■ ■ ■

13

Wie bereits erwähnt, gibt es zu diesem zentralen Problem eine positive Antwort. Diese Tatsache ist nicht nur für die Modellierung von Objekten von Bedeutung, sondern das nachfolgende Theorem hat vielfältige Anwendungen in der Numerik und damit in der Computergrafik. Theorem: Es seien n+1 paarweise verschiedene Knoten (ui, Pi), i=0,...,n d mit ui ∈ℝ und Pi ∈ ℝ gegeben. Dann existiert genau ein Polynom p d vom Grad ≤n, mit n+1 Koeffizienten ci ∈ ℝ , so dass n

p(t ) = ∑ cit i und p(ui ) = Pi für alle i = 0,1,..., n i =0

Beweis: Nach Voraussetzung gilt: c0 + c1u0 + c2u02 + … + cnu0n = P0 c0 + c1u1 + c2u12 + … + cnu1n = P1 c0 + c1un + c 2un2 + … + cnunn = Pn

In Vektorschreibweise ergibt sich dann: ⎛ 1 u0 ⎜ ⎜ 1 u1 ⎜ ⎜ ⎝ 1 un

u0 2 u12 un 2

u0n ⎞⎛ c0 ⎞ ⎛ P0 ⎞ ⎟⎜ ⎟ ⎜ ⎟ u1n ⎟⎜ c1 ⎟ ⎜ P1 ⎟ = ⎟⎜ ⎟ ⎜ ⎟ ⎟⎜ ⎟ ⎜ ⎟ unn ⎠ ⎝ cn ⎠ ⎝ Pn ⎠

Μ ⋅C = P Die Matrix M hat die bekannte Form der sog. Van der Monde’schen Matrix. Die Zeilen sind jeweils fortschreitende Potenzen von ui. Sind die Stützstellen ui paarweise verschieden, ist die Matrix M invertierbar und das Gleichungssystem ist lösbar. Die unbekannten Koeffizienten ci sind dadurch eindeutig gegeben. Diese Methode (Interpolation mit Monomen) liefert die Existenz einer Lösung der Interpolationsaufgabe und deren Eindeutigkeit. Das Problem ist aber, die unbekannten Koeffizienten ci zu finden. Fügt man einen neuen Knoten ein (hat man einen zusätzlichen Interpolationspunkt), so muss die volle Matrix invertiert werden. Eine Lösung des Problems ist die Newton-Interpolation [Br00]. Schwieriger als das eben beschriebene Problem ist jedoch folgendes Phänomen: Stellen wir uns eine Kurve vor, welche wir durch Monominterpolation gewonnen haben: n

p(t ) = ∑ cit i und p(ui ) = Pi für alle i = 0,1,..., n i =0

14

■ ■ ■


Wobei also die Knoten (ui,Pi), i=0,…,n, vorgegeben und die Koeffizienten ci durch Lösen des Gleichungssystems gewonnen wurden. Wird nun auf diese Kurve eine affine Transformation (z. B. eine Rotation) angewandt, so stellt sich die Frage, ob die Kurve wieder durch die nun ebenfalls rotierten Punkte Pi geht. Leider ist dem nicht so! Untersuchen wir diese Eigenschaft einmal genauer: Es sei Φ eine d Abbildung (z. B. Translation, Rotation, Streckung) in ℝ . Φ heißt eine affine Abbildung, wenn für alle Skalare λ0, λ1, ..., λn∈ℝmit ∑ λi=1 und alle Punkte P0,…,Pn folgende Gleichung gilt: ⎛ ⎝

⎞ ⎠

Φ ⎜ ∑ λi Pi ⎟ = ∑ λΦ (Pi ) i i

i

Nun sind aber c0, c1,..., cn∈ ℝ und p(u) eine Polynomkurve mit p(u)=∑0≤i ≤ n ci fi(u). Diese Darstellung ist genau dann affin invariant, wenn d

n

∑ f (u) = 1 i

∀u ∈[a, b] , denn dann gilt

i =0

⎛ ⎝

n

⎞ ⎠

n

Φ ⎜ ∑ fi (u)Pi ⎟ = ∑ fi (u)Φ (Pi ) ∀u ∈[a, b] i =0

i =0

Anschaulich erhält man den gleichen Kurvenverlauf, unabhängig davon, ob man zuerst die Stützpunkte affin verschiebt und dann die Kurve berechnet, oder ob man zuerst die Kurve berechnet und dann die einzelnen Kurvenpunkte affin transformiert. i Für Monome gilt jedoch im Allgemeinen ∑ u ≠1 für u∈[a,b], daher ist die Polynomdarstellung mit Monomen (Taylorbasis) nicht affin invariant. Betrachten wir dazu ein Beispiel: Wir nehmen an, dass wir den Weg eines berühmten Bergsteigers auf den Gipfel des Mount Everest modellieren wollen. Er befindet sich zu gewissen Zeiten ui in den Basislagern Pi, die über GPS bestimmt wurden. Sein Weg wird durch Bestimmung der Taylorkoeffizienten computergrafisch modelliert. Leider dreht sich die Erde in 24 Stunden einmal um sich selbst und damit wird in einem globalen, geozentrischen Koordinatensystem die Kurve unseres Bergsteigers auf den Gipfel rotiert. Die Kurve muss immer dieselbe sein und es genügt nun nicht, einfach die Taylorkoeffizienten zu rotieren, um die Kurve zeichnen zu können! Um die Kurve durch die Basislager zu zwingen, müssen wir, Bild für Bild, zur Bestimmung der Taylorkoeffizienten ci ein Gleichungssystem lösen.


■ ■ ■

15

Außerdem ist es nicht möglich, die Koeffizienten ci irgendwie mit dem Verlauf der Kurve in Beziehung zu setzen. Sie haben keine geometrische Bedeutung für den Kurvenverlauf. Dies alles sind schwerwiegende Probleme bei der Interpolation mit Monomen. Die einzige Lösung aus diesem Dilemma ist, eine neue Menge von Basisvektoren für den Raum aller Polynomkurven zu finden, die die gewünschten Eigenschaften besitzt: • • • •

Einfache Berechnung der Koeffizienten ci Geometrische Deutung der Koeffizienten ci Affine Invarianz der Kurve Einfache Berechnung der Kurve p(t)

1.1.2.3 Interpolationsaufgabe, Lagrangekurven

Die ersten drei Eigenschaften sind leicht durch folgenden Ansatz zu erreichen: Lni (u) =

=

n

u − uj

j =0, j ≠i

ui − u j

∏

(u − u0 )(u − u1 ) (u − ui−1 )(u − ui+1 ) (u − un ) (ui − u0 )(ui − u1 ) (ui − ui−1 )(ui − ui+1 ) (ui − un )

Es seien n+1 Knoten (ui,Pi) gegeben, mit i=0,...,n und u0

Im obigen Beispiel soll eine Kopie des Quelldokumentes erzeugt, das Element txt jedoch nicht mitkopiert werden, so dass lediglich der Inhalt des Elementes im Zieldokument erscheint. Im Gegensatz zu der Instruktion copy-of erzeugt copy bei einfacher Verwendung nur eine flache Kopie des Dokumentenbaums. Durch das verschachtelte apply-templates mit select= "@*|node()" im ersten Template erfolgt jedoch solange ein rekursiver Aufruf des Templates, bis der Baum fertig traversiert ist. Alle Attribut- und Kindknoten werden dabei übergeben. Sobald das Element txt gefunden wird, wird die Verarbeitung durch das zweite Template fortgesetzt und nur der reine Text ausgegeben. Je nach Einsatz des jeweiligen Publishing-Werkzeuges besteht der Bedarf nach einer Zeichencodierung mit ISO-Entities oder Zeichenreferenzen. Dazu muss vorausgeschickt werden, dass jede Transformation mit XSLT per Definition mit Unicode als Zeichensatz erfolgt. Wird die Codierung der Zeichen als ISO-Entities gewünscht, so kann man sich der Character-Maps aus dem XSLT-2.0-Standard bedienen. Eine Character-Map weist den XSLT-Prozessor an, ein bestimmtes Zeichen durch einen bestimmten String im Zieldokument zu ersetzen.

2.3 Publishing

■ ■ ■

109

In obigem Beispiel wird wieder die Instruktion copy in Verbindung mit einem rekursiven Aufruf verwendet, um den ganzen Baum des Quelldokumentes in das Zieldokument zu überführen. Durch die Definition einer Character-Map lassen sich einzelne Vorschriften zur Zeichenersetzung zusammenfassen. Das Attribut usecharacter-maps des Elementes xsl:output wendet die Character-Map auf das Zieldokument an. Zu beachten ist dabei, dass das Zieldokument nun ISO-Entities enthält, die dort – wie im Beispiel mit einer DTD – noch zu definieren sind. Eine bereits fertige Character-Map zur Umsetzung von UnicodeZeichen in ISO-Entities findet sich bei: http://www.w3.org/2003/entities/iso8879doc/overview.html. Eine typische Anwendung, vor allem bei Online-Publikationen, ist das Umorganisieren und Gruppieren von Inhalten. Ein konkretes Beispiel dafür ist die Generierung eines Stichwortverzeichnisses aus 8 einem XML-Quelldokument. Gegeben sei folgendes XML-Fragment :

8

110

■ ■ ■

Es sei angemerkt, dass die Erstellung eines Stichwortverzeichnisses weitaus komplexer organisiert sein kann. Sowohl die Verzeichnistiefe als auch die Auswahl und Codierung der Begriffe erfordert dann eine komplexere technische Umsetzung sowie die Möglichkeit redaktioneller Eingriffe.

2 Einsatz von Markup-Languages

Extensible Markup Language Einführung Die Extensible Markup Language, abgekürzt XML , ist ein Standard zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer Baumstruktur. XML definiert dabei die Regeln für den Aufbau solcher Dokumente Anwendungen Für einen konkreten Anwendungsfall ("XML -Anwendung") müssen die Details der jeweiligen Dokumente spezifiziert werden. Dies betrifft insbesondere die Festlegung der Strukturelemente und ihre Anordnung innerhalb des Dokumentenbaums.

Durch das Element emp werden die Stichworteinträge kenntlich gemacht. Da im Fließtext das Stichwort oft nicht in seiner Grundform auftritt, empfiehlt es sich, den eigentlichen Eintrag separat zu codieren. Dies geschieht hier über das Attribut entry. Die Generierung eines Stichwortverzeichnisses gliedert sich nun in zwei Schritte: • Erstellen einer Liste von Begriffen mit Verlinkung in HTML • Gruppieren dieser Liste nach Oberbegriffen Im ersten Schritt muss nun jedem Attributwert von entry eine eindeutige ID zugeordnet werden, damit später darauf referenziert werden kann. Die Funktion generate-id ordnet zur Laufzeit des XSLT-Skripts einem XML-Knoten einen eindeutigen String zu.

Das obige Template erzeugt für jedes emp-Attribut einen HTMLAnker mit eindeutiger ID. Da generate-id die ID dem jeweiligen

2.3 Publishing

■ ■ ■

111

Knoten zuordnet, gilt: Wird generate-id auf demselben Knoten mehrmals aufgerufen, so ergibt sich auch die identische ID. Bei der Generierung des Stichwortverzeichnisses kann man sich diese Tatsache zu Nutze machen.

In einem ersten Schritt wird über das entry-Attribut aller empElemente iteriert. Durch den wiederholten Aufruf von generate-id für die Codierung der Sprungadresse des HTML-Links korrespondiert der Begriff im Stichwortverzeichnis mit dem HTML-Anker im Haupttext. Das Resultat ist eine verlinkte Liste aller Stichwörter. Unschön an einer solchen Umsetzung ist, dass zum Beispiel der Begriff "XML" in obigem Beispiel mehrmals hintereinander auftaucht. Wünschenswert wäre daher eine gruppierte Darstellung, so dass XML nur noch als Oberbegriff erscheint und alle dazugehörigen Links nachfolgend unter Angabe der Kapitelnummer und des Titels. Für die Lösung des Problems können wir uns einer Instruktion aus XSLT 2.0 bedienen. Die Instruktion xsl:for-each-group bildet eine Schleife über Gruppen von Einträgen. Während des Schleifendurchlaufs kann sowohl auf die aktuelle Gruppe (currentgrouping-key()) als auch auf jeden Eintrag in der Gruppe (current-group()) zugegriffen werden.

112

■ ■ ■


In diesem zweiten Schritt werden zunächst Gruppen von empElementen gebildet mit dem Attribut entry als Gruppierungskriterium. In einer verschachtelten for-each-Schleife kann nun auf die einzelnen Elemente der jeweiligen Gruppe zugegriffen werden. Die Funktion position() gibt dabei lediglich die aktuelle Nummer des section-Elementes aus.

2.3.5 Druckbare Ausgabe Ein Grundprinzip medienneutraler Datenhaltung ist die Abspaltung konkreter Layoutinformationen vom eigentlichen Dokumentinhalt und der Dokumentstruktur. Diese Tatsache ermöglicht es, die Publikation ein und desselben Dokumentinhalts unter Berücksichtigung medientypischer Besonderheiten (z. B. Links bei HTML) für verschiedene Medien zu publizieren. Für jedes Zielmedium wird dann eine eigene Layoutkomponente erstellt, die eine komplette Neuanlage und damit die redundante Datenhaltung für jedes Zielmedium nicht mehr notwendig macht. Das Dateiformat XML kann bei korrekter Modellierung eine solche Trennung leisten. Um nun ein medienneutral vorliegendes XML-Dokument für den Print publizieren zu können, ist eine medienspezifische Formatierungskomponente nötig. Die nachfolgende Abbildung zeigt den typiAbb. 2.2: Der XSL-Verarbeitungsprozess

2.3 Publishing

■ ■ ■

113

schen Ablauf einer vollautomatisierten Satzproduktion mit XSL. Die eigentliche Verarbeitung erfolgt dabei in zwei Schritten, die jedoch für 9 den Anwender unsichtbar im Hintergrund ablaufen . Den Ausgangspunkt des Modells stellt die XML-Quelldatei dar. Zusätzlich ist ein XSLT-Stylesheet erforderlich, das Regeln zur Formatierung des Zieldokumentes enthält. Eine Softwarekomponente, der so genannte XSLT-Prozessor, wendet die Regeln aus dem XSLT-Stylesheet an und erzeugt als Ausgabedokument ein sog. FO-Dokument. Das FO-Dokument enthält dabei die Kombination aus Inhalten des XML-Dokumentes und den Layoutund Typografiebeschreibungen aus dem XSLT-Dokument. Ein nachgeschalteter FO-Formatierer übernimmt den Seitenumbruch und generiert eine druckfertige PDF-Datei. Die Kombination aus XSLT-Prozessor und FO-Formatierer stellt sich von außen als integrierte Einheit dar, die aus einer Quelldatei (XML-Dokument) und einem Stylesheet (XSLT-Datei) ein formatiertes Dokument (PDF-Datei) erzeugt. XSL-FO ist kein neues Satzsystem, sondern eine normierte Syntax zur Beschreibung von Layout und Typografie. Im Unterschied zu anderen Seitenbeschreibungssprachen lässt sich XSL-FO nicht direkt drucken oder betrachten, sondern muss vorher durch eine spezielle Software in druckbare Informationseinheiten umgewandelt werden. Ein so genannter FO-Formatierer (Renderer) interpretiert die Layoutinformationen aus dem FO-Dokument, baut die Seitengeometrie auf, „umbricht“ das Dokument nach vorgegebenen Regeln, erzeugt Zeilenund Spaltenumbrüche, veranlasst Silbentrennungen und kann neben anderen Formaten PDF als Ausgabedokument erzeugen. Als Analogie mag der Vergleich mit HTML dienen. HTML-Strukturen bestehen aus Informationen über das Layout eines Web-Dokuments. Erst ein Internet-Browser „übersetzt“ die Layoutbeschreibung in „sichtbare“ Elemente (wie Linien, Farben usw.). Genauso verhält es sich auch mit FO-Dokumenten. Sie enthalten lediglich die Layoutbeschreibung für ein seitenorientiertes Dokument. Das Rendern, also die eigentliche Umsetzung dieser Layoutbeschreibung, übernimmt der FO-Formatierer. Im Unterschied zu vielen herkömmlichen Satzsystemen arbeitet ein FO-Formatierer vollautomatisch, das heißt, es wird z. B. lediglich eine Konvertierung von XSL-FO nach PDF vorgenommen. Ein solches System arbeitet zudem immer nach dem „Output-only-Verfahren“. Einen manuellen Eingriff, wie zum Beispiel inhaltsbezogene Autorenkorrekturen, lässt ein solcher Workflow nicht zu. Korrekturen dieser 9

114

■ ■ ■

Es sei angemerkt, dass PDF nur ein mögliches Ausgabeformat eines FODokumentes darstellt. Weitere Formate sind z.B. SVG oder RTF.


Art werden daher in der Regel nicht in der FO-Datei vorgenommen, sondern in den ursprünglichen XML-Daten, die dann erneut nach XSL-FO gewandelt werden. Individuelle Korrekturen, die das Layout oder die Platzierung von Gestaltungselementen wie Bilder oder Tabellen betreffen und nicht durch Regeln festgelegt werden können, stellen einen XSL-FO-Workflow vor eine große Herausforderung. Nachträgliche Eingriffe in das generierte FO-Dokument können dabei Abhilfe schaffen, verstoßen aber gegen das Prinzip des Vollautomatismus (siehe oben). Um den Publishing-Prozess mit XSL-FO wirtschaftlich sinnvoll einsetzen zu können, müssen folgende wichtige Voraussetzungen erfüllt sein [6]: • Das Layout sollte feststehen und regelbasiert aufgebaut werden können. • Es müssen valide XML-Daten vorliegen, deren Struktur mindestens ein Element oder Attribut für eine Layout- oder Typografieänderung vorsieht. • Manuelle Layout- oder Typografiekorrekturen können ein Ausschlusskriterium sein. • Für kleine Datenmengen und nicht wiederkehrende Arbeiten lohnt sich der Einsatz kaum. Ein großer Vorteil des Publikations-Workflows mit XSL-FO ist die schon genannte vollständige Automatisierbarkeit. Werden also Regeln gefunden, die das Layout und die Typografie zu 100 Prozent abbilden können, stellt der Ansatz über XSL-FO eine geeignete Lösung dar. Auch die ernorme Geschwindigkeit führt dazu, dass keine umfangsabhängigen Kosten anfallen. Ein weiterer Vorteil liegt in der Standardisierung des XSLT-Stylesheets. Man ist also nicht mehr von einer bestimmten Software (bzw. Dienstleister) abhängig, sondern hat nun auch das Stylesheet „herstel10 lerunabhängig“ vorliegen . Probleme beim Einsatz von XSL ergeben sich vor allem dann, wenn ein zusätzlicher manueller Feinumbruch durchzuführen ist. Da bis zum heutigen Tag keine Software auf dem Markt existiert, die FO-Daten grafisch darstellt und zugleich interaktiv bearbeiten lässt, stellt jede manuelle Änderung an Layout und Typografie eine Art „Blindflug“ dar. Änderungen können zwar im FO-Dokument vorge10

Es soll dabei nicht verschwiegen werden, dass sich die Hersteller von FOFormatierern oft nicht exakt an den Standard halten oder aber diesen um Sonderfunktionen erweitern. Daraus folgt dann wieder eine stärkere Bindung an den Softwarehersteller.

2.3 Publishing

■ ■ ■

115

nommen werden, das Resultat kann aber erst nach einer erneuten Formatierung durch den FO-Formatierer begutachtet werden. Auch die regelbasierte Platzierung von Abbildungen ist mit XSL nicht möglich. Eine Abbildung wird immer an der Stelle platziert, wo sich der Aufruf in der XML-Daten befindet – ein echtes Ausschlusskriterium für viele „anspruchsvolle“ Layouter.

2.4 XML-gestützte Anwendungsentwicklung Die Extensible Markup Language ist nach ihrer Einführung 1998 zu einem festen Bestandteil der modernen Anwendungsentwicklung geworden. XML und die auf XML basierenden Technologien sind dabei ein integraler Bestandteil nahezu jeder modernen Softwareapplikation geworden. Der Einsatz von XML in den verschiedenen Anwendungsbereichen ist dabei aber sehr unterschiedlich. Vor allem findet die Markup-Technologie Anwendung bei der Spezifikation von neuen Auszeichnungssprachen wie etwa den vom W3-Konsortium entwickelten Internetstandards XHTML, Wireless Markup Language (WML), Scalable Vector Graphics (SVG) oder auch bei der Synchronized Multimedia Integration Language (SMIL), welche als XMLDokumenttyp-Definitionen realisiert sind. Aber auch die Festlegung von Dateiformaten zum Austausch von Daten zwischen verschiedenen Applikationen oder zum Speichern von komplexen Objektstrukturen in Form von Textdateien zählt zu den Einsatzfeldern von XML in der Anwendungsentwicklung. Beispielsweise stellt UN/EDIFACT im E-Commerce-Umfeld ein XML-gestütztes Austauschformat zur elektronischen Abwicklung von Geschäftsvorfällen dar, während das Apple Interchange Format eine textuelle Repräsentation der Schnittpunkte eines Apple Final Cut Pro-Videoschnittprojektes wiedergibt. Doch auch die Architektur moderner Softwaresysteme ist entscheidend durch die Extensible Markup Language beeinflusst. So wird bei neueren Anwendungsentwicklungen immer häufiger zwischen der Ebene der Anwendungslogik und der Ebene der Präsentation unterschieden. Das in XML realisierte Grundprinzip der Trennung von Inhalt, Struktur und Präsentation bietet vor allem für Cross-Media-Applikationen einen entscheidenden Vorteil, so dass Anwendungen, welche verschiedene Ausgabemedien unterstützen, einfacher und schneller entwickelt werden können. Nachfolgend werden diese drei Aspekte der XML-gestützten Anwendungsentwicklung detaillierter vorgestellt.

116

■ ■ ■


2.4.1 Austauschformate In der heutigen Zeit wird von den meisten Applikationen verlangt, dass sie interoperabel genutzt werden können. Das bedeutet, dass die Arbeitsergebnisse, die mit einer Applikation auf einem Rechner gewonnen wurden, auf einem anderen Rechner mit einem evtl. anderen Betriebssystem und einer anderen Applikation bzw. einer anderen Version der Applikation weiter bearbeitet werden können sollen. Diese Anforderung können Anwendungsentwickler erfüllen, wenn sie die Softwareanwendungen als netzgebundene Client-Server-Architekturen unter Nutzung des Internets konzipieren und realisieren. Bei diesem Architekturprinzip erfolgt die Datenhaltung zentral auf einem Server und die verschiedenen Nutzer greifen über das Internet oder über ein anderes Netzwerk mittels eines speziellen an das Betriebssystem angepassten Client-Programms auf die Daten zu. Diese Lösung verlangt aber nach einer ständigen Netzwerkverbindung und ist nur für ein beschränktes Datenvolumen sinnvoll. Dieses Architekturprinzip wird häufig bei der Realisierung von Internetinformationssystemen eingesetzt, bei denen die Datenhaltung in Datenbanksystemen und die Präsentation der Daten über dynamische Web-Technologien wie PHP/HTML erfolgt. Dort, wo eine zentrale Datenhaltung nicht möglich oder sinnvoll erscheint, bleibt nur die Möglichkeit, die Arbeitsergebnisse am Ende der Bearbeitung in einer Datei zu speichern, welche dann von den anderen Applikationen gelesen werden kann. Da Textdateien zumeist die kleinste gemeinsame Basis der verschiedenen Betriebssysteme darstellen, werden diese häufig zum Austausch von Daten verwendet. Damit Daten aber zwischen Applikationen erfolgreich ausgetauscht werden können, bedarf es Festlegungen, wie die komplexen Anwendungsdaten einer Applikation in einer linearisierten Textdatei repräsentiert werden. Erst diese Festlegung erlaubt es einer anderen Applikation, die in der Textdatei repräsentierten Daten in die eigenen internen Datenstrukturen zu überführen. Austauschformate sind dabei feste Regelwerke, die es ermöglichen, Daten zwischen verschiedenen Applikationen auszutauschen. Die nachfolgende Abb. 2.3 zeigt den Auszug aus so einer Textdatei. Es handelt sich dabei um eine Edit Decision List (EDL), also eine Auflistung sämtlicher Clips und Schnittpunkte eines Videoschnittprojektes. Mit etwas Übung ist das durch die EDL-Datei beschriebene Videoschnittprojekt zu erkennen. Es handelt sich um einen Film, welcher aus sieben Clips besteht. Jeder Clip wird dabei durch vier Zahlenkolonnen beschrieben. Die ersten beiden Zahlenkolonnen beschreiben über den

2.4 XML-gestützte Anwendungsentwicklung

Austauschformate

■ ■ ■

117

Abb. 2.3: Eine EDL-Datei eines Videoschnittprojektes

11

Timecode die Position des Clips auf dem Videoband (welches von der Videoschnittsoftware unter dem Namen Videoschnitt SS05 verwaltet wird) und die letzten beiden Zahlenkolonnen die Position des Materials im fertig geschnittenen Film. Weiterhin ist der Name eines jeden Clips in der EDL-Datei verzeichnet. Diese Art des Austausches von Daten birgt jedoch verschiedene Probleme in sich. Zum einen stellt sich die Frage, welche Syntax genau verwendet wird und wo und wie diese spezifiziert ist. Jeder der solche EDLs erstellt oder auswertet, muss diese Spezifikation zwangsläufig kennen. Zum anderen ist der Aufwand für die Überprüfung sehr groß, denn vor dem Import muss die zu importierende Textdatei auf Fehlerfreiheit kontrolliert werden. Der Aufwand zur Programmierung des Quelltextes zur Validierung der zu importierenden Datei stellt einen nicht zu unterschätzenden Aufwand dar. In der Praxis ist jedoch der Aspekt von viel größerer Bedeutung, dass z. T. die einzelnen Daten

11

118

■ ■ ■

Der Timecode stellt eine Zeitangabe dar. Aus ihm können die Angaben zur Stunde, Minute, Sekunde und zum Sekundenbruchteil, gemessen in Bildern, abgelesen werden. Ein Timecode kann genutzt werden, um die Dauer einer Videosequenz oder die Position eines Bildes der Videosequenz auf dem Videoband exakt zu beschreiben.


sehr kryptisch codiert sind und so bei Bedarf von Menschen nur bedingt decodiert werden können. XML bietet sowohl als Spezifikationstechnik als auch als Datenformat in diesem Zusammenhang viele Vorteile. Als Erstes bietet es mit der Dokumenttyp-Definition bzw. der Schema-Definition die Möglichkeit, den syntaktischen Rahmen für die auszutauschende Textdatei exakt vorzugeben. Dies reduziert den Aufwand für die Programmierung entsprechender Export- bzw. Importfilter ungemein, da es dabei nicht mehr notwendig ist, den Fehlerbehandlungscode für den Import entsprechender Textdateien selbst zu realisieren, sondern es können vorgefertigte Applikationen, sogenannte Parser, genutzt werden, die als Bibliotheken für die verschiedenen Programmiersprachen wie Java, C++, PHP etc. verfügbar sind. Diese Parser können vor der Verarbeitung der XML-Datei die syntaktische Korrektheit der zu importierenden Datei überprüfen. Dabei können zwei Konformitätsstufen unterschieden werden. Dies ist zum einen die Wohlgeformtheit, welche besagt, dass das Textdokument eine syntaktisch korrekte XML-Datei ist, und zum anderen die Validität, welche besagt, dass das XML-Dokument sowohl syntaktisch korrekt ist als auch die inhaltlichen Vorgaben der Dokumenttyp-Definition bzw. der Schema-Beschreibung erfüllt. Ein weiterer Vorteil der Anwendungsentwicklung auf Basis von XML liegt in der Möglichkeit, entsprechende Bibliotheken nutzen zu können, welche Funktionen bereitstellen, mit denen XML-Dokumente traversiert werden können. Im Falle von Textdokumenten müssen die Anwendungsentwickler sich den Inhalt der zu importierenden Textdatei selbst erschließen, d. h., sie müssen den Inhalt der Textdatei byte- oder zeilenweise einlesen und diesen in die verschiedenen syntaktischen Einheiten zerlegen. Für XML existieren entsprechende Funktionen als Bibliotheken, so dass die Entwickler sich auf die Programmierung höher liegender Anwendungslogik konzentrieren können. Mit Hilfe des Document Object Model, kurz DOM, wird ein XML-Dokument als Baumstruktur im Speicher des Rechners abgelegt und über entsprechende Pfadangaben innerhalb dieser Baumstruktur kann gezielt auf den Inhalt 12 eines jeden Elementes zugegriffen werden. Beim SAX -Ansatz wird das XML-Dokument elementweise abgearbeitet und das Erreichen bspw. einer Start- bzw. Endmarke löst ein gewisses Ereignis aus, auf das der Entwickler dann mit seiner eigenen Anwendungslogik reagieren kann. Abbildung 2.4 stellt einen Auszug aus einer Textdatei dar, welche das gleiche Videoschnittprojekt repräsentiert, das bereits für die Erstellung der in der Abb. 2.3 dargestellten EDL-Datei benutzt wurde. Doch dieses Mal wurde das Videoschnittprojekt nicht als EDL-Datei, sondern als Apple Interchange Format exportiert. Das Apple Inter12

XML-basierte Austauschformate

SAX steht für „Simple API for XML“.


■ ■ ■

119

Abb. 2.4: Auszug aus einer Apple-InterchangeFormat-Datei

IDB Hymne 4512 FALSE 25 FALSE 25 01:00:00:00 90000 source NDF -1 -1 720 576 FALSE PAL-CCIR-601 lower FALSE 25 24 Apple DV - PAL ...

change Format ist ein XML-basiertes Format und verfügt daher über die zuvor erläuterten Vorteile bei der maschinengestützten Verarbeitung. Des Weiteren enthält es gegenüber der EDL-Datei auch noch viele weitere Angaben zu dem Videoschnittprojekt, welche in der EDL-Datei gar nicht enthalten sind. So wird z. B. durch die Marke erkennbar, dass es sich bei dem Videoschnittprojekt um

120

■ ■ ■


Intro 575 FALSE 25 0 575 0 575 3937 TRUE FALSE none Intro 0 ...

ein Projekt handelt, welches mit einer Bildrate von 25 Bildern pro Sekunde arbeitet. Weiterhin ist durch die Marken und die Bildgröße erkennbar, in dem Videoschnittprojekt werden PAL-Videosequenzen mit 720 × 576 Bildpunkten erzeugt. Abbildung 2.5 zeigt einen anderen Ausschnitt aus der AppleInterchange-Format-Datei, an dem die Verwendung von XML zur Codierung von Daten mitsamt der zugehörigen Metadaten näher beschrieben werden soll. In dem Auszug aus der exportierten XML-Datei in Abb. 2.4 sind verschiedene Metadaten zu dem Videoschnittprojekt erkennbar. So kann bspw. aus dem Element die Dauer des Films abgelesen werden. Es handelt sich dabei um 4512 Bilder. Aus der Angabe 25 des Elements kann geschlossen werden, dass es sich um eine Filmlänge von 4512 Bildern – bei 25 Bilder pro Sekunde –, also von 3 Minuten und 0,5 Sekunden handelt. Abbildung 2.5 kann zudem entnommen werden, dass der Clip Intro insgesamt 575 Bilder (23 Sekunden) lang ist (Marke ) und über keinen AlphaKanal verfügt (Marke ). An diesen Auszügen aus der XML-Datei, welche ein Videoschnittprojekt repräsentiert, kann man leicht die Selbstbeschreibungsfähigkeit von XML demonstrieren. Obwohl die meisten Leser mit dem Apple Interchange Format nicht vertraut sein dürften, fällt es dem geübten Leser recht leicht, aus den einzelnen Marken deren Bedeutung herauszulesen. Als Konsequenz sind XML-Dateien im Vergleich zu anderen


Abb. 2.5: Beschreibung des Clips Intro durch XML-Marken

Selbstbeschreibungsfähigkeit

■ ■ ■

121

13

Austauschformaten, wie bspw. CSV für tabellarische Daten, sowohl für Menschen wie auch für Maschinen gleicherweise les- und interpretierbar. Dies gilt allerdings nur dann, wenn für die Namen der Marken sprechende Bezeichnungen gewählt wurden. Das heißt die XML-Marken können nicht nur genutzt werden, um die auszutauschenden Daten eindeutig zu begrenzen und zu strukturieren, sie können zugleich in Form von Metadaten den Daten auch noch eine Bedeutung verleihen. Nimmt man alle diese Eigenschaften von XML zusammen, so erklärt sich, warum XML-basierte Austauschformate verstärkt für den Austausch von Daten über Programm- und Systemgrenzen hinweg eingesetzt werden. Dabei spielt es auch keine Rolle, ob die XMLDateien über Datenträger zwischen den einzelnen Applikationen ausgetauscht werden oder ob die XML-codierten Daten über Netzwerke zwischen verteilten Applikationen versendet werden.

2.4.2 Serialisierung von Objekten

Serialisierung von Objekten

Eine weitere Problematik, die auch im Zusammenhang mit Austauschformaten von Bedeutung ist, ist die Serialisierung von Objekten. Moderne Softwareentwicklungen basieren zumeist auf dem Paradigma der Objektorientierung, das heißt, dass Daten und die sie verändernden Methoden in einem Objekt gekapselt sind. Dieses Grundprinzip lässt sich iterieren, was bedeutet, dass Objekte wiederum andere Objekte beinhalten können. Als Folge davon können mehrstufige Objektstrukturen entstehen. Wann immer Objekte zwischen zwei Applikationen ausgetauscht werden sollen, die keinen gemeinsamen Speicher besitzen, ist die Serialisierung und spätere Deserialisierung des Objekts erforderlich. Dies ist beispielsweise auch notwendig, wenn Objekte persistent gespeichert werden sollen, z. B. in einem Dateisystem einer Festplatte oder mittels einer relationalen Datenbank. Dann müssen diese Objekte zuvor serialisiert werden, da weder das Dateisystem noch die relationale Datenbank in der Lage sind, hierarchische Objektstrukturen zu speichern. Die Serialisierung von Objekten wird nachfolgend näher ausgeführt. Serialisierung kann als der Prozess zum Speichern des Status einer Objektinstanz auf einem Speichermedium bezeichnet werden. Während dieses Prozesses werden die Attribute des Objekts und der Name der Objektklasse in einen Strom von alphanumerischen Zeichen oder 13

122

■ ■ ■

CSV steht für Comma Separated Values (kommaseparierte Werte) und stellt ein Standard-Austauschformat für alphanumerische Daten dar, welches häufig bei Tabellenkalkulationen zum Einsatz kommt.


Abb. 2.6: Serialisierung und Persistenz

Bytes konvertiert, der dann in einen Datenstrom geschrieben wird. Die nachfolgende Abbildung zeigt das Prinzip der Serialisierung/Deserialisierung schematisiert. Serialisierung bedeutet dabei, dass die hierarchische Struktur der Objekte und deren über Attribute gespeicherte Zustände in eine lineare Abfolge gebracht werden müssen, um in linearen Speichermedien persistent abgelegt oder über lineare Netzwerkstrukturen übertragen werden zu können. Die mehrstufigen Objektstrukturen müssen dazu aufgelöst und jedes Objekt inklusive seiner Attribute muss in eine lineare Abfolge gebracht werden, um es zum Beispiel in Form von Buchstaben in den Zeilen einer Textdatei ablegen zu können. Relevant in diesem Zusammenhang sind nur die Attribute der Objekte, da diese den Zustand des Objektes codieren. Die Methoden des Objektes müssen nicht serialisiert werden, da diese durch die Klassenbeschreibung festgelegt sind und sich während der Existenz des Objektes ja nicht verändern können. Alleinig die Information, welche Objekte mit welchem inneren Zustand zum Zeitpunkt des Speicherns in der Applikation existent waren, gilt es, persistent zu sichern. Diese Informationen reichen dann aus, um später beim Deserialisieren die Applikation in genau den Zustand zu versetzen, in dem sich die Applikation zum Zeitpunkt der Speicherung befunden hat. Es werden quasi Klone der Objekte erzeugt, welche sich zum Speicherzeitpunkt im Speicher befunden haben. Wie ausgeführt drückt sich der Zustand eines Objektes durch dessen Attribute aus. Ein Attribut ist dabei gekennzeichnet durch einen eindeutigen Namen und einen zugeordneten Wert. Die Reihenfolge der Attribute eines Objektes ist dabei nicht von Bedeutung. Beim Serialisieren müssen also die Informationen erhalten bleiben, welche Objekte zum Zeitpunkt des Speicherns existieren und welche Attribute (Namen) und welche Werte diese Attribute besitzen.


Zustand eines Objektes

■ ■ ■

123

Abb. 2.7: Zulässige Strukturierung von XML-Elementen

Abb. 2.8: Nicht zulässige Strukturierung von XML-Elementen

Serialisierung von Objekten mittels XML

Nimmt man eine in der Praxis unbedeutende Einschränkung in Kauf, so kann die Serialisierung von Objekten sehr einfach und elegant mittels XML-Technologien erfolgen. Das bei XML verwendete Inhaltsmodell erlaubt Unterelemente im Inhalt eines Elementes mit der Einschränkung, dass jedes Element sich vollständig im Inhalt des anderen Elementes befinden muss. Sich überlappende Elemente sind durch das Inhaltsmodell von XML ausgeschlossen. Die Abb. 2.7 veranschaulicht, eine zulässige Strukturierung von Elementen eines XML-Dokumentes. Nicht zulässig ist hingegen die in der Abb. 2.8 dargestellte Strukturierung von XML-Elementen. Als Konsequenz muss von Objektstrukturen, die mittels XML serialisiert werden sollen, verlangt werden, dass sie streng hierarchisch strukturiert sind. Ist dies der Fall, so kann jede beliebige Objektstruktur nach folgendem Verfahren serialisiert werden: 1. Jedes Objekt wird in ein XML-Element gewandelt, welches den Namen des Objektes trägt. 2. Besitzt das Objekt Attribute, so wird jedes Attribut zu einem Unterelement gleichen Namens. a. Besteht der Attributwert aus einem simplen Datentyp, so wird der Attributwert in den Inhalt des Unterelementes übernommen. b. Besteht der Attributwert aus einem Objekt, so ist mit dem Unterobjekt wie in 1.) beschrieben zu verfahren. Die nachfolgende Abb. 2.9 und Abb. 2.10 veranschaulichen das beschriebene Verfahren. In der Abb. 2.9 ist eine Objektbeschreibung in PHP-Syntax zu sehen, während Abb. 2.10 die nach dem beschriebenen Verfahren erstellte serialisierte Darstellung dieser PHP-Objektbeschreibung in Form einer XML-Datei zeigt. Das beschriebene Prinzip der Objektserialisierung findet in einigen objektorientierten Programmierumgebungen Anwendung. So existieren zum Beispiel in dem NET-Framework von Microsoft Klassenbibliotheken, um Objekte als Bytestrom, als SOAP-Datei oder als XML-

124

■ ■ ■


class Person { var $Vorname, $Nachname; var $Nachkomme;

Abb. 2.9: PHP-Objektdefinitionen

function Person ($new_firstname, $new_lastname){ $this->Vorname = $new_firstname; $this->Nachname = $new_lastname; } function get_name (){ $full_name = $this->Vorname." ". $this->Nachname; return $full_name; } function set_name ($new_firstname, $new_lastname) { $this->Vorname = $new_firstname; $this->Nachname = $new_lastname; } function set_child ($new_child) { $this->Nachkomme = $new_child; } } $Pebbles =& new Person ('Pebbles', 'Feuerstein'); $Fred = new Person('Fred', 'Feuerstein'); $Fred->set_child ($Pebbles);

Fred Feuerstein Pebbles Feuerstein

O:6:"person":3:{s:7:"Vorname";s:4:"Fred";s:8: "Nachname"; s:10:"Feuerstein";s:9:"Nachkomme";O:6:"person":3:{s:7:"Vornam e";s:7:"Pebbles";s:8:"Nachname";s:10:"Feuerstein";s:9:"Nachko mme";N;}}


Abb. 2.10: Serialisierte Objektdarstellung in XML

Abb. 2.11: Ergebnis der Serialisierung durch die PHP-Funktion serialize()

■ ■ ■

125

Dokument zu serialisieren. Auch Java kennt das Prinzip der Objektserialisierung und stellt zum Schreiben und Lesen von Objekten in Streams die Klassen ObjectInputStream und ObjectOutputStream bereit. In PHP wird die Serialisierung von Objekten vorwiegend im Zusammenhang mit Session genutzt. Durch die Serialisierung von Objekten kann eine Session auf der Festplatte gespeichert werden und zu einem späteren Zeitpunkt wieder gelesen und dann in dem gespeicherten Zustand fortgesetzt werden. Die Routinen zum Serialisieren/ Deserialisieren lauten in PHP serialize() bzw. unserialize(). Die nachfolgende Abb. 2.11 zeigt das Ergebnis der Serialisierung des Objektes $Fred aus Abb. 2.9. Zumeist wird von den Programmierern die Erzeugung von Byteströmen bevorzugt, da diese sehr kompakt sind und so nur wenig Speicherplatz bzw. Netzbandbreite verbrauchen. Bei Verwendung von XML anstatt von Byteströmen könnten aber die grundlegenden Vorteile von XML, die Selbstbeschreibungsfähigkeit, die Plattformunabhängigkeit und die Validierbarkeit, auch bei der Objektserialisierung zum Tragen kommen, deshalb ist in der Regel bei plattformübergreifenden, nicht zeitkritischen Anwendungen XML als Format für die serialisierten Daten dem Bytestrom vorzuziehen. Dieser Vorteil wird offenkundig, wenn man die beiden Abb. 2.10 und Abb. 2.11 vergleicht. Beide Darstellungen zeigen eine Serialisierung des Objektes $Fred aus der Abb. 2.9. Während das ungeschulte Auge sowohl Struktur als auch den Objektinhalt aufgrund der Selbstbeschreibungsfähigkeit von XML aus Abb. 2.10 recht gut erfassen kann, so sind die serialisierten Daten aus Abb. 2.11 ohne Abbildungsvorschrift nur bedingt wieder von Hand zu deserialiseren.

2.5 Trennung der Implementierungslogik und Präsentation einer Anwendung 2.5.1 Servlets und XSL Die Java-Servlet-Spezifikation bietet eine Möglichkeit zur Entwicklung HTTP-basierter Client-Server-Applikationen. Die Anwendung wird dabei in einem Container ausgeführt, für welchen es verschiedene Implementierungen gibt. Das nachfolgend beschriebene Beispiel wurde auf der Basis der Tomcat-Implementierung entwickelt. Prinzipiell funktioniert der Zugriff eines Clients auf den in einem Container laufenden Server nach folgendem Muster:

126

■ ■ ■


Abb. 2.12: Zugriff eines Clients auf eine Servletbasierte Applikation via HTTP

Bei einem HTTP-Zugriff ruft der Servlet-Container die doGet-Methode der Servlet-Applikation auf und übergibt dieser zwei Parameter: 1. Der HttpServletRequest enthält Parameter des Client-Zugriffs wie z. B. Key/Value-Paare von HTML-Formulardaten. 2. Der HttpServletResponse erlaubt das Setzen von HTTP-Parametern für die Antwort an den Web-Client. Beispielsweise kann der Typ einer dynamisch generierten Grafik auf appli-cation/pdf gesetzt werden.

2.5.2 Eine Beispielapplikation Wir wollen eine Applikation entwickeln, welche einem Client das aktuelle Datum und die aktuelle Zeit in einer Menge vordefinierter LocaleVarianten zurückliefert: Abb. 2.13: Länderspezifische Ausgabe von Zeitund Datumsangaben

Die Daten selbst können als Tabellenstruktur gewählt werden. Prinzipiell eignet sich dafür das aus Swing bekannte TableModelInterface. Da wir nur lesenden Zugriff betrachten, genügt es, wenn unser Servlet das nachfolgend beschriebene Interface implementiert: public interface SimpleTableModel { /** * @see javax.swing.table.TableModel#getColumnCount() .

2.5 Trennung der Implementierungslogik und Präsentation einer Anwendung

■ ■ ■

127

* @return number of colums. */ public int getColumnCount(); /** * @see javax.swing.table.TableModel#getColumnName(int n) . * @param columnIndex the index of the column's name to be returned. * @return name of n-th column. */ public String getColumnName(int columnIndex); /** ... / public int getRowCount(); public Object getValueAt(int rowIndex, int columnIndex); public Class getColumnClass(int column); }

Um die geforderte Trennung zwischen Implementierung und Präsentation zu erreichen, verwenden wir ein XSL-Stylesheet zur Formatierung. Dies ermöglicht unter Verwendung von Formatting Objects das Anbieten verschiedener Ausgabeformate an den Client. In unserem Beispiel werden wir sowohl HTML als auch PDF anbieten. Dazu realisieren wir folgende Architektur: Abb. 2.14: Di Servlet Struktur zur Erzeugung unterschiedlicher Sichten auf Tabellenobjekte

Wie wandeln also die im SimpleTableModel enthaltenen Daten zunächst in einen XML-Baum um. Als Darstellung in Java bietet sich das Document Object Model (DOM) an. Dieser XML-Baum kann dann mittels XSL sowohl in das HTML-Format als auch unter Zuhilfenahme von Formatting Objects in ein PDF-Dokument transformiert werden.

128

■ ■ ■


2.5.3 Die Implementierung der Anwendungslogik Unser Servlet benötigt die Möglichkeit, Datumsformate für verschiedene Länder definieren zu können. Wir erreichen dies durch einen Konstruktor, welcher als Parameter ein Array aus Locale-Objekten erhält: public class DateLocaleTable implements SimpleTableModel { public DateLocaleTable(final Locale localeSet[]) { this.localeSet = localeSet; } private final Locale localeSet[]; ...

Abb. 2.15: Die Implementierung mit einem Konstruktor zur Definition der gewünschten Menge von länderspezifischen Formaten aus Locale Objekten

Die Implementierung der SimpleTableModel-Methoden ist übersichtlich: public class DateLocaleTable implements SimpleTableModel { ... public int getColumnCount() { return columnHeaders.length; } public String getColumnName(int columnIndex) { return columnHeaders[columnIndex]; } public int getRowCount() { return localeSet.length; }

Abb. 2.16: Zur Implementierung des Datum Servlets

... private final Date currentDate = new Date(); private final Locale localeSet[]; private final static String columnHeaders[] = { "Locale", "Datumsformat", "Zeitformat" }; private final static int COLINDEX_LOCALE = 0, COLINDEX_DATUM = 1, COLINDEX_TIME = 2; }

Die vollständige Implementierung ist als Bestandteil eines komplett beschriebenen Eclipse-Projektes dieser Servlet-Applikation inklusive der Konfiguration des Tomcat-Webservers unter nachfolgender Adresse verfügbar:

2.5 Trennung der Implementierungslogik und Präsentation einer Anwendung

■ ■ ■

129

http://fb1.hdm-stuttgart.de/skripte/Dokumenterstellung_1/ vorlesung/noframe_xslServletSetup.html.

2.5.4 Serialisierung des Servlets als DOM-Baum Zur Serialisierung eines SimpleTableModel-Objekts als XML-DOMStruktur kann die unter http://xml.apache.org verfügbare Xerces-Implementierung verwendet werden. Das Erzeugen eines Unterknotens vom Typ Element inklusive eines Text-Unterknotens zu einem bereits vorhandenen Element-Knoten geschieht im DOM durch folgende Schritte: Abb. 2.17: Hinzufügen eines Element-Knotens, welcher einerseits #PCDATA enthält

Dies wird in unserem Serialisierer wie folgt implementiert: Abb. 2.18: Hinzufügen von Unterelementen mit und ohne Textinhalt durch Hilfsmethoden

private Element appendElement(final Element parent, final String tagname){ final Element child = doc.createElement(tagname); parent.appendChild(child); return child; } private Element appendElement(final Element parent, final String tagname, final Object pcdata){ final Element elementChild = appendElement(parent, tagname); elementChild.appendChild(doc.createTextNode(pcdata.toString ())); return elementChild; }

130

■ ■ ■


Die beiden überladenen Methoden fügen einem vorhandenen Parent Knoten einen neuen erzeugten Unterknoten vom Typ Element hinzu, welcher als Returnwert zurückgeliefert wird. Zusätzlich fügt die zweite Methode noch einen Unterknoten vom Typ Text hinzu. Dies entspricht einem Element mit Content Model #PCDATA. Über diese zwei Hilfsmethoden kann nun die Serialisierung beliebiger SimpleTableModel-Instanzen in einer Klasse TableSerializer implementiert werden:

public class TableSerializer { ... private void set(final SimpleTableModel tableModel){ doc = docCreator.createDocument(null, "table", null); final Element table = doc.getDocumentElement(); table.setAttribute("class", tableModel.getClass().getName()); final Element head = appendElement(table, "head"); for (int colIndex = 0; colIndex < tableModel.getColumnCount(); colIndex++){ final Element column = appendElement( head, "column", tableModel.getColumnName(colIndex)); column.setAttribute("class", tableModel.getColumnClass(colIndex).getName()); } final Element body = appendElement(table, "body"); for (int rowIndex = 0; rowIndex < tableModel.getRowCount(); rowIndex++){ final Element row = appendElement(body, "row"); for (int colIndex = 0; colIndex

Kompendium Medieninformatik: Medienpraxis GERMAN

Kompendium Medieninformatik: Medienpraxis (X.Media.Press)

Kompendium Medieninformatik: Mediennetze (X.media.press)

Java 2 Kompendium GERMAN

Kompendium Multimediales Lernen GERMAN

Energieausweis - Das große Kompendium GERMAN

Windows XP Home Kompendium GERMAN

Adobe Photoshop CS3 Kompendium GERMAN

Windows 2000 Server - Kompendium GERMAN

Microsoft Office. Access 2003. Kompendium. GERMAN

Microsoft Office Outlook 2003 Kompendium GERMAN

Word 2002 - Kompendium. Schreiben, gestalten, publizieren GERMAN

Microsoft Office Word 2003 Kompendium GERMAN

Das C++ Kompendium: STL, Objektfabriken, Exceptions GERMAN

Kompendium Informationsdesign

Trojaner Kompendium

C# Kompendium

Druckluft-Kompendium

Hardware Kompendium

Trojaner Kompendium

C# Kompendium

Microsoft SQL Server 7.0 - Kompendium . Für Administration und Entwicklung GERMAN

Access 2002 - Kompendium. Datenbanken planen, entwickeln, optimieren GERMAN

Moderne C-Programmierung: Kompendium und Referenz (Xpert.press) (German Edition)

MiFID-Kompendium: Praktischer Leitfaden für Finanzdienstleister (German Edition)

Kompendium der Web-Programmierung: Dynamische Web-Sites (X.media.press) German

Excel 2002 - Kompendium. Professionell analysieren und planen GERMAN

Kompendium Katekismus Gerejakatolik

Adobe InDesign CS Kompendium

Kompendium Ajaran Sosial Gereja

Leczenie w neurologii: kompendium

Kompendium Medieninformatik: Medienpraxis GERMAN

Kompendium Medieninformatik: Medienpraxis (X.Media.Press)

Kompendium Medieninformatik: Mediennetze (X.media.press)

Java 2 Kompendium GERMAN

Kompendium Multimediales Lernen GERMAN

Energieausweis - Das große Kompendium GERMAN

Windows XP Home Kompendium GERMAN

Adobe Photoshop CS3 Kompendium GERMAN

Windows 2000 Server - Kompendium GERMAN

Microsoft Office. Access 2003. Kompendium. GERMAN

Microsoft Office Outlook 2003 Kompendium GERMAN

Word 2002 - Kompendium. Schreiben, gestalten, publizieren GERMAN

Microsoft Office Word 2003 Kompendium GERMAN

Das C++ Kompendium: STL, Objektfabriken, Exceptions GERMAN

Kompendium Informationsdesign

Trojaner Kompendium

C# Kompendium

Druckluft-Kompendium

Hardware Kompendium

Trojaner Kompendium

C# Kompendium

Microsoft SQL Server 7.0 - Kompendium . Für Administration und Entwicklung GERMAN

Access 2002 - Kompendium. Datenbanken planen, entwickeln, optimieren GERMAN

Moderne C-Programmierung: Kompendium und Referenz (Xpert.press) (German Edition)

MiFID-Kompendium: Praktischer Leitfaden für Finanzdienstleister (German Edition)

Kompendium der Web-Programmierung: Dynamische Web-Sites (X.media.press) German

Excel 2002 - Kompendium. Professionell analysieren und planen GERMAN

Kompendium Katekismus Gerejakatolik

Adobe InDesign CS Kompendium

Kompendium Ajaran Sosial Gereja

Leczenie w neurologii: kompendium

Recommend Documents