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
schmitz@hdm-stuttgart.de
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.

1.1 Modellierung virtueller Welten

■
■
■

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

■
■
■

1 Computergrafik und Virtual Reality

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.

1.1 Modellierung virtueller Welten

■
■
■

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

■
■
■

1 Computergrafik und Virtual Reality

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

1.1 Modellierung virtueller Welten

■
■
■

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

■
■
■

1 Computergrafik und Virtual Reality

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

1.1 Modellierung virtueller Welten

■
■
■

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

■
■
■

1 Computergrafik und Virtual Reality

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

1.1 Modellierung virtueller Welten

■
■
■

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

■
■
■

1 Computergrafik und Virtual Reality

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.

1.1 Modellierung virtueller Welten

■
■
■

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

■
■
■

1 Computergrafik und Virtual Reality

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.

1.1 Modellierung virtueller Welten

■
■
■

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<u1<...<un.
Weiter sei I=[a,b] ein Intervall. Für jedes i=0,…,n definieren wir das
folgende Polynom vom Grad n (i-tes Lagrange-Polynom vom Grad n):
Die Interpolationsaufgabe ist durch
n

p(u) = ∑ Lni (u)Pi , u ∈ [a, b ]
i =0

eindeutig gelöst. Außerdem ist ∑0≤i≤n Li (u)=1, d. h., die Kurve ist affin
invariant.
Diese Tatsache ist leicht einzusehen. Zentral ist die Eigenschaft der
Lagrangepolynome, dass
n

⎧1 i = k
Lni (uk ) = δ ik = ⎨
⎩0 sonst
Damit scheinen wir alle Punkte erreicht zu haben. Leider ist die
Kurve nicht einfach zu ermitteln und muss nach der Definition gerechnet werden. Kommt ein neuer Knotenpunkt hinzu, so ändert sich
komplett die Form der Lagrangepolynome.

16

■
■
■

1 Computergrafik und Virtual Reality

Beispiel: Gegeben seien drei Knoten (ui,Pi) i=0,1,2 mit (0,(1|0)),
(1,(−1|0)) und (3,(3|3)). Die Lagrangepolynome sind dann
(u − 1)(u − 3) u2 − 4u + 3
=
(0 − 1)(0 − 3)
3
u(u − 3)
L21 (u) =
−2
u
(
u
− 1)
L22 (u) =
6
L20 (u) =

und die Interpolationskurve ist durch
⎛ 1 ⎞ u2 − 4u + 3 ⎛ −1 ⎞ u(u − 3) ⎛ 3 ⎞ u(u − 1)
p(u) = ⎜ ⎟
+⎜ ⎟
+⎜ ⎟
3
⎝0⎠
⎝ 0 ⎠ −2
⎝ 3⎠ 6
gegeben. Der Kurvenverlauf ist in Abb. 1.11 dargestellt.
Versucht man mit diesen Kurven Objekte zu modellieren, so stellt
man leicht fest, dass diese Kurven ihre Form stark ändern, wenn ein
(Interpolations-)Punkt verschoben wird. Leider ändert sich die Form
der Kurve auch nicht immer in Richtung der Verschiebung des Punktes. Zudem kann am Anfang und Ende der Kurve die Steigung nicht
vorgegeben werden, was ein „glattes“ Aneinanderfügen von Kurvenstücken sehr schwer macht.
Abb. 1.11:
Beispiel einer Lagrangekurve

1.1.2.4
Interpolationsaufgabe, Hermitekurven
Da Kurvensegmente in der Monom- und Lagrangebasis in der Regel
0
nur mit C -Stetigkeit aneinandergefügt werden können, sind diese
1
Basen nicht für stückweise C -stetige Interpolation geeignet.

1.1 Modellierung virtueller Welten

■
■
■

17

Für diesen Fall bieten sich z. B. kubische Hermite-Splines an:
Sind die Parameterwerte t0, t1 ,..., tn∈ ℝ, die dazugehörigen Punkte
d
p0 , p1 ,..., pn∈ ℝ und in den Knotenpunkten die Ableitungen m0, m1 ,...,
d
mn∈ℝ gegeben, so erfüllen folgende Segmente qi , i=0,...,n-1 die Interpolationsaufgabe:

qi (u) = pi H 03 (si ) + Δ i mi H13 (si )
+ Δi mi+1 H 23 (si ) + pi+1 H 33 (si ) , u ∈[t i ,t i+1 ]
wobei
si =

(u − t i )
Δ i = t i+1 − t i
(t i+1 − t i )

Die Polynome H 03 , H13 , H 23 und H 33 heißen Hermitepolynome vom
Grad 3. Den Parameter u nennt man globalen Parameter des Splines
und Parameter si heißt lokaler Parameter für das Intervall [ti,ti+1]. Die
vier kubischen Hermitepolynome über dem Intervall [0,1] sind in
Abb 1.12 definiert.
Abbildung 1.13 zeigt einige Beispiele von kubischen Hermitekurven.
Dennoch gibt es bei dieser Art von Interpolationskurven ein Problem: Oft hat man die Tangenten mi nicht alle explizit gegeben.
Abb. 1.12:
Die vier kubischen Hermitepolynome

Abb. 1.13:
Beispiele kubischer Hermitekurven

18

■
■
■

1 Computergrafik und Virtual Reality

Abb. 1.14:
Vorgabe der Tangenten an allen
Stützstellen

Trick: Berechne die fehlenden Tangenten aus Stützstellen. Die Tangentenrichtung mi im Punkt Pi wird parallel zur Sehne durch Pi-1 und
Pi+1 gewählt. Der entstehende Interpolant wird auch als Catmull-RomSpline bezeichnet (FMILL-Schätzung).
Mit Hermite-Interpolationskurven ist einfach und intuitiv zu modellieren. Jedoch ist die explizite Angabe der Steigungstangenten der
Kurve in der Praxis oft ein Problem.
1.1.2.5
Bézierkurven

Wieder sind wir auf der Suche nach einem Satz von Polynomfunktion
nen als Basis des P ([s,t]). Dafür betrachten wir das Intervall [s,t] und
berechnen:

(t − s)n = (t − u + u − s)n
n
⎛n⎞
= ∑ ⎜ ⎟(t − u)i (u − s)n−i
i =0 ⎝ i ⎠

Wir können abkürzend schreiben:
t
s

Bin (u) =

1 ⎛n⎞
(t − u)i (u − s)n−i , i = 0,..., n .
n ⎜ ⎟
i
(t − s) ⎝ ⎠

Dies sind n+1 Polynome vom Grad n über dem Intervall [s,t] und
aus der Definition ergibt sich direkt, dass
n

1 = ∑ st Bin (u), für alle u ∈[s,t ].
i =0

Diese n+1 Polynome heißen Bernsteinpolynome vom Grad n über
dem Intervall [s,t]. Häufig wählt man das Einheitsintervall [0,1] und
n
schreibt einfacher Bi . Es kann gezeigt werden, dass diese n+1 Poly-

1.1 Modellierung virtueller Welten

Bernsteinpolynome

■
■
■

19

nome linear unabhängig sind und daher eine Basis des Polynomraums
n
P ([s,t]) bilden.
Viele weitere Eigenschaften der Bernsteinpolynome sind einfach
aus der Definition nachzurechnen:
n

∑

t
s

Bin (u) = 1, für u ∈[s,t ]

Partition der Eins

t
s

Bin (u) ≥ 0, für u ∈[s,t ]

Positivität

i =0

u − s t n−1
t − u t n−1
s Bi −1 (u) +
s Bi (u) Rekursion
t −s
t −s
t n
t
n
Symmetrie
s Bi (u) = s Bn−i (t − (u − s ))
t
s

Bin (u) =

t
s

Bin (s) = 0 = ts Bin (t ), ts B0n (s) = 1 =ts Bnn (t ), ts B0n (t ) = 0 = ts Bnn (s)

max ts Bin (u) = ts Bnn−i (i / n)

Für den Fall n=4, s=0 und t=1 ergeben sich die folgenden Bern4
3
2 2
4
4
4
4
steinpolynome B0 = (1–u) , B1 = 4(1–u) u, B2 = 6(1–u) u sowie B3 =
3
4
4
4(1–u)u und B4 = u :
Abb 1.15:
Bernsteinpolynome vom Grad 4 über
dem Intervall [0,1]

Diese Basisfunktionen sind nun Ausgangspunkt für folgende Definition einer Bézierkurve: Sei mit I=[s,t] ein Intervall und b0, b1,...,bn
d
∈ ℝ Punkte gegeben, dann heißt
n

p(u) = ∑ bi ⋅ st Bin (u), u ∈[s,t ]
i =0

Bézierkurve vom Grad n. Die Punkte b0, b1,...,bn heißen Bézierd
punkte und definieren zusammen das Bézierpolygon in ℝ .

20

■
■
■

1 Computergrafik und Virtual Reality

Beispiel: b0=(1|0), b1=(0|2), b2=(1|5.5), b3=(6|5.5), b4=(7.5|0.5) seien
Bézierpunkte in der Ebene. Wir wählen das Einheitsintervall als Parametervorrat. Die Bézierkurve ist dann durch
4

3

2

2

p(u)=(1|0) (1-u) + (0|2) 4 (1-u) u + (1|5.5)6 (1-u) u
3
4
+ (6|5.5) 4(1-u)u + (7.5|0.5) u
gegeben. Das Schaubild sieht folgendermaßen aus:

Aus den oben genannten Eigenschaften der Bernsteinpolynome
können sofort elementare Eigenschaften der Bézierkurven abgeleitet
werden.
Die erste Eigenschaft (Partition der Eins) zusammen mit der Positivität der Bernsteinpolynome zeigt direkt die affine Invarianz der
Bézierkurven. Außerdem schließen wir daraus auch, dass die Bézierkurve innerhalb der konvexen Hülle der Bézierpunkte verläuft, und
zwar als Konvexkombination der Bézierpunkte.
Die Bézierkurve verläuft durch Anfangs- und Endpunkt b0 und bn.
Dies folgt aus den vorletzten Eigenschaften der Bernsteinpolynome,
die die Werte 0 und 1 genau an den Grenzen des Parameterintervalls
annehmen.
Betrachtet man die Ableitung einer Bézierkurve am Anfang und
Ende, so ist leicht zu zeigen, dass die respektiven Ableitungen durch

p′(s) =

n
n
(b1 − b0 ) und p′(t ) =
(bn − bn−1 )
t −s
t −s

gegeben sind. Dies bedeutet aber, dass die Bézierkurve innerhalb der
konvexen Hülle der Bézierpunkte verläuft und tangential an das
Bézierpolygon ist.

1.1 Modellierung virtueller Welten

■
■
■

21

Abb. 1.16:
Bézierkurve mit Bézierpunkten
und -polygon

Allgemeiner gilt für die i-te Ableitung der Bézierkurve:
p(i ) (s) =

n! i ⎛ i ⎞
1
∑ ⎜ ⎟(−1)i− j b j
(t − s)i (n − i)! j=0 ⎝ j ⎠

p(i ) (t ) =

n! i ⎛ i ⎞
1
∑ ⎜ ⎟(−1) j bn− j
i
(t − s) (n − i)! j=0 ⎝ j ⎠

Konvention: Im Folgenden betrachten wir s=0, t=1, d. h. I=[0,1]
n
1 n
und schreiben einfach Bi (u) statt 0 Bi (u). Im Übrigen kann jederzeit
durch die folgende Abbildungen
u=

u−s
, u ∈[s,t ] bzw. u = s(1 − u) + tu,
t −s

u ∈[0,1]

reparametrisiert werden.
1.1.2.6
Der De-Casteljau-Algorithmus

Bei der Monomdarstellung von Polynomfunktionen haben wir das
Hornerschema zur Berechnung von Funktionswerten der Kurve kennengelernt. Auch im Falle von Bézierkurven existiert nun ein Berechnungsschema, das die schnelle Berechnung von Kurvenwerten erlaubt:
Das Schema nach de Casteljau oder der De-Casteljau-Algorithmus:
d
Seien I=[0,1] und b0, b1 ,..., bn∈ ℝ gegeben und
n

p(u) = ∑ bi Bin (u)
i =0

eine Bézierkurve, dann liefert für jedes u∈I=[0,1] das rekursiv definierte Schema
bi0 (u) = bi

i = 0, ..., n

b (u) = u ⋅ b (u) + (1 − u) ⋅ b (u)
r
i

r −1
i +1

r −1
i

den Funktionswert p(u) = b0n (u).

22

■
■
■

1 Computergrafik und Virtual Reality

r = 1, ..., n, i = 0, ..., n − r

Wir betrachten folgendes Beispiel: Es seien I=[0,1] und die Bézierpunkte b0=(1|0), b1=(0|2), b2=(1|5.5), b3=(6|5.5) und b4=(7.5|0.5) gegeben. Wir suchen den Funktionswert p(u) für u=0.5:
De-Casteljau-Schema

⎛1⎞
b00 (0.5) = b0 = ⎜ ⎟
⎛ 0.5 ⎞
⎝0⎠ 1
b0 (0.5) = ⎜ ⎟
⎛0⎞
⎛ 0.5 ⎞
⎝ 1 ⎠ 2
b0 (0.5) = ⎜
b10 (0.5) = b1 = ⎜ ⎟
⎟
⎛ 0.5 ⎞
⎝ 2⎠ 1
⎝ 2.125 ⎠ ⎛ 1.25 ⎞
b1 (0.5) = ⎜
⎜
⎟
⎟
⎛ 2 ⎞ ⎝ 3 ⎠ ⎛ 2.40625 ⎞
⎛ 1 ⎞
⎝ 3.25 ⎠ 2
0
b1 (0.5) = ⎜
b2 (0.5) = b2 = ⎜ ⎟
⎜
⎟
⎟
⎛ 3.5 ⎞
⎝ 3.875 ⎠ ⎛ 3.5625 ⎞ ⎝ 3.34375 ⎠
⎝ 5.5 ⎠ 1
b2 (0.5) = ⎜ ⎟
⎜
⎟
⎛ 5.125 ⎞ ⎝ 3.6875 ⎠
⎛ 6 ⎞
⎝ 5.5 ⎠ 2
0
b2 (0.5) = ⎜
b3 (0.5) = b3 = ⎜ ⎟
⎟
⎛ 6.75 ⎞
⎝ 3.5 ⎠
⎝ 5.5 ⎠ 1
b3 (0.5) = ⎜
⎟
⎛ 7.5 ⎞
⎝ 2.5 ⎠
b40 (0.5) = b4 = ⎜ ⎟
⎝ 0.5 ⎠

Dieses Schema wird von links nach rechts aufgebaut. Jeweils zwei
untereinander stehende Punkte werden mit Koeffizienten s und (1 – s)
multipliziert und addiert, um einen neuen Wert der nächsten Spalte
zu ergeben. Der gesuchte Funktionswert steht ganz rechts am Ende
dieses Dreiecksschemas. Also ist
⎛ 2.41 ⎞
p( 12 ) = ⎜
⎟
⎝ 3.34 ⎠
Das Schema wird größer, je mehr Bézierpunkte für die Kurve verwendet werden.
1.1.2.7
Unterteilung und Graderhöhung von Bézierkurven

Diesem Schema ist noch mehr zu entnehmen! Dazu betrachten wir die
(i)
Ableitungen der Bézierkurve einmal näher. Die i-te Ableitung p (u)
ergibt sich aus dem De-Casteljau-Schema in der (n-i)-ten Stufe.
p(i ) (u) =

1
n! i ⎛ i ⎞
∑ ⎜ ⎟(−1)i−k bkn−i (u)
(t − s)i (n − i)! k=0 ⎝ k ⎠

1.1 Modellierung virtueller Welten

■
■
■

23

Für die erste Ableitung ist die vorletzte Stufe des Schemas entscheidend:

b00
b10
0
2

b

b30

b01
1
1

b

b21

b02
2
1

b

b03 p ′(u ) =

(

n
b1n −1 (u ) − b0n −1 (u )
(t − s )

)

1. Ableitung

Das De-Casteljau-Schema dient also nicht nur zur Berechnung von
Funktionswerten der Kurve, sondern kann auch für die Berechnung
der Ableitungen verwendet werden.
Eine Besonderheit des De-Casteljau-Algorithmus ist seine unmittelbar geometrische Veranschaulichung. Zur einfacheren Konstruktion wollen wir einmal 4 Bézierpunkte in der Ebene betrachten. Die
einzelnen Konstruktionsebenen sind in Abb. 1.17 farblich markiert.
Abb. 1.17:
Geometrische Konstruktion nach de
Casteljau

Die geometrische Konstruktion in der Ebene ist exemplarisch für
gegebene Bézierpunkte.
2
2
Die Strecke b0 und b1 liegt, wie wir uns überlegt haben, tangential
zur Bézierkurve. Der Funktionswert p(1/2) ist markiert.
Der De-Casteljau-Algorithmus erlaubt es, eine gegebene Bézierkurve
leicht in zwei Bézier-Teilsegmente zu zerlegen. Die neuen Bézierpunkte
der Teilsegmente ergeben sich aus dem oberen und unteren Rand des
Schemas. Dies kann wieder in der Konstruktion dargestellt werden:

24

■
■
■

1 Computergrafik und Virtual Reality

Abb. 1.18:
Zerlegung einer Bézierkurve
in Teilsegmente

Ist also q∈[s,t] ein beliebiger Punkt des Intervalls, so kann die
Bézierkurve in q geteilt werden, und die neuen Bézierpunkte auf den
Teilsegmenten [s,q] und [q,t] ergeben sich aus dem De-CasteljauAlgorithmus wie folgt:

⎧n q n
i
⎪∑ s Bi (u)b0 (q)
⎪ i =0
p(u) = ⎨ n
⎪ t Bn (u)b n −i (q)
q i
i
⎪⎩∑
i =0

s≤u≤q
q≤u≤t

Man beobachtet nun, dass bei mehrmaliger, fortgesetzter Unterteilung der Bézierkurve die Folge der Bézierpolygone gegen die eigentliche Kurve konvergiert. Bei fortgesetzter Halbierung des Parameterintervalls ist diese Konvergenz exponentiell und liefert ein praktisches
Verfahren zur Darstellung einer Bézierkurve durch eine stückweise
lineare Approximation.
Werden zur genaueren Approximation einer geometrischen Figur
durch eine Bézierkurve mehr Bézierpunkte benötigt als vorhanden, so
kann der Grad der Kurve erhöht werden. Bei Erhöhung um einen
Grad wird ein weiterer Kontrollpunkt in das Kontrollpolygon eingefügt, ohne dass sich die geometrische Form der Kurve ändert.
Ist eine Bézierkurve p vom Grad n mit den Bézierpunkten b0, b1,...,bn
d
∈ ℝ gegeben, so ist p als Bézierkurve vom Grad n+1 darstellbar, so
dass gilt:
n

∑b
i =0

t
i s

Graderhöhung einer
Bézierkurve

n +1
~
Bin (u ) = p (u ) = ∑ bi ts Bin +1 (u ), u ∈ [ s, t ]
i =0

1.1 Modellierung virtueller Welten

■
■
■

25

Abb. 1.19:
Graderhöhung einer
Bézierkurve

Die neuen Bézierpunkte sind gegeben durch:

~
b0 = b0
~
bj =
~
bn +1

Eigenschaften von Bézierkurven

26

■
■
■

j
j
)b j ,
b j −1 + (1 −
n +1
n +1
= bn

j = 1,..., n

Dieses Vorgehen wird uns an anderer Stelle noch einmal begegnen
und zeigen, wie Bézierkurven mit Subdivisionalgorithmen erzeugt
werden können. An dieser Stelle sei einfach die Idee in einer Figur
dargestellt.
Bézierkurven vereinigen einige sehr gute Eigenschaften, die zur (interaktiven) Modellierung gebraucht werden. Die Kurven sind schnell
zu berechnen, sie sind affin invariant und haben zahlreiche geometrische Eigenschaften: Das Bézierpolygon vermittelt den ungefähren
Verlauf der Kurve. Neben der erwähnten Tatsache, dass die Kurve
einfach auszurechnen ist, hat man die Ableitungen ebenso unter Kontrolle; die Kurve verläuft am Anfang und Ende tangential zum Bézierpolygon der Kurve und die Ableitung kann aus dem De-CasteljauAlgorithmus bestimmt werden.
Außerdem können Bézierkurven unterteilt und weiter verfeinert
werden. Verändert man interaktiv die Lage der Bézierpunkte, so folgt
die Kurve der Richtung der Lageänderung. Dies ermöglicht erst ein
intuitives und interaktives Modellieren.
Doch sind neben all diesen schönen Eigenschaften auch ein paar
Punkte, die wir noch verbessern sollten: Sind n+1 Bézierpunkte gegeben, so sind n+1 Bernsteinpolynome zur Gewichtung notwendig. Dien
se besitzen den Grad n und bilden eine Basis des Vektorraums P aller
d
Polynomkurven vom Grad n in ℝ . Der Grad einer Bézierkurve ist also
direkt mit der Anzahl der Bézierpunkte gekoppelt. Je mehr Bézierpunkte oder „Gestaltungspunkte“ man für eine Kurve betrachtet,
desto größer werden der Grad und damit die Welligkeit der Kurve.

1 Computergrafik und Virtual Reality

Ein weiterer Punkt: Betrachtet man einmal die Bernsteinpolynome,
so erkennt man, dass diese zwar positiv sind und sich zu 1 addieren,
jedoch sind sie auf dem gesamten Intervall positiv und verschwinden
nie. Dies bedeutet dann aber wiederum, dass der Einfluss eines Bézierpunktes, der mit einem Bernsteinpolynom gewichtet wird, sich über das
gesamte Intervall erstreckt. Der Bézierpunkt beeinflusst global die Form
der Kurve. Dies ist ein Nachteil, will man doch lokal die Form der Kurve
gestalten und nicht durch lokale Änderung eines Kurven(kontroll)punktes eine globale Formänderung der Kurve in Kauf nehmen müssen.
1.1.2.8
Splines, Béziersplines

Um den Grad des Interpolationspolynoms nicht allzu groß werden zu
lassen, unterteilen wir das Problem (Interpolationsaufgabe, Approximation von Kurven) in Teilstücke von Kurvensegmenten mit niederem Grad (in der Praxis meist vom Grad 3) und fügen diese Kurvenn
segmente G stetig aneinander. Wir definieren:
Ein Spline ist eine stetige Abbildung q von einer Menge von Interd
vallen in den Vektorraum ℝ .
Die Intervalle [ti,ti+1], i=0,...,l-1 werden durch einen Stützstellenvektor T=(t0, t1,..., tl) mit t0≤ t1≤ … ≤ tl definiert.
Jedes Intervall [ti,ti+1] wird dabei auf ein Polynomsegment, das SplineSegment, abgebildet.
So können wir nun mit Bézierkurven einen solchen Spline gestalten. Interessant sind die Stellen ti, an welchen die Teilkurven aneinanderstoßen:
Gegeben seien Intervalle [ti,ti+1], i=0,...,l-1, durch einen Stützstellenvekd
tor T=(t0, t1,..., tl) mit t0≤ t1≤ … ≤ tl und Bézierpunkte bi,j∈ℝ für i=0,...,l
und j=0,...,n. Dann heißt die durch die Segmente
n

qi (u) = ∑ ttii +1 B nj (u) bi, j , u ∈[ti , ti +1 ]
j =0

definierte Kurve q=∑qi Bézierspline vom Grad n.
Abb. 1.20:
Aneinanderfügen von Kurvensegmenten

1.1 Modellierung virtueller Welten

■
■
■

27

Zu Beginn des Kapitels hatten wir Reparametrisierung und Anschlüsse von Kurven beschrieben und dabei parametrisch und geometrisch richtige Anschlüsse unterschieden. Zur Erinnerung: Wir
definierten die Ableitungsvektoren folgendermaßen:
T (u) = p′(u), u ∈[s,t ] Tangentenvektor an die Kurve in u
K (u) = p′′(u), u ∈[s,t ] Krümmungsvektor an die Kurve in u

In Anfangs- und Endpunkt einer Kurve sind die rechts- und linksseitigen Ableitungen zu betrachten.
d
d
Sind nun zwei Spline-Segmente qi:[ti-1,ti]→ℝ und qi+1:[ti,ti+1]→ℝ
mit den Bézierpunkten bi,0 ,…, bi,n und bi+1,0 ,…, bi+1,n gegeben, so stoßen
sie in ti aneinander.
… ≤ ti-1 ≤ ti ≤ ti+1 ≤ ...
qi(u)

b1,n-1

bi,n=bi+1,0

...

qi+1(u)

bi
bi+1,1

bi,1
bi.0
Stetigkeit an den Anschlussstellen

.

bi+1,n-1

bi+1,2

Zu untersuchen ist, welchen Stetigkeitsgrad, parametrisch stetig
n
n
(C ) oder geometrisch stetig (G ), dieser Anschluss besitzt.
1
Die G -Stetigkeit an der Verbindung von qi und qi+1 ist gleichbedeutend mit bi,n=bi+1,0 und der Kollinearität der Punkte bi,n-1, bi,n, bi+1,0, bi+1,1.
Wie wir wissen, verläuft nämlich die Bézierkurve qi in bi,n tangential
zum Vektor bi,n-1-bi,n und die Bézierkurve qi+1 in bi+1,0 tangential zu bi+1,0–
bi+1,1.
Sind also die vier Bézierpunkte kollinear, so zeigen die Ableitungen
am Ende und Anfang der Bézier-Spline-Segmente in dieselbe Rich1
tung und dann sind qi und qi+1 G -stetig in ti.
1
C -Stetigkeit fordert die Eigenschaft, dass sowohl Richtung als auch
Länge der beiden Tangenten (im Ende und Anfang der Spline-Segmente) gleich ist. Also sind in diesem Falle nicht nur die Kollinearität
der vier Bézierpunkte zu testen, sondern auch noch die Längenverhältnisse. Es muss gelten:
n
n
(bi ,n − bi ,n−1 ) = qi′(t i ) = qi′+1 (t i ) =
(bi+1,1 − bi+1,0 )
t i − t i−1
t i+1 − t i

28

■
■
■

1 Computergrafik und Virtual Reality

2

2

2

G - und C -Stetigkeit sind auch noch von Interesse. Für G Stetigkeit ist Folgendes zu überprüfen: Der Übergang ist stetig, beide
Tangentenvektoren haben am Übergang die gleiche Richtung und die
Krümmungsvektoren haben auch die gleiche Richtung. Für unsere
Bézier-Spline-Segmente bedeutet dies, dass die Punkte bi,n-2, bi,n-1, bi,n
und bi+1,0, bi+1,1, bi+1,2 komplanar sein müssen und natürlich bi,n= bi+1,0
gelten muss.
1.1.2.9
B-Splines

Béziersplines sind Kurven, die schon viele gute Eigenschaften realisieren. Jedoch ist noch immer eine gewisse Bindung des Grades der gesamten Kurve an die Zahl der Bézierpunkte festzustellen. Die wirkliche Unabhängigkeit von Grad und Anzahl der Kontrollpunkte ist nur
durch das Erreichen eines lokalen Trägers der Polynomfunktionen zu
schaffen. Dann muss auch nicht durch Einfügen eines neuen Kontrollpunktes der Grad der Kurve erhöht werden. Im Falle von Béziersplines wäre dies nur durch eine größere Umordnung zu schaffen.
Alle „guten“ Eigenschaften (affine Invarianz, konvexe Hülleneigenschaft, De-Casteljau-Berechnung) sollten jedoch für unsere neue Kurvenart in ähnlicher Weise gelten. Wir müssen neue Basisfunktionen
finden, mit denen wir wiederum gegebene Punkte gewichten, die den
Kurvenverlauf steuern.
Erinnern wir uns an die Eigenschaften der Bernsteinpolynome, so
war die Rekursionsgleichung besonders wichtig. Mit ihrer Hilfe ergab
sich der De-Casteljau-Algorithmus, mit seiner Hilfe konnte die konvexe Hülleneigenschaft bewiesen werden und und und …
Also sollte diese Rekursionsgleichung eine zentrale Rolle für die
neuen Basispolynomfunktionen spielen. Warum also nicht die Rekursionsgleichung als Definitionsbasis hernehmen?
Es seien Zahlen n ≤ m ∈ ℕ und eine schwach monotone Folge
T = (t0 = ... = tn, tn+1, ... , tm, tm+1 = ... = tm+n+1) von Knoten ti ≤ ti+n+1 ,
0 ≤ i ≤ m, gegeben (schwach monoton = monoton, aber es dürfen auch
gleiche Elemente vorkommen).
n
Die normalisierten B-Spline-Basisfunktionen Ni vom Grad n über T
sind durch
⎧1 falls t i ≤ u ≤ t i+1
N i0 (u) = ⎨
sonst
⎩0
u − t i r −1
t − u r −1
N ir (u) =
N i (u) + i+1+r
N i+1 (u), 1 ≤ r ≤ n
t i +r − t i
t i+1+r − t i+1

1.1 Modellierung virtueller Welten

■
■
■

29

Abb.1.21:
B-Spline-Basisfunktionen

rekursiv definiert. Vorkehrung ist für ti+r = ti und ti+r+1 = ti+1 zu treffen
(schwach monotone Folge). In diesem Fall definieren wir den Summanden gleich 0.
Zu beachten ist, dass die B-Spline-Basisfunktionen abhängig vom
gewählten Trägervektor T sind. Sind die Abstände ti+n+1 – ti , für alle
0 ≤ i ≤ m stets gleich, so sprechen wir von gleichförmigen (uniform),
andernfalls von nicht-gleichförmigen (non-uniform) B-Spline-Basisfunktionen.
Wie für Bernsteinpolynome, so können viele Eigenschaften der
B-Spline-Basisfunktionen abgeleitet werden. Sie können sämtlich
durch vollständige Induktion bewiesen werden.
• So bestehen die B-Spline-Basisfunktionen Ni (u) stückweise aus
Polynomen vom Grad n über T.
n
• Die Funktionen Ni besitzen einen lokalen Träger.
n
• Es gilt Ni (u)≥0 für alle u ∈ [ti ,ti+n+1] und
n
• Ni (u)=0 für alle u ∉ [ti ,ti+n+1].
• Wie die Bernsteinpolynome summieren sich die B-Splines für jeden
Parameterwert auf zu eins:
n

n

∑N
i =0

n
i

(u) = 1 , u ∈[t 0 ,t n+m+1 ]

Wichtig für die Glattheit der Kurve ist die Aussage, dass falls tj,
n
j∈{0,...,m+n+1}, ein einfacher Knoten ist ( tj-1≠tj ≠ tj+1), so ist Ni (tj)
n– 1
mindestens C -stetig.
Wir sehen, dass die Eigenschaften der Bernsteinpolynome erweitert
n
wurden. Man erkennt sogar, dass die B-Splines Ni (u) die Bernsteint n
polynome s Bi (u) über einem Intervall [s,t] als Spezialfall enthalten:
Es sei s<t∈ℝund T = (s,...,s,t,...,t) ein Knotenvektor mit (n+1)fachen Randknoten s und t. Dann stimmen für s ≤ u ≤ t die B-Splines
n
t n
Ni auf T mit den Bernsteinpolynomen s Bi auf [s,t] überein.

30

■
■
■

1 Computergrafik und Virtual Reality

Jetzt ist es an der Zeit, Kurven aus diesen neuen Basisfunktionen zu
definieren: Wie üblich wählen wir uns zuerst einen Trägervektor T
und dazu Zahlen n≤m∈N und eine schwach monotone Folge
T = (t0 = ... = tn, tn+1, ... , tm, tm+1 = ... = tm+n+1)

mit ti≤ ti+n+1 , 0 ≤ i ≤ m.
Die B-Spline-Basispolynome sind damit eindeutig definiert und wir
können die Punkte d0, …, dm∈ℝd mit den Basisfunktionen gewichten.
m

q(u) = ∑ di N in (u), u ∈[t 0 ,t n+m+1 ]
i =0

Die entstehende Kurve heißt B-Spline-Kurve oder einfach B-Spline
über T vom Grad n. Häufig beschränkt man sich jedoch auf kubische
B-Splines. Die Punkte d0,...,dm heißen Kontroll- oder De-Boor-Punkte
von q. Sie bilden das Kontroll- oder De-Boor-Polygon.
Die Eigenschaften der B-Spline-Basisfunktionen zeigen, dass die
Kurve affin invariant (Partition der 1) ist, innerhalb der konvexen
Hülle der De-Boor-Punkte verläuft (Konvex-Kombination) und durch
Anfangs- und Endpunkt geht. Wie sieht es nun mit der gesuchten lokalen Einflusseigenschaft eines De-Boor-Punktes aus? Aus Definition
n
n
der Basisfunktionen Ni (u) ist klar, dass Ni (u)≥0 für alle u ∈ [ti ,ti+n+1]
n
und Ni (u)=0 für alle u ∉ [ti ,ti+n+1] ist. Also ist das Produkt des Den
Boor-Punktes di mit Ni (u) nur auf dem Parameterstück [ti ,ti+n+1] ungleich null und verschwindet auf dem ganzen Rest des Intervalls
[t0 ,tn+m+1]. Die Form der Kurve wird über dem Intervall [ti ,ti+n+1] also
nur von den De-Boor-Punkten di-n,...,dn beeinflusst und die Basisfunkn
tionen Ni (u) schalten bei Segmentübergängen ti neue De-Boor-Punkte
an oder aus.
Außerdem folgt die Kurve der Verschiebungsrichtung des De-BoorPunktes wie bei Bézierkurven. Aber Bézierkurven sind auch ein Spezi-

Kontrollpunkte (De-Boor-Punkte)
Kontrollpolygon

Abb. 1.22:
Manipulation eines B-Splines durch
Verschiebung der Kontrollpunkte

1.1 Modellierung virtueller Welten

■
■
■

31

alfall, da der Trägervektor T=(s,s,…,s,t,t,…,t) speziell gewählt wurde
(n-mal s und t)

1.1.3
De-Boor-Algorithmus für B-Splines
Auch die Berechnung des Kurvenverlaufs kann wie bei Bézierkurven
durch ein rekursives Schema durchgeführt werden: Gegeben sei ein
B-Spline vom Grad n über
T = (t0 = ... = tn, tn+1, ... , tm, tm+1 = ... = tm+n+1)

mit ti≤ ti+n+1 , 0 ≤ i ≤ m:
m

q(u) = ∑ di N in (u), u ∈[t l ,t l+1 ]
i =0

dann liefert das rekursiv definierte Schema (De-Boor-Algorithmus)
n
den Funktionswert q(u)=dl-n (u).
di0 (u) = di ,

i = l − n,..., l

⎛
u − t i +r
dir (u) = ⎜ 1 −
t
i +n+1 − t i +r
⎝

⎞ r −1
u − t i +r
⋅ dir+−11 (u)
⎟ ⋅ di (u) +
t
t
−
i +n+1
i +r
⎠
i = l − n,..., l − r und 0 ≤ r ≤ n

Noch einmal sieht man hier den Zusammenhang zwischen allgemeineren B-Splines und Bézierkurven: Ist der Trägervektor T = (s,...,s,t,...,t),
dann geht der De-Boor-Algorithmus in den De-Casteljau-Algorithmus
über. Insbesonderes stimmt dann die B-Spline-Darstellung einer
B-Spline-Kurve q über T mit der Bézierdarstellung von q über [s,t]
überein.
Wir wollen einmal diesen Algorithmus an einem Beispiel testen.
Bekannt ist, dass der B-Spline durch Anfangs- und Endpunkt verläuft.
Kommt dies auch beim De-Boor-Algorithmus heraus? Dazu betrachten wir beispielhaft: n=2, T=(0,0,0,1,2,3,3,3) und d0=(0|0), d1=(1|0),
d2=(1|1), d3=(0|1). Wir wollen den Anfangspunkt berechnen, somit ist
u=0 und damit u∈[0,1]=[t2,t3], also l=2. Der De-Boor-Algorithmus
liefert:

d 0 = (0 | 0) d 0 = (1 | 0) d 0 = (1 | 1)
0

1

2

d1 = (0 | 0) d1 = (1 | 0)
0

1

d2
0

32

■
■
■

= (0 | 0)

1 Computergrafik und Virtual Reality

Auch diesmal kann der De-Boor-Algorithmus als geometrische
Konstruktion interpretiert werden, wie wir an einem weiteren Beispiel,
das in Abb. 1.24 dargestellt ist, sehen können: Es sei wieder n=2,
T=(0,0,0,1,2,2,2) und d0=(0|0), d1=(1|0), d2=(1|1), d3=(0|1).
Abb. 1.23:
Geometrische Konstruktion
des De-Boor-Algorithmus

Viele Eigenschaften lassen sich für B-Splines beweisen. Hier sind
die wichtigsten zusammengefasst:
Für tl≤u≤ tl+1 liegt q(u) in der konvexen Hülle der n+1 Kontrollpunkte dl-n, ..., dl (konvexe Hüllen-Eigenschaft, convex hull property):
Abb. 1.24:
Konvexe Hüllen-Eigenschaft

Fallen n Kontrollpunkte dl-n+1=dl-n=...= dl=d zusammen, so gilt
q(tl+1)=d, d. h., die Kurve verläuft durch diesen Kontrollpunkt.
Abb. 1.25:
n-facher Kontrollpunkt

1.1 Modellierung virtueller Welten

■
■
■

33

Liegen n+1 Kontrollpunkte dl-n=...= dl auf einer Geraden L, so gilt
q(u)∈L für tl≤u ≤ tl+1.
Abb. 1.26:
n+1 kollineare Kontrollpunkte

Fallen n Knoten tl+1 = ... tl+n =:t zusammen, so ist q(t) = dl ein Kontrollpunkt, und die Kurve schmiegt sich dort tangential an das Kontrollpolygon. Insbesondere verläuft die Kurve bei (n+1)-fachen Anfangs- und Endknoten durch die Endpunkte des Polygons und ist dort
tangential zum Kontrollpolygon.
Abb. 1.27:
n-facher Knoten

Einfügen weiterer Kontrollpunkte

Wie bei Bézierkurven will man durch interaktives Einfügen weiterer Kontrollpunkte die Geometrie der Kurve „verfeinern“. Der
B-Spline lässt sich flexibler gestalten. Analog wollen wir einen neuen
De-Boor-Punkt dr* einfügen, allerdings ohne gleichzeitig den Grad des
B-Splines zu erhöhen!
Gegeben sei ein B-Spline vom Grad n über
T = (t0 = ... = tn, tn+1, ... , tm, tm+1 = ... = tm+n+1).
m

q(u) = ∑ di N in (u)
i =0

34

■
■
■

1 Computergrafik und Virtual Reality

Es sei weiter dr*∈ℝd und etwa tr≤ t* ≤ tr+1. Dann besitzt q(u) die Darstellung vom Grade n über T = (t0 = ... = tn, tn+1, ..., tr, t*, tr+1,… , tm, tm+1
= ... = tm+n+1)
m+1

q(u) = ∑ d i∗ N in (u)
i =0

Die neuen De-Boor-Punkte di* sind:
d i∗ = (1 − ai ) d i −1 + ai d i
⎧
1
⎪⎪ t − t
i
ai = ⎨
t
-t
⎪ i+n i
⎪⎩
0

mit

für i ≤ r − n

bleiben

für r − n + 1 ≤ i ≤ r
für r + 1 ≤ i

nur n De-BoorPunkte

geshiftet
1.1.3.1
Rationale Kurven

Mit den B-Splines besitzen wir ein mächtiges Werkzeug zur Gestaltung von Kurven. Sie bieten die Möglichkeit, interaktiv zu modellieren
und sind schnell auszurechnen. Außerdem sind diese Kurven stabil
unter affinen Transformationen. Jedoch tritt wieder ein Problem auf:
Es gibt leider Kurven, die wir nicht als B-Spline beschreiben können.
Eine der elementarsten Kurven ist ein Kreis:

⎛ r cos(2πu )⎞
⎟⎟, u ∈ [0.0,1.0]
K (u ) = ⎜⎜
⎝ r sin (2πu ) ⎠

Jedoch sieht man nun sofort, dass die Koordinatenfunktionen aus
Sinus- und Cosinusfunktion bestehen, die wiederum nicht als Polynom endlichen Grades dargestellt werden können. Sie sind Exponentialreihen. Also gibt es keine Chance, Kreise als Monom-, Lagrange-,
Hermite-, Bézier- oder B-Spline-Kurve darzustellen. Es wäre immer
nur eine gute Näherung, aber nicht exakt ein Kreis.
Aber es gibt auch hier einen Ausweg! Kreise erhält man auch als
Projektionen eines Kegelmantels (Kegelschnitt). Die parametrisierte
Kurve eines Kreises hat daher auch die Form

1.1 Modellierung virtueller Welten

■
■
■

35

⎛ 1 − u 2 2u ⎞
⎟
K (u ) = r ⋅ ⎜⎜
2
2 ⎟
⎝1+ u 1+ u ⎠

Rationale Bézierkurve

Nun aber sind die Koordinaten durch (ganz)rationale Funktionen
gegeben. Aus dieser Not wird eine Tugend und wir definieren:
Gegeben seien Bézierpunkte bi∈ℝd, i=0,...,n, und Gewichte ωi≥0,
i=0,...,n, mit ω0=ωn=1. Dann heißt
n

r(u) =

∑ω b

t
i s

i

Bin (u)

i =0
n

∑ωi st Bin (u)

, u ∈[s,t ]

i =0

Rationale B-Spline-Kurve

rationale Bézierkurve vom Grad n.
Nun kann man nicht nur rationale Bézierkurven betrachten, sondern auch dasselbe für die allgemeineren B-Splines durchführen.
Sei T = (t0 = ... = tn, tn+1, ... , tm, tm+1 = ... = tm+n+1) ein Trägervektor und
sind m+1 Kontrollpunkte di∈ℝd und Gewichte ωi≥0, i=0,...,m, gegeben, so heißt
m

m

q(u) = ∑ di
i =0

ωi N in (u)
m

∑ω N
i

n
j

(u)

j =0

NURBS

=

∑d ω N
i

i

n
i

(u)

i =0
m

∑ω N
i

n
j

(u)

j =0

rationale B-Spline-Kurve. Sind die Intervallgrößen in T unterschiedlich, heißt q nicht-gleichförmiger rationaler (non-uniform-rational)
B-Spline (NURBS).
In beiden Kurvenarten sind jeweils Bézier- oder B-Spline-Kurven in
Zähler und Nenner zu finden. Zur Berechnung der Kurve könnte man
nun naiv Zähler und Nenner mit dem De-Casteljau- oder De-BoorAlgorithmus auswerten und den Quotient als Kurvenwert berechnen.
Jedoch geht es besser, wenn man sich daran erinnert, dass wir Projektionen vor uns haben (Kreis als Kegelschnitt)!
Gegeben seien Bézierpunkte bi=(xi,yi,zi) ∈ℝ3, i=0,...,n, und
Gewichte ωi≥0, i=0,...,n, mit ω0=ωn=1.
Dann ist bi = (ωi xi, ωi yi, ωi zi, ωi) ∈ℝ4, und
h

n

F (u) = ∑ bih st Bin (u), u ∈[s, t ]
i =0

definiert eine Bézierkurve im ℝ4.

36

■
■
■

1 Computergrafik und Virtual Reality

Diese Bézierkurve wird nun auf die Hyperebene ℝ3 =(*,*,*,1) projiziert, d. h. durch die letzte Koordinate dividiert. Man erhält die rationale Bézierkurve r(u). Gleiches gilt für die B-Spline-Kurven und
(N)URBS.
Für die Berechnung wendet man also den De-Casteljau- oder Deh
Boor-Algorithmus auf bi an. Wir erhalten den Funktionswert der
vierdimensionalen Kurve F(u)=(x|y|z|w). Den gesuchten Funktionswert der rationalen Kurven erhält man nun, indem man die Koordinaten x, y und z durch die vierte berechnete Koordinate w dividiert und
somit auf die dreidimensionale Hyperebene (mit w=1) projiziert.
Sei zum Beispiel T=(0,0,0, 1,1,1) gegeben mit b0=(1|0), b1=(1|1) und
b2=(0|1) mit Gewichten ω0=1= ω1 und ω2=2 . Dann ist die rationale
Bézierkurve des Viertelkreises gegeben durch:
2

r(u) =

∑ω b B (u)
i

i

2
i

i =0
2

∑ωi Bin (u)

, u ∈[0,1]

i =0

=

⎛1⎞

⎛1⎞

⎛0⎞

⎝ ⎠

⎝ ⎠

⎝ ⎠

ω0 ⎜ ⎟(1 − u)2 + ω1 ⎜ ⎟ 2u(1 − u) + ω2 ⎜ ⎟ u2
0
1
1
ω0 (1 − u)2 + ω1 2u(1 − u) + ω2u2

Wie nun leicht nachzurechnen ist, gilt
⎛ x(u) ⎞ ⎛ 1 − u2
r(u) = ⎜
⎟=⎜
2
⎝ y(u) ⎠ ⎝ 1 + u

T

2u ⎞
2
2
⎟ , mit x (u) + y (u) = 1
1 + u2 ⎠

Also beschreibt r(u) einen Kreisbogen, der in (1|0) beginnt und in
(0|1) endet. Zur Berechnung (und Darstellung) der Kreisbogenpunkte
wird jedoch nicht die obige Formel verwendet, sondern es wird der
h
h
De-Casteljau-Algorithmus auf die Punkte b0 =(1|0|1), b1 =(1|1|1) und
h
b2 =(0|1|2) angewendet. Es entsteht eine dreidimensionale Bézierkurve, welche dann auf die Ebene x3=1 projiziert wird.
Abb. 1.28:
Einfluss der Gewichte auf den
Kurvenverlauf

1.1 Modellierung virtueller Welten

■
■
■

37

Wird das Gewicht ωk vergrößert, so bewegt sich die Kurve zum
k-ten Kontrollpunkt.

1.1.4
Flächen
Im vorhergehenden Kapitel hatten wir Kurven immer nach dem gleichen Prinzip gebildet: Wir hatten gegebene Kontrollpunkte mit verschiedenen (polynomiellen) Basisfunktionen, die über einem Intervall
[s,t] definiert waren, gewichtet. Was, wenn nun die Kontrollpunkte
selbst wieder durch Kurven definiert werden? Man erhält die sogenannten Tensorproduktflächen. Zunächst betrachten wir zur Begriffsklärung allgemeine Flächenfunktionen.
Sei Ω⊆ℝ2 ein Gebiet in der Ebene − der Parameterbereich. Meist
verwendet man Rechtecks- oder Dreiecksgebiete als Parameterbereich. Eine Fläche ist eine Abbildung q: Ω→ℝd.
Im Falle d=3 und Ω=[0,1]×[0,1] ist eine Fläche also durch drei Koordinatenfunktionen x, y und z in jeweils zwei Parametern u und v
gegeben:
⎛ x(u, v ) ⎞
⎜
⎟
q : (u, v ) → ⎜ y(u, v ) ⎟ , (u, v ) ∈[0,1]2
⎜ z(u, v ) ⎟
⎝
⎠
Stetigkeit von Flächen

Reguläre Flächen

Wieder sind wie im Kurvenfall d Koordinatenfunktionen zu wählen, die Stetigkeitseigenschaften besitzen. So sagen wir, die Fläche ist
n
C -stetig oder n-mal differenzierbar, falls die Abbildung q mindestens
n-mal stetig differenzierbar ist, d. h., q ist n-mal stetig partiell differenzierbar.
Eine Fläche heißt regulär in (u0,v0), falls q einmal stetig differenzierbar ist und die Vektoren

⎛ ∂x
⎞
⎜ (u0 , v0 ) ⎟
⎜ ∂u
⎟
∂y
∂q
∂q
⎜
(u0 , v0 ) =
(u0 , v0 ) ⎟ qv (u0 , v0 ) =
qu (u0 , v0 ) =
(u0 , v0 )
⎜ ∂u
⎟
∂u
∂v
⎜ ∂z
⎟
⎜ (u0 , v0 ) ⎟
⎝ ∂u
⎠
Tangentialvektoren

38

■
■
■

linear unabhängig sind (und damit nicht verschwinden). qu und qv
heißen Tangentialvektoren.

1 Computergrafik und Virtual Reality

Ist q regulär, so spannen qu und qv eine Tangentialebene auf. Die
Normale dieser Tangentialebene ist definiert durch das Kreuzprodukt
(oder Vektorprodukt) der Tangentialvektoren
n(u0 , v0 ) =

Normale

qu (u0 , v0 ) × qv (u0 , v0 )
qu (u0 , v0 ) × qv (u0 , v0 )

und heißt Normalenvektor in (u0,v0).
Abb. 1.29:
Beispiele für parametrisierte Flächen

1.1.4.1
Tensorproduktflächen

Tensorproduktflächen gewinnt man leicht aus den uns bekannten
Kurvendarstellungen. Betrachten wir zum Beispiel eine Kurve q, gegeben durch
n

q(u) = ∑Ci Fi (u)
i =0

mit Kontrollpunkten Ci und Basisfunktionen Fi.
Nun bewegen wir diese Kurve mittels eines weiteren unabhängigen
Parameters v durch den Raum, wobei wir auch Deformationen der
Kurve zulassen werden. Deformation der Kurve bedeutet dabei Veränderung der Kontrollpunkte Ci, d. h., wir beschreiben diese Verände-

1.1 Modellierung virtueller Welten

■
■
■

39

rung wieder durch eine Kurve mit dem neuen Parameter v und möglicherweise anderer Basisfunktionen Gj:
m

Ci (v ) = ∑ AijG j (v ).
j =0

Insgesamt entsteht so die Tensorproduktfläche:
n

m

i =0

j =0

q(u, v ) = ∑∑ AijG j (v )Fi (u), (u, v ) ∈[a, b]× [c , d]

Ein einfaches Beispiel einer Tensorproduktfläche ist ein Geradenstück, bei dem die beiden Endpunkte mittels einer Kurve verändert werden. So entsteht zum Beispiel eine Kegelstumpf-Mantelfläche:
Abb. 1.30:
Beispiel einer Tensorproduktfläche

Eine Tensorproduktfläche mit rechteckigem Parametergebiet kann
auch in Matrixform angegeben werden:

Sei (u, v ) ∈[a, b]× [c , d]
n

m

i =0

j =0

q(u, v ) = ∑∑ AijG j (v )Fi (u) =
= ( F0 (u)

⎛ A00
⎜
Fn (u)) ⎜
⎜A
⎝ n0

A0m ⎞⎛ G0 (v ) ⎞
⎟⎜
⎟
⎟⎜
⎟
⎟
Anm ⎟⎜
⎠⎝ Gm (v ) ⎠

Man erkennt deutlich die regelmäßige Gitterstruktur der gegebenen Kontrollpunkte Aij, die für eine so gebildete Tensorproduktfläche

40

■
■
■

1 Computergrafik und Virtual Reality

notwendig gegeben sein müssen. Regelmäßig soll heißen, in der gleichen Anzahl der Kontrollpunkte in u- und v-Richtung und nicht in
der Raumlage der Punkte. Sind die Kontrollpunkte unregelmäßig
verteilt (scattered), müssen andere Techniken eingesetzt werden, wie
sie bei der Scattered-Data-Interpolation entwickelt wurden [LF99].
1.1.4.2
Interpolation

Wie im Kurvenfall stellt sich in der Praxis oft die Aufgabe, eine Fläche
(Kurve) durch eine gegebene Anzahl von Kontrollpunkten zu legen.
Es seien also n×m Kontrollpunkte Pij, i=0,…,n, und j=0,…,m, gegeben
zu Parameterwerten ui und vj. Gesucht sei nun eine (polynomielle)
Fläche X(u,v), die diese Punkte interpoliert. Es ergibt sich aus der
Voraussetzung X(ui,vj)=Pij für i=0,...,m, j=0,...,n ein Gleichungssystem
P=FAG aus Matrizen:
⎛ P00
⎜
P =⎜
⎜P
⎝ n0
⎛ F0 (u0 )
⎜
F =⎜
⎜ F (u )
⎝ 0 n

P0m ⎞
⎛ A00
⎟
⎜
A=⎜
⎟
⎜A
Pnm ⎟⎠
⎝ n0
Fn (u0 ) ⎞
⎛ G0 (v0 )
⎟
⎜
⎟ G=⎜
⎜ G (v )
Fn (un ) ⎟⎠
⎝ m 0

A0m ⎞
⎟
⎟
Anm ⎟⎠
G0 (vm ) ⎞
⎟
⎟.
Gm (vm ) ⎟⎠

Dieses Gleichungssystem ist nach der unbekannten Matrix A aufzulösen. Sind wiederum wie im Kurvenfall die Parameterwerte ui und vj
paarweise verschieden, und wählt man als Basisfunktionen Fi und Gj
Monome, dann sind F und G invertierbare van der Monde’sche Matrizen. Das Gleichungssystem kann dann zu A = F −1 PG −1 aufgelöst werden
und liefert die Existenz und Eindeutigkeit einer Interpolationsfläche.
Werden für F und G Lagrangepolynome verwendet, d. h.
⎧1 falls i = k
Fi n (uk ) = δ ik = ⎨
⎩0 sonst
m
G j (vl ) = δ jl ,
so sind F und G Einheitsmatrizen und wir erhalten, wie im Fall der
Kurven, eine besonders einfache Lösung der Interpolationsaufgabe
mit A=P.

1.1 Modellierung virtueller Welten

■
■
■

41

1.1.4.3
Bézier-Tensorproduktflächen

Verwendet man als Basisfunktionen F und G die bekannten Bernsteinpolynome über [0,1] oder [s,t] vom Grad n bzw. m, so erhalten
d
wir mit gegebenen Bézierpunkten bij ∈ ℝ eine Bézier-Tensorproduktfläche oder ein Bézierpflaster:
Abb. 1.31:
Bézier-Tensorproduktfläche

Kontrollnetz

Die Bézierpunkte bilden das Kontrollnetz des Bézierpflasters.
Die Parameterlinien liefern Bézierkurven, wie man leicht durch geeignetes Klammern erkennt:
n
n
⎛ m
⎞
q(u0 , v ) = ∑ ⎜ ∑ bij Bim (u0 ) ⎟Bnj (v ) = ∑ b j (u0 )Bnj (v )
j =0 ⎝ i =0
j =0
⎠

Die Bézier-Tensorproduktfläche liegt für die Parameterwerte
(u,v)∈[0,1] ebenfalls in der konvexen Hülle des Kontrollnetzes, wie
man aus den Eigenschaften
m

⎛

n

⎝

j =0

⎞

∑ ⎜ ∑ B (v) ⎟ B
i =0

n
j

⎠

m
i

(u) = 1 und

=1
=1
m

n

∑∑ B

m
i

i =0

42

■
■
■

(u)Bnj (v ) ≥ 0

j =0

1 Computergrafik und Virtual Reality

erkennen kann. Die erste der obigen Eigenschaften sichert auch die
affine Invarianz dieser Flächen.
Eine weitere Eigenschaft ist direkt aus den Bernsteinpolynomen abzuleiten, ähnlich wie im Kurvenfall: Die Bézierpunkte der Randkurven
sind die Randpunkte des Bézier-Tensorproduktflächen-Kontrollnetzes.
Die Ableitungen in den Randpunkten lassen sich wie bei den Kurven aus den Bézierpunkten der Randkurven berechnen:
Abb. 1.32:
Ableitungen in den Randpunkten von
Bézier-Tensorproduktfläche

Der bereits von den Bézierkurven bekannte De-Casteljau-Algorithmus kann auf Tensorproduktflächen erweitert werden:
n
n
⎛ m
⎞
q(u0 , v0 ) = ∑ ⎜ ∑ bij Bim (u0 ) ⎟Bnj (v ) = ∑ b j (u0 )Bnj (v0 )
j =0 ⎝ i =0
j =0
⎠
für festes i ,u0 aus den
b0 ( u0 )=bij ( u0 )

mit de Casteljau Kurve an
der Stelle v =v0 auswerten

ij

mit de Casteljau
b j ( u0 )=bn ( u0 ) berechnen
ij

Die vorletzten Elemente des De-Casteljau-Schemas liefern wieder
die Richtungen der partiellen Ableitungen qu bzw. qv der Bézierfläche.

1.1.5
Anschlüsse von Bézier-Tensorproduktflächen
Wie wir wissen, definieren die Randpunkte des Kontrollnetzes den
Verlauf der Randkurve der Tensorproduktfläche. Durch sie können
wir auch zwei Tensorproduktflächen q1 und q2, die wir aneinanderfügen wollen, kontrollieren.
m

n

i =0

j =0

m

n

i =0

j =0

q1 (u, v ) = ∑∑ bij or11 Bim (u) st11 Bnj (v )
q2 (u, v ) = ∑∑ cij or22 Bim (u) st22 Bnj (v )

1.1 Modellierung virtueller Welten

■
■
■

43

Abb. 1.33:
Aneinanderfügen zweier
Bézier-Tensorproduktflächen

Sollen sie stetig aneinandergefügt werden, so müssen die jeweiligen
Randpunkte der Kontrollnetze an der Anschlussstelle identisch sein.
Dann besitzen die beiden Bézierflächen dieselbe Randkurve. Ein wenig schwieriger wird es, die beiden Flächenstücke an der Übergangs1
1
stelle C oder G stetig zu gestalten.
Wir wissen jedoch, wie sich die Randableitungen, d. h. die partiellen Ableitungen an den Rändern, berechnen.
1
Um zwei Pflaster entlang der Randkurve in v-Richtung (C -stetig)
aneinanderschließen zu können, müssen erstens die beiden Pflaster
dieselbe Randkurve in v-Richtung besitzen, d. h., für die Bézierpunkte
gilt
bmj=c0j, j=0,...,n,
und zweitens müssen entlang der Randkurve, d. h. zu jedem festen v,
die Ableitungen in u-Richtung in Betrag und Richtung überein1
stimmen. Für C -Stetigkeit muss also gelten (Anschluss in v-Richtung), dass die Ableitungen in u-Richtung entlang der gemeinsamen
v-Kurve gleich sind:

bmj − bm−1, j = c1 j − c0 j
Fordert man beim Aneinanderfügen nur paarweise kollineare Tan1
gentenvektoren − also gleiche Tangentenrichtung −, was der G -Stetigkeit entlang der gesamten Nahtlinie entspricht, so müssen die Polygonsegmente des Kontrollnetzes zwar kollinear sein, aber in keinem
bestimmten Längenverhältnis stehen.
k
Allgemeiner kann festgestellt werden, will man einen C -stetigen
Übergang erzwingen, müssen die Kontrollpunkte des Netzes so gek
wählt werden, dass alle Kurven (in u- und v-Richtung) C -stetig sind.

44

■
■
■

1 Computergrafik und Virtual Reality

Abb. 1.34:
Anschlussbedingungen beim
Aneinanderfügen mehrerer
Bézierpflaster

Beim Aneinanderfügen von drei oder mehr Bézierpflaster sind so
eine ganze Reihe von Bedingungen an die Kontrollpunkte zu erfüllen.
Vor allem am gemeinsamen Punkt sind Vorkehrungen zu treffen.
1
Wie man aus Abb. 1.34 leicht erkennen kann, sind schon im G -Fall
die vier nächsten Kontrollpunkte zum gemeinsamen Punkt in einer
Ebene zu wählen.
Will man vier Bézierpflaster so aneinanderfügen, dass die Überk
k
gänge C -(G -)stetig sind, so sind am besten die Randkurven
(schwarz) glatt vorzugeben und die inneren (freien) Kontrollpunkte
entsprechend der geforderten Stetigkeit zu setzen.
1.1.5.1
Rationale Bézier-Tensorproduktflächen

Sind ein Kontrollnetz bij∈ℝ und Gewichte wij∈ℝgegeben (i=0,…m
und j=0,…,n), kann eine rationale Bézierfläche gebildet werden:
d

m

n

i =0

j =0

m

n

∑∑b B
ij

R(u, v ) =

m
i

∑∑ w B
ij

i =0

(u)Bnj (v )

m
i

,
n
j

(u)B (v )

j =0

wobei

⎧wij bij , falls wij ≠ 0
bij = ⎨
sonst.
⎩ bij

1.1 Modellierung virtueller Welten

■
■
■

45

Abb. 1.35:
Beispiele rationaler
Bézier-Tensorproduktflächen

Um diese rationale Bézierfläche durch die Eckpunkte zu zwingen,
fordert man wm0=w0n=1.
Die rationale Bézierfläche ist wieder als Projektion einer Fläche in
4
ℝ in den dreidimensionalen Raum zu betrachten. Daher übertragen
sich die Eigenschaften wie konvexe Hülle, affine Invarianz, Stetigkeit
u. A. auch auf diesen Flächentyp.
1.1.5.2
Tensorproduktflächen über Dreiecken

Wie schon erwähnt werden nicht nur rechteckige Parametergebiete
zur Flächenbildung verwendet. In der Tat gibt es Modelle, die durch
Rechteckspflaster nicht zu realisieren sind:
Abb. 1.36:
Modelle, die nicht nur aus
Viereckspflastern bestehen

Vor allem zur Modellierung von Augen-, Nasen- und Mundbereichen sind Mischungen von Dreiecks- und Vierecksflächen notwendig.

46

■
■
■

1 Computergrafik und Virtual Reality

Um diese Situationen lösen zu können, sind zwei Strategien möglich: Zum einen können „entartete“ Vierecksnetze verwendet werden,
bei denen zwei Kontrollpunkte zusammenfallen.
Zum anderen können, um wieder auf Viereckspflaster zu kommen,
zusätzliche Punkte eingefügt werden:
Abb. 1.37:
Einfügen zusätzlicher Punkte,
um Viereckspflaster zu erreichen

Die dritte Möglichkeit besteht in der Verallgemeinerung von Tensorproduktflächen auf Dreiecksgebieten.
Sind nun drei Punkte R, S und T der Ebene gegeben, welche nicht
kollinear sind, so kann bekanntlich jeder weitere Punkt U der Ebene
in baryzentrischen Koordinaten der Punkte R, S und T ausgedrückt
werden:
Abb. 1.38:
Baryzentrische Koordinaten

Die Koeffizienten ρ (U), σ (U) und τ (U) heißen baryzentrische Koordinaten des Punktes U bezüglich des Dreiecks RST.
Dann definieren die Funktionen
RST

⎛ n ⎞
i
j
k
Bin, j ,k (U ) := ⎜
⎟ ρ (U ) σ (U ) τ (U ) , i + j + k = n
i
j
k
,
,
⎝
⎠

die sog. verallgemeinerten Bernsteinpolynome bezüglich des Referenzdreiecks RST. Dabei ist

Verallgemeinerte Bernsteinpolynome

⎛ n ⎞
n!
⎜
⎟=
i
j
k
,
,
⎝
⎠ i ! j !k !

1.1 Modellierung virtueller Welten

■
■
■

47

der bekannte verallgemeinerte Binomialkoeffizient. Wie die Bernsteinpolynome eine Basis für den Raum der reellwertigen univariaten
Polynome (Polynome in einer Variablen) bilden, so bilden die oben
definierten verallgemeinerten Bernsteinpolynome eine Basis für den
Raum aller reellwertigen bivariaten Polynome (Polynome in zwei
Variablen) vom Grad n.
Für jedes bivariate Polynom q(u,v), q:ℝ2→ℝ3 existiert also eine
Bézierdarstellung
q(u, v ) = q(U ) =

∑

RST

Bijkn (U )bijk

i + j +k =n

bezüglich des Referenzdreiecks RST und den Bézierpunkten bijk∈ℝ .
Die Punkte bijk bilden das Kontroll- oder Béziernetz.
Setzen wir für eine so gegebene Bézierfläche
d

bi0, j ,k (U ) := bijk , mit i + j + k = n
und bir, j ,k (U ) := ρ (U )b(ri−+11), j ,k (U ) +
+ σ (U )bir,(−1j+1),k (U ) +
+ τ (U )bir,−j1,( k+1) (U ), mit i + j + k + r = n,
n
dann ist der Funktionswert q(U) mit dem letzten Glied b0,0,0
(U ) des
rekursiven Schemas berechnet (de Casteljau für Dreiecksflächen).
Wieder sind die bekannten Resultate für diese Dreiecksflächen ableitbar:

• Liegt U im Dreieck RST, so liegt q(U) innerhalb der abgeschlossenen konvexen Hülle des Kontrollpolygons.
• Fläche und Kontrollpolygon sind affin invariant.
• Die Fläche verläuft durch die drei Eckpunkte des Bézierpolygons,
d. h. q(R) = bn,0,0, q(S) = b0,n,0 und q(T) = b0,0,n.
• Die Fläche verläuft in den Eckpunkten q(R), q(S) und q(T) tangential an das Kontrollnetz.
• Die Einschränkung von q auf die Gerade (S,T) (und analog für die
Geraden (R,S) und (T,R)) ist eine Bézierkurve mit den Bézierpunkten b0,n-k,k, d. h., für U∈(S,T) gilt:
n

q(U ) = ∑ TS Bkn (U )b0,n−k ,k .
k =0

Für den Anschluss von Dreiecksflächen sei auf die Literatur verwiesen
[ES97] bzw. [HL89].

48

■
■
■

1 Computergrafik und Virtual Reality

1.2
Bildberechnung – vom Modell zum Bild
Im vorigen Kapitel wurden einige Datenstrukturen vorgestellt, mit
deren Hilfe dreidimensionale Objekte durch die geometrische Beschreibung ihrer Oberflächen im Rechner repräsentiert werden.
In diesem Kapitel wird die Erzeugung zweidimensionaler Ansichten aus solchen geometrischen Beschreibungen behandelt, wie sie zum
Beispiel zur Darstellung der Szenen auf einem Bildschirm benötigt
werden. Dazu sind mehrere Arbeitsschritte notwendig, die im Folgenden vorgestellt werden.
Zunächst müssen die Objekte in der Regel Transformationen unterzogen werden, um eine Darstellung in Weltkoordinaten zu erhalten. Anschließend müssen die Objekte auf die Bildebene projiziert
werden. Dies kann durch eine orthogonale Projektion oder eine perspektivische Projektion geschehen. Die mathematischen Grundlagen
zu Transformationen und Perspektive und ihre Umsetzung in der
Computergrafik sind zum Beispiel in [FD96] zu finden.
Nun müssen diejenigen Objektteile der so entstandenen zweidimensionalen geometrischen Objekte abgeschnitten werden, die außerhalb des sichtbaren Bereiches des Bildschirms liegen. Diesen Vorgang bezeichnet man als Clipping. Ausführliche Informationen finden
Sie z. B. in [BB06] oder [FD96].
Auch die gegenseitige Verdeckung von Objekten muss berücksichtigt werden, so dass nur die sichtbaren und unverdeckten Teile der
Objekte dargestellt werden (siehe Kap. 1.2.4).
Zur Ausgabe grafischer Darstellungen werden heutzutage fast ausschließlich Raster-Ausgabegeräte verwendet, bei denen das dargestellte Bild aus vielen einzelnen Bildpunkten (Pixeln) besteht. Die geometrischen Objekte müssen deshalb in einem nächsten Schritt rasterisiert
werden, das heißt, es müssen diejenigen Bildpunkte bestimmt werden,
die von den einzelnen Objekten bedeckt werden [BB06 55 ff.][FD96].
Bei der Rasterisierung treten Abtastfehler (Aliasing) auf, die zu visuellen Artefakten wie zum Beispiel Treppenstufeneffekten führen, die mit
geeigneten Gegenmaßnahmen (Antialiasing) minimiert werden müssen [Wa02 435 ff.].
Die Farbwerte der einzelnen Pixel ergeben sich jeweils aus der
Leuchtdichte der Oberfläche, die das entsprechende Pixel bedeckt, in
Richtung des Beobachters. Diese wird bestimmt vom Einfluss der Lichtquellen auf die Oberfläche, von den Reflexionseigenschaften der Oberfläche und auch von gegenseitigen Wechselwirkungen der Oberflächen
untereinander, wie z. B. Spiegelungen oder indirekte Beleuchtung.

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

49

Um eine realistische Darstellung dreidimensionaler Szenen zu erhalten, ist es deshalb notwendig, die Beleuchtungssituation in den
Szenen mehr oder weniger genau zu berechnen. Die Genauigkeit der
Berechnung hat dabei einen entscheidenden Einfluss auf den Realitätsgrad der Darstellung, da eventuelle Fehler von Beobachtern aufgrund ihrer Erfahrungen in realen Szenen schnell als störend wahrgenommen werden.
Eine exakte Berechnung der Beleuchtung für größere Szenen ist
aber auch mit der heute zur Verfügung stehenden Rechenleistung
nicht in akzeptabler Zeit möglich. Deshalb müssen in der Praxis Vereinfachungen vorgenommen werden, die es erlauben, eine hinreichende Näherung der Beleuchtungssituation schnell zu berechnen.
Modelle zur Berechnung der Beleuchtung in dreidimensionalen
Szenen werden Beleuchtungsmodelle genannt. Man unterscheidet
hierbei zwischen lokalen Beleuchtungsmodellen (siehe Kap. 1.2.3), die
nur den Einfluss der Lichtquellen auf die Oberflächen berechnen und
Wechselwirkungen der Oberflächen untereinander außer Acht lassen,
und globalen Beleuchtungsmodellen (siehe Kap. 1.2.6), die auch solche Wechselwirkungen berücksichtigen.
Globale Beleuchtungsmodelle erfordern einen wesentlich höheren
Berechnungsaufwand als die lokalen, weshalb sie in der Regel für interaktive Anwendungen, die eine sehr schnelle Bildberechnung erfordern, nicht in Betracht kommen. Globale Beleuchtungsmodelle erreichen aber einen wesentlich höheren Realitätsgrad.

1.2.1
Die Beleuchtungsgleichung
Für eine physikalisch korrekte Simulation der Lichtausbreitung in
einer Szene müssen die Reflexionen an den Oberflächen der Szene
möglichst genau modelliert werden. Die physikalischen Vorgänge bei
der Lichtausbreitung in dreidimensionalen Szenen sind denen der
Wärmeausbreitung in der Thermodynamik sehr ähnlich.
Im Jahr 1986 veröffentlichte Kajiya eine Übertragung der Wärmeleitungsgleichung auf das Problem der Lichtausbreitung und stellte in
[Ka86] die allgemeine Beleuchtungsgleichung vor. Diese Gleichung ist
gegeben durch
Beleuchtungsgleichung

L(x,ωr ) = LE (x, ωr ) + LR (x,ωr )

mit
LR (x,ωr ) = ∫ ρ (x,ωr ,ωi )L(x′,ωr )H (x, x′)
F

50

■
■
■

1 Computergrafik und Virtual Reality

cosφi cosφ0
dx ′
2
x − x′

für alle Oberflächenpunkte x in der Szene und alle Richtungen ωr.
Dabei ist
•
•
•
•
•

F die Menge aller Oberflächenpunkte der Szene
L(x,ωr) die Leuchtdichte am Punkt x in Richtung ωr
LE(x,ωr) die emittierte Leuchtdichte am Punkt x in Richtung ωr
LR(x,ωr) die reflektierte Leuchtdichte am Punkt x in Richtung ωr
H(x,x’) die Sichtbarkeitsfunktion zwischen x und x’. Sie ist 1 im Fall
der Sichtbarkeit und 0 im Fall einer Verdeckung
• φi der Winkel zwischen der Oberflächennormalen am Punkt x und
der Verbindungslinie zwischen x und x’
• φ0 der Winkel zwischen der Oberflächennormalen am Punkt x’ und
der Verbindungslinie zwischen x und x’
• ρ (x,ωr ,ωi ) die bidirektionale Reflexionsfunktion
Die bidirektionale Reflexionsfunktion (in der englischen Literatur
als bidirectional reflection distribution function (BRDF) bezeichnet)
gibt dabei an, welcher Anteil der aus Richtung ωi am Punkt x einfallenden Leuchtdichte in Richtung ωr reflektiert wird. Dabei sei ωi die
Richtung, aus der Strahlungsleistung vom Punkt x’ auf den Punkt x
einstrahlt.
Gesucht ist eine Funktion L(x,ωr), die diese Beleuchtungsgleichung
löst und für die das Integral

∫

Bidirektionale Reflexionsfunktion (BRDF)

L(x,ωr ) d(x, ωr )
2

F×Ω

existiert (Funktion endlicher Energie). Dabei läuft x über alle Oberflächenpunkte der Szene und ωr über alle Raumrichtungen des oberen
Halbraumes Ω über dem Punkt x. Mathematisch formuliert gehört die
2
Funktion L zum Raum L . Der mathematisch interessierte Leser findet
weitere Details hierzu z. B. in [We00].
Eine Lösung dieser allgemeinen Beleuchtungsgleichung zu bestimmen ist eine äußerst komplexe Aufgabe, die auch mit modernen
Techniken der Numerik nicht einfach gelöst werden kann. Die größten Schwierigkeiten dabei sind:
• Es handelt sich um eine zweidimensionale Integralgleichung.
• Die Sichtbarkeitsfunktion H ist sehr aufwendig zu bestimmen.
• Die bidirektionale Reflexionsfunktion muss für jeden Oberflächenpunkt für jede Einstrahl- und jede Reflexionsrichtung berechnet
werden. Auch die Speicherung dieser Funktion wäre extrem aufwendig, wenn sie bestimmt werden könnte.

Dennoch werden selbst durch diese komplexe Gleichung nicht alle
in der Realität auftretenden Beleuchtungseffekte erfasst. So kann es

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

51

z. B. vorkommen, dass Licht, das auf eine Oberfläche trifft, diese nicht
am selben Punkt wieder verlässt, sondern eine kurze Strecke innerhalb der Oberfläche zurücklegt, um an anderer Stelle wieder auszutreten. Auch die Wellenlänge des Lichtes kann bei der Reflexion verändert werden. Um diese Effekte abzudecken, muss die BRDF durch eine
sog. BSSRDF (bidirectional scattering surface reflectance distribution
function) ersetzt werden. Weitere Details dazu finden sich z. B. in
[JM01].

1.2.2
Farben in der Computergrafik
Das sichtbare Licht besteht aus einem kontinuierlichen Wellenlängenspektrum von ca. 400 nm bis 800 nm. Eine korrekte Beleuchtungsberechnung müsste also dieses komplette Spektrum berücksichtigen,
d. h., die Beleuchtung müsste mit Hilfe von Funktionen über diesem
Spektrum angegeben werden.
Das menschliche Auge ist aber nicht in der Lage, das komplette
Wellenlängenspektrum als solches wahrzunehmen. Die Netzhaut des
Auges besitzt drei Arten von Zäpfchen, die für das Farbsehen verantwortlich sind. Die Reize dieser drei Zäpfchenarten bestimmen den
wahrgenommenen Farbeindruck.
Um einen bestimmten Farbeindruck zu erzeugen, ist es deshalb
nicht notwendig, eine bestimmte Spektralverteilung zu erzeugen, sondern es genügt, eine Spektralverteilung (aus unendlich vielen möglichen) zu wählen, die bei den drei Zäpfchenarten die entsprechenden
Reize auslöst.
Deshalb ist es möglich, (fast) jeden Farbeindruck durch eine Kombination von drei geeigneten Grundfarben zu erzeugen. Bei aktiven
Anzeigegeräten wie Monitoren oder Projektoren werden dazu die
Farben Rot, Grün und Blau verwendet. In der Drucktechnik kommen
deren komplementäre Farben Cyan, Magenta und Gelb zum Einsatz.
Die Berechnung der Beleuchtung wird deshalb meist separat für die
drei Grundfarben Rot, Grün und Blau durchgeführt, was Darstellungen in voller Farbe erlaubt.
Eine ausführliche Einführung in Lichtmodellierung und Wahrnehmung ist zum Beispiel in [Gl95] zu finden.

1.2.3
Lokale Beleuchtungsmodelle und Shading
Ein Beleuchtungsmodell beschreibt, wie die Beleuchtung eines Oberflächenpunktes in einer dreidimensionalen Szene zu berechnen ist. Daraus ergibt sich dann der Farbwert für die Darstellung dieses Punktes

52

■
■
■

1 Computergrafik und Virtual Reality

auf einem Ausgabegerät. Ein Shading-Algorithmus beschreibt, an welchen Punkten eines geometrischen Objektes die Beleuchtung berechnet wird und wie die Pixel, die von diesem Objekt bedeckt werden,
dann zu füllen sind.
Obwohl bei lokalen Beleuchtungsmodellen bereits die gegenseitigen Wechselwirkungen der Flächen ignoriert werden, ist es notwendig, weitere Vereinfachungen vorzunehmen. Sowohl die Abstrahleigenschaften realer Lichtquellen als auch die Reflexionseigenschaften
von Oberflächen sind sehr komplex. Eine exakte Berechnung wäre
sehr aufwendig. Die Berechnung wird deshalb eingeschränkt auf wenige idealisierte Lichtquellen- und Reflexionstypen.
1.2.3.1
Lichtquellen

Punktlichtquellen strahlen Licht von einem Punkt aus gleichmäßig in
alle Richtungen des Raumes. Eine Punktlichtquelle wird definiert
durch ihre Position und ihre Lichtstärke I (in Candela). Sie bewirkt
2
eine Beleuchtungsstärke von E=cosφ⋅I/r (in lux) auf einem Oberflächenpunkt in der Entfernung r. Dabei ist φ der Winkel zwischen der
Lichteinfallsrichtung und der Oberflächennormalen (siehe Abb. 1.39).
Bei einem Strahler ist die Lichtausstrahlung auf einen Lichtkegel
begrenzt. Dabei ist die Lichtstärke im Zentrum des Kegels maximal
und nimmt nach außen hin zum Rand des Kegels ab. Ein Strahler wird
definiert durch seine Position, Lichtabstrahlrichtung, Öffnungswinkel,
Abschwächungsexponent und seine Lichtstärke. Er bewirkt innerhalb
n
2
seines Lichtkegels eine Beleuchtungsstärke von E=(cosθ) ⋅cosφ⋅I/r (in
lux) auf einen Oberflächenpunkt in der Entfernung r. Dabei ist n der
Abschwächungsexponent, φ der Winkel zwischen der Lichteinfallsrichtung und der Oberflächennormalen, θ der Winkel zwischen der
Lichtabstrahlrichtung der Lichtquelle und der Richtung von der Lichtquelle zum Oberflächenpunkt (siehe Abb. 1.40).

Abb. 1.39:
Punktlichtquelle

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

53

Abb. 1.40:
Strahler

Abb. 1.41:
Richtungslichtquelle

Richtungslichtquellen sind unendlich ferne Lichtquellen. Ihre Strahlen fallen parallel aus einer konstanten Richtung ein (wie z. B. das Sonnenlicht). Eine Richtungslichtquelle wird definiert durch ihre Rich2
tung und die spezifische Lichtausstrahlung M (in Lumen/m ). Sie
bewirkt auf einem Oberflächenpunkt eine Beleuchtungsstärke von
E=M⋅cosφ. Dabei ist φ der Winkel zwischen der Lichteinfallsrichtung
und der Oberflächennormalen (siehe Abb. 1.41).
Umgebungslicht (ambiente Lichtquelle): gibt es als Lichtquellentyp
in der Realität nicht. Da bei lokalen Beleuchtungsmodellen der Einfluss
anderer Oberflächen wie z. B. die indirekte Beleuchtung unberücksichtigt bleibt, wären viele Teile einer Szene, die nicht direkt von einer
Lichtquelle beleuchtet werden, völlig dunkel. Das ambiente Licht soll
die fehlende indirekte Beleuchtung in der Szene ersetzen. Es fällt auf
alle Flächen der Szene mit gleicher Beleuchtungsstärke ein und wird
deshalb auch durch die Beleuchtungsstärke (in lux) charakterisiert.
1.2.3.2
Reflexionstypen

Diffuse Reflexion: Bei ideal diffuser Reflexion (auch Lambert’sche Reflexion genannt) wird einfallendes Licht gleichmäßig in den gesamten
Halbraum oberhalb der Fläche reflektiert, und zwar so, dass die reflek2
tierte Leuchtdichte (in cd/m ) in alle Reflexionsrichtungen gleich ist.

54

■
■
■

1 Computergrafik und Virtual Reality

Abb. 1.42:
Diffuse Reflexion

Die reflektierte Leuchtdichte Lr ist dann durch das Lambert’sche Cosinus-Gesetz gegeben:

⎧ ρ ⋅ L ⋅ cos φ
Ld = ⎨ d
⎩0

für φ < 90°
sonst

Lambert’sches Cosinus-Gesetz

Dabei ist L die einfallende Leuchtdichte, 0≤ρd<1 der diffuse Reflexionsgrad der Oberfläche und φ der Einfallswinkel des Lichts (siehe
Abb. 1.42).
Ideal spiegelnde Reflexion: Für die ideal spiegelnde Reflexion gilt das
aus der Optik bekannte Reflexionsgesetz. Ein auf die Oberfläche auftreffender Lichtstrahl wird, ohne sich zu streuen, so reflektiert, dass der
einfallende Strahl, die Flächennormale und der reflektierte Strahl in
einer Ebene liegen und der einfallende und der reflektierte Strahl mit
der Flächennormalen jeweils denselben Winkel bilden.
Abb. 1.43:
Ideal spiegelnde Reflexion

Spekulare Reflexion: In der Praxis trifft man häufig Oberflächen an,
die weder ideal diffus noch ideal spiegelnd reflektieren, sondern das
Licht mehr oder weniger unregelmäßig streuen. Sehr häufig beobachtet man aber, dass viel Licht in Richtungen nahe der ideal spiegelnden
Reflexion gestreut wird. So nimmt man auf glänzenden Oberflächen
an der Stelle einen hellen Lichtfleck wahr (auch Glanzlicht genannt),
an der sich eine Lichtquelle spiegeln würde, wenn die Oberfläche ideal
spiegelnd wäre.

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

55

Abb. 1.44:
Spekulare Reflexion

Dieses Phänomen wird durch die spekulare Reflexion modelliert,
die ein Maximum in Richtung der idealen Spiegelung aufweist. Die
reflektierte Leuchtdichte ist gegeben durch:

⎧⎪ ρ ⋅ L ⋅ ( cos γ )m
Ls = ⎨ s
⎪⎩ 0

für γ < 90°
sonst

Dabei ist L die einfallende Leuchtdichte, 0≤ρs<1 der spekulare Reflexionsgrad der Oberfläche und γ der Winkel zwischen der betrachteten
Reflexionsrichtung und der Richtung der idealen Spiegelung (siehe
Abb. 1.43).
Ambiente Reflexion: Die ambiente Reflexion gibt es – wie die ambiente Lichtquelle – in der Realität nicht, sie reflektiert das Umgebungslicht und soll die in der Realität auftretende, aber bei lokalen Beleuchtungsmodellen unberücksichtigte indirekte Beleuchtung reflektieren.
Die reflektierte Leuchtdichte ist gegeben durch:
La = ρa ⋅ L

Dabei ist L die einfallende Leuchtdichte und 0≤ρa<1 der ambiente
Reflexionsgrad der Oberfläche.
1.2.3.3
Das Phong’sche Beleuchtungsmodell

In diesem Abschnitt wird das Phong’sche Beleuchtungsmodell vorgestellt, das bei (fast) allen Echtzeitdarstellungen zum Einsatz kommt
und von aktuellen Grafikkarten durch entsprechende Hardware unterstützt wird.
Das Phong’sche Beleuchtungsmodell ist ein empirisches Modell, das
Anfang der siebziger Jahre entwickelt wurde und mit geringem Aufwand realitätsnahe Darstellungen von Oberflächen erreichen sollte.

56

■
■
■

1 Computergrafik und Virtual Reality

Abb. 1.45:
Phong’sches Beleuchtungsmodell

Die berechnete Leuchtdichte setzt sich hierbei aus 3 einzeln zu berechnenden idealisierten Teilen zusammen:
LPhong = La + Ld + Ls
Dabei sind La, Ld und Ls ambient, diffus und spekular reflektierte Anteile (siehe Abb. 1.45).
1.2.3.4
Shading-Algorithmen

Da zur Darstellung von Dreiecken effiziente und ausgereifte Techniken zur Verfügung stehen, die von aktuellen Grafikkarten durch
Hardware-Implementierung unterstützt werden, werden geometrische
Objekte für die Echtzeitdarstellung durch Dreiecksnetze approximiert.
Die folgenden Abschnitte befassen sich deshalb mit Techniken zur
Darstellung von Dreiecken.
Ein Shading-Algorithmus beschreibt, an welchen Punkten eines
Dreiecks die Beleuchtung durch Auswertung eines Beleuchtungsmodells (wie z. B. des Phong’schen Beleuchtungsmodells) bestimmt wird
und wie daraus die Werte für die einzelnen Pixel des Dreiecks gewonnen werden.
Das Flat-Shading ist die einfachste Shading-Methode. Hier wird die
Beleuchtung an einem Punkt innerhalb des Dreiecks berechnet und

1.2 Bildberechnung – vom Modell zum Bild

Flat-Shading

■
■
■

57

Gouraud-Shading

Phong-Shading

das Dreieck dann mit konstanter Farbe gefüllt. Der Berechnungsaufwand für diese Methode ist zwar gering, die Darstellung gekrümmter
Oberflächen ist aber nicht realistisch, da die Triangulierungen der
Oberflächen deutlich sichtbar sind. Außerdem ist die Methode ungeeignet für Beleuchtungsmodelle mit spekularem Anteil, da hieraus
resultierende Glanzeffekte nicht sinnvoll wiedergegeben werden (siehe
Abb. 1.46).
Gouraud-Shading wurde 1971 von Henri Gouraud [Go71] vorgestellt. Hierbei wird die Beleuchtung an den Eckpunkten der Dreiecke
berechnet und die Leuchtdichten (oder Farbwerte) dann innerhalb der
Dreiecke linear interpoliert. Dadurch entsteht im Gegensatz zum FlatShading auch an den Kanten zwischen aneinandergrenzenden Dreiecken ein stetiger Farbverlauf.
Der Verlauf der Leuchtdichte (und damit der Farbverlauf) an den
Dreieckskanten ist aber nicht stetig differenzierbar, was bei starker
Änderung der Leuchtdichte zu sogenannten Machbandeffekten führen kann. Dies sind helle oder dunkle Linien, die das Auge an solchen
Stellen nicht stetiger Leuchtdichten-Änderung wahrnimmt. Solche
Machbandeffekte sind bei der mittleren Kugel in Abb. 1.46 im rechten
oberen Bereich deutlich zu erkennen.
Auch das Gouraud-Shading führt bei spekularen Reflexionen nicht
zu befriedigenden Ergebnissen, da auch hier die Glanzeffekte nicht hinreichend genau wiedergegeben werden.
Bei diffuser Reflexion sind die Ergebnisse aber trotz der auftretenden Machbandeffekte befriedigend. Das Verfahren lässt sich sehr gut
in den Prozess der Rasterung integrieren und kann effizient realisiert
werden.
Beim Phong-Shading werden die an den Eckpunkten der Dreiecke
vorliegenden 3D-Positionen und Normalen im Innern der Dreiecke
linear interpoliert. Bei der Rasterisierung der Dreiecke wird für jedes
Pixel mit Hilfe der so interpolierten 3D-Position und Normalen das
Beleuchtungsmodell ausgewertet. Die Berechnung der Beleuchtung

Abb. 1.46:
Shading-Algorithmen

58

■
■
■

1 Computergrafik und Virtual Reality

erfolgt hier also pixelgenau, was zu einer korrekten Darstellung von
spekularen Reflexionen führt (siehe Abb. 1.46).
Machbandeffekte sind bei dieser Shading-Methode zwar teilweise
noch zu erkennen, aber im Vergleich zu Gouraud-Shading stark reduziert. (Die hier auftretenden Machbandeffekte sind auf Unstetigkeiten
höherer Differentiationsordnung zurückzuführen, die das Auge in
manchen Situationen immer noch wahrnimmt.)
Der Berechnungsaufwand beim Phong-Shading ist wesentlich höher als beim Gouraud-Shading, da das Beleuchtungsmodell für jedes
Pixel ausgewertet werden muss und 3D-Positionen und Normalen
interpoliert werden müssen. Die interpolierten Normalen müssen vor
der Auswertung des Beleuchtungsmodells jeweils normiert werden,
was die Berechnung einer Quadratwurzel erfordert. Um den Aufwand
zu reduzieren, wird in manchen Implementierungen auf die Normierung verzichtet, was aber zu Fehlern in der Berechnung führt und
Machbandeffekte verstärkt.

1.2.4
Verdeckungsrechnung
Ein grundlegendes Problem bei der Bilderzeugung aus dreidimensionalen Modellen ist die Bestimmung der Objektteile, die von einer gegebenen Kameraposition aus sichtbar sind.
Werden bei der perspektivischen Projektion mehrere Objekte auf
dieselbe Position der Bildebene abgebildet, verdecken sie sich gegenseitig. Nur das Objekt, das der Kameraposition am nächsten liegt, ist
sichtbar.
Zur Lösung des Verdeckungsproblems gibt es zwei unterschiedliche Klassen von Verfahren: Objektraumverfahren und Bildraumverfahren. Objektraumverfahren arbeiten mit den analytischen
3D-Objekten und bestimmen die sichtbaren Teile dieser Objekte direkt im Objektraum. Bildraumverfahren arbeiten mit den diskreten
Daten des Ausgabegerätes und ermitteln für jedes Pixel das Polygon,
das an diesem Pixel sichtbar ist.
Der z-Buffer-Algorithmus wurde 1974 von W. Strasser [St74] vorgeschlagen. Weil er zusätzlichen Speicherplatz erfordert, der zu dieser
Zeit noch sehr teuer war, wurde er damals aber aus Kostengründen
nicht realisiert. Bereits seit vielen Jahren ist der z-Buffer-Algorithmus
nun das Standardverfahren zur Behandlung der Verdeckung bei der
Bilderzeugung.
Dabei wird der Bildspeicher erweitert, und für jedes Pixel wird zusätzlich zum Farbwert ein Tiefenwert (z-Wert) gespeichert, der den
Abstand des an diesem Pixel gezeichneten Objektpunktes von der
Bildebene angibt.

1.2 Bildberechnung – vom Modell zum Bild

z-Buffer Algorithmus

■
■
■

59

Painters-Algorithmus

Kombination von z-Buffer und
Painters-Algorithmus

60

■
■
■

Zu Beginn der Bilderzeugung werden die z-Werte aller Pixel mit
dem maximal möglichen z-Wert initialisiert. Anschließend werden die
Polygone der Szene in beliebiger Reihenfolge mit der Bildauflösung
gerastert. Dabei werden die z-Werte innerhalb der Polygone für jedes
Pixel perspektivisch korrekt interpoliert. Für jedes Pixel kann nun
festgestellt werden, ob an diesem Pixel bereits ein Polygon gezeichnet
wurde, das sich näher an der Bildebene befindet (und deshalb das
aktuelle Polygon verdeckt), indem der aktuelle z-Wert mit dem im
z-Buffer gespeicherten Wert verglichen wird. Nur wenn der aktuelle
z-Wert kleiner ist, wird das Pixel gezeichnet und der z-Buffer entsprechend neu gesetzt.
Alle aktuellen Grafikkarten unterstützen den z-Buffer-Algorithmus
in Hardware und erlauben so die Lösung des Verdeckungsproblems
bei der Bilderzeugung praktisch ohne Zeitverlust.
Der z-Buffer-Algorithmus führt auf der anderen Seite aber auch zu
den für Rasterverfahren typischen Problemen. Eine exakte Glättung
(Antialiasing) von Objektkanten ist prinzipiell nicht möglich. Diese
Probleme können aber durch Supersampling (Rasterung auf Subpixelebene) oder anschließende Filterung reduziert werden. Ein weiterer
Nachteil ist, dass der z-Buffer-Algorithmus für transparente Objekte
nicht verwendet werden kann. Dafür kommt deshalb häufig der nachfolgend beschriebene Algorithmus zum Einsatz.
Beim Painters-Algorithmus werden die Objekte so gezeichnet, wie
dies ein Maler bei einem Ölgemälde gewöhnlich tut: Er beginnt mit
den am weitesten entfernten Objekten und übermalt diese dann durch
näher liegende Objekte.
Die Polygone werden zuerst nach ihrem Abstand von der Kamera
sortiert. Dabei kann es notwendig sein, Polygone in einzelne Teile aufzuspalten, um eine eindeutige Sortierung erreichen zu können. Anschließend werden die Polygone von hinten nach vorne gezeichnet.
Dieser Algorithmus führt auch bei transparenten Objekten zu einem korrekten Ergebnis. Ein Nachteil ist aber, dass die Sortierung
(und eventuell auch die Aufspaltung der Polygone) bei Änderung der
Kameraposition neu bestimmt werden muss.
Da bei Kamerafahrten die Tiefensortierung bei benachbarten Kamerapositionen häufig sehr ähnlich ist, führt aber z. B. der BubbleSort-Algorithmus, ausgehend von der vorhergehenden Sortierung,
schnell zu einer Lösung. Die Sortierung lässt sich durch geeignete
Verfahren, wie z. B. die Verwendung von BSP-Bäumen (binary space
partitioning) oder Octrees, wesentlich beschleunigen.
Häufig werden bei der Bilderzeugung zuerst alle nicht transparenten
Objekte mit Hilfe des z-Buffer-Algorithmus gezeichnet. Anschließend
werden die transparenten Objekte mit Hilfe des Painters-Algorithmus
hinzugefügt. Der z-Buffer kann dann auch hier verwendet werden, um

1 Computergrafik und Virtual Reality

die transparenten Objekte korrekt zwischen die nicht transparenten
einzufügen.

1.2.5
Mapping-Techniken
Die Darstellung von Objekten mit lokalen Beleuchtungsmodellen
hängt vom Einfluss der Lichtquellen auf die Oberflächen und von
deren Reflexionseigenschaften ab. In der Regel arbeitet man dabei mit
einer Triangulierung der Oberflächen. Die Reflexionseigenschaften
werden innerhalb der einzelnen Dreiecke konstant gehalten.
In der Praxis trifft man aber häufig Oberflächen mit feinen und
komplexen Farbstrukturen an, wie z. B. Marmor, Holzmaserungen,
Tapeten oder Bilder. Um solche Oberflächen korrekt darstellen zu
können, wäre eine sehr feine, an die Farben der Oberflächen angepasste Triangulierung notwendig. Auch die geometrische Struktur der
Oberflächen ist häufig sehr komplex, wie z. B. bei der Schale einer
Orange. Ein korrektes geometrisches Modell wäre hier sehr aufwendig
und würde zu einer riesigen Anzahl von Dreiecken führen.
Um dies zu vermeiden, werden Mapping-Techniken eingesetzt, die
es erlauben, die Oberflächeneigenschaften zu modulieren. Dieser Vorgang kann mit dem Tapezieren einer Wand verglichen werden. Das
geometrische Modell der Wand besteht aus einem ebenen Rechteck
(oder zwei in einer Ebene liegenden Dreiecken), die Oberflächenfarbe
wird durch ein aufgeklebtes zweidimensionales Bild definiert.
Auf diese Weise lassen sich aber nicht nur Farben manipulieren,
sondern auch andere Oberflächeneigenschaften, wie z. B. die Oberflächennormalen. Selbst die Parameter von Beleuchtungsmodellen können so manipuliert werden. Abbildung 1.47 zeigt ein ebenes Rechteck,
bei dem mit Hilfe von Mapping-Techniken verschiedene Parameter
moduliert wurden.
Abb. 1.47:
Einsatz von Mapping-Techniken
auf einem ebenen Rechteck

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

61

1.2.5.1
Textur-Mapping

Unter Textur-Mapping verstehen wir hier Mapping-Techniken, welche die Reflexionseigenschaften (und damit die Farben) von Oberflächen beeinflussen.
Eine zweidimensionale Textur ist formal eine Abbildung, die Punkte
(u,v) des zweidimensionalen Texturraums auf (r,g,b)-Farben abbildet.
Abb. 1.48:
Textur: Jedem Punkt (u,v) wird
ein Farbwert zugeordnet

Texturkoordinaten

Gewöhnlich wird der Texturraum auf den Parameterbereich [0,1]×
[0,1] beschränkt, und die Texturen werden entsprechend in diesen
Bereich skaliert.
Um eine Textur auf eine Oberfläche aufbringen zu können, müssen
allen Punkten der Oberfläche eindeutige Koordinaten im Texturraum,
die sog. Texturkoordinaten, zugeordnet werden.
Bei triangulierten Modellen geschieht dies durch Zuordnung von
Texturkoordinaten an allen Dreiecks-Eckpunkten (auch Vertices genannt), die dann im Innern der Dreiecke interpoliert werden. Dabei
ist allerdings zu beachten, dass die Interpolation perspektivisch korrekt durchgeführt wird. Einfache bilineare Interpolation in der Bildebene führt zu einem falschen Ergebnis.

Abb. 1.49:
Texturkoordinaten zur Positionierung
der Textur auf der Oberfläche

62

■
■
■

1 Computergrafik und Virtual Reality

Bei Triangulierungen parametrischer Flächen, wie z. B. ebenen
Rechtecken, Zylindermänteln, Kugeln oder B-Spline-Flächen, lässt
sich leicht eine Zuordnung von Texturkoordinaten zu den Eckpunkten der Dreiecke aus der Parametrisierung ableiten. Bei nicht parametrischen Flächen ist diese Zuordnung jedoch in der Regel nicht
trivial. Eine häufig angewandte Methode zur TexturkoordinatenBestimmung ist die Projektion der Objekte auf Ebenen, Zylinder oder
Kugeln, um dann die Parametrisierung dieser Flächen zur Texturkoordinaten-Bestimmung heranzuziehen.
Viele Softwareprodukte bieten auch Werkzeuge zur interaktiven
Zuordnung von Texturkoordinaten. So können z. B. Kanten definiert
werden, an denen die Flächen in einzelne Teilflächen aufgetrennt
werden, die dann in die Ebene abgewickelt werden können. Diese
Abwicklung kann dann über die Textur gelegt werden. Durch Verschieben der einzelnen Dreiecks-Eckpunkte kann die Texturkoordinaten-Zuordnung interaktiv angepasst werden.
Soll eine Textur auf einer Oberfläche mehrfach wiederholt werden,
lässt man Texturkoordinaten kleiner als 0 oder größer als 1 zu. Beim
Zugriff auf die Textur wird dann der ganzzahlige Anteil der Koordinaten ignoriert.
Eine Texturabbildung, die Texturkoordinaten (u,v) auf (r,g,b)Farben abbildet, kann entweder als prozedurale oder als diskrete Textur gegeben sein. Bei prozeduralen Texturen wird der Farbwert zu
einem Koordinatenpaar (u,v) mit Hilfe einer mathematischen Funktion ermittelt. Diskrete Texturen, die in der Praxis weitaus häufiger
Verwendung finden, sind einfach durch Pixelbilder gegeben. Jedes
Pixel der Textur (auch Texel genannt) repräsentiert dabei den Farbwert zu einem bestimmten Texturkoordinaten-Paar. Farbwerte zu
beliebigen Texturkoordinaten-Paaren werden in der Regel durch bilineare Interpolation der Farbwerte der vier benachbarten Texel bestimmt. Textur-Mapping mit diskreten Texturen wird von den Grafikkarten in Hardware unterstützt.

Prozedurale und diskrete Texturen

1.2.5.2
Bump-Mapping

Beim Bump-Mapping werden Abbildungen verwendet, die Punkte
(u,v) des zweidimensionalen Texturraums auf Grauwerte abbilden.
Diese Grauwerte werden als Höhenwerte über der Objektoberfläche
interpretiert, mit deren Hilfe die Oberflächennormalen für die Beleuchtungsrechnung manipuliert werden. Aufgrund der dadurch entstehenden Verdunklungen, Aufhellungen und Glanzlichter nimmt der
Betrachter Vertiefungen und Erhebungen auf der Oberfläche war. Dies

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

63

ist in Abb. 1.47 deutlich zu erkennen, die ein ebenes Rechteck zeigt,
das mit einer Textur-Map und einer Bump-Map versehen ist.
Da bei diesem Verfahren nur die Beleuchtungsrechnung beeinflusst
wird, die Position der Oberflächenpunkte aber unverändert bleibt,
erhält man bei schrägem Blickwinkel keine Parallaxenverschiebung,
wie dies bei einer echten Oberflächenerhebung der Fall wäre. Dies
führt zum einen zu einer verzerrten Darstellung der Texturen, zum
anderen werden die Objektkonturen von Bump-Maps nicht beeinflusst. Das heißt, die Kontur einer Kugel besteht auch dann aus einem
exakten Kreis, wenn sie mit einer Bump-Map versehen ist.
Solche Probleme werden z. B. durch das sogenannte DisplacementMapping [Co84] oder das Parallax-Mapping [KT01] adressiert.
1.2.5.3
Reflexions- und Umgebungs-Mapping

Beim Reflexions-Mapping [MH84; HS93]werden mit Hilfe von Texturen Spiegelungen auf Objektoberflächen simuliert. Da Spiegelungen
von der Beobachterposition abhängen und sich bei Bewegung des
Beobachters ihre Position ändert, können Spiegelungen nicht fest mit
Hilfe einer Textur auf eine Oberfläche gemappt werden.
Beim Reflexions-Mapping werden Reflexionen mit Hilfe von Texturierungs-Hardware approximativ berechnet. Zugrunde liegt dabei
die folgende Beobachtung: Ist ein Objekt sehr klein im Vergleich zur
Entfernung der Objekte, die sich in seiner Oberfläche spiegeln, so
hängt die gespiegelte Leuchtdichte im Wesentlichen von der Reflexionsrichtung ab, während die exakte Oberflächenposition nur eine
untergeordnete Rolle spielt.
Ignoriert man die Oberflächenposition, so hängt die Spiegelung nur
noch von der Reflexionsrichtung ab, die sich mit zwei Werten parametrisieren lässt. Damit wird es möglich, Spiegelungen für ein Objekt im
Voraus zu berechnen und in einer zweidimensionalen Textur zu speichern. Man kann sich das so vorstellen, dass das Objekt von einer virtuellen Kugel umgeben ist, an deren Innenseite sich die Szenenumgebung
befindet. Bei der Bilderzeugung können Spiegelungen nun in Echtzeit
an der Innenseite der Kugel abgelesen werden, indem aus der Blickrichtung und der Oberflächennormalen die Reflexionsrichtung berechnet
wird. Deshalb spricht man häufig auch von Umgebungs-Mapping.
Abbildung 1.50 zeigt dazu eine schematische Darstellung. Die
durch den gestrichelten Vektor gekennzeichnete exakte Reflexion
wird näherungsweise durch die Reflexion ersetzt, die durch den gepunkteten Vektor gegeben ist. Dies ist die Reflexion, die man vom
Zentrum der Kugel aus beobachten würde.

64

■
■
■

1 Computergrafik und Virtual Reality

Abb. 1.50:
Approximative Berechnung der
Spiegelung beim Umgebungs-Mapping

In der Praxis ist für die Umgebungstextur eine geeignete Parametrisierung erforderlich. Dafür gibt es verschiedene Alternativen, wie
z. B. die Verwendung von Kugelkoordinaten, die Projektion auf die
Seiten eines umgebenden Würfels oder das sog. Sphere-Mapping, das
von OpenGL® und Direct3D® (siehe Kap. 1.2.7) für Echtzeitanwendungen unterstützt wird.
Eine Sphere-Map enthält das Bild, das man sehen würde, wenn
man eine ideal spiegelnde Kugel betrachten würde, die sich an der
Position des spiegelnden Objektes befindet.
Eine Umgebungstextur liefert die korrekte Spiegelung der Umgebung, wenn sich ein Oberflächenpunkt genau im Zentrum des spiegelnden Objektes befindet und, je nach verwendetem Verfahren, wenn
außerdem die Blickrichtung dieselbe ist, die bei der Erzeugung der
Umgebungstextur verwendet wurde. An anderen Positionen oder
eventuell auch bei Betrachtung aus anderer Blickrichtung ist das Ergebnis nicht mehr exakt. Bei stark gekrümmten Oberflächen, wie z. B.
Türgriffen, Töpfen usw., erscheint das Ergebnis aber trotzdem sehr
realistisch, da der Beobachter nicht in der Lage ist, die Ungenauigkeiten wahrzunehmen.
Abb. 1.51:
Sphere-Map:
Die Spiegelung im rechten Bild wurde
mit Hilfe der im linken Bild dargestellten
Sphere-Map erzeugt

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

65

1.2.5.4
Texturfilterung

Footprint

Bei der Verwendung diskreter Texturen kommt es häufig vor, dass diese
Texturen verkleinert dargestellt werden. Das heißt, mehrere Texel einer
Textur werden auf dasselbe Bildschirmpixel abgebildet. In solchen Fällen kommt es zu einer Unterabtastung der Textur und zu Abtastfehlern
im Bild. Abbildung 1.52 zeigt eine Rechtecksfläche unter schrägem Betrachtungswinkel, die mit einer Schachbrett-Textur versehen ist. Im
weiter entfernten Bereich, in dem die Textur aufgrund der Perspektive
verkleinert dargestellt wird, sind die Abtastfehler deutlich zu erkennen.
Mathematisch kann dieses Verhalten mit Hilfe des Abtasttheorems von
Whittaker, Kotelnikow und Shannon [Je77] erklärt werden.
Um solche Abtastfehler zu verhindern, muss entweder die Abtastrate erhöht werden, indem die einzelnen Pixel in mehrere Subpixel
aufgeteilt werden, oder die Textur ist mit einem Tiefpassfilter zu filtern, was moderne Grafikkarten in Hardware unterstützen.
Der Bereich einer Textur, der bei der Darstellung auf ein Bildschirmpixel fällt, wird Footprint genannt. Eine korrekte Texturfilterung bestünde in der Mittelwertbildung der Texel des Footprints (entsprechend ihrer Entfernung vom Bildschirm-Pixel gewichtet). Dieser
Mittelwert wird bei praktikablen Verfahren durch einfachere Mittelwerte ersetzt, die leichter und im Voraus zu berechnen sind.

Abb. 1.52:
Abtastfehler

Abb. 1.53:
Mipmap-Pyramide

66

■
■
■

1 Computergrafik und Virtual Reality

Das wohl wichtigste Verfahren zur Texturfilterung in Echtzeitanwendungen ist das sog. Mipmap-Verfahren. Dabei werden die Texturen, deren Größe in x- und in y-Richtung jeweils eine Zweierpotenz
sein muss, in fortlaufend halbierten Auflösungsstufen gespeichert, so
dass eine Pyramide von Texturen entsteht, deren Spitze nur noch ein
einzelnes Pixel enthält.
Je nach Größe des Footprints (die mit Hilfe der partiellen Ableitungen der (u,v)-Koordinaten nach den Bildschirmachsen abgeschätzt werden kann) wird dann auf eine entsprechend verkleinerte
Textur der Mipmap zugegriffen oder zwischen zwei benachbarten
Mipmap-Stufen interpoliert. In diesem Fall spricht man auch von
trilinearer Interpolation, da die Farbwerte zwischen den MipmapStufen linear und innerhalb der Mipmap-Stufen bilinear interpoliert
werden. Eine ausführliche Beschreibung des Mipmap-Verfahrens
finden Sie in [Wi83].
Das Mipmap-Verfahren lässt sich sehr gut in Hardware implementieren. Die verkleinerten Texturen der einzelnen Mipmap-Stufen lassen sich im Voraus berechnen, und der Speicherbedarf beträgt lediglich ein Drittel dessen, was für die Originaltextur benötigt wird.
Der Footprint wird beim Mipmap-Verfahren aber immer durch ein
Rechteck approximiert, das dasselbe Seitenverhältnis besitzt wie die
Originaltextur. Die Richtungsabhängigkeit des Footprints bleibt dabei
unberücksichtigt. Vor allem bei schrägem Betrachtungswinkel von
texturierten Oberflächen werden deshalb Mittelwerte über zu große
Bereiche der Textur gebildet, was dazu führt, dass die Texturen unscharf werden.
Beim Footprint Assembly [SK96] werden solche Probleme weitgehend vermieden (siehe Abb. 1.54. Hierbei handelt es sich um ein sog.
anisotropes Verfahren, das die Richtungsabhängigkeit des Footprints
berücksichtigt. Dabei wird der Footprint durch mehrere Rechtecke
approximiert, deren Mittelwert jeweils mit Hilfe einer Mipmap bestimmt werden kann. Anstatt eines Zugriffs auf ein Mipmap-Level
grober Auflösung werden also mehrere Zugriffe auf MipMap-Levels

Mipmap-Verfahren

Footprint Assembly

Abb. 1.54:
Texturfilterung mit
Mipmapping (links) und
Footprint Assembly (rechts)

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

67

feinerer Auflösung gemittelt, wodurch der eigentliche Footprint wesentlich genauer angenähert werden kann.

1.2.6
Globale Beleuchtung
Anders als bei den lokalen Beleuchtungsmodellen, bei denen die möglichst schnelle und effiziente Berechnung im Vordergrund steht, wird
bei globalen Beleuchtungsmodellen ein möglichst realistisches Ergebnis angestrebt. Dazu werden auch Wechselwirkungen der Oberflächen
untereinander in die Berechnung einbezogen, wie z. B. Schattenwurf,
Spiegelungen, Brechungen oder indirekte Beleuchtung.
Da die Lösung der allgemeinen Beleuchtungsgleichung (siehe
Kap. 1.2.1) zu aufwendig wäre, werden auch bei den globalen Beleuchtungsverfahren wieder Vereinfachungen vorgenommen. Die im Folgenden vorgestellten Verfahren berechnen also keine Lösung dieser
allgemeinen Gleichung, sondern berücksichtigen jeweils nur einen Teil
der möglichen Wechselwirkungen zwischen den Oberflächen der Szene.
1.2.6.1
Raytracing

Raytracing ist ein optisches Verfahren, das ideale Spiegelungen und
Lichtbrechungen berücksichtigt. Die Idee besteht darin, Lichtstrahlen
auf ihrem Weg von den Lichtquellen durch die Szene bis zum Auge
des Beobachters zu verfolgen. Da nur solche Lichtstrahlen von Bedeutung sind, die auch tatsächlich das Auge des Beobachters treffen, werden die Strahlen beim klassischen Raytracing rückwärts vom Auge
ausgehend durch die Szene verfolgt. Das heißt, man versucht die Frage
zu beantworten, woher die Strahlen kommen, die das Auge treffen.
Abb. 1.55:
Raytracing

68

■
■
■

1 Computergrafik und Virtual Reality

Um den Farbwert eines Pixels zu bestimmen, wird ein Primärstrahl
(auch Sehstrahl genannt) vom Auge ausgehend durch dieses Pixel in
die Szene geschossen und der nächstliegende Schnittpunkt dieses
Strahls mit den Szenenobjekten bestimmt. Die durch direkte Lichteinstrahlung auf diesen Schnittpunkt bedingte Leuchtdichte wird durch
Auswertung eines lokalen Beleuchtungsmodells (z. B. des PhongModells) an diesem Punkt bestimmt. Außerdem wird ein ideal reflektierter und ein ideal gebrochener Strahl berechnet, deren Leuchtdichte
rekursiv auf dieselbe Weise bestimmt wird. Diese Leuchtdichten werden dann gewichtet mit dem Reflexions- bzw. Refraktionskoeffizienten des Materials zu der zuvor berechneten Leuchtdichte addiert.
Um die Sichtbarkeit von Lichtquellen zu erkennen, werden vor der
Auswertung des lokalen Beleuchtungsmodells an den Schnittpunkten
Schattenstrahlen zu den Lichtquellen geschickt und auf Schnittpunkte
mit Szenenobjekten getestet. Es werden dann nur die Beiträge der
unverdeckten Lichtquellen berücksichtigt.
Die rekursive Strahlverfolgung wird abgebrochen, wenn ein Strahl
auf ein Objekt trifft, das weder spiegelt noch transparent ist, wenn ein
Strahl die Szene verlässt, wenn die durch einen Strahl transportierte
Abb. 1.56:
Raytracing-Bilder
berechnet mit PYTHA RAYTRA

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

69

Leuchtdichte zu gering wird oder wenn eine vorgegebene Rekursionstiefe überschritten wird.
Der weitaus größte Teil der Rechenleistung beim Raytracing wird
für die Schnittpunktberechnungen benötigt. Mit Hilfe geeigneter Beschleunigungstechniken, wie z. B. regulären Gittern, Octrees oder
Szenenhierarchien [ES97; Wi83], kann dieser Aufwand aber auf ein
praktikables Maß reduziert werden.
Raytracing liefert für Szenen mit hohem spiegelndem und transparentem Flächenanteil sehr gute Ergebnisse. Die Szenengeometrie kann
in analytischer Form gehalten werden, eine Triangulierung der Oberflächen ist nicht notwendig. Da die Berechnung blickpunktabhängig
ist, ist Raytracing zur Darstellung bei Echtzeitanwendungen nicht
geeignet. Diffuse indirekte Beleuchtung wird nicht berücksichtigt.
Als Kajiya 1986 die Beleuchtungsgleichung (siehe Kap. 1.2.1) vorstellte, bemerkte er, dass das Raytracing-Verfahren eine Lösung dieser
Gleichung berechnet, wobei das Intergral durch die Summe der direkten Beleuchtung und der beiden rekursiv berechneten Anteile ersetzt
wird.
Um weitere Beleuchtungseffekte berücksichtigen zu können, existieren verschiedene Erweiterungen des klassischen Raytracing-Algorithmus, wie z.B:
Pfad-Tracing

Photon-Tracing

70

■
■
■

• Pfad-Tracing: Hier werden an den Schnittpunkten nicht alle möglichen Aufspaltungen des Lichtstrahls rekursiv weiterverfolgt, sondern es wird zufällig eine Möglichkeit der Reflexion gewählt. So
verfolgt man einen einzelnen, zufällig gewählten Pfad der Lichtausbreitung. Bei dieser Vorgehensweise ist man nicht mehr auf ideale
Spiegelung und Brechung beschränkt, sondern kann beliebige
BRDFs abtasten und kann somit z. B. auch diffuse Reflexionen berücksichtigen. Um eine ausreichende Abtastung zu gewährleisten,
ist es aber notwendig, für jedes Pixel des Bildschirms eine größere
Anzahl an Strahlen zu verfolgen.
• Photon-Tracing (oder bidirektionales Raytracing): Dieses Verfahren
besteht aus zwei Schritten. Im ersten Schritt werden nach der Art
des Pfad-Tracing sogenannte Photonen, die eine bestimmte Energie
transportieren, von den Lichtquellen ausgehend durch die Szene
transportiert. Die Oberflächen werden mit Photonen-Maps versehen, die das Auftreffen von Photonen registrieren (in der Regel Gitter mit einer gewissen Auflösung). Dieser Schritt ist unabhängig
von der Beobachterposition. In einem zweiten Schritt wird mit klassischem Raytracing oder Pfad-Tracing ein Bild berechnet. Dabei
werden die im ersten Schritt an den Oberflächen der Szene gewonnenen Informationen benutzt. Mit Photon-Tracing lassen sich auch
diffuse Beleuchtungseffekte und Kaustiken berechnen [Je01].

1 Computergrafik und Virtual Reality

1.2.6.2
Radiosity

Das Radiosity-Verfahren ist ein globales Beleuchtungsverfahren, das
auf einer Einschränkung der Beleuchtungsgleichung (siehe Kap. 1.2.1)
auf ideal diffus reflektierende Oberflächen beruht. Solche Oberflächen
sind in Innenraumszenen häufig vorherrschend, weshalb das Radiosity-Verfahren hier Ergebnisse mit sehr hohem Realitätsgrad erreicht.
Die Einschränkung auf diffus reflektierende Oberflächen bedeutet,
dass die BRDF ρ(x,ωr ,ωi ) = ρ(x) unabhängig vom Einfallswinkel und
Ausfallswinkel ist und dass die reflektierte Leuchtdichte Lr (x,ωr ) = Lr (x)
unabhängig von der Abstrahlrichtung ist. Die Beleuchtungsgleichung
lautet damit
L(x) = LE (x) + LR (x)

mit
LR (x) = ρ (x)∫ L(x′)H (x, x′)
F

cosφi cosφ0
dx ′
2
x − x′

für alle Oberflächenpunkte x in der Szene.
Da alle Oberflächen diffus reflektierend sind, kann anstatt mit der
Leuchtdichte auch mit der spezifischen Ausstrahlung (englisch:
Radiosity) gerechnet werden, die mit dem Buchstaben B bezeichnet
wird. Dabei ist die spezifische Ausstrahlung B(x) an einem Punkt x
identisch mit dem Integral über L(x,ωr ) , wobei ωr über alle Winkel
des oberen Halbraumes Ω läuft:
B(x) = ∫ L(x, ωr )cosφr dωr = π L(x)
Ω

Ersetzt man πρ (x) durch den Reflexionsfaktor
0 ≤ ρ (x) < 1 , erhält man damit die Radiosity-Gleichung
B(x) = E(x) + ρ (x) ⋅ ∫ B(x ′)H (x, x ′)
F

ρ (x)

mit

Radiosity-Gleichung

cosφi cosφ0
dx ′
2
π x − x′

Gesucht ist hier eine Funktion B, die diese Gleichung erfüllt und für
die das Integral

∫

F

2

B(x) dx
2

existiert (eine Funktion aus dem Raum L ). Der mathematisch interessierte Leser findet ausführliche Informationen hierzu z. B. in [We05].

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

71

Klassisches Radiosity

Doch auch diese Gleichung ist für realistische Szenen nicht explizit
zu lösen. Man versucht deshalb, die Lösung dieser Gleichung durch
eine Linearkombination endlich vieler geeigneter Funktionen zu approximieren. Mathematisch formuliert wählt man einen endlichdi2
mensionalen Teilraum von L mit einer geeigneten Basis und löst die
auf diesen Teilraum projizierte korrespondierende Gleichung. Damit
erhält man eine Linearkombination der gewählten Basisfunktionen als
Lösung der Gleichung.
Beim klassischen Radiosity zerlegt man die Szene in n Flächenstücke Fi, i=1,...,n (auch Patches genannt), und wählt als Teilraum den
Raum der auf diesen Flächenstücken konstanten Funktionen. Das
heißt, man nimmt an, dass die Radiosity-Funktion auf jedem dieser
kleinen Flächenstücke konstant ist (B(x)=Bi für alle x∈Fi). Geht man
ferner davon aus, dass der Reflexionsfaktor ρ(x)=ρi auf jedem Flächenstück Fi konstant ist, erhält man die klassische RadiosityGleichung:
n

Bi = E i + ρi ∑ B j
j =1

1
Ai

∫ ∫
Fi

n

= E i + ρi ∑ B j Fij

Fj

H ( x, x′)

cos φi cos φ j

π x − x′

2

dx′

für alle i = 1,..., n

j =1

Formfaktor

Dabei ist Ai der Flächeninhalt von Flächenstück Fi und
Fij =

1
Ai

∫∫
Fi

Fj

H (x, x′)

cosφi cosφ j

π x − x′

2

dx′

der sog. Formfaktor [FD96; SH93] von Flächenstück Fi zu Flächenstück Fj. Dieser Formfaktor ist eine geometrische Größe und gibt an,
welcher Anteil der Strahlungsleistung, die von Flächenstück Fi abgestrahlt wird, auf dem Flächenstück Fj ankommt.
Da die Integrale unter Vertauschung invariant sind, ergibt sich zwischen den Formfaktoren Fij und Fji die Reziprozitätsbeziehung:

Ai Fij = Aj Fji

i = 1,..., n

Aus Gründen der Energieerhaltung gilt außerdem:
n

∑F
j =1

72

■
■
■

ij

≤ 1 für alle i = 1,..., n

1 Computergrafik und Virtual Reality

Da ein ebenes Flächenstück kein Licht auf sich selber abstrahlt, gilt
außerdem:

Fii = 0 für alle i = 1,..., n
Die klassische Radiosity-Gleichung ist ein lineares Gleichungssystem und kann deshalb in Matrixform geschrieben werden. Mit den
oben erwähnten Eigenschaften lautet die Gleichung dann
⎛ 1
⎜
⎜ − ρ2 F21
⎜
⎜
⎝ − ρn Fn1

− ρ1 F12
1
− ρn Fn 2

− ρ1 F1n ⎞⎛ B1 ⎞ ⎛ E1 ⎞
⎟⎜ ⎟ ⎜ ⎟
− ρ 2 F2n ⎟⎜ B2 ⎟ ⎜ E2 ⎟
=
⎟⎜ ⎟ ⎜ ⎟
⎟⎜ ⎟ ⎜ ⎟
1 ⎠⎝ Bn ⎠ ⎝ En ⎠

Da die Reflexionsfaktoren ρi alle kleiner als 1 sind und die Summe
der Formfaktoren in jeder Zeile auch kleiner oder gleich 1 ist, ist die
Koeffizientenmatrix strikt zeilendiagonaldominant und damit auch
regulär. Das heißt, dieses Gleichungssystem besitzt eine eindeutige
Lösung.
Um die Radiosity-Werte Bi zu berechnen, müssen nun zum einen
die Formfaktoren berechnet werden, und zum andern muss das Gleichungssystem gelöst werden. Dabei stellt die Größe der Matrix ein
besonderes Problem dar, da realistische Szenen oft aus Hunderttausenden oder gar Millionen Flächenstücken bestehen.
Zur Darstellung des Ergebnisses werden an den Eckpunkten Mittelwerte der Farbwerte aller angrenzenden Flächenstücke gebildet. Die
einzelnen Flächenstücke können dann mittels Gouraud-Shading dargestellt werden, so dass kontinuierliche Farbverläufe auf den Oberflächen erreicht werden.

Darstellung des Ergebnisses

Abb. 1.57:
Unterteilung der Szene in Flächenstücke

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

73

Berechnung der Formfaktoren

Fernnäherung

Hemicube-Verfahren

74

■
■
■

Die Bestimmung der Formfaktoren erfordert die Berechnung doppelter Flächenintegrale, deren Integranden aufgrund der Sichtbarkeitsfunktion H Unstetigkeiten aufweisen können. Solche Integrale lassen
sich nur in einfachen Anordnungen analytisch lösen [SH93]. Auch die
ansonsten in der Numerik üblichen Quadraturformeln zur numerischen Lösung von Integralen lassen sich wegen der Unstetigkeiten der
Integranden nicht effizient einsetzen. Deshalb müssen die Formfaktoren entweder mit Monte-Carlo-Methoden stochastisch gelöst werden,
was in [BG62], [HH64] und [Be99] ausführlich beschrieben wird, oder
es müssen vereinfachende Annahmen getroffen werden, wie dies bei
den im Folgenden beschriebenen Verfahren geschieht.
Eine wesentliche Vereinfachung erhält man durch die Annahme,
dass die Ausdehnung der beiden Flächenstücke im Vergleich zu ihrem
Abstand klein ist (Fernnäherung). Häufig lässt sich dies durch Unterteilung der Flächenstücke erreichen. In manchen Fällen, z. B. bei aneinandergrenzenden Flächenstücken, kann diese Annahme aber nicht
erfüllt werden, wodurch es zu sichtbaren Fehlern in der Berechnung
kommt. Unter der Annahme der Fernnäherung ist der Formfaktor Fij
unabhängig von der Ausdehnung der Fläche Fi (d. h., die Fläche Fi
kann als infinitesimal klein angenommen werden) und die Abstände
x − x′ können durch eine Konstamte r ersetzt werden.
Das erste effiziente Verfahren zur Berechnung von Formfaktoren,
das gleichzeitig auch das Verdeckungsproblem löst, ist das HemicubeVerfahren, das 1985 von Cohen und Greenberg vorgestellt wurde
[CG85]. Dieses Verfahren berechnet alle Formfaktoren von einem als
infinitesimal klein angenommenen Flächenstück Fi zu allen anderen
Flächenstücken der Szene.
Das infinitesimal kleine Flächenstück Fi wird dazu mit einem
Halbwürfel (Hemicube) umgeben. Der Formfaktor von Fi zu einem
anderen Flächenstück ist dann genauso groß wie der Formfaktor zu
dessen Projektion auf den Halbwürfel. Wird der Halbwürfel nun mit
einem Rechtecksraster (sog. Hemicube-Pixeln) überzogen, kann die
Projektion aller anderen Flächenstücke der Szene auf den Hemicube
näherungsweise durch Rasterisierung mit Hilfe gewöhnlicher Grafikhardware gewonnen werden. Bei der Rasterisierung werden die einzelnen Hemicube-Pixel dabei aber nicht mit Farbwerten, sondern mit
IDs der gerasterten Flächenstücke belegt. Das Verdeckungsproblem
kann implizit mit Hilfe des z-Buffer-Algorithmus gelöst werden.
Den Formfaktor zu einem Flächenstück erhält man dann durch
Summieren der Beiträge aller Hemicube-Pixel, die mit der entsprechenden ID belegt sind. Diese Beiträge werden Delta-Formfaktoren
genannt. Sie lassen sich aufgrund der einfachen Geometrie analytisch
berechnen. Wählt man eine feste Auflösung für den Hemicube, können

1 Computergrafik und Virtual Reality

Abb. 1.58:
Formfaktorberechnung mit Hemicube

die Delta-Formfaktoren einmal im Voraus berechnet und in einer Tabelle gespeichert werden.
Die Formfaktorberechnung mit dem Hemicube-Verfahren ist dank
der Hardwareunterstützung bei der Rasterisierung sehr schnell. Die
Rasterisierung ist aber aufgrund der endlichen und festen Anzahl der
Hemicube-Pixel mit Abtastfehlern verbunden, die zu auffälligen Artefakten führen.
Bei der Formfaktorberechnung nach Wallace [WE89] wird der
Formfaktor einer infinitesimal kleinen Fläche Fi zu einer endlichen
Fläche Fj näherungsweise bestimmt, indem die Fläche Fj durch eine
Anzahl Kreisscheiben gleichen Flächeninhalts approximiert wird. Die
Sichtbarkeit zwischen Fi und den Kreisscheibenmittelpunkten wird mit
Hilfe von Raytracing bestimmt. Der Formfaktor Fij wird dann durch die
Summe der Formfaktoren zu den sichtbaren Kreisscheiben approximiert. Die Formfaktoren von infinitesimal kleinen Flächenstücken zu
Kreisscheiben können analytisch berechnet werden [SH93].
Zur Lösung des Gleichungssystems könnten angesichts der strikten
Zeilendiagonaldominanz der Matrix im Prinzip bekannte numerische
Verfahren eingesetzt werden, wie z. B. das Gauß-Seidel-Verfahren
oder die Jakobi-Iteration. Da es aufgrund der Größe der Matrix in der

Formfaktorberechnung nach Wallace
mit Raytracing

Lösung des Gleichungssystems

Abb. 1.59:
Formfaktorberechnung nach Wallace

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

75

Progressive Refinement

76

■
■
■

Regel nicht möglich ist, die gesamte Matrix zu speichern, geschweige
denn alle ihre Koeffizienten zu berechnen, sind diese Standardverfahren in der Praxis nicht einsetzbar. Es werden also Verfahren benötigt,
die mit einem kleinen Teil der Koeffizienten der Matrix auskommen.
Zum einen kann dabei ausgenutzt werden, dass der Strahlungsaustausch zwischen manchen Flächenpaaren nur unwesentlich zum
Gesamtergebnis beiträgt, so dass die entsprechenden Koeffizienten
vernachlässigt werden können. Dies wird z. B. beim Progressive-Refinement-Verfahren ausgenutzt, das weiter unten beschrieben wird.
Zum anderen führen räumliche Kohärenzen dazu, dass sich die
Koeffizienten benachbarter Flächenstücke nur unwesentlich unterscheiden. So können ganze Blöcke der Matrix durch einen einzigen
Wert approximiert werden. Dies wird z. B. beim hierarchischen Radiosity oder beim Wavelet-Radiosity ausgenutzt.
Das Progressive-Refinement-Verfahren, das 1988 von Cohen et al.
vorgestellt wurde [CC88], ist ein iteratives Verfahren, das in jedem
Iterationsschritt die Strahlungsleistung eines ausgewählten Flächenstücks auf alle anderen Flächen der Szene verteilt.
Die Radiosity der Flächenstücke wird zu Beginn des Verfahrens mit
deren Eigenemission initialisiert. Zusätzlich wird für jedes Flächenstück die noch unverteilte (d. h. noch nicht in die Szene reflektierte)
Radiosity gespeichert, die ebenfalls mit der Eigenemission initialisiert
wird.
In jedem Iterationsschritt wird das Flächenstück ausgewählt, das
über die größte noch unverteilte Strahlungsleistung verfügt (die Strahlungsleistung eines Flächenstücks ist das Produkt der Radiosity und
des Flächeninhalts). Diese wird dann in die Szene reflektiert und an
die anderen Flächenstücke verteilt.
Mathematisch betrachtet ist das Progressive-Refinement-Verfahren
eine Variante der Southwell Relaxation und konvergiert aufgrund der
strikten Zeilendiagonaldominanz der Matrix gegen die korrekte Lösung [GC94]. Zur Durchführung eines Iterationsschrittes werden die
Formfaktoren einer Spalte der Matrix berechnet.
Da die Beiträge derjenigen Flächen zuerst berechnet werden, die
den größten Einfluss auf die gesamte Beleuchtungssituation haben,
führt dieses Verfahren sehr schnell zu visuell guten Ergebnissen.
Wenn keine exakte Lösung der Radiosity-Gleichung, sondern nur ein
realistisches Bild benötigt wird, kann der Prozess schon nach wenigen
Iterationsschritten abgebrochen werden.
Die Effizienz des Verfahrens kann durch den Einsatz hierarchischer
Techniken, ähnlich wie die im folgenden Abschnitt beschriebenen,
weiter gesteigert werden. Solche hierarchische Techniken wurden
auch bei der Berechnung in Abb. 1.60 eingesetzt. Die Szene besitzt drei
Lichtquellen an der Decke des Raumes.

1 Computergrafik und Virtual Reality

Abb. 1.60:
Berechnungsfolge einer
Progressive-Refinement-Berechnung

Hanrahan et al. stellten 1991 einen Algorithmus vor [HS91], der es
ermöglicht, die Formfaktormatrix, die für eine aus n Flächenstücken
2
bestehende Szene n Formfaktoren enthält, mit Hilfe einer hierarchischen Repräsentation zu einer Blockmatrix zu reduzieren, die aus
O(n) Blöcken besteht. Die Matrixeinträge werden dabei durch sog.
Links zwischen den zugehörigen Flächenstücken repräsentiert.
Der Algorithmus arbeitet in zwei Phasen. In der „Initial Linking“Phase wird die Blockmatrix erzeugt, in der zweiten Phase eine Lösung
des Gleichungssystems bestimmt.
Dabei startet man mit möglichst großen rechteckigen Flächenstücken, die während der „Initial Linking“-Phase unterteilt werden. Als

1.2 Bildberechnung – vom Modell zum Bild

Hierarchisches Radiosity und Clustering

■
■
■

77

Unterteilungskriterium dient dabei die Größe der Formfaktoren. Für je
zwei Flächenstücke Fi und Fj werden zunächst die beiden Formfaktoren
Fij und Fji ohne Berücksichtigung der Verdeckung berechnet. Ist der
größere der beiden Formfaktoren größer als eine vorgegebene Schranke Fε, wird die zugehörige Empfängerfläche in vier Teilflächen unterteilt, sofern deren Flächeninhalt ein vorgegebenes Minimum nicht
unterschreitet. Im Falle einer Unterteilung wird das „Initial Linking“
rekursiv für die Teilflächen durchgeführt, ansonsten wird die gegenseitige Verdeckung der beiden Flächenstücke mit Hilfe einer Anzahl von
Strahlen ermittelt, die mit Raytracing durch die Szene verfolgt werden.
Die Formfaktoren werden nun um die Verdeckung korrigiert und in
einem Link zwischen den beiden Flächenstücken gespeichert.
Abb. 1.61:
Radiosity-Lösungen,
berechnet mit PYTHA RadioLab

78

■
■
■

1 Computergrafik und Virtual Reality

Dies führt zu einer Matrix mit O(n) Blöcken, sofern die initialen
Formfaktoren nicht kleiner als Fε sind. Für kleinere initiale Formfaktoren werden Clustering-Techniken verwendet, die es erlauben, mehrere Flächen zu Clustern zusammenzufassen, die als Ganzes Radiosity
senden oder empfangen können [Si94].
Die Idee ist nun, Interaktionen zwischen Flächenstücken in verschiedenen Ebenen der Unterteilungshierarchie zuzulassen. Das Gleichungssystem in Blockmatrix-Form kann mit Hilfe von StandardLösungsverfahren oder mit der Progressive-Refinement-Methode
gelöst werden.
Weitere effiziente Verfahren zur Berechnung einer Radiosity-Lösung sind Wavelet-Radiosity, bei dem eine Lösung auf der Basis von
Wavelet-Konstruktionen hierarchischer Funktionen höherer Ordnung
berechnet wird, und Monte-Carlo-Radiosity, wo stochastische Verfahren zum Einsatz kommen. Diese Verfahren werden hier nicht näher
beschrieben. Für weiterführende Informationen wird auf [GS93],
[SG93] bzw. [Be99] und [SP96] verwiesen.
Die Darstellungsqualität einer Szene, die mit Hilfe des klassischen
Radiosity berechnet wurde, hängt stark von der gewählten Unterteilung (Meshing) der Flächen ab. In Abb. 1.62 ist ein Ausschnitt aus
einer Radiosity-Szene dargestellt, in dem eine an einer Wand montierte Tischplatte zu sehen ist.
In den oberen Bildern wurde eine ungünstige Flächenunterteilung
gewählt, die zu einer schlechten Wiedergabe der Schatten führt. Die
Schattengrenzen verlaufen stufenförmig, und dunkle Bereiche unter
der Tischplatte gelangen durch Interpolation nach oben.
In den unteren Bildern wurde dagegen eine Flächenunterteilung
gewählt, die zu einer korrekten Darstellung der Schatten führt. Wie
man hier sieht, ist es dazu aber notwendig, auch angrenzende Flächen
bei der Bestimmung der Flächenunterteilung mit zu berücksichtigen.

Wavelet-Radiosity und
Monte-Carlo-Radiosity

Meshing-Problematik

Abb. 1.62:
Abhängigkeit der Radiosity-Lösung von
der Flächenunterteilung

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

79

Bewertung des Radiosity-Verfahrens

Geeignete Meshing-Strategien sind deshalb bei der Berechnung einer Radiosity-Lösung essenziell wichtig. Manche dieser Strategien
bearbeiten die Szene vor der eigentlichen Radiosity-Berechnung
(A-priori-Meshing), andere nehmen während der Berechnung Anpassungen der Flächenunterteilung vor (A-posteriori-Meshing). Grundsätzlich gibt es dabei zwei mögliche Vorgehensweisen. Zum einen
können Flächenstücke in Problemgebieten einfach feiner unterteilt
werden, zum andern können Unstetigkeitslinien der Radiosity-Funktion oder deren Ableitungen direkt als Kanten in die Unterteilung
eingearbeitet werden, d. h., man wählt die Unterteilung so, dass u. A.
entlang von Schattengrenzen Flächenkanten verlaufen. Eine ausführliche Beschreibung von Meshing-Strategien ist z. B. in [Wa02] enthalten.
Das Radiosity-Verfahren liefert sehr gute Ergebnisse für Szenen,
die einen hohen diffusen Flächenanteil besitzen, was in Innenraumszenen häufig der Fall ist. Für primäre Lichtquellen kann auf die Einschränkung rein diffuser Abstrahlung leicht verzichtet werden, so dass
Lichtquellen mit beliebiger Lichtverteilung verwendet werden können.
Das Ergebnis der Radiosity-Berechnung ist unabhängig vom Standpunkt des Beobachters. Dadurch sind Bewegungen in Echtzeit durch
eine Szene möglich, deren Beleuchtung mit Hilfe des RadiosityVerfahrens berechnet wurde. Andererseits bedeutet dies aber auch,
dass blickpunktsabhängige Beleuchtungseffekte wie Spiegelungen,
Lichtbrechungen oder Glanzlichter nicht berechnet werden können.
Zur Aufwertung der visuellen Darstellung können jedoch auch andere
Effekte nachträglich addiert werden. Dadurch bedingte globale Effekte
bleiben dabei aber unberücksichtigt.
Die Berechnung von Radiosity-Lösungen für dynamische Szenen,
in denen sich ein großer Teil der Objekte bewegen, ist nur mit sehr
großem Aufwand möglich. Weitere Informationen zu Radiosity-

Abb. 1.63:
Echtzeitdarstellung einer
Radiosity-Lösung mit nachträglicher
Addition von Spiegelungen, Glanz- und
Lense-Flair-Effekten.
berechnet mit PYTHA RadioLab

80

■
■
■

1 Computergrafik und Virtual Reality

Lösungen in dynamischen Szenen finden Sie z. B. in [Ha00], [GS90],
[MS94] und [FY94].

1.2.7
3D-Grafik-Programmierung
und GPU-unterstütztes Rendering
Moderne Grafikkarten unterstützen viele Verfahren der Bilderzeugung durch entsprechende Hardware. Zur Verwendung dieser Verfahren existieren verschiedene Programmierschnittstellen (APIs). Die
wichtigsten sind OpenGL® und Direct3D®. Die Implementierung
dieser APIs wird in der Regel mit den Grafikkarten-Treibern bereitgestellt, die die entsprechenden Aktionen der Grafikkarten auslösen und
Funktionen, die die Grafikkarten nicht bieten, in Software realisieren.
Was die reine Grafikausgabe anbelangt, sind OpenGL® und Direct3D® in ihrer Funktionalität und ihrer Mächtigkeit sehr ähnlich.
Auch in der Ausführungsgeschwindigkeit gibt es – wenn überhaupt –
keine großen Unterschiede. Grafikkarten-Hersteller optimieren ihre
Hardware und Treiber in der Regel für beide APIs.
1.2.7.1
OpenGL®

OpenGL® (Open Graphics Library) ist eine plattformunabhängige API
zur Grafikprogrammierung, die ursprünglich aus der Grafikbibliothek
von Silicon Grafics® (IRIX GL®) entstand. OpenGL® unterstützt
sowohl 2D- als auch 3D-Grafik und erlaubt Echtzeitdarstellungen
dreidimensionaler Objekte.
Wegen der Plattformunabhängigkeit von OpenGL® ist die API auf
die reine Grafikprogrammierung beschränkt, Fensterprogrammierung und Ereignis-Handling sind nicht Bestandteil der API.
OpenGL® besteht im Kern aus zwei Bibliotheken, der eigentlichen
Grafikbibliothek, welche die Schnittstelle zur Grafikkarte darstellt,
und einer weiteren Bibliothek, die nützliche Funktionen bereitstellt,
um Daten für die eigentlichen Grafikfunktionen aufzubereiten. Außerdem gibt es noch ein Utility Toolkit, das Funktionen für rudimentäre Fensterprogrammierung und Ereignisbearbeitung enthält.
OpenGL® ist ein Zustandsautomat, auf dessen Funktionalität mittels C-Funktionen zugegriffen wird.
OpenGL® bietet die Möglichkeit, bis zu 8 Punktlichtquellen, Richtungslichtquellen oder Strahler zu definieren und Materialeigenschaften festzulegen. Für die Lichtberechnung wird das Phong’sche Beleuchtungsmodell benutzt, und als Shading-Algorithmen stehen Flat- und

1.2 Bildberechnung – vom Modell zum Bild

■
■
■

81

Gouraud-Shading zur Verfügung. Objekte können texturiert und mit
Umgebungstexturen versehen werden.
Weiterführende Verfahren, wie Phong-Shading, Bump-Mapping
und Ähnliches, werden nicht direkt unterstützt, können aber mit Hilfe
der in Kap. 1.2.7.3 beschriebenen Shader-Programmierung realisiert
werden.
Weitere Informationen zu OpenGL® können z. B. in [SW04] nachgelesen werden.
1.2.7.2
Direct3D®

Direct3D® ist ein Teil von DirectX® und stellt eine Programmierschnittstelle für 3D-Grafik zur Verfügung. DirectX® ist eine ziemlich
umfassende Programmierschnittstelle für Multimedia-Anwendungen,
die von der Firma Microsoft® bereitgestellt wird und in Windows®Betriebssysteme integriert ist. Neben der 3D-Grafik enthält DirectX®
auch Unterstützung für die Programmierung von Eingabegeräten,
Sound, Mehrbenutzer-Spielen und anderem.
DirectX® erlaubt den direkten Zugriff auf die Hardware bei gleichzeitiger Hardwareunabhängigkeit des Programmcodes. Dies wird
durch eine abstrakte Hardwareschicht realisiert, welche die Anforderungen bei vorhandener Hardwareunterstützung direkt an die Hardware weitergibt oder entsprechende Hardware emuliert.
Auch Direct3D® erlaubt die Definition von Lichtquellen und Materialien, die Texturierung von Oberflächen und die Verwendung von
Umgebungstexturen.
Direct3D® basiert auf dem Common Object Model (COM) und
wird in C++ programmiert. Daten und Kommandos werden nicht wie
in OpenGL® durch viele einzelne Funktionsaufrufe übergeben, sondern in Puffern abgelegt, die dann anschließend ausgeführt werden.
Im Gegensatz zu OpenGL® besitzt Direct3D® ein eigenes Dateiformat und bietet Unterstützung zum Laden von Texturen und Geometrie und zur Definition von Animationen.
Weiterführende Verfahren können auch in Direct3D® durch
Shader-Programmierung selbst ergänzt werden.
1.2.7.3
Vertex- und Pixel-Shader

Im Laufe der letzten Jahre ging die Entwicklung der Grafikhardware in
rasantem Tempo voran. Ein besonderer Meilenstein bei dieser Entwicklung war die Programmierbarkeit der Prozessoren auf der Grafikkarte,
was völlig neue Dimensionen der Grafikprogrammierung eröffnet.

82

■
■
■

1 Computergrafik und Virtual Reality

Abb. 1.64:
Schematische Darstellung der
Bilderzeugungs-Pipeline auf modernen
Grafikkarten

Abbildung 1.64 zeigt eine schematische Darstellung der Bilderzeugungs-Pipeline moderner Grafikkarten. Die einzelnen zu zeichnenden
Dreiecke werden an die Grafikkarte übergeben.
Für jeden Eckpunkt (Vertex) eines Dreiecks läuft dann auf einem
Vertex-Prozessor ein Programm ab, das verschiedene Berechnungen
vornimmt. Hier wird die perspektivische Projektion auf die Bildebene
und bei der konventionellen Bilderzeugung auch die Beleuchtung
berechnet.
Die so für die Eckpunkte des Dreiecks gewonnenen Ergebnisse
werden bei der Rasterisierung für alle Bildschirmpixel interpoliert, die
von dem Dreieck bedeckt werden.
Für jedes einzelne Pixel eines Dreiecks läuft nun ein Programm auf
dem Fragment-Prozessor ab, das die vom Rasterisierer interpolierten
Werte als Eingabe erhält und daraus den Farbwert des Pixels berechnet. An dieser Stelle findet auch die Texturierung statt.
Die Grafikprozessoren (GPUs) unterscheiden sich wesentlich von
gewöhnlichen CPUs. Sie sind sehr stark auf ihre jeweiligen Aufgaben
spezialisiert. So ist z. B. ein Vertex-Prozessor in der Lage, geometrische
Transformationen sehr schnell zu berechnen, während ein FragmentProzessor Texturzugriffe mit trilinearer Interpolation sehr schnell
ausführen kann.
Seit wenigen Jahren sind die Programme, die auf den Vertex- und
Fragment-Prozessoren ablaufen, nicht mehr fest in Hardware gegossen, sondern frei programmierbar. Die Programme auf den VertexProzessoren werden auch Vertex-Shader, die Programme, die auf den
Fragment-Prozessoren laufen, Fragment- oder Pixel-Shader genannt.
Mit Hilfe solcher Shader-Programme lassen sich eigene Beleuchtungsmodelle und auch weiter gehende Techniken implementieren,
die von OpenGL® oder Direct3D® nicht direkt unterstützt werden.
Die Grafikprozessoren unterliegen in ihrer Programmierbarkeit im
Vergleich zu CPUs aber immer noch starken Einschränkungen. So
stehen z. B. nur eine begrenzte Anzahl an Registern für verschiedene

1.2 Bildberechnung – vom Modell zum Bild

Vertex-Prozessor

Rasterisierer

Fragment-Prozessor

Vertex-Shader
Pixel-Shader
Fragment-Shader

■
■
■

83

Shader-Modelle

Datentypen zur Speicherung von Zwischenergebnissen zur Verfügung, oder bei manchen Prozessoren sind dynamische Verzweigungen nicht möglich.
Die zur Programmierung der Prozessoren zur Verfügung stehenden Features werden in sog. Shader-Modellen spezifiziert. So ist es
z. B. ab Shader-Modell 3.0 möglich, dynamische Verzweigungen zu
programmieren oder auch von Vertex-Shadern auf Texturen zuzugreifen.
OpenGL® bietet seit Version 1.5 eine assemblerartige Sprache zur
Programmierung von Shadern und seit Version 2.0 mit GLSL (OpenGL
Shading Language) auch eine C-ähnliche Hochsprache. In Direct3D®
ist die Shader-Programmierung seit der Version 8 ebenfalls mit Hilfe
einer C-ähnlichen Hochsprache HLSL (High Level Shading Language)
möglich.
Des Weiteren bietet die Firma nVidia eine ebenfalls C-ähnliche
Hochsprache Cg (C for graphics) zur Shader-Programmierung an, die
sowohl unter OpenGL® als auch unter Direct3D® verwendet werden
kann, bei Grafikkarten anderer Hersteller aber zu Problemen oder
schlechter Performance führen kann.

1.3
Virtual Reality (VR) – Holodecks?

Immersion

84

■
■
■

Mit fortschreitender Entwicklung der Rechnerleistung und der Techniken in der Computergrafik wurde es möglich, virtuelle Welten in
immer höherem Realitätsgrad darzustellen.
In der Realität ergibt sich die Wahrnehmung der Umgebung aus
der Summe der Informationen, die alle menschlichen Sinne liefern
(Sehen, Hören, Riechen, Fühlen).
In VR-Anwendungen müssen beim Benutzer die entsprechenden
Sinneswahrnehmungen erzeugt werden, um den Eindruck zu erwecken, er befände sich wirklich in der virtuellen Welt. Das Eintauchen
bzw. der Grad des Eintauchens in eine virtuelle Welt wird als Immersion bezeichnet.
Die meisten VR-Anwendungen beschränken sich dabei auf optische und akustische Signale, die zweifelsfrei auch die wichtigsten Beiträge zur Wahrnehmung liefern. Ein besonders wichtiger Aspekt ist
dabei die dreidimensionale Wahrnehmung von Bildern, die im Folgenden ausführlicher behandelt wird.

1 Computergrafik und Virtual Reality

1.3.1
Stereoskopie
Der Begriff Stereoskopie setzt sich zusammen aus den griechischen
Begriffen stereo = räumlich und skopein = sehen und befasst sich mit
der Darstellung von räumlich wahrnehmbaren Bildern.
Zunächst werden hier die Aspekte der räumlichen Wahrnehmung
durch das menschliche Auge und anschließend deren technische Umsetzung beschrieben.
1.3.1.1
Tiefenwahrnehmung durch das menschliche Auge

Die Tiefenwahrnehmung des menschlichen Auges beruht auf mehreren verschiedenen Aspekten.
Den weitaus größten Beitrag für die Tiefenwahrnehmung liefert die
sog. Querdisparation. Aufgrund des seitlichen Abstandes der beiden
Augen nehmen diese die Umgebung aus einer leicht unterschiedlichen
Perspektive wahr. Aus der unterschiedlichen Position eines Objektes
in den beiden Bildern kann das Gehirn die Entfernung des Objektes
ermitteln.
Ebenfalls bedingt durch den seitlichen Abstand der beider Augen
ergeben sich je nach Entfernung eines Objektes verschiedene Blickrichtungen für die beiden Augen. Bei der Betrachtung weit entfernter
Objekte sind beide Augen fast parallel ausgerichtet, bei näher liegenden Objekten mehr aufeinander zu gerichtet. Der Einfluss des Konvergenzgefühls zum räumlichen Eindruck wird von der Fachwelt aber
weitaus geringer bewertet als der Einfluss der Querdisparation.
Ein weiterer sehr wichtiger Aspekt ist die teilweise Verdeckung von
Objekten, die hintereinander angeordnet sind. Das verdeckende Objekt befindet sich stets näher beim Betrachter als das verdeckte Objekt.
Daraus ergibt sich eine Reihenfolge hintereinanderliegender Objekte.

Querdisparation

Konvergenz

Gegenseitige Verdeckung

Abb. 1.65:
Querdisparation

1.3 Virtual Reality (VR) – Holodecks?

■
■
■

85

Geometrische Perspektive und
Darstellungsgröße

Licht und Schatten

Auch die geometrische Perspektive und die Darstellungsgröße von
Objekten, deren reale Größe aus Erfahrung bekannt ist, spielt eine
wichtige Rolle für die Entfernungseinschätzung. Werden z. B. zwei
Personen in unterschiedlicher Größe nebeneinander dargestellt,
schließt der Betrachter daraus, dass die kleiner dargestellte Person
weiter entfernt ist.
Des Weiteren liefert das Zusammenspiel von Licht und Schatten
einen wichtigen Beitrag zum Tiefeneindruck eines Bildes. Aus Erfahrung geht der Mensch davon aus, dass Szenen in der Natur von oben
beleuchtet sind.
Weitere Effekte, wie z. B. die Tatsache, dass weit entfernte Objekte
aufgrund von Schwebeteilchen in der Luft undeutlich erscheinen oder
dass sich die Farben sehr weit entfernter Objekte aufgrund unterschiedlicher Lichtbrechung verschiedener Wellenlängen in Richtung
Blau verschieben, tragen zu einem kleinen Teil zum Gesamteindruck
bei. Der Akkomodationsanstrengung (Scharfstellen auf eine bestimmte Entfernung) wird keine große Bedeutung zugeschrieben.
1.3.1.2
Techniken der stereoskopischen Bilddarstellung

Stereoskopisches Bildpaar,
Stereoskopische Halbbilder

86

■
■
■

Die in Kap. 1.2 beschriebenen Techniken der Bilderzeugung erlauben
es, einige dieser Effekte, die beim Betrachter für das räumliche Sehen
verantwortlich sind, korrekt darzustellen, so z. B. eine korrekte geometrische Perspektive, korrekte gegenseitige Verdeckung und je nach
verwendetem Verfahren und investiertem Berechnungsaufwand auch
mehr oder weniger korrekte Beleuchtung und Schatten. Diese Verfahren liefern aber nur ein einziges ebenes Bild der Szene. Durch weitere
Perfektionierung lässt sich allenfalls der Tiefeneindruck einer Fotografie erreichen. Für VR-Anwendungen ist dies aber nicht ausreichend. Um den Eindruck zu erzeugen, der Betrachter befinde sich in
der Szene, ist es notwendig, verschiedene Bilder für das linke und das
rechte Auge zu erzeugen. Dadurch können auch Querdisparation und
Konvergenz korrekt dargestellt werden.
Ein stereoskopisches Bild ist also in Wirklichkeit ein Bildpaar, das
aus zwei einzelnen Bildern, den sog. stereoskopischen Halbbildern,
besteht. Zur Darstellung solcher Bilder sind Techniken notwendig, die
es erlauben, den beiden Augen des Betrachters verschiedene Bilder
zuzuführen. Die gängigsten dieser Techniken werden im Folgenden
vorgestellt. Weitere Informationen dazu sowie die Beschreibung einer
größeren Auswahl an Ausgabegeräten zur stereoskopischen Darstellung sind z. B. in [SC03] oder [BK05] zu finden.

1 Computergrafik und Virtual Reality

1.3.1.3
Head Mounted Displays

Bei Head Mounted Displays (HMD) werden zwei kleine Bildschirme
direkt vor den Augen des Betrachters positioniert. Um störendes Umgebungslicht fernzuhalten, werden die Bildschirme in einem helmähnlichen Gerät untergebracht.
Viele der ersten VR-Systeme arbeiteten mit solchen HMDs. In der
Zwischenzeit wurden die HMDs aber für viele Anwendungen weitgehend von Projektionssystemen verdrängt, die größere Darstellungen
in hoher Auflösung und ein wesentlich ermüdungsfreieres Arbeiten
erlauben.
Abb. 1.66:
Head Mounted Display

1.3.1.4
Anaglyphen-Verfahren

Das Anaglyphen-Verfahren ist das einfachste Verfahren, das eine
stereoskopische Bilddarstellung bei äußerst geringen Hardwarekosten
erlaubt. Hierbei werden die beiden Stereohalbbilder jeweils einfarbig
dargestellt, aber mit komplementären Farben für das linke und rechte
Auge (z. B. Rot und Grün bzw. Rot und Cyan). Die beiden Halbbilder
werden zu einem Bild überlagert, das mit einer Brille stereoskopisch
betrachtet werden kann, die für jedes Auge einen entsprechenden
Farbfilter benutzt.
Die Möglichkeiten der Farbdarstellung sind beim AnaglyphenVerfahren sehr begrenzt. Außerdem wird der Bildeindruck gestört,
wenn Gegenstände aufgrund ihrer Farbe nur in einem der beiden
Bilder sichtbar sind.
1.3.1.5
Zeitmultiplex-Verfahren

Bei Zeitmultiplex-Displays werden die Bilder für das linke und das
rechte Auge abwechselnd angezeigt. Der Betrachter trägt eine LC-

1.3 Virtual Reality (VR) – Holodecks?

■
■
■

87

Shutterbrille, die mit Hilfe eines Infrarotsignals mit dem Display synchronisiert wird und den Blick für die beiden Augen abwechselnd
öffnet bzw. schließt.
Weil sich bei diesem Verfahren die Bildwiederholfrequenz halbiert,
müssen die Displays mit einer hohen Frequenz betrieben werden, um
ein flimmerfreies Bild zu erreichen, i.d.R. mit mindestens 120 Hz. Dies
kann mit modernen CRT-Monitoren und auch mit CRT- oder DLPProjektoren erreicht werden.
Das Nachleuchten der Displays führt hier aber insbesondere bei der
Verwendung von CRT-Monitoren oder -Projektoren zu einer schlechten Stereobildtrennung.
Insgesamt sind Zeitmultiplex-Displays eine relativ kostengünstige
Lösung zur stereoskopischen Bilddarstellung in guter Qualität.
1.3.1.6
Polarisationstechnik

Eine weit verbreitete Technik zur stereoskopischen Darstellung großflächiger Projektionen ist die Verwendung von Polarisationsfiltern zur
Trennung der beiden Stereohalbbilder.
Die Darstellung erfolgt mit zwei Projektoren, je einen für jedes Auge, die ihre Bilder übereinander auf eine Leinwand projizieren. Jeder
Projektor ist dabei mit einem Polarisationsfilter versehen. Bei der
Verwendung linearer Polarisation müssen die beiden Filter um 90°
gegeneinander verdreht sein, bei der Verwendung zirkularer Filter
müssen die Drehrichtungen gegenläufig sein.
Der Betrachter trägt eine Brille, deren Gläser ebenfalls mit den entsprechenden Polarisationsfiltern ausgestattet sind, so dass jedes Brillenglas nur das Licht des zugehörigen Projektors durchlässt.
Mit Hilfe der Polarisationstechnik, insbesondere bei Verwendung
zirkularer Polarisation, kann eine relativ gute Stereobildtrennung
erreicht werden. Bei dieser Technik können beliebige Projektortechnologien eingesetzt werden. Es fallen aber höhere Kosten an als bei der
Verwendung der zuvor beschriebenen Zeitmultiplex-Technik. Zum
einen erfolgt die Darstellung mit zwei verschiedenen Projektoren, zum
anderen sind teure polarisationserhaltende Projektionsflächen nötig.
In der Regel werden dazu silberbeschichtete Leinwände verwendet.
1.3.1.7
Wellenlängenmultiplex-Verfahren (Infitec)

Wie in Kap. 1.2.2 beschrieben, wird der Farbeindruck bei farbigen
Anzeigegeräten dadurch erzeugt, dass drei Grundfarben miteinander
kombiniert werden.

88

■
■
■

1 Computergrafik und Virtual Reality

Dies kann aber nicht nur mit den üblicherweise verwendeten Grundfarben erreicht werden. Auch mit der Wahl abweichender Grundfarben
kann derselbe Farbeindruck erzeugt werden, wenn diese Grundfarben
entsprechend kombiniert werden. Auf dieser Tatsache beruht das Infitec-Verfahren [Jo02], das im Forschungszentrum von DaimlerChrysler
ab 1999 entwickelt und dann in die Firma Infitec ausgelagert wurde.
Die Darstellung erfolgt auch hier durch zwei separate Projektoren
für das linke und rechte Halbbild, deren Bilder auf eine Leinwand
übereinander projiziert werden. Die Projektoren sind mit schmalbandigen Interferenzfiltern ausgestattet, die jeweils drei Grundfarben
eines sehr schmalen, aber unterschiedlichen Wellenlängenspektrums
durchlassen. Dadurch arbeiten die beiden Projektoren jeweils mit
unterschiedlichen Grundfarben Rot, Grün und Blau. Der Betrachter
trägt eine Brille, deren Gläser ebenso mit den entsprechenden Interferenzfiltern bestückt sind.
Da die verwendeten Grundfarben von den üblicherweise verwendeten Grundfarben abweichen, müssen sie in anderen Verhältnissen
kombiniert werden, um einen bestimmten Farbeindruck zu erzeugen.
Deshalb muss für jeden Projektor eine Farbkorrektur vorgenommen
werden, um eine korrekte Farbdarstellung zu erreichen. Dazu wird eine
einfache lineare Transformation auf das Farbtripel (r,g,b) angewandt.
Dies kann entweder per Software erfolgen, oder zwischen Rechner und
Projektor wird eine elektronische Farbkorrektur-Einheit installiert, die
die entsprechende Transformation auf das Bildsignal anwendet.
Für das Infitec-Verfahren können handelsübliche Projektoren beliebiger Technik eingesetzt werden. Es wird eine hervorragende Bildtrennung der beiden Halbbilder bei voller Farbdarstellung erreicht. Außerdem lässt sich das Verfahren auf mehr als zwei Halbbilder erweitern, so
Abb. 1.67:
Stereobildtrennung durch verschiedene
Grundfarben für die beiden Halbbilder

1.3 Virtual Reality (VR) – Holodecks?

■
■
■

89

dass auch für mehrere Betrachter je zwei Halbbilder in der für ihre individuelle Position korrekten Perspektive bereitgestellt werden können.
1.3.1.8
Autostereoskopische Displays

Bei autostereoskopischen Displays werden mehrere Ansichten der
Szene für verschiedene Blickrichtungen gleichzeitig dargestellt. Technisch wird dies dadurch erreicht, dass jedes Pixel in mehrere Subpixel
unterteilt wird. Durch geeignete Linsenraster oder Lochmasken wird
sichergestellt, dass aus verschiedenen Raumrichtungen verschiedene
Subpixel sichtbar sind (siehe Abb. 1.68).
Solche Displays erlauben eine stereoskopische Betrachtung ohne
Brille, da den beiden Augen jeweils das für ihre Position korrekte Bild
zugespielt wird. Auch bei mehreren Betrachtern erhält jeder Betrachter ein für seine Position korrektes Stereobildpaar.
Um mit dieser Technik eine Bildqualität zu erreichen, die mit den
zuvor beschriebenen stereoskopischen Techniken vergleichbar ist,
muss die Zahl der Subpixel pro Pixel in der Größenordnung von 100
liegen. Dies ist aber zurzeit technisch nicht realisierbar, da es zum
einen Probleme bereitet, die Subpixel entsprechend klein zu produzieren, und zum andern die zur Übertragung der Bildinformation notwendige Bandbreite nicht zur Verfügung steht. Außerdem müsste die
Renderleistung bereitgestellt werden, die notwendig ist, um das Bild
gleichzeitig für entsprechend viele Ansichten zu berechnen.
Bisher realisierte autostereoskopische Displays verwenden deshalb
eine sehr viel kleinere Anzahl an Subpixeln (z. B. sieben Subpixel pro
Pixel).
Ausführlichere Informationen zu autostereoskopischen Displays
finden sich z. B. in [PW97].

Abb. 1.68:
Autostereoskopische Displays:
Abhängig von der Blickrichtung sind
verschiedene Subpixel sichtbar

90

■
■
■

1 Computergrafik und Virtual Reality

1.3.2
Ein- und Ausgabegeräte
Der Realitätseindruck, der in VR-Umgebungen vermittelt wird, basiert
zu einem großen Teil auf den Sinneswahrnehmungen des Benutzers,
die durch die Ausgabegeräte des VR-Systems erzeugt werden. Aber
auch die Interaktionsmöglichkeiten mit der virtuellen Umgebung, die
mit Hilfe der Eingabegeräte erfolgen, leisten einen entscheidenden
Beitrag. Im Idealfall sollte die virtuelle Welt genau so auf Interaktionen
reagieren, wie der Benutzer dies aus der realen Welt kennt. Dann kann
ein maximaler Grad der Immersion erreicht werden.
1.3.2.1
Ausgabegeräte

Wie schon zu Beginn des Kapitels 1.3 erwähnt wurde, ist der visuelle
Eindruck für die Wahrnehmung des Benutzers von größter Bedeutung. Deshalb bilden stereoskopische visuelle Ausgabegeräte in der
Regel die Hauptbestandteile von VR-Systemen.
Herkömmliche Ausgabegeräte wie z. B. Monitore sind nicht in der
Lage, dem Betrachter den Eindruck zu vermitteln, er befände sich in
der virtuellen Welt. Deshalb wurden für VR-Anwendungen spezielle
Ausgabegeräte entwickelt, von denen hier die am weitesten verbreiteten kurz beschrieben werden. Ausführliche Beschreibungen einer
großen Anzahl an Ausgabegeräten finden sich z. B. in [SC03] oder
[BK05].
In frühen VR-Systemen kamen häufig Head Mounted Displays
(HMD) zum Einsatz. Diese wurden bereits in Kap. 1.3.1.3 beschrieben.
Zwischenzeitlich findet man in vielen VR-Systemen Ausgabegeräte,
die mit Hilfe von Projektoren eine großflächige Darstellung erreichen.
Halbtransparente Head Mounted Displays sind auch für den Einsatz
in Augmented-Reality-Anwendungen geeignet. Hier ist es möglich,
einer realen Szene zusätzliche virtuelle Informationen zu überlagern.
TM
Eine CAVE (Cave Automated Virtual Environment) ist ein kubischer Raum, der i.d.R. eine Kantenlänge von 2,5 bis 3 Meter besitzt. In
der vollen Ausbaustufe bestehen alle 6 Flächen des Raumes (4 Wände,
der Boden und die Decke) aus Projektionsflächen, die von außen mittels Rückprojektion mit einem Stereobildpaar versehen werden. Kleinere Ausbaustufen begnügen sich mit Projektionen auf 3, 4 oder 5 Flächen des Raumes.
Mit Hilfe eines Trackingsystems (siehe Kap. 1.3.2.2) wird die exakte
Position des Betrachters bestimmt, so dass die Bilder in der für die Position des Betrachters korrekten Perspektive erzeugt werden können.

1.3 Virtual Reality (VR) – Holodecks?

Head Mounted Displays

TM

CAVE

■
■
■

91

TM

ImmersaDesk

Power Wall

Haptische Ausgabegeräte

92

■
■
■

In einer CAVE lässt sich ein sehr hoher Grad der Immersion erreichen, da sich der Betrachter mitten in der Szene befindet und diese
in allen Blickrichtungen korrekt dargestellt wird.
Beim ImmersaDesk handelt es sich um eine Tischplatte, die um
45 Grad geneigt ist und mittels Rückprojektion von unten mit einem
stereoskopischen Bild versehen wird. Zur Stereobildtrennung wird das
Zeitmultiplex-Verfahren mit Shutterbrille verwendet. Das ImmersaDesk erlaubt eine bequeme Blickrichtung nach schräg unten.
Bei der Power Wall (auch Infinity Wall genannt) handelt es sich um
eine sehr große vertikale Projektionsfläche, die mittels Rückprojektion mit einem sehr hoch auflösenden stereoskopischen Bild versehen
wird. Dies wird erreicht, indem die Bilder einer größeren Anzahl an
Projektoren (z. B. 16 oder 32) so neben- und übereinander positioniert
werden, dass daraus ein großes Bild entsteht. Zur Stereobildtrennung
kann dabei eine beliebige Technik verwendet werden.
Die großflächigen Projektionsverfahren bieten gegenüber den Head
Mounted Displays für viele Anwendungen einige Vorteile, wie z. B.
eine geringere Beanspruchung der Augen, ein größeres Sichtfeld, das
bei den meisten HMDs sehr eingeschränkt ist, oder die Möglichkeit
der Kollaboration, da die Projektionen von mehreren Personen gleichzeitig betrachtet werden können.
Bei Interaktionen in der realen Welt kommt der Benutzer in der
Regel physikalisch mit den manipulierten Objekten in Berührung. Er
fühlt, dass ein Objekt wirklich da ist. Er ertastet die Beschaffenheit der
Oberflächen und fühlt z. B. die Kräfte, die er aufbringen muss, um ein
Objekt zu verschieben. Diese Wahrnehmungen liefern einen wesentlichen Beitrag zum Realitätsempfinden einer Umgebung.
Haptische Ausgabegeräte sprechen den Tastsinn des Benutzers an.
Dazu sind aufwendige Hardwarekonstruktionen und eine aufwendige
Software zur Steuerung notwendig.
Taktile haptische Ausgabegeräte sprechen den Tastsinn der Haut
an und sind häufig in Form von Handschuhen oder Anzügen realisiert, die gezielt an ausgewählten Stellen Druck auf die Haut des Benutzers ausüben können.
Andere Geräte, die dem Benutzer ein Kräfte-Feedback vermitteln,
bestehen häufig aus Roboterarmen, die der Benutzer bei der Interaktion bewegt. Diese Geräte melden dem VR-System Bewegungen des
Benutzers und können gleichzeitig Widerstandskräfte erzeugen. Kleine Roboterarme zwischen Fingergliedern und Hand können so z. B.
einen Widerstand beim Schließen der Hand erzeugen, wenn ein virtuelles Objekt gegriffen wird.
Der interessierte Leser findet eine ausführliche Beschreibung haptischer Ausgabegeräte z. B. in [SC03].

1 Computergrafik und Virtual Reality

1.3.2.2
Trackingsysteme

Bei vielen VR-Anwendungen ist es notwendig, in Echtzeit die genaue
Position und Orientierung verschiedener Objekte zu bestimmen. Zum
einen ist die korrekte perspektivische Darstellung der Szene von der
Beobachterposition abhängig, zum anderen müssen Interaktionsgeräte wie z. B. Datenhandschuh oder 3D-Maus erfasst werden. Ein präzises Trackingsystem mit kurzer Latenzzeit ist dabei für den Immersionseindruck von entscheidender Bedeutung [BK05]. Es existieren
verschiedene technische Umsetzungen von Trackingsystemen, die in
den folgenden Abschnitten kurz vorgestellt werden.
Optische Systeme benutzen mehrere fest installierte Kameras, um
die Position der Objekte zu bestimmen. Dazu wird jedes zu trackende
Objekt mit kugelförmigen Reflektoren in charakteristischen Anordnungen versehen, die von Infrarotsendern bestrahlt werden und das
Licht in die Kameras reflektieren. Aus den Kamerabildern lassen sich
dann Position und Orientierung der Objekte berechnen.
Die Genauigkeit optischer Systeme ist um ein Vielfaches höher als
die elektromagnetischer oder anderer Systeme. Allerdings sind optische Systeme auch wesentlich teurer. Die Installation ist oft schwierig,
da sich die zu trackenden Objekte innerhalb des Sichtfeldes der Kameras bewegen müssen und zumindest von einigen der Kameras erfasst
werden müssen. Bei der Verwendung einer größeren Anzahl von Kameras ist diese Anforderung leichter zu erfüllen.
Optische Trackingsysteme setzen sich in letzter Zeit in professionellen VR-Umgebungen immer mehr durch.
Elektromagnetische Trackingsysteme arbeiten mit einem Sender,
der ein Magnetfeld niederer Frequenz aussendet. Empfänger bestimmen ihre Position und Orientierung relativ zu diesem Magnetfeld.
Der Einsatz magnetischer Trackingsysteme ist in vielen Umgebungen problematisch, da elektrische Geräte und metallene Bauteile das
Magnetfeld stark stören können und die Messung dadurch verfälscht
wird. Kleinere konstante Störungen können durch Kalibrierung des
Systems ausgeglichen werden. Dazu werden die Eckpunkte eines dreidimensionalen Gitters als Referenzpunkte gemessen, zwischen die die
eigentlichen Messungen dann eingepasst werden.
Ultraschall-Tracker arbeiten mit mehreren fest installierten Ultraschallempfängern und entsprechenden Sendern, die an den zu trackenden Objekten angebracht werden. Mit Hilfe der Laufzeitunterschiede der Ultraschallsignale lassen sich so die Positionen der Sender
berechnen. Solche Trackingsysteme sind im Vergleich zu magnetischen oder optischen Systemen relativ preisgünstig. Ihre Genauigkeit

1.3 Virtual Reality (VR) – Holodecks?

Optisches Tracking

Elektromagnetisches Tracking

Ultraschall-Tracker

■
■
■

93

und Reichweite ist aber wesentlich schlechter, weshalb sie in professionellen VR-Systemen kaum zum Einsatz kommen.
1.3.2.3
Interaktions- und Eingabegeräte

Datenhandschuh

3D-Maus

Für intuitive Interaktionen mit Objekten in virtuellen Umgebungen
sind Eingabegeräte notwendig, die Bewegungen in allen 6 Freiheitsgraden des dreidimensionalen Raumes zulassen. Tastatur und Maus
sind dazu nicht geeignet. Aus diesem Grund wurden in den letzten
Jahren eine ganze Anzahl an Eingabegeräten für den VR-Bereich entwickelt [BK05]. Über die gängigsten Technologien wird im Folgenden
ein kurzer Überblick gegeben.
Ein weit verbreitetes VR-Interaktionsgerät ist der Datenhandschuh.
Dieser Handschuh erfasst die Bewegungen der Finger und der Hand
durch eingearbeitete Dehnmessstreifen oder Biegesensoren. Die Position und Orientierung der Hand im Raum wird mit Hilfe eines Trackingsystems erfasst.
Mittels eines Datenhandschuhs kann das Greifen und Manipulieren
virtueller Objekte realisiert werden. Bestimmte Gesten können auch
dazu verwendet werden, verschiedene Aktionen auszulösen.
Eine 3D-Maus ist ein Eingabegerät, das der Benutzer in der Hand
hält und frei im Raum bewegen kann. Mit Hilfe eines Trackingsystems
wird die Position und Orientierung im Raum bestimmt. Durch Betätigen eines oder mehrerer Schalter können verschiedene Aktionen ausgelöst werden. Eine 3D-Maus eignet sich sowohl zur Navigation in
virtuellen Welten als auch zum Greifen, Selektieren oder Positionieren
von Objekten.
Weitere Interaktionsgeräte sind z. B. in [BK05] oder [SC03] ausführlich beschrieben.

1.3.3
Ausblick
In den vorigen Abschnitten haben wir verschiedene Technologien
kennen gelernt, die in VR-Umgebungen eingesetzt werden können,
um beim Benutzer einen Eindruck der Immersion zu erzeugen.
Welcher Realitätseindruck lässt sich damit erreichen? Wie weit sind
wir noch von der Realisierung eines Holodecks wie in Star Treck entfernt, in dem alle menschliche Sinne gleichzeitig stimuliert werden?
Für die optische Wahrnehmung stehen inzwischen ausgereifte
Techniken zur Verfügung, die einen realistischen stereoskopischen
Rundumblick erlauben. Alle diese Techniken erzeugen jedoch ein
scharfes Bild in einer gewissen Projektionsentfernung, die nicht mit

94

■
■
■

1 Computergrafik und Virtual Reality

der Entfernung der virtuellen Objekte übereinstimmt. Der Benutzer
muss seine Augen deshalb auf die Projektionsentfernung fokussieren,
um ein scharfes Bild zu sehen. Dann erscheinen aber auch näher oder
entfernter gelegene Objekte scharf. Die natürliche Tiefenunschärfe
wird nicht korrekt wiedergegeben. Die Entwicklung von RetinalDisplays, die das Bild direkt auf die Netzhaut des Benutzers projizieren, verspricht hier Abhilfe.
3D-Audiosysteme in guter Qualität stehen heutzutage auch zur
Verfügung, so dass Geräusche realistisch wiedergegeben werden können. Die Kombination solcher Systeme mit Rundum-Displays bereitet
aber noch Probleme, da der Sound abgeschirmt wird, wenn die Lautsprecher hinter den Projektionsflächen angebracht werden, und umgekehrt die Darstellung verdeckt wird, wenn die Lautsprecher vor den
Projektionsflächen positioniert werden. Um dieses Problem zu lösen,
gibt es Anstrengungen, transparente Lautsprecher zu entwickeln.
Für haptische Ausgabegeräte existieren verschiedene Lösungen. Es
müssen aber noch Geräte entwickelt werden, die alle Aspekte des Tastens, wie das Erfassen der Oberflächenbeschaffenheit, Widerstandskräfte, Temperatur, Feuchtigkeit usw., gleichzeitig adressieren können.
Außerdem sind alle bisherigen haptischen Geräte mit aufwendigen
mechanischen Aufbauten und Verkabelungen verbunden, die den
Realitätseindruck stören.
Die Möglichkeiten, den Geruchssinn anzusprechen, befinden sich
noch in den ersten Anfängen, obwohl diese Sinneswahrnehmung für
die emotionale Erinnerung einen wichtigen Beitrag leistet. Erste Versuche wurden unternommen, wenige vorgegebene Gerüche in die
Umgebung zu leiten. Man ist aber noch weit davon entfernt, die Geruchswahrnehmung verstanden zu haben. So ist es z. B. nicht bekannt,
ob es ein Menge an Grundgerüchen gibt, aus denen sich beliebige Gerüche kombinieren lassen, so wie dies bei der Farbwahrnehmung der
Fall ist. Falls dies nicht möglich ist, was sind dann die Alternativen?
Ein weiterer Aspekt, der mindestens so wichtig ist wie die korrekte
Stimulation der Sinne, sind korrekte Bewegungen der virtuellen Objekte. Diese Bewegungen müssen den Gesetzen der Physik genügen,
die jeder aus der realen Welt kennt. Oft ist es dabei nicht vermeidbar,
die Bewegungen in aufwendigen Simulationen physikalisch korrekt zu
berechnen. Bei Echtzeitanwendungen reicht dafür aber häufig die
heutige zur Verfügung stehende Rechenleistung nicht aus.
Bei Animationsfilmen können Bewegungen unter Einsatz längerer
Rechenzeiten im Voraus berechnet werden. Oder die Bewegungen
werden mit Hilfe von Motion-Capturing-Systemen an realen Objekten
aufgenommen und auf die virtuellen Objekte übertragen.
Des Weiteren müssen für einen vollständigen Realitätseindruck Interaktionen mit der virtuellen Welt möglich sein, wie sie der Benutzer

1.3 Virtual Reality (VR) – Holodecks?

■
■
■

95

aus der Realität kennt. Dazu bedarf es weiterer Entwicklungsarbeit an
den Eingabegeräten.
Auch die räumliche Beschränktheit der VR-Aufbauten stellt ein
noch ungelöstes Problem dar. Der Benutzer muss in die Lage versetzt
werden, einfach durch eine virtuelle Umgebung zu gehen, anstatt auf
der Stelle zu stehen und die Umgebung mit einer 3D-Maus zu bewegen. Auch in diesem Punkt gibt es laufende Forschungsanstrengungen. So wird u. A. mit Laufbändern experimentiert, auf denen sich der
Benutzer frei bewegen kann, die ihn aber trotzdem an seiner ursprünglichen Position halten.
Bis zur Realisierung eines echten Holodecks wird wohl noch einige
Zeit vergehen. Die Forschungsanstrengungen resultieren jedoch immer wieder in Ergebnissen, die uns zu diesem Ziel führen werden.

Literatur
[Bau75] B. G. Baumgart: A polyhedron representation for computer vision. In
Nat. Comp. Conf. 44, pages 589–596. AFIPS, 1975.
[BB06] M. Bender, M. Brill: Computergrafik. Ein anwendungsorientiertes
Lehrbuch. 2. Auflage. Hanser Verlag, 2006.
[Be99] P. Bekaert: Hierarchical and Stochastic Algorithms for Radiosity.
Dissertation, Katholische Universität Leuven, Belgien, 1999.
[BG62] N.P. Buslenko et al.: The Monte Carlo Method – The Method of Statistical Trials. Pergamon Press, 1962.
[BK05] D.A. Bowman, E. Kruijff, J.J. LaViola und J.I. Poupyrev: 3D User
Interfaces, Theory and Practice. Addison-Wesley, 2005.
[Br00] I.N. Bronstein, K. A. Semendjajew, G. Musiol, H. Mühlig: Taschenbuch der Mathematik. Harri Deutsch, Thun/Frankfurt, 5., überarb. u.
erw. Aufl., 2000.
[Ca93] M.P. do Carmo: Differentialgeometrie von Kurven und Flächen.
Vieweg, 1993.
[CC88] M. Cohen, S.E. Chen, J.R. Wallace und D.P. Greenberg: „A Progressive Refinement Approach to Fast Radiosity Image Generation“.
Computer Graphics Proceedings, ACM SIGGRAPH, August 1988.
[Co84] R.L. Cook: Shade Trees. Computer Graphics Proceedings, ACM
SIGGRAPH, Juli 1984.
[CG85] M. Cohen und D.O. Greenberg: „The Hemi-Cube: A Radiosity Solution for Complex Environments“. Computer Graphics Proceedings,
ACM SIGGRAPH, August 1985.
[ES97] J. Encarnação, W. Straßer, R. Klein: Graphische Datenverarbeitung.
Band II, Oldenbourg Verlag, 1997.
[Fa02] A. Farin: Curves and Surfaces for CAGD – A Practical Guide. 5. Auflage, Academic Press, 2002.

96

■
■
■

1 Computergrafik und Virtual Reality

[FD96] J.D. Foley et al.: Computer Graphics: Principles and Practice. Second
Edition. Addison-Wesley, 1996.
[FY94] D.A. Forsyth, C. Yang und K. Teo: „Efficient Radiosity in Dynamic
Environments“. Fifth Eurographics Workshop on Rendering, Juni
1994.
[GC94] S.J. Gortler, M.F. Cohen und P. Slusallek: „Radiosity and Relaxation
Methods“. IEEE Computer Graphics and Applications, November
1994.
[GS90] D.W. George, F.X. Sillion und D.P. Greenberg: „Radiosity Redistribution for Dynamic Environments“. IEEE Computer Graphics and Applications, Juli 1990.
[Gl95] A.S. Glassner: Principles of Digital Image Synthesis. Morgan Kaufmann, 1995.
[Go71] H. Gouraud: Continuous Shading of Curved Surfaces. IEEE Transactions on Computers, Juni 1971.
[GS93] S.J. Gortler, P. Schroder, M-F. Cohen und P. Hanrahan: „Wavelet
Radiosity“. Computer Graphics Proceedings, ACM SIGGRAPH, 1993.
[Ha00] J. Hahn: Simulation und Photorealismus. Dissertation, Universität
Tübingen, 2000.
[HS91] P. Hanrahan, D. Salzman und L. Auperle: „A Rapid Hierarchical
Radiosity Algorithm“. Computer Graphics Proceedings, ACM SIGGRAPH, Juli 1991.
[HH64] J.M. Hammersley and D.C. Handscomb: The Monte Carlo Method.
Cambridge University Press, 1964.
[HL89] J. Hoschek, D. Lasser: Grundlagen der geometrischen Datenverarbeitung, Teubner, 1989.
[HS93] P. Haeberli und M. Segal: Texture Mapping as a Fundamental Drawing Primitive. Fourth Eurographics Workshop on Rendering, Eurographics, Juni 1993.
[Je01] H.W. Jensen: Realistic Image Synthesis Using Photon Mapping.
AK Peters, 2001.
[Je77] A.J. Jerri: “The Shannon Sampling Theorem – Its Various Extensions
and Applications: A Tutorial Review”. Proceedings of the IEEE, November 1977.
[JM01] H.W. Jensen et al.: „ A Practical Model for Subsurface Light Transport”. Proceedings of Siggraph, 2001.
[Jo02] H. Jorke: Infitec – Wellenlängenmultiplex Visualisierungssysteme.
Infitec GmbH Ulm, 2002.
[Ka86] J.T. Kajiya: „The Rendering Equation“. Computer Graphics ´86 Proceedings, vol. 20, pp. 143−150. ACM SIGGRAPH, August 1986.
[KT01] T. Kaneko et al.: „Detailed Shape Representation with Parallax Mapping“ Proceedings of ICAT, Dezember 2001.
[LF99] S. K. Lodha, R. Franke: Scattered Data Techniques for Surfaces, in
Proceedings of Dagstuhl Conference on Scientific Visualization,

Literatur

■
■
■

97

[Mä88]
[MH84]

[Mo97]
[MS94]

[NB94]
[PW97]
[SC03]
[SG93]

[SH93]
[Si94]

[SK96]

[SP96]

[St74]
[SW04]
[Wa02]
[We00]
[We05]
[WE89]

[Wi83]

98

■
■
■

(eds.) H. Hagen, G. Nielson and F. Post, IEEE Computer Society
Press, 1999, pages 182−222.
Martti Mäntylä: An introduction to solid modeling. Computer Science
Press, College Park, MD, 1988.
G.S. Miller und C.R. Hoffman: “Illumination and Reflection Maps:
Simulated Objects in Simulated and Real Environments”, Course
Notes for Advances Computer Graphics Animation, SIGGRAPH 1984.
M.E. Mortensen: Geometric Modelling, Wiley, 1997.
S. Müller und F. Schöffel: „Fast Radiosity Repropagation for Interactive Virtual Environments Using a Shadow-Form-Factor-List“. Fifth
Eurographics Workshop on Rendering, Juni 1994.
X. Ni, S. Bloor: Performance of Boundary Datastructures, IEEE Computer & Graphics, November 1994.
S. Pastoor und M. Wopking: 3-D Displays: A Review of Current
Technologies. Displays vol. 17, 1997.
W.R. Sherman und A.B. Craig: Understanding Virtual Reality, Interface, Application and Design, Morgan Kaufmann, 2003.
P. Schroder, S.J. Gortler, M.F. Cohen und P. Hanrahan: „Wavelet
Projections for Radiosity”. Fourth Eurographics Workshop on Rendering, Eurographics, Juni 1993.
P. Schroder und P. Hanrahan: „On the Form Factor Between Two
Polygons“. Computer Graphics Proceedings, ACM SIGGRAPH, 1993.
F. Sillion: ”Clustering and Volume Scattering for Hierarchical Radiosity Calculations”. Fifth Eurographics Workshop on Rendering, Eurographics, Juni 1994.
A. Schilling, G. Knittel und W. Strasser: Texram: “A Smart Memory
for Texturing”. IEEE Computer Graphics and Applications 16(3),
1996.
M. Sbert, X. Pueyo, L. Neumann und W. Purgathofer: „Global Multipath Monte Carlo Algorithms for Radiosity“. The Visual Computer,
vol. 12, 1996.
W. Strasser: Schnelle Kurven- und Flächendarstellung auf graphischen Sichtgeräten. Dissertation, TU Berlin, 1974.
D. Shreiner, M. Woo, J. Neider und T. Davis: OpenGL Programming
Guide. Fourth Edition, Addison-Wesley, 2004.
A. Watt: 3D-Computergrafik. 3. Auflage, Addison-Wesley, 2002.
J. Weidmann: Lineare Operatoren in Hilberträumen, Teil I. Teubner
Verlag, 2000.
D. Werner: Funktionalanalysis, 4. Auflage, Springer-Verlag, 2005.
J.R. Wallace, K.A. Elmquist und E.A. Haines: “A Ray Tracing Algorithm for Progressive Radiosity”. Computer Graphics Proceedings,
ACM SIGGRAPH, Juli 1989.
L. Williams: Pyramidal Parametrics. Computer Graphics, vol. 17,
1983.

1 Computergrafik und Virtual Reality

2 Einsatz von Markup-Languages
Martin Goik, Marko Hedler, Jörg Westbomke

2.1
Einleitung
Wir beginnen dieses Kapitel mit der Frage, was ist XML? Die einfache
Antwort lautet: XML ist eine Spezifikation des W3-Konsortiums [7].
Die Spezifikation enthält u. A. die formale Syntaxdefinition sowohl für
XML-Dokumentinstanzen als auch die Syntax der Beschreibungssprache, in welcher eine Document Type Definition (DTD) verfasst ist.
Gemäß dieser Spezifikation kann man XML-Dokumente erstellen
und auf Wohlgeformtheit sowie ggf. Validierbarkeit prüfen (s. auch
Kap. 2.2). Aus Sicht sowohl eines Anwendungsentwicklers als auch
z. B. eines Dokumentautors handelt es sich dabei um reine Basistechnologien, welche die gewachsene Bedeutung nicht erklären können.
Was bedingt also die Attraktivität von XML?
Die Antwort liegt zumindest teilweise in der Vielzahl fertiger Applikationen und Schnittstellen auf unterschiedlichen Ebenen, welche
zum Standard selbst als Basistechnologien verwendet werden können.
Auf unterster Ebene werden einem Anwendungsentwickler grundlegende Zugriffstechnologien wie z. B. Parser und XML-fähige Datenbanken geboten. Für bestimmte Standards, etwa das Scalable Vector
Graphics Format (SVG) [10], werden fertige Komponenten und Applikationen zur Verfügung gestellt, welche als Bausteine eigener Applikationen verwendet werden können.
Gestiegen ist auch die Bedeutung als Austauschformat. Die enge
Verzahnung der Produktionsprozesse von Wirtschaftsunternehmen
bedingt eine Kommunikation der beteiligten Systeme etwa bei Bestellvorgängen. Dies wird dadurch kompliziert, dass die verwendeten
Branchenlösungen in der Regel inkompatibel sind in Bezug auf beispielsweise das verwendete Datenmodell. Es werden daher Austauschformate benötigt, welche den kleinsten gemeinsamen Nenner darstellen, auf welchen sich die beteiligten Firmen einigen können. Auch hier
spielt XML eine Rolle, da zumindest ein Teil der für den Austausch

2.1 Einleitung

Was ist XML?

Verwendung von XML

■
■
■

99

benötigten Integritätsbedingungen bereits in einer DTD oder einer
XML-Schema-Definition deklarativ erfassbar ist.
Ein etwas anderer Gesichtspunkt stellt die Verwendung von XML
als Mittel zur Datenhaltung von Dokumenten dar. Obwohl sich viele
Aussagen der letzten Jahre hinsichtlich einer Totalablösung proprietärer Office-Formate oder auch von DTP-Systemen nicht erfüllt haben,
gibt es auch hier eine Entwicklung in Richtung XML. Dies ist insofern
verständlich, als Dokumente einen hierarchischen Aufbau besitzen,
wenn wir von Internverweisen einmal absehen. Wir können hier zwei
grundlegend verschiedene Arten der Verwendung von XML im Dokumentkontext unterscheiden:
• Eine Anwendung verwendet XML lediglich als Ersatz für ein bisher
verwendetes Internformat. Das Format selbst ist zwar im Gegensatz
zu einem Binärformat prinzipiell im Klartext lesbar, die formalen
Regeln seines Aufbaus sind aber in der Anwendung selbst implementiert.
• Die Strukturierungsmöglichkeiten werden durch eine DTD festgelegt. Der Anwender verwendet zum Bearbeiten des Dokuments eine
prinzipiell austauschbare Software, welche die DTD liest und eine
Bearbeitung des Dokuments innerhalb der dort definierten Grenzen ermöglicht.
Ein wesentlicher Vorteil letzterer Lösung besteht in der Unabhängigkeit der Dokumentverarbeitung von einem bestimmten Anbieter.
Dies gilt insbesondere auch in Hinsicht der zeitlichen Entwicklung
von Software: Auch nach großen zeitlichen Abständen kann das Dokument prinzipiell als XML-Dokument mit gegebener DTD verändert
werden, sofern man unterstellt, dass auch modernere Editoren noch
DTDs lesen können.

2.2
Voraussetzungen
Im Folgenden geben wir eine kurze Übersicht von als bekannt angenommenen Technologien im XML- und Java-Umfeld.
XML selbst ist ein beim W3-Konsortium (W3C) spezifizierter Standard. Zu diesem Standard konforme Dokumente können wohlgeformt
oder validierbar sein. Letzteres bedeutet, dass die Grammatik eines
XML-Dokuments in einer Document Type Definition (DTD) festgelegt ist. Ein Parser kann dann prüfen, ob eine Dokumentinstanz konform zu einer gegebenen DTD ist.

100

■
■
■

2 Einsatz von Markup-Languages

Viele Applikationen unterstützen eine einfache Visualisierung von
XML-Dokumenten über Cascading Stylesheets (CSS) [13], ein Standard aus dem Bereich der Online-Publikationen.
Für aufwendigere Transformationen von XML-Dokumenten in andere XML- oder Textformate (also Sichten auf ein XML-Dokument)
kann die Sprache XSLT [8] verwendet werden.
Sollen druckbare Versionen eines XML-Dokuments erstellt werden,
bieten sich verschiedene Formatierer an. Diesen gemeinsam ist die
Tatsache, dass sie jeweils eine Stilvorlage (= Stylesheet) benötigen, in
welcher die für die einzelnen Elemente und Hierarchiebedingungen
gültigen Regeln erfasst sind. Zwei herstellerneutrale Standards in diesem Umfeld sind:

XSL-FO und DSSL

• XSL-FO [9]: Eine im XML-Standard definierte Stylesheet-Sprache.
• DSSL (sprich Dissel): Ein älterer Sprachstandard zur Formatierung
von XML-Dokumenten.
Beide Standards benötigen eine Software, welche eine entsprechende Formatvorlage lesen und damit ein gegebenes XML-Dokument
verarbeiten kann. Das Apache-Konsortium bietet beispielsweise eine
einfache Implementierung des Formatting Object Processors (FOP)
[14]. Für typografisch höherwertige Ansprüche werden allerdings
kommerzielle Lösungen benötigt.
Um Software-Applikationen schreiben zu können, welche auf XMLDokumenten operieren, werden Programmierschnittstellen benötigt.
Für die nachfolgenden Kapitel beziehen wir uns auf das herstellerund programmiersprachenneutrale Document Object Model (DOM)
[11]. Für dieses gibt es sprachspezifische Language Bindings und für
eine gewählte Zielsprache (z. B. Java oder Perl) wiederum Implementierungen, wie z. B. Xerces [12] vom Apache-Konsortium.

Das Document Object Model (DOM)

2.3
Publishing
Dass sich das Informationsverhalten der Menschen in den letzten
zehn Jahren sehr stark verändert hat, ist unumstritten. Vor allem mit
der Erfindung des Internets steht bei Informationsdienstleistern anstelle der herkömmlichen Produkte wie z. B. Bücher oder Zeitschriften
immer mehr die Werthaltigkeit von Inhalten im Vordergrund. Darüber hinaus weist das menschliche Nutzungsverhalten bei der Verwendung neuer Medien den Trend auf, immer speziellere und damit
auch kleinere Einheiten von Informationen abzufragen. Medien wie
das Internet und Datenbanken bieten deshalb vor allem für Informationsdienstleister die Möglichkeit, einmal gespeicherte und struktu-

2.3 Publishing

Cross-Media-Publishing

■
■
■

101

rierte Informationen gleichzeitig in verschiedener medialer Form zu
publizieren, um damit ihren Kunden Zusatznutzen wie etwa Suchfunktionen oder vernetzte Inhalte anbieten zu können. Diese Mehrfachverwendung von Daten (Cross-Media-Publishing) setzt also ein
Datenformat voraus, das es ermöglicht, unabhängig vom Ausgabemedium Inhalte und Strukturen von Informationen zu speichern [3]. Die
eXtensible Markup Language XML bietet diese Möglichkeit.
In diesem Abschnitt werden vier typische Einsatzgebiete von XML
im Electronic Publishing vorgestellt. Am Beispiel eines zu publizierenden Fachartikels wird auf die Besonderheiten beim Umgang mit
XML vorwiegend im textzentrierten Umfeld des Electronic Publishing
eingegangen [1].
Bevor das eigentliche Publishing mit medienneutralen Daten erfolgen kann, muss die Struktur des Dokumenttyps bekannt sein und
formalisiert werden. Die Dokumentanalyse, in der diese Strukturen
erarbeitet werden, wird in Kap. 2.3.1 vorgestellt. Als weitere Herausforderung für Informationsdienstleister und -hersteller stellt ist möglichst effiziente Überführung von Autorendaten nach XML anzusehen.
Kap. 2.3.2 beschreibt eine Vorgehensweise zur Konvertierung von
Word-Daten nach XML. Ausgewählte Beispiele beim Einsatz der
Transformationssprache XSLT speziell im Electronic Publishing zeigt
der Kap. 2.3.3. Um ein gedrucktes Werk zu erzeugen, kann man sich
der Sprache XSL-FO bedienen, deren Einsatzbereich in Kap. 2.3.4
vorgestellt wird

2.3.1
Dokumente und ihre Struktur
Was sind Dokumente?

„Unter Dokumenten im allgemeinsten Sinne verstehen wir Bündel
von Informationen, die in der Absicht erzeugt worden sind, dass sie
von Menschen wahrgenommen werden“ [4]. Beispiele für Dokumente
sind Tonbeiträge, Filme, Bilder und auch Textdokumente, die sowohl
1
in analoger als auch in digitaler Form vorliegen können .
Ein Textdokument besteht in erster Linie aus Inhalt – bei Textdokumenten also aus dem eigentlichen Text. Damit der Dokumentinhalt vom
Betrachter wahrgenommen werden kann, bedarf es der Visualisierung
des Dokumentes, z. B. auf dem Bildschirm oder auf Papier. Diese Form
der Darstellung bezeichnet man als layoutierte Darstellung oder Formatierung eines Dokumentes. Anders als das Layout bezieht sich die Struktur eines Dokumentes auf die vom Autor beabsichtigte Bedeutung der
einzelnen Informationsstücke. So besteht z. B. ein Buch aus der logi1

102

■
■
■

Im Folgenden beschränken wir uns nur auf Textdokumente, die digital vorliegen.

2 Einsatz von Markup-Languages

schen Struktur von Kapiteln, Unterkapiteln, Absätzen usw. Diese logische Struktur wird grafisch z. B. durch Überschriften in verschiedenen
typografischen Auszeichnungen (also durch das Layout) dargestellt [4].
Durch die Trennung des Layouts von Inhalt und Struktur ist es
möglich, Dokumente unabhängig vom Zielmedium zu archivieren
und bei Bedarf für das jeweilige Zielmedium zu publizieren. Im besten
Fall können aus einem solchen „medienneutralen“ Dokument, unter
Hinzunahme entsprechender Layoutbeschreibungen, mehrere Zielmedien gleichzeitig bedient werden. XML kann bei entsprechender
Anwendung eine solche Trennung leisten.
Im großen Anwendungsbereich von Textdokumenten unterscheidet man grundsätzlich zwei Typen [1]:

Dokumenttypen

• Datenzentrierte Dokumente
• Textzentrierte Dokumente
Den Typ der datenzentrierten Dokumente findet man häufig im
Bereich des Datentransports, also bei Datenbanken und Protokollen.
Typischerweise bestehen solche Dokumente aus einer fein-granularen
Struktur, deren Elemente hochgetypt sind. Die Ordnung der Elemente
spielt hier eine untergeordnete Rolle, da oft Eigenschafts-Wert-Paare
abgebildet werden.
2
Anders verhält es sich bei textzentrierten Dokumenten . Sie besitzen oft eine grobgranulare Struktur, deren Hauptbestandteil aus reinem Text kombiniert mit Auszeichnungen besteht. Da solche Dokumente vorwiegend von Menschen entwickelt und für die menschliche
Verwendung gedacht sind, ist die Anordnung der Elemente in diesen
3
narrativen Strukturen entscheidend.
Bevor ein Dokument strukturiert erstellt und publiziert werden
kann, bedarf es eines Prozesses zur Entwicklung einer Strukturbeschreibung von Dokumenten. Ziel eines solchen Prozesses ist die
Formalisierung von Strukturregeln in Form einer DTD oder eines
4
XML-Schemas . Eine ausführliche Beschreibung eines solchen Entwicklungsprozesses liefern Maler und Andalussi ausführlich in [2].
Beim elektronischen Publizieren von wissenschaftlichen Werken,
wie z. B. Artikel von Fachzeitschriften, hat man es sehr oft mit Mischformen von daten- und textzentrierten Bestandteilen in XML-Dokumenten zu tun. Abbildung 2.1 zeigt die schematische Aufteilung eines
solchen Dokumentes.
2
3

4

Oft auch dokumentzentriert genannt.
Narrative Strukturen: Strukturen, die durch eine zeitlich oder kausal bedingte
Reihenfolge angeordnet sind.
Aus Verständnisgründen verwenden wir die DTD als Sprache für Strukturregeln.

2.3 Publishing

■
■
■

103

Abb. 2.1:.
Typische Struktur eines Fachartikels

Der narrative Textteil (Fließtext) besteht weitgehend aus semistrukturierten, grobgranularen und oft ungetypten Strukturen. Den
Inhaltstyp für die Beschreibung solcher Bestandteile bezeichnet man
als Strukturtyp [2]. Strukturtypen werden nicht nach dem textuellen
Inhalt des Elementes benannt, sondern vielmehr nach der übergeordneten logischen Struktur.
Beispiele für Strukturtypen sind:
•
•
•
•
•
•

Absatz
Liste und Eintrag
Kapitel und Abschnitt
Tabelle
Abbildung
Überschrift

Vor allem die Strukturtypen von Absätzen und Listeneinträgen
weisen ein besonderes Inhaltsmodell auf. Neben dem „reinen“ Text
enthalten sie häufig Elemente zur Auszeichnung auf Textebene. Die
sog. Präsentationstypen sind Inhaltstypen die sich häufig auf typografische Hervorhebungen für das Print- oder Online-Medium beziehen,
wie z. B. eine Fett- oder Kursivstellung. Oft bleibt die Semantik hinter
einer solchen typografischen Hervorhebung verborgen, was zur Folge
hat, dass nur die reine Präsentationsauszeichnung zur Modellierung
5
herangezogen werden kann . Beispiele für Präsentationstypen sind:
• Fett
• Kursiv
5

104

■
■
■

Hier wird ein Bruch der Trennung zwischen Inhalt, Struktur und Layout
deutlich. Präsentationsauszeichnungen sind mediengebunden, wie z.B. Fett
für Online- und Printmedien. Für andere Medien (z.B. Datenbanken) hat
eine solche Auszeichnung nur wenig „Bedeutung“.

2 Einsatz von Markup-Languages

• Kapitälchen
• Unterstreichung
Neben dem oben beschriebenen narrativen Teil beinhaltet ein
Fachartikel häufig zusätzliche Daten über das Dokument selbst, sogenannte Metadaten. Metadaten können vor allem Informationen zur
Identifikation und Kategorisierung von textzentrierten Dokumenten
enthalten. Im Gegensatz zu den im Fließtext verwendeten Strukturtypen, wie z. B. Absätze oder Überschriften, werden für Metadaten im
Allgemeinen inhaltsbasierte Typen verwendet. Man versteht darunter
Elemente, deren Name auf den eigentlichen Inhalt des Elementes
schließen lässt. Inhaltsbasierte Typen modellieren sehr genau Dinge
aus der realen Welt und werden deshalb auch als semantisch reichhaltig bezeichnet. Beispiele für inhaltsbasierte Typen sind:
•
•
•
•

Name und Vorname des Autors
Institutsangaben
Datum des Reviews
Keywords

Ein Bereich, der zwar zweifellos zum „lesbaren“ Inhalt eines Artikels
zählt, der aber dennoch semantisch hochgradig ausdifferenziert ist, ist
bei wissenschaftlichen Publikationen der Block der Referenzen. Die
feingranulare Struktur von Referenzen ist vor allem bei der OnlineAnwendung von Dokumenten relevant. So kann eine Referenz einen
Link zu einem referenzierten Artikel oder Buch repräsentieren. Auch
Informationen darüber, „wer zitiert wen“ oder „welcher Autor wird am
häufigsten zitiert“, lassen sich anhand von Datenbankanwendungen
realisieren, wenn die nötigen Inhalte entsprechend modelliert sind [5].

2.3.2
Modellierung
Nach der Analyse der Dokumentstruktur lassen sich nun die erarbeiteten Informationseinheiten mit XML-Mitteln modellieren. Modellierungstechnisch interessant ist dabei die Umsetzung der Präsentationstypen; in dem hier vorgestellten Beispiel also die typografischen
Auszeichnungen. Der zentrale Container für Textdaten stellt das Element eines Absatzes dar, hier als Para modelliert.
<!ELEMENT Para (...)>
Das Inhaltsmodell von Para umfasst neben dem reinen Text
(#PCDATA) die erwähnten typografischen Auszeichnungen. Das sogenannte „mixed content model“ kann sowohl Text (#PCDATA) als auch
Kindelemente gemischt beinhalten. Reihenfolge und Häufigkeit der
Inhalte sind nicht festgelegt und spiegeln daher genau die Verwendung

2.3 Publishing

Das Mixed-Content-Model

■
■
■

105

in textzentrierten Dokumenten wider. Zusätzlich zum Element Para
können Auszeichnungen auch noch in anderen Strukturtypen wie z. B.
Überschriften vorkommen. Es bietet sich deshalb an, die Auszeichnungen wiederverwendbar als Parameter-Entity zu deklarieren.
<!ENTITY % TextModell "#PCDATA | Hochstellung |
Tiefstellung | Auszeichnung">
Neben den reinen typografischen Auszeichnungen treten auf Textebene häufig weitere Elemente wie z. B. Referenzen, Fußnoten oder
Formeln auf. Das vorhandene Parameter-Entity Textmodell kann
nun wiederverwendet und um weitere Elemente ergänzt werden.
<!ENTITY % ErwTextModell "%TextModell; | Referenz
| Fussnote | Formel">
Beide Inhaltsmodelle können nun den entsprechenden Strukturtypen zugeordnet werden. Für Para gilt das erweitere Textmodell, für
Überschriften das einfache Textmodell. Dies führt dann zu folgenden
Elementdeklarationen:
<!ELEMENT Para (%ErwTextModell;)*>
<!ELEMENT Heading (%TextModell;)*>
Gerade das „mixed content model“ ist aufgrund des hohen Grades
der Wiederverwendbarkeit prädestiniert für eine Strukturierung mit
Parameter-Entities.
Die Strukturen von Präsentationstypen finden sich in beinahe jeder
Klasse von Dokumenten wieder, in der nicht explizit semantische Ausdifferenzierung gefordert bzw. möglich ist. Eine daraus folgende Ent6
wicklung sind Standards wie z. B. DocBook von OASIS , der eine Abbildung immer wiederkehrender Strukturen aus dem Bereich der
technischen Dokumentation beinhaltet und eine viel genutzte Dokumentklasse für die Produktion von Büchern, Artikeln und Dokumenta7
tionen bereitstellt . Ein großer Vorteil dieser offenen Standards bieten
bereits entwickelte Tools, die das Arbeiten z. B. mit DocBook aus technischer Sicht unterstützen. Neben Anpassungen verschiedener XMLEditoren für DocBook stellt OASIS für die automatisierte Generierung
von PDF kostenlos ein XSL-FO Stylesheet zur Verfügung.

2.3.3
Datenherkunft
Wenn es um die Produktion von Zeitschriften oder Buchreihen auf
Basis von XML geht, stellt sich immer die Frage nach der Datenher6
7

106

■
■
■

Organization for the Advancement of Structured Information Standards
Weitere Standards im Bereich technische Dokumentation sind TEI und
DITA; für den Bereich der wissenschaftlichen Publikationen A++ von
Springer.

2 Einsatz von Markup-Languages

kunft. Vor allem im Bereich der wissenschaftlichen Publikationen ist
Microsoft Word® das meistgenutzte Autorenwerkzeug. Diese Tatsache liegt in der klassischen Rollenverteilung bei der Verlagsherstellung begründet. Der Autor, der am Beginn dieser Produktionskette
steht und Urheber der Inhalte ist, hat mit Word ein Werkzeug an der
Hand, welches ohne zusätzlichen Aufwand eine WYSIWYG-Umgebung bietet, um einen druckbaren Artikel zu erzeugen.
Wie bereits in Abschnitt 2.3.1 erwähnt, sind die Anforderungen an
das Ausgangsdokument bezüglich der Struktur sehr hoch. Vor allem
Metadaten und fein ausdifferenzierte Dokumentbestandteile stellen oft
ein Problem bei der Datenübernahme dar, die zusätzlich durch eingebettete Grafiken und die fehlende Strukturkontrolle erschwert wird.
Die Konvertierung von Daten zum Beispiel aus Word nach den Regeln eines spezifischen Dokumenttyps ist oft eine ungeliebte Notwendigkeit. Das Ziel einer solchen Konvertierung ist die verlässliche Überführung aller Informationen und Strukturen in das Zielformat. Die
Qualität der Quelldaten und die in einer DTD festgeschriebene Struktur der Zieldaten beeinflussen gleichermaßen den Aufwand für die
Konvertierung.
Voraussetzung für eine reibungslose Produktion ist ein formal und
technisch einwandfreies Manuskript. Um dies zu gewährleisten, stellen viele Verlage Autorenhinweise und Word-Dokumentvorlagen zur
Verfügung. Hält sich ein Autor an die Satzanweisungen der Autorenhinweise, so steht einer automatischen Verarbeitung der Daten nichts
im Wege. Eine Konvertierung muss folgende Funktionen abdecken:

Datenkonvertierung

• Umsetzung von Absatzformaten
• Umsetzung von Zeichenformaten wie fett, kursiv, hoch-/tiefgestellt,
unterstrichen
• Umsetzung von Fußnoten und Verzeichniseinträgen
• Umsetzung von Tabellen in ein XML-Tabellenmodell (z. B. CALS)
• Umsetzung von Sonderzeichen
• Export von eingebetteten Grafiken
In der Anwendung von Fachartikeln stellen zusätzlich die feingranularen Bereiche des Metadatenblocks und der Referenzen große Anforderungen an eine automatische Konvertierung. Für solche „kleinen“
Informationseinheiten stellt Word keinerlei semantische Auszeichnungsmöglichkeiten zur Verfügung.
Eine Möglichkeit besteht darin, Trennzeichen wie Komma oder
Doppelpunkt dazu zu benutzen, die fehlende Struktur innerhalb eines
Referenzeintrags mit Hilfe eines Word-Makros per Suchen und Ersetzen einzuarbeiten.

2.3 Publishing

■
■
■

107

Diese Technik bedingt jedoch die korrekte Umsetzung der Autorenhinweise. Da die Fehlerquelle einer solchen Vorkonvertierung sehr
hoch ist, kann sie oftmals nur interaktiv eingesetzt werden.
Entscheidend für einen reibungslosen Prozess bei der Datenübernahme ist die genaue Vorbereitung der Erfassung. Eine wichtige Anforderung die bereits bei der Erfassung berücksichtigt werden sollte,
besteht also darin, den Autoren in ihrer bekannten Systemumgebung
eine Möglichkeit zu schaffen, strukturierte Dokumente zu erzeugen.
Die naheliegendste Lösung wäre es, den Autoren eine WordDokumentvorlage (.dot) zur Verfügung zu stellen, die alle zu verwendenden Formatvorlagen enthält. Allerdings würde bei dieser Lösung
nichts den Benutzer abhalten, anstelle einer Überschrift1 einen
optisch identischen Absatz mit der Schriftgröße 20 pt und fett zu formatieren. Mit VBA-Programmierung lässt sich jedoch dieser Ansatz
um Prüfmechanismen erweitern und auch nicht gewünschte WordFunktionen ausschalten. Das so entstandene Autorenwerkzeug innerhalb von Word mit individuell angepasster Oberfläche und Symbolleisten würde die Fehlerquelle von nicht vordefinierten Strukturen
enorm minimieren.
Die eigentliche Überführung des Word-Dateiformates nach XML
kann ab der Version 2003 Word selbst erledigen. Praktische Tipps
dazu gibt Montero Pineda in [15]. Zudem kann die Konvertierung
auch von verschiedenen Software-Tools durchgeführt werden. Beispiele dafür sind:
•
•
•
•

Infinity loop: UpCast
Logictran: R2Net
MediaTEXT: XML Word-Konverter
SCHEMA: MarkupKit

All diesen Tools ist jedoch eine Eigenschaft gemein: Die Konvertierung von Word nach XML erfolgt oft in eine herstellerspezifische
Struktur mit dazugehöriger DTD. Ein weiterer Schritt, nämlich die
Transformation in die erforderliche Zielstruktur, ist also notwendig.

2.3.4
Verarbeitung
Wurden einmal XML-Strukturen erzeugt, so liegen diese in einem
standardisierten Dateiformat vor. Der große Vorteil des Einsatzes von
XML beim elektronischen Publizieren ist neben den Eigenschaften des
Formates selbst, wie Herstellerunabhängigkeit, Plattformunabhängigkeit usw., auch das große Angebot an kommerziellen und freien Softwaretools und Sprachen zur Weiterverarbeitung von XML-Doku-

108

■
■
■

2 Einsatz von Markup-Languages

menten. Die standardisierte Transformationssprache XSLT wird beispielsweise häufig eingesetzt, um XML-Strukturen in andere XMLAnwendungen umzuwandeln.
Im Folgenden werden einige ausgewählte Transformationsbeispiele
aus dem Bereich des elektronischen Publizierens vorgestellt.
Eine häufige Anwendung besteht darin, nicht für eine Publikation
benötigte XML-Elemente aus einer Instanz zu entfernen, den Inhalt
des Elementes jedoch beizubehalten.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:output method="xml" indent="no" encoding="UTF-8"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- loesche den Tag "txt",
<xsl:template match="txt">
<xsl:apply-templates/>
</xsl:template>
</xsl:stylesheet>

aber behalte den Inhalt -->

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

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:output use-character-maps="my_map" doctype-system="doc.dtd"/>
<xsl:character-map name="my_map">
<xsl:output-character character="&#xE4;" string="&amp;auml;"/>
<!-- usw. -->
</xsl:character-map>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>

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

<?xml version="1.0" encoding="UTF-8"?>
<article>
<title>Extensible Markup Language</title>
<section>
<title>Einführung</title>
<para>Die Extensible Markup Language, abgekürzt <emp entry="XML">XML</emp> , ist
ein Standard zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer
Baumstruktur.</para>
<para>XML definiert dabei die Regeln für den Aufbau solcher Dokumente</para>
</section>
<section>
<title>Anwendungen</title>
<para>Für einen konkreten Anwendungsfall ("<emp entry="XML">XML</emp> -Anwendung")
müssen die Details der jeweiligen Dokumente spezifiziert werden. </para>
<para>Dies betrifft insbesondere die Festlegung der
<emp entry="Strukturelement">Strukturelemente</emp> und ihre Anordnung innerhalb
des <emp entry="Dokumentbaum">Dokumentenbaums</emp>.</para>
</section>
<!-- weitere sections -->
</article>

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.
<xsl:template match="emp">
<a name="{generate-id(@entry)}">
<xsl:value-of select="."/>
</a>
</xsl:template>

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.
<xsl:for-each select="//emp/@entry">
<li>
<a href="#{generate-id()}">
<xsl:value-of select="."/>
</a>
</li>
</xsl:for-each>

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.
<xsl:for-each-group select="//emp" group-by="@entry">
<p>
<b>
<xsl:value-of select="current-grouping-key()"/>
</b>
<br/>
<ul>
<xsl:for-each select="current-group()/@entry">
<li>
<a href="#{generate-id()}">
<xsl:value-of select="../../../position()"/>
<xsl:text> </xsl:text>
<xsl:value-of select="../../../title"/>
</a>

112

■
■
■

2 Einsatz von Markup-Languages

</li>
</xsl:for-each>
</ul>
</p>
</xsl:for-each-group>

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.

2 Einsatz von Markup-Languages

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 Einsatz von Markup-Languages

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.

2 Einsatz von Markup-Languages

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“.

2.4 XML-gestützte Anwendungsentwicklung

■
■
■

119

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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xmeml>
<xmeml version="1">
<sequence id="IDB Hymne">
<name>IDB Hymne</name>
<duration>4512</duration>
<rate>
<ntsc>FALSE</ntsc>
<timebase>25</timebase>
</rate>
<timecode>
<rate>
<ntsc>FALSE</ntsc>
<timebase>25</timebase>
</rate>
<string>01:00:00:00</string>
<frame>90000</frame>
<source>source</source>
<displayformat>NDF</displayformat>
</timecode>
<in>-1</in>
<out>-1</out>
<media>
<video>
<format>
<samplecharacteristics>
<width>720</width>
<height>576</height>
<anamorphic>FALSE</anamorphic>
<pixelaspectratio>PAL-CCIR-601
</pixelaspectratio>
<fielddominance>lower</fielddominance>
<rate>
<ntsc>FALSE</ntsc>
<timebase>25</timebase>
</rate>
<colordepth>24</colordepth>
<codec>
<name>Apple DV - PAL</name>
...

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
<timebase> erkennbar, dass es sich bei dem Videoschnittprojekt um

120

■
■
■

2 Einsatz von Markup-Languages

<clipitem>
<name>Intro</name>
<duration>575</duration>
<rate>
<ntsc>FALSE</ntsc>
<timebase>25</timebase>
</rate>
<in>0</in>
<out>575</out>
<start>0</start>
<end>575</end>
<subclipinfo>
<endoffset>3937</endoffset>
</subclipinfo>
<enabled>TRUE</enabled>
<anamorphic>FALSE</anamorphic>
<alphatype>none</alphatype>
<masterclipid>Intro</masterclipid>
<syncoffset>0</syncoffset>
...

ein Projekt handelt, welches mit einer Bildrate von 25 Bildern pro
Sekunde arbeitet. Weiterhin ist durch die Marken <width> und
<height> 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 <duration> die Dauer des
Films abgelesen werden. Es handelt sich dabei um 4512 Bilder. Aus der
Angabe 25 des Elements <timebase> 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 <duration>) und über keinen AlphaKanal verfügt (Marke <alphatype>).
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

2.4 XML-gestützte Anwendungsentwicklung

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.

2 Einsatz von Markup-Languages

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.

2.4 XML-gestützte Anwendungsentwicklung

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

■
■
■

2 Einsatz von Markup-Languages

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>
<Vorname>Fred</Vorname>
<Nachname>Feuerstein</Nachname>
<Nachkomme>
<Pebbles>
<Vorname>Pebbles</Vorname>
<Nachname>Feuerstein</Nachname>
<Nachkomme></Nachkomme>
</Pebbles>
</Nachkomme>
</Fred>

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;}}

2.4 XML-gestützte Anwendungsentwicklung

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

■
■
■

2 Einsatz von Markup-Languages

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 Einsatz von Markup-Languages

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

■
■
■

2 Einsatz von Markup-Languages

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<tableModel.getColumnCount(); colIndex++){
appendElement(
row, "cell", tableModel.getValueAt(rowIndex,
colIndex));
}
}
}

Abb. 2.19:
Eine Methode zum Transformieren eines
SimpleTableModel-Objekts.
Die lokale Variable doc enthält nach
Ausführung eine Referenz auf das
resultierende DOM-Objekt

Die textuelle Repräsentation für unser Datumsbeispiel lautet:

2.5 Trennung der Implementierungslogik und Präsentation einer
Anwendung

■
■
■

131

Abb. 2.20:
Textdarstellung der XML-Serialisierung
eines SimpleTableModel-Objektes

<table class="servlet.xsl.DateLocaleTable">
<head>
<column class="java.util.Locale">Locale</column>
<column class="java.util.Date">Datumsformat</column>
<column class="java.util.Date">Zeitformat</column>
</head>
<body>
<row>
<cell>Germany</cell>
<cell>Montag, 28. November 2005</cell>
<cell>11:46:15 CET</cell>
</row>
<row>
<cell>United States</cell>
…

Damit kann nun die eigentliche Sesrvlet-Klasse implementiert werden:
Abb. 2.21:
Die Servlet-Klasse verwendet sowohl
das Tabellenmodell als auch
den Serialisierer zur Erzeugung
einer XML-Antwort an den Client.

public class Datesource extends HttpServlet{
public void doGet(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException{
resp.setContentType("text/xml");
final DateLocaleTable dlTable =
new DateLocaleTable(new Locale[]
{Locale.GERMANY, Locale.US, Locale.FRANCE,
Locale.ITALY});
final PrintWriter pw = resp.getWriter();
serializer.serialize(dlTable, pw);
resp.flushBuffer();
getServletContext().log("Created response");
}
public Datesource()
throws ParserConfigurationException{
super();
serializer = new TableSerializer();
}
private final TableSerializer serializer;
}

Der Web-Client kann mit einer entsprechenden Antwort nicht allzu
viel anfangen. In Ermangelung eines Stylesheets wird er den XMLQuelltext darstellen:

132

■
■
■

2 Einsatz von Markup-Languages

Abb. 2.22:
Die Darstellung des
resultierenden XML DOM Baumes
in einem HTML Browser

Dies kann immerhin zur Fehlersuche dienen, falls Probleme mit
den nachfolgend beschriebenen Konversionsmechanismen auftreten.

2.5.5
XSL-Stylesheets für die Zielformate HTML und PDF
Unabhängig von der Frage der Integration in unser Servlet können wir
zunächst XSL-Stylesheets für die XML-Serialisierung der ServletDaten implementieren. Wir betrachten zunächst ein auf unser Datumsbeispiel zugeschnittenes Stylesheet:
<xsl:template match="/">
<HTML>
<HEAD>
<TITLE>Datumsangaben in unterschiedlichen
Locales</TITLE>
</HEAD>
<BODY>
<H1>Datumsangaben in unterschiedlichen Locales</H1>
<table>
<tr>
<th>Locale</th>
<th>Datumsformat</th>
<th>Zeitformat</th>
</tr>
<xsl:apply-templates
select="table/body/row"/>
</table>
</BODY>
</HTML> ...

2.5 Trennung der Implementierungslogik und Präsentation einer
Anwendung

Abb. 2.23:
Ausschnitt eines Stylesheets zur
Transformation von Datums- und
Zeitangaben in das HTML-Format

■
■
■

133

Das hier noch fehlende Template für <row>-Elemente finden Sie
als Bestandteil des bereits erwähnten Sourcecodes zum ServletBeispiel. Ein analoges Stylesheet kann via Formatting Objects zur
Erzeugung einer PDF-Ausgabe verwendet werden:
Abb. 2.24:
Ein XSLT zur Generierung eines FO
Dokuments. Aus diesem kann
unmittelbar eine PDF Ausgabe erzeugt
werden

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" ... >
<xsl:output indent="yes" method="xml"/>
<xsl:template
match="/table[@class='servlet.xsl.DateLocaleTable']">
<fo:root font-size="10pt"
xmlns:fo="http://www.w3.org/1999/XSL/Format">
<!-- layout master set --> ...
<fo:page-sequence masterreference="simplePageLayout">
...
<fo:flow flow-name="xsl-region-body">
<fo:block font-size="20pt" font-weight="bold"
>Länderspezifische Datumsangaben</fo:block>
<fo:table table-layout="fixed">
<fo:table-column column-width="20mm"/>
<fo:table-column column-width="30mm"/>
<fo:table-column column-width="30mm"/>
<fo:table-header font-weight="bold">
<fo:table-row>
<fo:tablecell><fo:block>Locale</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>Datumsformat</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>Zeitformat</fo:block>
</fo:table-cell>
</fo:table-row>
</fo:table-header>
<fo:table-body>
<xsl:apply-templates select="body/row"/>
</fo:table-body>
</fo:table>
</fo:flow>
</fo:page-sequence>
</fo:root>
</xsl:template>
...
</xsl:stylesheet>

134

■
■
■

2 Einsatz von Markup-Languages

2.5.6
Servlets und Filter
Die Konfiguration einer Servlet-Anwendung kann in der Definitionsdatei web.xml eines Servlet-Kontexts erfolgen. Zunächst wird dort der
Java-Klassenname des Servlets auf einen Servlet-Namen gemappt:
<servlet>
<servlet-name>servlet-xsl-Datesource</servlet-name>
<servlet-class>servlet.xsl.Datesource</servlet-class>
</servlet>

Nun wird das Mapping zwischen einer URL und dem zuvor definierten Servlet definiert. Das verbindende Element ist der Name des
Servlets:
<servlet-mapping>
<servlet-name>servlet-xsl-Datesource</servlet-name>
<url-pattern>/datesource</url-pattern>
</servlet-mapping>

Dies bedeutet, dass der Zugriff auf die URL http://.../.../datesource
vom Servlet-Container auf unser Servlet gelenkt wird. Der Container
wird das Servlet instanziieren, danach dessen init-Methode aufrufen
und dann der doGet-Methode die HTTP-Parameter des ClientZugriffs übergeben.
Es stellt sich nun die Frage, auf welche Weise die Stylesheets in die
Servlet-Implementierung eingebunden werden können. Prinzipiell
kann die XSL-Transformation unmittelbar in den Servlet-Code integriert werden. Das Servlet-API bietet alternativ die Möglichkeit, diesen
Schritt als sogenannten Filter zu realisieren.
Filter erlauben es, die Erzeugung einer HTTP-Antwort als Abfolge
einzelner Transformationsschritte zu realisieren. Die Ausgabe des
n-ten Filterschrittes ist dabei die Eingabe des (n-1)-ten Filters. Das
Prinzip entspricht dem UNIX-Pipe-Konzept.
Für unser Beispiel benötigen wir einen Filter, welcher XML nach
HTML transformiert. Die Definition des Filters erfolgt ebenfalls in
web.xml:

2.5 Trennung der Implementierungslogik und Präsentation einer
Anwendung

■
■
■

135

<filter>
<filter-name>XSLT_Filter</filter-name>
<filter-class>servlet.xsl. </filter-class>
<init-param>
<param-name>xslt</param-name>
<param-value>
/Input/Xslt/date2html.xsl</param-value>
</init-param>
</filter>

Diese Definition korrespondiert zu einer Java-Klasse XSLTFilter
im Package servlet.xsl, welche wir später betrachten. Über das
<initparam>-Element können beliebig viele Parameter an die
XSLTFilter-Instanz weitergereicht werden. In unserem Beispiel verwenden wir den Namen des XSL-Stylesheets als Parameter xslt.
Bislang haben wir noch nicht spezifiziert, für welche Prozesse obiger Filter verwendet werden soll. Dies erfolgt mit Hilfe von:
<filter-mapping>
<filter-name>XSLT_Filter</filter-name>
<url-pattern>/datesource</url-pattern>
</filter-mapping>

Diese Definition legt fest, dass der Filter mit Namen XSLT_Filter
beim Zugriff auf die URL http://.../.../datesource verwendet werden
soll. Auf diese Weise erhält der Client das Ergebnis der HTMLTransformation:
Abb. 2.25:
Die endgültige HTML Ansicht

136

■
■
■

2 Einsatz von Markup-Languages

2.5.7
Die Java-Implementierung des Filters
Unter http://java.sun.com/products/servlet/Filters.html findet sich eine
gute Einführung zur Implementierung von Filtern. Der in diesem
Dokument vorgestellte XSLT-Filter diente als Ausgangsbasis für die
im Datumsbeispiel verwendeten XSLT und XSLT-FO/PDF Filter.
Gemäß der Servlet-Spezifikation werden Filter und Servlets über
eine identische Schnittstelle durch den Servlet-Container instanziiert:
• Erzeugung via des Defaultkonstruktors
• Aufruf der init-Methode des Servlets oder Filters
Bei einem Servlet kann die init-Methode verwendet werden, um
z. B. Datenbankverbindungen aufzubauen. Unser XSLT-Filter benötigt
z. B. die Angabe, welches Stylesheet zur Transformation verwendet
werden soll.
Entsprechende Parameter können wie bereits gezeigt in der Datei
web.xml des Servlet-Containers definiert werden. Das Interface eines
Filters lautet:

public abstract interface javax.servlet.Filter extends java.lang.Object {
public abstract void init(FilterConfig arg) throws
javax.servlet.ServletException;
public abstract void doFilter(ServletRequest arg, ServletResponse arg, FilterChain arg)
throws java.io.IOException, javax.servlet.ServletException;
public abstract void destroy();
}

Das FilterConfig-Argument der init-Methode stellt ein Dictionary
bereit, in welchem die Parameternamen als eindeutige Schlüssel auftreten. Über diese können dann die Werte aus der Konfiguration
web.xml weitergereicht werden. Die doFilter-Methode leistet die eigentliche Arbeit des Filters, in unserem Fall die Transformation des
über das ServletRequest-Argument erhaltenen XML-Eingabestroms
auf die Ausgabeseite des Filters unter Anwendung des Stylesheets.
Der XSLT-Filter erzeugt bei der Initialisierung intern ein javax.xml.
transformer.Transformer-Objekt, welches in der init-Methode mit
dem XSL-Stylesheet initialisiert wird. Der Aufruf der doFilter-Methode durch den Servlet-Container bewirkt dann:

2.5 Trennung der Implementierungslogik und Präsentation einer
Anwendung

■
■
■

137

• Die Transformation des Eingabestroms,
• das Setzen des korrekten Ausgabetyps im HTTP-Response-Header
als text/html sowie
• das Setzen der korrekten Länge (content-length) im Header der
HTTP-Antwort.
Der so implementierte Filter kann für verschiedene Transformationen unterschiedlicher Servlets mit variierenden Stylesheets verwendet werden. Die entsprechende Parametrierung erfolgt wie diskutiert
über die Servlet-Definitionen in web.xml.

2.5.8
PDF-Ausgabe
Für eine hochqualitative Druckausgabe wird ein entsprechendes Format benötigt. Wir demonstrieren die PDF-Ausgabe unter Verwendung des Formatting Object Processors (FOP), siehe:
http://xmlgraphics.apache.org/fop.
Die Definition des entsprechenden Filters in web.xml lautet:
<filter>
<filter-name>FO_Filter</filter-name>
<filter-class>servlet.xsl.FOFilter
</filter-class>
<init-param>
<param-name>xslt</param-name>
<param-value>
/Input/Xslt/date2fo.xsl</param-value>
</init-param>
</filter>

Die Java-Implementierung der Klasse servlet.xsl.FOFilter erfolgt
analog zum reinen XSLT-Beispiel mit Konversion in das HTMLFormat. Allerdings muss zusätzlich das durch die Transformation
erzeugte FO-File noch nach PDF gewandelt werden.
Prinzipiell ist es denkbar, diese letzte Umwandlung von FO als
XML-Format nach PDF ebenfalls als eigenen Filter zu implementieren.
Es wären dann zwei aufeinanderfolgende Filter nötig, was sich negativ
auf die Performance auswirkt. Demgegenüber steht die Tatsache, dass
eine FO-Software i. A. bereits den Fall vorsieht, unmittelbar das eigentliche XML-Dokument sowie das anzuwendende XSL-FO-Stylesheet als Eingaben zu akzeptieren, um daraus PDF zu erzeugen. Das

138

■
■
■

2 Einsatz von Markup-Languages

reine FO File existiert dann nur als internes Zwischenprodukt im Formatierer, welches höchstens für die Fehlersuche interessant ist.
In der Beispielimplementierung wird dazu der frei verfügbare Formatting Objects Processor (FOP) des Apache-Konsortiums verwendet.
Für weiter gehende typografische Ansprüche ist es ratsam, eine kommerzielle Implementierung zu verwenden, beispielsweise das Produkt
Xep von http://www.renderx.com.
Wie im Fall von HTML benötigen wir noch das Mapping einer URL
auf diesen Filter:
<filter-mapping id="xml2fo">
<filter-name>FO_Filter</filter-name>
<url-pattern>/pdf/datesource</url-pattern>
</filter-mapping>

Dies führt im genannten Beispiel beim Zugriff auf die URL
http://localhost:8080/Vorlesungen/pdf/datesource
zu:
Abb. 2.26:
Eine zur HTML Ansicht analoge Sicht als
generiertes PDF

Das hier verwendete XSL-FO-Stylesheet ist bereits etwas aufwendiger: Die Zeilen der Tabelle werden abwechselnd normal bzw. grau
hinterlegt dargestellt.

2.5 Trennung der Implementierungslogik und Präsentation einer
Anwendung

■
■
■

139

2.5.9
Weitere Möglichkeiten
Die hier vorgestellte Möglichkeit der Definition von Filterketten findet
sich in wesentlich elaborierterer Form im Cocoon Framework, welches
insbesondere nicht auf Java-Applikationen beschränkt ist. Für viele
praktische Zwecke ist die Servlet-Spezifikation aber flexibel genug.
Die Mächtigkeit der Sprache XSL ermöglicht sehr flexible Formatierungsmechanismen. Beispielsweise wurden im Datumsbeispiel
XSL-Templates verwendet, welche aufgrund der Beschränkung auf
dreispaltige Tabellen nur für das Datumsbeispiel anwendbar sind.
Möglich ist:
• die Erstellung generischer Templates zur Formatierung beliebiger
Tabellen,
• die Erstellung dedizierter Templates für bestimmte Tabellentypen,
• die Formatierung einzelner Felder (z. B. Datum) gemäß dem
zugrunde liegenden Datentyp.
Wir können etwa Kundenaufträge via JDBC aus einer Datenbank
lesen und dann die einzelnen Positionen eines Auftrags als SimpleTableModel erzeugen. Über den im Kopf der XML-Serialisierung enthaltenen Java-Datentyp kann nun ein Template speziell für Auftragspositionen geschrieben werden, welches die für diesen Spezialfall
gewünschte Formatierung liefert.
Darüber hinaus können andere Modelle verwendet werden. Für
Dateisysteme bietet sich analog ein SimpleTreeModel an, welches
Baumgraphen repräsentiert. Diese können dann mit entsprechenden
Stylesheets visualisiert werden.
Möglich ist auch die Generierung von Vollgrafiken bzw. anderen
Ausgabeformaten. Beispielsweise können prozentuale Ergebnisse
einer Wahl als Kuchendiagramm erzeugt werden: Ein XSL-Konverter
erstellt zunächst ein Diagramm im SVG Format, welches dann z. B.
durch das Batik-Framework über einen Servlet-Filter in ein Pixelformat umgewandelt wird.

Literatur
[1]
[2]
[3]
[4]

140

■
■
■

Ron Bourret: Xml and Databases. Technical report.
http://www.rpbourret.com/xml/XMLAndDatabases.htm
E. Maler, J. E. Andaloussi: Developing SGML Dtds. Prentice Hall, 1995
H. P. Fritsche: Cross Media Publishing – Konzept, Grundlagen und Praxis.
Galileo Press, 2001
Wilhelm, Heckmann: Einführung in die Dokumentverarbeitung. AddisonWesley, 1996

2 Einsatz von Markup-Languages

[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]

Science Citation Index.
http://scientific.thomson.com/products/sci/
T. Ott, G. Fuelle et al.: XML-Kompendium. Pagina GmbH, 2004
Extensible Markup Language (XML) 1.0 (Fourth Edition).
http://www.w3.org/TR/2006/REC-xml-20060816
XSL Transformations (XSLT) Version 1.0
http://www.w3.org/TR/xslt
Extensible Stylesheet Language (XSL) Version 1.0.
http://www.w3.org/TR/xsl
Scalable Vector Graphics (SVG) 1.1.
http://www.w3.org/TR/SVG11
Document Object Model (DOM) Level 3 Core Specification
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407
Apache Xerces
http://xerces.apache.org
Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification.
http://www.w3.org/TR/CSS21
Apache Fop.
http://xmlgraphics.apache.org/fop
M. Montero Pineda, J. Sieben: Professionnelle XML-Verarbeitung mit XML.
dpunkt Verlag, 2006

Literatur

■
■
■

141

3 Computer-Supported
Cooperative Work (CSCW) –
kollaborative Systeme und
Anwendungen
Ansgar Gerlicher

Das folgende Kapitel geht auf das interdisziplinäre Forschungsgebiet
Computer-Supported Cooperative Work (CSCW) ein und beschreibt
den Einsatz von CSCW-Systemen in Bezug auf die Medieninformatik.
Zunächst wird der Begriff „CSCW“ in diesem Zusammenhang definiert.
CSCW-Systeme kann man in Anwendungsbereiche und Synchronisationstypen einordnen. Nach der Begriffsdefinition und der Einordnung der CSCW in die Medieninformatik werden die folgenden drei
Anwendungsbereiche anhand einer Reihe von Beispielen vorgestellt.
Neben dem Einsatzzweck des jeweiligen Systems wird auch auf die
Prinzipien der technischen Realisierung solcher Systeme eingegangen.
Dem/der Leser/-in soll damit ein grundsätzliches Verständnis für den
technischen Aufbau und die Funktionsweise kollaborativer Systeme
vermittelt werden:
• Groupware und Workgroup Computing
• Versionsverwaltung
• Mehrbenutzer-Editoren
Folgende Synchronisationstypen können dabei festgestellt werden:

Eingruppierung der CSCW-Systeme

• Synchron
• Asynchron
• Multisynchron
Synchrone Systeme unterstützen das gleichzeitige Arbeiten mehrerer Personen im selben Bereich oder auf denselben Datenobjekten.
Dies ist zum Beispiel bei Chat-Systemen oder den meisten Mehrbenutzer-Editoren der Fall. Bei asynchronen Systemen arbeiten mehrere
Personen „nacheinander“ auf einem oder mehreren Datenobjekten.

3.1 Begriffsdefinition CSCW

■
■
■

143

Es ist also kein gleichzeitiger Zugriff (z. B. lesend oder schreibend) auf
eine Ressource oder einen Bereich möglich, wie zum Beispiel bei verschiedenen Versionsverwaltungs- oder Groupware-Systemen. Multisynchrone Systeme erlauben das gleichzeitige Arbeiten auf einer Kopie desselben Datenobjekts, wobei das Datenobjekt im Nachhinein
synchronisiert wird, also zwischen asynchronem und synchronem
Modus umgeschaltet wird. Dieser Wechsel zwischen Synchronisationstypen geschieht meist automatisch, kann bei manchen Systemen
aber auch manuell vorgenommen werden. Es gibt MehrbenutzerEditoren (wie z. B. SAMS [1]), die das manuelle Umschalten zwischen
verschiedenen Synchronisationstypen erlauben.
Die Einordnung von CSCW-Systemen in Groupware, Versionsverwaltung und Mehrbenutzer-Editoren in diesem Kapitel dient der Gliederung, ist aber in manchen Fällen nicht eindeutig möglich. Manche
CSCW-Systeme haben Eigenschaften, die zum Beispiel sowohl einer
Groupware als auch einer Versionsverwaltung entsprechen. Manche
Mehrbenutzer-Editoren integrieren zum Beispiel eine Versionsverwaltung. Auch können innerhalb eines CSCW-Systems verschiedene Synchronisationstypen festgestellt werden. Die Abb. 3.1 zeigt die verschiedenen CSCW-Anwendungsbereiche und Synchronisationstypen.
Das Unterkapitel „Architektur kollaborativer Systeme“ soll einen
Überblick über die Grundprinzipien der Architektur solcher CSCWSysteme geben, bei denen es sich um verteilte Systeme handelt.
Bei CSCW-Systemen nimmt die Kommunikation von Menschen einen besonderen Stellenwert ein. Daher sollte hier besonderes Augenmerk auf die Softwareergonomie und die Bewusstheit, die sogenannte
„Awareness“, gelegt werden. Das Unterkap. 3.8, „Awareness in kollaborativen Systemen“, befasst sich damit. Zum Abschluss des Kapitels
wird ein Ausblick auf mögliche zukünftige Entwicklungen und potenzielle neue Einsatzgebiete der CSCW gegeben.

Abb. 3.1:
CSCW-Anwendungsbereiche und
Synchronisationstypen in der Übersicht

144

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

3.1
Begriffsdefinition CSCW
Durch den technischen Fortschritt vor allem im Bereich der Computertechnologie, Netzwerktechnik und Telekommunikation wurden
neue Möglichkeiten der Zusammenarbeit geschaffen. Heutzutage
erlaubt die weltweite Vernetzung von Computern mehr Effizienz in
der gemeinschaftlichen Bewältigung einer Aufgabe, selbst über weite
Entfernungen hinweg.
Das Forschungsgebiet der computerunterstützten Zusammenarbeit
(Computer-Supported Cooperative Work) beschäftigt sich mit der
Nutzung dieser Technologien, um die Arbeitsweise von Menschen an
einer gemeinsamen Aufgabe zu verbessern und die Arbeit effizienter
und einfacher zu gestalten. CSCW ist ein Forschungsgebiet, das in
vielen Disziplinen wie der Soziologie, Psychologie, den Arbeits- und
Organisationswissenschaften, dem Management, der Ethnologie, Anthropologie, den Wirtschaftswissenschaften und nicht zuletzt der
Informatik behandelt wird.
In der Literatur findet man mehrere Definitionen für den Begriff
„Computer-Supported Cooperative Work“. Angeblich erstmals er1
wähnt von Irene Greif und Cashman (1984) , wird der Begriff CSCW
von Paul Wilson (1991) folgendermaßen beschrieben:

CSCW ist ein multidisziplinäres
Forschungsgebiet

„CSCW is a generic term that combines the understanding of the
way people work in groups with the enabling technologies of computer networking and associated hardware, software, services
and techniques“ [2]
Mit dieser Definition umfasst der Begriff CSCW verschiedenste
Disziplinen wie Soziologie, Arbeitspsychologie, Ethnologie, aber auch
die verschiedensten Bereiche der Informatik (z. B. Verteilte Systeme,
Informationssysteme, Usability, Künstliche Intelligenz) und der Elektrotechnik. Grudin bestätigt dies (1994), mit der Aussage:
„CSCW started as an effort by technologists to learn from economists, social psychologists, anthropologists, organizational theorists, educators and anyone else who could shed light on group
activity.“ [3]
CSCW ist also ein allgemeiner Begriff, der das „universelle Arbeitsgebiet und die dazugehörigen Forschungsfelder bezeichnet“ [4], die
sich mit der computergestützten Zusammenarbeit von Menschen
beschäftigen.
1

In der Literatur finden sich
verschiedenste Definitionen von
Groupware und CSCW

Quelle: http://de.wikipedia.org/wiki/CSCW.

3.1 Begriffsdefinition CSCW

■
■
■

145

Am häufigsten wird im Zusammenhang mit CSCW der Begriff
„Groupware“ genannt. Ein oft verwendetes Zitat stammt von Clarence
(Skip) Ellis. Er definiert dabei Groupware als:
„computer-based systems that support groups of people engaged
in a common task (or goal) and that provide an interface to a
shared environment. “ [5]
Damit wäre Groupware also die Bezeichnung für Softwarelösungen
und CSCW das allgemeine Forschungsgebiet. Greenberg allerdings
definiert 1991 CSCW folgendermaßen:
„CSCW is a scientific discipline that guides the thoughtful and
appropriate design and development of computer systems to support group work. “ [6]
In der Literatur findet man daher den Begriff Groupware häufig in
Verwendung als Synonym zu CSCW.
Dieses Kapitel bezeichnet mit Groupware spezielle Softwaresysteme, welche die Zusammenarbeit von Menschen (Teilnehmern) an
einer gemeinsamen Aufgabe unterstützen sollen und bei denen das
Hauptaugenmerk auf der Kommunikation zwischen den Teilnehmern
und der Koordination von Aufgaben liegt. Groupware-Systeme sind
hier also nur ein Teilbereich des verschiedenste Disziplinen umfassenden Forschungsgebiets CSCW.
Wir definieren CSCW wie folgt:
Mit Computer-Supported Cooperative Work (CSCW) wird das
verschiedenste Disziplinen umfassende Forschungsgebiet bezeichnet, das sich mit der Unterstützung der Zusammenarbeit
von Menschen durch Computertechnologien (Software, Hardware, Infrastruktur) beschäftigt.

Die Begriffe Cooperation und
Collaboration stiften Verwirrung

Teilbereiche der CSCW beschäftigen sich mit der Entwicklung von
verschiedenen Softwaresystemen, die diese Zusammenarbeit ermöglichen und verbessern sollen. Diese Teilbereiche sind unter anderem Groupware-, Versionsverwaltungssysteme und MehrbenutzerEditoren.
Verwirrung stiftet in der Literatur oft die verschiedene Verwendung
des Begriffs „Cooperation“. Dieser wird von vielen Autoren oft mit
„Collaboration“ gleichgesetzt, andere dagegen unterscheiden die beiden Begriffe sehr wohl, wie zum Beispiel Dillenbourg, Baker et al. 1995:
„Cooperation and collaboration do not differ in terms of whether or
not the task is distributed, but by virtue of the way in which it is divided; in cooperation the task is split (hierarchically) into independent subtasks; in collaboration cognitive processes may be (heterarchically) divided into intertwined layers. In cooperation,

146

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

coordination is only required when assembling partial results,
while collaboration is“...„a coordinated, synchronous activity that
is the result of a continued attempt to construct and maintain
a shared conception of a problem.“ [7]
In diesem Kapitel wird „Cooperation“ als Synonym zu „Collaboration“ verwendet, da beide Begriffe im Deutschen mit „Zusammenarbeit“ übersetzt werden können und um Begriffsverwirrungen zu vermeiden.

3.2
CSCW in der Medieninformatik
Digitale Medien spielen vor allem im Bereich der Groupware eine
wichtige Rolle. Angefangen bei einfachen Textnachrichten, wie sie bei
Chats, Newsgroups, RSS Feeds, E-Mail und anderen Diensten eingesetzt werden, über Hypermedia bei Wikis und Weblogs bis hin zur
interaktiven Multimedia und Audio-/Video-Datenströmen bei modernen Konferenzsystemen wie dem Virtual Conferencing.
Aber auch bei Versionsverwaltungssystemen spielen digitale Medien eine wichtige Rolle, wenn auch eher eine passive. Versionsverwaltungssysteme erlauben nicht nur die Verwaltung von Quellcode
oder einfachen (z. B. ASCII) Textdokumenten, sondern verwalten
auch den Zugriff mehrerer Personen auf multimediale Inhalte. Diese
können z. B. in Form von XML-basierten (wie z. B. XHTML, SVG,
SMIL) oder binärcodierten (proprietären) Dokumentenformaten
vorliegen (z. B. verschiedene Video-/Audioformate, Flash, Real).
Mehrbenutzer-Editoren werden unter anderem zur Erstellung multimedialer Inhalte verwendet. Vor allem in der Forschung existieren
Mehrbenutzer-Editoren, die gleichzeitiges Arbeiten mehrerer Personen auf einer Grafik, einem Textdokument oder einer Webseite erlauben. Auch wenn diese aktuell weniger als Groupware und Versionsverwaltungssysteme im produktiven Einsatz sind, so wird der
Stellenwert von Mehrbenutzer-Editoren, vor allem im MultimediaBereich, mit den immer schnelleren Datenleitungen und internationalen Projektteilnehmern zunehmen.
Das Gruppenbewusstsein (engl.: Group Awareness) ist ein weiterer
zentraler Punkt bei der Entwicklung von CSCW-Systemen. Da Anwender eines CSCW-Systems immer Teil einer Gruppe sind, erfordert
dies eine Änderung ihrer gewohnten Arbeitsweise. Die Anwender
müssen nun, im Gegensatz zu Ein-Benutzer-Systemen, auf Aktionen
der Gruppe zielgerichtet und zeitnah reagieren können. Diese speziellen Anforderungen eines CSCW-Systems in Bezug auf Usability und

3.2 CSCW in der Medieninformatik

Die Rolle der digitalen Medien in
CSCW-Systemen

Das Gruppenbewusstsein spielt eine
wichtige Rolle in CSCW-Systemen

■
■
■

147

Nichtfunktionale Anforderungen an
CSCW-Systeme

Softwareergonomie können nur durch einen Paradigmenwandel und
die Entwicklung spezieller Benutzerschnittstellen erfüllt werden.
Des Weiteren werden an CSCW-Systeme, da es sich meist um verteilte Anwendungen handelt, besondere nichtfunktionale Anforderungen gestellt, die sie von lokalen Anwendungen unterscheiden:
• Häufig sehr kurze Antwortzeiten (fast Echtzeit) über Weitverkehrsnetze wie z. B. das Internet
• Hohe Systemstabilität und hohe Fehlertoleranz bei Netzwerkproblemen und –verzögerungen
• Unterstützung heterogener Umgebungen
Die Forschung an und die Entwicklung von modernen CSCWSystemen erfordert aufgrund des intensiven Einsatzes, der Verwaltung
und der Bearbeitung von multimedialen Inhalten ein gutes Verständnis dieser Systeme und ist wie auch die Entwicklung verteilter Systeme
und die Forschung im Bereich Usability und Softwareergonomie ein
Aufgabengebiet der Medieninformatik.

3.3
Groupware- und
Workgroup-Computing-Systeme
3.3.1
Zielsetzung der Groupware-Systeme
Kommunikation und Koordination
sind zentrale Aufgaben

Der Begriff Groupware ist ein aus den Begriffen Group (Gruppe) und
Software zusammengesetztes Kunstwort. Workgroup Computing wird
hier als Synonym zur Groupware betrachtet. Groupware-Systeme
dienen, im Gegensatz zu „Ein-Benutzer-Systemen“, unter anderem
zur Kommunikation zwischen Personen und von Sachverhalten. Auch
spielt die Koordination von Aufgaben und Prozessen eine Rolle. Obwohl traditionelle Technologien wie das Telefon sich auch als Groupware qualifizieren lassen, bezieht sich der Begriff Groupware auf eine
spezielle Klasse von Technologien. Gemeint sind meist Technologien,
die auf Computernetzwerken basieren, wie zum Beispiel E-Mail,
Newsgroups, Videotelefonie oder Chat.
Wir definieren Groupware- Systeme wie folgt:
Der Begriff Groupware bezeichnet ein aus Software und eventuell spezifischer Hardware bestehendes System, das die Zusammenarbeit im
Team durch die Schaffung von Kommunikations- und/oder Koordinationslösungen unterstützt oder ermöglicht.

148

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Groupware-Systeme bieten entscheidende Vorteile gegenüber „EinBenutzer-Systemen“. Unter anderem wird Groupware aus folgenden
Gründen eingesetzt:
• Zur Verbesserung der Kommunikation innerhalb einer Gruppe. Es
soll schneller, klarer und überzeugender kommuniziert werden
können.
• Um Kommunikation auch dort zu ermöglichen, wo es sonst nicht
möglich wäre.
• Um Telearbeit zu ermöglichen (bei geografisch entfernten Benutzern).
• Zur Einsparung von Reisekosten.
• Zur Bündelung von Fachwissen und dem Gedankenaustausch in
der Gruppe.
• Um Gruppen mit gemeinschaftlichem Interesse zu bilden.
• Zur Zeit- und Kostenreduktion bei der Koordination von Gruppenarbeit.
• Zur Problemlösung in der Gruppe.
• Zur Erlangung neuer Kommunikationsmöglichkeiten, wie zum
Beispiel dem anonymen oder strukturierten Informationsaustausch.

Groupware- Systeme bieten viele
Vorteile gegenüber Ein-BenutzerAnwendungen

Die Entwicklung erfolgreicher Groupware-Systeme ist dagegen
schwieriger als die Entwicklung herkömmlicher Ein-BenutzerSysteme. Das liegt nicht nur an den erschwerten technischen Voraussetzungen. Groupware „lebt“ von der Gruppe. Daher ist die volle Akzeptanz der Groupware durch die Zielgruppe entscheidend für den
Erfolg einer Groupware.

3.3.2
Werkzeuge und Anwendungen
Groupware-Systeme werden oft mit Hilfe einer Raum-Zeit-Matrix
klassifiziert, wie sie in der Tabelle 3.1 dargestellt ist.
Die erste Achse teilt die Systeme in synchrone und asynchrone Systeme ein. Asynchrone Systeme, wie z. B. E-Mail, Weblogs oder elektronische schwarze Bretter, erlauben dabei den Zugriff verschiedener
Personen auf die Daten zu unterschiedlichen Zeiten. Synchrone Systeme dagegen ermöglichen die gleichzeitige Zusammenarbeit mehrerer Personen an einer Aufgabe. Die zweite Achse teilt die Systeme
nach dem Ort der gemeinschaftlichen Arbeit ein. Dabei gibt es Systeme, die Gemeinschaftsarbeit am selben Ort unterstützen (Angesicht
zu Angesicht) und Systeme zur Unterstützung der Arbeit von örtlich

3.3 Groupware- und Workgroup-Computing-Systeme

■
■
■

149

Tabelle 3.1:
Raum-Zeit-Matrix der GroupwareSysteme

verteilten Personen. In diesem Kapitel werden nur Systeme, welche
kollaboratives Arbeiten an verschiedenen Orten unterstützen, betrachtet. Im Folgenden werden die wichtigsten Typen von GroupwareSystemen beschrieben.
3.3.2.1
Asynchrone Groupware
Es gibt synchrone, asynchrone und
multisynchrone Systeme

E-Mail: eines der bedeutendsten
Groupware-Systeme

150

■
■
■

Im Folgenden werden verschiedene Beispiele für asynchrone Groupware vorgestellt. Dabei handelt es sich um Systeme, die keine Echtzeitanforderungen erfüllen müssen. Das heißt, der Zugriff der Gruppenmitglieder auf Daten und Informationen findet nacheinander bzw.
zeitversetzt statt.
E-Mail
E-Mail ist wohl eine der bekanntesten und meistgenutzten GroupwareAnwendungen. Grundsätzlich dient E-Mail zur Übertragung von einfachen Textnachrichten zwischen zwei Benutzern. Schon einfache EMail-Systeme erlauben heutzutage das Weiterleiten, Abspeichern und
Sortieren von Nachrichten sowie das Einrichten von Mailgruppen und
das Anhängen von Dateien an Nachrichten. Auch das automatische
Filtern und das Routen von Nachrichten gehört mittlerweile zum Standard der meisten E-Mail-Systeme. Dabei können E-Mails anhand verschiedener Kriterien automatisch aussortiert, in andere E-Mail-Ordner
einsortiert oder an andere E-Mail-Adressen weitergeleitet werden.
Manche Systeme erlauben auch das Strukturieren und Anreichern von

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Metadaten zu Nachrichten. Weit verbreitete E-Mail-Systeme sind zum
2
3
4
Beispiel Microsoft Exchange , Lotus Notes und Postfix .
Für E-Mail existieren verschiedenste Client-Anwendungen, auch
Mail User Agents genannt, mit denen E-Mails versendet und empfangen werden können. Diese bieten unterschiedlichste Zusatzfunktionen
(z. B. SPAM-Filter, Suchen, Sortierung) und unterstützen verschiedene
Protokolle (z. B. POP3, IMAP, SMTP) für den E-Mail-Transport. Zu
den bekanntesten Clients zählen unter anderem Microsoft Outlook
und Thunderbird. Gesendet werden E-Mails, indem der E-Mail-Client
eine Verbindung zu einem SMTP (Simple Mail Transfer Protocol) Server (SMTP-Relay-Server oder Smarthost) aufbaut und die zu sendende Nachricht an diesen überträgt. Dieser leitet sie dann an den
Empfänger weiter. Um E-Mails abzurufen, verbindet sich der Client
mit einem Mail-Server über das Post-Office-Protokoll 3 (POP3 oder
POP3S für eine sichere Verbindung). Alternativ kann ein Client sich
über das Internet Message Access Protocol (IMAP oder IMAPS für
eine sichere Verbindung) mit einem Mail-Server verbinden. Bei IMAP
müssen (im Gegensatz zu POP3) E-Mails nicht vom Server heruntergeladen und somit dort gelöscht werden, um sie lesen zu können,
sondern verbleiben auf dem Server. Neben den E-Mail-Anwendungen,
die auf der Zielplattform (z. B. Heim-PC) installiert werden müssen,
sind sogenannte Webmail-Clients sehr beliebt. Diese erlauben den
Zugriff auf E-Mails über einen Web-Browser. Verschiedene Dienstleister haben sich darauf spezialisiert, solche „Webmailer“ und den dazugehörigen E-Mail-Dienst anzubieten. Weiterführende Literatur zum
Thema E-Mail finden sie unter [8,9,10].
Newsgroups und Mailinglisten
Diese Systeme dienen, im Gegensatz zu E-Mail, dem Nachrichtenaustausch in einer größeren Gruppe. Ansonsten sind sie dem E-MailSystem aber sehr ähnlich. Der Hauptunterschied zwischen Newsgroups und Mailinglisten besteht darin, dass Newsgroups nur Nachrichten anzeigen, wenn ein Benutzer diese auch direkt anfordert. Bei
Mailinglisten werden Nachrichten an alle Benutzer, welche die Liste
abonniert haben, sofort weitergeleitet.

E-Mail-Protokolle

Workflow-Management Systeme
Aufgabe des Workflow-Managements ist es, eine Spezifikation für die
technische Ausführung von Arbeitsabläufen zu liefern. Das Workflow2
3

4

http://www.microsoft.com.
Der Lotus Domino Server dient dabei unter anderem als IMAP/POP3/SMTP
Server. http://www-306.ibm.com/software/de/lotus/.
http://www.postfix.org/.

3.3 Groupware- und Workgroup-Computing-Systeme

■
■
■

151

Groupware zur Steuerung von
Arbeitsabläufen

Wikis und Blogs sind sehr populär

Management kann damit als eine technische Umsetzung des Geschäftsprozess-Managements verstanden werden. Ein WorkflowManagement-System (WfMS) dient der aktiven Steuerung arbeitsteiliger Prozesse. Eine Workflow-Management-Anwendung ist eine implementierte Lösung zur Steuerung von Arbeitsabläufen (engl.: Workflows) auf der Basis eines Workflow-Management-Systems.
Workflow-Systeme werden häufig der Groupware zugeordnet, da
sie die Arbeit unterschiedlicher Personen innerhalb einer Organisation regeln. In diese Kategorie fallen auch sogenannte AnforderungsManagement- (engl.: Requirements-Management-) und ÄnderungsManagement-Systeme (engl.: Change-Management-Systems). Diese
unterstützen die Kollaboration und Kommunikation bei der Erfassung von Anforderungen eines Systems. Hierbei soll eine strukturierte
Vorgehensweise (durch Workflow-Management) bei der Anforderungserfassung und eine Verwaltung der erfassten Daten die Arbeit
erleichtern. Ein Beispiel für ein führendes Anforderungs-Management-System ist DOORS der Firma Telelogic. Beispiele für kommerzielle WfMS bzw. Änderungs-Management-Systeme sind IBM Ratio5
nal ClearCase und ClearQuest MultiSite .
Weiterführende Literatur zum Thema Workflow-Management finden sie unter [11].
Hypertext-basierte Systeme
Mit der Entwicklung des Hypertext-Transfer-Protokolls (HTTP) und
den ersten Web-Browsern wurde die Grundlage für eines der meistgenutzten Groupware-Systeme geschaffen: Das World Wide Web
(WWW) ist im Prinzip ein Groupware-System, da viele Personen darüber Informationen computergestützt austauschen.
Heutzutage existieren viele Groupware-Systeme, die sich die Hypertext-Technologie zu Nutze machen. Die schon erwähnten webbasierten E-Mail-Clients gehören noch zu den einfachen. Hypertextbasierte Systeme nutzen das Internet bzw. Intranet und das Hypertext-Transfer-Protokoll, um Zugang zu ihren Diensten über einen
Web-Browser zu ermöglichen. Prinzipiell kann fast jede asynchrone
Groupware-Lösung auch mit einer Web-Schnittstelle ausgestattet
werden.
Viele Systeme besitzen neben webbasierten Clients (auch ThinClients genannt) herkömmliche Clients, da nicht alle Funktionalitäten
über einen Web-Client abgebildet werden können. Hingegen gibt es
einige Groupware-Systeme, die nur Web-Clients einsetzen. Dazu gehören neben den sogenannten Blogs oder Weblogs auch die WikiSysteme (wie z. B. das MediaWiki) und viele weitere. Damit ist es mög5

152

■
■
■

http://www-306.ibm.com/software/awdtools/clearcase/multisite.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

lich, auf relativ einfache Weise Informationen einer großen Zahl an
Personen (bestenfalls allen Internetnutzern) zur Verfügung zu stellen.
Interessierte Benutzer müssen diese Informationen entweder aktiv
abrufen, indem sie die entsprechende Webseite aufrufen, oder sogenannte RSS (Really Simple Syndication) Feeds für Blogs und andere
Inhalte (z. B. Podcast Hypermedia) abonnieren. Die auf diese Weise
abonnierten Inhalte werden automatisch zugestellt.
Zusätzlich wurden Erweiterungen des Hypertext-Transfer-Protokolls entwickelt, die das Aufspielen und Ändern von HypertextInhalten auf einen Web-Server erleichtern. Dazu gehört das sogenannte WebDAV (Web-based Distributed Authoring and Versioning).
Gegenüber der Verbindung mit FTP (File Transfer Protocol) oder
anderen Protokollen hat WebDAV verschiedene Vorteile. Es ist unter
anderem leichter bedienbar, denn es wird von den gängigen Betriebssystemen standardmäßig unterstützt. Die Verwendung von WebDAV
bereitet auch hinter Firewalls weniger Schwierigkeiten als z. B. FTP, da
die Standard-HTTP-Ports genutzt werden.
Ein Beispiel für ein kommerzielles webbasiertes asynchrones
Groupware-System, welches unter anderem WebDAV einsetzt, ist der
6
Microsoft SharePoint Portal Server . Dieses System dient zur Verwaltung und zum Bearbeiten von Dokumenten in einer Gruppe.
Hypertext-Systeme, die nicht nur textuelle, sondern auch multimediale Inhalte verwalten, werden oft Hypermedia-Systeme genannt.
Hierzu zählen Groupware-Systeme, die webbasiert arbeiten, aber neben Text auch Audio- und/oder Videostreams einsetzen. Oft handelt
es sich dabei um Online-Konferenzsysteme oder Systeme für kooperatives Lernen. Computer-Supported-Cooperative-Learning- (CSCL-)
Systeme arbeiten oft webbasiert, da der Zugang einer breiten Personengruppe möglich sein soll und die Installation einer speziellen
Software nicht immer erwünscht ist.
Mit Hilfe der sogenannten Web 2.0-Technologien wie Ajax (Asynchronous Javascript and XML) und den Web-Service-APIs wird es möglich, auch „quasi synchrone“ kollaborative webbasierte Anwendungen
zu realisieren. Dabei informieren sich die webbasierten Clients durch
regelmäßige Anfragen beim Server (Polling) über Änderungen an den
gemeinsamen Daten. Solche kollaborativen Web 2.0 Dienste erlauben
das gemeinsame Bearbeiten von Dokumenten im Team über einen
Web-Browser, ähnlich der Wikis, nur interaktiver und zeitnah. Beispiel
7
für webbasierte Mehrbenutzer-Editoren sind Zoho Writer und Write8
ly . Web 2.0-basierte Dienste zeichnen sich durch eine Benutzerinter6
7
8

Web 2.0-Dienste verbessern die Usability
einer webbasierten Anwendung

http://www.microsoft.com/office/sharepoint/prodinfo/default.mspx.
http://www.zohowriter.com.
http://www.writely.com.

3.3 Groupware- und Workgroup-Computing-Systeme

■
■
■

153

aktivität aus, die herkömmlichen Stand-alone-Anwendungen sehr
nahe kommt. Sie vereinen damit die Vorteile der Plattformunabhängigkeit mit größtmöglicher Benutzerfreundlichkeit und Funktionalität.
Die Entwicklung von effizienten Hypermedia-Protokollen und neuen Anwendungen ist ein Forschungsgebiet, das mit der ständig wachsenden Bandbreite der Datenleitungen stark zugenommen hat. Verschiedene Forschungsgruppen versuchen hier neue Standards im
9
Bereich Hypermedia zu etablieren. Ein Beispiel dafür ist Annodex , ein
offener Standard für die Annotierung und Indexierung von Multimedia-Inhalten im Internet. Ziel dabei ist es, das sogenannte Continuous
Media Web (CMWeb) zu entwickeln: eine extrem mehrbenutzerfähige
verteilte Hypermedia-Umgebung für das World Wide Web der übernächsten Generation.

Gruppenkalender wollen gepflegt
werden

Gruppenkalender
Gruppenkalender erlauben die Terminplanung und die Koordination
von vielen Personen innerhalb einer Organisation. Oft unterstützen
solche Systeme auch die Synchronisation von Terminen mit mobilen
Endgeräten. Sie können automatisch Terminkonflikte erkennen und
Termine finden, an denen jeder Teilnehmer einer Gruppe Zeit hat.
Gruppenkalender sind oft integrierte Bestandteile anderer Group10
ware-Systeme wie z. B. Microsoft Outlook . Gruppenkalender leiden
oft unter fehlender Datenpflege, da nicht immer alle Benutzer ein
Interesse an der Eingabe ihrer Daten haben. Daher sollten solche Systeme besonderen Wert auf die Privatsphäre von Benutzern legen und
den Zugriff auf Informationen stark durch die Benutzer kontrollierbar
machen. Jeder Benutzer sollte selbst bestimmen können, wem welche
Informationen über ihn zugänglich sind.
3.3.2.2
Synchrone Groupware
Bei Groupware-Systemen, die den gleichzeitigen Zugriff der Gruppenmitglieder auf Daten und Informationen ermöglichen, handelt es
sich um synchrone Groupware. Im Folgenden werden einige Beispiele
dafür vorgestellt.
Elektronische Tafel
Elektronische Tafeln (engl.: Electronic Whiteboard) erlauben es mehreren Personen, zur selben Zeit und von unterschiedlichen Orten aus
auf eine für alle sichtbare Fläche zu zeichnen.
9
10

154

■
■
■

http://www.annodex.net/.
http://office.microsoft.com/de-de/FX010857931031.aspx.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Elektronische Tafeln können zum Beispiel dazu verwendet werden,
ein visuelles Problem zu besprechen oder während eines Telefonats
Notizen zu machen, die dann von jeder Person kommentiert werden
können. Die meisten dieser Systeme dienen informellen Zwecken,
können aber auch für anspruchsvollere Aufgaben eingesetzt werden.
Im Gegensatz zu grafischen Mehrbenutzer-Editoren besitzen sie allerdings meist keine Synchronisationsmöglichkeit und garantieren keine
Datenkonsistenz. Einfache Systeme arbeiten sogar asynchron und
erlauben zu einem Zeitpunkt nur einer Person den Zugriff auf die
Zeichenfläche, während die anderen Personen die gemachten Änderungen nur betrachten können. Erst nach Freigabe der Zeichenfläche
durch den Benutzer, kann dann der nächste Teilnehmer den „Zeichenstift“ ergreifen.
Elektronische Tafeln sind häufig integraler Bestandteil anderer
Groupware-Anwendungen wie Audio- und/oder Videokonferenzsysteme oder Chats.
Application Sharing Systeme
Application-Sharing-Systeme werden auch Systeme zur Anwendungsaufteilung genannt. Dabei handelt es sich um eine Software, die es
ermöglicht, eine Anwendung oder eine Betriebssystemoberfläche mit
mehreren Benutzern zu teilen. Application-Sharing-Systeme sind
Client-Server-basiert. Der PC oder die Workstation, deren Anwendungen anderen zugänglich gemacht werden sollen (das HostSystem), betreibt den Server des Application-Sharing-Systems. Die
Application-Sharing-Clients verbinden sich mit dem Host und übermitteln an diesen Informationen wie Mausbewegungen und Tastendrücke. Diese werden dann vom Host-System direkt ausgeführt, als ob
sie vom lokalen Benutzer stammen würden. Der Application-SharingServer übermittelt die grafische Darstellung der Anwendungen des
Host-Systems an die Clients. Das Application Sharing funktioniert
dabei ähnlich einer elektronischen Tafel, nur dass dabei das Abbild
einer Anwendung (ähnlich einem Screenshot) übertragen wird anstatt
der Zeichenfläche. Ein Beispiel für ein System, welches sowohl eine
elektronische Tafel als auch Videokonferenz, Chat und Application11
Sharing unterstützt, ist Microsoft Netmeeting® .
Application-Sharing-Systeme sind anwendungsunabhängig und
kollaborationstransparent (engl. collaboration transparent). Das heißt,
es können damit im Prinzip alle Arten von Anwendungen gemeinsam
genutzt werden und die geteilte Anwendung bekommt davon nichts
mit. Solche Systeme unterstützen striktes WYSIWIS (What You See Is
What I See) und eignen sich damit besonders für die sehr enge
11

Elektronische Tafeln helfen bei der
Visualisierung in Teambesprechungen

Enge Zusammenarbeit wird trotz
räumlicher Trennung durch
Application Sharing möglich

http://www.microsoft.com/windows/netmeeting/.

3.3 Groupware- und Workgroup-Computing-Systeme

■
■
■

155

Zusammenarbeit räumlich getrennter Benutzer. Application-SharingSysteme werden sinnvollerweise durch eine direkte Kommunikation
aller Teilnehmer ergänzt, z. B. durch eine Telefonkonferenz, um die
Aktionen der Teilnehmer zu koordinieren. Beispiele für Application12
13
Sharing-Systeme sind VNC oder NetViewer .

Videokonferenzsysteme sind
mittlerweile Standard in vielen
größeren Unternehmen

Videokonferenzsysteme
Bei den Videokonferenzsystemen gibt es verschiedenste Ausführungen in Soft- und Hardware. Neben den Desktop-Systemen, die auf
herkömmlichen PCs laufen, existieren Settop-Boxen, Raumsysteme
und mobile Systeme, die zum Beispiel Videokonferenzen über UMTS
ermöglichen. Die meisten Videokonferenzsysteme basieren auf einer
zentralistischen Architektur, bei dem sich die Teilnehmer an einem
zentralen Server anmelden, um an der Konferenz teilzunehmen. Diese
zentralen Instanzen werden Gatekeeper genannt und sind unter anderem für den Verbindungsaufbau zwischen den Endgeräten und der
Multipoint Control Unit (MCU) zuständig.
MCUs sind Sternverteiler – auch als Reflector bezeichnet – für
Gruppenkonferenzen. Sie sind immer dann notwendig, wenn mehr als
zwei Teilnehmer an einer Konferenz teilnehmen wollen. Ein Gateway
verbindet unterschiedliche Netze miteinander und konvertiert Protokolle ineinander oder koppelt Netzwerke. Bei gemeinsamer Nutzung
von ISDN- und TCP/IP-Endgeräten ist der Einsatz eines Gateways
zwingend notwendig.
Peer-to-Peer- (P2P-) Videokonferenzsysteme stellen einen alternativen Ansatz zu den herkömmlichen zentralistischen Videokonferenzsystemen dar. Sie verzichten auf einen zentralen Gruppen- und Kommunikationsserver wie Gatekeeper und die MCU. Stattdessen wird die
gesamte Intelligenz in die Endsysteme, d. h. die PCs und Workstations,
verlagert. Es existieren verschiedene Protokolle für den Verbindungsaufbau und die Übertragung der Video- und Audiodaten. Die wichtigsten sind H.323 und das Session Initialisation Protocol (SIP).
Multimediale Konferenzsysteme
Neben Videokonferenzsystemen gibt es auch Systeme, die außer Video- und Audiodaten auch multimediale Inhalte in eine Konferenz
einfließen lassen. Diese werden unter anderem für Projektbesprechungen, Führungskräftemeetings, Kundenberatung und E-Learning
eingesetzt. Teilnehmer einer Gruppe können sich dabei netzbasiert in
einer virtuellen Umgebung treffen z. B. zum Koordinieren ihrer Aufgaben, Präsentieren von Lösungen und Diskutieren von Lösungsalter12
13

156

■
■
■

http://www.vnc.com/.
http://www.netviewer.de/.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

nativen. Ein Beispiel für ein solches multimediales Konferenzsystem
14
ist VITERO (Virtual Tea Room) .
Chat-Systeme
Chats sind ein äußerst beliebtes Mittel, sich im Internet zu treffen und
auszutauschen. Sie erlauben vielen Personen, Nachrichten in „Echtzeit“ zu schreiben und zu veröffentlichen. Sobald eine Person eine
Nachricht abschickt, erscheint diese sofort auf dem Bildschirm der
anderen Teilnehmer. Es gibt verschiedenste Ausprägungen von ChatSystemen. Meist sind dies Anwendungen, die auf einem Endgerät
installiert werden und sich mit einem zentralen Chat-Server verbinden. Es gibt aber auch Peer-to-Peer-Chat-Systeme, die keinen zentralen Server benötigen, und webbasierte Clients. Chat-Server verwalten
sogenannte Chat-Räume, die meist nach Diskussionsthemen eingeteilt
sind und entweder offen und für jedermann zugänglich oder privat
sind. Manche Chat-Räume besitzen einen Moderator, der die Diskussion leitet. Missbrauch verhindert dieser, indem er Benutzer aus dem
Chat-Raum verweist, die die Regeln nicht einhalten. Chat-Teilnehmer
wählen zur Identifizierung meist einen anonymen Spitznamen (engl.
Nickname).
15
Bekannteste PC-basierte Chat-Clients sind ICQ , AOL Instant Mes16
17
senger , Microsoft Messenger (MSN) , verschiedene IRC-Chat Clients
18
wie mIRC und verschiedene Jabber-Clients. Auch für mobile Endge19
räte existieren Chat-Clients wie zum Beispiel Mjabber und andere,
die das Chatten von überall und zu jederzeit ermöglichen.
Für Chat-Systeme existieren keine einheitlichen Standards. Es gibt
viele proprietäre nicht offen gelegte Protokolle und Systeme zum Datenaustausch (ICQ, AOL etc.). Offene Systeme sind unter anderem das
schon relativ alte Internet Relay-Chat- (IRC-) System, von dem es
viele Ausprägungen und Erweiterungen gibt. Ein neueres Protokoll
und Chat-Netzwerk ist zum Beispiel Jabber, das basierend auf XML
zusammen mit sogenannten „Transports“ die Kommunikation mit
den meisten der proprietären Chat-Systemen wie ICQ, AOL und
Microsoft unterstützt.
Neben dem Versenden von reinen Textnachrichten unterstützen
viele Chat-Systeme auch die Übertragung von Dateien und Audiound/oder Videostreams. Eine relativ neue Entwicklung sind die soge14
15
16
17
18
19

Chats dienen nicht nur der Unterhaltung

Chats für Mobiltelefone anstatt SMS

http://www.vitero.de/.
http://www.icq.com/.
http://www.aim.com/.
http://messenger.msn.com/Xp/Default.aspx.
http://www.mirc.com/.
http://www.mjabber.com/.

3.3 Groupware- und Workgroup-Computing-Systeme

■
■
■

157

nannten Voice-Over-IP- (VoIP-) Chat-Systeme wie z. B. Skype. Diese
erlauben die Gruppentelefonie über VoIP und zusätzlich das versenden von Textnachrichten und Dateien. Auch klassische Chat-Systeme
wie z. B. ICQ sind nachgezogen und bieten die Möglichkeit der Telefonkonferenz oder das sogenannte Push-to-Talk über das Internet.
Beim Push-to-Talk werden beim Drücken eines Tasters (Mausklick)
kurze Audiodateien aufgezeichnet und danach an mehrere Teilnehmer versendet. Die Push-to-Talk-Technologie ähnelt (in Bezug auf die
Bedienung) der Funkgerätetechnik und wird auch im Mobilfunk
(GPRS, UMTS) eingesetzt. Die VoIP-Chat-Systeme nutzen neben proprietären Protokollen auch klassische VoIP-Protokolle wie SIP (Session Initialisation Protocol) und H.323.
Systeme zur Entscheidungsfindung
Diese Systeme sollen Gruppen in der Entscheidungsfindung unterstützen und bieten dazu Werkzeuge für Brainstorming, Ideensammlung und Kritik, Pro- und Kontra-Abwägung und zum Wählen. Sie
sind oft integraler Bestandteil von Konferenzsystemen und dienen als
zusätzliche Unterstützung in Besprechungen, um zur aktiven Teilnahme zu ermutigen, anonyme Teilnahme zu ermöglichen oder die
Teilnahme durch „Aufrufen“ zu erzwingen.
Mehrbenutzer-Spiele
Verteilte Mehrbenutzer- bzw. Online-Spiele sind komplexe, kollaborative Systeme. Die ersten Online-Spiele waren nur textbasiert und ähnelten sehr stark Chats. Meist handelt es sich bei diesen „einfachen“ Spielen
20
um sogenannte Rollenspiele. Ein bekanntes Beispiel dafür ist Unitopia .
Mit der größeren Bandbreite und den schnelleren PC-Systemen wurden
die grafischen Fähigkeiten der Online-Spiele immer besser. Moderne
Mehrbenutzer-Spiele bieten sehr realitätsnahe „Echtzeit“ 3D Umgebungen und werden durch andere Kommunikationsmittel wie Text-,
Audio- oder sogar Video-Chat erweitert. Bei Echtzeit-MehrbenutzerSpielen (engl.: multi-player games) ist eine sehr zeitnahe Interaktion
notwendig, um das „Überleben“ der Spielfigur zu gewährleisten. Daher
haben diese Mehrbenutzer-Spiele sehr hohe Echtzeitanforderungen. Im
Gegensatz zu z. B. Mehrbenutzer-Editoren, spielt die Datensynchronität
bei Mehrbenutzer-Spielen oft eine untergeordnete Rolle. Gehen ein paar
wenige Informationen verloren, so fällt dies oft nicht ins Gewicht. Wird
z. B. eine abgeschossene Kugel von hunderten in einem Feuergefecht
nicht an alle Teilnehmer übertragen, spielt das meist keine große Rolle.
Wichtiger ist dabei die „grobkörnige“ Information wie z. B. „Spielfigur
ist im Gefecht gefallen“ oder „Spielfigur hat 20 Lebenspunkte verloren“.
20

158

■
■
■

http://unitopia.uni-stuttgart.de/.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Die Verbreitung und Vermarktung von Online-Mehrbenutzer-Spielen
nimmt stark zu und der Online-Spielmarkt ist zurzeit einer der am
stärksten wachsenden Bereiche der Softwarebranche.
Kollaborative Betriebssysteme
21
Das Croquet-Projekt ist ein Beispiel für eine neuartige kollaborative
Betriebssystemarchitektur, die mit Hilfe einer neuartigen Benutzeroberfläche und Netzwerkarchitektur ein intensives Zusammenarbeiten aller Benutzer des Systems ermöglichen soll. Croquet ist noch
Gegenstand der Forschung, bietet aber sehr interessante Ansätze und
einen Ausblick auf die Zukunft des kollaborativen Arbeitens.

3.4
Versionsverwaltungssysteme
3.4.1
Zielsetzung der Versionsverwaltungssysteme
Größere Softwareprojekte, aber auch das Erstellen umfangreicher
Dokumente wie zum Beispiel Bücher, Kataloge und Handbücher erfordern die erfolgreiche Zusammenarbeit mehrerer Personen. Dabei
stellt sich automatisch die Frage nach der Verwaltung der sich in der
Erstellung befindlichen Artefakte und der Kontrolle des Zugriffs auf
diese. Unkontrollierter gleichzeitiger Zugriff auf die Artefakte kann
Dateninkonsistenz zur Folge haben. Gerade bei Softwareprojekten, bei
denen verschiedene Quellcodedateien von mehreren Personen gleichzeitig bearbeitet werden sollen, ist die Erhaltung der Quellcodekonsistenz essenziell, da ein Projekt ansonsten eventuell nicht mehr übersetzt werden kann.
Häufig werden Verfahren wie Turn-Taking, Split-Combine oder
Copy-Merge zur Kontrolle der Zugriffe eingesetzt. Diese haben den
Vorteil, dass sie keine Softwareinstallation erfordern, aber auch
Nachteile in Bezug auf den Zeitaufwand und die Nachvollziehbarkeit
von Änderungen (siehe Kap. 3.6.1).
Versionsverwaltungssysteme haben die Aufgabe, die Teamarbeit zu
unterstützen und die Konsistenz der Artefakte zu wahren. Zusätzlich
sollen sie die Nachvollziehbarkeit von Änderungen zu jedem Zeitpunkt durch die Versionierung der zu verwaltenden Artefakte gewährleisten. Versionsverwaltungssysteme werden daher gerade im
Bereich der Softwareentwicklung häufig eingesetzt. Sie sind aber prinzipiell nicht auf diesen Bereich beschränkt. Neben der Versionsver21

Versionsverwaltung ist nicht nur in der
Softwareentwicklung wichtig

http://www.opencroquet.org/.

3.4 Versionsverwaltungssysteme

■
■
■

159

waltung können diese Systeme auch für die Konfigurationsverwaltung
eingesetzt werden. Dabei werden verschiedene Versionen von Artefakten zu einer Konfiguration zusammengestellt.
Beispiele für bekannte kommerzielle Versionsverwaltungssysteme
22
sind Microsoft Visual Sourcesafe (VSS), Synergy/CM (ehem. Conti23
24
nuus/CM) und Perforce . Die bekanntesten kostenlosen Systeme
25
sind das Concurrent Versioning System (CVS) oder dessen Nachfol26
gesystem Subversion (SVN). All diese Systeme können im Prinzip für
die Versionierung jedes Datentyps eingesetzt werden. Bei der Verwaltung der Versionen der verschiedenen Datentypen bestehen allerdings
Unterschiede. Je nach Datentyp werden entweder nur die Änderungen
zwischen den Versionen oder das komplette Artefakt in der neuen
Version abgespeichert. Letzteres trifft z. B. bei Visual Sourcesafe oder
Perforce auf Binärdateien zu. Subversion hingegen speichert auch bei
Binärdateien nur die Unterschiede zwischen den Versionen ab und
spart somit Speicherplatz.
Ein Versionsverwaltungssystem zeichnet jede Änderung an einem
von ihm verwalteten Artefakt auf. Die Artefakte werden dabei üblicherweise in einem zentralen Datenspeicher (Projektarchiv) gehalten.
Der Zugriff darauf wird vom System verwaltet und geschieht durch
einen sogenannten Check-In/Check-Out-Mechanismus. Jedes Teammitglied arbeitet dabei auf lokalen Kopien der Artefakte. Diese müssen
zunächst vom Teammitglied durch ein Check-Out (Ausprüfung) als
„in Bearbeitung“ markiert werden. Dabei werden die lokalen Kopien
angelegt. Nun können Änderungen an den Artefakten vorgenommen
werden. Nach Abschluss der Änderungen werden die Artefakte wieder
durch ein Check-In in das System übertragen, wodurch eine neue Artefakt-Version entsteht. Beim Check-In ist dabei oft das Kommentieren von Änderungen obligatorisch, um später einfacher Änderungen
nachvollziehen zu können. Das System prüft bei jedem Check-In, ob
die Änderungen überhaupt zurückspielbar sind oder unlösbare Konflikte mit zwischenzeitlich von anderen Teammitgliedern vorgenommenen Änderungen bestehen.
Versionsverwaltungssysteme arbeiten dabei mit Sperrverfahren
(engl.: locking), um Konflikte zu erkennen und Inkonsistenzen zu vermeiden. Hierbei werden hauptsächlich zwei Verfahren eingesetzt: das
pessimistische und das optimistische Sperrverfahren (siehe Kap. 3.6).

22
23
24
25
26

160

■
■
■

http://msdn.microsoft.com/vstudio/previous/ssafe/.
http://www.telelogic.com/.
http://www.perforce.com/.
http://www.nongnu.org/cvs/.
http://subversion.tigris.org/.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

3.4.2
Anforderungen an Versionsverwaltungssysteme
Neben der reinen Versionsverwaltung und der Konsistenzerhaltung
durch Sperrverfahren gibt es weitere Anforderungen an ein Versionsverwaltungssystem.
Ein wichtiger Aspekt beim Bearbeiten von Artefakten ist die Gruppierung zugehöriger Änderungen in sogenannte Change-Sets. Dies
ermöglicht das einfache Erkennen eines Änderungskontexts. Die Evolution eines Projekts geht dabei nicht nur aus den Änderungen der
einzelnen Artefakte hervor, sondern es bleiben durch die Definition
eines Change-Sets auch die Zusammenhänge der einzelnen Änderungen erhalten.
Beim Check-In von Änderungen sollten Systeme transaktionsorientiert arbeiten. Werden z. B. mehrere Dateien gleichzeitig eingecheckt, kann es dazu kommen, dass einige Änderungen konfliktfrei
sind, andere aber hingegen konfliktbehaftet. Lässt ein System dabei
das Check-In der konfliktfreien zu und ignoriert die konfliktbehafteten Änderungen, so kann dies zu Problemen führen, wenn zwischen
den gleichzeitig eingecheckten Artefakten Zusammenhänge bestehen.
Daher bieten einige Versionsverwaltungssysteme sogenannte atomare
Check-Ins: Eine Menge von Änderungen werden entweder vollständig
oder gar nicht ausgeführt. Der Projektteilnehmer hat somit Versionskonflikte aufzulösen, bevor das Versionsverwaltungssystem seine
Änderungen akzeptiert.
Die Rechtevergabe sollte bei Versionsverwaltungssystemen möglichst feinkörnig sein, um den Zugriff nicht nur für Verzeichnisse,
sondern auch für Dateien regeln zu können. Dies macht vor allem
dann Sinn, wenn Projektteilnehmer ihre Änderungen nicht direkt
„einchecken“ können sollen, sondern erst nachdem mehrere andere
Personen zugestimmt haben (Qualitätskontolle, Review).
Eine Versionsverwaltung sollte auch das Verzweigen von Projektversionen erlauben (engl.: Branching). Dies ermöglicht z. B. in Softwareprojekten das Arbeiten an Patches für eine Version unabhängig
von den Arbeiten an der Nachfolgeversion. Solche einmal verzweigten
Projektversionen sollten danach auch wieder zusammengeführt werden können (engl.: Merging). Zusätzlich sollte das Verwenden eines
Artefakts in mehreren Projekten möglich sein (engl.: Sharing).
Eine recht hilfreiche Funktion ist es, Metadaten wie Kommentartexte frei vergeben zu können, um damit bestimmte Versionen von
Artefakten leichter wiederfinden zu können (engl.: Tagging).

3.4 Versionsverwaltungssysteme

Versionsverwaltungssysteme können
mehr

■
■
■

161

3.4.3
Architektur von Versionsverwaltungssystemen
Versionsverwaltungssysteme sind meist klassische Client-Server Systeme. Es gibt einen zentralen Server, der den Datenspeicher verwaltet,
und mehrere Clients, die über verschiedenste Protokolle mit dem
Server kommunizieren.
Eine Ausnahme bildet hier Microsoft Visual Sourcesafe (VSS).
Sourcesafe besitzt keine echte Client-Server-Architektur. Der Datenspeicher (Projektarchiv) ist nur eine Freigabe im Netzwerk, welche
eine Sourcesafe-Datenbank in einem proprietären Format enthält. Die
Clients greifen also auf den Datenspeicher über Filesharing zu. Dies
setzt das SMB-Protokoll (Server Message Block) voraus. Damit müssen sich VSS-Clients zumindest im selben virtuellen Netzwerk befinden und können nicht direkt über TCP/IP auf den Datenspeicher
zugreifen. Auch laufen die VSS-Clients nur unter Windows.
Andere Systeme unterstützen eine heterogene Umgebung, laufen
auf verschiedensten Plattformen und erlauben den Zugriff auf den
Datenspeicher entweder direkt über TCP/IP oder andere höhere Protokolle. Subversion z. B. erlaubt den Zugriff zusätzlich über die HTTPProtokollerweiterung WebDAV (Web-based Distributed Authoring
and Versioning)
Die Clients der Versionsverwaltungssysteme gibt es in unterschiedlichsten Ausführungen und von unterschiedlichsten Herstellern. Es
existieren kommandozeilenbasierte und grafische Clients. Viele
27
Clients sind als Plug-In zu Entwicklungsumgebungen (z. B. Subclipse )
erhältlich. Eine von Microsoft entwickelte API (Application Programmers Interface) namens SCC-API (Source Code Control) ermöglicht
die einfache Entwicklung und Integration von Clients in bestehende
Entwicklungsumgebungen.

3.5
Kollaborative Mehrbenutzer-Editoren
3.5.1
Zielsetzung der Mehrbenutzer-Editoren
Mehrbenutzer-Editoren kommen in
verschiedensten Bereichen zum Einsatz

Kollaborative Mehrbenutzer-Editoren existieren für verschiedenste
Dokumentenformate. Ähnlich wie die Versionsverwaltungssysteme
sind viele der Editoren aus dem Bereich der Softwareentwicklung und
zum Zweck der gemeinsamen Bearbeitung von Quellcode entstanden.
27

162

■
■
■

http://subclipse.tigris.org/.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Mittlerweile gibt es Mehrbenutzer-Editoren für einfache Quellcode
und Textdokumente, Grafiken, Hypertextdokumente und weitere. Das
Ziel beim Einsatz von Mehrbenutzer-Editoren ist es, die Produktivität
durch gemeinsames Arbeiten mehrerer Personen an einem Dokument
zu steigern. Die meisten der existierenden Mehrbenutzer-Editoren
unterstützen jeweils nur ein bestimmtes proprietäres Dokumentenformat und die Einsatzgebiete sind daher meist recht spezialisiert.
Mehrbenutzer-Editoren können synchron, asynchron oder multisynchron sein. Asynchrone Mehrbenutzer-Editoren (z. B. CES [12],
28
DistEdit [13], Lotus Notes ) erlauben mehreren Personen, nacheinander an einem Dokument zu arbeiten. Das komplette Dokument
oder Teile davon werden z. B. mit Hilfe eines pessimistischen oder
optimistischen Sperrverfahrens (siehe Abschn. 3.6.) konsistent gehalten. Sie sind praktisch Editoren mit integrierter Versionsverwaltung
und unterstützen die Gruppenarbeit zusätzlich z. B. durch eine gemeinsame Dokumentenablage, ein gemeinsames Objektrepository,
verschiedene Awareness-Mechanismen (z. B. um zu sehen, wer gerade
woran arbeitet) und zusätzliche Kommunikationsunterstützung
durch z. B. Chats oder Videotelefonie. Diese Editoren erlauben es also
Benutzern, am selben Dokument zu arbeiten, aber typischerweise in
verschiedenen Abschnitten und zu verschiedenen Zeiten. Asynchrone
Mehrbenutzer-Editoren basieren entweder auf einer zentralistischen
oder einer replizierten Architektur (siehe Kap. 3.7.).
Multisynchrone Mehrbenutzer-Editoren erlauben das Umschalten
zwischen asynchroner und synchroner Arbeitsweise. Diese Umschaltung geschieht entweder automatisch oder manuell (z. B. SAMS [1]).
Beim gemeinsamen Arbeiten an einem Dokument ist es oft nicht erwünscht, dass andere sofort alle Änderungen eines Benutzers mitbekommen (asynchron). Diese sollen erst zu einem vom Benutzer bestimmten Zeitpunkt allen zur Verfügung stehen. Zu einem anderen
Zeitpunkt aber arbeiten mehrere Personen gleichzeitig (synchron) am
selben Bereich innerhalb eines Dokumentes (z. B. um die vorher gemachten Änderungen zu besprechen), und es ist erforderlich, dass sie
die jeweiligen Änderungen sofort sehen können. In diesem Fall ist
eine Umschaltung zwischen synchroner und asynchroner Arbeitsweise sinnvoll.
Synchron arbeitende Editoren werden auch als „Echtzeit“ (engl.
„real-time“) -Editoren bezeichnet. Das Forschungsgebiet des „RealTime Collaborative Editing“ (RTCE) ist ein Teilgebiet des CSCW und
untersucht Computersysteme zum gleichzeitigen und effektiven Bearbeiten eines Dokuments durch mehrere Personen in „Echtzeit“. Dazu
zählen Systeme wie REDUCE [14], CoWord oder CoPowerPoint [15].
28

http://www.lotus.de/.

3.5 Kollaborative Mehrbenutzer-Editoren

■
■
■

163

Bei der Entwicklung von Echtzeit-Editoren müssen verschiedene
Probleme überwunden werden, die mit den Anforderungen dieser
Systeme zusammenhängen. Die Lösung dieser Probleme ist teilweise
noch Gegenstand der Forschung. Im Folgenden werden die wichtigsten dieser Probleme beschrieben.

3.5.2
Probleme des „Echtzeit“-Editierens
Echtzeit-Mehrbenutzer-Editoren sind verteilte Systeme, die es ermöglichen sollen, Dokumente in Echtzeit von mehreren Personen von
verschiedenen Orten aus zu bearbeiten. Dies sollte möglichst so geschehen, dass die einzelnen Personen in Bezug auf die Performanz fast
keinen Unterschied zu einem Ein-Benutzer-Editor feststellen können.
Ein Benutzer soll nach einem Tastendruck nicht erst warten müssen,
bis das System seine Eingabe geprüft hat. Daher erfordern diese Editoren im Vergleich zu den meisten anderen kollaborativen Systemen
und Datenbanksystemen besonders schnelle Antwortzeiten.
Ein „verteiltes“ Dokument, das mit Hilfe eines MehrbenutzerEditors bearbeitet wird, muss bei allen Benutzern zu jeder Zeit denselben Inhalt tragen. Es muss also überall und zu jeder Zeit konsistent
sein. Eine Voraussetzung für den Erhalt der Konsistenz ist die serielle
Äquivalenz von Operationen. Wie auch in Datenbanksystemen ist
daher in kollaborativen Editier-Systemen der Erhalt der seriellen Äquivalenz eine zentrale Aufgabe. Die serielle Äquivalenz lässt sich
folgendermaßen definieren:
Werden alle Paare von miteinander in Konflikt stehenden Operationen zweier Transaktionen auf allen betroffenen Objekten in
derselben Reihenfolge ausgeführt, so bezeichnet man diese
Transaktionen als seriell äquivalent.

Konfliktlösung in
Mehrbenutzer-Editoren

164

■
■
■

Um die serielle Äquivalenz zu erhalten, wurden verschiedene Nebenläufigkeitskontrollverfahren entwickelt, wie z. B. das Zeitstempelund das Sperrverfahren (siehe Abschnitt 3.6). Die meisten Nebenläufigkeitskontrollverfahren, wie sie in Datenbanksystemen oder anderen
kollaborativen Systemen zum Einsatz kommen, können die hohen
Anforderungen der Echtzeit-Mehrbenutzer-Editoren in Bezug auf
schnelle Antwortzeiten allerdings nicht erfüllen. Auch ist eine andere
Systemarchitektur als die zentralistische für kollaborative Editoren
notwendig.
Die meisten Echtzeit-Mehrbenutzer-Editoren (z. B. [16,17]) basieren daher auf der replizierten Architektur (siehe Kap. 3.7), um gute
Reaktionszeiten zu erreichen. Bei der replizierten Architektur besitzt
jeder Teilnehmer der Gruppenarbeit eine lokale Kopie des Doku-

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

ments. Auf dieser lokalen Kopie führt jeder Teilnehmer seine Änderungen (allgemeiner: Operationen) durch. Dies kann gleichzeitig geschehen. Der jeweilige Teilnehmer sieht das Ergebnis seiner Operation
sofort und erst danach wird die ausgeführte Operation an die anderen
Teilnehmer der Sitzung übertragen. Ist die Operation bei den anderen
Teilnehmern angekommen, wird sie dort auf den jeweiligen Kopien
ausgeführt. Dabei können Probleme durch Verzögerungen bei der
Datenübertragung und gleichzeitiges Ändern desselben Datenobjekts
entstehen.
Die folgende Abbildung zeigt einen typischen Ablauf beim verteilten Editieren eines Dokuments durch mehrere Benutzer.
Abb. 3.2:
Szenario einer Mehrbenutzer-EditorSitzung

Im oben dargestellten Szenario werden vier verschiedene Operationen von drei Benutzern auf dem verteilten Dokument ausgeführt:
O1,O2,O3 und O4.
Benutzer 1 führt die Operation O1 auf seiner lokalen Kopie des Dokuments gleichzeitig mit der Operation O2 von Benutzer 2 aus. Etwas
zeitversetzt führt Benutzer 3 die Operation O4 aus und Benutzer 2 die
Operation O3. Durch die Zeitverzögerungen bei der Übertragung der
Operationen über das Netzwerk werden die Operationen auf den jeweiligen Dokumentkopien der Benutzer in unterschiedlichen Reihenfolgen ausgeführt. Auf der lokalen Kopie von Benutzer 1 werden die
Operationen in der Reihenfolge: O1,O2,O4,O3 ausgeführt. Bei Benutzer 2 ist die Reihenfolge O2,O1,O3,O4 und bei Benutzer 3 O2,O4,O3,O1.
Die serielle Äquivalenz der Operationen ist dadurch gefährdet. Probleme der Divergenz, Kausalitätsverletzung und Intentionsverletzung
können auftreten. Diese werden im Folgenden beschrieben.

3.5 Kollaborative Mehrbenutzer-Editoren

■
■
■

165

3.5.2.1
Divergenz
Es wird zwischen Intra- und InterObjekt-Divergenz unterschieden

Sind die Operationen O1,O2,O4,O3 nicht kommutativ, können die
Ergebnisse in den Dokumenten der drei Benutzer unterschiedlich
aussehen. In diesem Fall besteht eine Divergenz der Dokumentkopien.
Es wird zwischen der Divergenz innerhalb eines Datenobjekts (IntraObjekt-Divergenz) und der Divergenz zwischen Datenobjekten (InterObjekt-Divergenz) unterschieden. Bei der Intra-Objekt-Divergenz
entstehen für dasselbe Datenobjekt in verschiedenen Kopien des verteilten Dokuments unterschiedliche Ergebnisse. Betrachten wir als
Beispiel einen kollaborativen Grafikeditor. Die Operationen O1 und
O2 seien dabei Operationen, welche dasselbe Grafikobjekt A (z. B. ein
Rechteck) an verschiedene Positionen X und Y im Dokument verschieben. Diese Operationen werden konkurrierende Operationen
genannt. Konkurrierende Operationen können in unterschiedlicher
Reihenfolge an verschiedenen Orten ausgeführt werden und führen
dort zu jeweils unterschiedlichen Ergebnissen.
Bei der Inter-Objekt-Divergenz entstehen unterschiedliche Ergebnisse an zwei oder mehreren Datenobjekten in den verschiedenen
Kopien des verteilten Dokuments.
Ein Beispiel: In einem kollaborativen Grafikeditor werden zwei unterschiedliche Objekte zur selben Zeit von zwei Personen erzeugt. Die
Objekte überlappen sich dabei. Je nachdem welche Operation für die
Erzeugung eines Objektes zuerst ausgeführt wird, liegt entweder das
erste Objekt über dem zweiten oder umgekehrt. Die folgende Abbildung soll dies verdeutlichen.

Abb. 3.3:
Szenario InterObjekt-Divergenz

166

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Die Operation O1 von Benutzer 1 erzeugt ein Objekt B. Relativ zeitnah wird durch die Operation O2 von Benutzer 2 ein Objekt A erzeugt.
Nachdem die Operationen an den jeweils anderen Benutzer übertragen und dort ausgeführt wurden, zeigt sich eine Inter-Objekt-Divergenz der Dokumente.
3.5.2.2
Kausalitätsverletzung
Wie in der Abb. 3.2 zu sehen ist, wird Operation O3 bedingt durch die
nicht deterministische Netzwerkslatenz erst nach der Ankunft der
Operation O1 bei Benutzer 2 erzeugt. Geht man davon aus, dass Benutzer 2 die Operation O3 als Reaktion auf O1 ausgeführt hat, besteht
eine kausale Abhängigkeit zwischen O3 und O1. Die Kausalordnung
von Ereignissen gibt vor, ob diese kausal voneinander abhängig sind
oder nicht. Kausal unabhängige Ereignisse werden auch als nebenläufige Ereignisse bezeichnet.
Werden Operationen, die kausal abhängig sind, in falscher Reihenfolge ausgeführt, so liegt eine Kausalitätsverletzung vor. Dies ist im
obigen Beispiel bei Benutzer 3 der Fall, da die Operation O3 vor O1
eintrifft.
3.5.2.3
Intentionsverletzung
Werden konkurrierende Operationen auf einem Datenobjekt ausgeführt, welche die Eigenschaften dieses Objektes ändern, so können die
Änderungen einer Operation verloren gehen. Betrachten wir das gleiche Beispiel, wie es beim Problem der Divergenz beschrieben wurde.
Zwei konkurrierende Operationen verschieben dasselbe Objekt an
unterschiedliche Positionen im Dokument. Dies führt zu unterschiedlichen Ergebnissen in den verschiedenen Dokumentkopien der zwei
Benutzer und damit zu Divergenz. Wird nun auf irgendeine Weise
eine Konvergenz hergestellt und das Objekt steht danach in beiden
Dokumentkopien an derselben Position, so geht eine der beiden Änderungen verloren. Es gibt in diesem Fall keine Möglichkeit, eine
Konvergenz zu schaffen, die beide Intentionen der Benutzer integriert.
Somit liegt hier eine Intentionsverletzung vor. Dabei handelt es sich
um eine syntaktische Intentionsverletzung, die von einem System
festgestellt werden kann. Es gibt auch den Fall einer semantischen
Intentionsverletzung. Dabei wollen zwei Benutzer dasselbe semantisch
korrekte Ergebnis erzielen, gehen aber gleichzeitig auf unterschiedliche Weise vor und es entsteht ein syntaktisch korrektes Ergebnis, das
allerdings semantisch falsch ist. Ein Beispiel:

3.5 Kollaborative Mehrbenutzer-Editoren

■
■
■

167

In einem Grafikdokument existieren zwei Körbe mit Äpfeln. Der
eine Korb ist grün, der andere rot. Die Äpfel im roten Korb sind alle
rot, die im grünen alle, bis auf einen roten Apfel, grün. Nun wollen
zwei Benutzer, die gleichzeitig an diesem Dokument arbeiten, den
roten Apfel aus dem grünen Korb entfernen. Der erste Benutzer verschiebt dazu den roten Apfel aus dem grünen Korb in den roten. Der
zweite Benutzer färbt den roten Apfel grün. Das Endergebnis ist ein
grüner Apfel im roten Korb. Die Lösung solcher semantischen Konsistenzprobleme ist noch Gegenstand der Forschung [18].

3.5.3
Mehrbenutzer-Editoren in der Praxis
Mehrbenutzer-Editoren existieren für verschiedene Quellcode- und
Text-Derivate, Word, UML, HTML, PowerPoint und verschiedene
Grafikformate. Vor allem asynchrone Editoren sind häufig vertreten.
Hier gibt es eine Vielzahl an Text- und HTML-Editoren, aber auch
einige Grafikeditoren. Die meisten synchronen und asynchronen
Mehrbenutzer-Editoren sind Teil eines Forschungsprojektes und basieren auf proprietären Datenformaten. In der Praxis sind die synchronen Editoren zurzeit noch weniger relevant. Dies könnte sich aber
mit der rasanten Entwicklung der Netzwerk- und Computertechnologien ändern. Es besteht allerdings noch Bedarf in der Forschung und
der Entwicklung von Standards, um Mehrbenutzer-Editoren so populär wie z. B. E-Mail und Chats zu machen. Oft liegen die Probleme
neben der technischen Komplexität dieser Systeme in der Usability.
Eine zentrale Rolle spielen allerdings auch psychologische Aspekte.
Die Akzeptanz eines Echtzeit-Mehrbenutzer-Editors hängt stark vom
Vertrauen der Benutzer untereinander ab. Die Benutzer müssen sich
gut kennen, um sich von einem Kollegen freiwillig bei der Arbeit „über
die Schulter“ blicken zu lassen. Dies kann auch wirtschaftliche Relevanz haben. Kann bei einem Echtzeit-Mehrbenutzer-Editor z. B. für
die Entwicklung von Quellcode gesehen werden, was ein Entwickler
wann erstellt, so könnte ein unbeliebter Chef seinen Mitarbeiter direkt
nach der Anzahl der Quellcodezeilen pro Stunde bewerten und dementsprechend sein Gehalt anpassen. Wo es möglich ist, zu sehen, was
und wann jemand arbeitet, so ist es auch möglich zu sehen, wann jemand nicht arbeitet. Dieser Eingriff in die Privatsphäre stellt ein großes Problem für die Akzeptanz eines Echtzeit-Mehrbenutzer-Editors
dar, dem mit Hilfe von geeigneten Sicherheits- und Kontrollmechanismen begegnet werden muss. Im Folgenden werden beispielhaft
verschiedene Mehrbenutzer-Editoren kurz vorgestellt. Eine relativ
umfassende Aufstellung asynchroner und synchroner MehrbenutzerEditoren findet man in [19].

168

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

• SAMS [1]: Synchronous/Asynchronous/Multisynchronous Editor.
Dieser erlaubt das Editieren von speziellen im Softwaredesign eingesetzten Objektkarten und einfachen HTML-Dokumenten. Dabei
kann zwischen den verschiedenen Synchronisationsmodi umgeschaltet werden. Es kann auf Knopfdruck synchronisiert werden,
oder die Arbeit wird auf dem Dokument zunächst alleine durchgeführt und es wird zu einem späteren Zeitpunkt synchronisiert. Es
handelt sich dabei um ein Forschungsprojekt.
29
• MoonEdit : Dies ist ein kooperativer synchroner Mehrbenutzer
Texteditor, der die Mausbewegungen der anderen Teilnehmer
sichtbar macht. Es handelt sich dabei um ein Freeware Projekt.
• CoWord und CoPowerPoint [15]: Dies sind Anwendungen, die als
30
Erweiterung (Plug-In) für das Microsoft Word -Produkt installiert
werden. Sie erlauben das synchrone Bearbeiten von Microsoft
Word- und PowerPoint-Dokumenten (Forschungsprojekt).
31
• Kollaborativer UML-Editor : Der im Rahmen des COAST-Framework Projektes (1999) entstandene Editor erlaubt das gemeinsame
synchrone Editieren von UML-Dokumenten (Forschungsprojekt).
• REDUCE [14]: Kollaborativer webbasierter Texteditor. Er erlaubt das
Bearbeiten von einfachsten Texten in Echtzeit (Forschungsprojekt).
• GRACE [18]: Kollaborativer synchroner Grafikeditor, der das
gleichzeitige Bearbeiten von einfachen Grafiken im Team ermöglicht (Forschungsprojekt).
32
• SubEthaEdit ist ein studentisches Projekt, das 2003 mit dem Apple
Design Award ausgezeichnet wurde. Es handelt sich dabei um einen
Texteditor, mit dem auch sogenanntes Extreme-Programming
möglich ist (Freeware für Privatnutzer).
• CoDraft [20]: Eine verteilte Architektur zur Unterstützung von
Gruppenarbeit durch multimediale Objekte (Forschungsprojekt).
• SEPIA [21]: Ein Editor für Hypertextdokumente (Forschungsprojekt).

29
30
31
32

Beispiele für Mehrbenutzer-Editoren

http://moonedit.com/.
http://office.microsoft.com/en-us/default.aspx.
http://www.darmstadt.gmd.de/concert/activities/internal/umledit.html.
http://www.subethaedit.de/collaborate.de.html.

3.5 Kollaborative Mehrbenutzer-Editoren

■
■
■

169

3.6
Nebenläufigkeitskontrolle
in CSCW Systemen
Um inkonsistente Daten bei der Arbeit in der Gruppe zu vermeiden,
werden Zugriffskontroll- bzw. Nebenläufigkeitskontrollverfahren
(engl.: concurrency control methods) eingesetzt. Frei nach der Definition von Bernstein et al. [22] versteht man unter Nebenläufigkeitskontrolle die Koordination der Aktionen verschiedener Prozesse, die
gleichzeitig auf gemeinsame Daten zugreifen und sich damit potenziell behindern. Es gibt prinzipiell zwei Funktionsweisen der Nebenläufigkeitskontrolle:
• Konsistenzerhalt durch Konfliktprävention
• Konsistenzerhalt durch Konfliktauflösung

Zum Konsistenzerhalt werden
verschiedenste Verfahren eingesetzt

170

■
■
■

Die am häufigsten eingesetzten Verfahren sind das Turn-Taking,
das Split-Combine und das Copy-Merge-Verfahren, bei denen der
Zugriff durch Absprache der Teilnehmer oder durch andere Vorgaben
zeitlich und/oder lokal begrenzt wird. Der Zugriff erfolgt entweder
nacheinander oder auf Kopien des betreffenden Artefakts. TurnTaking und Split-Combine sind Verfahren der Konfliktprävention,
Copy-Merge ein Verfahren, bei dem Konflikte nachträglich gelöst
werden müssen. Diese Verfahren werden deshalb oft eingesetzt, da sie
sehr einfach sind und häufig keine zusätzliche Installation einer Software erfordern. Sie bringen aber Nachteile in Bezug auf den Zeitaufwand und die Nachvollziehbarkeit von Änderungen mit sich.
Zu den Verfahren der Konfliktvorbeugung zählen unter anderem
auch die in der Datenbankwelt weit verbreiteten Sperrverfahren, zum
Beispiel das pessimistische Sperrverfahren. Diese Sperrverfahren
(engl. locking) sind softwaregestützt und werden in den meisten
CSCW-Systemen, wie Groupware, Versionsverwaltung und Mehrbenutzer-Editoren, eingesetzt. Eine zentrale Instanz (Server) regelt dabei
den Zugriff der Teilnehmer (Clients) auf die Artefakte. Mit Hilfe eines
sogenannten Check-In/Check-Out-Mechanismus werden die Daten
bereitgestellt.
Daneben gibt es noch Verfahren, die vor allem in MehrbenutzerEditoren zum Einsatz kommen, da sie deren besondere Anforderungen, wie echtzeitnahe Antwortzeiten und feingranulare Nebenläufigkeitskontrollen (z. B. auf Buchstabenebene), unterstützen. Dieser Abschnitt beschreibt die gängigsten Nebenläufigkeitskontrollverfahren.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

3.6.1
Nebenläufigkeitskontrolle ohne CSCW-System
Beim Turn-Taking kann immer nur eine Person zu einer gegebenen
Zeit auf ein Artefakt (z. B. ein Textdokument) zugreifen. Hat die Person ihre Arbeit an dem Artefakt abgeschlossenen, so wird das Artefakt
an die nächste Person, „die an der Reihe ist“, weitergereicht. Wer
wann „an der Reihe“ ist, wird entweder mit Hilfe einer technischen
Lösung (z. B. Software) oder durch Absprache der Teilnehmer bestimmt. Nach der Übergabe kann nun die nächste Person ihrerseits
Änderungen am Artefakt durchführen. Auf diese Art und Weise ist es
möglich, das Artefakt sehr einfach konsistent zu halten, da zu jedem
Zeitpunkt immer nur eine gültige Artefaktversion existiert.
Eine andere Möglichkeit der Zusammenarbeit ist das Aufteilen der
Arbeit in kleinere Arbeitspakete. Dabei bekommt jeder Teilnehmer
ein Arbeitspaket zugeteilt. Nach Erledigung der Arbeit werden die
einzelnen Ergebnisse an zentraler Stelle wieder zusammengeführt.
Dieses sogenannte Split-Combine-Verfahren erfordert neben dem
aufwendigen nachträglichen Zusammenführen der Artefakte auch
eine Aufteilbarkeit der Aufgabe in Arbeitspakete.
Dies ist z. B. bei Quellcode nicht immer möglich, da eine Abhängigkeit der Quelldateien untereinander besteht. Daher wird hier oft das
sogenannte Copy-Merge-Verfahren eingesetzt. Dabei erhält jeder
Teilnehmer eine Kopie aller vorliegenden Artefakte und kann nun
selbständig Änderungen daran vornehmen. Am Schluss müssen alle
Änderungen allerdings wieder zusammengeführt (engl.: to merge)
werden. Dies kann unter Umständen sehr aufwendig sein. Die Nachvollziehbarkeit der Änderungen ist besonders bei größerer Personenzahl nur schwer möglich, da nach einem erfolgreichen Zusammenführen im Artefakt keine Informationen über die jeweils durchgeführten
Änderungen gespeichert sind (keine Versionsinformationen).
Trotz dieser Nachteile wird heute oft auf diese Weise gearbeitet –
gerade bei der Erstellung von Dokumenten und der Umsetzung von
Softwareprojekten in kleineren Teams, ohne Unterstützung durch ein
CSCW-System.

Turn-Taking, Split-Combine und
Copy-Merge

3.6.2
Sperrverfahren
Sperrverfahren werden besonders in Datenbanksystemen eingesetzt,
um den Erhalt der seriellen Äquivalenz zu gewährleisten und den
parallelen Zugriff auf Daten zu synchronisieren. Das grundlegende
Prinzip beim Sperren paralleler Zugriffe ist sehr einfach, aber nicht
besonders geeignet für produktive Systeme. Daher wurden optimierte

3.6 Nebenläufigkeitskontrolle in CSCW Systemen

■
■
■

171

Sperrverfahren und -algorithmen entwickelt, die den Anforderungen
produktiver Systeme gewachsen sind. Im Folgenden werden die zwei
hauptsächlich verwendeten Verfahren, das pessimistische und das optimistische Sperren, und verschiedene Varianten dieser besprochen.
3.6.2.1
Pessimistisches Sperren
Pessimistisches Sperren kommt häufig
in Datenbanksystemen zum Einsatz

Aus den Synchronisationstechniken der Betriebssysteme (wie z. B.
Semaphore, Mutexe und Monitore) ist das sogenannte exklusive Sperren (engl.: exclusive locking) entstanden. Um auf ein Datenobjekt
zuzugreifen, muss dabei zunächst eine exklusive Sperre für dieses
Objekt besorgt werden. Diese Sperre verhindert den Zugriff aller anderen Transaktionen auf das gesperrte Datenobjekt. Wird zum Beispiel in einer Transaktion T2 versucht, eine Sperre auf ein Datenobjekt zu erlangen, welches sich bereits im Zugriff einer anderen
Transaktion T1 befindet, so muss T2 warten, bis T1 die Sperre wieder
frei gibt. Für den Fall, dass viele parallele Transaktionen auf dieselben
Datenobjekte zugreifen, kann allerdings eine schlechte Systemperformanz die Folge sein. Daher wurde, um die Performanz zu verbessern,
die sogenannte Teilsperre (engl.: shared lock) oder Lesesperre (engl.:
read lock) eingeführt. Für eine verbesserte Systemperformanz wird
dabei davon ausgegangen, dass das Lesen von Datenobjekten weitaus
öfter vorkommt als das Schreiben dieser. Eine Lesesperre erlaubt dabei das Lesen eines Datenobjekts in parallelen Transaktionen, aber
nicht das Ändern desselben. Um das Datenobjekt nun zu ändern, wird
weiterhin eine exklusive Sperre benötigt. Dieses Verfahren wird TX(Teil-, Exklusiv-) oder LX- (Lese-, Exklusiv-) Sperren genannt (engl.:
SX oder RX locking). Abbildung 3.4 zeigt die Kompatibilität der zwei
Sperrmodi (Lese- und Exklusivsperre).
In Abb. 3.4 zeigt KS den Zustand an, in dem keine Transaktion eine
Sperre auf ein Datenobjekt hält. Ein Sperren dieses Datenobjekts ist in
diesem Fall immer gestattet. Hält eine andere Transaktion bereits eine
Lesesperre, kann eine weitere Transaktion auch eine Lesesperre für
dasselbe Datenobjekt erhalten. Lesesperren sind daher kompatibel, was

Abb. 3.4:
Kompatibilitätsmatrix des
LX-Sperrmechanismus

172

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

bedeutet, dass ein Datenobjekt von beliebig vielen Transaktionen zur
selben Zeit gelesen werden kann. Eine Anfrage nach einer exklusiven
Sperre für ein Datenobjekt wird allerdings nur gewährt, solange dieses
Objekt mit keiner Sperre durch eine weitere Transaktion belegt ist.
Versucht eine Transaktion eine Exklusivsperre für ein Datenobjekt
zu erhalten, welches bereits gesperrt ist (Lese- oder Exklusivsperre), so
wird diese so lange blockiert, bis die entsprechende Sperre wieder
aufgehoben wurde. Dabei kann es zu einem sogenannten Deadlock
(Verklemmung) kommen. Bei einem Deadlock warten Transaktionen
unendlich lange auf die Freigabe einer Sperre. Es gibt verschiedenste
Methoden, um Deadlocks zu vermeiden: Eine Methode ist zum Beispiel das sogenannte Vorbelegen (engl.: preclaiming) oder statisches
Sperren (engl.: static locking), bei dem alle benötigten Sperren einer
Transaktion gleich zu Beginn besorgt werden. Andere Methoden sind
zum Beispiel das sofortige Neustarten einer Transaktion (engl.: immediate restart, no waiting), das WDL-Verfahren (wait depth limited)
oder die Verwendung von Zeitstempeln in Transaktionen (wait/die,
wound/wait). Diese Verfahren werden näher von Härder et al. [23]
besprochen.
Ein weiteres pessimistisches Sperrverfahren ist das sogenannte
Zwei-Phasen-Sperren (engl.: two phase locking). In der ersten Phase,
der Wachstumsphase (engl.: growing phase), besorgt sich eine Transaktion alle benötigten Sperren. In der zweiten Phase, der Schrumpfphase (engl.: shrinking phase), gibt die Transaktion die Sperren wieder
frei. Abbildung 3.5 zeigt die Phasen der Zwei-Phasen-Sperrmethode.
Treten während der Schrumpfphase Probleme auf und die Transaktion muss rückgängig gemacht werden (engl. rollback), so kann es
zu einem sogenannten „dirty read“ (dreckiger Lesevorgang) kommen:
Dabei wird in einer Transaktion mit Daten gearbeitet, die durch den
„Rollback“ einer anderen Transaktion bereits ungültig sind. Man
spricht dabei auch von sogenannten unbestätigten Abhängigkeiten
(engl.: uncommited dependency).

Verfahren zur Lösung der
Deadlock-Problematik

Abb. 3.5:
Zwei-Phasen-Sperrmethode

3.6 Nebenläufigkeitskontrolle in CSCW Systemen

■
■
■

173

Abb. 3.6:
Strikte Zwei-Phasen-Sperre

Eine Möglichkeit, einen „dirty read“ zu verhindern, ist das sogenannte strikte Zwei-Phasen-Sperren (engl.: strict two phase locking).
Dabei wird die komplette Schrumpfphase erst am Ende der Transaktion durchgeführt, wenn ein erfolgreicher Abschluss sicher ist. Abbildung 3.6 zeigt den Ablauf einer strikten Zwei-Phasen-Sperre.
3.6.2.2
Optimistisches Sperren
Beim optimistischen Sperren wird davon ausgegangen, dass Zugriffskonflikte nur relativ selten auftreten (daher optimistisch) und dass
das präventive Sperren von Datenobjekten unnötig hohen Aufwand
und Leistungseinbußen bedeuten würde. Erst am Ende einer Transaktion wird geprüft, ob Konflikte aufgetreten sind. So sind parallele
Transaktionen möglich und es entstehen keine Zeitverzögerungen
durch das Warten auf frei werdende Sperren.
Der Ablauf einer Transaktion ist beim optimistischen Sperren in
drei Phasen aufgeteilt. In der Lesephase werden die Datenobjekte
gelesen und lokale Kopien angelegt, auf denen Änderungen durchgeführt werden.
Nachdem die Transaktion abgeschlossen (commited) wurde, beginnt die Validierungsphase. In dieser Phase wird geprüft, ob durch
die Transaktion ein Integritätsverlust auftritt oder das gewünschte
Ergebnis erzielt wird. Schlägt die Validierung fehl, wird die Transaktion rückgängig gemacht und beginnt von neuem. In diesem Fall, werden Konflikte durch das Rückgängigmachen und neue Starten von
einer oder mehreren beteiligten Transaktionen gelöst. Dies bedeutet
allerdings, dass mehr Rollbacks auftreten als beim pessimistischen
Sperrverfahren. Dagegen ist das Auftreten von Deadlocks im Gegensatz zum pessimistischen Sperren nicht möglich.

174

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Abb. 3.7:
Drei Phasen des optimistischen
Sperrverfahrens

Falls sichergestellt werden kann, dass die Änderungen einer Transaktion nicht zu einem Integritätsverlust führen, werden die lokalen
Kopien in der dritten Phase, der Schreibphase, als global gültig erklärt.
Abbildung 3.7 zeigt die drei Phasen einer Transaktion beim optimistischen Sperrverfahren.
Das Ausführen von Operationen auf lokalen Kopien von Datenobjekten hat Vor- und Nachteile. Ein Vorteil ist, dass das Auftreten von
„dirty-reads“ oder „dirty-writes“ verhindert wird. Ein weiterer Vorteil
ist die hohe Parallelität von Operationen, die durch das gleichzeitige
Ändern und Lesen von Datenobjekten erzielt werden kann. Das Rückgängigmachen einer Transaktion wird einfach durch das Verwerfen
der Änderungen auf den lokalen Kopien der Datenobjekte erreicht.
Ein Nachteil des optimistischen Sperrverfahrens ist der höhere
Speicherverbrauch durch die lokalen Kopien und die benötigten
komplexen Puffermechanismen. Die Schreibphase kann in Bezug auf
die Performanz des Gesamtsystems sehr teuer werden, falls eine große
Anzahl von Schreiboperationen in einer Transaktion ausgeführt werden müssen. In diesem Fall besteht eine erhöhte Gefahr des „Verhungerns“ (engl.: starvation) einer Transaktion. Diese Gefahr tritt auf,
wenn die Validierung von Transaktionen ständig fehlschlägt was besonders bei sehr langen Transaktionen passieren kann, das heißt bei
Transaktionen, die sehr viele Leseoperationen beinhalten und damit
gegen viele andere Transaktionen validiert werden müssen. Zusätzlich
kann das erst relativ spät durchgeführte Rückgängigmachen (Rollback) einer Transaktion (im Falle eines Konfliktes) zu vielen unnötig
durchgeführten Operationen führen, was wiederum Einbussen in der
Systemperformanz zur Folge haben kann.
Es ist möglich, pessimistische und optimistische Sperrverfahren zu
kombinieren. Beispiele für solche „Hybrid“-Ansätze findet man in
33
Datenbanksystemen wie zum Beispiel IMS Fast Path oder Gem34
Stone . Diese versuchen durch die Kombination beider Verfahren
deren Vorteile zu nutzen, ohne die Nachteile in Kauf nehmen zu müssen. Das IMS Fast Path System verwendet zum Beispiel eine spezielle
33
34

Kombination pessimistischer und
optimistischer Sperrverfahren

http://www-306.ibm.com/software/data/ims/.
http://www.gemstone.com/.

3.6 Nebenläufigkeitskontrolle in CSCW Systemen

■
■
■

175

Die Wahrscheinlichkeit für Konflikte ist
von verschiedensten Parametern
abhängig

Kombination von pessimistischen und optimistischen Verfahren.
Dabei werden Datenobjekte zunächst in der Lesephase wie beim optimistischen Verfahren behandelt. Erst in der Validierungs- und
Schreibphase werden sie gesperrt. Durch die damit verbundene Reduzierung der Sperrzeit im Vergleich zu dem rein pessimistischen Verfahren wird die Wahrscheinlichkeit eines Blockierens anderer Transaktionen stark reduziert.
Ein ähnlicher Ansatz wird in verschiedenen Versionsverwaltungssystemen wie zum Beispiel CVS oder Subversion verwendet. Dabei
werden Änderungen an Datenobjekten zunächst nur auf lokalen Kopien durchgeführt. Sobald die Änderungen bestätigt (engl.: commited)
wurden, werden sie zentral gesperrt. Nun wird geprüft, ob Konflikte
mit anderen Transaktionen bestehen (Validierung). Mit Hilfe von
Zeitstempeln wird dabei ermittelt, ob Datenobjekte in der Zeit zwischen dem Erstellen der lokalen Kopie und dem Bestätigen der Änderungen geändert wurden. Schlägt die Validierung fehl, so wird entweder die Transaktion rückgängig gemacht oder der Teilnehmer, der die
Transaktion ausgeführt hat, benachrichtigt. Dieser kann dann entscheiden, ob seine eigenen oder die Änderungen der anderen Teilnehmer verworfen oder alle Änderungen zusammengeführt werden
(engl.: merge). Das Zusammenführen der Änderungen kann dabei
automatisch, halbautomatisch oder manuell geschehen. Ein Vorteil
dieser Vorgehensweise ist die relativ kurze Zeit in der Validierungsphase, in der die Datenobjekte gesperrt werden, und die damit
geringere Wahrscheinlichkeit für Transaktionskonflikte und Rollbacks. Ein Nachteil ist die mit der Anzahl der Teilnehmer steigende
Wahrscheinlichkeit von Konflikten (Validierungsfehlern). Die Wahrscheinlichkeit der Konflikte ist zusätzlich abhängig von der Granularität der Sperre (z. B. Dokumentebene oder Buchstabenebene), der Größe und Anzahl der Artefakte und der Verteilung der gleichzeitigen
Zugriffe auf diese. Ist die Granularität der Sperren klein (z. B. Sperren
von einzelnen Buchstaben eines Dokumentes) und die Anzahl und
Größe der Artefakte hoch, so sinkt die Wahrscheinlichkeit für Konflikte. Die Sperrgranularität bestimmt dabei die kleinste Einheit eines
35
36
Sperrvorganges. Systeme wie VSS und CVS , aber auch andere existierende CSCW-Systeme zur Unterstützung der Arbeit im Team wie
37
38
zum Beispiel Wikis oder die HTTP-Protokollerweiterung WebDAV
35

36
37
38

176

■
■
■

Microsoft Visual SourceSafe©:
http://msdn.microsoft.com/vstudio/previous/ssafe/.
Concurrent Versioning System – CVS: http://www.nongnu.org/cvs/.
Wiki-Software: http://en.wikipedia.org/wiki/Wiki_software.
Web-based Distributed Authoring and Versioning – WebDAV:
http://www.webdav.org/.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

verwenden nur eine Sperrgranularität auf Dokumentebene. Das heißt,
es wird immer das komplette Dokument gesperrt, auch wenn tatsächlich nur ein kleiner Teil bearbeitet wird.

3.6.3
Zeitstempelverfahren
Bei diesem Verfahren werden zum Erhalt der seriellen Äquivalenz
Zeitstempel verwendet. Bei Beginn jeder Transaktion wird ein Zeitstempel gesetzt und dieser zugeordnet. Im Gegensatz zu den Sperrverfahren steht hier die Serialisierungsreihenfolge der nebenläufigen
Transaktionen und deren Operationen fest und wird über die Zeitstempel ermittelt. Eine Transaktion muss dabei nur auf Konflikte mit
Transaktionen, die zeitlich vor ihr liegen, geprüft werden. Transaktionen, die einen späteren Zeitstempel tragen, werden nicht in Betracht
gezogen. Tritt ein Konflikt auf, so wird die betreffende Transaktion
rückgängig gemacht und mit einem neuen Zeitstempel wiederholt. Die
Transaktionen werden also nach ihren Zeitstempeln geordnet, daher
nennt man dieses Verfahren Zeitstempelordnungs- (engl.: timestamp
ordering) oder Zeitstempelverfahren. Der Vorteil dieses Verfahrens
liegt in der impliziten Verhinderung von Deadlocks [22].
Innerhalb einer Transaktion werden zur Konfliktprüfung für jeden
Lese- und Schreibzugriff Zeitstempel gesetzt. Jedes Datenobjekt, auf
das zugegriffen wurde, erhält entsprechend einen Lese-Zeitstempel
(Sr) bzw. einen Schreib-Zeitstempel (Sw). Eine Leseoperation mit
Zeitstempel Sr(T) einer Transaktion T ist nicht erlaubt, wenn das zu
lesende Datenobjekt X einen Schreib-Zeitstempel besitzt, der neuer
(>) ist als Sr(T). Gilt:
Sr(T) < Sw (X),
so muss die Transaktion zurückgesetzt werden. Entsprechend wird
die Transaktion auch zurückgesetzt, falls auf ein Datenobjekt geschrieben werden soll, welches einen Lesestempel neueren Datums
besitzt. Damit ist eine Transaktion nur gültig, solange keine andere
Transaktion zu einem späteren Zeitpunkt als T dasselbe Datenobjekt
X ändert. Generell ist eine Schreiboperation Sw(T) nicht erlaubt, falls
gilt:
Sw(T) < Max(Sr(X), Sw (X))
Entweder wird die Transaktion zurückgesetzt (Sw(T) <S r(T)) oder
der Schreibbefehl ignoriert (Sw(T) < Sw(X)).

3.6 Nebenläufigkeitskontrolle in CSCW Systemen

■
■
■

177

Abb. 3.8:
Szenario Zeitstempelverfahren

Die Abbildung zeigt ein Szenario, in dem die Transaktionen T1 und
T2 auf dasselbe Datenobjekt X in der richtigen Transaktionsreihenfolge zugreifen. In dem Moment, in dem T1 auf das Datenobjekt Y zugreift, wurde es bereits durch Transaktion T3 geändert, was dazu
führt, dass T1 zurückgesetzt wird.
Das Beispiel zeigt, dass mit der Dauer einer Transaktion die Wahrscheinlichkeit für ein Zurücksetzen (Rollback) ansteigt. Es kann dabei
in manchen Fällen zu einem sogenannten „Verhungern“ (engl.: starvation) einer Transaktion kommen. Auch besteht bei diesem Verfahren
die Gefahr eines „dirty writes“ durch unbestätigte Abhängigkeiten.

3.6.4
Operational Transformation
Operational Transformation erfüllt die
hohen Anforderungen der
Mehrbenutzer-Editoren

178

■
■
■

Das Ziel der Operational Transformation (OT) ist der Erhalt der Konsistenz und der Benutzerintentionen durch Konfliktauflösung. Dabei
werden Operationen sofort, d. h. ohne Verzögerung ausgeführt, wodurch eine sehr schnelle Reaktionszeit ermöglicht wird. Der Benutzer
muss also, im Gegensatz zu Sperrverfahren, nicht warten, bis eine
Sperre auf dem zu bearbeitenden Datensatz eingerichtet wurde. Operationen werden direkt auf einer lokalen Kopie des Dokuments ausgeführt und erst danach an die anderen Clients verteilt. Dort werden sie
erneut durchgeführt. Eine Operation kann dabei, wenn sie von einem
Client empfangen wurde, vor ihrer Durchführung zunächst transformiert werden. Die Transformation hat dabei das Ziel, die Intention
der Benutzer beizubehalten und die auf allen Clients vorliegenden
Dokumentkopien zu konvergieren [24]. Es gibt verschiedenste Vorschläge für Operational-Transformation-Algorithmen. Die meisten
sind für Dokumente, die auf einem linearen Datenformat (z. B. ASCIITextdokumente) basieren, geeignet. Einige davon sind unter anderem
dOPT [25], adOPTed [26], GOT [27], GOTO [28], SOCT2 [29]. Zurzeit
gibt es nur wenige Algorithmen für Operational Transformation, welche auf einem hierarchischen Datenformat (z. B. XML) basieren: Einer

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

davon ist der treeOPT-Algorithmus [24]. Die meisten dieser OT Algorithmen arbeiten nach demselben Prinzip der Konsistenzerhaltung.
Der Operational-Transformation-Algorithmus wurde ursprünglich
entwickelt, um die Probleme der Divergenz (siehe Abschnitt 3.5.2.1),
Kausalitätsverletzung (siehe Abschnitt 3.5.2.2) und der Intentionsverletzung (siehe Abschnitt 3.5.2.3) in kollaborativen Editiersystemen zu
beheben. Ein kollaboratives Editiersystem wird dabei als konsistent
bezeichnet, wenn es immer den Erhalt von Konvergenz, Kausalität
und Intention gewährleistet.
Bei der Operational Transformation wird zur Bewahrung der Kausalität ein Zeitstempelverfahren auf Basis der „Vector-Logical Clock“
[30, 29] verwendet. Dadurch kann sichergestellt werden, dass eine
Operation A, die nach der Kausalordnung „vor“ einer Operation B
liegt (A < B), auch vor dieser ausgeführt wird. Dies geschieht unabhängig davon, in welcher Reihenfolge die Operationen jeweils beim
entsprechenden Teilnehmer eintreffen. Zum Erhalt der Konvergenz
und der Intention einer Operation wird eine totale Ordnungsrelation
[24, 31, 32] (engl.: total ordering relation) zwischen den Operationen
definiert. Diese legt fest, in welcher Reihenfolge welche Operationen
auf der jeweiligen lokalen Kopie eines Dokuments ausgeführt werden.
In einem sogenannten History-Buffer werden zusätzlich alle ausgeführten Operationen gespeichert. Jede Operation wird basierend auf
der Ordnungsrelation und den bereits ausgeführten Operationen im
History-Buffer vor ihrer Ausführung transformiert, um auf die Änderungen zu reagieren, die durch die anderen Operationen hervorgerufen wurden. Um dies zu verdeutlichen zeigt Abb. 3.9 das Szenario
eines Editiervorganges ohne Transformational Operation.
Dabei arbeiten zwei Benutzer an einem gemeinsamen Dokument,
welches den Text „Schiffart“ enthält. Der Text kann durch die Operation Ins(p,c) modifiziert werden. Durch diese Operation wird ein Buchstabe c an Position p im Text eingefügt. Es wird angenommen, dass die
Position des ersten Buchstabens im Text 0 ist. Benutzer 1 generiert die
Operation O1 = Ins(4,f) und Benutzer 2 die Operation O2 = Ins(7,h).
Wird die Operation O1 beim zweiten Benutzer empfangen und ausgeführt, so führt dies zu dem erwarteten Ergebnis „Schifffahrt“.
Im Dokument des ersten Benutzers sieht dies anders aus. Dort wird
nicht beachtet, dass die Operation O1 bereits zuvor ausgeführt wurde
und damit die Textlänge verändert wurde. Das Resultat ist eine Divergenz der beiden lokalen Dokumente. Um ein korrektes Ergebnis zu
erhalten, muss die Operation O2 unter Einbeziehung von O1 zuerst
transformiert werden, bevor sie ausgeführt werden kann. Wird nun
zum Beispiel die Operation O2 im Dokument von Benutzer 1 in Ins(8,h)
transformiert, so wird eine Konvergenz der Dokumente erzielt.
Abbildung 3.10 zeigt das Beispiel mit Operational Transformation.

3.6 Nebenläufigkeitskontrolle in CSCW Systemen

Zeitstempel zur Bewahrung der
Kausalität

Der History-Buffer enthält alle
ausgeführten Operationen

■
■
■

179

Abb. 3.9:
Szenario ohne Operational
Transformation

Abb. 3.10:
Szenario mit Operational
Transformation

180

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

3.7
Architektur kollaborativer Systeme
Ein CSCW-System kann je nach Anforderung auf verschiedenste Weise aufgebaut sein. In diesem Abschnitt werden die wichtigsten Softwarearchitekturen von CSCW-Systemen vorgestellt. Es wird dabei nur
auf den abstrakten Aufbau und dessen Vor- und Nachteile eingegangen. Neben der Softwarearchitektur spielen die Netzwerkarchitektur
und die Sicherheitsarchitektur eine wichtige Rolle bei der Entwicklung
eines CSCW-Systems. Oft kommen hier Standards zum Einsatz, auf
denen die CSCW-Systeme aufsetzen. Zum Beispiel werden zur Übertragung von Daten zwischen CSCW-Clients häufig ein VPN (Virtual
Private Network) und entsprechende Verschlüsselungsverfahren eingesetzt, um eine sichere Datenübertragung über das Internet zu gewährleisten. Im Bereich der Netzwerkanbindung spielen immer mehr
mobile Datennetze eine Rolle. Dabei werden Daten zum Beispiel über
GPRS oder UMTS ausgetauscht. Hier müssen bei der Planung eines
mobilen CSCW-Systems die Eigenschaften des verwendeten Datennetzes in Betracht gezogen werden, wie z. B. geringe Bandbreite und
Übertragungsausfall durch z. B. Funklöcher.

3.7.1
Zentralisierte Architektur
Die zentralisierte Architektur ist die am meisten verbreitete ClientServer-Architektur bei verteilten Systemen. Dabei verwaltet ein zentraler Server die sich im Zugriff mehrerer Clients befindlichen Daten.
Die Clients können nicht direkt auf die Daten zugreifen. Der Zugriff
wird vom Server geregelt.
Die zentralisierte Architektur ist oft bei Datenbank-ManagementSystemen zu finden. Aber auch bei CSCW-Systemen ist sie sehr beliebt. Vor allem Versionsverwaltungssysteme, aber auch viele Groupware-Systeme basieren auf dieser klassischen Client-Server-Architektur. Bei Echtzeit-Mehrbenutzer-Editoren kommt sie seltener zum
Einsatz, da hier besondere Anforderungen, wie geringe Antwortzeiten,
bestehen. Diese können durch eine zentralisierte Architektur nicht in
allen Fällen erfüllt werden.
Bei der zentralisierten Architektur besitzt der Server einen oder
mehrere Server-Prozesse. In der einfachsten Variante hat ein Server nur
einen Prozess. Somit ist ein gleichzeitiger Zugriff mehrerer Clients auf
eine Ressource nicht möglich. Dadurch kann auf einfachste Weise eine
Dateninkonsistenz vermieden werden. Ein Nachteil dabei ist allerdings
die schlechte Performanz des Gesamtsystems, da der Datenzugriff so

3.7 Architektur kollaborativer Systeme

Die zentralisierte Architektur wird am
häufigsten eingesetzt

■
■
■

181

lange blockiert wird, solange ein Client die Daten (wie zum Beispiel ein
verteiltes Dokument) auf dem Server bearbeitet. Um dennoch die „Illusion“ des gleichzeitigen Zugriffs mehrerer Clients auf die Datenobjekte
zu schaffen, unterstützen Systeme dieser Art sehr feinkörnige Operationen, die in sehr kurzer Zeit durchgeführt werden können.
In der Regel werden aber bei modernen Systemen mehrere ServerProzesse gestartet, um die Performanz des Gesamtsystems zu verbessern. Damit können gleichzeitig Anfragen von mehreren Clients
entgegengenommen werden. Werden Datenobjekte nicht nur gelesen
(wie z. B. bei Web-Servern), sondern auch geschrieben, so muss ein
Nebenläufigkeitskontrollverfahren eingesetzt werden, um Dateninkonsistenzen zu vermeiden.
Will ein Client auf Datenobjekte des Servers zugreifen, muss zunächst eine Anfrage an den Server übertragen werden. Dort entscheidet der Server mit Hilfe des eingesetzten Nebenläufigkeitskontrollverfahrens (wie z. B. Sperrverfahren), ob ein Zugriff durch den Client zu
diesem Zeitpunkt erlaubt ist. Je nach eingesetztem Verfahren kann es
hierbei zu einer entsprechenden Verzögerung kommen (z. B. bei Blockierung durch Sperre). Wird der Zugriff erlaubt, so kann die gewünschte Operation der Clients (z. B. Lesen oder Schreiben eines Datenobjekts) ausgeführt werden und der Client erhält eine Antwort
vom Server mit der Bestätigung seiner Anfrage.
Dieser Ablauf kann relativ zeitaufwendig sein und hängt eventuell
von vielen „äußeren“ Faktoren wie zum Beispiel der Netzwerkverbindung ab. Daher ist diese Architektur für sehr zeitkritische kollaborative Anwendungen unter Umständen weniger geeignet. Abbildung 3.11
zeigt den Aufbau einer zentralistischen Systemarchitektur.
Abb. 3.11:
Zentralisierte Architektur mit nur einem
Server-Prozess

182

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

3.7.2
Replizierte Architektur
Bei der replizierten Architektur existiert keine zentrale Datenquelle
und kein zentraler Server. Jeder Client besitzt eine Kopie der Daten,
die sich im gemeinsamen Zugriff befinden. Die Daten werden dabei
entweder komplett repliziert oder, je nach System, nur die Daten, die
für den Client relevant sind. Jeder Client besitzt zusätzlich eine Art
Server-Prozess, der den Zugriff auf die Daten und die Synchronisation
dieser verwaltet. Dazu kommuniziert der Server-Prozess mit allen
anderen Client-Server-Prozessen. Abbildung 3.12 zeigt einen Überblick der Architektur.
Eine replizierte Architektur bietet den Vorteil schneller Antwortzeiten an der Benutzerschnittstelle. Lokale Operationen werden direkt
vom lokalen Server-Prozess ausgeführt. Das Ergebnis ist sofort sichtbar, da keine Netzwerkkommunikation und Prüfung der Anfrage
benötigt wird. Erst nach der lokalen Ausführung einer Operation wird
diese an alle anderen Teilnehmer der Kollaboration die daran interessiert sind, weitergegeben. Sobald die anderen Server-Prozesse die
Operation empfangen, führen sie diese auf deren lokalen Kopien der
Daten aus. Ein weiterer Vorteil ist eine geringere Ausfallwahrscheinlichkeit des Gesamtsystems, da es keine zentrale Instanz gibt, bei deren Ausfall das System zum Stillstand gebracht wird (kein „SinglePoint-of-Failure“).
Nachteil dieser Architektur ist das Problem der möglichen Inkonsistenzen, die bei der gleichzeitigen Bearbeitung eines Datensatzes

Mehrbenutzer-Editoren verwenden
meist die replizierte Architektur

Abb. 3.12:
Replizierte Systemarchitektur

3.7 Architektur kollaborativer Systeme

■
■
■

183

durch mehrere Server-Prozesse auftreten können. Diesem Problem
wird versucht, mit verschiedenen Nebenläufigkeitskontrollverfahren,
wie zum Beispiel der Operational Transformation, zu begegnen.
CSCW-Systeme, die eine solche replizierte Architektur einsetzen
sind meist Mehrbenutzer-Editoren, die besondere Anforderungen an
die clientseitigen Antwortzeiten stellen. Dazu gehören zum Beispiel
das COAST-Framework und darauf basierende Systeme (siehe [33, 34,
35, 36, 37, 38, 39]).
Eine ähnliche Architektur wie diese wird auch von sogenannten
Peer-to-Peer- (P2P-) Systemen oder manchen Online-Spielen eingesetzt. Bei P2P-Systemen liegt der Fokus allerdings nicht unbedingt auf
schnellen Antwortzeiten, sondern auf möglichst geringen Ausfallwahrscheinlichkeiten durch die Unabhängigkeit von zentralen Datenspeichern (für weitere Informationen zu P2P-Systemen siehe Kapitel
„Verteilte Systeme“ in Teil 3 des Kompendiums).

3.7.3
Hybrid-Architektur

Die hybride Architektur vereint die
Vorteile der zentralisierten und der
replizierten Architektur

184

■
■
■

Bei der sogenannten Hybrid-Architektur gibt es einen zentralen Server, der immer eine aktuelle Version des zu bearbeitenden Datenobjekts (Artefakt), z. B. eines Dokuments, besitzt. Die verschiedenen
Clients erhalten jeweils lokale Kopien der gemeinsam genutzten Datenobjekte (komplett oder teilweise). Die Clients besitzen zusätzlich
wie bei der replizierten Architektur einen eigenen Server-Prozess, der
für die Verwaltung der Zugriffe auf die Daten und die Übertragung
der Operationen an die anderen Clients zuständig ist. Mit der hybriden Architektur wird somit versucht, die Vorteile der zentralisierten
und der replizierten Architektur zu kombinieren. Abbildung 3.13 zeigt
eine Hybrid-Architektur im Überblick.
Die meisten Systeme mit Hybrid-Architektur unterscheiden zwischen problematischen und unproblematischen Operationen. Problematische Operationen sind dabei Operationen, welche Dateninkonsistenzen herbeiführen können (z. B. Löschen und Ändern).
Unproblematische Operationen führen nicht zu Dateninkonsistenzen
(z. B. das Erstellen neuer Datenobjekte).
Wie auch bei der replizierten Architektur werden unproblematische Operationen sofort lokal ausgeführt und danach an die anderen
Clients übertragen. Auf den anderen Clients werden die Operationen
dann je nach Nebenläufigkeitskontrollverfahren und Datenstruktur
sofort oder nur bei Bedarf ausgeführt (vgl. [14]). Dadurch werden
schnelle Antwortzeiten erreicht. Problematische Operationen hingegen werden wie bei der zentralisierten Architektur zunächst nur an
den Server übertragen, dort geprüft und danach lokal ausgeführt. Als

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Abb. 3.13:
Hybrid-Architektur

Nebenläufigkeitskontrollverfahren kommen hier auch klassische
Sperrverfahren (wie in Datenbanken) zum Einsatz. Alle Operationen –
unproblematische und (falls möglich) problematische – werden immer auch auf dem Server ausgeführt. Dadurch wird sichergestellt, dass
auf dem Server immer die kompletten aktuellen Versionen aller Datenobjekte vorliegen. Dies ist neben den schnellen Antwortzeiten beim
Editieren ein weiterer Vorteil der hybriden Systemarchitektur. Eine
Kopie eines aktuellen Datenobjekts kann dadurch zum Beispiel immer
abgerufen werden, sobald ein neuer Benutzer am kollaborativen Editierprozess teilnehmen will. Auch können die Datenobjekte auf dem
Server für die Synchronisation genutzt werden. Arbeiten mehrere
Personen zum Beispiel an einem sehr großen Dokument, so ist die
Wahrscheinlichkeit, dass diese sich eventuell gegenseitig stören, vergleichsweise gering. Betrachtet nun ein Benutzer einen Teil des Dokuments, das von einem anderen Benutzer intensiv bearbeitet wurde,
so muss zuvor die lokale Kopie des Dokuments synchronisiert werden. Dies kann nun entweder durch Ausführen der bereits empfangenen Operationen geschehen oder durch Abrufen der benötigten Daten
vom zentralen Server. In manchen Systemen mit hybrider Architektur
werden auch problematische Operationen sofort lokal ausgeführt
[40, 48]. Dies erfordert allerdings Nebenläufigkeitskontrollverfahren,
wie sie auch bei replizierter Architektur zum Einsatz kommen.
Außer in CSCW-Systemen wird die hybride Architektur ähnlich der
hier beschriebenen auch bei Online-Spielen und Peer-to-Peer-Systemen eingesetzt.

3.7 Architektur kollaborativer Systeme

■
■
■

185

3.8
Awareness in kollaborativen Systemen

Awareness ist wichtig für eine
erfolgreiche Zusammenarbeit

Bei der Arbeit in einer Gruppe ist es wichtig, dass jeder Teilnehmer die
Gruppe wahrnimmt, sich als Teil dieser Gruppe sieht und auf die Aktionen anderer reagieren kann, um das gemeinsame Ziel effektiv erreichen zu können. Im Gegensatz zu Ein-Benutzer-Anwendungen
muss bei CSCW-Systemen daher eine Möglichkeit geschaffen werden,
die Gruppe und deren Aktionen wahrzunehmen. Dies geschieht mit
sogenannten Awareness- (Bewusstheit-) Mechanismen.
Das Ziel der Awareness-Mechanismen ist es, ein Gruppenbewusstsein zu schaffen und einen Teilnehmer an einer Guppenaktivität über
die Aktionen anderer Teilnehmer aufzuklären. Dourish schrieb (1997)
über Awareness:
„The primary role of awareness information is to make one's activity visible to others“ [41]
Awareness-Mechanismen bieten die Möglichkeit für Individuen,
die Arbeit anderer Teilnehmer einer Gruppe besser zu verstehen und
dann diese Information zu nutzen, um ihre und die Aktivitäten innerhalb der Gruppe zu koordinieren.

3.8.1
Workspace Awareness
Die Awareness spielt in allen CSCW-Systemen eine Rolle, besonders
jedoch in Systemen, die gleichzeitiges Arbeiten in „Echtzeit“ unterstützen, so zum Beispiel in echtzeitbasierten Mehrbenutzer-Editoren.
Bei diesen Systemen ist die wichtigste Art von Awareness die sogenannte Workspace Awareness (Bewusstsein des Arbeitsbereichs).
Gutwin beschreibt diese (1996) folgendermaßen:
„The up-to–the minute knowledge a person holds about another’s
interaction with the workspace“ [42].
Workspace Awareness bedeutet also Wissen darüber:
•
•
•
•

186

■
■
■

Wer sich im selben Arbeitsbereich (Workspace) befindet
Wer woran gerade arbeitet
Was die anderen Personen machen
Was als Nächstes zu tun ist, bzw. was welche Personen als Nächstes
tun werden

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

Workspace Awareness soll dabei:
• Den Koordinationsaufwand von Aufgaben reduzieren
• Das Wechseln von Teilnehmern zwischen individueller und Gruppenarbeit erleichtern
• Einen Kontext schaffen, in dem Äußerungen anderer interpretiert
und Aktivitäten anderer vorausgeahnt werden können
Während die meisten Nebenläufigkeitskontrollverfahren nur die
syntaktische Konsistenz von Daten gewährleisten können, ermöglichen Awareness-Mechanismen zusätzlich durch die Schaffung eines
Kontextes auch die Möglichkeit zur Interpretation und können dadurch zum Erhalt der semantischen Konsistenz der Daten beitragen.
Hier ein Beispiel zur Erläuterung:
Zwei Personen arbeiten gemeinsam an einem Buch. Die erste Person bearbeitet z. B. Kap. 5, während die zweite Person an Kap. 1 arbeitet. Nun möchte die erste Person einen Abschnitt aus Kap. 1 referenzieren, der gerade von der zweiten Person bearbeitet wird. Weiß die
erste Person allerdings nicht, was die zweite Person gerade macht, so
referenziert sie womöglich einen Abschnitt, der noch nicht fertig ist
und mit evtl. einem anderen Inhalt als erwartet. Damit könnte die
Referenz auf besagten Abschnitt semantisch inkorrekt sein. Weiß die
erste Person allerdings mit Hilfe von Awareness-Mechanismen über
die Arbeit der zweiten Person Bescheid, so würde sie eventuell warten,
bis die zweite Person den Abschnitt fertig gestellt hat und dann anders
entscheiden. Awareness kann also helfen, andere über die eigenen
Aktivitäten in Kenntnis zu setzen, um so effektivere Gruppenarbeit zu
ermöglichen.
Bei der Arbeit in einer Gruppe sind Absprachen und Informationen
über die Aktivitäten anderer sehr wichtig. Werden diese nicht durch
Awareness-Mechanismen ermöglicht, so kann man immer noch zum
Telefonhörer greifen, eine E-Mail schreiben oder Chatten. Diese Art
von „Awareness-Mechanismen“ stört aber meist den Arbeitsablauf. Es
wäre viel effektiver, wenn man auf einen Blick die für die Arbeit wichtigen „Awareness“- Informationen sehen könnte. Daher ist die Integration von Awareness-Mechanismen in ein CSCW-System wichtig, um
so den Arbeitsablauf effektiv zu unterstützen, ohne ihn durch unnötige Informationen zu behindern.
Es gibt verschiedenste Arten von Awareness-Informationen, angefangen bei Informationen über Dokumente, Projekte und Aufgaben
bis hin zu Informationen über den Ort und die Aktivitäten von anderen Gruppenarbeitern. Diese Informationen werden mit Hilfe verschiedenster Techniken bereitgestellt.

3.8 Awareness in kollaborativen Systemen

Awareness schafft ein Bewusstsein für
die Aktionen der anderen

■
■
■

187

Es existieren zahlreiche AwarenessMechanismen

In kollaborativen Systemen wie Mehrbenutzer-Editoren wird oft die
Benutzeroberfläche mit neuen Komponenten, sogenannten „Widgets“,
erweitert, welche die fehlenden Informationen über die anderen Teilnehmer bereitstellen. Beispiele dafür sind das „Teleporting“, „Telepointing“, Mehrbenutzer-Scrollbalken, „What You See Is What I Do“(WYSIWID-) Ansichten, Miniaturansichten oder sogenannte Radaransichten.
Mit dem „Teleporting“ kann die Arbeitsumgebung einer anderen
Person betrachtet werden. Dabei wird zum Beispiel ein Screenshot der
Ansicht (z. B. Arbeitsbereich, Desktop) eines anderen Teilnehmers
gezeigt. Beim „Telepointing“ werden die Mausbewegungen einer anderen Person sichtbar gemacht. Der Mehrbenutzer-Scrollbalken zeigt
die relative Position jedes Teilnehmers im Arbeitsbereich. Die
WYSIWID-Ansicht erlaubt es, die Aktivitäten einer anderen Person
direkt zu sehen. Die Miniaturansicht gibt eine Übersicht über den
gesamten Arbeitsbereich und die Radaransicht zeigt Zusatzinformationen über die Position anderer im Arbeitsbereich. Weitere Möglichkeiten zur Bereitstellung von Awareness-Informationen sind Bilder
von Web-Kameras, Videoausschnitte und Hintergrundgeräusche.
Die Entwicklung von Awareness-Mechanismen beschränkt sich
nicht nur auf Softwarelösungen. Es werden auch neuartige Geräte
eingesetzt, um die Awareness zu verbessern. Es gibt verschiedene
Ansätze, Alltagsgegenstände mit „Intelligenz“ auszustatten, um unter
anderem die Mensch-Computer-Interaktion zu verbessern oder den
Menschen auf andere Weise das Leben zu erleichtern. Aus den Forschungsgebieten Human Computer Interaction (HCI), Ubiquitous
Computing und Ambient Intelligence entstehen zusätzlich neue Ansätze, wie die Awareness in CSCW-Systemen verbessert werden kann.
Zum Beispiel existieren in der Forschung spezielle Stühle mit Sensoren, die ein Groupware-Konferenzsystem automatisch darüber informieren, wenn ein Teilnehmer von seinem Stuhl aufsteht und den
Raum verlässt [43]. Damit wird ein aktives Abmelden durch den Benutzer unnötig und die anderen Teilnehmer der Konferenz sind nicht
überrascht, dass der Teilnehmer nicht mehr antwortet, weil er vergessen hatte, sich abzumelden.

3.8.2
Usability und Privatsphäre
Bei der Entwicklung der Awareness-Unterstützung für ein CSCWSystem hat die Usability einen zentralen Stellenwert. Man sollte sich
unter anderem überlegen, welche Information relevant ist und wie
diese bereitgestellt wird. Ein Zuviel an Awareness-Informationen oder
eine ungeschickte Aufbereitung und Darstellung dieser kann auch

188

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

ablenkend bzw. hinderlich auf den Arbeitsablauf wirken. Auch ist
eventuell relevant, was die Unterbrechung des Arbeitsablaufs für die
Benutzer bedeutet.
Ein bewusster Umgang mit der Privatsphäre der Benutzer ist wichtig. Es sollte jedem Benutzer die Möglichkeit gegeben werden, selbst
zu kontrollieren, welche Informationen über ihn und seine Arbeit
preisgegeben werden und welche nicht. Besteht diese Möglichkeit der
Kontrolle nicht, kann dies im einfachsten Fall die Ablehnung des
CSCW-Systems durch die Benutzer bewirken. Bei kommerziell eingesetzten Systemen kann dies aber auch zur unfreiwilligen Offenlegung
von geschäftsrelevanten Informationen führen. Wenn jeder Benutzer
eines CSCW-Systems sehen kann, was ein anderer gerade tut (oder
nicht tut), kann diese Information eventuell schädigend eingesetzt
werden.
Anonymität der Benutzer kann daher bei manchen Systemen Voraussetzung und Ermutigung für eine faire und konstruktive Teilnahme am System (z. B. bei Diskussionsgruppen) sein und schützt Benutzer vor Belästigung. Auf der anderen Seite besteht ein Interesse an der
Preisgabe persönlicher Daten, da dadurch Systeme sinnvoller individuelle Anpassungen wie z. B. der Benutzeroberfläche vornehmen
können und dadurch die Usability verbessert werden kann. Auch gibt
es Fälle, in denen Anonymität z. B. aus abrechnungs- und sicherheitstechnischen Gründen nicht erwünscht ist, um z. B. Missbrauch zu
verhindern. Um den widersprüchlichen Anforderungen gerecht zu
werden, ist Reziprozität (Wechselseitigkeit) eine mögliche Verfahrensweise. Dabei muss ein Benutzer, der über einen anderen Benutzer
etwas erfahren will, die gleiche Information über sich preisgeben.
Diese Verfahrensweise ist allerdings nicht überall sinnvoll. Generell
sollte bei CSCW-Systemen Wert auf die Sicherheit und die Privatsphäre gelegt werden.

Privatsphäre und Benutzerfreundlichkeit
sind entscheidend für die Akzeptanz
eines CSCW-Systems

3.9
Fazit und Ausblick
Was wäre das Internet ohne das WWW und E-Mail? Wer heutzutage
keine E-Mail-Adresse besitzt, gilt als veraltet. Auch Weblogs und Wikis gehören mittlerweile zum modernen Menschen der Informationsgesellschaft. CSCW-Systeme sind daher schon fester Bestandteil des
Alltags vieler, ohne dass sie es wahrnehmen, und nicht mehr aus diesem wegzudenken. Und der Trend geht weiter.
Aktuelle CSCW-Systeme bieten in vielen Bereichen eine gute Unterstützung, doch gibt es noch viel zu verbessern. Die Integration der kollaborativen Systeme in den Arbeitsablauf lässt meist noch zu wünschen

3.9 Fazit und Ausblick

■
■
■

189

Mobilität wird immer wichtiger

CSCW-Systeme machen die Welt zum
Büro

übrig. Es gibt zu viele kleine Projekte und proprietäre Systeme, die
jeweils nur für eine Teillösung taugen. Oft will man aber mehr. Eine
Integration verschiedener Systeme zu einem auf den Anwendungsfall
abgestimmten Gesamtsystem sollte möglich werden. Dazu bedarf es
neuer Standards, um zwischen Systemen Daten und Informationen
austauschen zu können, ohne dabei von einem System abhängig zu
sein. Die Integration der CSCW-Systeme in die Betriebssysteme und
die Kompatibilität der Systeme untereinander sollte also auch besser
werden, um unter anderem eine gute Usability und damit eine bessere
Benutzerakzeptanz zu erreichen.
Usability, Awareness und Privatsphäre sind wichtige Punkte, die in
aktuellen CSCW-Systemen oft zu kurz kommen. Es besteht also noch
großer Forschungsbedarf im Bereich CSCW.
Im mobilen Zeitalter will oder muss man jederzeit und überall erreichbar sein. Ob per SMS, Mobiltelefon oder im Chat mit dem Laptop im Homeoffice, in der Bahn, im Flugzeug oder im Café sitzend.
Dabei nimmt das kollaborative Arbeiten von Überall und zu jeder
Zeit einen immer höheren Stellenwert ein. Nicht nur auf Flugplätzen
und Bahnhöfen sind heute Hotspots verfügbar. Mit der Weiterentwicklung der Hardware und der Vernetzung wird sich auch die kollaborative Software immer weiter entwickeln. CSCW-Systeme wie
Groupware, Versionsverwaltung und Mehrbenutzer-Editoren werden
noch mehr miteinander verschmelzen. CSCW-Systeme werden in
Zukunft auf verschiedenste Weisen zusammenspielen und uns immer
und überall begleiten.
Das Mobiltelefon wird in Zukunft zur zentralen Kommunikationszentrale werden, mit der Leistungsfähigkeit eines PCs und ständiger
Breitbandanbindung an das Internet oder das Firmennetzwerk. Mit
neuen Displaytechnologien, neuartigen Eingabegeräten und spezialisierten Betriebssystemen wird man immer und überall mit hohem
Komfort im mobilen Büro arbeiten. Dabei unterstützen kollaborative
Systeme den Benutzer und vermitteln ihm den Eindruck als wäre er
vor Ort beim Kunden oder beim Kollegen im Büro. Neben den drei
„klassischen“ mobilen Geschäftsanwendungen Surfen, E-Mail und
Zugriff aufs Firmennetz wird die Internet-Zusammenarbeit z. B. als
Desktop-Sharing oder als Web-Conferencing zu den Standardanwen39
dungen des mobilen Büros gehören . Das spart Zeit und Reisekosten.
Die Telearbeit wird durch immer bessere kollaborative Systeme und
Hardware zur Normalität werden und nebenbei spart die Firma dadurch Büromiete. Entfernung spielt in der Zukunft keine Rolle mehr.
In der Zukunft könnte zum Beispiel ein japanischer 3D-Designer
von zu Hause aus mit seinem deutschen Kollegen gleichzeitig an einem
39

190

■
■
■

Erste Trends setzen Anwendungen wie Netviewer. http://www.netviewer.de/.

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

3D-Modell für ein neues Automobil arbeiten. Dabei nutzen sie einen
Echtzeit-Mehrbenutzer-Editor mit integrierter Versionsverwaltung
und ein Groupware-System für die Kommunikation und die Besprechungen mit den anderen Teammitgliedern, die auf der ganzen Welt
verteilt arbeiten. Virtuelle Konferenzräume werden dabei die „echten“
Konferenzräume ersetzen. Sie werden eine Interaktivität bieten, die der
Realität in nur wenigen Punkten nachsteht. Die dabei eingesetzte kollaborative Software wird äußerst benutzerfreundlich in das Betriebssystem integriert sein. Forschungsprojekte wie Croquet geben einen
Hinweis darauf, wie ein kollaboratives Betriebssystem der Zukunft
aussehen könnte.
Nicht allein die Zeitersparnis und der Wegfall der Reisekosten sind
überzeugende Argumente für den Einsatz von CSCW-Systemen. Auch
bieten sie heute schon eine gute Unterstützung der gemeinschaftlichen Arbeit durch neue Kommunikationsmöglichkeiten und die Integration von Arbeitsabläufen. Gerade in Zeiten der Globalisierung
sind CSCW-Systeme nicht mehr wegzudenken.

Literatur
[1]

Molli, P., Skaf, H., Oster, G., Jourdain., S.: „SAMS: Synchronous, Asynchronous, Multi-Synchronous Environments“. Proceedings of CSCWD'02, Rio de
Janeiro, Brazil, 2002.
[2] Wilson, P.: Computer supported cooperative work: an introduction. Oxford,
England Norwell, MA, Intellect; Sold and distributed in the U.S.A. and
Canada by Kluwer Academic Publishers, 1991.
[3] Grudin, J.: Groupware and social dynamics: eight challenges for developers.
Communications of the ACM, 37, 1994.
[4] Koch, M.: Unterstützung kooperativer Dokumentenbearbeitung in Weitverkehrsnetzen. Dissertation an der Technischen Universität München,
1996.
[5] Ellis, C.A., Gibbs, S.J., Rein, G.L.: Groupware – Some Issues and Experiences.
Communications of the ACM, 34, 1991.
[6] Greenberg, S.: Computer Supported Cooperative Work and Groupware.
Academic Press, London, 1991.
[7] Dillenbourg, P. et al.: The Evolution of Research on Collaborative Learning.
Learning in humans and machines. Towards an interdisciplinary learning
science. P. Reimann and H. Spada. London, Pergamon: 189–211, 1995.
[8] Hildebrand, R., Koetter, P.: Postfix. Dpunkt Verlag, 2005.
[9] Carius, F., Mantke, I.: Microsoft Exchange Server 2003. Hanser Fachbuchverlag, 2005.
[10] Levine, J.: QMAIL. O’Reilly Media, 2004.
[11] Riempp, G.: Wide Area Workflow Management. Springer-Verlag, London
1998.

Literatur

■
■
■

191

[12] Greif, I., Seliger, A., Weihl, W.: A Case Study of CES: A Distributed Collaborative Editing System Implemented in Argus. IEEE Transactions on Software Engineering, S. 827–839, 1992.
[13] Knister, M.J., Prakash, A.: DistEdit: a distributed toolkit for supporting
multiple group editors. Proceedings of the 1990 ACM conference on Computer-supported cooperative work, Los-Angeles, S. 343–355, 1990.
[14] D. Chen.: REDUCE – REal-time Distributed Unconstrained Collaborative
Editing System. Research Project at the Griffith University, Brisbane. 2001.
[15] Sun, C. et al.: A consistency model and supporting schemes in real-time
cooperative editing systems. Proceedings of the 19th Australian Computer
Science Conference, Melbourne, S. 582–591, Jan. 1996.
[16] Galli, R., Luo, Y.: MU3D: A Causal Consistency Protocol for a Collaborative
VRML Editor. Proceedings of the Web3D-VRML 2000 fifth symposium on
Virtual Reality Modeling Language. ACM, February 2000.
[17] Ellis, C.A., Gibbs. S.J.: Concurrency Control in Groupware Systems. Proceedings of the 1989 ACM SIGMOD international conference on management
of data. ACM, 1989.
[18] Chen, D.: Consistency Maintenance in Collaborative Graphics Editing Systems. Dissertation at the Griffith University Brisbane, 2001.
[19] Koch, M.: Unterstützung kooperativer Dokumentenverarbeitung in Weitverkehrsnetzen. Dissertation an der TU München, 1997.
[20] Kirsche, T. et al.: CoDraft: Eine verteilte Architektur zur Unterstützung von
Gruppenarbeit durch Multimediale Objekte, Praxis Information und Kommunikation, Stuttgart, 1993.
[21] Haake, J.M., Wilson, B.: Supporting collaborative writing of hyperdocuments in SEPIA. Proceedings of the 1992 ACM Conference on ComputerSupported Cooperative Work, Toronto, Canada, 1992.
[22] Bernstein, P. et al.: Concurrency Control and Recovery in Database Systems.
Addison-Wesley, 1987.
[23] Härder, T.: Datenbanksysteme: Konzepte und Techniken der Implementierung. 2. Auflage, Springer-Verlag, 2001.
[24] Ignat, C., Norrie, M.: Tree-based model algorithm for maintaining consistency in real-time collaborative editing systems. ACM. Fourth International Workshop on Collaborative Editing Systems, New Orleans, Louisiana,
2002.
[25] Ellis, C.A., Gibbs, S.J.: Concurrency Control in Groupware Systems. ACM
Proceedings. SIGMOD International Conference on Management of Data.
1989.
[26] Ressel, M., Nitsche-Ruhland, D. et al.: An integrating, transformationoriented approach to concurrency control and undo in group editors. ACM
Conference on Computer-Supported Cooperative Work, 1996.
[27] Sun, C., Jia, X. et al.: Achieving Convergence, Causality-preservation, and
Intention-preservation in Real-time Cooperative Editing Systems. ACM
Transactions on Computer-Human Interaction, 1998.
[28] Sun, C., Ellis, C.: Operational Transformation in Real-Time Group Editors:
Issues, Algorithms, and Achievements. ACM Proceedings. ACM Conference
on Computer-Supported Cooperative Work, Seattle, Washington, 1998.

192

■
■
■

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

[29] Suleiman, M., Cart, M. et al.: Serialization of Concurrent Operations in
a Distributed Collaborative Environment. ACM International Conference
on Supporting Group Work, 1997.
[30] Fidge, C. J.: Timestamps in message-passing systems that preserve the partial ordering. University of Queensland, Australia. 11th Australian Computer Science Conference, 1988.
[31] Lamport, L.: Time, clocks and the ordering of events in a distributed system.
Computer Associates, 1978.
[32] Raynal, M., Singhai, M.: Logical Time: Capturing Causality in Distributed
Systems. IEEE Computer. S. 49–56. IEEE, 1996.
[33] Pfister, H.-R., Schuckmann, C., Beck-Wilson, J., Wessner, M.: The Metaphor
of Virual Rooms in the Cooperative Learning Environment. Proceedings of
CoBuild'98, Darmstadt, 1998.
[34] Miao, Y. et al.: An Activity-Oriented Approach to Visually Structured Knowledge Representation for Problem-Based Learning in Virtual Learning Environments. COOP'2000 (Fourth International Conference on the Design of
Cooperative Systems). Sophia Antipolis, Frankreich, 2000.
[35] Streitz, N.A. et al.: DOLPHIN: Integrated Meeting Support across LiveBoards, Local and Remote Desktop Environments. Proceedings of the 1994
ACM Conference on Computer-Supported Cooperative Work (CSCW'94),
Chapel Hill, N.C., S. 345–358, 1994.
[36] Streitz, N.A. et al.: i-LAND: An interactive Landscape for Creativity and
Innovation. ACM Conference on Human Factors in Computing Systems
(CHI '99). ACM Press, New York, 1999.
[37] Haake, J., Wang, W.: Flexible Support for Business Processes: Extending
Cooperative Hypermedia with Process Support. Information and Software
Technology, S. 355–366, 1999.
[38] GMD-IPSI: „Co-operative UML Editor“
http://www.darmstadt.gmd.de/concert/activities/internal/umledit.html,
2000.
[39] Schümmer, T., Schümmer, J.: Support for Distributed Teams in eXtreme
Programming, Proceedings of eXtreme Programming and Flexible Processes in Software Engineering - XP2000, Addison-Wesley, 2000.
[40] Gerlicher, A.: Erweiterung bestehender Anwendungen um kollaborative
Funktionen mit Hilfe des Collaborative Editing Framework for XML
(CEFX). Aktuelle Trends in der Softwareforschung. Band 2: Tagungsband
zum doIT Software−Forschungstag am 29. Oktober 2004. Fraunhofer IRB
Verlag, Stuttgart, 2005.
[41] Dourish, P.: Extending Awareness Beyond Synchronous Collaboration.
Position paper for the CHI’97 Workshop on Awareness in Collaborative Systems, Atlanta, 1997.
[42] Gutwin, C., Roseman, M., Greenberg, S.: A Usability Study of Awareness
Widgets in a shared Workspace Groupware System. ACM CHI '96 Conference Companion, 1996.
[43] Szwillus, G., Ziegler, J. (Hrsg.): Mensch & Computer 2003: Interaktion in
Bewegung. Stuttgart: B. G. Teubner, S. 135–143, 2003.
[44] Beaudouin-Lafon, Michel (ed.): Computer-Supported Cooperative Work.
John Wiley, 1999.

Literatur

■
■
■

193

[45] Coleman, D. (ed.): Groupware. Collaborative Strategies for Corportate
LANSs and Intranets. Upper Saddle River: Prentice-Hall, 1997.
[46] Crabtree, A.: Designing Collaborative Systems: A Practical Guide to Ethnography, Springer-Verlag, 2003.
[47] Darses, F., Dieng, R., Simone, C. Zacklad, M. (Hrg.): Cooperative Systems
Design, Scenario-Based Design of Collaborative Systems, Proceedings of
COOP 2004, Hyères Les Palmiers, Frankreich, 2004.
[48] Gerlicher, A.: A Framework for Real-Time Collaborative Engineering in the
Automotive Industries. Lecture Notes on Computer Science, Proceedings of
the Third International Conference on Cooperative Design, Visualization
and Engineering, Mallorca, Spain, Springer-Verlag, September 2006.

Links zu Forschungsprojekten
COAST:
CoWord:
CoPowerPoint:
Reduce:
Grace:
Annodex:
Croquet:

http://www.opencoast.org/download/
http://reduce.qpsf.edu.au/coword/
http://reduce.qpsf.edu.au/copowerpoint/
http://reduce.qpsf.edu.au/reduce/index.html
http://www.cit.gu.edu.au/~scz/projects/grace/
http://www.annodex.net/
http://www.opencroquet.org/

Abkürzungen
API
BLOG
CMWeb
CSCL
CSCW
CVS
FTP
GPRS
HCI
HTML
HTTP
IMAP
IMAPS
IP
IRC
ISDN
MCU
OT
P2P
POP3
POP3S
RSS

194

■
■
■

Application Programmer’s Interface
Weblog
Continuous Media Web
Computer-Supported Cooperative Learning
Computer-Supported Cooperative Work
Concurrent Versioning System
File Transfer Protocol
General Packet Radio System
Human Computer Interaction / Interface
Hypertext Markup Language
Hypertext Transfer Protocol
Internet Message Access Protocol
Internet Message Access Protocol Secured
Internet Protocol
Internet Relay Chat
Integrated Services Digital Network
Multipoint Control Unit
Operational Transformation
Peer to Peer
Post Office Protocol 3
Post Office Protocol 3 Secured
Really Simple Syndication

3 Computer-Supported Cooperative Work (CSCW) – kollaborative
Systeme und Anwendungen

RTCE
SAMS
SCC
SIP
SMB
SMTP
SPAM
SVN
TCP
UML
UMTS
VoIP
VPN
VSS
WebDAV
WfMS
WWW
WYSIWID
XML

Real-Time Collaborative Editing
Synchronous Asynchronous Multisynchronous System
Source Code Control
Session Initialisation Protocol
Server Message Block
Simple Message Transfer Protocol
Engl. Dosenfleisch oder unerwünschte E-Mail
Subversion
Transmission Control Protocol
Unified Modelling Language
Universal Mobile Telecommunications System
Voice over IP
Virtual Private Network
Visual Sourcesafe
Web-based Distributed Authoring and Versioning
Workflow Management System
World Wide Web
What You See Is What I Do
Extensible Markup Language

Abkürzungen

■
■
■

195

4 Content-Related-Technologien
Oliver Kretzschmar

Dieses Kapitel vermittelt einen Überblick und das Verständnis über die
grundlegenden und interdisziplinären Content-Related-Technologien
in Systemen, wie Dokumenten-Management-, Web-Content-Management-, Enterprise-Content-Management-Systemen etc. Im Folgenden
werden wir Systeme aus dem Umfeld der Content-Related-Technologien als CRT-Systeme bezeichnen (der verwandte Begriff „DRT Document-Related-Technologien“ wurde 1998 von Ulrich Kampffmeyer
eingeführt). CRT-Systeme, deren Vertreter in Kap. 4.3 noch näher
erläutert werden, sind IT-Systeme, die überwiegend digitale Inhalte
erfassen, beschaffen, verwalten und verwerten (vgl. Kampffmeyer
2003). Der Begriff wird auch deshalb verwendet, um dem Wildwuchs
der Systembezeichnungen mit einem Überbegriff begegnen zu können.
Dabei unterscheiden sich diese Systeme vorrangig in ihrem eigentlichen Anwendungsgebiet, den primären Nutzenfaktoren und den daraus abgeleiteten Anforderungen sowie in der Art der erfassten bzw.
verwalteten digitalen Inhalte.
Wir betrachten und erläutern hier in kompakter Form die im Kontext des Themas stehenden Begrifflichkeiten, die elementaren Nutzenaspekte und die grundlegenden technologischen Bausteine solcher
Systeme. Für eine weitere Vertiefung wird jeweils auf entsprechende
Literatur verwiesen. Zur Veranschaulichung geben wir zu den komplexen Sachverhalten entsprechende Beispiele aus der Praxis.

Content-Related-Technologien

4.1
Grundlegende Begriffe
4.1.1
Informationen, Daten, Medien, Content, Asset
und Wissen
Information meint zum einen die Kenntnis über Zustände, Geschehnisse oder Sachverhalte in der realen Welt, zum anderen ist es der Prozess

4.1 Grundlegende Begriffe

Informationen und Daten

■
■
■

197

Medien

Content

Rechte

198

■
■
■

der Kommunikation selbst im Sinne von Informieren, Verständigen
und Mitteilen. Im Kontext der Content-Related-Technologien wird der
Aspekt der Erkenntnis, die Bedeutung von Information und der pragmatische Aspekt von Nutzen und Zielen der Information in den Vordergrund gestellt (vgl. Schneider, Werner 2004).
Daten werden im Computer (systemintern) verarbeitet und mittels
eindeutiger Vorschriften verarbeitungsgerecht formuliert. Zum Beispiel ist die Zahl „4,60“ zwar ein Datum (pl. Daten), aber noch keine
Information. Information lässt sich als Verknüpfung zwischen Daten,
einer semantischen Bedeutung und einem pragmatischen Wert darstellen. Information lebt also in einer Welt von Bedeutung, Kontext
(Beziehung) und Interpretation. Zum Beispiel wird unsere Zahl (Datum) „4,60“ durch den Kontext und der Bedeutung „1 DIN A4 Block
kostet 4,60 Euro“ zu einer Information mit praktischem Wert.
Medien dienen der Speicherung, Darstellung und Übermittlung
von Informationen. Dabei können die Informationen in unterschiedlich strukturierter Form und Codierung vorliegen. Die Struktur definiert dabei den gegliederten Aufbau, also die Anordnung von Teilen
zu einem Ganzen. Eine Strukturierung kann dabei auf unterschiedliche Arten herbeigeführt werden, etwa mittels Metadaten als ergänzende Informationen oder durch Eingliederung in eine Ordnungsstruktur, etwa eine hierarchische Gruppierung. Die Codierung
bestimmt den Medientyp, wie Text, Rasterbild, Ton, Video. Medienobjekte bezeichnen Datenobjekte gleichen Medientyps, zum Beispiel die
Mediendatei PhotoShop-Bild PSD mit einer zugehörigen Zusatzinformation, wie der Bildbeschreibung. Multimedia-Objekte bezeichnen
Inhalte, die aus mehreren digitalen Medien unterschiedlicher Medientypen bestehen, zum Beispiel PowerPoint-Datei mit referenzierten
(nicht eingebetteten) Bilddateien.
Content (engl. Inhalt) bezeichnet Medien in schwach oder stark
strukturierter Form, die in elektronischen Systemen genutzt werden
können. Die Art der Strukturierung und deren Granularität ist unterschiedlich ausgeprägt. Zum Beispiel kann sich der Content auf ein
Bildobjekt mit ergänzenden Informationen, wie Bildbeschreibungen,
beziehen oder auf die Überschrift eines Dokumentenberichtes. Eine
zunehmende Rolle in CRT-Systemen spielen komplexer strukturierte
Content-Objekte wie Produkte im Katalog-Management (z. B. „Bohrmaschine 4711“) mit unterschiedlichen Abbildungen, Preis- und Artikelinformationen. Auf die Möglichkeiten und Notwendigkeiten der
Strukturierung solcher Medien werden wir noch eingehen.
Rechte spezifizieren die Bedingungen eines Verwendungs-, Vervielfältigungs- bzw. Verwertungsrechts von Content. Diese Bedingungen
stehen im Kontext zum Urheberrecht. Als Urheberrecht wird das ausschließliche Recht eines Schöpfers (Urhebers) an seinem Werk (z. B.

4 Content-Related-Technologien

Musikkompositionen, Gemälde, Filme, Fotografien, wissenschaftliche
oder literarische Texte etc.) bezeichnet. Die resultierenden Nutzungsrechte können an andere Rechtspersonen abgetreten werden.
Assets (engl. Wert) definiert einen verwertbaren Content unter Berücksichtigung der existierenden Rechtsverhältnisse. Aus diesem
Wertegedanken leiten sich viele Systeme in diesem Kontext ab: Das
geht vom einfachen Wiederauffinden von Dokumenten in Archivund Dokumenten-Management-Systemen bis zur automatischen Verknüpfung und Wiederverwertung von Inhalten in unterschiedlichen
Werbemitteln in Enterprise-Content-Management-Systemen. Die
Berücksichtigung der Rechteverhältnisse (vgl. Kreikle 2001) spielt
insbesondere dort eine Rolle, wo Content von anderen Urhebern bezogen wird, etwa bei der Verwendung von Bildern anderer Urheber in
Verlagen oder aktuellen Nachrichten auf Unternehmens-Webseiten
(Abb. 4.1).
Wissen ist die intelligente Verknüpfung von Informationen mit
vorhandenen Erfahrungen und Kenntnissen. Wissen kann dabei explizit, also codiert in Form von Daten, Dokumenten etc., oder aber
implizit (als Erfahrung menschlicher Wissensträger) vorliegen (vgl.
Bullinger, Wörner, Prieto 1998).

Asset

Wissen

Abb. 4.1:
Medien, Struktur, Content, Rechte und
Asset

4.1.2
Formatierung und Strukturierung von Content
Um Content kommunizieren und darstellen zu können, muss er in
Formate codiert werden.

4.1 Grundlegende Begriffe

■
■
■

199

Formatierung

Strukturierung

200

■
■
■

Im Bereich der Content-Related-Technologien kann man zwei primäre Arten von Formatierung unterscheiden: die binäre und die Rendering-Formatierung. Die binäre Formatierung dient zur Codierung
analoger in digitale Daten, etwa der Umwandlung eines gescannten
Farbfotos in das digitale Bildformat EPS; das Ergebnis ist ein Dateiformat. Die interne Codierung eines Medientyps besteht aus den eigentlichen Rohdaten (z. B. Bitfolgen) und aus Registrierungsdaten zur
korrekten Identifikation und Interpretation der Rohdaten (z. B. Header-Informationen in einem Videostream) sowie optional beschreibende Daten (vgl. Meyer-Wegener 2003).
Die Rendering-Formatierung dient als Darstellungsform zur Informations-Präsentation von Content. Zu den Rendering- Formatierungen gehören visuelle, emotionale und Formeffekte für Inhalt und Layout, wie Schriftgröße, Hervorhebungen durch Farbe und Positionen
von Textpassagen oder Zeichen- und Absatzformatierungen mit einer
bestimmten Schriftart (vgl. Boiko 2002; Rockley 2003).
Das Layout definiert die räumliche (z. B. Dokument), zeitliche (z. B.
Video) und logische Anordnung von Inhalten, die wiederum durch
Rendering-Formatierungen gestaltet sind. Das Layout mit den gestalteten Inhalten ergibt die eigentliche Darstellungsform. Die Forderung
im Bereich der Content-Related-Technologien nach Trennung von
Struktur, Inhalt und Gestaltung ist von zentraler Bedeutung.
Zur ausgabekanalunabhängigen (device independent) Verwertung
von Content ist die Trennung von Binär- und Rendering-Formatierung
erforderlich. Des Weiteren sollten die Gestaltungseigenschaften nicht
auch schon codiert sein, da dies bereits eine spezifische Ausrichtung
für einen bestimmten Ausgabekanal, wie Print oder Web, beinhaltet.
Die Struktur definiert den gegliederten Aufbau und die Anordnung
von Teilen eines Ganzen zueinander. Die Strukturierung ermöglicht
das Zusammenführen von Content in unterschiedlichen Prozessstufen, etwa durch Bündelung von unterschiedlichen Fachartikeln zu
einem neuen thematischen Sammelband innerhalb einer ContentVerwertung. Die Strategie der Mehrfachverwertung werden wir in
Kap. 4.2.2 erörtern. Eine Strukturierung ermöglicht des Weiteren,
unterschiedliche Sichten auf ein und denselben Content oder dessen
Zusammenführungen abzubilden: So kann ein Artikeltext der „Content“-Fachzeitschriften-Ausgabe 12/2005 zum Thema „Metadaten“
nicht nur in eine hierarchische Gruppe „Fachzeitschrift Content ->
2005 -> Ausgabe 12“ eingeordnet werden, sondern auch in die hierarchische Gruppe „Content-Themen -> Metadaten“.
Es gibt im Bereich der Content-Related-Technologien unterschiedliche Arten zur Strukturierung. Die wohl Wichtigsten sind das Hinzufügen von sogenannten Metadaten, also ergänzende Informationen
(z. B. eine Artikelnummer zu einer Produktabbildung), die Möglich-

4 Content-Related-Technologien

keit der Einordnung in ein Ordnungssystem (z. B. hierarchische
Gruppe) und das Auszeichnen (z. B. Tagging) von Content-Bestandteilen und deren „Binnenstruktur“, etwa mittels XML, in dafür geeigneten Medientypen wie XML-Dokumenten.
Sehr häufig wird eine Strukturierung vereinfachend nur durch Gestaltungsformatierung und nicht über eine vorhergehende explizite
Strukturierung herbeigeführt; man denke an die Formatierung mittels
Formatvorlagen in WinWord; oftmals gibt es gar keine Alternative zu
dieser impliziten Strukturierung. Ziel muss aber sein, dass umgekehrt
die Gestaltung auf der Basis einer expliziten Strukturierung erfolgt.
Beispiel: In einem Fachzeitschriftenartikel erkennen wir allein durch
das Layout (Gestaltungsformatierung) die Überschrift, die Zusammenfassung (z. B. Kurztext), den eigentlichen Artikelinhalt (z. B. Langtext), den Namen des Autors und das Erscheinungsjahr. Würde man
diese Layoutformatierung als Grundlage der Strukturierung heranziehen, dann könnte dieser Content zwar wieder gedruckt, nicht aber
automatisch auf eine Webseite übernommen werden, wenn nur die
Überschrift und der Kurztext zu verwenden wäre. Denn die Abbildung
der Gestaltungsformatierung auf eine Struktur erfordert im Regelfall
implizites menschliches Wissen oder ein komplexes Regelwerk (z. B.
Text in 18 pt ==> Überschrift). Deshalb ist im Sinne einer ContentVerwertung eine explizite Strukturierung des Contents unverzichtbar,
aufgrund derer dann die ausgabekanalspezifische Formatierung erfolgen kann.

Zusammenhang zwischen Formatierung
und Strukturierung

4.1.3
Dokumente früher und heute
Nach wie vor ist das Dokument der gebräuchlichste Medientyp bzw.
Multi-Media-Typ, wenn Bildinhalte darin verknüpft sind: als WinWord-, XML- oder HTML-Dokument. Dokumente seien im Folgenden im zeitlichen Wandel und den daraus resultierenden Eigenschaften auch für CRT-Systeme betrachtet.
Dokumente sind in ihrer klassischen Betrachtung durch folgende
Eigenschaften definiert:

Dokumente

• Ein Dokument ist eine Urkunde, ein Beweisstück, ein Schriftstück
oder allgemein ein Stück Papier, das Informationen enthält.
• Laut Brockhaus: „m.lat. beweisende Urkunde, eigtl. das zur Belehrung über etwas oder zur Erhellung von etwas Dienliche, zu lat. docere lehren; Urkunde, amtl. Schriftstück; Beweismittel, Beleg.“
• In den Grundlagen der Dokumentenverarbeitung (vgl. Wilhelm,
Heckmann 1996) sind Dokumente ein Bündel von Informationen,

4.1 Grundlegende Begriffe

■
■
■

201

die in der Absicht erzeugt wurden, dass sie von Menschen wahrgenommen werden. Beispiele dafür sind Reden, Filme, Bilder und
Schriftdokumente.
• In der DIN-Norm ist ein Dokument die materielle Einheit eines
Trägers bibliografischer und dokumentarischer Daten.
• Die Quellen dieser Dokumente sind dabei im Regelfall Autoren
oder Redakteure.
• Die Zielgruppe bzw. der Empfänger ist der Leser.
Wenn wir nun heutige Dokumente noch zusätzlich unter dem Aspekt der elektronischen Verfügbarkeit (vgl. Content-Begriffserläuterung) betrachten, dann können wir zusätzlich folgende Eigenschaften
nennen (vgl. Boiko 2002):
• Dokumente können zugangsgeschützt sein.
• Dokumente können interaktive Bestandteile beinhalten, etwa elektronische Formulare.
• Dokumente können automatisch be- und verarbeitbar sein, etwa in
einer Formularverarbeitung.
• Dokumente können ortskorrelierte (z. B. Texte, Bilder) oder zeitkorrelierte Inhalte wie Animationen oder Videosequenzen enthalten.
• Dokumente können abhängig oder unabhängig von anderen Dokumenten und Inhalten nutzbar sein, etwa durch verlinkte oder
eingebundene Inhalte.
• Dokumente können statische oder dynamische Inhalte integrieren,
wie dynamisch generierte Lagerbestandstabellen in einer Webseite.
• Dokumente können integrierte Funktionen beinhalten, wie elektronische Berechnungen.
• Die Quellen von Dokumenten können Autoren oder Redakteure,
aber auch Maschinen (z. B. Messgeräte, Rekorder) oder Programme (z. B. Suchmaschinen) sein.
• Die Zielgruppen bzw. die Empfänger für Dokumente können Leser,
Programme (z. B. Back-Office, Web-Crawler, Literaturdienste) oder
Maschinen sein.
• Dokumente können strukturiert oder unstrukturiert sein.
CRT-Systeme zur Verwaltung und Verwertung von Dokumenten
müssen je nach Einsatzzweck diesen unterschiedlichen Eigenschaften
und Sachverhalten gerecht werden.
Die wichtige Eigenschaft der Strukturiertheit oder Unstrukturiertheit von Dokumenten soll hier noch kurz aufgegriffen werden. Wie in
der Struktur-Begriffsdefinition erwähnt, bietet erst die Strukturierung

202

■
■
■

4 Content-Related-Technologien

die Möglichkeit, eine Ordnungsbeziehung von Inhaltsbestandteilen
oder Segmenten (z. B. einzelne Textbereiche) zu einem Ganzen (z. B. zu
einem Fachartikel) herzustellen. Innerhalb eines Zeitungsartikels etwa
wäre eine solche Strukturierung über die Auszeichnung der Überschrift,
der Kurzbeschreibung, des eigentlichen langen Artikeltextes, des Autors
und des Erscheinungsjahres mit XML-Tags möglich (vgl. Rothfuss, Ried
2001). Im Sinne einer Verwertung von Content können jetzt intelligente
Systeme auf diese Bestandteile und Segmente zugreifen und sie in unterschiedlichen Kommunikations- und Informationsmittel sowohl für
Print als auch online zusammenführen (Aggregation) und verwerten.
Strukturiertheit ist somit die Voraussetzung für eine Content-Verwertung. Wir werden diesen Aspekt nochmals im Kap. 4.2.2 aufgreifen.

4.1.4
Geschäftsprozesse und Workflow
Eine zunehmende Bedeutung im Bereich der Content-RelatedTechnologien erfahren alle logistischen Abläufe um den Content
selbst. Zur Content-Logistik zählt die Steuerung der Freigaben von
Webseiten ebenso wie die Weiterleitung von Dokumenten in Unternehmen. Im Kontext der Steuerung und Kontrolle von Abläufen muss
der Begriff „Geschäftsprozess“ herausgehoben werden.
Ein Geschäftsprozess besteht aus einer Anzahl von Aktivitäten und
Tätigkeiten, die in einer definierten Reihenfolge zur Erreichung eines
definierten Zieles durch Personen oder Maschinen ausgeführt werden
müssen. Der Geschäftsprozess hat einen definierten Start- und Endpunkt (vgl. Jablonski, Böhm, Schulze 1997).
Der Begriff Workflow bezeichnet die informationstechnische Umsetzung eines Geschäftsprozesses. Der Workflow beschreibt dabei die
funktionelle Zerlegung der einzelnen Aufgaben eines Geschäftsprozesses. Workflow-Management-Systeme (WfMS) bezeichnen Informationssysteme, die den Workflow und damit stark strukturierte Prozesse unterstützen, die im Idealfall immer wieder in der gleichen oder
ähnlichen Form ablaufen. Ein Prozess im Kontext dieses WorkflowManagements ist ein Vorgang gemäß einer formalen Beschreibung,
die eine automatisierte informationstechnische Bearbeitung ermöglicht (vgl. Jablonski, Böhm, Schulze 1997).
Ein einfaches Beispiel ist die Steuerung und Kontrolle der Freigabe
von Webseiten. Innerhalb solch eines vereinfachten Ablaufes wartet
das System auf das Setzen des Zustandes „Zur Freigabe“ einer Webseite. Wird dieser Zustand gesetzt, wird der Freigabe-Verantwortliche
automatisch per E-Mail benachrichtigt. Die Freigabe selbst müsste
natürlich von der betreffenden Person durchgeführt werden und kann
in einem Zustand „Freigabe abgelehnt“ oder aber „Freigabe erteilt“

4.1 Grundlegende Begriffe

Geschäftsprozess

Workflow

■
■
■

203

resultieren, der vom Verantwortlichen manuell gesetzt wurde. Auch
jetzt könnte wiederum ein Automatismus innerhalb des Ablaufes
greifen, der weitere Aktionen aufgrund des neuen Zustandes zur Folge
hätte.
Im Kontext der Content-Related-Technologien wird Content zunehmend in Beziehung zum Geschäftsprozess betrachtet. Diese Beziehung und die daraus resultierenden Anforderungen werden in einem
späteren Kapitel zur Steuerung und Kontrolle von Content-Workflows
detaillierter besprochen.

4.2
Nutzenbetrachtungen
4.2.1
Primäre Vorteile

Mehrfachverwertung

Funktionalitätsgewinn

204

■
■
■

Dieses Kapitel stellt die wesentlichen gemeinsamen Vorteile von Content-Related-Technologien dar, spezialisierte Systeme können noch
weitere Vorteile in ihrem jeweiligen Einsatzgebiet aufweisen. Zu diesen Vorteilen gehören (vgl. Kretzschmar, Dreyer 2003; Büchner
(Hrsg.), Traub, Zahradka, Zschau 2001):
Mehrfachverwertung: Jeder Content besitzt einen Wert (vgl. Begriffserklärung Asset), der sich aus unterschiedlichen Betrachtungsweisen ableitet. Die mehrfache Nutzung identischer, medienneutral vorgehaltener Inhalte in unterschiedlichen Verwendungen, sowohl in
unterschiedlichen Produkten als auch unterschiedlichen Ausgabekanälen (Cross-Media-Publishing), liegt nahe (vgl. Fritsche 2001). Daraus
resultieren Effekte, wie Kostenreduktion aufgrund „verhinderter“
Neuproduktion von Inhalten, Qualitätssicherung durch Verwendung
bereits geprüfter Inhalte, Rationalisierungseffekte durch Nutzung
desselben Inhalts für unterschiedliche Ausgabekanäle, Verhinderung
redundanter Informationsspeicherung etc.
Funktionalitätsgewinn: CRT-Systeme ermöglichen eine rationellere
Erfassung, Beschaffung, Verwaltung und Verwertung von Content.
Sie ergänzen ihn durch Strukturierungsinformationen und bieten
optimierte Funktionalitäten zum Wiederauffinden des Contents. Die
optimierte datenbankgestützte Ablage der Inhalte führt neben dem
zentralen Zugriff auf Content auch gleichzeitig zur Reduzierung einer
mehrfachen gleichen Datenhaltung (Redundanz), etwa durch ein integriertes Versionsmanagement.

4 Content-Related-Technologien

Effizienzsteigerung: Der Einsatz solcher CRT-Systeme ermöglicht
generelle Effizienzsteigerungen:

Effizienzsteigerung

• Strukturierte Inhalte können direkt bei der Erfassung generiert
werden (Siehe bei redaktioneller Erfassung in Kap. 4.4.2).
• Schnellere und sichere Aktualisierung von Inhalten durch Automatismen in der Content-Integration.
• Vereinfachte Integration unterschiedlichster Content-Quellen,
(z. B. Agenturnachrichten) – Auf das Stichwort Content-Syndication werden wir in Kap. 4.4.2 eingehen.
• Vereinfachtes und für unterschiedliche Verwendungen und Ausgabekanäle mögliches Publizieren durch die Trennung von Inhalt,
Struktur und Gestaltung.
• Die mögliche Kompetenz- und Aufgabentrennung (z. B. Redaktion,
Gestaltung) in Verbindung mit dezentralen Pflegemöglichkeiten
gewährleistet eine bessere Ressourcennutzung und kann eine Unabhängigkeit von externen Dienstleistern sowie die Verbesserung
der Zusammenarbeit schaffen.
• Die schnellere und einheitlichere Unternehmens-kommunikation
(Time-To-Market) wird durch die qualitätssichere und effizientere
Steuerung und Kontrolle von Abläufen herbeigeführt (vgl. Begriffserklärungen Geschäftsprozess und Workflow).
Synergieeffekte: CRT-Systeme schaffen durch das Vorhalten und
Zuliefern von Inhalten die Ausgangsbasis für weitere komplementäre
E-Business-Möglichkeiten wie CRM (Customer Relationship Management), E-Commerce-Systeme, Produkt-Informations-Systeme, Katalog-Management, Community-Systeme, ERP (Enterprise Resource
Planning) etc.

Synergieeffekte

4.2.2
Mehrfachverwertung von Content als Strategie
Die Mehrfachverwertung von Content spielt in Content-RelatedTechnologien eine zentrale Rolle. Wir betrachten nun die Verfolgung
einer grundlegenden Content-Strategie und die unterschiedlichen
Möglichkeiten solch einer Mehrfachverwertung.
Es gibt zwei Arten der Mehrfachverwertung von Content. Die opportunistische Mehrfachverwertung, bei der eher manuell und willkürlich Inhalte wieder verwendet werden: Ein Autor wählt ein Bild aus
einer Mediendatenbank und baut dieses in Ergänzung seines Artikeltextes in sein Layout ein. Bei der systematischen Wiederverwendung
dagegen gibt es eine klare Strategie, die besagt, welche Inhalte in wel-

4.2 Nutzenbetrachtungen

Content-Strategie

■
■
■

205

Content in ökonomischen Prozessstufen

chen Produkten für welchen Ausgabekanal in gleicher oder veränderter Form verwendet werden (vgl. Rockley 2003).
Die opportunistische Wiederverwendung kann mittels ausgereifter
Retrieval-Funktionen und der Optimierung von Beschaffungsprozessen von Content verbessert und vereinfacht werden. Im Sinne einer
höheren Automatisierung in Verbindung mit Zeit- und Kostenersparnissen steht in Content-Related-Technologien die systematische Wiederverwendung durch die Eruierung und Umsetzung einer ContentStrategie im Vordergrund. Die systematische Beantwortung von Fragen – wie „In welchen Produkten (z. B. Webseite, Handbuch, Produktdatenblatt) werden welche Inhalte (z. B. Text1, Text2, Bild1) verwendet? Welche Inhalte werden in welcher Form (z. B. genau gleich,
abgeändert etc.) und Granularität verwendet? Sind Änderungen in
Verwendungen notwendig?“ - führt zu einer Übersicht, die eine Ableitung solch einer Content-Strategie und der dafür notwendigen Strukturierungsgrade von Inhalten ermöglicht.
Die Betrachtung der grundlegenden Prozessstufen identifiziert diejenigen, in denen eine Mehrfachverwertung von Content möglich ist.
Folgende ökonomische Prozesse bei der Entstehung eines Medienproduktes werden dabei untersucht (vgl. Hess, Eggers, Schulze 2003
und Schmid 2004 und Schumann, Hess (Hrsg.) 1999):
• 1. Stufe: Erzeugung/Beschaffung der Inhalte, wie Texte, Bilder, Musikstücke oder Videos. Eine generelle Optimierungsmöglichkeit
liegt etwa in der Optimierung der Abläufe selbst und in der erreichbaren Qualität bei der Erfassung und Beschaffung der Inhalte.
• 2. Stufe: Bündelung der Inhalte zu marktgerechten Produkten. In
diesem Sinne werden etwa verschiedene Musikstücke auf einer CD
zusammengefasst, Artikel und Werbung zu einer Tageszeitung gebündelt oder es werden unterschiedliche Buchkapitel zu neuen Seminarunterlagen zusammengestellt.
• 3. Stufe: Distribution der Inhalte an die Rezipienten über den konventionellen Druck, über Datenträger, Rundfunk, Internet etc.

Mehrfachverwertung im
Bündelungsprozess

Die Mehrfachverwertung im Bündelungsprozess betrachtet Medienprodukte als Bündel publizistischer Inhalte. Digitale Inhalte sind
bei dieser Betrachtungsweise als Komponenten oder auch Bausteine
zu behandeln, die sich flexibel zu beliebigen Produkten rekombinieren
lassen. Innerhalb des Bündelungsprozesses kann man vereinfacht drei
Varianten unterscheiden (siehe Abb. 4.2):
1. Die kombinierende Bündelung von vorliegenden Inhalten, die bereits bei der Herstellung von anderen Produkten verwendet worden
sind, zu neuen Medienprodukten, wie die Bündelung ausgewählter
Fachbeiträge einer Fachzeitschrift zu einem Sonderheft.

206

■
■
■

4 Content-Related-Technologien

Abb. 4.2:
Mehrfachverwertung

2. Die versionierende Bündelung: Mittels Produktdifferenzierung für
Medien- und Informationsprodukte, die das Angebot von verschiedenen Marktsegmenten gemäß Präferenzen und Zahlungsbereitschaft beinhalten, wie die Modifikation des Leistungsumfangs, gemessen in Textlänge, Sende- oder Abspielzeit.
3. Die individuelle Bündelung als simultane Bereitstellung eines für den
jeweiligen Kunden „maßgeschneiderten“ Medienproduktes, dessen
Bündelungskonfiguration weitestgehend auf dessen Konsumbedürfnisse zielt, wie regionalspezifische Wohnungsmarktanzeigen
oder die Personalisierung von Online-Newslettern (siehe Abb. 4.2).
Die Mehrfachverwertung im Distributionsprozess, also dem Verteilen, Zuliefern und Zurverfügungstellen von Inhalten, unterteilt man
grob in:

Mehrfachverwertung im
Distributionsprozess

1. Die zeitbasierte Distribution: Hier werden von einem Medienprodukt durch Modifikation seiner zeitlichen Eigenschaft „Aktualität“
verschiedene Angebotsformen abgeleitet, die dann innerhalb des
gleichen Mediums ausgewertet werden, wie aktuelle Nachrichtenartikel, deren Konsum zeitgleich oder zeitversetzt erfolgt. Je nachdem, ob man die Meldung aktuell bezieht oder zeitversetzt, wird
der Preis variiert.
2. Die mehrkanalbasierte Distribution: Hier werden identische Medieninhalte für verschiedene Medien ausgewertet, etwa die gleichzeitige Verwertung von Fachartikeln auf CD-ROM und im Internet.

4.2 Nutzenbetrachtungen

■
■
■

207

3. Die syndikationsbasierte Distribution: Ein Medienprodukt wird an
mindestens einen wirtschaftlich eigenverantwortlich handelnden
Distributor vertrieben, der es gegenüber den Endkunden folgeverwertet, etwa der elektronische Abgleich (Syndikation) von Nachrichten zwischen Nachrichtenagenturen und Zeitungsverlagen.
Um es an dieser Stelle nochmals zu wiederholen: Die grundlegende
Voraussetzung für die Mehrfachverwertung von Content sind definiert strukturierte Inhalte! Der Strukturierungsgrad hängt zum einen
von der jeweils notwendigen Content-Strategie (siehe oben) ab und
zum anderen von den Möglichkeiten der Strukturierung des jeweiligen
Medientyps. So können in Texten und Dokumenten viel höhere inhaltliche Strukturierungsgrade erreicht werden, wie in Bildern, Video- und
Audiosequenzen, deren Strukturierung sich vorrangig auf hinzugefügte Metadaten (z. B. IPTC-Daten in Bildern) beschränkt.

4.2.3
Wirtschaftliche Überlegungen

TCO-Betrachtung

Wirtschaftliche Überlegungen im Bereich der Content-Related- Technologien müssen immer die Gesamtkosten (Total Cost of Ownership TCO) betrachten, also sowohl die einmaligen als auch die jährlichen
Kosten im gesamten Lebenszyklus eines Produktes sowie die entsprechende Erlösseite (vgl. Donovan 2001).
Folgende grundlegende Kostenblöcke der TCO eines CRT-Systems
entstehen:
• Lizenzkosten für Hard- und Software (z. B. Content-ManagementSystem, Datenbank-Software, Betriebssysteme, Server-Hardware
etc.)
• Eventuelle Migrationskosten für das bestehende Content-, Metadaten-, Berechtigungs-, Workflow- und Rendering-/Templating-Modell sowie gegebenenfalls der bereits bestehenden IT-Infrastruktur
• Implementierungskosten, etwa für den Aufbau eines Berechtigungsmodells, das Terminologie-Management, das Workflow- und
Metadatenmodell, ein flaches oder hierarchisches Ordnungsschema, die Template- und Pflegemasken-Entwicklung
• Einführungskosten (z. B. Schulung und Training etc.)
• Administrations-, Wartungs- und Instandhaltungskosten für Hardund Software

208

■
■
■

4 Content-Related-Technologien

Auf der Erlösseite können folgende primäre Faktoren aufgezählt
werden (vgl. Christ 2003):
• Erlöse mittels Kostenreduktion durch den Einsatz des CRTSystems
• Erlöse durch Synergieeffekte (verbesserte Prozess- und Qualitätssicherung, Synergieeffekte durch Nutzung als Basisplattform für
E-Business-Technologien etc.)
• Erlöse durch neue Business-Modelle: Werbung, Cross-Sales (z. B.
Abonnenten einer Print-Anzeige können eine Online-Anzeige kostengünstiger schalten), Pay-per-Access (z. B. Provisionierung bei
Kaufvermittlung über den Content-Zugang), Mehrfachverwertung
von Inhalten (z. B. Content-Syndication, Mehrkanalstrategien) etc.

4.3
Überblick über CRT-Systeme
In diesem Kapitel soll ein grundlegender Überblick über die unterschiedlichen CRT-Systeme vermittelt werden. Während die klare Abgrenzung der einzelnen Systeme immer unschärfer wird, steigt die
Anzahl der Systembezeichnungen. Zunehmend entstehen neue Bezeichnungen auch aus reinen Marketinggründen, etwa zur Differenzierung und Positionierung des eigenen alten Produktes. Die nachfolgende Aufzählung ist daher nicht vollständig und orientiert sich an
der Begriffswelt der AIIM (Association for Information and Image
Management). Die AIIM war ursprünglich eine internationale Vereinigung von Herstellern und Anwendern von Informations- und Dokument-Management-Systemen und formiert jetzt unter dem Label
„The ECM Association“ mit dem Fokus auf die Entwicklung und Pflege von Standards im Umfeld der Content-Related-Technologien.
Bilddatenbanken oder Image-Management-Systeme (IMS) stellen
die einfachste Variante unter den Mediendatenbanken dar und dienen
zur Verwaltung von Bildern, Fotos, Grafiken etc. Im Regelfall verfügen
Sie auch über eine Verwaltung für Metadaten-Standardformate wie
IPTC- oder EXIF-Header.
Medien-Datenbank- oder Media-Asset-Management-Systeme (MAM)
dienen zur verwertungsgerechten Verwaltung digitaler Medien unterschiedlichster Medientypen (z. B. Bild, Video, Audio). Sie bieten elementare Werkzeuge zur Strukturierung, Archivierung und zum Retrieval von Assets.
Records-Management-Systeme (RMS) werden vorwiegend zur Erfüllung gesetzlicher Vorschriften (z. B. GDPdU, Sarbanes-Oxley) und

4.3 Überblick über CRT-Systeme

Bilddatenbanken

Media-Asset-Management-/
Medien-Datenbank-Systeme

Records-Management- Systeme
(RMS)

■
■
■

209

Dokumenten-Management-Systeme
(DMS)

Medien-Logistik-Systeme

Web-Content-Management-Systeme
(WCMS)

Content-Management-Systeme
(CMS)

Redaktionssysteme

Autorensysteme

Katalog-Management- /
Produkt-Informations-Systeme

Portal-Systeme

210

■
■
■

zur revisionssicheren und nachprüfbaren digitalen Speicherung von
Unternehmensunterlagen eingesetzt (z. B. Inhaltssammlung, Inhaltsverwaltung und -bereitstellung).
Dokumenten-Management-Systeme (DMS) werden bei der Verwaltung von Dokumenten während ihres gesamten Lebenszyklus eingesetzt. Dazu zählt das Erfassen, Archivieren, Verwalten, Weiterleiten
und Archivieren von Dokumenten. Beim Erfassen wird auch der Bereich des Scannens und der Übernahme der gescannten Dokumente in
lesbare Informationen (z. B. Optical Character Recognition – OCR) zum
DMS gezählt.
Medien-Logistik-Systeme dienen der Verwaltung von digitalen Produktions- und Beschaffungsaufträgen und den ihnen zugrunde liegenden Medien. Hier stehen logistische und Workflow-Funktionen
bei der Beschaffung und Verteilung von Content im Vordergrund.
Web-Content-Management-Systeme (WCMS) dienen zur Administration von größeren Websites. Hier stehen insbesondere die komfortable redaktionelle Bearbeitung von Web-Inhalten durch mehrere
Personen und die Verwaltung der internetspezifisch aufbereiteten
Medien im Vordergrund.
Content-Management-Systeme (CMS), ein früheres Synonym für
WCMS, werden heute zur Verwaltung aller Medien- und Contentarten
eingesetzt und versuchen alle Ausgabekanäle abzudecken. Häufig
integriert ein CMS ergänzende DMS-Funktionalitäten und setzt direkt
auf ein MAM-System auf. Zusätzlich bietet ein CMS auch Funktionen
zur Erstellung von Inhalten sowie zur automatisierten Präsentation
und Distribution von Inhalten.
Klassische Redaktionssysteme sind Systeme, die an die spezifischen
Anforderungen der Buch-, Zeitungs- und Zeitschriftenproduktion angepasst sind. Da viele Verlage zunehmend crossmedial produzieren,
nähern sich Redaktions- und CM-Systeme immer weiter an.
Autorensysteme für Multimedia unterstützen die Produktion komplexer Rich-Media-Anwendungen (z. B. Video, Audio, Web) durch
eine effiziente Verwaltung mono- und multimedialer Komponenten
(auch unter dem Aspekt der Mehrfachverwertung) und die Bereitstellung entsprechender Editier- und Bearbeitungsfunktionen.
Katalog-Management-Systeme und Produkt-Informations-Systeme
verbinden Produkt- und Marketing-Datenbanken über einen gemeinsamen Datenbestand. So können Produktkataloge mit umfangreichem
und hochvariablem Datenbestand aus technischen und werblichen
Informationen erstellt werden.
Portal-Systeme werden ähnlich wie WCM-Systeme zur kollaborativen Pflege von Internetpräsenzen und deren Personalisierung sowie
zur Integration von unterschiedlichen Content-Quellen und Prozessen eingesetzt. Darüber hinaus bieten sie Funktionen zur Steue-

4 Content-Related-Technologien

rung eines kommunikativen Workflows im Sinne eines Community
Management. Zuweilen rücken dabei Darstellungsfunktionen zugunsten einer einfacheren Handhabung (ohne Einarbeitungsaufwand) und
einer schnellen Aktualisierbarkeit von Inhalten in den Hintergrund.
Enterprise-Content-Management-Systeme (ECMS) repräsentieren
eine Strömung, die alle bestehenden CRT-Systeme integrieren will.
Dabei werden Funktionen aus der traditionellen Archivwelt, dem
Dokumenten- und dem Workflow-Management an die Anforderungen eines Content-Management-Systems angepasst. Dadurch können
web-basierte Komponenten mit herkömmlichen Produkten verbunden werden. Mehr dazu später.
Business-Process-Management-Systeme (BPM) versuchen, alle materiellen und kommunikativen Prozesse eines Unternehmens mit
Hilfe der IT abzubilden, zu organisieren und zu optimieren. Dazu
zählt etwa die automatisierte Beschaffung von Gütern (Procurement),
die Verringerung von Durchlaufzeiten, die Bestandsverwaltung und
die transparente Darstellung aller Prozesse im Sinne eines Management-Information-Systems (MIS).
Knowledge-Management-Systeme (KMS) dienen zur intelligenten
Verknüpfung von Informationen mit vorhandenen Erfahrungen und
Kenntnissen und somit der Verwaltung von Wissensinhalten. Das
Wissensmanagement gilt heute als wichtigste Schlüsseltechnologie des
Informationszeitalters: Die Zukunftsfähigkeit von Organisationen
jeder Art und Größenordnung hängt davon ab, wie gut sie ihre vorhandenen Wissensressourcen nutzen können.

Enterprise-Content-ManagementSysteme (ECMS)

Business-Process-Management-Systeme
(BPM)

Knowledge-Management-Systeme
(KMS)

4.4
Technische Bausteine
4.4.1
Schematische Systemarchitektur
Eine schematische Systemarchitektur, die sich an dem ECM-Modell
des AIIM (Association for Information and Image Management) orientiert, besteht aus folgenden Bereichen (siehe Abb. 4.3):
•
•
•
•
•

Capture: Erfassung und Beschaffung
Store: Ablage und Suche
Manage: Verwaltung, Aggregation und Strukturierung
Deliver: Bereitstellung, Anzeige und Publikation
Preserve: Erhaltung und Archivierung

4.4 Technische Bausteine

■
■
■

211

Abb. 4.3:
Enterprise-Content-ManagementModell

Sowie den Bereichen:
•
•
•
•
•

Dokumenten-Management (DM)
Collaboration (Collab) (siehe Kap. 4.4.2)
Web-Content-Management (WCM)
Records-Management (RM)
Workflow- (WF) und Business-Process-Management (BPM)

Bei der folgenden Besprechung von Content-Related-Technologien
werden wir bewusst nicht einzelne Systeme tiefer gehend erläutern.
Vielmehr wollen wir technologische Bausteine definieren, die im Kontext der CRT-Systeme vorrangig unter dem ökonomischen Gesichtspunkt einer Content-Strategie (vgl. Kap. 4.2.2) zum Einsatz kommen
und auf deren Detailbesprechung oftmals innerhalb dieses Buches referenziert werden kann. Deshalb sollen folgende zu der schematischen
Systemarchitektur korrelierenden Bausteine besprochen werden:
•
•
•
•
•
•

212

■
■
■

Erfassung, Beschaffung und Validierung von Content
Ablage von Content
Strukturierung von Content
Retrieval und Anzeige von Content
Beziehungsmodelle für Content
Steuerung und Kontrolle von Content-Workflows

4 Content-Related-Technologien

•
•
•
•
•

Content-Aggregation, -Delivery und -Publishing
Personalisierung von Content
Archivierung und Revisionssicherheit
Integration für Anwender, Content und Prozesse
Administration

4.4.2
Erfassung, Beschaffung und Validierung
von Content
Die getroffene Content-Strategie (vgl. Kap. 4.2.2) entscheidet maßgeblich über den notwendigen Granularitäts- oder Strukturierungsgrad
der Inhalte und somit über die Erfassungs- und Ablageform in einem
CRT-System. Zum Beispiel würde in einem Media-AssetManagement-System (MAM) zur Verwaltung von Bilddateien oder in
einem Dokumenten-Management-System (DMS) zur reinen Verwaltung von Berichtsdokumenten keine redaktionelle Erfassung stattfinden, allenfalls eine Ergänzung von Metadaten. Die häufigste Art der
Erfassung ist hier ein Check-In-Vorgang von kompletten Mediendateien. Bei einem Content-Management-System (CMS) zur Verwaltung
und Verwertung von Fachartikeln und -bestandteilen in einem Verlagsunternehmen hingegen wäre die redaktionelle Erfassung und
Strukturierung dieser Inhalte mit XML-Tags zu irgendeinem Zeitpunkt des Erstellungs- oder Nachbearbeitungsprozesses eine grundlegende Voraussetzung. Das zunehmende, gemeinschaftliche Erzeugen
von Inhalten und die unternehmensübergreifende Zusammenarbeit
verlangt zusätzlich nach effizienten Werkzeugen, um diese Collaboration zu begleiten und zu optimieren, dazu zählen etwa Diskussionsforen, Video-Conferencing, Container für projektbezogene Inhaltsablage, Groupware-Werkzeuge etc. (siehe Kap. 3). Im Folgenden sollen
grundlegende Möglichkeiten der Beschaffung und Erfassung von Content besprochen werden.
Ein redaktioneller Prozess erfasst die Inhalte unter Berücksichtigung von Regeln zur Wahrung der strukturellen Integrität, etwa über
webbasierte Pflegemasken, mittels Auszeichnungsmechanismen in
XML-Editoren oder über Autorensysteme zur Manipulation von Video- und Audiodaten (siehe Kap. 1). Inhalte sollen dabei nicht nur
über die einheitliche Medientypebene als Ganzes (z. B. als ganzes Dokument in WinWord), sondern in jeder beliebigen Ebene, etwa mit
Auszeichnung von Überschrift und weiteren Textbestandteilen, bearbeitet werden können. Durch die Ablage der strukturierten Inhalte
kann ein Zusammenführen der Inhalte im Publikationsbereich in
unterschiedliche Verwendungsarten und Ausgabekanäle erfolgen. Die

4.4 Technische Bausteine

Redaktionelle Erfassung

■
■
■

213

Unterstützung redaktioneller Prozesse erlaubt nicht nur die Erfassung
strukturierter Inhalte, sondern bietet neben einer Vielzahl von Vorteilen auch eine konsequente Aufgaben- und Kompetenztrennung. Die
Möglichkeit, Inhalte getrennt vom eigentlichen Layout und von der
Gestaltung zu erzeugen, erlaubt dem Autor oder Redakteur, dies ohne
spezielle Formatierungskenntnisse zu tun.
Im Dokumentenbereich, etwa in Verlagsunternehmen, unterscheidet man generell zwei verschiedene Formen des redaktionellen Ablaufs: Zum einen „Layout vor Redaktion (Text)“, Bei dieser Arbeitsweise wird zuerst das gestalterische Layout gefertigt und nachträglich
die Inhalte dafür erzeugt, zum anderen „Redaktion (Text) vor Layout“
mit der umgekehrten Vorgehensweise. Die Ausbringung der Inhalte in
der jeweiligen Publikationsform erfolgt dann mit verschiedenen Mechanismen, wie dem häufigen Web-Templating, bei dem die Inhalte
oder Inhaltssegmente dann in „Platzhaltern“ innerhalb einer HTMLVorlage eingebracht werden. Dieses Templating-Verfahren wird zumeist in Web-Content-Management-Systemen (WCMS) eingesetzt
und wird im Kap. 4.4.8.1 näher betrachtet.
Eine technologische Umsetzung sowohl der Erfassung wie auch der
Validierung erfolgt durch:
• Native und webbasierte Pflegemasken mit nachfolgender Evaluierung der Eingaben auf der Basis von Regelwerken, etwa als HTMLMaske mit nachfolgender „festverdrahteter“ Überprüfung der Eingaben im Verarbeitungssystem selbst oder Überprüfung der erfassten Inhalte anhand einer DTD (Document Type Definition) oder
eines XML-Schemas (vgl. zu XML: Rothfuss, Ried 2001).
• Direkte Erfassung in Editoren mit gleichzeitiger oder nachfolgender
Überprüfung der Eingaben auf der Basis eines definierten Regelwerkes, wie der Erfassung in einem XML-Editor mit gleichzeitiger
Prüfung der Eingaben anhand einer DTD (Document Type Definition) oder eines XML-Schemas.
Check-In/Check-Out

214

■
■
■

Ein Check-In-Vorgang ist ein Verfahren, um Mediendateien in ein
CRT-Ablagesystem zu übernehmen. Dieser Check-In-Vorgang wird im
Bereich der Dokumenten-Management-Systeme oft auch Archivierung
genannt, während in anderen CRT-Systemen als Archivierung die Auslagerung oder Migration von Mediendateien vom Online-System (z. B.
Festplatten-, RAID-, SAN- oder NAS-Systeme) auf externe Datenträger
bzw. -systeme bezeichnet wird. Beim Check-In-Vorgang bietet das CRTSystem in der Regel die Möglichkeit, zusätzliche Strukturinformationen
und ergänzende Informationen als Metadaten (vgl. Kap. 4.4.4) einzugeben. Ein Check-Out-Vorgang bezeichnet hingegen das „Herausnehmen“ einer Mediendatei aus dem Ablagesystem, etwa für eine externe Bearbeitung dieser Datei. Dieses „geschützte Editieren“ wird durch

4 Content-Related-Technologien

einen Sperrmechanismus mit Einsicht der Check-Out-Daten (von wem,
wann, zu welchem Zweck) der noch im Ablagesystem verbleibenden
Kopie der Mediendatei unterstützt. Beim erneuten „Einchecken“ der
bearbeitenden Mediendatei wird je nach Einstellung im Beziehungsmodell zum Beispiel eine neue Version (vgl. Kap. 4.4.6) angelegt und Historiedaten in eine Protokollierungsdatei eingetragen. Mit den Historiedaten lässt sich genau nachvollziehen, wer wann welche Mediendateien zu
welchem Zweck bearbeitet oder „entnommen“ hat.
Die Validierung von Mediendateien beim Check-In erfolgt unter
anderem durch:
• PreFlight-Werkzeuge, die vor oder beim Check-In-Vorgang die
Mediendateien auf der Basis definierter Qualitätskriterien prüfen
(z. B. Auflösung, Format und Farbraum beim Einchecken von Bildern), oder die Vollständigkeitsprüfung von Dokumenten auf referenzierte oder verlinkte Bilddateien.
• PostFlight-Werkzeuge, die nach Ablage der Inhalte zu einem definierten oder manuell gewählten Zeitpunkt eine Validierung der Inhalte
durchführen, wie die Link-Prüfung auf Konsistenz der Referenzierungen von Webseiten in einem Web-Portal (Link-Management).
• Manuelle Prüfung von eingecheckten Inhalten, z. B. durch nachträgliche Sichtung.
Enabling-Technologien und Anwendungsintegration sind spezielle
Formen einer direkten Integration von CRT-Funktionalitäten, wie
Recherche, Dokumentenzugriff (z. B. Check-Out/Read-only) oder das
„Ablegen“ von Inhalten (z. B. Check-In) in die Benutzeroberfläche der
erzeugenden Anwendungen selbst. Zum Beispiel ermöglicht die Enabling-Technologie innerhalb vieler Dokumenten-Management-Systeme (DMS), dass Dokumente direkt aus Microsoft Word in das Ablagesystem ein- und ausgecheckt werden können. Die oftmals eher
rudimentäre Anwendungsintegration ermöglicht hingegen, dass Mediendateien direkt aus dem CRT-System durch ein Anwendungsprogramm gesichtet und bearbeitet werden können. Die Validierung eingecheckter Inhalte erfolgt nach den oben beschriebenen Mechanismen.
Die Realisierung dieser Technologien kann auf unterschiedlichste
Art und Weise erfolgen:

Enabling-Technologien
Anwendungsintegration

• Plug-In-Technologien oder proprietäre API-Schnittstellen der Anwendungsprogramme selbst, wie für Adobe Indesign CS, QuarkXPress, WinWord.
• Standardisierte, oftmals plattformunabhängige Schnittstellen, wie
ODMA API (Open Document Management API) im Bereich der
Dokumenten-Management-Systeme (vgl. Götzer, Schneiderath,
Maier, Boehmelt 2004) oder die WebDAV-Schnittstelle (Web-based

4.4 Technische Bausteine

■
■
■

215

Distributed Authoring and Versioning) als Erweiterung der HTTPProtokolls und Schnittstelle zum Zugriff auf Verzeichnisstrukturen
und Mediendateien samt Metadaten, Benutzerrechten, Versionierung, Dateisystemoperationen und über das Internet für Remote
Editing (vgl. Gulbins, Seyfried, Strack-Zimmermann 2002).
• Zunehmend verfügbare Web-Service-Schnittstellen zur DiensteIntegration.
Content-Syndication

Content-Beschaffung

Neben der Erzeugung von Inhalten spielen die Syndication- oder Beschaffungs-Methoden eine wichtige Rolle als weitere Quelle von Inhalten. Content-Syndication bezeichnet die Möglichkeit, Content meist
webbasierend anderen Betreibern von Websites zur Verfügung zu stellen oder von diesen zu beziehen. Sogenannte Content-Provider stellen
dabei unterschiedliche Mechanismen zum Austausch von Content zur
Verfügung. Als Austauschformat wird zumeist XML verwendet wie bei
der Content-Syndication gemäß ICE-Standard (Information and Content Exchange) (vgl. Büchner (Hrsg.), Traub, Zahradka, Zschau 2001).
Unter Content-Beschaffung verstehen wir das Erwerben von Inhalten
aus Content-Quellen i.d.R. anderer Urheber. Eine nähere Betrachtung
von Beschaffungsprozessen auch bezüglich des Verwaltens von Medien-Rechteverhältnissen (oft auch als Intellectual-Property-Management (IPM) bezeichnet) etwa in Verlagen würde den Rahmen dieses
Buchbeitrages sprengen. Anbei einige Beispiele von unterschiedlichen
Content-Quellen ohne den eigentlichen Erzeugungsprozess:
• Lizenziertes Content-Broking mit Hilfe von Content-Maklern oder
-Vermittlern und die Content-Syndication zum Austausch von Inhalten.
• Content aus nutzergenerierten Quellen wie Community-Systemen,
Foren, Chats, Schwarze Bretter, Newsgroups, E-Mail, SMS, Weblogs
etc.
• Content aus internen/externen Backend-Systemen wie Kundendaten, Preislisten (intern) und Produktinformationen oder Auftragsdaten von Geschäftspartnern (extern).
• Eine etwas differenzierte Bedeutung für die Content-Beschaffung
haben Werbequellen wie Bannerwerbung etc.

Automatisierte
Content-Generierung

216

■
■
■

Unter der automatisierten Content-Generierung werden alle Methoden zusammengefasst, die neue Inhalte aufgrund einer Transformation (z. B. durch Umwandlung) oder Konvertierung (z. B. durch
Scannen) von analogen Dokumenten in digitale Bilder oder Dokumente generieren, ebenso alle Methoden, die aufgrund bestehender
Inhalte automatisiert neue Inhalte erzeugen. Hierzu einige Beispiele:

4 Content-Related-Technologien

• Umwandlung von analogen Vorlagen in digitale Vorlagen durch
Scan-Vorgänge (Scanning/Imaging).
• Umwandlung eines digitalen Bitmap-Bildes (NCI = Non Coded
Information) eines beleghaften Dokumentes in ein digitales Dokument (CI = Coded Information) durch Texterkennungs- und
Volltext-Indizierungs-Verfahren, z. B. OCR/ICR (Optical Character
Recognition und Intelligent Character Recognition).
• Unterstützung des COLD-Verfahrens (Computer Output to Laser
Disk) in DMS. Bei diesem Verfahren zur Massendatenarchivierung
werden Daten (meist von Großrechner-Systemen (Hosts)) entgegengenommen, in die Bestandteile Indexdaten und Dokumentoder Formulardaten getrennt und in Ablagesystemen oder auf optischen Medien gespeichert.
• Automatische Erstellung von Inhaltsverzeichnissen in Publikationen.
• Automatische Index- und Glossarerstellung in Dokumenten.
• Erstellung von Linklisten referenzierter bzw. verknüpfter Inhalte.
• Erstellung von Sitemaps, etwa für Websites.
• Unterstützung des Aufbaus von Navigationsstrukturen, wie Menü-,
Teaser- und Rubriken-Generierung in Websites.
• Unterstützung der Content-Erstellung durch Rechtschreibkorrekturen und Thesauren, etwa bei der Erstellung von Fachartikeln.
• Erstellung fremdsprachlicher Übersetzungen von Inhalten durch
Translation-Memory-Systeme (TMS). Dabei werden eindeutig gekennzeichnete Inhalte über einen XML-Export aus dem CRTSystem einem datenbankgestützten Übersetzungssystem zugeliefert. Dieses TMS führt eine automatische oder halbautomatische
Übersetzung der Inhalte durch und stellt dem CRT-System das
übersetzte XML-Dokument wieder zur Verfügung. Beim Übersetzungsprozess werden bekannte und neu übersetzte Wort- und Satzfolgen in der Datenbank zur späteren Wiederverwendung bei Übersetzungen gespeichert.

4.4.3
Ablage von Content
Ein Ablagesystem für Content wird Content-Repository genannt und
kann unterschiedlich realisiert sein:

Content-Repository

• Ablage von Content im Dateisystem: Nachteile sind dabei geringqualifizierte Suchfunktionalitäten; wird deshalb selten eingesetzt.
• Ablage in einem Datenbanksystem: Etwa in relationalen oder XMLDatenbanken. Diese Form eignet sich dann für die Ablage, wenn

4.4 Technische Bausteine

■
■
■

217

der Content nur ein niedriges Datenvolumen beansprucht, wie bei
Web-Anwendungen oder im Dokumenten-Management.
• Ablage in einem hybriden System aus Datenbank- und Dateisystem: Diese duale Verwaltung von Inhalten eignet sich dann, wenn
es neben Textinhalten auch große Mediendateien wie Bilddateien
für Print-Publikationen oder Videodateien zu verwalten gilt. Zwar
erlauben Datenbanksysteme große Datenmengen in Form von
BLOBs (Binary Large Objects für Bilder, Video, Audio) oder CLOBs
(Character Large Objects für Text, HTML, XML) abzulegen. Allerdings hat diese Form der Ablage Nachteile bei der Auslagerung der
Mediendatei-Bestände vom Online-Datenspeicher auf externe Datenträger im Sinne einer Migration, bei der direkten Bearbeitung
von Mediendateien über das CRT-System sowie bei Worst-CaseSzenarios, wenn die Produktionssicherheit mit Mediendateien auch
ohne Datenbank gesichert sein muss, wie bei Verlagen, Werbeagenturen oder Medienbetrieben.

Medienneutrale Datenhaltung

Nahezu alle CRT-Systeme besitzen in irgendeiner Form ein Content-Repository zur Ablage von Content mit unterschiedlichem Strukturierungsgrad. So hat fast jedes Web-Content-Management-System
eine Art Bilddatenbank zur Verwaltung von oftmals gering aufgelösten Bildern integriert. Eine detailliertere Besprechung der Ablage von
Medienobjekten in Datenbanken erfolgt im Kapitel „Medienobjekte in
Datenbanken“ in Teil 3 des Kompendiums.
In Zusammenhang von Content-Repositories wird sehr oft von
medienneutraler Datenhaltung gesprochen. Die medienneutrale Datenhaltung bezeichnet die Ablage von Content in der Art, dass deren
Verwendung für unterschiedliche Medienarten und Medienprodukte
gewährleistet bleibt. Diese Form der Datenhaltung betrachtet in der
Praxis vorrangig zwei Medientypen:
• Medientyp Text: Durch Ablage von Dokumenten und Texten im
XML-Format besitzen diese eine Trennung von Struktur, Inhalt
und Layout und somit die Voraussetzung einer medienneutralen
Datenhaltung.
• Medientyp Bild: Die Ablage von Bildern in einem medienneutralen
Farbraum mit einer hohen Auflösung und ohne verlustbehaftete
Kompression bildet die Voraussetzung zur medienneutralen Datenhaltung. Zum Beispiel könnten Bilder mit mindestens 300 dpi
und im CIELAB-Farbraum mit entsprechenden ICC-Profilen abgelegt werden (vgl. Gierling 2004 und Dreyer 2004). So ist bei richtiger
Anwendung gewährleistet, dass bei Ausgaben sowohl für Print als
auch für Web die Farbabweichungen (bedingt durch die unterschiedlich großen und verschobenen Farbräume der einzelnen

218

■
■
■

4 Content-Related-Technologien

Ausgabekanäle) nur gering oder nicht vorhanden sind. Für die Datenkompression sollte tunlichst ein verlustfreies Verfahren (TiffLZW) eingesetzt werden. Unter den verlustbehafteten Verfahren
bietet JPEG2000 (ISO 15444) bei gleicher Kompressionsrate eine
deutlich bessere Qualität gegenüber dem betagten JPEG!
Die zunehmende Standardisierung im Umfeld der ContentRelated-Technologien führte im Bereich der Content-Repository zu
dem Standard JSR-170 (Java Specification Request 170), der eine einheitliche Schnittstelle für den Zugriff auf Content-Repositories spezifiziert. Unterschiedliche Level dieser Schnittstelle ermöglichen nicht
nur rudimentäre Zugriffe auf die hierarchisch organisierten ContentElemente im Content-Repository, sondern auch komplexe Operationen inklusive Versionierung, Transaktions-Management, Monitoring
etc. (vgl. Eisele 2006).

4.4.4
Strukturierung von Content
Über die Aufgabe und Funktion der Strukturierung von Content innerhalb einer Content-Strategie haben wir bereits in einem vorigen
Kapitel berichtet. Das folgende Kapitel erklärt die grundlegenden
Möglichkeiten und Werkzeuge in CRT-Systemen. Zu diesen grundlegenden Einteilungen gehören folgende Strukturierungsmöglichkeiten
(vgl. Boiko 2002; Kretzschmar, Dreyer 2003):
Strukturierung der internen „Binnenstruktur“ von Content sowohl
des gleichen Medientyps als auch eines Multimedia-Objektes mit unterschiedlichen Medientypen: Das bedeutet eine Fragmentierung des
inneren Aufbaus des Contents selbst, wie die beim redaktionellen
Erfassungsprozess erzeugte XML-Struktur eines Dokumentes.
Strukturierung der Navigation und des Zugriffes, also die Einordnung von Content in ein Ordnungssystem: Hierarchien und Taxonomien, Indexe, Link-Listen. Hierarchien und Taxonomien (griechisch
Taxon = Gruppe, pl. Taxa) bilden sogenannte Ordnungsschemata. Sie
erlauben die Assoziation mit existierenden Strukturen (z. B. Warengruppen) und bieten die Möglichkeit eines „geführten“ Navigierens,
im Regelfall über mehrere Ebenen (z. B. Themenbäume). Die Mehrfachzuordnung desselben Inhalts in unterschiedliche Hierarchien
ermöglicht die Abbildung von verschiedenen Sichtweisen auf denselben Inhalt, wie thematische Differenzierungen, Schlagwort-Bäume etc.
In Ergänzung zum manuellen „händischen“ Zuordnen eines Inhalts in
eine Hierarchie versuchen automatische Klassifikationssysteme nach
einer Lernphase mit speziellen „Lerndokumenten“, die später eingestellten Dokumente durch unterschiedliche Verfahren aus den Berei-

4.4 Technische Bausteine

Fragmentierung

Hierarchien und Taxonomien

■
■
■

219

Metadaten

Inkludierung und Referenzierung

Organisatorische Einordnungen

chen der Statistik, Bewertung und Linguistik automatisch einzuordnen (vgl. Semio 2000; Wittkewitz 2001).
Strukturierung über Metadaten („Daten über Daten“), also ergänzende Informationen zum Content-Inhalt, wie Erstellungsdatum,
Autor, Bildbeschreibung etc.: Grundlage bilden sogenannte Metadatenmodelle, die die formale Beschreibung der Metadaten inklusive
Typisierung, Vererbungsmechanismen, Gültigkeiten und ihren Beziehungen untereinander definieren. Den Vorgang des Hinzufügens von
Metadaten in CRT-Systemen bezeichnet man als Verschlagwortung
oder Attributisierung. Neben dem manuellen Hinzufügen dieser Metadaten in speziellen Eingabenmasken kann die Verschlagwortung
auch durch automatisches Auslesen von Zusatzinformationen, wie
beiliegende XML-, EXCEL-, ASCII-Dateien, oder im Inhalt integrierte
(„embedded“) Informationen erfolgen, wie z. B. IPTC-Daten in Bilddateien. Im Umfeld verschiedener Anwendungen und Medientypen
gibt es unterschiedliche Metadatenstandards wie DublinCore, XMP,
IPTC, EXIF, SCROM etc. (vgl. Kretzschmar, Dreyer 2003).
Strukturierung der Inkludierung und Referenzierung im ContentObjekt: Welche anderen Content-Objekte sind in welcher Ausprägung
(z. B. identisch als Version, verändert als Variante; siehe auch
Kap. 4.4.6) enthalten oder werden in dem jeweiligen Content referenziert (z. B. Bild-Verwendungsnachweise in Publikationen)?
Strukturierung der Organisation, also Strukturierung für die eigentliche Verwendung oder organisatorische Einordnungen des Content-Objekts, etwa für eine Fachzeitschriften-Ausgabe oder für eine
Firma oder einen Mandanten.

4.4.5
Retrieval und Anzeige von Content

Generelle Suchfunktionen

220

■
■
■

Retrieval-Funktionen dienen dem Auffinden von Inhalten in CRTSystemen. Dabei unterscheidet man folgende Funktionen (siehe auch
das Kapitel „Medienobjekte in Datenbanken“ in Teil 3 des Kompendiums):
Generelle Suchfunktionen, die das Suchen vorrangig in den Strukturierungsdaten (z. B. Suche in Metadaten oder in hierarchischen Gruppen) und in den Beziehungsdaten (z. B. Suche nach aktueller Version)
erlauben. Generelle Suchabfragen können durch boolsche Operatoren
(z. B. und, oder, und nicht, oder nicht) kombiniert werden. Suchabfragen müssen dabei auch allgemeine Attribute, wie „ist“, „beginnt mit“,
„enthält“, „von/bis“, „ist leer“, „Groß-/Kleinschreibung“ etc. unterstützen. Komplexere Systeme bieten weitere zusätzliche Suchmethoden, etwa aus der Linguistik. Zu den geläufigen Methoden gehören:

4 Content-Related-Technologien

• Thesaurus-gestützte Synonym-Suche: Synonyme sind unterschiedliche Begriffe mit gleicher Bedeutung (z. B. Suche nach „Auto“ findet auch „KFZ“ und „PKW“).
• „Unscharfe“, Fuzzy- oder phonetische Homonym-Suche: Homonyme sind Wörter, die genauso klingen wie ein anderes, die aber
neben einer anderen Bedeutung auch eine andere Schreibweise haben können (z. B. Suche nach Baier findet auch ähnlich klingende
Wörter wie Bayer, Beier etc.).
Media-Mining oder Content-Mining bezeichnet die Suche im Inhalt
eines jeweiligen Medien- bzw. Multimedia-Typs selbst. Die wichtigsten Suchverfahren sind:
Das Text-Mining (hier Volltextsuche) ist die wichtigste Methode der
inhaltlichen Suche und basiert auf der Möglichkeit, Texte und Dokumente so zu indexieren, dass nach dem sprachlich-semantischen Inhalt des Dokumentes gesucht werden kann (vgl. Kretzschmar, Dreyer
2003). Dabei werden Wörter und Wortfolgen aus dem eigentlichen
Dokument extrahiert: Ohne störende Formatierungsangaben und
ohne sogenannte Stoppwörter, wie „und“, „der“, „die“ etc. In „unscharfen“ Verfahren ermöglicht ein Ranking (Relevanzgrad) der
Suchergebnisse eine Darstellung von prozentualen Trefferquoten mit
Textumfeld-Auszügen, wie sie typischerweise in webbasierten Suchmaschinen (z. B. Google) verwendet werden. Für den Relevanzgrad
(Gewichtung) werden unterschiedliche Parameter herangezogen, wie
beispielsweise in einfachen Verfahren die Häufigkeit des Vorkommens eines Wortes oder eines Synonyms aus einem Thesaurus, also
einer Menge von vordefinierten Schlagwörter (vgl. Schäuble 1997).
Beim Image-Mining oder Content-based-Image-Retrieval werden
Bilder aufgrund des Bildinhalts suchbar gemacht. Es gibt verschiedene
Verfahren, wie die Analyse von Farbgebung, Mustern, Strukturen und
Formen vorrangig in Vektorgrafiken bis zur „vergleichenden“ oder
Ähnlichkeitssuche in Rasterbildern. Die Ähnlichkeitssuche wird am
häufigsten angewandt: Dabei erfolgt vorrangig ein Vergleich von
Farbhistogrammen unterschiedlicher Bildbereiche mit denen von
vordefinierten, bekannten oder manuell gewählten Inhalten. Farbhistogramme stellen die Häufigkeitsverteilung des Auftretens von
Referenzfarben in definierten Bildbereichen dar. Die Suche in Videos
beschränkt sich im Allgemeinen auf die Verwendung von ImageMining-Methoden in Bezug auf bestimmte Schlüsselbilder des Videos
(vgl. Meyer-Wegener 2003).
Die geläufigsten Formen zur Darstellung der Suchergebnisse und
deren Kombinationen in CRT-Systemen sind:

4.4 Technische Bausteine

Text-Mining
und Volltextsuche

Image-Mining
bzw. Image-Retrieval

■
■
■

221

• Abbildung von Baumstrukturen für die Hierarchiendarstellung.
• Darstellung von Ergebnislisten mit oder ohne Icon. Das Icon zeigt
entweder ein sehr kleines Vorschaubild oder ein Bildsymbol des
jeweiligen Datentyps der Anwendung.
• In Dia-Leuchttisch-Darstellungen werden Previews der Fundstellen
in einer Art Schachbrettmuster angezeigt. Previews zeigen niedrigaufgelöste Voransichtsbilder der gefundenen Bilddateien und
Dokumentseiten oder extrahierte Sequenzen von Video-Schlüsselbildern.
• Integrierte oder extern aufgerufene Viewerprogramme zur detaillierten Sichtung der Inhalte, wie integrierte PDF-Viewer oder Multimedia-Player für Audio und Video.

4.4.6
Beziehungsmodelle für Content

Versionen

Beziehungsmodelle definieren die Abhängigkeiten und das Verhalten
von Content-Objekten untereinander. Die wichtigsten sollen hier angeführt werden (vgl. Kretzschmar, Dreyer 2003):
Versionen: Für das Beziehungsmodell Versionen gilt, dass eine Version genau ein aus einem existierenden Ursprungsobjekt entstandenes
und ihm nachfolgendes Objekt darstellt. Das Ursprungsobjekt kann in
der neuen Version des entstandenen Objektes verändert sein, wobei
dann die Grenze zur Variante fließend ist, wenn etwa die neue Version
eines Bildes inhaltlich oder nur seine Metadaten verändert wurden.
Der Medien- bzw. Multimedia-Typ bleibt bei einer Versionierung stets
gleich (siehe Abb. 4.4).

Abb. 4.4:
Versionen

222

■
■
■

4 Content-Related-Technologien

Abb. 4.5:
Varianten

Typische Funktionen im Versionsmanagement sind die Definierbarkeit des Erkennungsverfahrens von Versionen, etwa über Dateinamen- oder Metadatenerkennung, ferner die Protokollierungen, die
Regelung der Lebensdauer von alten Versionen und die damit verbundene Regelung der Auslagerung/Migration von älteren Versionen
auf externe Datenträger, Werkzeuge zur optischen Differenzanzeige
von Versionen sowie Möglichkeiten des Rücksetzens von neuen Versionen auf alte Versionsstände.
Varianten: Für das Beziehungsmodell Varianten gilt, dass eine Variante ein aus einem existierenden Ursprungsobjekt hervorgegangenes, aber dabei deutlich verändertes Objekt darstellt. Die Variante
trägt den Verweis auf das Objekt, von dem es abgeleitet wurde. Von
einem Objekt können mehrere Varianten entstehen. Ebenso sind Varianten von Varianten möglich. Der Medien- bzw. Multimedia-Typ
muss nicht gleich bleiben (siehe Abb. 4.5).
Composing-Objekte: Für das Beziehungsmodell Composing-Objekte
gilt, dass ein Composing-Objekt ein aus einem oder mehreren Objek-

Varianten

Composing-Objekte

Abb. 4.6:
Composing-Objekte

4.4 Technische Bausteine

■
■
■

223

ten entstandenes neues Objekt darstellt, wobei die enthaltenen Objekte
entweder referenziert (z. B. referenzierte Bilddateien in einem Adobe
Indesign-Layoutdokument) oder aber eingebettet („embedded“) sind
(z. B. eingefügtes JPEG-Bild in einer PowerPoint-Folie). Die Quellobjekte selbst können im neu entstandenen Composing-Objekt auch
verändert sein. Die Protokollierung der im Composing-Objekt enthaltenen Objekte kann in verschiedenen CRT-Systemen zwingend sein,
etwa für Bildquellenverweise und Bildlizenzabrechnungen in Fachbüchern eines Verlages (siehe Abb. 4.6).

4.4.7
Steuerung und Kontrolle von Content-Workflows
CRT-Systembausteine zur Unterstützung des Content-Workflows
können nur unter zwei Voraussetzungen sinnvoll eingesetzt werden:
Die exakte Analyse der Abläufe, die oft beträchtlichen Aufwand erfordert sowie die vollständige Dokumentation und Modellierung dieser
Abläufe. Content und die contentbezogenen Prozesse müssen als dialektische Einheit betrachtet werden, um die folgenden Nutzenaspekte
durch einen gesteuerten Workflow zu erzielen (vgl. Rockley 2003):
• Erhöhung der Effizienz durch die Nutzung bereits einmal definierter und qualitativ geprüfter Abläufe.
• Rationalisierungspotenziale durch die Automatisierung von Arbeitsschritten durch das System selbst, etwa durch automatisierte
Benachrichtigungen bei Vergabe bestimmter Zustände oder das
Anstoßen eines automatisierten Umrechnungs- oder Bearbeitungsprozesses eines Bildes für die Web-Darstellung.
• Sicherung von Prozessabläufen: Freigaben erfolgen zur richtigen
Zeit, von den zuständigen Verantwortlichen und in der richtigen
Reihenfolge.
• Erhöhung der Transparenz durch Protokollierungen und Statuskontrollen.
• Vermeidung von Mehrfacheingaben, Medienbrüchen und manuellen Abstimmungen.
• Automatische Kontrolle von Zeiten und Kosten und das damit
verbundene Initiieren von Eskalationsszenarien (z. B. Konflikt- und
Notfallplanung).
• Zeit- und Kostenreduktion.

Workflow-Modellierung

224

■
■
■

Folgende Phasen innerhalb des Managements eines ContentWorkflows sind elementar:
Workflow-Modellierung (Workflow-Definition): Entwurf und Modellierung der Abläufe mittels geeigneter Werkzeuge wie Graphen- und

4 Content-Related-Technologien

Netzeditoren. Die Modellierung enthält dabei definierte Start- und
Endbedingungen, Aufgaben und Aktivitäten inklusive zugeordneter
Rollen, deren Abfolge und ihrer Beziehungen untereinander. Vorrangige Ziele der Modellierung sind die maximale Automatisierung von
Arbeitsschritten durch das System selbst und die Vermeidung von
Medienbrüchen. Durch die notwendige Beschäftigung mit den Abläufen ist ein Erkennen von Optimierungspotenzialen teilweise möglich
und wünschenswert. Die aus der Workflow-Modellierung resultierenden Daten werden zunehmend in XML spezifiziert und standardisiert,
etwa in der Business Process Modeling Language (BPML) und der Business Process Execution Language (BPEL) (vgl. Dustdar, Gall, Hauswirth 2003).
Der Workflow-Enactment-Service setzt die aus der WorkflowModellierung stammenden Daten in ein oder mehreren WorkflowEngines um. Zu dieser Umsetzung gehören das Erzeugen, das Verwalten und Ausführen von Workflow-Prozessen. Eine Workflow-Engine
kann als Runtime-Umgebung zum Initialisieren, Starten, Kontrollieren, Steuern und Beenden von Prozessen aufgefasst werden.
Typische Einsatzgebiete eines Workflow-Enactment-Service in einem CRT-System sind Korrektur- und Freigabezyklen. Zur Optimierung der Kommunikation innerhalb der Abläufe werden auch
zunehmend Groupware-Lösungen eingesetzt (siehe Kap. 3).
Folgende Arten von Workflows und deren Kombinationen kommen in CRT-Systemen primär zum Einsatz:

Workflow-Enactment-Service
und Workflow-Engine

• Strukturierte und vordefinierte Workflows: Sie werden durch Administratoren oder explizit dazu berechtigten Personen definiert.
Der Anwender kann diesen Ablauf nur in sehr geringem Maße
selbst verändern. Der Einsatz erfolgt vorrangig bei gleichen oder
annähernd gleichen Abläufen (z. B. Abwicklung der Beantwortung
einer Kundenfrage über die Website).
• Ad-hoc-Workflows werden vom Anwender selbst definiert und können jederzeit von ihm verändert werden. Zum Einsatz kommen sie
insbesondere bei einmalig auftretenden Abläufen, wie etwa zur Dokumentation und Protokollierung einer Metadatenänderungen im
Beipackzettel eines Arzneimittels.
• Semi-strukturierte Workflows als Kombination der beiden zuvor
genannten Arten.
Standardisierungen im Workflow-Management werden etwa von
der Workflow Management Coalition (WfMC) vorgegeben. Die WfMC
ist ein internationaler Zusammenschluss von Anbietern, Anwendern
und Beratern für Workflow-Lösungen. Ihre Aufgabe ist die Entwicklung von gemeinsamen Softwarespezifikationen und Standards, um

4.4 Technische Bausteine

■
■
■

225

eine breite Basis für die Interoperabilität und Kommunikation von
Produkten und Komponenten in verschiedenen Umgebungen zu
schaffen. Das Workflow Reference Model der WfMC beschreibt dabei
allgemeine Eigenschaften, Funktionen und Schnittstellen von Workflow-Systemen (vgl. Gierhake 1998).
Zu den grundlegenden Elementen von Workflow-ManagementWerkzeugen in CRT-Systemen gehören:
• Unterstützung von sequenziellen und auch graphenorientierten
Arbeitsabläufen.
• Werkzeuge zur Steuerung und Überwachung der Abläufe.
• Unterstützung von Rollen und Verantwortlichkeiten.
• Benachrichtigungs- und Wiedervorlagemechanismen.
• Werkzeuge zum Pflegen und Verwalten von Zuständen (z. B. Status) und Filter für Vorgänge und Bearbeitungen.
• Automatisches Generieren von Aufgabenlisten (z. B. Tasklisten)
sowie deren Verteilung an die zuständigen Personen bzw. -gruppen.
• Erzeugen von Protokollierungen.
• Unterstützung von Vertreterregeln.
• Automatisierung einzelner Arbeitsschritte innerhalb des Ablaufes
durch das CRT-System selbst.
• Unterstützung der Zugriffsberechtigung auf Content
• Unterstützung elementarer Freigabemechanismen, wie die Einhaltung des 4-Augen-Prinzips.
• Benachrichtigungen, etwa beim Eintreffen eines Dokumentes in
einer persönlichen Vorgangsmappe.
• Auswertung von Soll- und Ist-Werten (z. B. Zeiten, Kosten).

4.4.8
Content-Aggregation, -Delivery und -Publishing
Content-Aggregation

Content-Delivery

226

■
■
■

Content-Aggregation bezeichnet das Sammeln und Zusammenfügen
von Inhalten oder Inhaltssegmenten aus unterschiedlichen Quellen
und Bereichen des Content-Repository. Voraussetzung für diese Content-Aggregation ist die Vorhaltung strukturierter Inhalte im Sinne
einer Content-Strategie, wie dies in den vorigen Kapiteln bereits besprochen wurde.
Content-Delivery bezeichnet das Bereitstellen von Inhalten durch
eine gezielte Verteilung an unterschiedliche Empfänger mittels unterschiedlicher Ausgabe- und Distributionsformen. Die Bereitstellung
kann dabei sowohl zustellend als auch abholend (Push-/PullVerfahren) erfolgen: Zugestellte Werbe-E-Mail als zustellende Form

4 Content-Related-Technologien

und aktives Abholen eines Produktdatenblattes auf der Unternehmens-Website durch den Anwender als abholende Form. Zunehmend
erfolgt dabei eine personalisierte Bereitstellung (vgl. Kap. 4.4.9). Man
unterscheidet unter anderem folgende Ausgabe- und Distributionsformen:
•
•
•
•
•
•
•
•

Web: Internet, Extranet und Intranet
Print: Produktdatenblatt, Werbekatalog, Werbe-Flyer
Mobile Geräte: Mobiltelefone, PDAs
Datenträger: DVD, CD
Multimedia-Ausgabegeräte: Digitales Fernsehen
Backend-Systeme: ERP, E-Business-Systeme
Kommunikationsformen: Fax, SMS, MMS, E-Mail
Elektronischer Datenaustausch: EDI, BMEcat, XML
Content-Publishing beschreibt die Umwandlung aggregierter Inhalte in das jeweilige Format der Ausgabe- oder Distributionsform. Dabei
kommen die beiden grundsätzlichen technischen Verfahren ContentTemplating und Content-Rendering zum Einsatz. Beide Formen werden nachfolgend detaillierter besprochen.

Content-Publishing

4.4.8.1
Content-Templating
Content-Templating bezeichnet die Publikation strukturierter Inhalte
oder Inhaltssegmente auf der Basis von Vorlagen (Templates) und
unter Berücksichtigung definierter Regeln. Dabei erfolgt das Einbringen der Inhalte in die Vorlagen durch Substitution von Platzhaltern
oder Anweisungen. Layout und Gestaltung werden durch die Vorlage
selbst definiert (siehe Abb. 4.7). In vielen CRT-Systemen unterscheidet
man zwischen den Dokumenten- und Seitenvorlagen (z. B. StandardWebseite, Titelseite) und den Inhaltsvorlagen (z. B. Text mit Bild,
Textaufzählung, Bild). Die Vorteile dieses Verfahrens sind zum einen
einfacher zu realisierende komplexere Layout sowie Gestaltungen, in
denen dem Layout eine gesonderte Aufgabe zukommt (z. B. im Bereich
der Kommunikation, wie bei Werbemitteln, und im Bereich der Didaktik, wie bei einem Schulbuch mit hohem grafischem Anteil). Zum
anderen lässt die Publikation auch im noch layoutfähigen Endformat
(z. B. Adobe Indesign-Format, QuarkXPress-Format) nachträgliche
Änderungen zu. Ein gutes Beispiel ist die nachträgliche Aktualisierung
von Preisinformationen in mehrseitigen Produktkatalogen, ohne dafür einen kompletten neuen Datenimport durchführen zu müssen.
Folgende Beispiele erläutern den Templating-Prozess anhand häufiger Ausgabeformen:

4.4 Technische Bausteine

■
■
■

227

Abb. 4.7:
Typischer Templating-Prozess
auf der Basis von Vorlagen

• Für die Web-Ausgabe werden definierte Platzhalter in einer HTMLVorlage beim Templating-Prozess mit Inhalten aus einem ContentRepository ersetzt. Im gängigsten Verfahren sind diese Platzhalter
nicht als eine Art Variable oder Auszeichnungs-Tag definiert, vielmehr werden die Inhalte aus dem Content-Repository durch Anweisungen auf der Basis von Skriptsprachen wie JSP, ASP, PHP etc.
bei einem Templating-Prozess auf dem Server (Server Side Scripting) in die HTML-Vorlage einsetzt (vgl. Balzert 2003).
• Für die Print-Ausgabe, etwa in einer automatisierten Print-Katalogproduktion, werden in den Layoutvorlagen Platzhalter für die
einzubringenden Inhalte hinterlegt, die dann durch den Templating-Prozess ersetzt werden. Im Bereich der automatisierten Katalogproduktion (z. B. Database-Publishing) kommen vorwiegend
Anweisungen mit Datenbankverbindungen oder Verbindungen zu
XML-Tag-Strukturen als Platzhalter zum Einsatz. Im Bereich des
direkten Templating von PDF-Dokumenten werden überwiegend
Bibliotheken zum Verändern oder Einbringen von Inhalten in
PDF-Vorlagen genutzt (vgl. Merz 1998).
• In Analogie zur Nutzung von HTML-Vorlagen für die Web-Ausgabe können für mobile Endgeräte dort eingesetzte Markup-Sprachen wie die Wireless Markup Language (WML) bzw. XHTML
MP/CSS genutzt werden. Insbesondere die Vielzahl an unterschiedlichen Display-Eigenschaften, Eingabe- und Navigationswerkzeugen in mobilen Endgeräten erfordert nicht nur eine automatische
Anpassung des Contents, sondern in vielen Fällen auch deren spezifische Erstellung (siehe auch das Kapitel „Mobile Multimedia“ in
Teil 1 des Kompendiums).
4.4.8.2
Content-Rendering
Content-Rendering bezeichnet die Publikation strukturierter Inhalte
oder Inhaltssegmente auf der Basis einer Transformation in Ziel- oder

228

■
■
■

4 Content-Related-Technologien

Abb. 4.8:
Rendering-Prozess auf der Basis einer
Transformationsvorschrift

Ausgabeformate unter Berücksichtigung definierter Regeln (siehe
Abb. 4.8). Die Layout- und Gestaltungsanweisungen sind in der Transformationsvorschrift definiert. Vorteile dieses Verfahrens sind die hohe
Automatisierbarkeit, der generische Ansatz für heutige und zukünftige
Standards und die Geschwindigkeit beim Erzeugen der eigentlichen
Ausgabeform (z. B. HTML, PDF). Mit der weiteren Entwicklung von
komfortablen Werkzeugen zur Definition der Transformationsvorschriften und der konsequenten Öffnung klassischer Layoutformate für
XML wird das Rendering-Verfahren zunehmend in CRT-Systemen
eingesetzt.
Folgende Beispiele erläutern den Rendering-Prozess anhand häufiger Ausgabeformen:
• Für die Web-Ausgabe werden XML-Inhalte aus dem Content-Repository über Transformationsskripte in XSLT (Extensible Stylesheet Language Transformation), in HTML oder in SVG (Scalable
Vector Graphics) umgesetzt (siehe Kap. 2). Zunehmend werden
auch XML-Publishing-Frameworks wie Apache Cocoon eingesetzt.
Diese Frameworks bieten unterschiedliche Werkzeuge zur crossmedialen Umsetzung von Inhalten auf der Basis von XML-Technologien (vgl. http://cocoon.apache.org).
• Für die Print-Ausgabe ermöglicht die Transformation mittels XSLFO (der Formatierungskomponente von XSL) die Umsetzung von
XML-Inhalten in PDF. Das Rendering von proprietären Layoutformaten, wie QuarkXPress und Adobe Indesign, auf der Basis von
XML wird momentan nur rudimentär als Import von XML-Inhalten
in bestehende Layoutvorlagen unterstützt. Neuere Entwicklungen
hingegen unterstützen Ansätze, in denen das gesamte Dokumentenformat als XML importiert und exportiert werden kann, etwa in
QuarkXPress 6.5/7.0.
• Für die Ausgabe auf mobilen Endgeräten werden ebenfalls dort
eingesetzte Markup-Sprachen wie WML bzw. XHTML MP/CSS mittels XSLT-Transformationen umgesetzt (siehe auch das Kapitel
„Mobile Multimedia“ in Teil 1 des Kompendiums).

4.4 Technische Bausteine

■
■
■

229

4.4.8.3
Konzepte für unterschiedliche Content-Klassen

Statischer Content

Dynamischer Content

Bei der Betrachtung von grundlegenden Content-Publishing-Konzepten müssen zunächst die grundsätzlichen Klassen von Content berücksichtigt werden.
Generell unterscheidet man statisch und dynamisch generierten
Content. Statischer Content besitzt einen definierten Zustand und
wird nach der Erstellung nicht mehr geändert. Hierzu gehören zum
Beispiel Aufzeichnungen von Ereignissen, Biografien verstorbener
Personen, Veröffentlichungen etc.
Dynamischer Content besitzt keinen definierten Zustand und wird
in regelmäßigen zeitlichen Abständen durch zyklisches Abfragen etwa
von Preisinformationen oder aufgrund bestimmter Ereignisse, wie
einer Interaktion zur Anfrage eines Lagerbestandes, aus unterschiedlichen Quellen aktualisiert. Hierzu gehören zum Beispiel Lagerbestände
aus ERP-Datenbanken, Börsenkurse etc. Eine noch genauere Betrachtung des dynamischen Contents unterscheidet demnach ereignisgesteuert generierten und zyklisch generierten Content. Die Generierung
selbst kann nochmals in neu erzeugten und aktualisierten Content
(semidynamischer Content) unterschieden werden (vgl. Büchner
(Hrsg.), Traub, Zahradka, Zschau 2001). Abbildung 4.9 zeigt hierfür
einige Beispiele.

Abb. 4.9:
Beispiele für dynamischen Content

230

■
■
■

4 Content-Related-Technologien

Beim Content-Publishing, also der Ausbringung des Contents (statisch/dynamisch) in die jeweilige Ausgabe- oder Distributionsform
mittels der bereits weiter oben besprochenen Templating- und Rendering-Verfahren, kann ebenfalls zwischen statischem und dynamischem Publishing unterschieden werden (vgl. Bodendorf 2006).
Das statische Publishing erzeugt Ausgabeformen, die einem System
in einem definierten Zustand und zu einem definierten Zeitpunkt zur
Verfügung gestellt werden, etwa HTML-Seiten nach der Freigabe einem Web-Server. Die primären Vorteile des statischen Publishing
liegen in dem geringeren technischen Aufwand, den Möglichkeiten
des einfacheren Hosting und der erreichbaren Zugriffsgeschwindigkeit
auf die Ausgabeformen (z. B. Webseiten im Internet) (vgl. Abb. 4.10).
Dynamisches Publishing erzeugt die Ausgabeformen erst bei einem
bestimmten Ereignis (z. B. Aufruf einer Webseite und klicken auf einen Link zu einer bestimmten Produktinformation). Der Vorteil liegt
in der Aktualität der Inhalte (vgl. Abb. 4.11).
Die Art und das Verhältnis des vorliegenden Contents (statisch,
dynamisch) im Sinne einer Content-Strategie schränken die zuvor
beschriebenen Publishing-Konzepte ein. Hinzu kommen betriebswirtschaftliche Überlegungen, etwa bei der Auslegung der Performance:
Wie viele User müssen gleichzeitig bedient werden? Soll das CRT-System selbst gehostet werden oder durch einen Internet-Provider oder
ASP-Dienstleister? Welche Inhalte müssen wirklich dynamisch neu
erzeugt werden? Können sie auch zu bestimmten Zeitpunkten zyklisch
neu erzeugt werden, wie die Meldungen einer Online-Publikation?
Die meisten CRT-Systeme bieten durch Trennung des eigentlichen
Redaktionssystems vom Live-System (Staging-Konzepte) die Möglich

Statisches Publishing

Dynamisches Publishing

Staging-Konzept

Abb. 4.10:
Statisches Publishing

Abb. 4.11:
Dynamisches Publishing

4.4 Technische Bausteine

■
■
■

231

Abb. 4.12:
Staging-Konzept

keit, ein semidynamisches Konzept zu realisieren. Dabei werden statische Inhalte nach der Freigabe bereitgestellt, und nur in den Bereichen, in denen dynamischer Content notwendig ist, wird dieser entweder zyklisch statisch abgeglichen oder aber wirklich dynamisch aus
Backend-Datenbanken generiert (vgl. Abb. 4.12).

4.4.9
Personalisierung von Content
Unter Content-Personalisierung versteht man die personalisierte oder
zielgruppenoptimierte Bereitstellung von Inhalten, um dadurch höhere Verkaufswahrscheinlichkeiten, höheres Interesse, optimiertere Informationskonzentration, längere Verweildauer etc. zu erreichen.
Folgende Phasen können im Personalisierungsprozess unterschieden werden (vgl. Runte 2000) (vgl. Abb. 4.13):
Identifizierung

Profilierung

• Identifizierung des Nutzers durch manuelle Anmeldeverfahren (z. B.
Login) oder automatisches Erkennen mittels gespeicherter Nutzerdaten (z. B. Session-IDs, Cookies) (Fragestellung: Wer ist der Anwender?).
• Profilierung, also das Erfassen der Content-Interessen des Nutzers.
Man unterscheidet zwei prinzipielle Verfahren: Das explizite Profilieren ermittelt die Interessen durch manuelles Erfragen mittels

Abb. 4.13:
Phasen der Personalisierung

232

■
■
■

4 Content-Related-Technologien

eines Fragebogens. Implizites Profilieren erfolgt durch Nutzung
anderer Quellen wie Kundendatenbanken oder durch Eruieren der
Interessen mittels Analyse des Nutzerverhaltens im CRT-System,
zum Beispiel durch Analyse des Klickverhaltens auf einer Website
(Fragestellung: Welche Interessen hat der Anwender?).
• Im Analysing werden die eruierten Profildaten mittels unterschiedlicher Methoden analysiert, um eine bessere Differenzierung der
Interessen und Neigungen des Nutzers festzustellen (Fragestellung:
Was könnte den Anwender noch interessieren?). Beispielhafte Analysing-Verfahren werden nachfolgend aufgezeigt.
• Matching ermöglicht durch Abgleich und Vergleich von Interessen,
Neigungen des Nutzers und möglichen anbietbaren Inhalten den
Aufbau eines personalisierten Content-Angebotes. Voraussetzung
hierfür ist die Zuordenbarkeit des verfügbaren Contents zu dem
Nutzerinteresse, der Content muss also über seine Strukturdaten
(z. B. Metadaten, Gruppenzuordnungen) entsprechend kategorisierbar sein (Fragestellung: Welche Inhalte meines Angebotes entsprechen noch dem Interesse des Anwenders?).
• Channeling meint die Umsetzung der gewonnenen Erkenntnisse
und das automatische oder manuelle Bereitstellen der personalisierten Inhalte per Web, SMS, E-Mail, Fax, teilweise auch Print etc.
(Fragestellung: Welche Ausgabeformen sollen genutzt werden?).
Für das Analysing werden verschiedene grundlegende Verfahren in
CRT-Systemen eingesetzt (vgl. Dörner 2003):
In den Bereich der regelbasierten Verfahren gehören die formularbasierte Personalisierung, bei der aufgrund von Nutzereingaben bestimmte Inhalte angezeigt werden (z. B. Eingabe des gleichen Suchbegriffs in einem Formular führt zur Anzeige gleicher Inhalte) sowie das
Rule-based Filtering, bei dem durch fest definierte Regeln eine Personalisierung durchgeführt wird: „Wenn der Nutzer sich für Produkt
„Motorrad 4711“ interessiert, dann biete ihm auch Produktinformationen zu „Versicherungen für 4711“ an“.
Zu den vergleichsbasierten Verfahren gehören das Content-based
Filtering und das Collaborative Filtering. Content-based Filtering führt
eine Bewertung aufgrund von Objekteigenschaften durch. Voraussetzung hierfür ist natürlich, dass das Objekt mittels Eigenschaften beschreibbar ist (z. B. rote Hosen der Marke xyz). Wenn sich ein Nutzer
für ein Produkt mit bestimmten Eigenschaften interessiert, dann ist es
wahrscheinlich, dass er auch für andere Produkte mit denselben bzw.
ähnlichen Eigenschaften Interesse zeigt.
Das Collaborative Filtering ist eine Methode der Personalisierung
auf der Basis der Beobachtung des Nutzerverhaltens und dem Bilden
von Korrelationen. Dabei wird versucht, das Profil von Benutzern auf

4.4 Technische Bausteine

Analysing

Matching

Channeling

Regel- und vergleichsbasierte
Analysing-Verfahren

■
■
■

233

der Basis dieser Korrelationen zu erweitern: Wenn sich ein Benutzer
für A, B und C interessiert und ein anderer für A, B und D, so ist die
Wahrscheinlichkeit groß, dass der zweite Benutzer sich auch für C
interessiert, obwohl er es nicht explizit angegeben hat.

4.4.10
Archivierung und Revisionssicherheit
4.4.10.1
Archivierung
Archivierung

Backup

Online-Speicher

Nearline-Speicher
Offline-Speicher

234

■
■
■

Unter Archivierung in CRT-Systemen wird die langfristige Auslagerung (Migration) von Mediendateien, die sich nicht mehr im aktiven
Änderungsprozess befinden, von einem Online-System (z. B. Festplatten-, RAID-, SAN- oder NAS-Systeme) auf externe Datenträger (z. B.
WORM-, DVD- oder TAPE-Library-Systeme) verstanden. Zur Verwirrung: In Dokumenten-Management-Systemen wird unter Archivierung oftmals das „Einbringen“ (Check-In) von Dokumenten in das
eigentliche Dokumenten-Management-System selbst bezeichnet.
Nach der Archivierung ist der archivierte Datenbestand auf dem
Archivmedium und nicht mehr auf dem Online-Speicher (z. B. RAID,
Festplatte) des Rechnersystems vorhanden. Aus diesem Grund müssen zusätzliche Backup-Strategien wie das automatische Klonen für
diese Archivierungsmedien entwickelt werden.
Im Gegensatz hierzu versteht man unter Backup das Anlegen einer
Sicherheitskopie des aktuellen Datenbestandes eines Rechnersystems
auf externe Medien. Nach Durchführung des Backups ist der gesicherte Datenbestand auf dem Backup-Medium und auf dem Online-Speicher des Rechnersystems vorhanden. Ein Backup soll bei Datenverlust
oder -zerstörung eine Möglichkeit bieten, die ursprünglichen Datenbestände wiederherzustellen.
Das Archiv im Sinne von CRT-Systemen erlaubt über die Speichergrenzen des verfügbaren Online-Speichers hinaus einen Zugriff auf
die Datenbestände. Teilweise unterscheidet man innerhalb der Archivierung folgende prinzipielle Speicherstufen:
• Online-Speicher: RAID-System mit hochperformanten Festplattensystemen (z. B. SCSI-RAID), Speichernetzwerke (z. B. Network Attached Storage (NAS), Storage Area Network (SAN)).
• Nearline-Speicher: Früher MO-Jukeboxen, heute üblicherweise
RAID-System mit billigeren Festplatten (z. B. IDE-RAID).
• Offline-Speicher: Band-, CD-, DVD-Jukebox- oder Robotersysteme.

4 Content-Related-Technologien

4.4.10.2
Langzeitarchivierung
Unter Langzeitarchivierung versteht man Archivsysteme, die Daten und
Dokumente über einen größeren Zeitraum (>10 Jahre) verfügbar halten
können. Im Kontext der Kulturgüterarchivierung geht es um Zeithorizonte von mehreren hundert Jahren. Primäre Fragestellungen für die
Langzeitarchivierung (vgl. Borghoff, Rödig, Scheffczyk 2003) sind dabei:

Langzeitarchivierung

• Welcher Datenträger eignet sich hinsichtlich der Lebensdauer von
Datenträgern, Laufwerken, Betriebssystemen etc.? Lebensdauer bezieht sich hier nicht nur auf die physikalische Haltbarkeit, sondern
auch auf die Verfügbarkeit!
• Welches Format soll für die Speicherung angesichts der Lesbarkeit
und Anwendbarkeit genutzt werden? Bisher wurde häufig hierfür
das TIFF-Format verwendet. Trends gehen in Richtung des neuen
ISO-Standards PDF/A, einer Untermenge von PDF 1.4.
Mögliche Lösungsansätze für obige Fragestellungen resultieren
nicht in einer konkreten Antwort, sondern in Strategien, die trotz notwendiger Entscheidung für einen Datenträger und ein Format die Langzeitarchivierung sicherstellen sollen. Zu den Möglichkeiten zählen:
• Aufbau eines „Technik-Museums“ mit alten Hardware- und Softwaresystemen.
• Zyklisches Migrieren der alten Datenbestände auf neue Datenträger
und in neuen Formaten. Dies widerspricht jedoch den Prinzipien
einer revisionssicheren Archivierung (siehe nachfolgend).
• Emulation von Software zum Lesen von Formaten durch virtuelle
Umgebungen, in denen ältere Betriebssysteme und Anwendungen
auf neuerer Hardware noch lauffähig bleiben sollen.
Bei extrem langen Zeithorizonten wie in der Kulturgüterarchivierung sind auch analoge Speichermedien wie der farbige Mikrofilm in
Betracht zu ziehen, die mit analogen Daten (z. B. Text, Bild) und/oder
mit digital und verlustfrei rücklesbar codierten Daten (z. B. Flächencodes) laserbelichtet werden.
4.4.10.3
Revisionssichere Archivierung
Unter revisionssicherer Archivierung versteht man die langfristig garantierte Verfügbarkeit von archivierten Daten und Dokumenten. Im
Vordergrund steht dabei die Unveränderbarkeit und sichere Aufbewahrung. Insbesondere dann, wenn durch Dokumenten-Manage-

4.4 Technische Bausteine

Revisionssichere Archivierung

■
■
■

235

ment-Systeme (DMS) Papierarchive bestimmter Dokumententypen
ersetzt werden sollen und diese zudem von entsprechenden Organisationen und Institutionen anerkannt werden sollen (wie z. B. Rechnungen und Buchungsbelege vom Finanzamt), müssen diese revisionssicher sein und deren Archivierung bestimmten Grundsätzen
entsprechen. Regelungen und Vorgaben sind dann mehr oder weniger
genau in unterschiedlichen Vorgaben wie z. B. in GDPdU (Grundsätze
des Datenzugriffs und der Prüfbarkeit digitaler Unterlagen), HGB
(Handelsgesetzbuch), AO (Allgemeine Abgabenordnung) und GoBS
(Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme)
enthalten (vgl. Götzer, Schneiderath, Maier, Boehmelt 2004). Folgende
Grundeigenschaften der Verwaltung von Daten und Dokumenten in
solchen revisionssicheren Archiven stehen dabei im Vordergrund:
• Sicher: Inhalte müssen auch über mehrere Jahre oder Jahrzehnte
hinweg verfügbar sein und während ihrer vorgesehenen Lebenszeit
nicht zerstört werden können.
• Unveränderbar: Es darf keine Möglichkeit der Veränderung von
Inhalten bestehen. Dadurch wird die Auswahl an Archivierungsmedien eingeschränkt, etwa auf WORM-Systeme (Write Once,
Read Multiple).
• Vollständig: Auf dem Weg ins Archiv oder im Archiv selbst dürfen
keine Informationen verloren gehen.
• Ordnungsgemäß: Gesetzliche Bestimmungen müssen eingehalten
werden.
• Verlustfrei reproduzierbar: Jedes Dokument muss in genau der
gleichen Form, wie es erfasst wurde, wieder angezeigt und gedruckt
werden können.
• Recherchierbar: Dokumente müssen mit geeigneten RetrievalTechniken wieder auffindbar sein.

4.4.11
Integration für Nutzer, Content, Funktion
und Prozesse
Der Einsatz von CRT-Systemen innerhalb eines Unternehmens sollte
immer im Kontext bestehender IT-Landschaften mit unterschiedlichen Systemen betrachtet werden, die ihrerseits immer weiter vernetzte und räumlich voneinander getrennte Strukturen aufweisen. Der
Informationsaustausch innerhalb eines Unternehmens muss hierbei
als Wertkette verstanden werden. Außerdem reicht die Wertschöpfungskette von Content und Medien oft über die Grenzen des eigenen
Unternehmens hinaus und bindet mehr und mehr auch Kunden und

236

■
■
■

4 Content-Related-Technologien

Zulieferer ein (vgl. Kretzschmar, Dreyer 2003). Die grundlegenden
Integrationsebenen sind hierbei die Content-, Funktions-, Prozessund Nutzerebene.
4.4.11.1
Integration auf Content-Ebene
Die Integration auf Content-Ebene erfolgt als Abgleich-, Replikationsoder Austauschszenario i.d.R. auf XML-Basis.
In Verbindung mit dem Abgleich von Produktdaten in CRTSystemen sind bereits verschiedene Standardisierungen im Einsatz
(z. B. BMEcat, ebXML, OpenTRANS, ETIM, eCl@ss; vgl. Hentrich 2001).
Ebenfalls häufig eingesetzte Möglichkeiten des generellen Abgleichs
sind die Verwendung sogenannter BusinessObjects auf XML-Basis und
die zunehmende Nutzung standardisierter CRT-Schnittstellen (z. B.
JSR-168, JSR-170). Unter BusinessObjects versteht man logische Objekte, die Daten und Funktionen von Objekten kapseln, die in der realen
Geschäftswelt vorkommen (vgl. Bullinger (Hrsg.), Schuster, Wilhelm
2001; Delp 1998).
Da strukturierte Produktdaten als Content und das daraus resultierende Katalog-Management in CRT-Systemen immer wichtiger werden, sollen hier einige Standardisierungen kurz vorgestellt werden:
Der Standard BMEcat ist ein auf Initiative des Bundesverbands Materialwirtschaft, Einkauf und Logistik (BME) und namhafter Unternehmen (Alcatel, American Express, Audi, Bayer, BMW, C@Content,
DaimlerChrysler, Deutsche Bahn etc.) vom Fraunhofer-Institut für
Arbeitswirtschaft und Organisation sowie von den Universitäten Essen und Linz entwickelter Standard zur elektronischen Datenübertragung für Artikel- und Produktkataloge, der erstmals Ende 1999 veröffentlicht wurde. Im deutschsprachigen Raum ist BMEcat der am
weitesten verbreitete Austauschstandard für elektronische Produktkataloge. Auch international erfolgt zunehmend die Nutzung von BMEcat im zwischenbetrieblichen E-Commerce. BMEcat unterstützt mit
der einfachen Übernahme von Katalogdaten aus den unterschiedlichsten Formaten den Warenverkehr zwischen Unternehmen im Internet.
Der Standard BMEcat basiert auf XML (vgl. BMEcat 2001;
www. bmecat.org).
Der Standard ebXML (Electronic Business using eXtensible Markup
Language) ist ein Regelwerk für den Austausch von Geschäftsinformationen im Internet. Er basiert auf einem Entwurf der Vereinten Nationen (UN/CEFACT) und der Organisation für die Förderung Strukturierter Informationsstandards (OASIS), die 14 Nationen und mehr als
100 Unternehmen vertritt. Als Rahmenwerk will ebXML einen elektronischen Marktplatz schaffen, der es Unternehmen unabhängig von

4.4 Technische Bausteine

BMEcat

ebXML

■
■
■

237

OpenTRANS

ETIM

eCl@ss

Generelle Schnittstellen
JSR-168/JSR-170

ihrem Standort und ihrer Größe ermöglicht, Nachrichten auf Basis
von XML-Dokumenten auszutauschen. Er wird wohl das klassische
EDI-Format ersetzen: UN/EDIFact ist ebenfalls ein von der UN initiiertes Austauschformat (vgl. www.ebxml.org).
OpenTRANS ist ein Standard für den Austausch von Geschäftsdokumenten wie Auftragsdaten, Lieferscheine, Rechnungen etc. und
unterstützt die elektronische Beschaffung (E-Procurement) zwischen
Handelsunternehmen (vgl. www.opentrans.org).
ETIM ist eine deutsche Standardisierungsinitiative für den elektronischen Produktdatenaustausch in der Elektrobranche. Er erlaubt
neben der lieferantenunabhängigen Produktbeschreibung auch die
Zuordnung zu einer Produktklasse. Eine Artikelklasse fasst vergleichbare, bau- oder funktionsähnliche Produkte zusammen. Eine Artikelgruppe fasst eine oder mehrere Artikelklassen zusammen. Produkte
werden in zwei hierarchischen Stufen (Artikelgruppe und Artikelklasse) strukturiert. ETIM wird speziell zur Herstellung von Produktkatalogen eingesetzt; die Übertragung dieser Katalogdaten geschieht in
einem erweiterten BMEcat-Format (vgl. www.etim.de).
Der Standard eCl@ss bietet ein hierarchisches System zur Klassifizierung von Produkten, Materialien, Waren und Dienstleistungen. Die
Klassifizierung soll nicht nur den Aufbau eines Ordnungsschemas erlauben, sondern auch die Vergleichbarkeit von Produkten ermöglichen.
Der Standard eCl@ss ist nach einem logischen Schema aufgebaut, das in
seiner Granularität den Produktmerkmalen entspricht. Dadurch können Märkte branchen-, unternehmens- und produktneutral dargestellt
werden. Die eCl@ss-Klassifizierung kann optional jedem Produktkatalog im BMEcat-Format übergeben werden (vgl. www.eclass.de).
Auf Content-Ebene sind die akzeptierten Standards (Java Specification Requests) JSR-170 und JSR-168 im CRT-Bereich interessant (vgl.
www.jcp.org). JSR-170 wurde bereits weiter oben im Zusammenhang
mit dem Content-Repository besprochen (siehe Kap. 4.4.3). Hier
bleibt abzuwarten, inwieweit er sich bei den Systemherstellern durchsetzen wird. JSR-168 spezifiziert die Schnittstelle, wie aggregierte Inhalte, etwa aus einem CM-System, in eine Portalseite auf der Basis von
sogenannten Portlets integriert werden können. Portlets sind webbasierte, personalisierbare Bausteine, die Zugriff auf definierte Informationen aus unterschiedlichen internen und externen Quellen ermöglichen (vgl. Großmann, Koschek 2005).
4.4.11.2
Integration auf Funktionsebene
Bisherige Integrationstechnologien auf Funktionsebene basierten auf
unterschiedlichen IT-Technologien wie RPC (Remote Procedure Calls)

238

■
■
■

4 Content-Related-Technologien

oder RMI (Remote Method Invocation) (vgl. Schneider, Werner 2004).
Einer dieser Ansätze ist die EAI (Enterprise Application Integration),
ein Konzept zur unternehmensweiten Integration der Geschäftsfunktionen, die über verschiedene Applikationen auf unterschiedlichen
Plattformen verteilt sind (vgl. Dustdar, Gall, Hauswirth 2003). Diese
Ansätze werden mehr und mehr durch dienste-orientierte Technologien ergänzt oder abgelöst.
In solchen serviceorientierten Architekturen (SOA) werden Funktionalitäten in Form von lose gekoppelten Diensten (sogenannte Services) bereitgestellt. Der Aufruf dieser Dienste erfolgt über standardisierte Schnittstellen, etwa mittels Web Services auf der Basis weiterer
Standards wie SOAP (Simple Object Access Protocol) etc. Komplexere
Abläufe, wie sie typischerweise in Programmabfolgen oder Geschäftsprozessen anzutreffen sind, werden durch die Kopplung unterschiedlicher, auch verteilt zur Verfügung gestellter Dienste und der Koordinierung zugehöriger Aufrufe (Orchestrierung) umgesetzt (siehe auch
das Kapitel „Verteilte Systeme“ in Teil 3 des Kompendiums).
4.4.11.3
Integration auf Prozessebene
Die Integration auf Prozessebene erfolgt auf der Basis der Nutzung
von Standards, wie dem bereits erwähnten WfMC-Standard der
Workflow Management Coalition. Allerdings wird dieser Standard
derzeit in wenigen CRT-Systemen unterstützt. Eine häufig angewandte Methodik ist die Modellierung in eigenen oder externen Grapheneditoren, etwa zur Definition von UML-Aktivitätsdiagrammen, die
dann im Regelfall als nicht standardisierte XML-Dokumente zur Weiterverarbeitung von Prozessdefinitionen in einer eigenen WorkflowEngine exportiert werden.
Im Zuge der zunehmenden Diensteorientierung auf der Basis der
vorher kurz angeführten serviceorientierten Architekturen (SOA)
werden Prozessbeschreibungssprachen, wie BPEL (Business Process
Execution Language) und BPEL4WS (Business Process Execution
Language for WebServices) zur Beschreibung von Geschäftsprozessen
auf der Basis von XML, in diesem Zusammenhang vermehrt zum
Einsatz kommen (vgl. Dustdar, Gall, Hauswirth 2003).
4.4.11.4
Integration auf Nutzerebene
Eine Integration auf Nutzerebene inkl. Berechtigungskonzepten für
Daten und Funktionen erfolgt mehrheitlich auf der Basis von Verzeichnisdiensten. Verzeichnisdienste versuchen Lösungen für die

4.4 Technische Bausteine

■
■
■

239

durch heterogene Betriebssystem-Landschaften resultierenden Probleme zu bieten, wie unterschiedliche Passwort-, Zugangs-, Benutzerund Ressourcenverwaltung etc. Eine einheitliche Basis unterschiedlicher, proprietärer Verzeichnisdienste wurde durch LDAP (Lightweight
Directory Access Protocol) (vgl. Schneider, Werner 2004) geschaffen.
Auf der Basis dieser LDAP-Schnittstellen erfolgt die Kopplung der
CRT-Systeme an eine zentrale Nutzerverwaltung inkl. Berechtigungsstrukturen.

4.4.12
Administration

Multisite-Management /
Mandantenfähigkeit

Seiten- / Blattplanung

System- / Mediensicherheit

Berechtigungskonzepte

Mehrsprachigkeit
Content-Rotation

240

■
■
■

In jedem CRT–System gibt es weitere Funktionen für die Systemadministration. Ein Auszug grundlegender administrativer Bausteine
wird im Folgenden vorgestellt.
Das Multisite-Management und die Mandantenfähigkeit eines
CRT-Systems ermöglichen es, auf einem System mehrere unterschiedliche und abgegrenzte Content-Bereiche eigenständig zu verwalten
und zu betreiben. Dazu gehören zum Beispiel das gemeinsame Betreiben von mehreren Websites unterschiedlicher Firmen oder Kunden
(z. B. Mandanten) oder das Verwalten unterschiedlicher Publikationen (z. B. Ausgaben einer Fachzeitschrift) auf einem System.
Die Seiten- und Blattplanung vorrangig in WCM- und PrintRedaktionssystemen dient der seitenbezogenen Planung von Produktion und Publikation einzelner Inhalte auf den jeweiligen Seiten. Bei
einer Tageszeitung etwa müssen verschiedene Content-Komponenten
zu unterschiedlichen Zeiten und aus ganz verschiedenen Quellen angeliefert werden.
System- und Mediensicherheit: Erforderlich ist eine Zugangssicherung des gesamten Systems (z. B. mittels Benutzername und Passwort)
und Kommunikationssicherheit durch Verschlüsselung und Authentifizierung (z. B. digitale Signatur). Maßnahmen zur Mediensicherheit
sind Mechanismen zum Schutz der Inhalte im Bereich des DRM (Digital Rights Management) (z. B. digitale Wasserzeichen, digitale Signatur; vgl. Kapitel „Mediensicherheit“ in Teil1 des Kompendiums).
Berechtigungskonzepte für Daten auf der Ebene von Mandanten,
Sprachversionen, Seitenbereichen, Inhaltsbereichen und Feldern sowie Funktionen auf unterschiedlichen Ebenen, wie Administratoren-,
Projekt-, Redaktions- und Anwenderebene.
Mehrsprachigkeit für Inhalt und Benutzeroberfläche mit durchgängiger Unicode-Unterstützung (Sonderzeichenfähigkeit).
Unterstützung von Content-Rotation zur zeitlich abgrenzbaren
Verwendung und Publikation von Inhalten.

4 Content-Related-Technologien

Protokollierung aller Transaktionen mit spezifizierenden Informationen, wie Datum, Zeit, User, optionale Kommentare etc.
Reporting: Erstellung von Reports und Statistiken zur Auswertung
von Auflagenhöhe, Abonnentenzahl, Zahl der Seiten-, Inhalts- und
Dokumentabrufen etc.
Plattformunabhängigkeit: Unterstützung verschiedener Hard- und
Softwareplattformen mit der Berücksichtigung grundlegender Aspekte wie Performance, Skalierbarkeit und Ausfallsicherheit.

Protokollierung
Reporting

Plattformunabhängigkeit

4.5
Ausblick
Im Folgenden soll ein Ausblick gegeben werden, welche primären
technologischen Strömungen in Zukunft sich ausprägen werden bzw.
zu erwarten sind. Nicht betrachtet werden insbesondere die immer
wichtiger werdenden Notwendigkeiten zur Berücksichtigung gesetzlicher Regelvorschriften im Umgang mit Content (Stichwort: Compliance-Anforderungen etc.).
Etablierung von CRT-Systeme als Basis-Content-Infrastruktur für EBusiness-Technologien: Content-Related-Technologien werden zukünftig weit mehr als bisher als integrale Basis-Content-Infrastruktur
für alle komplementären E-Business-Technologien, wie E-Commerce,
Customer-Relationship-Management (CRM) oder E-Procurement
eingesetzt werden. Dies schließt nicht nur die Einbindung dezentraler,
verteilter Content-Repositories und die Integration von LegacySysteme ein, sondern beinhaltet auch eine weitere Prozess-Integration, zunehmend auf der Basis dienste-orientierter Architekturen.
Integration unstrukturierter Content-Quellen: Bedingt durch das
rasante Anwachsen von unstrukturierten Inhalten in und aus Web2.0
Communities, werden neben den bisherigen Content-Quellen auch
alle unzureichend erschlossenen, meist „unstrukturierten“ ContentQuellen, vorrangig die sogenannten Blog-Inhalte, in diese Systeme mit
eingebunden bzw. von diesen Systemen effiziente Werkzeuge hierfür
bereitgestellt werden. Diese Integration wird eine der größten Herausforderungen an moderne CRT-Systeme sein.
Stärkung des Multi-Channeling und Cross-Media-Publishing: Die
Publikation von Inhalten wird sich zunehmend auf die unterschiedlichsten Ausgabegeräte erweitern. Dies wird sich neben den klassischen Ausgabekanälen (z. B. Print und Web) auch auf unterschiedlichste Multimedia-Geräte wie Handy, Spielekonsolen, digitales Fernsehen, PDA etc. ausdehnen und dadurch der Forderung nach
konsequent medienneutraler Haltung von Content weiter Gewicht
geben.

4.5 Ausblick

Basis-Content-Infrastruktur für
E-Business-Technologien

Integration unstrukturierter
Content-Quellen

Stärkung des Multi-Channeling und
Cross-Media-Publishing

■
■
■

241

Personalisierung als
entscheidender Faktor

Unterstützung von mobilen Endgeräten
und interaktivem Fernsehen i-TV

Zunehmende Wissensgenerierung

Zunehmende Verknüpfung
mit Produkt-Informations-Systemen

Standardisierungen

Personalisierung als entscheidender Faktor: Die zunehmende Personalisierung von Content in Verbindung mit einem konsequenten
Management des Anwender-Feedbacks wird die Bereitstellung von
Informationen an die Rezipienten entscheidend prägen. Dazu müssen
aber noch ausgereiftere Analysewerkzeuge im Bereich der Personalisierung entwickelt werden.
Unterstützung von mobilen Endgeräten und interaktivem Fernsehen i-TV: Insbesondere die Personalisierungs- und Ortungsmöglichkeiten der meisten mobilen Endgeräte sowie deren zunehmende
Verbreitung werden für eine weitere Unterstützung in ContentSystemen führen. Ergänzend zu den mobilen Endgeräten sieht man
weitere Entwicklungen im Bereich des interaktiven Fernsehens (i-TV).
Zunehmende Wissensgenerierung: Komfortablere Werkzeuge in
CRT-Systemen werden mehr als bisher neue Möglichkeiten zur Gewinnung von neuem Wissen und Erkenntnissen aus Informationen
und Content schaffen. Die automatischen Klassifizierungsverfahren
spielen dabei eine entscheidende Rolle.
Zunehmende Verknüpfung mit Produkt-Informations-Systemen:
Produktinformationen werden vermehrt in CRT-Systemen als Content verwaltet oder gleich integriert werden. In Verbindung mit komfortablen Publishing-Engines von CRT-Systemen und unter Berücksichtigung von effizienten Personalisierungsmethoden werden neben
Standardkatalogen für Print und Online auch immer mehr individualisierte oder zielgruppenspezifische Kommunikationsmittel mit den
jeweiligen Produktinformationen für unterschiedlichste Ausgabeformen erzeugt und kanalspezifisch verteilt werden.
Standardisierungen: Die zunehmende Standardisierung von CRTSchnittstellen wird zu einer Spezialisierung von Content-Bausteinen
für unterschiedlichste Einsatzgebiete führen. Im Gegenzug werden
Datenbank- und Betriebssysteme zukünftig die eigentlichen ContentRepositories über diese standardisierten Schnittstellen zur Verfügung
stellen.

Literatur
Balzert, H.: JSP für Einsteiger. Dynamische Websites mit JavaServer Pages erstellen, W3l, 2003.
Blessing, D.: Content Management für das Business Engineering. Fallbeispiele,
Modelle und Anwendungen für das Wissensmanagement bei Beratungsunternehmen. Dissertation, Universität St. Gallen, St. Gallen, 2001.
Bodendorf, F.: Daten- und Wissensmanagement. 2.Auflage, Springer-Verlag, 2006.
Boiko, B.: Content-Management-Bible. Wiley Publishing, Inc., New York, 2002.
Borghoff, U.M.; Rödig, P.; Scheffczyk, J.: Langzeitarchivierung. dpunkt.verlag,
2003.

242

■
■
■

4 Content-Related-Technologien

BMEcat: E-Commerce Standard BMEcat, www.bmecat.org, www.bme.de, 2001.
Büchner, H. (Hrsg.); Traub, D.; Zahradka, R.; Zschau, O.: Web Content Management. Websites professionell betreiben. Galileo Press, Bonn, 2001.
Bullinger, H.J.; Wörner, K.; Prieto, J.: Wissensmanagement – Modelle und Strategien für die Praxis. In: H.D. Bürgel (Hrsg.): Wissensmanagement – Schritte
zum intelligenten Unternehmen. Springer-Verlag, Berlin, 1998.
Bullinger, H.J. (Hrsg.); Schuster, E.; Wilhelm, S.: Content Management Systeme.
Auswahlstrategien, Architekturen und Produkte. Verlagsgruppe Handelsblatt, Düsseldorf, 2001.
Christ, O.: Content-Management in der Praxis. Spinger-Verlag, Berlin, 2003.
Delp, M.: Media Warehouse – was die Medienindustrie braucht. Aus: IFRA
(Hrsg.): Pre-Publishing – the new Pre Press for modern Publishing. Darmstadt, 1998.
Dörner, J.-H.: Personalisierung im Internet. Persönliche Empfehlungen mit Collaborative Filtering. Verlag Kovac J, 2003.
Donovan, T.: Wirtschaftliche Gründe für Content Management. Ein Leitfaden für
Führungskräfte. Trend Consulting, London, 2001.
Dreyer, R.: Der Farbmanagement-Workflow bei der Filmdigitalisierung von Archivgut. Aus: Maier, G.; Fricke, T. (Hrsg.): Kulturgut aus Archiven, Bibliotheken und Museen im Internet. Werkhefte der staatlichen Archive Baden
Württemberg, Band A17. Kohlhammer, Stuttgart, 2004.
Dustdar, S.; Gall, H.; Hauswirth, M.: Software-Architekturen für Verteilte Systeme.
Springer-Verlag, Berlin, 2003.
Eisele, M.: Dokumenteneintopf: JSR-170: Einheitlicher Zugriff auf Unstrukturiertes. iX 1/2006.
Fritsche, H.P.: Cross Media Publishing. Konzept, Grundlagen und Praxis. Galileo
Press, Bonn, 2001.
Gierhake, O.: Integriertes Geschäftsprozessmanagement: effektive Organisationsgestaltung mit Workflow-, Workgroup- und DokumentenmanagementSystemen. Vieweg Verl., Braunschweig. Wiesbaden, 1998.
Gierling, R.: Farbmanagement. Mitp-Verlag, 2004.
Götzer, K.; Schneiderath, U.; Maier, B.; Boehmelt, W.: Dokumenten-Management.
dpunkt.verlag, 2004.
Großmann, M.; Koschek, H.: Unternehmensportale Grundlagen, Architekturen,
Technologien. Springer-Verlag, Berlin, 2005.
Gulbins, J.; Seyfried, M.; Strack-Zimmermann, H.: Dokumenten-Management.
Springer-Verlag, Berlin, Heidelberg, New York, 2002.
Hentrich, H.: B2B-Katalogmanagement – E-Procurement und Sales mit XML.
Galileo Press, Bonn, 2001.
Hess, T.; Eggers, B.; Schulze, B.: Synergien realisieren durch die Mehrfachnutzung
von Inhalten im Rahmen von Verwertungsketten: Der Fall Frankfurter Allgemeine Zeitung (FAZ). Arbeitsbericht Nr. 8/2003 des Instituts für Wirtschaftsinformatik und Neue Medien an der Ludwig-Maximilians-Universität, München, 2003.
Jablonski, S.; Böhm, M.; Schulze, W. (Hrsg.): Workflow-Management. Entwicklung von Anwendungen und Systemen. dpunkt.verlag, Heidelberg, 1997.
Kampffmeyer, U.: Dokumenten-Technologien: Wohin geht die Reise? PROJECT
CONSULT, 2003.

Literatur

■
■
■

243

Kreikle, M.: Grundlagen: Urheberrechtsfragen in Media Asset Management.
07/2001 ContentManager.de.
Kretzschmar, O.; Dreyer, R.: Medien-Datenbanken und Medien-Logistik-Systeme.
Oldenbourg Verlag, München, 2003.
Merz, T.: Web Publishing with Acrobat/ PDF. Springer-Verlag, Berlin, 1998.
Meyer-Wegener, K.: Multimediale Datenbanken. Teubner, 2003.
Rockley, A.: Managing Enterprise Content. New Riders, Indianapolis, 2003.
Rothfuss, G.; Ried C.: Content Management mit XML. Springer-Verlag, Berlin,
Heidelberg, New York, 2001.
Runte, M.: Personalisierung im Internet. Deutscher Universitäts-Verlag, 2000.
Schäuble, P.: Multimedia Information Retrieval. Kluwer Academic Publishers,
1997.
Schmid, D.: Wettbewerbsvorteile durch Media Asset Management in der Medienbranche. Diplomarbeit an der Hochschule der Medien, 2004.
Schneider, U.; Werner D.: Taschenbuch der Informatik. Hanser Fachbuchverlag
Leipzig, 2004.
Schumann, M.; Hess, T. (Hrsg.): Medienunternehmen im digitalen Zeitalter. Neue
Technologien – Neue Märkte – Neue Geschäftsansätze. Gabler, Wiesbaden,
1999.
Semio: Automatic Taxonomy Building. An Semio White paper, Semio Corporation, San Mateo, 2000.
Wilhelm, R.; Heckmann, R.: Grundlagen der Dokumentenverarbeitung. Oldenbourg, 1996.
Wittkewitz, J.: Ausgepresst. Automatische Klassifizierung von Dokumenten. IX
12/2001.

244

■
■
■

4 Content-Related-Technologien

5 Usability und Design
Michael Burmester

5.1
Usability
5.1.1
Mensch und Computer
Ob in der Freizeit oder im Beruf – Computer werden immer mehr zu
einem Bestandteil unserer alltäglichen Erfahrung. Sie tauchen als Bildschirmarbeitsplätze (im Jahre 2005 nutzten 57% aller Deutschen am
Arbeitsplatz einen PC, BITKOM 2006c) und Heimcomputer (58% der
deutschen Bevölkerung hatten 2005 einen Internetzugang, BITCOM
2006a) auf. Computer „verstecken“ sich aber auch in vielen Geräten.
Im Freizeitbereich findet man sie in Digitalkameras, Fahrzeugnavigationssystemen, Mobiltelefonen (95% der Deutschen besaßen in 2005
ein Mobiltelefon, BITCOM 2006b), MP3-Player, Harddisk-Rekorder,
Interaktivem Fernsehen, Radioweckern, programmierbaren Kochherden, Waschmaschinen, Hausautomatisierung, Kinderspielzeug, Fahrkartenautomaten, Informationskioske etc. Im professionellen Umfeld
finden sich Computer in Schweißmaschinen, Laserschneidegeräten,
Ultraschallgeräten, Motorenprüfsystemen, Sachbearbeitersoftware,
Content-Management-Systemen (CMS), Projektiersoftware für automatisierungstechnische Anlagen, betriebswirtschaftliche Software etc.
Computer halten Einzug in die unterschiedlichsten Bereiche des Lebens. Begleitend dazu sind immer wieder die gleichen Folgen festzustellen:

Computer als Bestandteil
alltäglicher Erfahrung

• Zunehmende Funktionalität
• Zunehmende Interaktionsmöglichkeiten zwischen Mensch und
Computer
• Zunahme der angebotenen Informationen
Der Mensch kommuniziert mit dem Computer über die Benutzungsschnittstelle. Jef Raskin, der Vater des Apple Macintosh User

5.1 Usability

Benutzungsschnittstelle ist
das eigentliche Produkt

■
■
■

245

Qualität der Nutzung

Interfaces, schreibt in seinem Buch „Das intelligente Interface“: „Soweit es den Verbraucher betrifft, ist die Oberfläche das eigentliche
Produkt“ (Raskin 2000, S. 22). Nur wenn die Benutzungsschnittstelle
optimal auf den Benutzer, seine Aufgaben und die Anwendungsumgebung abgestimmt ist, kann das Produkt mit einem angemessenen
Aufwand erfolgreich genutzt werden. Der komfortablen Nutzung in
unterschiedlichen Nutzungssituationen wird also eine entscheidende
Bedeutung zugeschrieben. Gesprochen wird von leichter Erlernbarkeit, Benutzungs- oder Benutzerfreundlichkeit, Ease of Use, Ease of
Learning, Gebrauchstauglichkeit, Usability, Nutzungsqualität.
Diese Qualitäten sind vor allem auch durch die Frage nach der richtigen Gestaltung von Websites und Web-Applikationen in die öffentliche Diskussion geraten. Internetnutzung unterscheidet sich in einem
ganz wesentlichen Aspekt von der Nutzung anderer computerbasierter Produkte. Im Internet werden die Benutzer zuerst mit der Qualität
der Nutzung konfrontiert. Kann der Benutzer die gewünschten Informationen nicht zügig finden, so wechselt er die Website einfach. Bei
anderen Produkten erfolgt zunächst der Kauf. Hier machen die Käufer
erst einmal keine Erfahrung mit der Nutzung der Geräte. Sie lassen
sich vielleicht eher durch umfangreiche Funktionslisten und Informationsangebote beeindrucken. Im professionellen Umfeld wird den
Benutzern beispielsweise der Bildschirmarbeitsplatz vom Arbeitgeber
eingerichtet. Von den Benutzern wird gefordert, mit den Applikationen zu arbeiten, die für ihre Aufgaben relevant sind. Erst wenn es an
die Nutzung geht, wird deutlich, wie gut oder schlecht der Bildschirmarbeitsplatz ist. So machen sich auch bei diesen Produkten mangelnde
Produktivität, geringe Akzeptanz, hohe Schulungskosten etc. negativ
bemerkbar (Bias & Mayhew 1994, 2005; Kalbach 2003; Marcus 2002).

5.1.2
Usability als Qualität der Nutzung
Aspekte von Usability

246

■
■
■

Nielsen (1993, S. 24 f.) sieht Usability als einen von zwei Aspekten der
„Usefullness“ (Brauchbarkeit) eines Produkts. Neben der sozialen
Akzeptanz wird sie als Bestandteil der praktischen Akzeptanz eines
Systems gesehen. Die „Usefullness“ beschreibt Nielsen (1993, S. 24 ff.)
als „Utility“ (Nützlichkeit) und „Usability“ (Bedienbarkeit). Bei Utility
stehen die Funktionen im Vordergrund, die für eine bestimmte Aufgabe notwendig sind. Als Usability bezeichnet er den Zugang zu diesen Funktionen. Somit wird Usability allein mit der Einfachheit der
Nutzung in Verbindung gebracht („Ease of use“). Damit einher geht
häufig das Missverständnis, dass durch genügend Wissen über die
Gestaltung von Benutzungsschnittstellen Usability erzeugt werden
könne. Usability wird also als Eigenschaft des Produkts gesehen und

5 Usability und Design

gilt als Qualitätsmerkmal des Zugangs zu vordefinierten Funktionen.
Dieser Sichtweise von Usability wird mit der Norm DIN EN ISO 9241
Teil 11 (1998) eine andere Sichtweise entgegengesetzt (Bevan 1995).
Usability oder Gebrauchstauglichkeit, wie es in der offiziellen deutschen Übersetzung der internationalen Norm ISO 9241 Teil 11 heißt,
wird definiert als „das Ausmaß, in dem ein Produkt durch bestimmte
Benutzer in einem bestimmten Nutzungskontext genutzt werden
kann, um bestimmte Ziele effektiv, effizient und zufrieden stellend zu
erreichen“ (DIN EN ISO 9241-11 1998, S. 4). Ganz wesentlich an dieser
Definition ist, dass über Usability nur etwas ausgesagt werden kann,
wenn der Nutzungskontext bekannt ist. Der Nutzungskontext umfasst
die Benutzer, die von ihnen zu erledigenden Aufgaben, die Arbeitsmittel sowie die physische und soziale Umgebung, in der das Produkt
genutzt wird.
Nigel Bevan, der Herausgeber von Teil 11 der ISO 9241, weist darauf hin, dass es sich bei Usability um eine Qualität der Nutzung handelt. Es lässt sich also nicht anhand der reinen Produkteigenschaften
entscheiden, ob ein Produkt gebrauchstauglich ist oder nicht. Das
Produkt muss immer in Bezug zum Nutzungskontext betrachtet werden. Bevan schreibt „[…] there is no such thing as a ‚usable product‘
or ‚unusable product‘. For instance a product which is unusable by
inexperienced users may be quite usable by trained users“ (Bevan
1995) und spricht von „Quality of use“. Er weist explizit darauf hin,
dass Qualität in der Softwarebranche häufig damit assoziiert wird, die
Spezifikation einzuhalten. Für die Qualität der Nutzung reicht das
allerdings nicht aus. Diese wird nur erkannt, wenn das Produkt in
dem jeweiligen Nutzungskontext genutzt werden kann. Bevan schreibt
dazu: „However this alone is rarely sufficient to ensure quality of use –
that the product can be used for its intended purpose in the real
world“ (Bevan 1995).
Die Usability-Definition wurde entwickelt, um die Evaluation von
Produkten zu ermöglichen. Somit sind die zentralen Kriterien für
Usability eben Effektivität, Effizienz und Zufriedenstellung (vgl.
Abb. 5.1). Aber auch die Gestaltung selbst profitiert von diesem Verständnis. Die Analyse des Nutzungskontextes ist daher zentraler Bestandteil des benutzerzentrierten Gestaltungsprozesses, wie er in der
DIN EN ISO 13407 (2000) beschrieben wird.
In der Usability-Definition findet sich ein Hinweis auf Zielorientierung. Der Definition liegt die Vorstellung zugrunde, dass Benutzer
Ziele erreichen wollen. Diese Ziele werden als das angestrebte Arbeitsergebnis verstanden. Die dafür notwendigen Aktivitäten werden in der
Norm als Aufgabe definiert. Das Produkt soll die Benutzer so unterstützen, dass sie ihre Ziele vollständig und genau, d. h. effektiv erreichen können. Der Aufwand, den die Benutzer dabei einsetzen müssen,

5.1 Usability

Usability-Definition

Zentrale Bedeutung des
Nutzungskontexts

Effektivität, Effizienz und
Zufriedenstellung

■
■
■

247

Abb. 5.1:
Einfluss des Nutzungskontextes auf die
Usability-Kriterien (nach Bevan 1995)

wird als Effizienz beschrieben. Er wird im Verhältnis zur Genauigkeit
und Vollständigkeit der Zielerreichung gesehen. Werden die Ziele mit
angemessenem Aufwand erreicht, führt dies zur Zufriedenstellung der
Benutzer. Damit ist gemeint, dass der Benutzer bei der Nutzung des
Produkts nicht beeinträchtigt wird (z. B. erhöhte Anstrengung durch
zu kleine Schriften oder missverständliche Interaktionen). Darüber
hinaus entwickelt der Benutzer eine positive Einstellung zum Produkt,
was eine wiederholte Nutzung fördert. Damit die Ziele auch wirklich
effektiv und effizient erreicht werden können, muss das Produkt an
die Bedingungen des Nutzungskontextes angepasst sein. Dazu gehört,
dass das Produkt über die Funktionen und Inhalte verfügt, die zur
Zielerreichung benötigt werden. Zudem muss der Zugang zu Funktionen und Inhalten leicht zu erlernen und zu handhaben sein.

248

■
■
■

5 Usability und Design

Die von Bevan (1995) und in der DIN EN ISO 9241-11 (1998) beschriebenen Zusammenhänge wurden für den Einsatz von computerisierten Produkten in der Arbeitswelt definiert. In der Praxis wird jedoch auch bei Produkten der Unterhaltungselektronik, wie z. B. einem
MP3-Player, von Usability gesprochen. Prinzipiell ist dies auch möglich. Wichtig ist nur zu verstehen, dass die Ziele nicht immer aus einer
Arbeitsorganisation generiert werden (siehe Abb. 5.1), sondern
durchaus auch von den Benutzern selbst (z. B. das Abspielen einer
bestimmten Playlist) oder aber aus anderen sozialen Kontexten als
den beruflichen. Ein Beispiel dafür ist das familiäre Betrachten des
Urlaubsfilms auf DVD: Dem „Fernbedienungsinhaber“ wird von der
Familie gesagt, dass eine Szene noch einmal gezeigt werden soll. In
diesem Fall generieren die Familienmitglieder ein Ziel, das der Benutzer übernehmen kann. Produkte werden aber auch ohne explizite
Zielstellung genutzt. Bei Computerspielen steht zwar das Ziel im
Raum, zu gewinnen. Im Vordergrund steht jedoch die Aktivität. Oft
dient aktivitätsorientiertes Verhalten auch der Zielfindung, wenn sich
der Benutzer beispielsweise durch das Angebot eines Online-Shops
anregen lässt.
Carroll plädiert für eine Erweiterung des Usability-Begriffs: „I would
urge that we construct a broader, more encompassing concept of „usability“, one that incorporates „fun“ and other significant aspects of the
experience of human interaction with technology, rather than settling
for the primitive caricature of usability as synonymous with simplicity
and ease, and regarding fun (and other aspects of the user experience)
as something beyond or aside of usability.“ (Carroll 2004, S. 39). Wie
auch später noch erläutert wird (siehe Kap. 5.2.5), spielt Spaß an der
Nutzung eine entscheidende Rolle bei der Benutzererfahrung mit einem Produkt. Carroll (2004) bezieht als weitere Qualitäten das Wohlbefinden der Person, das Erleben der Selbstwirksamkeit oder der kollektiven Wirksamkeit sowie das der kulturellen Identität mit ein.

Usability jenseits der Arbeitswelt

Erweiterung des Usability-Begriffs

5.1.3
Nutzen von Usability
Auch wenn Usability in Normen eingeflossen ist (s.o. sowie Norm zur
Softwarequalität DIN ISO/IEC 12119 1995), werden nach wie vor Diskussionen um den Nutzen von Usability geführt. Allerdings hat sich
die missionarische Haltung der Usability Professionals, wie sie in den
80er Jahren und Anfang der 90er noch vorherrschte, etwas gewandelt.
Schon 1994 rechneten Randolph G. Bias und Deborah J. Mayhew in
ihrer Aufsatzsammlung „Cost-Justifying Usability“ mit mehreren
Autoren vor, dass sich Usability auch ökonomisch auszahlt und rechtfertigen lässt. Im Nachfolgewerk aus dem Jahre 2005 „Cost Justifying

5.1 Usability

Cost-Justifying Usability

■
■
■

249

Return on Investment

Usability – An Update for the Internet Age“ wird dargelegt, dass sich
seit den 90ern Usability-Engineering-Methoden und benutzerzentrierte Gestaltung bei einigen Firmen etabliert haben. Allerdings wurde
bemerkt, dass dies nur teilweise zufriedenstellend geschieht und dass
immer noch zu viele Produkte mit eindeutigen Usability-Problemen
auf dem Markt sind. Die Notwendigkeit, Usability-Maßnahmen zu
rechtfertigen, besteht weiterhin (Bias & Mayhew 2005, S. 2).
Somit ist der Ruf nach Return on Investment (ROI) bzw. die „Rendite der Investition“ (Hinderberger 2003, S. 30) in Bezug auf UsabilityMaßnahmen deutlich. Hinderberger (2003, S. 31) präsentiert eine
einfache Formel, mit der grobe Rechnungen zum ROI angestellt werden können:
⎛ ∑ Einkünfte
⎞
⋅100 ⎟ − 100
ROI = ⎜
⎜ ∑ Kosten
⎟
⎝
⎠

Effekt von Usability-Maßnahmen

250

■
■
■

Einkünfte und Kosten werden auf einen bestimmten Zeitraum bezogen. So lassen sich einfache Abschätzungen über das Verhältnis von
Kosten (z. B. von Usability-Maßnahmen) und den erzielten Einkünften machen. Insgesamt ist die ROI-Berechnung nicht trivial. Weitere
Informationen finden sich bei Hinderberger (2003, S. 24 ff.).
Der Effekt von Usability-Maßnahmen lässt sich oft schon anhand
einfacher Hochrechnungen ermitteln. So fand Brodbeck (1991) heraus, dass für Fehlerbewältigung 10% der Terminalzeit verwendet wird.
Dies sind 6 Minuten pro Stunde. Nehmen wir nun ein kleines Unternehmen mit 200 Mitarbeitern. Diese arbeiten 300 Tage pro Jahr und
erzeugen Kosten von 200 Euro pro Tag und Mitarbeiter. Gehen wir
davon aus, dass die Mitarbeiter von ihren 8 Stunden Arbeitszeit nur
4 Stunden wirklich am Bildschirm sitzen, dann ergibt sich eine Summe von 600.000 Euro, die für Fehlerbewältigung bezahlt wird. Würde
durch Usability-Maßnahmen die Fehlerbewältigungszeit um die Hälfte reduziert, dann ergibt sich eine Reduktion der Kosten für unproduktive Fehlerbewältigung um 300.000 Euro pro Jahr. In dieser sehr
simplen Rechnung geht nur die Produktivitätsüberlegung ein. Es gibt
jedoch noch weitere Faktoren, die eine Rolle spielen.
Tabelle 5.1 zeigt, dass Usability-Maßnahmen aus Sicht von Herstellern (Software, Geräte etc.) oder Betreibern (z. B. von Websites) wichtige Vorteile mit sich bringen: Kosten- und Zeitersparnis während der
Entwicklung, Umsatz- und Gewinnpotenzial, die Möglichkeit, neue
Kunden zu generieren und bestehende Kunden zu behalten. Durch
hervorragende Usability können sich Hersteller und Betreiber auf dem
Markt differenzieren bzw. Usability-Maßnahmen auch als Quelle für
Innovationen nutzen. Für Anwender (z. B. Unternehmen, die eine
bestimmte Software für ihre Mitarbeiter einsetzen) und Benutzer (die

5 Usability und Design

Mitarbeiter, die mit der Software arbeiten) liegen die Vorteile ebenfalls in der Einsparung von Kosten, z. B. für Schulungen, und ganz
deutlich in der erhöhten Produktivität. Steigende Zufriedenheit unter
den Benutzern, geringere Risiken für Erkrankungen sowie die Einhaltung von Vorschriften sind deutliche Argumente für Usability-Maßnahmen. Tabelle 5.1 präsentiert zu jedem Nutzenargument exemplarisch Studien, die dieses Argument stützen (aus Bias & Mayhew
1994, 2005; Kalbach 2003 und Marcus 2002).
Nutzenargument

Tabelle 5.1:
Argumente zur Rechtfertigung
von Usability-Maßnahmen

Studie

für Hersteller und Betreiber
Kostenersparnis

Die Kostenersparnis in der Entwicklung ist umso deutlicher, je früher Usability-Maßnahmen im Entwicklungsprozess eingesetzt werden. Gilb (1988)* zeigt, dass 1 $, der
in frühen Phasen der Entwicklung für UsabilityMaßnahmen ausgegeben wurde, 10 $ für Fehlerkorrekturen in der Implementierung und bis 100 $ für Korrekturen
nach der Auslieferung spart.
Bei der Wartung von Systemen konnten Nachbesserungen, die auf Usability-Probleme zurückgehen, um 60−90%
reduziert werden (Harrison et al. 1994*).

Zeitersparnis

Die Anforderungen an ein Produkt genau zu erheben
spart Zeit: Zeiten für die Entwicklung nicht benötigter
Funktionen und Zeiten für die Nachbesserung übersehener Nutzeranforderungen. Ehrlich und Rohn (1994)*
errechnen 40% Ersparnis und Bosert (1991)* zwischen
30% und 50%.

Umsatz & Gewinne

Wixon und Jones (1995)* stellen fest, dass die Erlöse für
ein Softwareprodukt nach dem Einsatz von UsabilityMaßnahmen um 80% anstiegen.
Nach der benutzerfreundlichen Umgestaltung des IBMOnline-Shops stieg nach einer Studie von Battey (1999)*
die Nutzung um 120% und die Umsätze um 400%.

Neue Kunden

Eine größere Umgestaltung von staples.com nach Usability-Kriterien führte zu einer Reduktion der ‚drop off rates‘
um 31−45% und eine Erhöhung der wiederkehrenden
Kunden um 67%.
Eine Studie zeigt, dass 83% der Studienteilnehmer OnlineShopping als besonders einfach und komfortabel bewerten. Darauf weist Nielsen (1999)* hin. Schlechte Usability
sollte diese positive Einstellung nicht beeinträchtigen.

5.1 Usability

■
■
■

251

Nutzenargument

Studie

Kundenloyalität

Kalin (1999) weist darauf hin, dass schlechte Usability zu
einem Rückgang der wiederkehrenden Kunden um 40%
führte. Nielsen (1997)* zeigt, dass wiederkehrende Kunden doppelt so viel in einem Online-Shop ausgeben wie
Erstkunden.

Differenzierung

Usability ist mittlerweile Bestandteil von Software-, Produkt- und Site-Bewertungen in Zeitschriften, Magazinen
und Testorganisationen (Kalbach 2003). Nach Nielsen
(1993)* beschäftigen sich 15% von Technologiebeurteilungen in Zeitungen, Magazinen und Journalen mit Usability-Fragestellungen.
Häufig können Produkte nicht mehr über Funktionen auf
dem Markt differenziert werden, sondern eher über gute
Usability.

Innovationsfaktor

Ein bisher vernachlässigter, aber nicht zu unterschätzender Faktor bei Usability-Maßnahmen ist, dass nicht nur
technologische Innovationen gebrauchstauglich gemacht
werden können, sondern dass durch UsabilityMaßnahmen auch Produktinnovationen initiiert werden
(Burmester & Görner 2003; Kalbach 2003).

für Anwender und Benutzer

252

■
■
■

Kostenersparnis

Die Schulungszeit in einem Unternehmen konnte durch
die Verbesserung der Usability von einer Woche auf eine
Stunde reduziert werden (Marcus 2005). Die Firma AT&T
sparte durch ähnliche Maßnahmen 2,5 Mio. $ (Harrison
et al. 1994)*.

Produktivität

Die Produktivität steigt durch Reduktion der Aufgabenbearbeitungszeiten (Karat 1994)*, Reduktion der Fehlerhäufigkeit (Gallaway 1981)* und Steigerung der Erfolgsraten (Nielsen 1998)*.

Zufriedenheit

Die Gardener Group (1992) ermittelte nach Anwendung
von Usability-Methoden bei der Entwicklung einer Software eine erhöhte Zufriedenheit um 40% (Harrison et al.
1994)*.

Gesundheit

Fehlerbewältigung bei Bildschirmarbeiten erhöht die
mentale Beanspruchung (Brodbeck 1991). Studien zeigen,
dass bei Benutzern an Bildschirmarbeitsplätzen mehr
Schulter- und Nackenprobleme, Überanstrengung der
Augen, Abwesenheit von der Arbeit, geringere Arbeitszufriedenheit und höhere Fluktuation als an anderen Arbeitsplätzen auftreten (Schneider 1985)*.

5 Usability und Design

Nutzenargument

Studie

Gesetze

Die Verordnung über Sicherheit und Gesundheitsschutz
bei der Arbeit an Bildschirmgeräten (Bildschirmarbeitsverordnung (1996) ist seit dem 21. Dezember 1996 in Kraft
und stellt klare software-ergonomische Anforderungen an
die Gestaltung von Software an Bildschirmarbeitsplätzen.
Seit dem 17. Juli 2002 gilt die „Verordnung zur Schaffung
barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz“ (BITV 2002). Demnach soll
Menschen mit Sinnes- und Körperbehinderungen die
Nutzung des Internets erleichtert werden.

*zitiert nach Marcus (2005)

5.2
Theoretische Grundlagen
5.2.1
Überblick
Usability-Engineering wird als eine angewandte Disziplin beschrieben,
die mit Hilfe systematischer Methoden versucht, Usability bei der
Gestaltung von Benutzungsschnittstellen zu erreichen (Mayhew 1999).
Benutzungsschnittstelle wird in der DIN EN ISO 9241-110 (2006) definiert als „alle Bestandteile eines interaktiven Systems (Software oder
Hardware), die Informationen und Steuerelemente zur Verfügung
stellen, die für den Benutzer notwendig sind, um eine bestimmte Arbeitsaufgabe mit dem interaktiven System zu erledigen.“ Ein interaktives System ist gekennzeichnet durch „die Kombination von Hardware- und Softwarekomponenten, die Eingaben von einem (einer)
Benutzer(in) empfangen und Ausgaben zu einem (einer) Benutzer(in)
übermitteln, um ihn (sie) bei der Ausführung einer Arbeitsaufgabe zu
unterstützen“ (DIN EN ISO 13407 2000, S. 3). Im Folgenden werden
interaktive Systeme auch einfach als Produkt bezeichnet.
Theoretische Grundlagen bilden den Rahmen für alle Maßnahmen,
die im Usability-Engineering angewandt werden. Human-Computer
Interaction (HCI, oder Mensch-Computer-Interaktion, MCI) gilt als
wissenschaftliche Disziplin, die sich damit beschäftigt, wie Menschen
Geräte und Systeme nutzen, die auf Computertechnologie basieren.
Beeinflusst von Psychologie, Soziologie, Kognitionswissenschaft, Arbeitswissenschaft, Ergonomie und Design auf der einen Seite und
Informatik auf der anderen Seite, geht es darum, wie solche Geräte
und Systeme nützlicher und nutzbarer gestaltet und entwickelt wer-

5.2 Theoretische Grundlagen

Usability-Engineering

Human-Computer Interaction

■
■
■

253

Theorien

254

■
■
■

den können. Dabei wurde eine Fülle theoretischer Grundlagen erarbeitet (Jacko & Sears 2003; Carroll 2003). Dazu gehören Grundlagen,
die sich um das Verständnis des Menschen drehen. Dies sind Theorien zur Wahrnehmung (Ware 2003), zu motorischem Verhalten
(MacKenzie 2003) und menschlicher Informationsverarbeitung (John
2003; Proctor & Vu 2003), mentale Modelle (Dutke 1994), Emotion
(Brave & Nass 2003), Informationssuche (Pirolli 2003), verteilte Kognition (Perry 2003) und Handlungstheorie (Bertelsen & Bødker 2003;
Frese & Zapf 1994). Theoretische Grundlagen bezogen auf den Computer beinhalten Themen wie Eingabegeräte (Hinkley 2003; Ziegler &
Burmester 1997) und Ausgabe von Information (Brewster 2003; Iwata
2003; Luczak, Rötting & Oehme 2003). Bei der Frage der Interaktion
geht es beispielsweise grundlegend um den Einsatz von Multimedia
(Sutcliffe 2003), Multimodalität (Oviatt 2003) oder Adaptivität (Jameson 2003). Zudem spielen Fragen zu Anforderungen spezieller Benutzergruppen eine Rolle, wie z. B. ältere Benutzer (Czaja & Lee 2003)
oder Menschen mit Behinderungen (Sears & Young 2003; Jacko, Vitense & Scott 2003). Ebenso werden Erkenntnisse zu unterschiedlichen Anwendungsformen entwickelt, wie beispielsweise Informationsvisualisierung (Bederson & Shneiderman 2003) oder ComputerSupported Cooperative Work (CSCW, Olson & Olson 2003).
Im Folgenden sollen vier ausgewählte Theoriebereiche erläutert
werden. Zunächst wird ein Modell der Interaktion von Mensch und
Computer beschrieben. In der Informations- und Wissensgesellschaft
spielt die Nutzung von Informationen eine wichtige Rolle. In diesem
Modell wird explizit das Spannungsverhältnis zwischen dem Informationsanbieter und dem Informationsnutzer angesprochen. In den zwei
folgenden theoretischen Ansätzen geht es um die Suche nach Informationen und die durch die Benutzer wahrgenommene Glaubwürdigkeit der Informationsquelle. Diese ist speziell für Anbieter von Informationen wichtig, da Glaubwürdigkeit eine Voraussetzung dafür ist,
seine Ziele durchzusetzen. Informationen werden von Benutzern im
Rahmen von Aufgabenstellungen und persönlichen Informationszielen gesucht und genutzt. Nur Informationen aus glaubwürdigen Quellen werden von Benutzern verwendet. Sie haben das Potenzial Wissen,
Einstellungen oder Verhalten von Benutzern zu ändern. Benutzer zu
beeinflussen kann im Rahmen der Ziele von Anbietern liegen, z. B.
wenn Personen durch eine Energiespar-Website von umweltfreundlichem Verhalten überzeugt werden sollen. Im letzten Ansatz wird das
Konzept der Usability als Qualität der Nutzung um hedonische Aspekte erweitert und zu einer Theorie der Attraktivität integriert.

5 Usability und Design

5.2.2
Ein Modell zur Nutzung interaktiver Systeme
5.2.2.1
Werkzeug oder Medium
Die Usability-Definition der DIN EN ISO 9241 Teil 11 (1998) wurde
ursprünglich für Software entwickelt, die Bürotätigkeiten unterstützt
(„ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten“, DIN EN ISO 9241 1996–1998). Bei diesen Anwendungen
steht die Manipulation von Daten und Informationen im Vordergrund, wie beispielsweise die Verwaltung von Kundendaten und
-verträgen in Versicherungsunternehmen. Solche Produkte lassen sich
als Werkzeuge bezeichnen. Mediale Aufbereitung von Informationen
wird immer wichtiger und ist integraler Bestandteil solcher Werkzeuge. Hierzu zählen beispielsweise Geschäftsgrafiken als Bestandteil von
betriebswirtschaftlicher Software (Enterprise-Software) oder Aufbereitung von Parametern in der Prozesskontrolle, beispielsweise in der
chemischen Industrie. Bei anderen interaktiven Systemen hingegen
steht die Informationsvermittlung im Vordergrund, wie beispielsweise
bei interaktiven Wissensmedien (Eibl et al. 2006). Diese Art von Systemen hat auf der einen Seite einen Werkzeugcharakter, denn Benutzer suchen Informationen, analysieren diese, eignen sie sich an, stellen
neues Wissen her, verteilen es, bewahren und nutzen es. Auf der anderen Seite haben Medien einen Kommunikationsaspekt. Bei Wissensmedien verfolgt der Anbieter von Informationen auch bestimmte
Ziele.
Andere Systeme, wie z. B. Computer-Spiele, fallen aus dem beschriebenen Raster heraus, denn bei ihnen steht weder die ziel- oder
aufgabenorientierte Manipulation von Informationen noch das Vermittlungsinteresse eines Informationsanbieters im Vordergrund.
Auch wenn Spieler natürlich das Ziel z. B. eines Highscores verfolgen,
so steht doch der Genuss der Aktivität selbst im Fokus. Spiele müssen
natürlich benutzbar sein (Jørgensen 2004), da sie sonst keine Freude
bringen. Zum anderen müssen Spiele auf den Genuss hin optimiert
werden (Pagulayan, Steury, Fulton & Romero 2003).
In der Norm zur Gestaltung multimedialer Produkte DIN EN ISO
14915 (2002) „Software-Ergonomie für Multimedia-Benutzungsschnittstellen“ wird im „Teil 1: Gestaltungsgrundsätze und Rahmenbedingungen“ zu den speziellen Gestaltungsgrundsätzen für Multimedia mit dem Grundsatz „Eignung für das Kommunikationsziel“
verdeutlicht, dass in der Gestaltung sowohl die Ziele des Anbieters
einer Information als auch die Ziele des Benutzers der Information
berücksichtigt werden müssen (DIN EN ISO 14915 2002, S. 9).

5.2 Theoretische Grundlagen

Computer als Werkzeug zur
Unterstützung von Arbeit
oder als Medium zur Vermittlung
von Informationen

Norm zur Gestaltung multimedialer
Produkte DIN EN ISO 14915

■
■
■

255

Bestandteile des Modells

5.2.2.2
Das Modell
Um die Komponenten zu identifizieren und zu beschreiben, die bei
der Erreichung einer hohen Nutzungsqualität bzw. Usability berücksichtigt werden müssen, wird ein Modell zur Nutzung interaktiver
Systeme vorgestellt (vgl. Burmester 2006).
Das Modell (vgl. Abb. 5.2) basiert auf folgenden Modellen und theoretischen Grundlagen: DIN EN ISO 9241-11 (1998) und DIN EN ISO
14915-1 (2002) sowie Donald Norman (1986) und Horst Oberquelle
(1994).
Zusätzlich zu den klassischen Modellansätzen der Mensch-Computer-Interaktion (wie das ABC-Modell, Frese & Zapf 1991 oder dem
IFIP-Modell, Dzida 1983) wurde der Anbieter von Informationen gemäß der DIN EN ISO14915-1 (2002) mit aufgenommen.
Aufgrund der Fokussierung auf Usability fehlen bestimmte Gestaltungsaspekte von interaktiven Systemen. Dazu gehören beispielsweise
didaktische Aspekte des Erlernens, Präsentierens, Abrufens und Nutzens von Wissen durch den Benutzer. Aspekte der Kommunikation
und Kollaboration von Benutzern, die bei Wissensmedien wie z. B.
E-Learning-Produkten recht häufig vorkommen, werden nur angedeutet.

Abb. 5.2:
Modell zur Nutzung interaktiver Systeme
(nach Burmester 2006)

Ziele von Anbietern

5.2.2.3
Anbieter
Anbieter von Informationen verfolgen u. a. folgende Ziele mit ihrem
Informationsangebot:
• Benutzer sollen über bestimmte Themen informiert werden, z. B.
zum Unternehmen.
• Informationen zu kommerziellen Zwecken anbieten, wie z. B. kostenpflichtig herunterladbare Produkttests.
• Produkte verkaufen, wie z. B. bei Online-Reisebüros.

256

■
■
■

5 Usability und Design

• Bestimmte Inhalte im Rahmen einer Online-Lehrveranstaltung
vermitteln
• Das Verhalten der Benutzer beeinflussen, z. B. Informationen über
den Klimawandel vermitteln, um Personen von einem bewussten
Umgang mit fossilen Brennstoffen zu überzeugen.
Die Gestaltung des jeweiligen interaktiven Systems wird vom Anbieter so beeinflusst, dass seine Ziele optimal erreicht werden. Auch
wenn der Anbieter die Gestaltung nicht selbst in die Hand nimmt, so
wird er doch Ziele und Anforderungen für einen externen Gestalter
formulieren.
Wie später noch genauer beschrieben wird, ist es notwendig, Informationen aus den verschiedenen Nutzungskontexten als Ausgangsmaterial zu sammeln und zu analysieren. Zudem können Anbieter zur Optimierung ihres interaktiven Systems Daten aus den Interaktionen der Benutzer (z. B. Log-Files) und direkte Rückmeldung oder
Fragen der Benutzer zu den angebotenen Informationen verwenden.
Diese Informationen können zur Folge haben, dass Inhalte und deren
Präsentation geändert oder aber neue Inhalte hinzugefügt werden
(Jameson 2003).
5.2.2.4
Benutzer
Bei der aktiven Nutzung eines interaktiven Systems verfolgen die Benutzer eigene Ziele bzw. bearbeiten Aufgaben. Diese werden von den
Benutzern selbst, durch die Arbeitsorganisation, andere soziale Kontexte oder durch das jeweilige interaktive System (z. B. bei E-LearningAngeboten) vorgegeben.
Eine einfache, aber nach wie vor verwendete Handlungstheorie zur
psychologischen Erklärung der Aktivitäten von Benutzern (Rosson &
Carroll 2002, S. 110 f.; Wandmacher 1993, S. 81 f.) wurde von Donald
Norman (1986) formuliert. In diesem theoretischen Modell wird davon ausgegangen, dass der Benutzer sich ein Ziel setzt. Ziele sind häufig allgemein formuliert und es gibt unterschiedliche Wege, diese zu
verwirklichen. Der Benutzer will beispielsweise ein Wort in einem
Text hervorheben, den er oder sie gerade mit einem Texteditor verfasst. Dieses Ziel ist zunächst nicht konkret, denn das Wort könnte
unterstrichen, fett gesetzt oder kursiv formatiert werden. Diese Auswahl muss im nächsten Schritt getroffen werden. Anschließend wird
ein Handlungsplan erstellt, d. h., Maus auf Menüleiste zu Option
„Format“ bewegen, klicken etc. Der Plan wird schließlich mit Hilfe der
Eingabegeräte ausgeführt. Die Konkretisierung des Ziels, die Handlungsplanerstellung und Ausführung dienten nach Norman zur Überbrückung des „Gulf of Execution“ (Norman 1985, S. 38 f.). Bei all die-

5.2 Theoretische Grundlagen

Nutzung von Informationen
durch die Anbieter

Benutzer verfolgen Ziele

Handlungstheorie zur Nutzung
interaktiver Systeme

■
■
■

257

sen Schritten kann das Produkt mehr oder weniger gut unterstützen,
womit der „Abgrund der Ausführung“ mehr oder weniger groß ist.
Veränderungen des interaktiven Systems werden als Informationen
mit Hilfe der Ausgabegeräte über die Modalitäten (vgl. Kap. 5.2.2.6)
wahrgenommen. Die wahrgenommenen Inhalte werden interpretiert,
d. h. mit bestehendem Wissen in Verbindung gebracht. Auf Basis der
dargebotenen Informationen wird in der Bewertungsphase geprüft, ob
das Ziel erreicht bzw. dem Ziel näher gekommen wurde. Diese psychologische Informationsverarbeitungsstrecke dient zur Überbrückung des „Gulf of Evaluation“ (Norman 1986, S. 38 f.). Auch hier
kann das Produkt mehr oder weniger Unterstützung anbieten.
Die sieben dargestellten Stufen (wahrnehmen, interpretieren, bewerten, Ziel formulieren, auswählen, planen und ausführen) sind keine starr getrennten Einheiten. Es entfallen ab und zu Stufen, in manchen Situationen entsprechen sich bestimmte Stufen oder werden
wiederholt (Norman 1986, S. 41 f.). Zudem weist Wandmacher (1993,
S. 82) darauf hin, dass wahrgenommene Ausgaben direkt auf die Stufe
„planen“ und „auswählen“ wirken bzw. sich Interpretationen ebenfalls ohne Bewertung direkt auf „planen“ und „auswählen“ auswirken.
Benutzer können häufig über das interaktive System miteinander
in Austausch treten. Dies ist beispielsweise bei computerunterstützten
kollaborativen Systemen (CSCW, Computer Supported Collaborative
Work) der Fall. Mehrere Benutzer werden in dem Modell durch mehrere Benutzerblöcke angedeutet.

Vereinfachte Darstellung
der Funktionsweise interaktiver Systeme

Ubiquitous Computing

258

■
■
■

5.2.2.5
Interaktives System
Das interaktive System wird vereinfacht als System dargestellt, das mit
Hilfe der Eingabegeräte Eingaben vom Benutzer aufnimmt, analysiert
und in Ausgaben umwandelt. Im Ausgabeprozess werden diese zunächst aufbereitet und dann dem Benutzer über die Ausgabegeräte
unter Nutzung unterschiedlicher Modalitäten präsentiert. Die Interaktionstechniken (oder auch Interaktionsmethoden oder Interaktionsformen) werden in der Gestaltung von Benutzungsschnittstellen als
regelhafte Verknüpfungen von Ein- und Ausgaben verstanden, die
wiederholt für bestimmte Nutzungsaufgaben eingesetzt werden
(Herczeg 1994, S. 85), wie beispielsweise Menüs, Formulare etc. Sie
verbinden Eingaben, Funktionen, Inhalte und Ausgaben. Durch die
Protokollierung der Interaktionen können personalisierte Interaktionen und personalisierte Inhalte präsentiert werden (vgl. Jameson
2003).
Bei allgegenwärtigen Computern (Ubiquitous Computing) sind Informationen auf unterschiedlichen interaktiven Systemen mit jeweils

5 Usability und Design

eigenen Benutzungsschnittstellen verteilt (in Abb. 5.2 angedeutet
durch mehrere Systemblöcke hintereinander). In einem interaktiven
Seminarraum beispielsweise werden Informationen auf mehreren
Laptops und interaktiven Präsentationswänden dargeboten (z. B.
Schwabe & Löber 2002). Mehrere Benutzer arbeiten zusammen und
nutzen unterschiedliche Geräte zur Ein- und Ausgabe mit eigenen
Interaktionstechniken.
5.2.2.6
Modalitäten
Ausgaben und Eingaben werden zunehmend über verschiedene Modalitäten vorgenommen.
So finden sich zur Ausgabe die klassischen visuellen Ausgabegeräte
wie Monitore, Displays in verschiedenen Größen, LEDs etc. (Luczak,
Rötting & Oehme 2003). Akustisch werden Sprachausgaben (Karat,
Vergo & Nahamoo 2003) oder Klänge und Geräusche (z. B. Earcons,
vgl. Brewster 2003) vorgenommen. Haptische Ausgaben bei VRSystemen oder bei Computerspielen werden mehr und mehr zum
Standard (vgl. Oakley et al. 2000). Mit Duft-Ausgabegeräten (Kaye
2004) wird nun auch die olfaktorische Modalität zur Informationsausgabe verwendet. An einer Ausgabemöglichkeit über die gustatorische
Modalität wird bereits gearbeitet. Der Food-Simulator von Iwata, Yano, Uemura und Moriya (2004) simuliert die Bissfestigkeit, den Klang
und Geschmack der Nahrung. Die vestibuläre Modalität wird beispielsweise in Fahrzeugsimulatoren angesprochen (Krüger & Neukun
2005).
Die klassischen Eingabegeräte an Bildschirmarbeitsplätzen sind
Tastatur und Maus. Hier wird vor allem die Motorik angesprochen,
wie auch bei berührungsempfindlichen Bildschirmen, Stifteingabe,
Trackball, Twiddler etc. (Ziegler & Burmester 1997). Motorische Eingaben im weiteren Sinne sind auch Blickregistrierung (Augenbewegungen, z. B. Duchowski 2003) oder Erkennung des emotionalen Zustands des Benutzers mit Hilfe des Gesichtsausdrucks (Wahlster
2003). Akustische Eingabe wird mit Spracheingabe verwirklicht, die
bei z. B. kleineren Systemen mit Einzelworterkennung und bei größeren Auskunftssystemen bereits mit natürlicher Sprache funktioniert.
Auch physiologische Daten werden verstärkt verwendet, wie z. B.
durch Messung des galvanischen Hautwiderstandes durch die Emotion Mouse von IBM (Crosby et al. 2001) oder durch Erfassung der
Hirnströme bei Gehirn-Computer-Schnittstellen (Neuper et al. 2003).
Übersichten zu Ein- und Ausgabegeräten finden sich bei Hinckley
(2003), Luczak, Roetting & Oehme (2003) und Iwata (2003, 2005).

5.2 Theoretische Grundlagen

Ausgabe

Eingabe

■
■
■

259

Nutzungskontexte

5.2.2.7
Nutzungskontexte
Um Usability zu erreichen oder zu evaluieren, ist es notwendig, den
jeweiligen Nutzungskontext eines interaktiven Systems zu kennen. Es
wird von mehreren Nutzungskontexten gesprochen, da unterschiedliche Benutzer mit unterschiedlichen Aufgaben verschiedene interaktive Systeme in unterschiedlichen Nutzungsumgebungen verwenden
können.

5.2.3
Information Foraging –
die Suche nach Informationen

Information-Foraging-Theorie

Wurzeln der
Information-Foraging-Theorie

zielorientierte Suche
nach Informationen

5.2.3.1
Suche nach Informationen als zentrale Aufgabe
Um die Exploration und das Finden von Informationen theoretisch
besser erklären zu können, wurde die Information-Foraging-Theorie
entwickelt (Pirolli 2003, S. 157–158).
Erklärt werden Strategien der Benutzer bei der Suche, der Sammlung und dem Verwenden von Informationen in Bezug zu dem Vorkommen der Informationen in der informationsanbietenden Umgebung. Pirolli fasst zusammen: „Information-foraging theory deals with
understanding how user strategies and technologies for information
seeking, gathering, and consumption are adapted to the flux of information in the environment“ (Pirolli 2003, S. 158).
Die Wurzeln dieser Theorie liegen in evolutionären und ökologischen Theorien zur Nahrungssuche (Pirolli & Card 1999). „[…] modern-day information foragers use perceptual and cognitive mechanisms that carry over from the evolution of food-foraging adaptations“
(Pirolli 2003, S. 164).
Wie auch bei der Usability-Definition wird von gegebenen Zielen
ausgegangen. Bei der Information-Foraging-Theorie ist hier die zielorientierte Suche nach Informationen gemeint. Vernachlässigt werden
Nutzungssituationen, bei denen die Benutzer sich erst anregen lassen,
um überhaupt Suchziele zu entwickeln.
5.2.3.2
Elemente der Information-Foraging-Theorie
Die Information-Foraging-Theorie ist eine stark formalisierte Theorie,
die auch mathematisch verfasst wurde. Hier sollen nur die wesentlichen Elemente dargestellt werden, da sie grundlegende Gedanken zur
Gestaltung von interaktiven Systemen enthalten, bei denen Informati-

260

■
■
■

5 Usability und Design

onssuche und -sammlung eine Rolle spielen. Umfassende Beschreibungen der Theorie finden sich bei Pirolli und Card (1999) und Pirolli
(2003).
Information-Scent: Auf der Suche nach Informationen kann der Informationssuchende aufgrund von Informationsspuren „Witterung“
nach von ihm gewünschten Informationen aufnehmen. Hinweise auf
weiterführende Informationen werden als „proximal cues“ bezeichnet.
Dies sind beispielsweise Linkbezeichnungen im Internet, die auf eine
Webseite mit vertiefenden Inhalten verweisen, oder Zusammenfassungen in einer Suchergebnisliste einer Datenbank. Auf der Basis der
Linkbezeichnung muss der Informationssuchende entscheiden, ob die
Informationen auf der dazugehörigen Webseite relevant für den Informationsbedarf sind und welche Kosten beim Aufsuchen der Seite
entstehen. „Information-Scent is the (imperfect) perception of the
value, cost, or access path of information sources obtained from
proximal cues, such as bibliographic citations, WWW links, or icons
representing the sources“ (Pirolli & Card 1999). Die Verständlichkeit
dieser Informationsspuren ist sehr entscheidend. Pirolli (2003, S. 185)
weist darauf hin, dass bei den meisten Aufgaben zur Informationssuche im Internet textuell formulierte Linkbezeichnungen besser sind
als reine grafische Darstellungen. Eine Kombination zwischen beiden
Darstellungsformen kann durchaus vorteilhaft sein. Tamborello und
Byrne (2005) konnten zeigen, dass der Erfolg der visuellen Suche neben der semantischen Qualität von dargestellten Informationen auch
durch die visuelle Hervorhebung beeinflusst wird. Beides zusammen
erleichtert es, Hinweise aufzufinden und zu interpretieren.
Kosten: Pirolli und Card (1999) unterscheiden drei Arten von Kosten für den Informationssuchenden, die beim Zugang zu Informationen, der Verarbeitung und Nutzung auftreten können:

Information-Scent

Kosten

1. Zeitkosten (time cost), d. h. der Zeitbedarf für die jeweilige Aktivität
(z. B. Zeitbedarf beim Navigieren durch eine Website auf der Suche
nach einer bestimmten Information).
2. Ressourcenverbrauch (resource costs), wie Anstrengung, Geld etc.
3. Kosten verpasster Alternativen (opportunity costs), d. h. die Kosten
dafür, dass sich der Informationssuchende nicht für ein Verhalten
entschieden hat, das ihm mehr Vorteile bringt als das derzeitig gewählte. Beispielsweise würde ein Informationssuchender mit einer
anderen Suchmaschine schneller ans Ziel kommen können als mit
der gerade gewählten.
Informationsraum: Der Informationsraum eines Informationssuchenden wird in unterschiedliche Suchgebiete aufgeteilt. Card et al.
(2001) konnten dies für die Suche im Internet in einer Studie zeigen.

5.2 Theoretische Grundlagen

Informationsraum

■
■
■

261

Optimale Informationssuche

Gestaltungsprinzipien

Für den Informationssuchenden ist die zentrale Frage, ob das Informationsangebot eines Suchgebietes (z. B. einer Suchmaschine) so gut
ist, dass sich eine weitere Informationssuche lohnt, oder ob es optimaler ist, in ein anderes Suchgebiet zu wechseln (z. B. zu einer anderen
Suchmaschine oder Informationsportal).
Optimale Informationssuche: Der Informationssuchende versucht
konsequent die Menge nützlicher Informationen für jede Einheit Kosten unter den Randbedingungen der Aufgabenumgebung zu optimieren, d. h., die meisten relevanten Informationen bei den niedrigsten
Kosten zu finden. Bei der Suche nach Informationen muss einbezogen
werden, dass der Informationssuchende manipulativ in die Informationsumgebung eingreifen kann. Der Aufwand, von einem Suchgebiet
in ein anderes zu wechseln, lässt sich so optimieren. Beispielsweise
kann der Aufwand eines Wechsels von einer bestimmten Suchmaschine zu einer alternativen Suchmaschine reduziert werden, indem
eine Linkliste für Suchmaschinen angelegt wird. Die Ausbeute eines
Suchgebiets lässt sich durch Anwendung von Filtern, durch Optimierung der Suchbegriffe oder durch die Verwendung von detaillierter
Suche (advanced search) verbessern (Pirolli & Card 1999).
5.2.3.3
Einfluss auf die Gestaltung
Für die Gestaltung lassen sich aus der Information-Foraging-Theorie
folgende Prinzipien extrahieren:
• Wechsel zwischen Informationsquellen erleichtern (z. B. Suchmaschinengestaltung).
• Information Scent unterstützen (gute Linkbeschreibungen, aussagekräftige Icons, klare Hervorhebungen für Hinweise, die zu den
häufigsten Suchzielen passen).
• Quellenverarbeitung unterstützen (verständliche Texte, gute Medienauswahl).
• Anzahl der Alternativen in Grenzen halten (Information Overload).
• Kosten schätzen können: Aufwand, Zeitbedarf (z. B. bei Downloads: Größe der Datei, Format, Namen, benötigte Software, Wartezeit, Preis).

5.2.4
Persuasive Aspekte
Beeinflussen der Einstellung
und des Verhaltens von Benutzern

262

■
■
■

Wie bereits erläutert, verfolgen Anbieter von Informationen bestimmte Ziele. Sie versuchen Einfluss auf die Benutzer ihres Angebotes zu
nehmen. Sie versuchen Einstellung oder Verhalten der Benutzer zu

5 Usability und Design

ändern; sie versuchen zu überzeugen, persuasiv zu sein. Um mit Informationen überzeugen zu können, ist es nach Fogg (2003a) wichtig,
dass die Informationsquelle als glaubwürdig wahrgenommen wird.
Nur Informationen aus glaubwürdigen Quellen werden zum einen
eher genutzt und sind zum anderen eher geeignet, den Benutzer zu
beeinflussen. Mit dem zweiten Aspekt treten die Anbieter von Informationen mit ihren eigenen Zielen auf den Plan. Chak (2002) beschreibt Glaubwürdigkeit als eine wesentliche Voraussetzung, damit
potenzielle Kunden von Online-Shops zu Transaktionen motiviert
werden.
Ob eine Informationsquelle bzw. die von ihr angebotenen Informationen als glaubwürdig eingeschätzt werden, hängt von dem Beurteiler
ab. Somit definiert Fogg (2003a, S. 122) Glaubwürdigkeit („credibility“) als eine wahrgenommene Qualität. Nach der „Prominence-Interpretation Theory“ (Fogg 2003b) entsteht Glaubwürdigkeit in einem
Prozess: (1) Darstellungselemente einer Informationsquelle müssen
von dem Benutzer entdeckt werden. (2) Anschließend werden die
Darstellungselemente interpretiert. (3) Auf der Basis der Interpretation trifft der Benutzer ein Urteil über die Glaubwürdigkeit des Mediums. Entdeckt der Benutzer beispielsweise einen Link, der nicht funktioniert, dann interpretiert er diese Tatsache möglicherweise als Indiz
dafür, dass die Website nicht sorgfältig gestaltet und gepflegt wurde.
Diese Interpretation kann die Glaubwürdigkeit senken, die der Benutzer der Website zuschreibt.
Wahrgenommene Glaubwürdigkeit resultiert aus wahrgenommener Vertrauenswürdigkeit („trustworthiness“) und wahrgenommener
Expertise („expertise“) (Fogg 2003a, S. 123–125). Vertrauenswürdigkeit wird einem Produkt dann zugeschrieben, wenn die dargebotenen
Informationen als wahr und objektiv beurteilt, d. h. nicht durch Interessen beeinflusst werden: „A computer that is ‚trustworthy‘ is one
that is perceived to be thruthful, fair and unbiased“ (Fogg 2003a,
S. 123). Hohe wahrgenommene Expertise stellt sich dann ein, wenn
Wissen, Fähigkeiten und Erfahrung einer Informationsquelle hoch
eingeschätzt werden. Hinweise auf die Expertise einer Quelle können
beispielsweise wissenschaftliche Anerkennungen wie Wissenschaftspreise sein.
Nun stellt sich die Frage, welche gestalterischen Elemente die
Glaubwürdigkeit einer Informationsquelle in den Augen der Benutzer
unterstützen bzw. verhindern. In Studien zur Glaubwürdigkeit von
Websites (Fogg 2002; 2003a, S. 147 ff.) wurde festgestellt, dass die Vertrauenswürdigkeit als eine Grunddimension der Glaubwürdigkeit
einer Website positiv durch bestimmte Informationen beeinflusst
wird. Dazu gehörten beispielsweise Informationen wie die Angabe der
tatsächlichen Adresse einer Organisation, deren Telefonnummer und

5.2 Theoretische Grundlagen

Prominence-Interpretation Theory

Komponenten wahrgenommer
Glaubwürdigkeit

Gestaltungselemente, die Glaubwürdigkeit fördern oder senken

■
■
■

263

Kontakt-E-Mail-Adresse sowie die Angabe von Referenzen zu Quellen
außerhalb der Website, die als respektabel wahrgenommen wurden.
Vertrauenswürdigkeit wird hingegen herabgesetzt durch z. B. schlechte Unterscheidbarkeit von Werbung und Inhalt sowie Verlinkung auf
als unglaubwürdig beurteilte Quellen. Die wahrgenommene Expertise
als zweite Grunddimension der Glaubwürdigkeit wird z. B. durch
schnelle Beantwortung von Anfragen, die Bestätigung von Transaktionen, die Angabe von Empfehlungen für die angebotenen Artikel
sowie durch eine professionell anmutende Gestaltung positiv verändert. Im Gegenzug verringern z. B. seltene Aktualisierung der Website,
nicht funktionierende Links, Schreibfehler und zeitweise eingeschränkte Zugänglichkeit der Website die wahrgenommene Expertise.

5.2.5
Attraktivität
Zufriedenstellung oder Freude

Emotional Design, Funology

264

■
■
■

Wenn ein Produkt in einem bestimmten Nutzungskontext effektiv
und effizient genutzt werden kann, dann stellt sich beim Benutzer die
Zufriedenstellung ein, so die Norm DIN EN ISO 9241-11 (1998). Zufriedenstellung wird als „Freiheit von Beeinträchtigung und positive
Einstellung gegenüber der Nutzung des Produkts“ definiert (DIN EN
ISO 9241-11 1998, S. 4). Somit steht im Vordergrund, dass die Nutzung eines interaktiven Produkts nicht zu körperlichen und psychischen Beeinträchtigungen führen darf. Tatsächlich ist bei mangelnder
Effektivität und Effizienz dieser Zusammenhang nachgewiesen (siehe
Tab. 5.1). Freiheit von Beeinträchtigung gehört zu den zentralen Zielen der Arbeitswissenschaft. „Arbeitsfreude, die auf einer tiefbegründeten Bejahung der Arbeit durch die Persönlichkeit beruht“ (Friedmann 1953 zitiert nach Ulich 1994, S. 118) spielt in der Arbeitspsychologie als Begriff keine große Rolle mehr (Ulich 1994, S. 118).
In der wissenschaftlichen Human-Computer Interaction Community wird seit gut 10 Jahren die Diskussion um positive Qualitäten der
Produktnutzung mit zunehmender Intensität geführt (Hassenzahl &
Tractinsky 2006). Selbst Donald Norman, der 1988 mit seinem Buch
„Design of Everyday Things“ (quasi das Referenzwerk ergonomischer
Produktgestaltung) die gute Handhabung von Produkten als zentrales
Kriterium gepriesen hatte, schreibt 2004 in seinem Buch „Emotional
Design“ (Norman 2004), dass Usability nicht das einzige Kriterium
guter Produktgestaltung sein kann. Blythe, Overbeeke, Monk und
Wright (2003) brachten mit „Funology“ eine Sammlung wissenschaftlicher Arbeiten zum Spaß und Freude an der Nutzung heraus. Mit
„More Funology“ legten Blythe, Hassenzahl und Wright im Jahre 2004
nach. Bereits 1987 forderten Carroll und Thomas, dass der UsabilityBegriff erweitert werden müsse, welches Carroll 2004 noch einmal

5 Usability und Design

bekräftigte (Carroll & Thomas 1987; Carroll 2004). Logan wies 1994
darauf hin, dass positive Emotionen eine wichtige Rolle bei der Gestaltung von Unterhaltungselektronik spielen. Igbaria, Schiffman und
Wieckowski stellten in einer breit angelegten Studie unter Managern
fest, dass die Akzeptanz technischer Systeme in hohem Maße mit dem
Spaß an der Nutzung zusammenhing: „fun has its greatest value as
a means of accepting the new technology and making individuals
more adaptable and satisfied with quality of the system“ (Igbaria,
Schiffman & Wieckowski 1994, S. 358).
5.2.5.1
Pragmatische und hedonische Qualität
Hassenzahl und Kollegen (Hassenzahl 2003b, 2004; Hassenzahl, Burmester & Koller 2003; Hassenzahl et al. 2000) erforschten die Frage,
was die Attraktivität eines Produkts aus der Sicht der Benutzer ausmacht. Aus diesen Arbeiten wurde ein wissenschaftliches Modell
wahrgenommener Produktqualitäten abgeleitet (Hassenzahl 2003b,
2004).
Die zentrale Aussage ist, dass Usability als eine Qualität der Nutzung nicht ausreicht, damit ein Produkt als attraktiv durch die Benutzer bewertet wird. Hinzu kommen weitere Qualitäten, die vor allem
auf den Grad der Anregung durch das Produkt und den Grad der Identifikation mit dem Produkt abzielen.
Abbildung 5.3 zeigt ein Modell der Wahrnehmung und Bewertung
von Produktqualitäten (nach Burmester & Dufner 2006). Die Grundannahme dieses Modells ist, dass ein Gestalter bestimmte Qualitäten
durch Gestaltungsentscheidungen zu den Eigenschaften eines Produkts erreichen möchte. Er beeinflusst auf unterschiedlichen Gestaltungsebenen die Eigenschaften des Produkts. Der Benutzer nimmt
diese Eigenschaften wahr und bewertet sie. Das Ergebnis der Bewertung hat Konsequenzen auf seine Emotionen und sein Verhalten. Im
Folgenden werden die zentralen Komponenten des Modells und deren
Zusammenwirken erläutert (vgl. Hassenzahl 2003b, 2004):

Wahrgenommene Produktqualitäten

Usability und Attraktivität

Modell der Wahrnehmung
und Bewertung von Produktqualitäten

1. Wahrgenommene pragmatische Qualität (PQ)
Benutzer wollen ihr Umfeld unter der Prämisse bestimmter Ziele
manipulieren. Um dies tun zu können, müssen bestimmte Funktionen und Inhalte vorhanden sein, sie müssen in effektiver und effizienter Form genutzt werden können. Somit entspricht die wahrgenommene pragmatische Qualität der wahrgenommenen Usability
eines Produkts.
2. Wahrgenommene hedonische Qualität (HQ)
Unterschieden wird die wahrgenommene hedonische Qualität in

5.2 Theoretische Grundlagen

■
■
■

265

drei Subdimensionen. Diese sind Stimulation, Identität und Evokation (bzw. Symbolismus):
a. Wahrgenommene hedonische Qualität – Stimulation (HQ-S):
Dieser Qualität liegt das Bestreben von Menschen zugrunde, in
ihrem Wissen und ihrer Persönlichkeit zu wachsen und besser
zu werden. Das darunter liegende Motiv ist Neugier. Bei einem
Produkt können dies interessante Funktionen sein, durch die eine Aufgabe anders gelöst werden kann, neue Aspekte der Aufgabe entdeckt oder gänzlich neue Aktivitäten ausgeführt werden
können. Neuartige Interaktionsformen oder ungewöhnliches
Design können Benutzer anregen, sich jenseits ihrer Aufgabenbearbeitung mit dem Produkt zu beschäftigen.
b. Wahrgenommene hedonische Qualität – Identität (HQ-I): Das
Produkt kann die Persönlichkeit des Benutzers nach außen unterstreichen und komplettieren. Der Benutzer drückt durch das
Produkt aus, dass er zu einer bestimmten Gruppe von Menschen
gehört (z. B. die i-pod-User). Oder der Benutzer zeichnet sich als
besonders klug und vernünftig aus, da er sich durch ein intelligentes Beratungssystem (recommender system) bei einem Online-Shop immer die neuesten technischen Entwicklungen und die
günstigsten Preise anzeigen lässt.
c. Wahrgenommene hedonische Qualität – Evokation/Symbolismus (HQ-E): Das Produkt kann positive Erinnerungen des Benutzers anregen, indem das Produkt wie ein Symbol für eine bestimmte Erfahrung des Benutzers steht. Eine Branche, die im
Wesentlichen von dieser Qualität lebt, ist die Souvenirbranche.
3. Attraktivität (ATT)
Basierend auf den wahrgenommenen Qualitäten bilden sich die
Benutzer ein Gesamturteil über das Produkt. Sie bewerten es, d. h.
das Produkt ist „gut“ oder „schlecht“ bzw. „schön“ oder „hässlich“.
Dieses Gesamturteil wird als „Attraktivität“ bezeichnet.
4. Konsequenzen
Die Einschätzung der Attraktivität eines Produkts hat Konsequenzen. Zunächst wirkt sich diese Einschätzung auf das Verhalten aus.
Wenn beispielsweise die Attraktivität gering ist, dann wird die Nutzungsfrequenz niedrig sein. Es gibt aber auch emotionale Konsequenzen. Bei einer hohen Attraktivität empfindet der Benutzer
Freude und vielleicht sogar Stolz, dass er das Produkt besitzt und
nutzt.
Prozess der Wahrnehmung
und Bewertung von Produktqualitäten

266

■
■
■

Das Modell in Abb. 5.3 sagt nun folgendes aus. Ein Gestaltungsteam
setzt sich selbst Ziele und legt fest, welche Qualitäten in welcher Form
adressiert werden sollen. Die Kombination der verschiedenen Gestal-

5 Usability und Design

Abb. 5.3:
Modell der Attraktivität
(nach Burmester & Dufner 2006,
Erläuterung im Text)

tungsziele ergibt einen intendierten Produktcharakter (Hassenzahl
2003b, Jordan 2000). Die Gestalter können ihre Gestaltungsziele auf
vier verschiedenen Ebenen in ein Artefakt umsetzen. Dies ist zunächst
die Auswahl der benötigten Funktionen und der Inhalte. Dann kommt
die Präsentation der Informationen hinzu. Hier kann typischerweise
an den Farbpaletten, der Formensprache, dem Layout, der Typografie
etc. gearbeitet werden. Schließlich können die Interaktionsformen
gestaltet werden. Dazu gehören Interaktionstechniken wie Menüs,
Formulardialoge, Schaltflächen etc. Die Gestaltungsentscheidungen
werden mit Hilfe eines Prototyps oder in Form des Produkts für den
Benutzer erfahrbar gemacht. Durch diese Nutzungserfahrung nimmt
der Benutzer einen bestimmten Grad der verschiedenen Qualitäten
wahr. Die Ausprägung der wahrgenommenen Qualitäten kann sich
von der Ausprägung der Qualitäten unterscheiden, die vom Gestaltungsteam intendiert wurden. Beispielsweise könnte das Gestaltungsteam ein Produkt beabsichtigt haben, das einfach zu erlernen ist. Tatsächlich aber bereitet die Nutzung des Produkts in der Wahrnehmung
der Benutzer erhebliche Schwierigkeiten. Dieser Zusammenhang gilt
selbstverständlich auch für hedonische Qualitäten, denn auch dort
können die intendierten Qualitäten im Umgang mit dem Produkt
ganz anders wahrgenommen werden (Burmester, Hassenzahl & Koller
2003). Auf der Basis der wahrgenommenen Qualitäten eines Produkts
bildet der Benutzer das Attraktivitätsurteil, welches sich dann auf sein
Verhalten und auf seine Emotionalität auswirkt.
Wesentlich ist, dass Gestaltungsprozesse die Unterschiede zwischen
intendierten und wahrgenommenen Qualitäten berücksichtigen. Der
im Folgenden dargestellte benutzerzentrierte Gestaltungsprozess adressiert genau diese Problematik, indem Gestaltungsentscheidungen
durch Evaluationsmaßnahmen immer wieder überprüft werden.
Nach dem oben dargestellten Modell wurde ein Evaluationsinstrument entwickelt (Hassenzahl, Burmester & Koller 2003), mit dem die
wahrgenommene pragmatische Qualität, die hedonischen Qualitäten
Stimulation und Identität sowie die Attraktivität gemessen werden

5.2 Theoretische Grundlagen

Instrument zur Messung
von Attraktivität interaktiver Systeme

■
■
■

267

kann. Es handelt sich dabei um ein semantisches Differential von Eigenschaftswortpaaren, wie z. B. „kompliziert“ – „einfach“ für pragmatische Qualität oder „konservativ“ – „innovativ“ für hedonische Qualität Stimulation. Dieses kann im Rahmen der Evaluation (vgl. Kap. 5.3.5
Evaluation – Prüfung und Inspiration) von Produkten eingesetzt werden (AttrakDiff 2005, Burmester, Hassenzahl & Koller, 2007).

5.3
Design
5.3.1
User Centred Design

Usability-Engineering

Benutzerzentrierte Gestaltung

Eigenschaften
benutzerzentrierter Gestaltung

In den vorausgegangenen Abschnitten wurde erläutert, was Usability
ist, welche Bedeutung sie hat, welche benachbarten Themengebiete es
gibt und welche theoretischen Grundlagen zur Verfügung stehen. Die
entscheidende Frage ist nun, wie Usability als Qualität der Nutzung
erreicht werden kann.
Die Disziplin, die sich dem Ziel verschrieben hat, Usability bei der
Gestaltung von Benutzungsschnittstellen zu erreichen, ist das Usability-Engineering. „Engineering“ verweist darauf, dass sich diese Disziplin als ein ingenieurwissenschaftlicher Ansatz versteht. Somit wird
eine Systematik und Methodik bei der Gestaltungstätigkeit gefordert.
Deborah J. Mayhew definiert Usability-Engineering als „a discipline
that provides structured methods for achieving usability in user interface design during product development“ (1999, S. 2).
Das zentrale Vorgehen im Usability-Engineering wird als benutzerzentrierte Gestaltung oder „User Centred Design“ (UCD) bezeichnet.
Darunter wird ein fundierter, praktikabler und bewährter Gestaltungsprozess für Benutzungsschnittstellen interaktiver Produkte verstanden (vgl. Burmester & Görner 2003, S. 47). Über die Eckpunkte des
Gestaltungsprozesses und des methodischen Vorgehens herrscht in
Forschung und Praxis international eine weitgehende Einigkeit (z. B.
Beyer & Holtzblatt 1998; Burmester & Görner 2003; Gould & Lewis
1985; Hix & Hartson 1993; Mayhew 1999; Nielsen 1993; Rosson & Carroll 2002). Zudem ist die benutzerzentrierte Gestaltung als internationale Norm ISO 13407 (1999) festgeschrieben worden: Diese Norm ist
als DIN EN ISO 13407 (2000) in die deutsche Normung eingegangen.
Benutzerzentrierte Gestaltung weist folgende Eigenschaften auf:
1. Benutzer im Zentrum
Benutzer werden mit ihren Bedürfnissen, Interessen, Zielen und Aufgaben in ihren sozialen, organisatorischen, physischen und techni-

268

■
■
■

5 Usability und Design

schen Umgebungen als Maßstab für Gestaltungsentscheidungen gesehen und in den Gestaltungsprozess einbezogen. Somit wird der gesamte Nutzungskontext berücksichtigt. Maßstab ist der Benutzer.
2. Interdisziplinäre Zusammenarbeit
Gestaltungsarbeit kann nur in einem Team unterschiedlicher, am
Gestaltungsprozess beteiligter Disziplinen gesehen werden (DIN EN
ISO 13407 2000). Teams setzen sich zusammen aus Produktmanagern, Produktanalytikern, Designexperten, Usability-EngineeringFachleuten, Systemarchitekten, Softwareentwicklern, Marketing
und Verkaufspersonal, Fachexperten etc. Die Zusammensetzung eines Gestaltungsteams hängt stark von dem jeweiligen Produkt ab. So
werden bei einer Lernsoftware beispielsweise auch Pädagogen und
Didaktiker mit dabei sein. Die Benutzer werden systematisch konsultiert und sind so phasenweise ebenfalls Mitglieder des Teams.
3. Gestaltung als Prozess
Der benutzerzentrierte Gestaltungsprozess besteht aus unterschiedlichen Phasen (in Abb. 5.4 durch Rechtecke mit abgerundeten
Ecken dargestellt). Nachdem die Gültigkeit des benutzerzentrierten
Gestaltungsprozesses festgestellt wurde, muss in der ersten Phase
der Nutzungskontext analysiert werden. Ist dieser verstanden, werden Anforderungen aus dem Nutzungskontext abgeleitet und Usability-Ziele aufgestellt. Usability-Ziele geben an, welche Ausprägung
an Usability im Rahmen der Gestaltung erreicht werden soll. Beispielsweise könnte das Ziel sein, dass sich 95% aller Benutzer spontan ihr erstes Musikstück fehlerfrei von einem Musikportal herunterladen können. Die Informationen aus dem Nutzungskontext und
die Anforderungen leiten dann in der zweiten Phase die Entwurfsarbeit der Benutzungsschnittstelle ein. Die Gestaltungsideen müssen im interdisziplinären Team und gegenüber den Benutzern
Abb. 5.4:
Benutzerzentrierter Gestaltungsprozess
(Erläuterung im Text)

5.3 Design

■
■
■

269

kommunizierbar und erfahrbar gemacht werden. Spezifikationen
und Dokumentationen bieten oft nicht die notwendige Anschaulichkeit und führen zu Missverständnissen. Daher werden Gestaltungsideen in der dritten Phase in Prototypen umgesetzt. Ein Ziel
der Erfahrbarmachung von Gestaltungsideen ist deren Bewertung
bzw. deren Evaluation in der vierten Phase.
4. Methodische Unterstützung
Die in jeder Phase stattfindenden Aktivitäten, wie Analysieren, Gestalten, Prototyping und Evaluieren, werden durch fundierte Methoden unterstützt (vgl. auch Norm zu Methoden im benutzerzentrierten Gestaltungsprozess ISO/TR 16982 2002). So kann beispielsweise
in der Nutzungskontextanalyse eine spezielle Form des Interviews
angewandt werden: das Contextual Inquiry (Beyer & Holtzblatt
1998). Diese Interviewform koppelt in Feldstudien die Beobachtung
mit der Befragung von Benutzern im „Kontext“ ihres Arbeitsplatzes, ihrer realen Aufgabenbearbeitung und ihrer tatsächlichen organisatorischen und sozialen Bezüge am Arbeitsplatz. Für die Phase
des Prototypings und der Evaluation kann beispielsweise die Methode des „Paperprototypings“ von Carolyn Snyder (2003) genutzt
werden. Die Methoden zeichnen sich durch eine Beschreibung der
Arbeitsschritte und Durchführungsregeln sowie eine wissenschaftliche Fundierung oder zumindest praktische Bewährung aus. Die
Aktivitäten einer Phase resultieren in verschiedene Formen der Ergebnisrepräsentation. In Abb. 5.4 werden die Arbeitsergebnisse jeder Aktivität als Quadrate mit jeweils beispielhaften Arbeitsergebnissen dargestellt. Dies können je nach Phase und eingesetzter
Methode unterschiedliche Formen von Artefakten sein, z. B. Anforderungsliste, Liste der Usability-Ziele, Nutzungsszenarien, Papierprototypen, Evaluationsbericht als Ergebnis eines Usability-Tests.
5. Iterative Gestaltung
Bevor der Gestaltungsprozess beginnen kann, steht die Entscheidung
für oder gegen einen benutzerzentrierten Gestaltungsprozess an (vgl.
Raute „Benutzerzentrierte Gestaltung?“ in Abb. 5.4). Bei Produkten,
die einen hohen Anteil von Benutzerinteraktionen aufweisen, ist ein
benutzerzentrierter Gestaltungsprozess zu empfehlen. Der grundlegende Gedanke der benutzerzentrierten Gestaltung ist, dass Gestaltungsideen überprüft bzw. evaluiert werden. Denn trotz der vielen
Informationen aus der Nutzungskontextanalyse können Gestaltungsentscheidungen getroffen werden, die mit dem Nutzungskontext nicht kompatibel sind (z. B. aufgrund von Fehlinterpretation der
Daten oder unzureichender Umsetzung der Erkenntnisse aus dem
Nutzungskontext in Entwürfe). Evaluation hat die Aufgabe, dies zu
ermitteln. In der Evaluationsphase werden als formative Evaluation

270

■
■
■

5 Usability und Design

Anhaltspunkte gesammelt, um Usability-Probleme zu verstehen und
schließlich das Design zu verbessern. Zudem wird das Erreichen der
Usability-Ziele überprüft. Auf der Basis der Evaluationsergebnisse
muss dann die Entscheidung getroffen werden, ob es eine weitere Iteration gibt (Raute „Weitere Interation?“ in Abb. 5.4). Die vier Phasen
der benutzerzentrierten Gestaltung werden so lange wiederholt, bis
die Usability-Ziele erreicht werden. Sind diese erreicht, werden die
Ergebnisse des Gestaltungsprozesses als Benutzungsschnittstellenspezifikation und Style-Guide dokumentiert.

5.3.2
Nutzungskontextanalyse
5.3.2.1
Die Analyse des Nutzungskontextes
Die Nutzungskontextanalyse ist der Ausgangspunkt für die Arbeiten im
benutzerzentrierten Gestaltungsprozess. Wie die Usability-Definition
besagt, ist es nicht möglich, Aussagen über die Usability zu treffen, wenn
der Nutzungskontext nicht bekannt ist. Auch wenn kein vollständiger
benutzerzentrierter Prozess durchlaufen wird (z. B. nur Evaluation), ist
es notwendig zu wissen, welche Eigenschaften die Benutzer haben, welche Ziele und Aufgaben sie verfolgen und schließlich in welcher organisatorischen und sozialen sowie technischen und physischen Umgebung
das Produkt genutzt wird. Nur durch die Kenntnis dieser Informationen
kann beispielsweise ein sinnvoller Usability-Test geplant werden (vgl.
Kap. 5.3.5). Denn nur so ist bekannt, welche Testteilnehmer eingeladen
werden sollen, welche Testaufgaben sie machen sollen und wie die Testumgebung und das zu testende Produkt eingerichtet werden soll.
Die Nutzungskontextanalyse trägt der Tatsache Rechnung, dass die
Nutzungskontexte, für die Produkte entwickelt werden sollen, sehr
unterschiedlich sind. Die zu erhebenden und zu analysierenden Eigenschaften des jeweiligen Nutzungskontexts sind spezifisch für das
jeweilige Produkt. Angelehnt an die Norm DIN EN ISO 9241 Teil 11
(1998) und an die Arbeiten von Beu (2003), Shneiderman und Plaisant
(2004) sowie Thomas und Bevan (1996), beschreibt Tabelle 5.2 Eigenschaften, die bei der Analyse des Nutzungskontextes von Bedeutung
sind. Bei der Analyse der Aufgaben muss darauf geachtet werden, dass
diese pro Benutzergruppe bzw. Benutzerrolle beschrieben werden
müssen. Zudem ist wichtig, dass sich Nutzungskontexte von Kultur zu
Kultur unterscheiden (Honold 2000) und daher auch kulturspezifisch
analysiert werden müssen.
In der Phase der Nutzungskontextanalyse ist es gemäß der DIN EN
ISO 14915 (2002) auch angemessen, die Ziele des Anbieters zu be-

5.3 Design

Nutzungskontextanalyse
als Ausgangspunkt für die Arbeiten im
benutzerzentrierten Gestaltungsprozess

Zu erhebende und zu analysierende
Eigenschaften des Nutzungskontexts

■
■
■

271

Tabelle 5.2:
Ausgewählte Eigenschaften
des Nutzungskontextes

Produkt

ƒ
ƒ
ƒ
ƒ
ƒ

Benutzergruppen

ƒ Fähigkeiten, Vorerfahrungen, Wissen
ƒ demografische Daten wie Alter, Geschlecht,
ƒ körperliche Einschränkungen und spezielle
Anforderungen
ƒ mentale Eigenschaften, wie Motivation, Einstellung zum Produkt, zur Aufgabe, zur Informationstechnologie, Lernstile
ƒ Stellenbeschreibung, z. B. Position, Verantwortung, Arbeitszeiten

Aufgaben

ƒ Aufgabenziel
ƒ Einbettung der Aufgabe in einen Arbeitsablauf
bzw. Workflow
ƒ Wahlfreiheit
ƒ Beschreibung der Vorgaben und des Aufgabenergebnisses
ƒ Häufigkeit
ƒ Bearbeitungsdauer
ƒ physische und mentale Anforderungen
ƒ Sicherheit

Organisatorisches
Umfeld

ƒ Struktur: Gruppenarbeit, Unterbrechungen,
Benutzerunterstützung, Management, Kommunikationsstruktur
ƒ Organisationskultur
ƒ Leistungsüberprüfung
ƒ weitere Medien und Arbeitsmittel

Technisches Umfeld

ƒ Hardware (z. B. Peripheriegeräte)
ƒ Software (z. B. Betriebssystem)
ƒ Handbücher, Anleitungen etc.

Name, Version
Beschreibung, Zweck
Anwendungsfelder
Funktionen
Hardware mit Ein- und Ausgabegeräten

Physikalisches Umfeld ƒ Arbeitsplatzumgebung (z. B. Lichteinstrahlung,

Temperatur, Lärm)
ƒ Arbeitsplatzausstattung (z. B. Nutzungshaltung
im Stehen oder Sitzen)
ƒ Gesundheit und Sicherheit

272

■
■
■

5 Usability und Design

schreiben. Wenn neben Usability auch hedonische Qualitäten bei der
Produktgestaltung verwirklicht werden sollen, so müssen entsprechende Anforderungen auch in dieser Phase mit erhoben werden.
5.3.2.2
Datenerhebung und Dokumentation
Bei der Nutzungskontextanalyse muss unterschieden werden, ob ein
neues Produkt entwickelt oder ein bereits bestehendes erneuert werden soll. Wird ein bestehendes Produkt überarbeitet, kann in der Nutzungskontextanalyse auf vorhandenes Wissen aus vorherigen Nutzungskontextanalysen oder auf Ergebnisse bereits durchgeführter
Evaluationsstudien der Vorgängerversion zurückgegriffen werden. Bei
neuen Entwicklungen oder bei Entwicklungen, die bestehende Produkte komplett ersetzen sollen, muss der Nutzungskontext vollständig
untersucht werden.
Die Nutzungskontextanalyse ist in der Regel durch zwei aufeinanderfolgende Aktivitäten gekennzeichnet. Zunächst werden Daten zum
Nutzungskontext erhoben. Die Datenerhebung kann sich auf bestehende Dokumente stützen oder in empirischer Form ausgeführt werden. Anschließend werden die erhobenen Daten analysiert und dokumentiert.
Werden Dokumente als Grundlage verwendet, so werden typischerweise Dokumente verwendet wie z. B. Marktforschungsberichte, wissenschaftliche Literatur, Konkurrenzanalysen, Beschreibungen vergleichbarer Produkte, Dokumentationen von Vorgängerversionen,
Arbeitsplatzbeschreibungen, Beschreibungen technischer und ökonomischer Randbedingungen, White Papers sowie Expertenevaluationen,
Usability-Test-Berichte oder Hotline-Reports von Vorgängerversionen. Je nachdem wie weit der Informationsbedarf zum Nutzungskontext mit den Dokumenten gedeckt werden kann und wie gut die Inhalte
der Dokumente abgesichert sind, werden empirische Untersuchungen
des Nutzungskontextes vorgenommen. Während Informationen zu
Zielgruppenstruktur und Zielgruppeneigenschaften sowie technische
und formale organisatorische Randbedingungen oft gut dokumentiert
sind, fehlen meist Informationen über die Anforderungen der Benutzer, deren tatsächliche Arbeitsweisen sowie deren Einbettung in die
informelle Organisation. Auch die konkreten Nutzungsumgebungsbedingungen sind oft erst durch Feldstudien genau zu eruieren. Um die
Dokumentenanalyse zu vervollständigen, sind empirische Untersuchungen notwendig.
Tabelle 5.3 zeigt typische Methoden der Datenerhebung im Nutzungskontext. Im Anschluss an die Erhebung müssen die Daten analysiert werden. Dazu stehen ebenfalls verschiedene Methoden zur

5.3 Design

Nutzungskontextanalyse
für neue oder bestehende Produkte

Datenerhebung und -analyse

Nutzungskontextanalyse
auf der Basis bestehender Dokumente

Methoden der Datenerhebung

■
■
■

273

Verfügung. So werden im Rahmen des Contextual Design von Hugh
Beyer und Karen Holtzblatt (1998) verschiedene Modelle zu wichtigen
Aspekten des Nutzungskontextes erstellt. Dazu gehören das Modell
der Arbeitsorganisation und des Workflows (Flow Model), Arbeitsabläufe (Sequence Model), Beschreibungen der Gegenstände, mit denen
Benutzer umgehen (Artifact Model), das Modell der Unternehmensorganisation und -kultur (Cultural Model) und eine Darstellung der
Arbeitsumgebung, in der der Benutzer arbeitet (Physical Model).
Tabelle 5.3:
Beispiele für Datenerhebungsund Datenanalysemethoden

Methode

Beschreibung

Datenerhebung
Kontextsitzung

Sitzung mit repräsentativen Benutzern oder Benutzervertretern, Produktmanagern, Entwicklern und UsabilityExperten (Thomas & Bevan 1996).

Kontextinterview

Contextual Inquiry (Beyer & Holtzblatt 1998, Erläuterung
im Text; ethnografische Verfahren z. B. bei Kantner et al.
2003).

Fokusgruppe

Gruppenbefragung, in der die Teilnehmer nach Eigenschaften des Nutzungskontextes und persönlichen Bedürfnissen und Meinungen zum Produkt befragt werden
(z. B. Krueger & Casey 2000; Hassenzahl 2003a).

Datenanalyse und -dokumentation

274

■
■
■

Aufgabenanalyse

Aufgaben werden in Unteraufgaben zerlegt und mit
verschiedenen Beschreibungsformalismen dargestellt,
z. B. mit Hilfe der HTA, der Hierarchical Task Analysis
(z. B. Kirwan & Ainsworth 1992; Hackos & Redish 1998).

Contextual Design

Analysemodelle von Beyer & Holtzblatt (1998), Beschreibung im Text

Problem Scenario

Sehr anschauliche und gut kommunizierbare Form der
Ergebnisdokumentation einer Nutzungskontextanalyse.
Im Rahmen des Scenario Based Design (Rosson & Carrol
2002) wird der Nutzungskontext als narrative Beschreibung der derzeitigen Situation des Nutzungskontextes
dokumentiert.

Benutzerprofile

Beschreibung der Benutzereigenschaften als einfache
Liste oder als konkrete „Persona“ (Cooper 1999)

Anforderungen

Die Anforderungen an ein System, die aus dem Nutzungskontext abgeleitet werden, werden mehr oder
weniger formell erfasst (Sutcliffe 2002).

Kontext-Checklist

Berichtsvorlage für Nutzungskontextanalysen von Thomas und Bevan (1996)

5 Usability und Design

5.3.2.3
Definition von Usability-Zielen
Auf der Basis der Ergebnisse der Nutzungskontextanalyse werden
Usability-Ziele formuliert (DIN EN ISO 13407 2000; Mayhew 1999).
Ein typisches Usability-Ziel der Effizienz wäre beispielsweise, dass
Benutzer die Bestellung in dem zu testenden Online-Shop in höchstens zwei Minuten abschließen können. Bei der Formulierung von
Zielen spielen häufig auch andere Aspekte der Benutzererfahrung eine
wichtige Rolle. So lassen sich Beeinflussungsziele für persuasive Systeme oder Ziele hinsichtlich hedonischer Qualitäten formulieren.
Die Formulierung von Zielen hat den Vorteil, dass bei der Evaluation der Gestaltung überprüft werden kann, ob die Ziele erreicht werden. Das Ergebnis dieser Überprüfung bildet die Grundlage für die
Entscheidung, ob eine weitere Iteration durchlaufen werden muss.
Sobald die Usability-Ziele erreicht sind, wird keine weitere Iteration
benötigt.
Das Definieren eines harten Kriteriums macht aus der Logik eines
iterativen Prozesses durchaus Sinn, da so eine klare Entscheidung
über das Fortsetzen der Iterationen getroffen werden kann. Die praktische Handhabung von Usability-Zielen ist aus folgenden Gründen
meist nicht so einfach (vgl. auch Burmester & Görner 2003):

Usability-Ziele formulieren

Usability-Ziele
als Entscheidungsgrundlage

Schwierigkeiten der Definition
„harter“ Usability-Ziele

• Oftmals liegen keine Vergleichsdaten vor und die Festsetzung von
Kriterien ist allzu willkürlich. Einfacher ist es, wenn aktuelle Produkte mit Vorgängerversionen verglichen werden.
• Der Nutzungskontext ist meist komplex und es ist nicht möglich,
diesen von Beginn des Projektes vollständig zu erfassen und zu dokumentieren. Somit passiert es, dass sich im Prozess aufgrund neuer Erkenntnisse Ziele ändern können oder neue hinzukommen.
• Iterationen werden häufig nicht durch das Erreichen von Zielkriterien beendet, sondern durch Zeit- und Budgetgrenzen im Projekt.
Allerdings sind oft der Erkenntnisgewinn und damit der Qualitätssprung in der Gestaltung nach der ersten Evaluation am größten.
• Es ist fraglich, ob das knappe Verfehlen eines Usability-Ziels notwendigerweise zu einer neuen Iteration führen muss.
Die Entscheidung über eine weitere Iteration wird in der Praxis
häufig durch die gesamten zur Verfügung stehenden Informationen
und Randbedingungen beeinflusst. Wurde das Usability-Ziel wirklich
deutlich verfehlt? Lässt sich im bestehenden Zeit- und Kostenrahmen
noch eine weitere Iteration rechtfertigen? Solche Fragen gilt es bei der
Entscheidung über eine weitere Iteration im interdisziplinären Team
zu klären.

5.3 Design

Entscheidungsgrundlagen
über Iterationen in der Praxis

■
■
■

275

5.3.3
Entwurf und Gestaltung

Informationen der
Nutzungskontextanalyse
in Gestaltung überführen

Scenario-Based Design

276

■
■
■

5.3.3.1
„Bridging the gap“
Nach der Nutzungskontextanalyse liegen viele Informationen vor, die
in eine Gestaltung werden einfließen sollen. In seinem Buch „Bridging
the gap“ schreibt Larry E. Wood (1998, S. 3): „[…] while there are
some excellent sources of information on user interface design, none
contains specific descriptions of how a designer transforms the information gathered about users and their work into an effective user
interface design.“ Der Übergang von den Informationen aus dem
Nutzungskontext zum Entwurf und der Gestaltung ist schwierig. Der
Schritt wird umso schwieriger, je mehr Freiheitsgrade die Gestaltung
hat. Bei grafischen Benutzungsschnittstellen (graphical user interface,
GUI) werden durch die technischen Plattformen, die standardisierten
Dialogbausteine und die gültigen Style-Guides die möglichen Varianten der Gestaltung beschränkt. Versuche, den Entwurfs- und Gestaltungsprozess hochgradig zu strukturieren oder gar zu automatisieren
(z. B. Weisbecker 1995), haben nicht den gewünschten Erfolg erbracht.
Vielmehr muss anerkannt werden, dass der Entwurfsprozess eher
einen Diskurs im Gestaltungsteam erfordert als frühzeitige Festlegungen auf der Basis von Formalisierungen (Rosson & Carroll 2002).
5.3.3.2
Design
Um den Übergang methodisch zu unterfüttern und zu erleichtern,
wurden verschiedene Entwurfsverfahren entwickelt, wie z. B. der objektorientierte Entwurf grafischer Benutzungsschnittstellen (Janssen &
Ziegler 1996) bzw. OVID (Robert et al. 1998).
Kurz vorgestellt werden soll Scenario-Based Design von Rosson
und Carroll (2002), eine der am häufigsten verwendeten UsabilityEngineering-Methoden (Hudson 2000, zitiert nach Vredenburg, Mao,
Smith & Carey 2002). Dieser Ansatz widmet sich nicht der formalen
Analyse von Aufgaben oder der formalen Darstellung von Interaktionen, sondern „unlike approaches that consider human behavior
and experience through formal analysis and modeling of wellspecified tasks, scenario-based design is a relatively lightweight
method for envisioning future use possibilities“ (Rosson & Carroll
2003, S. 1033). Dieses Verfahren soll die Kreativität während der Entwurfsphase durch Förderung der Reflexion über die jeweiligen Gestaltungsideen unterstützen. Die Basis dieses Ansatzes ist das Kreieren
von Nutzungsgeschichten. Sie enthalten die relevanten Aspekte des

5 Usability und Design

Nutzungskontextes (beteiligte Personen, Aufgaben, soziale Umgebung
etc.) als Abfolge von Handlungen und Ereignissen, die zu einem Ergebnis führen.
Im Rahmen von Scenario-Based Design wird die Analysephase mit
einem sogenannten Problemszenario abgeschlossen. Dabei handelt es
sich um eine narrative Darstellung der derzeitigen Situation, d. h. so
wie die Nutzung ohne das neu zu entwickelnde Produkt aussieht (Rosson & Carroll 2002, S. 64 f.). Die eigentliche Entwurfs- und Gestaltungsphase baut darauf auf und verläuft in drei Arbeitsschritten. Im
ersten Schritt wird entwickelt, wie ein zu gestaltendes Produkt die
Tätigkeiten von Benutzern optimal unterstützen kann. Dabei werden
Szenarien als narrative Beschreibungen entworfen, die zeigen, welche
Funktionen den Benutzer unterstützen. Es wird entschieden, welche
Aspekte einer Aufgabe automatisiert werden und welche Aspekte
unter Kontrolle des Benutzers stehen sollen. Zudem werden Metaphern für die Tätigkeiten gesucht, um diese dann in der Benutzungsschnittstelle umzusetzen. Dieser Arbeitsschritt wird als „Activity Design“ (Rosson & Carroll 2002, S. 79 f.) bezeichnet. In einem zweiten
Schritt werden entlang der „Activity Scenarios“ die zentralen Informationsdarstellungen im Aufgabenfluss gestaltet. Dieser Gestaltungsschritt wird als „Information Design“ (Rosson & Carroll 2002,
S. 109 f.) bezeichnet. Hier wird an der Informationsarchitektur gearbeitet, so dass die unterschiedlichen Informationen, die für die Aufgabe benötigt werden, vorhanden sind und in einer angemessenen
Struktur präsentiert werden. Zudem wird die Grobnavigation zwischen Informationsbereichen entwickelt (vgl. auch Rosenfeld & Morville 2002). Der dritte und letzte Schritt ist das „Interaction Design“
(Rosson & Carroll 2002, S. 159 f.). Hier werden die notwendigen Interaktionen entworfen. Dialogelemente werden im Hinblick auf ihre
grafische Gestaltung und ihr Interaktionsverhalten bis ins Detail ausgearbeitet und spezifiziert.
Die Szenarien werden zunächst textuell und dann beim Information
Design und Interaction Design zusätzlich grafisch ausgearbeitet. Szenarien bieten eine Reihe von Vorteilen (nach Rosson & Carroll 2003):

Typen von Szenarien

Vorteile von Szenarien

• Die Szenarien sind hoch konkret und dennoch grob. Beide Fakto-

ren fördern Reflexion und Diskussion im Gestaltungsteam, was eine vorschnelle Fokussierung auf eine Lösung verhindert.
• Die Szenarien fokussieren klar auf Benutzerziele und Benutzeraufgaben, was beim Erreichen von Usability von entscheidender Bedeutung ist.
• Sie können schnell verworfen und geändert werden. Dahinter steht
die Erkenntnis, dass Gestaltungsideen mehrfach revidiert werden
müssen, bevor ein tragbarer Entwurf entsteht.

5.3 Design

■
■
■

277

• Gestaltungsideen in Form von Szenarien lassen sich außerordent-

lich gut kommunizieren, was schnelles Verständnis der Gestaltungsideen im Team fördert.

Formen des Gestaltungswissens

Angaben zu Gestaltungswissen

5.3.3.3
Gestaltungswissen
In der benutzerzentrierten Gestaltung werden die jeweiligen Eigenheiten des Nutzungskontextes in den Vordergrund gestellt. Ergänzend zu
dieser Betrachtungsweise stehen wissenschaftlich gesicherte oder in
der Praxis bewährte Erkenntnisse zur Gestaltung von Informationen
und Interaktionen zur Verfügung. Dieses Wissen liegt in Form wissenschaftlicher Arbeiten und in Form von Prinzipien, Regeln, Normen, Standards und Interaction Patterns (Entwurfsmuster von bewährten Gestaltungslösungen) für die Gestaltung vor.
Gestalter können auf dieses Wissen zurückgreifen. Allerdings muss
sich jede Regel und jedes Prinzip im Zyklus der Gestaltung beweisen.
Regeln und Prinzipien müssen auch gebrochen und verändert werden
können, wenn sich diese in der Evaluation nicht als anwendbar oder
vorteilhaft erweisen für die Benutzer, deren Aufgaben oder die Nutzungsumgebungen (Burmester & Machate 2003).
Im Folgenden werden ausgewählte Angaben zu Gestaltungswissen
für verschiedene Gestaltungsthemen gemacht:
• Dialoge für grafische Benutzungsschnittstellen
− DIN EN ISO 9241 Teil 12 bis 17 (1996–1998) enthält ca. 500 Gestaltungsregeln
− DIN EN ISO 9241 Teil 10 (1996) bzw. die überarbeitete Version
DIN EN ISO 9241-110 (2006) beschreiben die sieben zentralen Dialogprinzipien (Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Erwartungskonformität, Lernförderlichkeit, Steuerbarkeit, Fehlertoleranz, Individualisierbarkeit)
− Görner, Beu & Koller (1999) geben eine Hilfestellung zur konkreten Umsetzung der DIN EN ISO 9241 Teil 10, 12 bis 17 (1996–
1998) in grafische Benutzungsschnittstellen
− Industriestandards wie Microsoft Windows XP – Guidelines for
Applications (2003)
− Entwurfsmuster bzw. Interaction Patterns für grafische Benutzungsschnittstellen: van Welje (2002)
• Multimediale Produkte
− Prinzipien zum Multimedia-Design und spezielle Hinweise zu
Navigation, Steuerungselementen, Auswahl und Kombination
von Medien sowie Medienintegration und Aufmerksamkeitssteuerung: DIN EN ISO 14915 Teil 1–3 (2002, 2003)

278

■
■
■

5 Usability und Design

•

•

•
•

− Hinweise für Icons für Multimedia-Applikationen: ISO/IEC
18035 (2003)
− Spezielle Hinweise zur Gestaltung multimedialer Lernsysteme:
Issing & Klimsa (1997)
Geräte, mobile Produkte
− Wissen zur Gestaltung elektronischer Geräte: Baumann & Thomas (2001)
− Regeln zur Gestaltung von Interaktionen bei Haushalts- und Unterhaltungselektronikgeräten: Burmester (1997)
− Usability für Handhelds: Weiss (2002)
− Usability für Mobiltelefone: Lindholm (2003)
− Richtlinien für Geräte des täglichen Gebrauchs: ISO/FDIS 202821 (2006)
− Gestaltungswissen für Systeme im Fahrzeug (z. B. Navigationssystem): DIN EN ISO 15008
− Entwurfsmuster bzw. Interaction Patterns für mobile Geräte: van
Welje (2002)
Interfaces fürs Web
− Hinweise für Icons zur Verwendung in Browser-Applikationen:
ISO/IEC 18036 (2003)
− Hinweise zur Web-Usability: z. B. Nielsen (2000) und Balzert
(2004)
− Screen-Design: Thissen (2003)
− Entwurfsmuster für Web-Benutzungsschnittstellen: van Welje
(2002)
− Entwurfsmuster für Websites mit Schwerpunkt E-Commerce:
van Duyne, Landay & Hong (2003)
Interaction Patterns generell: Tidwell (2006)
Visualisierung komplexer Daten: z. B. Bederson & Shneiderman
(2003)

5.3.3.4
Partizipatives Gestalten
Benutzer können auch in der Gestaltungsphase direkt mit in die Entwurfsarbeiten einbezogen werden (Muller & Kuhn 1993). Mit der Methode CARD (Collaborative Anaysis of Requirements and Design;
Tudor 1993) können Benutzer den Ablauf von zentralen Informationssichten, dargestellt auf Karten, im Fluss ihrer Aufgaben legen.
PICTIVE (Plastic Interface for Collaborative Technology Initiatives
through Video Exploration; Muller 1991) dagegen eignet sich zum
detaillierten Ausarbeiten von Benutzungsoberflächen. Benutzer ent-

5.3 Design

Methoden CARD und PICTIVE

■
■
■

279

Überlegungen der Benutzer
bei der Gestaltung sind wichtig

Dokumentation der Grundlagen
von Gestaltungsentscheidungen

280

■
■
■

werfen Oberflächen mit auf Papier vorgefertigten Interaktionselementen (z. B. Schaltflächen) und erläutern ihre Gestaltungsentscheidungen
in Gruppenarbeit. Mit Hilfe der Card-Sorting-Technik (z. B. Kuniavky
2003, S. 192 f.) können Benutzer nach ihren eigenen Kriterien Informationen strukturieren. Die Benutzer erhalten die Aufgabe Informationseinheiten, die auf Karten bezeichnet sind, nach ihrem persönlichen Verständnis und ihren Vorlieben zu gruppieren.
Bei der Anwendung partizipativer Methoden ist es wichtig zu bedenken, dass Benutzer meist nicht in Gestaltung ausgebildet sind. Sie
sind Experten für ihre Bedürfnisse, Ziele und Aufgaben. Moderatoren
von Gestaltungsworkshops mit Benutzern müssen die Anforderungen
und Überlegungen der Nutzer verstehen, die zu den Gestaltungsvarianten geführt haben.
Neuere Ansätze der Benutzerpartizipation binden Benutzer und
Entwickler in Form von Rollenspielen in die Gestaltung ein. Nutzungssituationen werden mit einfachen Prototypen aus Papier oder Holz gespielt (Svanæs & Seland 2004). So können Abläufe, Informationsbedarf
etc. direkt in gespielten Situationen erprobt und untersucht werden.
5.3.3.5
Transparenz in der Gestaltung
Trotz Einhaltung des benutzerzentrierten Gestaltungsprozesses, Einbindung von fundiertem Gestaltungswissen und Arbeit von UsabilityExperten gibt es immer wieder Gestaltungsentscheidungen, bei denen
die Argumentationslage zwischen unterschiedlichen Experten im Patt
sein kann. In diesen Fällen lohnen sich Verfahren, um Argumente
transparent zu machen. Dazu lässt sich beispielsweise die Methode
QOC einsetzen (Bellotti 1993), bei der es um eine Gestaltungsfrage
(Q = question), um mögliche Gestaltungsvarianten (O = options) und
Entscheidungskriterien (C = criteria) geht. Die Entscheidungskriterien
sprechen für oder gegen eine Gestaltungsvariante. Wenn dies für die
zur Diskussion stehenden Gestaltungsvarianten dargestellt wird, ist
die Entscheidungssituation für alle Beteiligten deutlicher (Überblick
bei Louridas & Loucopoulos 2000). Auch mit einem transparenten
Verfahren gibt es Situationen, die nicht eindeutig entscheidbar sind.
Die strittigen Themen, z. B. welche der fraglichen Gestaltungsvarianten besser sind, können als Evaluationsziele formuliert werden, so
dass dann in der Evaluationsphase eine Klärung herbeigeführt werden
kann.

5 Usability und Design

5.3.4
Prototyping
5.3.4.1
Taxonomie des Prototyping
Prototypen dienen der Kommunikation von Gestaltungsideen. Das
Designteam muss sich über Gestaltungsideen verständigen und diese
bewerten. Produkt- und Projektmanagement sowie Marketing müssen
verstehen, in welche Richtung sich das Produkt entwickelt. Und „last
but not least“ müssen Gestaltungsideen potenziellen Benutzern kommuniziert und erfahrbar gemacht werden.
Beaudouin-Lafon und Mackay (2003, S. 1007) definieren einen Prototyp „[…] as a concrete representation of part or all of an interaction
system. A prototype is a tangible artefact, not an abstract description
that requires interpretation.“ Ferner unterscheiden Beaudouin-Lafon
und Mackay (2003, S. 1007 ff.) Prototypen in vier Dimensionen: Repräsentation (Form des Prototyps, z. B. Papierprototyp oder Softwaresimulation), Präzision (Detaillierungsgrad, z. B. Ausarbeitung grober
Skizzen bis hin zu vollständigen Bildschirmgestaltungen), Interaktivität (Umfang der Interaktionsmöglichkeiten, z. B. Aufgabenabläufe mit
Papierskizzen bis hin zu bedienbaren Eingaben in einer Softwaresimulation) und Evolution (Verortung im Lebenszyklus des Produkts).
Im Hinblick auf die Evolution lassen sich folgende Prototypen unterscheiden: rapid prototypes (für einen bestimmten Zweck entwickelt,
z. B. für einen Usability-Test hergestellt und dann weggeworfen), iterative prototypes (werden im Laufe des Gestaltungsprozesses weiter
ausgearbeitet und verfeinert) und schließlich evolutionary prototypes
(werden Schritt für Schritt Teil des Zielsystems).
Angelehnt an Rosson & Carroll (2002, S. 199) werden folgende
Formen von Prototypen exemplarisch beschrieben:

Erfahrbar und kommunizierbar machen
von Gestaltung

Definition von Prototyp

Formen von Prototypen

• Papierprototypen sind auf Papier skizzierte Benutzungsschnittstel-

len. Aus Serien von Informationssichten können ganze Aufgabenabläufe mit dem Produkt simuliert werden. Sogar Interaktionen
lassen sich mit Hilfe einfacher Hilfsmittel wie Post-Its darstellen
(vgl. auch Snyder 2003)
• Papier, Karton oder Holz eignen sich vor allem für mobile Geräte, die
durch Modelle aus unterschiedlichen Materialen simuliert werden.
• Storyboard sind Skizzen oder Bildschirmabzüge, an denen die Nutzung eines Produkts erläutert wird.
• Wizard-of-Oz-Prototypen dienen zur Simulation komplexer Systemreaktionen durch einen menschlichen Agenten. Beispielsweise

5.3 Design

■
■
■

281

•
•
•
•

•

Zweck eines Prototypen
muss beachtet werden

Horizontale und vertikale Prototypen

282

■
■
■

können so Sprachdialoge evaluiert werden, bevor überhaupt ein
Sprache erkennendes System implementiert wird.
Video Prototyp soll zeigen, wie ein System zukünftig genutzt werden kann.
Computeranimationen zeigen Bildschirmanzeigen und Eingaben
als laufenden Prozess.
Scenario Machine demonstriert Ein- und Ausgaben eines Nutzungsszenarios.
Rapid Prototype ist ein interaktives System, das einen bestimmten
Produktaspekt simuliert. Hierfür werden häufig spezielle Prototyping-Werkzeuge eingesetzt.
Systemteil ist ein Teil des Zielsystems.

5.3.4.2
Zielgerichtetes Prototyping
Prototyping im benutzerzentrierten Gestaltungsprozess muss zielgerichtet sein. Es geht nicht darum, das Produkt im Kleinen zu entwickeln. So kann es passieren, dass die Prototypentwicklung dann alle
typischen und arbeitsaufwendigen Arbeitsschritte der Entwicklung
von ganzen Systemen aufweist, wie Integration, Softwaretests, Debugging etc. (Burmester & Görner 2003, S. 51).
Der Zweck eines Prototyps muss zuvor bestimmt werden. Soll das
Management von dem zukünftigen Produkt beeindruckt werden, so
kann ein gut ausgearbeiteter Video-Prototyp angemessen sein. Sollen
die Informationsdarstellungen eines Wartungsunterstützungssystems
untersucht werden, so können Screenshots auf Papier reichen. Die
Navigation durch eine Informations-Website kann durch eine Reihe
von groben Papierskizzen verdeutlicht werden. Die in der Gestaltungsphase erhobenen Evaluationsziele steuern ebenfalls die Auswahl
der Art des Prototyps und seine Ausgestaltung. Die jeweilige Fragestellung, die in einem Evaluationsziel zum Tragen kommt, muss
durch die Prototypen abgedeckt werden können. Wenn ein Evaluationsziel existiert, bei dem zwei Gestaltungsideen gegeneinander getestet werden sollen, dann muss es jeweils einen Prototyp geben, der ein
vergleichbares Szenario abdeckt. Weitere Ausgangsinformationen für
die Gestaltung und Entwicklung von Prototypen sind die im Nutzungskontext definierten Aufgaben und die in der Entwurfs- und Gestaltungsphase entwickelten Szenarien.
Nielsen (1993, 93 f.) unterscheidet zwischen horizontalen und vertikalen Prototypen. Horizontale Prototypen veranschaulichen das zu
gestaltende Produkt in der Breite. Viele Sichten und Funktionen werden gezeigt, sind aber nicht oder nur teilweise ausgearbeitet. Diese
Art von Prototypen eignet sich beispielsweise, um einen ganzen Auf-

5 Usability und Design

gabenablauf zu demonstrieren. Details, wie einzelne Interaktionen,
werden weggelassen. In die Tiefe gehen die vertikalen Prototypen.
Mit ihnen werden einzelne Funktionen oder Interaktionen sehr detailliert erfahrbar gemacht. Wird bei einem Produkt beispielsweise
eine neue Eingabe-Interaktion erprobt, wie z. B. das Auswählen von
Informationen durch Fokussieren mit dem Blick des Benutzers, so
könnte dies durch eine Softwaresimulation speziell für die Auswahl
von Informationen auf einem Bildschirm mit einem Eye-TrackingSystem als Eingabeinstrument erfahrbar gemacht werden. Die innovative Eingabe-Interaktion ließe sich so in einem Usability-Test untersuchen. Der Rest des Produkts wäre durch diesen Prototyp dann
nicht abgedeckt.

5.3.5
Evaluation – Prüfung und Inspiration
5.3.5.1
Evaluation im benutzerzentrierten Gestaltungsprozess
Evaluation bedeutet zunächst einfach Bewertung oder Beurteilung.
Das kann ein fertiges Produkt sein oder, was im Prozess der benutzerzentrierten Gestaltung häufiger der Fall ist, ein Prototyp. Lawson
(2002, S. 47) untersuchte die Psychologie des Gestaltens und ermittelte, dass Evaluation eines Gestaltungsergebnisses integraler Bestandteil
jeglicher Form von Gestaltungsprozessen ist. Rauterberg et al. (1994,
S. 83–84) weisen darauf hin, dass Projekte zur Softwaregestaltung auf
der Basis eines „Test-Aktivitäts-Zyklus“ ablaufen sollten. In der Aktivitätsphase werden beispielsweise Entwürfe von Benutzungsschnittstellen als Prototypen erstellt und dann in der Testphase gemeinsam
mit Benutzern bewertet. So wird von einem „Optimierungszyklus“
gesprochen. Evaluation kann systematisch, aber auch unsystematisch
sein bzw. auf Daten beruhen oder auch ohne Daten erfolgen (Wottawa
& Thierau 2003, S. 13). Wie Lawson (2002) feststellte, beurteilen Gestalter ein Gestaltungsergebnis oft unsystematisch auf der Basis ihres
eigenen Wissens. Werden Evaluationsmethoden angewandt, wird der
Prozess der Bewertung stärker systematisiert und die Evaluationsergebnisse sind zuverlässiger und genauer. Zudem können Daten erhoben werden, indem man Benutzer hinzuzieht. Dies kann die Güte der
Evaluation weiter steigern.
In der benutzerzentrierten Gestaltung werden mit der Evaluation
zwei wesentliche Ziele verfolgt. Das erste Ziel ist, zu prüfen, ob die in
der Nutzungskontextanalyse erstellten Usability-Ziele erreicht wurden. Dieses Urteil bildet dann die Grundlage für die Entscheidung, ob
eine weitere Iteration erforderlich ist (vgl. Abb. 5.4).

5.3 Design

Evaluation als Bewertung
oder Beurteilung von Gestaltung

Ziele der Evaluation

■
■
■

283

Summative Evaluation

Formative Evaluation

Experten- und benutzerorientierte
Evaluation

284

■
■
■

Wenn es um die Frage geht, ob ein fertiges Produkt abschließend
den Anforderungen beispielsweise der Bildschirmarbeitsverordnung
(1996), einer Norm (z. B. der DIN EN ISO 9241 1996–1998; Dzida, et al.
2001) oder eines Industriestandards (z. B. Microsoft 2003) entspricht,
so wird von summativer Evaluation gesprochen. Ferner werden Evaluationsstudien eingesetzt, um zwischen Produkten (Preece 1994,
S. 604–605) oder zwischen alternativen Gestaltungsideen (vgl. Parallel
Design, Nielsen 1993, S. 85) Entscheidungen zu treffen.
Nach dem zweiten Ziel der Evaluation im benutzerzentrierten Gestaltungsprozess sollen Informationen gesammelt werden, um die Gestaltung zu optimieren. In diesem Fall wird von formativer Evaluation
gesprochen. Bei der Analyse der Häufigkeit von summativen und
formativen Usability-Tests ermittelten Hassenzahl und Burmester
(1999), dass formative Tests am häufigsten verwendet wurden. Im
Sinne einer Gestaltungsoptimierung können beispielsweise Fragen
untersucht werden, wie die Navigation verbessert werden kann, um
bestimmte Produkte in einem Online-Shop besser zu finden. Oder:
Welche Nutzungsprobleme treten im Prozess der Registrierung in
einem Online-Diskussionsforum auf?
5.3.5.2
Evaluationsmethoden
Um Evaluation möglichst systematisch auszuführen, kommen Evaluationsmethoden zum Einsatz. Diese lassen sich in expertenorientierte
und nutzerorientierte Verfahren einteilen. Bei expertenorientierten
Evaluationsmethoden bewerten Usability-Experten eine Benutzungsschnittstelle auf der Basis bestimmter Kriterien und Durchführungsregeln. Dies können Usability-Heuristiken (wie bei der Heuristischen
Evaluation von Nielsen 1994) oder theoretische Grundannahmen (wie
bei dem Cognitive Walkthrough von Wharton et al. 1994 oder der
Evaluation mit GOMS-Modellen bei Kieras 2003) sein. Bei der benutzerorientierten Evaluation werden repräsentative Benutzer bei der
Ausführung von realistischen Aufgaben befragt oder beobachtet. Befragungen können mittels Interviews und Fragebögen stattfinden. Bei
Beobachtungen wird die Interaktion eines Benutzers mit einem Produkt erfasst und protokolliert. Das Verhalten der Benutzer kann
durch einen Evaluator beobachtet oder die Interaktionen in Log-Files
vom System aufgezeichnet und anschließend ausgewertet werden.
Beim User-Testing werden die Benutzer zudem aufgefordert, laut zu
denken, d. h., ihre Gedanken während der Aufgabenbearbeitung auszusprechen. Die Analyse dieser verbalen Protokolle gibt Einblick in
die Erwartungen, Handlungsstrategien, Vorstellungen und Bewertungen der Benutzer.

5 Usability und Design

Formativ

Summativ

In den letzten Jahren sind weitere Beobachtungsmethoden hinzugekommen. Dazu gehört beispielsweise das Eye-Tracking (Scheier &
Heinsen 2003; Seifert & Rötting 2003), Erhebung physiologischer Daten (z. B. Hazlett 2003) oder Beobachtung der Gesichtsmimik zur Erfassung der emotionalen Reaktionen eines Benutzers (Mangold et al.
2000).
Eine Sammlung ausgewählter Evaluationsmethoden wird in Tabelle 5.4 präsentiert. Die verschiedenen Methoden werden grob nach den
Kategorien expertenorientiert versus benutzerorientiert und summativ versus formativ eingeteilt. Die Zuordnung zu den Kategorien ist
nicht immer eindeutig, denn einzelne Verfahren weisen Aspekte verschiedener Kategorien auf. Die Einteilung soll eher eine Tendenz aufzeigen. Für vertiefende Darstellungen wird auf die Fachliteratur verwiesen: Burmester (2003), Dumas (2003), Dumas und Redish (1999),
Hamborg, Gediga und Hassenzahl (2003), Kuniavsky (2003), Nielsen
(1993) Nielsen und Mack (1994), Sarodnick und Brau (2006) sowie
Schweibenz und Thissen (2003).
E

Expertenleitfäden für grafische Benutzungsschnittstellen: EVADIS II
(Oppermann et al. 1992) und SHIVA (Ziegler & Burmester 1995)

E
B

ErgoNorm: systematische Evaluation nach DIN EN ISO 9241 Teil 10
und 11 (Dzida et al. 2001)

B

Fragebögen wie z.B. ISONORM10, AttrakDiff 2 (Überblick bei Hamborg, Gediga & Hassenzahl 2003)
Log-File-Analyse (Kuniavsky 2003, S. 395 f.; Wessler, Geier & Koller
2002)

E

Heuristische Evaluation (Nielsen 1994; Tekom 2001), Cognitive
Walkthrough (Wharton et al. 1994), GOMS als modellbasiertes Evaluationsverfahren (Kieras 2003)

B

Pluralistic Usability Walkthrough (Bias 1994), IsoMetricsL (Hamborg
2002), Formatives Usability-Testing (Dumas & Redish 1995), EyeTracking (Scheier & Heinsen 2003)

5.3.5.3
Güte der Evaluation
Methoden, die im Rahmen der benutzerzentrierten Gestaltung in der
Evaluationsphase eingesetzt werden, müssen sich den Anforderungen
der Zeit- und Budgetbeschränkungen von Gestaltungs- und Entwicklungsprojekten anpassen. Zunächst wurden Methoden aus der Wissenschaft, z. B. experimentelle Verfahren der psychologischen Grundlagenforschung, einfach im Rahmen von industriellen Projekten
angewandt. Dabei wurde beklagt, dass diese Methoden nicht ausrei-

5.3 Design

Eye-Tracking, physiologische Daten,
Gesichtsmimik

Sammlung ausgewählter
Evaluationsmethoden

Tabelle 5.4:
Ausgewählte Evaluationsmethoden
(E = expertenorientiert;
B = benutzerorientiert)

Kriterien für den Einsatz
von Evaluationsmethoden

■
■
■

285

chend auf die dort existierenden Fragestellungen passten und einfach
viel zu aufwendig waren. Nielsen (1989) entwarf als Reaktion darauf
die sogenannten „discount usability methods“. Das waren Benutzerund Aufgabenbeobachtungen, Szenarios, einfaches lautes Denken und
heuristische Evaluation. Diese Methoden eigneten sich dazu, Benutzungsschnittstellen zu entwerfen, die den Anforderungen der Usability genügten und dabei realistisch in die meist knappen Zeit- und Budgetvorstellungen von Projektleitern passten. Tatsächlich sind
leichtgewichtige und eher „informelle“ Methoden in Projekten mit
benutzerzentrierter Gestaltung weit verbreitet (Vredenburg et al.
2002). Allerdings zeigen Studien zur Güte dieser Methoden, dass es
erhebliche Mängel in der wissenschaftlichen Fundierung und der korrekten praktischen Anwendung gibt (Gray & Salzmann 1998; Molich
et al. 1998, 1999). In Anlehnung an Cockton, Lavery & Woolrych
(2003) und Dumas (2003) und aus den oben beschriebenen Sachverhalten lassen sich folgende Erfolgskriterien der Planung und Durchführung formativer Evaluation nennen:
• Nutzungskontextanalyse ist unbedingt erforderlich, da Usability
sich aus dem Zusammenwirken des Produkts mit dem Nutzungskontext definiert.
• Evaluationsziele ergeben sich aus den Usability-Zielen und aus den
Fragestellungen, die aus anderen Studien oder aus der Gestaltungsphase stammen.
• Analyse des Produkts ist notwendig, da die Evaluatoren die relevanten Funktionen und Inhalte, die Navigations- und Dialogstrukturen
sowie die Informationsdarstellungen kennen müssen, um die Evaluation richtig planen und durchführen sowie auftretende Usability-Probleme richtig interpretieren zu können.
• Die Auswahl der Evaluatoren/Testnutzer spielt eine wichtige Rolle.
Bei expertenorientierter Evaluation müssen erfahrene UsabilityExperten ausgewählt werden, welche die Methoden beherrschen
und im optimalen Fall auch Experten im Nutzungskontext sind.
Letzteres ist selten der Fall. Bei benutzerorientierten Methoden
müssen die Zielgruppen für das jeweilige Produkt bekannt sein und
die Benutzer für die Evaluation entsprechend repräsentativ aus diesen Zielgruppen ausgewählt werden.
• Evaluationsplan enthält Informationen zu den Evaluationszielen,
zum Nutzungskontext, zu den zu prüfenden Produktbereichen, zu
den Evaluatoren und/oder Testbenutzern, zu den Aufgabenszenarien, zu den eingesetzten Methoden, zum Durchführungsplan sowie zur Ergebnisanalyse und Ergebnisdokumentation. Ein solcher
Evaluationsplan ist eine Art Vertrag zwischen den Evaluatoren und

286

■
■
■

5 Usability und Design

•
•

•

•

dem Auftraggeber. Der Evaluationsplan stellt sicher, wie die Evaluation ablaufen soll.
Einhaltung von Ausführungsregeln des Evaluationsverfahrens und
des Evaluationsplans ist notwendig.
Datenauswertung und -interpretation muss nach den Regeln der
jeweiligen Verfahren ausgeführt werden. Qualitative Daten aus Befragungen, lautem Denken oder Beobachtungen werden nach inhaltsanalytischen Verfahren qualitativer Forschung ausgewertet.
Severity-Rating ist die Einschätzung der Schwere eines UsabilityProblems durch Usability-Experten und ermöglicht eine Priorisierung aus Usability-Sicht. Nielsen (1994) hat eine Einschätzskala für
das Severity-Rating entwickelt.
Ergebnisdarstellung von Evaluationen werden in Berichtsform oder
als Präsentation niedergelegt. Für Usability-Tests wurde in der
Norm ANSI NCITS 354 (2001) ein „Common Industry Format for
Usability-Test Reports“ ein Standardberichtsformat festgelegt
(bzw. ISO/IEC 25062 2006). Obwohl dieser Standard für summative
Tests entwickelt wurde, können viele Anforderungen an die Informationen im Bericht formativer Tests übernommen werden. Es ist
sehr sinnvoll, dass die Evaluatoren die Ergebnisse präsentieren, da
sie die Usability-Probleme am genauesten kennen. Bei Rückfragen
und Gestaltungsideen zur Behebung der Usability-Probleme können sie somit fundierte und detailreiche Antworten geben.

5.3.6
Dokumentation
Sobald die Usability-Ziele erreicht wurden, kann eine Entscheidung
gegen eine weitere Iteration getroffen werden (vgl. Abb. 5.4). Das Ergebnis der Benutzungsschnittstellengestaltung muss nun für die weiteren Bearbeitungsschritte dokumentiert werden. Häufig folgen eine
komplette Ausarbeitung der grafischen Anmutung und der Start der
Entwicklung. Das Aussehen und Verhalten der Benutzungsschnittstelle wird in Form von Spezifikationen oder Prototypen als sogenannte
Live-Specification festgehalten. Begleitend dazu werden häufig StyleGuides geschrieben (Görner 2003), in denen neben den Layoutfragen
und der Informationspräsentation (pixelgenaue Bemaßung der Benutzungsschnittstellenelemente) vor allem Beschreibungen der für
das Produkt definierten Interaktionsformen enthalten sind (auch
Dialogbausteine genannt, vgl. Görner, Burmester & Kaja 1997).

5.3 Design

Sichern des Gestaltungsergebnisses

■
■
■

287

5.4
Integration von Usability-Engineering
und Software-Engineering
Notwendigkeit der Integration

Frühzeitiger Einsatz
von Usability-Engineering-Maßnahmen

Integration am Beispiel des Rational
Unified Process

Frühzeitige Einbindung und
Durchführung von UsabilityEngineering-Maßnahmen

Nutzungskontextanalyse in die
Anforderungserhebung integrieren

288

■
■
■

Benutzerzentrierte Gestaltung kann nur dann Erfolg haben, wenn sie
in Softwareentwicklungsprozesse integriert wird. Allerdings werden
häufig Software-Engineering-Prozesse unabhängig von UsabilityEngineering-Maßnahmen geplant und durchlaufen. Dies führt zu
Situationen, bei denen Zeit, Budget und Ressourcen für UsabilityMaßnahmen oder die Integration eines vollständigen benutzerzentrierten Gestaltungsprozesses im Rahmen der Softwareentwicklung
nicht oder nur unzureichend vorgesehen werden. So kommt es leicht
zu einer mangelnden Integration der Arbeitsergebnisse.
Den größten Nutzen aus dem Einsatz von Usability-EngineeringMethoden ziehen Projekte, die bereits in der Anforderungserhebung
und während des Systementwurfs konsequent auf deren Einsatz setzen. Obwohl das Durchlaufen einer Requirementsphase zum Standardablauf eines jeden Softwareentwicklungsprojekts zählt, bleibt eine
fundierte Auseinandersetzung mit den Anforderungen der Produktnutzer oftmals außen vor. Das erfolgreiche Einbinden von Benutzern
in die Requirementsphase, so wie es die DIN EN ISO 13407 (2000)
fordert, ist in der praktischen Anwendung vieler Software-Engineering-Prozesse noch nicht konsequent genug etabliert (Gulliksen, Göransson & Lif 2001).
Wie Usability-Maßnahmen und benutzerzentrierte Gestaltung in
Software-Engineering-Prozesse erfolgreich integriert werden können,
soll am Beispiel des Rational Unified Process (Kruchten 2000; RUP
IBM 2006) in den folgenden sechs Punkten erläutert werden (Burmester, Machate & Sandweg 2006):
1. Frühzeitige Einbindung und Durchführung von Usability-Engineering-Maßnahmen sind unbedingt notwendig. Überlegungen zu
Usability haben Einfluss auf Entscheidungen, die direkt die Softwareentwicklung betreffen. So weisen John, Bass und Adams (2003)
darauf hin, „usability requirements have an impact on architecture
design and […] architectural decisions can preclude delivery of a
usable system“.
2. Die Nutzungskontextanalyse muss in die Phase der Anforderungserhebung integriert werden. Im RUP würde die Nutzungskontextanalyse in der Prozessdisziplin „Geschäftsprozessmodellierung“
stattfinden.

5 Usability und Design

3. Die Gestaltung der Benutzungsschnittstelle wird im RUP bis hin zur
Spezifikation und zum Style-Guide dem Requirements-Workflow
zugeordnet (Kruchten, Ahlquist & Bylund 2001). Wichtig ist, dass
die Iterationen der benutzerzentrierten Gestaltung vor Beginn der
iterativen Softwareentwicklung abgeschlossen sind, da sonst mitten
in Entwicklungsaktivitäten Änderungen der Benutzungsschnittstelle zusätzliche Kosten verursachen können (vgl. Tab. 5.1).
4. Wird benutzerzentrierte Gestaltung in einen Software-EngineeringProzess integriert, so müssen die Rollen innerhalb des Prozesses
erweitert werden. Der RUP sieht im Requirements-Workflow folgende Rollen vor:
− Systemanalytiker (erarbeitet was das System leisten soll),
− Use Case Specifier (detailliert die Use Cases bzw. Anwendungsfälle des zu entwickelnden Systems),
− User Interface Designer (erarbeitet Use Case Storyboards und
User-Interface-Prototypen) und
− Architekt (definiert die Softwarearchitektur).
Um benutzerzentriert arbeiten zu können, muss die Rolle des Nutzungskontextanalytikers hinzugefügt werden. Die Rolle des User
Interface Designer muss aufgeteilt werden in:
− den Information-Architekten (definiert die Informationsarchitektur, legt Navigation fest)
− Interaction-Designer (Dialoge, Interaktion und Informationspräsentationen),
− Grafikdesigner (entwirft grafische Elemente, Layout, Typografie,
Anmutung etc.),
− Prototyper (entwickelt Prototypen),
− Usability Evaluator (evaluiert im Rahmen der Iterationen) sowie
− den Spezifikations- und Style-Guide-Redakteur (dokumentiert
die Gestaltung der Benutzungsschnittstelle).
5. Nachdem die Ergebnisse des benutzerzentrierten Gestaltungsprozesses dokumentiert sind, beginnt die Softwareentwicklung mit der
Konstruktionsphase des RUP. Spezifikationen der Benutzungsschnittstelle und des Style-Guides sind meist nicht ganz vollständig.
Bei der Implementierung tauchen spezielle Fragen auf, die erst
durch die Umsetzung in Software deutlich werden (z. B. Definition
seltener Interaktionssituationen). Die hier zu treffenden Gestaltungsentscheidungen sollten von den Inhabern der entsprechenden
Rollen (z. B. Interaction-Designer) getroffen werden. Änderungen
werden vom Spezifikations- und Style-Guide-Redakteur aufgenommen und dokumentiert.

5.4 Integration von Usability-Engineering und Software-Engineering

Gestaltung im
Requirements-Workflow

Erweiterung der Rollen im Prozess

Begleitung der Konstruktionsphase

■
■
■

289

Summative Evaluation in der Testphase

6. Zur Testphase des RUP gehört auch der Akzeptanztest. Im Sinne
der Qualitätskontrolle kann dieser nach Vorgaben des summativen
Evaluierens entworfen und die Einhaltung u. A. der typischen Usability-Kriterien Effektivität, Effizienz und Zufriedenstellung bestimmt werden (vgl. Dzida et al. 2001).

Anpassung Entwicklungsprozesses
an das jeweilige Projekt

Software-Engineering-Prozesse wie der Rational Unified Process
sind sehr komplexe Rahmenwerke, die auf die Bedingungen der jeweiligen Entwicklung angepasst werden müssen. Dies gilt insbesondere
für die Planung der Integration von benutzerzentrierter Gestaltung.
Gulliksen, Göransson und Lif untersuchten verschiedene Projekte, in
denen RUP eingesetzt wurde, und bemerkten: „The person responsible for applying RUP to user interface design thought that the model
contained answers to all problems and stopped acting as a thinking
person“ (Gulliksen, Göransson & Lif 2001, S. 294). Aktive Gestaltung
und Definition des für das jeweilige Projekt angemessenen Gestaltungs- und Entwicklungsprozesses bleibt bei aller methodischen Unterstützung des Usability-Engineering und Software-Engineerings unabdingbar.
Als Gegenbewegung gegen allzu überladene und starre SoftwareEngineering-Prozesse wurden agile Softwareentwicklungsansätze wie
z. B. Extreme Programming (Beck 1999) entwickelt. Dabei wird ein
Softwareprojekt in kleine Inkremente zerlegt und iterativ entwickelt.
Einfache und dynamische Methoden, die wenig Dokumentationsaufwand erfordern, kommen zum Einsatz. Aus diesen Ansätzen erwuchs
die Anforderung, dass Usability-Engineering an diese Prozesse angepasst werden sollte. Tatsächlich gibt es einige Parallelen zwischen
Extreme Programming und Usability-Engineering-Methoden, wie z. B.
„On-Site Customer“-Beteiligung auf Seiten des Extreme Programming
und partizipative Gestaltung auf Seiten des Usability-Engineering
(Gundelsweiler, Memmel & Reiterer 2004, S. 34). Allerdings gibt es
auch Konflikte zwischen den Ansätzen, denn beim Extreme Programming steht das schnelle Erstellen von Code im Vordergrund und
beim Usability-Engineering wird zunächst eine ausführliche Nutzungskontextanalyse vorgenommen. Gundelsweiler et al. (2004,
S. 36 ff.) schlagen einen agilen Usage-Centred Software Lifecycle vor,
bei dem in einer ersten Phase, der „Initial Requirements Usablity UpFront“, eine agile Anforderungsermittlung vorgenommen wird. Dort
werden mit empirischen Verfahren, wie z. B. Focus Groups (vgl.
Kap. 5.3.2.2), die notwendigen Informationen erhoben und in einfacher Form, z. B. auf Karten, dokumentiert. In der zweiten Phase, der
„Initial Conceptual Phase“, werden Entwurf der Benutzungsschnittstelle und Entwurf der Systemarchitektur getrennt. Gestaltungsideen
werden in unterschiedlich aufwendige Prototypen (Papier bis Flash-

Agile Softwareentwicklungsansätze

290

■
■
■

5 Usability und Design

Prototypen) umgesetzt und Benutzer- und Expertenreviews unterzogen. So können schwerwiegende Usability-Probleme, noch bevor eine
umfangreiche Softwareentwicklung stattgefunden hat, entdeckt werden. Die Programmierung findet in der dritten Phase statt, der
„Construction Phase“. Mit den ersten Inkrementen werden dann Reviews oder einfache Usability-Tests durchgeführt. So können weitere
Optimierungen vorgenommen werden. Mit der „Deployment und
Production Phase“ endet der agile Prozess.
Das Team besteht hier allerdings, anders als beim Extreme Programming, nicht nur aus Softwareentwicklern, sondern auch aus Usability Engineers, Grafikdesigner und Stakeholder (Auftraggeber, Manager, Benutzer) sowie einem „Tracker“, der auf die Einhaltung der
Usability-Ziele achtet.
Gerade für agile Softwareentwicklung eignen sich partizipative Gestaltungsmethoden (vgl. Kap. 5.3.3.4) oder einfache Evaluationsmethoden wie Pluralistic Walkthrough (Bias 1994, vgl. Kap. 5.3.5.2), da das
Gestaltungs- und Entwicklungsteam unmittelbar mit den Benutzern
zusammenarbeitet und so deren Feedback ohne Umwege aufnehmen
kann. Diese Form kurzzyklischer Anpassungen unterstützt auch die
Usability-Test-Methode RITE (Rapid Iterative Test and Evaluation)
von Medlock et al. (2005), bei der sofort Änderungen am Produkt bzw.
Prototyp vorgenommen werden, nachdem die ersten UsabilityProbleme im Test entdeckt wurden. Prinzipiell lassen sich UsabilityEngineering-Methoden auf die jeweiligen Projekt- und Prozesseigenschaften anpassen. Wichtig ist jedoch, dass nicht fundamentale
Durchführungsregeln der verschiedenen Methoden missachtet werden (vgl. Kap. 5.3.5.3).
Agile Gestaltungs- und Entwicklungsvorgehensweisen erfordern
ein hohes Maß an Kommunikation und direkter Zusammenarbeit im
Team. Die Dokumentation wird so gering wie möglich gehalten und
durch direkte Kommunikation ersetzt.

Team

Usability-Engineering-Methoden
für agile Prozesse

Kommunikation im Team ist vital

5.5
Abschlussüberlegungen
Zur Verwirklichung von Usability als Qualität der Nutzung liegen
nach dem geschilderten benutzerzentrierten Gestaltungsprozess und
der dazugehörenden Methodenunterstützung ausreichend Hilfsmittel
vor. Sie müssen in Projekte integriert werden, was zu vielfältigen positiven Konsequenzen führt, wie ebenfalls gezeigt wurde. Sicher sind
Weiterentwicklung und Ergänzung des Methoden- und Wissensfundus notwendig. Mit der angesprochenen Erweiterung des UsabilityKonzepts muss die Integration der Ziele von Informationsanbietern,

5.5 Abschlussüberlegungen

■
■
■

291

„user driven innovation“

die systematische Integration von persuasiven Aspekten und die explizite Berücksichtigung hedonischer Qualitäten bei der Gestaltung
von Benutzungsschnittstellen noch verbessert werden.
Usability-Engineering wird nach wie vor meist im Zusammenhang
mit Qualitätssicherung, Qualitätskontrolle und der Akzeptanz diskutiert. Ein unterschätzter Aspekt des Usability-Engineering ist, dass so
auch neue Ideen für Produkte oder Produkteigenschaften entstehen
können (Burmester & Görner 2003). Holmquist (2004) spricht von
„user driven innovation“. Die bisherige Strategie des „Technology
Push“, d. h., technische Neuerungen führen zu Innovationen, wurde
im Projekt InterLiving systematisch umgedreht. In diesem Projekt
ging es um Technologie für Familien. Hier wurde zunächst das Zusammenleben in Familien und deren Nutzungskontext empirisch
untersucht und dann im Rahmen partizipativer Gestaltung neue Produkte entworfen und beforscht (Westerlund 2006). Mit solchen Vorgehen entsteht Innovation im Rahmen eines „Technology Pull“.

Literatur
ANSI NCITS 354: Common Industry Format for Usability Test Reports. American
National Standards Institute, Inc. 2001
AttrakDiff: Online-Service. Letzter Zugriff am 15.09.2006 unter
http://www.attrakdiff.de (2005)
Balzert, H.: Webdesign & Web-Ergonomie – Websites professionell gestalten.
Dortmund: Herdecke 2004
Baumann, K. & Thomas, B.: User interface design of electronic appliances. London: Taylor & Francis 2001
Beaudouin-Lafon, M. & Mackay, W.: Evolution of Human-Computer Interaction:
From Memex to Bluetooth and beyond. In J.A. Jacko & A. Sears (Eds.), The
Human-Computer Interaction Handbook (pp. 1006–1031). Mahwah: Lawrence Erlbaum Associates 2003
Beck, K.: Extreme Programming Explained. Addison-Wesley 1999
Bederson, B.B. & Shneiderman, B.: The Craft of Information Visualization: Readings and Reflections. San Francisco: Morgan Kaufmann 2003
Bellotti, V.: Integrating theoreticians’ and practitioners’ perspectives with design
rationale. In: Proceedings of Interchi ’93 (pp. 101–106). New York: ACM 1993
Bertelsen, O.W. & Bødker, S.: Activity Theory. In: J.M. Carroll (Ed.), HCI Models,
Theories, and Frameworks – Toward a Multidisciplinary Science (pp. 291–
324). Amsterdam: Morgan Kaufmann 2003
Beu, A.: Analyse des Nutzungskontextes. In: J. Machate & M. Burmester (Hrsg.),
User Interface Tuning – Benutzungsschnittstellen menschlich gestalten
(S. 67–82). Frankfurt: Software und Support 2003
Bevan, N.: Usability is Quality of Use. In: Y.Anzai, H. Mori & K. Ogawa, (Eds.),
Proceedings of the Sixth International Conference on Human-Computer Interaction (pp. 349–354). Amsterdam: Elsevier 1995

292

■
■
■

5 Usability und Design

Beyer, H. & Holtzblatt, K.: Contextual design: defining customer-centered systems.
San Francisco, CA: Morgan Kaufmann 1998
Bias, R.: The Pluralistic Usability Walkthrough: Coordinated Empathies. In:
J. Nielsen & R.L. Mack (Eds.), Usability Inspection Methods (pp. 63–76).
New York: John Wiley 1994
Bias, R.G. & Mayhew, D.J.: Cost Justifying Usability, New York: Academic Press 1994
Bias, R. & Mayhew, D.: Cost Justifying Usability – An Update for the Internet Age.
Amsterdam: Morgan Kaufmann 2005
Bildschirmarbeitsverordnung: Verordnung über Sicherheit und Gesundheitsschutz bei der Arbeit an Bildschirmgeräten (BildscharbV) 1996
BITKOM: Internet. Letzter Zugriff am 5.09.2006 unter
http://www.bitkom.org/de/markt_statistik/38511_38547.aspx (2006a)
BITKOM: Mobilkommunikation. Letzter Zugriff am 5.09.2006 unter
http://www.bitkom.org/de/markt_statistik/38511_38545.aspx (2006b)
BITKOM: Technologische Modernisierung. Letzter Zugriff am 5.09.2006 unter
http://www.bitkom.org/41273_41261.aspx (2006c)
BITV: Verordnung zur Schaffung barrierefreier Informationstechnik nach dem
Behindertengleichstellungsgesetz (barrierefreie Informationstechnik-Verordnung – BITV) vom 17. Juli 2002
Blythe, M. A.; Overbeeke, K.; Monk, A. F.; Wright, P. C. (Eds.).: Funology. From
Usability to Enjoyment. Human-Computer Interaction Series. Volume 3.
Dordrecht: Kluwer Academic Publishers 2003
Brave, S. & Nass, C.: Emotion in Human-Computer Interaction. In: J.A. Jacko &
A. Sears (Eds.), The Human-Computer Interaction Handbook (pp. 81–97).
Mahwah: Lawrence Erlbaum Associates 2003
Brewster, S.: Non-Speech Auditory Output. In: J.A. Jacko & A. Sears (Eds.), The
Human-Computer Interaction Handbook (pp. 220–240). Mahwah: Lawrence Erlbaum Associates 2003
Brodbeck, F.C.: Fehlerbewältigungszeiten und die Nutzung von Unterstützungsmöglichkeiten (S. 80–94). In: M. Frese & D. Zapf (Hrsg.), Fehler bei der Arbeit mit dem Computer – Ergebnisse von Beobachtungen und Befragungen
im Bürobereich. Bern: Hans Huber 1991
Burmester, M. (Ed.): Guidelines and Rules for Design of User Interfaces for Electronic Home Devices. Stuttgart: IRB 1997
Burmester, M.: Ist das wirklich gut? Bedeutung der Evaluation für die benutzerzentrierte Gestaltung. In: J. Machate & M. Burmester (Hrsg.), User Interface
Tuning – Benutzungsschnittstellen menschlich gestalten (S. 97–119). Frankfurt: Software und Support 2003
Burmester, M.: Usability-Engineering für interaktive Wissensmedien. In: M. Eibl,
H. Reiterer, P.F. Stephan & F. Thissen (Hrsg.), Knowledge Media Design –
Grundlagen und Perspektiven einer neuen Gestaltungsdisziplin (S. 175–
210). München: Oldenbourg 2006
Burmester, M. & Dufner, A.: Designing the stimulation aspect of hedonic quality –
an exploratory study. In: M. Pivec (Ed.), Affective and Emotional Aspects of
Human-Computer Interaction: Emphasis on Game-Based and Innovative
Learning Approaches. The Netherlands: IOS Press 2006
Burmester, M. & Görner, C.: Das Wesen benutzerzentrierten Gestaltens. In: J.
Machate & M. Burmester (Hrsg.), User Interface Tuning – Benutzungs-

5.5 Literatur

■
■
■

293

schnittstellen menschlich gestalten (S. 47–66). Frankfurt: Software und Support 2003
Burmester, M. Hassenzahl, M. & Koller, F.: Usability ist nicht alles – Wege zu
attraktiven interaktiven Produkten. I-Com, 1 (2003)
Burmester, M., Hassenzahl, M., Koller, F.: Engineering attraktiver Produkte
AttrakDiff. In: J. Ziegler & W. Beinhauer (Hrsg.), Interaktion mit komplexen
Informationsräumen (S. 127–141). München: Oldenburg 2007
Burmester, M. & Machate, J.: Creative Design of Interactive Products and Use of
Usability Guidelines – a Contradiction? In: Proceedings of HCI international
2003. Mahwah: Lawrence Erlbaum Associates 2003
Burmester, M., Machate, J. & Sandweg, N.: Integration benutzerzentrierter Methoden in die Software-Entwicklung – Anregungen für die Projektpraxis.
I-COM, 3, 31–40 (2006)
Card, S.K., Pirolli, P., van der Wege, M., Morrison, J.B., Reeder, R.W., Schraedley,
P.K. & Boshart, J.: Information Scent as a Driver of Web Behavior Graphs:
Results of a Protocol Analysis Method for Web Usability. Chi Letters, Vol. 3
(1), 498–505 (2001)
Carroll, J.M.: HCI Models, Theories, and Frameworks – Toward a Multidisciplinary Science. Amsterdam: Morgan Kaufmann 2003
Carroll, J.M.: Beyond Fun. Interaction, Vol. XI.5, 38–40 (2004)
Carroll, J.M. & Thomas, J.C.: Fun. ACM SIGCHI Bulletin, 19(3), 21–24 (1987)
Chak, A.: Submit Now – Designing Persuasive Web Site. Boston: New Riders 2002
Cockton, G, Lavery, D. & Woolrych, A.: Inspection-based Evaluations. In: J.A.
Jacko & A. Sears (Eds.), The Human-Computer Interaction Handbook
(pp. 1118–1137). Mahwah: Lawrence Erlbaum Associates 2003
Cooper, A.: The Inmates Are Running the Asylum, Why High Tech Products Drive
Us Crazy and How To Restore The Sanity. Boston: Pearson Professional
Education 1999
Crosby M. E., Auernheimer, B., Aschwanden, C. & Ikehara, C.: Physiological Data
Feedback for Application in Distance Education. In: Proceedings of PUI
2001, Orlando FL, USA. New York: ACM 2001
Czaja, S.J. & Lee, C.C.: Designing Computer Systems for Older Adults. In: J.A.
Jacko & A. Sears (Eds.), The Human-Computer Interaction Handbook
(pp. 413–427). Mahwah: Lawrence Erlbaum Associates 2003
DIN EN ISO 9241: Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten. Berlin: Beuth 1996–1998
DIN EN ISO 9241-11: Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten – Teil 11: Anforderungen an die Gebrauchstauglichkeit; Leitsätze (ISO 9241-11:1998). Berlin: Beuth 1998
DIN EN ISO 9241-110: Ergonomie der Mensch-System-Interaktion – Teil 110:
Grundsätze der Dialoggestaltung. Berlin: Beuth 2006
DIN EN ISO 13407: Benutzer-orientierte Gestaltung interaktiver Systeme (ISO
13407:1999). Berlin: Beuth 2000
DIN EN ISO 14915: Software-Ergonomie für Multimedia-Benutzungsschnittstellen
– Teil 1-3. Berlin: Beuth 2002, 2003
DIN EN ISO 15008: Straßenfahrzeuge – Ergonomische Aspekte von Fahrerinformations- und Assistenzsystemen – Anforderungen und Bewertungsmethoden der visuellen Informationsdarstellung im Fahrzeug. Berlin: Beuth 2003

294

■
■
■

5 Usability und Design

DIN ISO/IEC 12119: Informationstechnik – Software-Erzeugnisse – Qualitätsanforderungen und Prüfbestimmungen. Berlin: Beuth 1995
Duchowski, A.T.: Eye-Tracking Methodology: Theory and Practice. London:
Springer-Verlag 2003
Dumas, J.C.: User-Based Evaluations. In: J.A. Jacko & A. Sears (Eds.), The Handbook of Human Computer Interaction (1093–1116). Mahwah: Lawrence Erlbaum Associates 2003
Dumas, J.C. & Redish, J.C.: A practical guide to usability testing. Exeter: Intellect 1999
Dutke, S.: Aufbau Mentaler Modelle durch Metaphern und konzeptuelle Modelle.
In: S. Dutke, Mentale Modelle: Konstrukte des Wissens und Verstehens
(Kap. 5). Göttingen: Verlag für Angewandte Psychologie 1994
Dzida, W.: Das IFIP-Modell für Benutzungsschnittstellen. Office Management, 6–8
(1983)
Dzida, W., Hoffmann, B., Freitag, R., Redtenbacher, W., Baggen, R., Geis, T., Beimel, J., Zurheiden, C., Hampe-Neteler, W., Hartwig, R. & Peters, H.:
Gebrauchstauglichkeit von Software. ErgoNorm: Ein Verfahren zur Konformitätsprüfung von Software auf der Grundlage von DIN EN ISO 9241
Teile 10 und 11. Dortmund: Wirtschaftsverlag NW 2001
Eibl, M., Reiterer, H., Stephan, P.F. & Thissen, F. (Hrsg.), Knowledge Media Design
– Grundlagen und Perspektiven einer neuen Gestaltungsdisziplin. München:
Oldenbourg 2006
Fogg, B.J.: „Stanford Guidelines for Web Credibility.“ A Research Summary from
the Stanford Persuasive Technology Lab. Stanford University.
www.webcredibility.org/guidelines (2002)
Fogg, B. J.: Persuasive Technology, Using Computers to Change What We Think
and Do. San Francisco, USA: Morgan Kaufmann 2003a
Fogg, B. J.: Prominence-Interpretation Theory: Explaining how people assess
credibility online. In: Proceedings of CHI 2003 Conference (pp. 722–723),
April 5–10, 2003, Ft. Lauderdale, Florida, USA. New York: ACM 2003b
Frese, M. & Zapf, D. (Hrsg.): Fehlersystematik und Fehlerentstehung: Eine theoretische Einführung. In: M. Frese. & D. Zapf (Hrsg.), Fehler bei der Arbeit mit
dem Computer: Ergebnisse von Beobachtungen und Befragungen im Bürobereich (S. 14–31). Reihe „Schriften zur Arbeitspsychologie“, Band 52. Bern:
Hans Huber 1991
Frese, M. & Zapf, D.: Action as the core of work psychology: A German approach.
In: H.C. Triandis, M.D. Dunnette & L.M. Hough (Eds.), Handbook of Industrial and Organizational Psychology, Vol. 4 (pp. 271–340). Palo Alto, CA:
Consulting Psychologists Press (2nd ed.) 1994
Görner, C.: Styleguides – Vom Ladenhüter zum Steuerungsinstrument. In: J. Machate & M. Burmester (Hrsg.), User Interface Tuning – Benutzungsschnittstellen
menschlich gestalten (S. 139–164). Frankfurt: Software und Support 2003
Görner, C., Beu, A. & Koller, F.: Der Bildschirmarbeitsplatz: Soft-wareentwicklung
mit DIN EN ISO 9241. Berlin: Beuth 1999
Görner, C., Burmester, M. & Kaja, M.: Dialogbausteine. Ein Konzept zur Verbesserung der Konformität von Benutzungsschnittstellen mit internationalen
Standards. In: R. Liskowsky, B.M. Velichkovsky & W. Wünschmann (Hrsg.),
Software-Ergonomie ’97. Usability-Engineering: Integration von MenschComputer-Interaktion und Software-Entwicklung. Stuttgart: B.G. Teubner
1997

5.5 Literatur

■
■
■

295

Gould, J.D.; Lewis, C.H.: Designing for usability: key principles and what designers
think. Communications of the ACM 28[3] 300–311 (1985)
Gray, W. & Salzmann, M.: Damaged merchandise? A review of experiments that
compare usability methods [special issue]. Human-Computer Interaction,
13, 203–261 (1998)
Gulliksen, J., Göransson, B. & Lif, M.: A User Centred Approach to ObjectOriented User Interface Design. In: M. van Harmelen (Ed.), Object Modeling and User Interface Design (pp. 283–312). Boston: Addison-Wesley 2001
Gundelsweiler, F., Memmel, T. & Reiterer, H.: Agile Usability-Engineering. In:
R. Keil-Slawik, H. Selke, G. Szwillus (Hrsg.): Mensch & Computer 2004: Allgegenwärtige Interaktion (S. 33–42). München: Oldenbourg 2004
Hackos, J. & Redish, J.: User and Task Analysis for Interface Design. New York:
Wiley & Sons 1998
Hamborg, K.-C.: Gestaltungsunterstützende Evaluation von Software: Zur Effektivität und Effizienz des IsoMetricsL Verfahrens. In: M. Herczeg, W. Prinz &
H. Oberquelle (Hrsg.), Mensch & Computer 2002 – Vom interaktiven Werkzeug zu kooperativen Arbeits- und Lernwelten (S. 303–312). Stuttgart: B.G.
Teubner 2002
Hamborg, K.-C., Gediga, G. & Hassenzahl, M.: Fragebogen zur Evaluation. In:
S. Heinsen & P. Vogt (Hrsg.), Usability praktisch umsetzen (S. 172–187).
München: Hanser 2003
Hassenzahl, M.: Focusgruppen. In: S. Heinsen; P. Vogt (Hrsg.), Usability praktisch
umsetzen (S. 138–153). München: Hanser 2003a
Hassenzahl, M.: The thing and I: Understanding the Relationship between User
and Product. In: M. A. Blythe, C.J. Overbeeke, A.F. Monk & P. C. Wright
(Eds.), Funology. From Usability to Enjoyment (pp. 3–42). HumanComputer Interaction Series. Volume 3. Dordrecht: Kluwer Academic Publishers 2003b
Hassenzahl, M.: The interplay of beauty, goodness and usability in interactive
products. Human Computer Interaction, 19, 319–349 (2004)
Hassenzahl, M. & Burmester, M.: Zur Diagnose von Nutzungsproblemen: Praktikable Ansätze aus der qualitativen Forschungspraxis. Konferenzband der
ZMMS Konferenz 5.10 – 8.10.1999 in Berlin 1999
Hassenzahl, M., Burmester, M. & Koller, F.: AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und pragmatischer Qualität. In:
J. Ziegler & G. Szwillus (Hrsg.), Mensch & Computer 2003. Interaktion in
Bewegung (S. 187–196). Stuttgart: Teubner 2003
Hassenzahl, M., Platz, A., Burmester, M. & Lehner, K.: Hedonic and Ergonomic
Quality Aspects Determine a Software's Appeal (pp. 201–208). In: Proceedings of the CHI 2000 Conference on Human Factors in Computing. New
York: ACM 2000
Hassenzahl, M.& Tractinsky, N.: User experience – a research agenda. Behaviour &
Information Technology. Volume 25, Number 2, 91–97 (2006)
Hazlett, R.: Measurement of User Frustration: A Biologic Approach. In: Proceedings of CHI 2003 Conference on Human Factors in Computing Systems
(pp. 734–735). New York ACM 2003
Herczeg, M.: Software-Ergonomie. Bonn: Addison-Wesley 1994

296

■
■
■

5 Usability und Design

Hinckley, K.: Input Technologies and Techniques. In: J.A. Jacko & A. Sears (Eds.),
The Human-Computer Interaction Handbook (pp. 151–169). Mahwah Lawrence Erlbaum Associates 2003
Hinderberger, R.: Usability als Investition. In: S. Heinsen; P. Vogt (Hrsg.), Usability praktisch umsetzen (S. 23–40). München: Hanser 2003
Hix, D. & Hartson, H.R.: Developing user interfaces: ensuring usability through
product and process. New York: John Wiley 1993
Holmquist, L.E.: User-Driven Innovation in the Future Applications Lab. In: Proceedings of CHI 2004, April 24–29, 2004, Vienna, Austria. New York: ACM 2004
Honold, P.: Interkulturelles Usability-Engineering. Eine Untersuchung zu kulturellen Einflüssen auf die Gestaltung und Nutzung technischer Produkte
Fortschritt-Berichte. Fortschritt-Berichte, Band Nr. 647. Düsseldorf: VDIVerlag 2000
Igbaria, M.; Schiffman, S.J.; Wieckowski, T.J.: The respective roles of perceived
usefulness and perceived fun in the acceptance of microcomputer technology. Behaviour & Information Technology 13[6], 349–361 (1994)
IBM RUP: Rational Method Composer and RUP. Letzter Zugriff am 20.09.2006
unter
http://www-128.ibm.com/developerworks/rational/products/rup (2006)
ISO 13407: Human-centred design processes for interactive systems. Berlin: Beuth
1999
ISO/IEC 18035: Information Technology – Icon symbols and functions for controling multimedia applications. Berlin: Beuth 2003
ISO/IEC 18036: Information Technology – Icon symbols and functions for web
browser toolbars: Beuth 2003
ISO/IEC 25062: Software-Engineering – Qualitätskriterien und Bewertung von
Softwareprodukten (SQuaRE) – Gemeinsames Industrieformat (CIF) für
Berichte über Gebrauchstauglichkeitsprüfungen. Berlin: Beuth 2006
ISO/FDIS 20282-1: Ease of operation of everyday products – Part 1: Design requirements for context of use and user characteristics. Berlin: Beuth 2006
ISO/TR 16982: Ergonomics of human-system interaction – Usability methods
supporting human-centred design. Berlin: Beuth 2002
Issing, L.J. & Klimsa, P.: Information und Lernen mit Multimedia. Weinheim:
Beltz / Psychologie Verlags Union 1997
Iwata, H.: Haptic Interfaces. In: J.A. Jacko & A. Sears (Eds.), The HumanComputer Interaction Handbook (pp. 206–219). Mahwah: Lawrence Erlbaum Associates 2003
Iwata, H.: Art and Technology in Interface Devices. VRST’05, November 7–9
(pp. 1–7). Monterey, California, USA. ACM 2005
Iwata, H., Yano, H., Uemura, T. & Moriya, T.: Food Simulator: A Haptic Interface
for Biting, vr, p. 51, IEEE Virtual Reality Conference (VR'04) 2004
Jacko, J.A. & Sears, A. (Eds.): The Human-Computer Interaction Handbook.
Mahwah: Lawrence Erlbaum Associates 2003
Jacko, J.A., Vitense, H.S. & Scott, I.U.: Perceptual Impairments and Computing
Technologies. In: J.A. Jacko & A. Sears (Eds.), The Human-Computer Interaction Handbook (pp. 504–522). Mahwah: Lawrence Erlbaum Associates 2003
Jameson, A.: Adaptive Interfaces and Agents. In: J.A. Jacko & A. Sears (Eds.), The
Human-Computer Interaction Handbook (pp. 306–310). Mahwah: Lawrence Erlbaum Associates 2003

5.5 Literatur

■
■
■

297

Janssen, C., Ziegler, J.: Objektorientierter Entwurf graphischer Benutzerschnittstellen. In: K.-P. Fähnrich, C. Janssen & G. Groh. (Hrsg.), Werkzeuge zur
Entwicklung graphischer Benutzerschnittstellen: Grundlagen und Beispiele
(S. 111–122). Handbuch der Informatik. München: Oldenbourg 1996
John, B.E.: Information Procession and Skilled Behavior. In: J.M. Carroll (Ed.),
HCI Models, Theories, and Frameworks – Toward a Multidisciplinary Science (pp. 55–102). Amsterdam: Morgan Kaufmann 2003
John, B.E., Bass, L., Adams, R.J.: Communication across the HCI/SE divide: ISO
13407 and the Rational Unified Process®. In: Proceedings of HCI International, June 2003
Jordan, P.: Designing pleasurable products. An introduction to the new human
factors. London, New York: Taylor & Francis 2000
Jørgensen, A.H.: Marrying HCI/Usability and Computer Games: A Preliminary
Look. In: NordiCHI '04, October 23–27, 2004 Tampere, Finland. New York:
ACM 2004
Kalbach, J.: Von Usability überzeugen. In: S. Heinsen; P. Vogt (Hrsg.), Usability
praktisch umsetzen (S. 8–23). München: Hanser 2003
Kalin, S.: Mazed and confused. CIO Web Business Magazine, April 1, 1999. Retrieved September 5, 2006, from
http://www.cio.com/archive/webbusiness/040199_use.html (1999)
Kantner, L., Hinderer Sova, D. & Rosenbaum, S.: Alternative Methods for Field
Usability Research. In: SIGDOC’03, October 12–15, 2003, San Francisco,
California, USA (pp. 68–72). New York: ACM 2003
Karat, C.M., Vergo, J. & Nahamoo, D.: Conversational Interface Technologies. In:
J.A. Jacko & A. Sears (Eds.), The Human-Computer Interaction Handbook
(pp. 169–186). Mahwah: Lawrence Erlbaum Associates 2003
Kaye, J.: Making Scents: aromatic output for HCI. interactions, Vol. 11 (1). 48–61
(2004)
Kieras, D.: Model-based Evaluation. In: J.A. Jacko & A. Sears (Eds.), The HumanComputer Interaction Handbook (pp. 1139–1151). Mahwah: Lawrence Erlbaum Associates 2003
Kirwan, B & Ainsworth, L.K.: A guide to task analysis. London: Tailor & Francis 1992
Kruchten, P.: The Rational Unified Process – An Introduction, Second Edition,
Addison Wesley Longman 2000
Kruchten, P., Ahlquist, S., Bylund, S.: User Interface Design in the Rational Unified
Process. In: M. van Harmelen (Ed.), Object Modelling and User Interface
Design (pp. 161–198). Boston: Addison-Wesley 2001
Krueger, R. A. & Casey, M. A.: Focus Groups. A practical guide for applied research. Thousand Oaks: Sage 2000
Krüger, H. & Neukun, A.: Der Fahrimulator als Herausforderung für Entwicklung
und Anwender. Zur Forderung nach der Realitätstreue von Fahrsimulation.
In: 1. Motion Simulator Conference, Braunschweig 2005
Kuniavky, M.: Observing the User Experience. San Francisco: Morgan Kaufmann
2003
Lawson, B.: How Designers Think. The design process demystified. 3rd Ed. Oxford: Architectural Press 2002
Lindholm, C.: Mobile usability: how Nokia changed the face of the mobile phone.
New York: McGraw-Hill 2003

298

■
■
■

5 Usability und Design

Logan, R.J.: Behavioral and emotional usability: Thomson Consumer Electronics. In:
M. Wiklund (Ed.) Usability in Practice. Cambridge, MA: Academic Press 1994
Louridas, P. & Loucopoulos, P.: A Generic Model for Reflective Design. ACM
Transactions on Software-Engineering and Methodology, Vol. 9, No. 2, 199–
237 (2000)
Luczak, H., Roetting, M. & Oehme, O.: Visual Displays. In: J.A. Jacko & A. Sears
(Eds.), The Human-Computer Interaction Handbook (pp. 187–205). Mahwah: Lawrence Erlbaum Associates 2003
MacKenzie, I.S.: Motor Behavior Models for Human-Computer Interaction. In:
J.M. Carroll (Ed.), HCI Models, Theories, and Frameworks – Toward a Multidisciplinary Science (pp. 27–54). Amsterdam: Morgan Kaufmann 2003
Mangold, R., Reese, F., Klauck, T. & Stanulla, S.: „Designed for emotions“? Mimikbasierte Mikroevaluation von Onlineangeboten. planung & analyse, 58–81
(2000)
Marcus, A.: Return of Investment for usable UI Design, User Experience, 1(3), 25–
31 (2002)
Marcus, A.: User Interface Design’s Return of Investment: Examples and Statistics.
In: R.G. Bias, & D.J. Mayhew, (Eds.), Cost Justifying Usability – An Update
for the Internet Age (S.18–39). Amsterdam: Morgan Kaufmann 2005
Mayhew, D.L: The Usability-Engineering lifecycle. A practitioner's handbook for
user interface design. San Francisco, CA: Morgan Kaufmann 1999
Medlock, M.C., Wixon, D., McGee, M. & Welsh, D.: The Rapid Iterative Test and
Evlauation Method: Better Products in Less Time. In: R.G. Bias, & D.J.
Mayhew, (Eds.), Cost Justifying Usability – An Update for the Internet Age
(S. 489–517). Amsterdam: Morgan Kaufmann 2005
Microsoft: Windows XP – Guidelines for Applications. Letzer Zugriff am 02. Jan.
2003 unter
http://www.microsoft.com/hwdev/windowsxp/downloads/ (2003)
Molich, R., Bevan, N., Curson, I, Butler, S. Kindlung, E. Miller, D. & Kirakowski, J.:
Comparative evaluation of usability tests. Pro-ceedings of the Usability Professionals’ Association 1998
Molich, R. Thomsen, D.A., Karyukina, B., Schmidt, L., Ede, M., van Oel, W. &
Arcuri, M.: Comparative Usability Evaluation. Letzter Zugriff am 21.03.2003
unter http://www.dialogdesign.dk/tekster/cue2/abstract.doc (1999)
Muller, M.J.: PICTIVE – An Exploration in Participatory Design. In: Proceedings
of the SIGCHI conference on Human factors in computing systems: Reaching through technology (pp. 225–231). New York: ACM 1991
Muller, M.J. & Kuhn, S.: Partcipatory design. Communications of the ACM, 36[24],
p. 28 (1993)
Neuper C., Müller G., Kübler A., Birbaumer N., Pfurtscheller G.: Clinical application
of an EEG-based Brain-Computer Interface: a case study in a patient with severe motor impairment. Clinical Neurophysiology, 114(3), 399–409 (2003)
Nielsen, J.: Usability-Engineering at a discount. In: G. Salvendy & M.J. Smith
(Eds.), Designing and Using Human-Computer Interfaces and Knowledge
Based Systems. Amsterdam: Elsevier Science 1989
Nielsen,J.: Usability-Engineering. Boston, San Diego: Academic Press 1993
Nielsen, J.: Heuristic Evaluation. In: J. Nielsen & R.L. Mack (Eds.), Usability Inspection Methods (pp. 25–62). New York: John Wiley 1994
Nielsen, J.: Web Design – Erfolg des Einfachen. München: Markt & Technik 2000

5.5 Literatur

■
■
■

299

Nielsen, J. & Mack, R.L. (Eds.): Usability Inspection Methods. New York: John
Wiley 1994
Norman, D.: Cognitive Engineering. In: D.A. Norman & S.D. Draper (Eds.), User
Centered System Design (pp. 31–61). Hillsdale, NJ: Lawrence Erlbaum Associates 1986
Norman, D.: The Psychology of Everyday Things. New York: Basic Books 1988
Norman, D.: Emotional Design. New York: Basic Books 2004
Oakley, I., McGee, M.R., Brewster, S. & Gray, P.: Putting the feel in ‚look and feel‘.
In: Proceedings of the SIGCHI conference on Human factors in computing
systems table of contents, The Hague, The Netherlands (pp. 415–422). New
York: ACM Press 2000
Oberquelle, H.: Formen der Mensch-Computer-Interaktion. In: H. Balzert (Hrsg.),
Einführung in die Software Ergonomie (S. 95–144). Berlin: Walter De
Gruyter 1994
Olson, G.M. & Olson, J.S.: Groupware and Computer-Supported Cooperative
Work. In: J.A. Jacko & A. Sears (Eds.), The Human-Computer Interaction
Handbook (pp. 583–595). Mahwah: Lawrence Erlbaum Associates 2003
Oppermann, R., Murchner, B., Reiterer, H. & Koch, M.: Software-ergonomische
Evaluation. Der Leitfaden EVADIS II. Berlin: Walter de Gruyter 1992
Oviatt, S.: Multimodal Interfaces. In: J.A. Jacko & A. Sears (Eds.), The HumanComputer Interaction Handbook (pp. 286–304). Mahwah: Lawrence Erlbaum Associates 2003
Pagulayan, R.J., Steury, K.R., Fulton, B. & Romero, R.L.: Designing for fun: user
testing case studies. In: M.A. Blythe, K. Overbeeke, A.F. Monk & P.C. Wright
(Eds.), Funology – From Usability to Enjoyment (pp. 137–150). Dordrecht:
Kluwer 2003
Perry, M.: Distributed Cognition. In: J.M. Carroll (Ed.), HCI Models, Theories, and
Frameworks – Toward a Multidisciplinary Science (pp. 193–224). Amsterdam: Morgan Kaufmann 2003
Pettersson, R.: Information design: an introduction. Philadelphia: Benjamins 2002
Pirolli, P.: Exploring and Finding Information. In: J.M. Carroll (Ed.), HCI Models,
Theories, and Frameworks – Toward a Multidisciplinary Science (pp. 157–
192). Amsterdam: Morgan Kaufmann 2003
Pirolli, P. & Card, S.K.: Information Foraging. Psychological Review, 106, 643–675
(1999)
Preece, J.: Human-Computer Interaction. Wokingham: Addison-Wesley 1994
Proctor, R.W. & Vu, K.-P L.: Human Information Procession: An overview for
Human-Computer Interaction. In: J.A. Jacko & A. Sears (Eds.), The HumanComputer Interaction Handbook (pp. 36–51). Mahwah: Lawrence Erlbaum
Associates 2003
Raskin, J.: Das intelligente Interface. München: Addison-Wesley 2000
Rauterberg, M., Spinas, P., Strohm, O., Ulich, E. & Waeber, D.: Benutzerorientierte
Software-Entwicklung. Zürich: Hochschulverlag a. d. ETH Zürich; Stuttgart:
B.G. Teubner 1994
Robert, D., Berry, D., Mullaly, J. & Isensee, S.: Designing for the User with OVID.
Macmillan Technical Publishers 1998
Rosenfeld, L. & Morville, P.: Information Archtecture (2nd Edition). Sebastopol:
O’Reilly 2002

300

■
■
■

5 Usability und Design

Rosson, M.B. & Carroll, J.M.: Usability-Engineering – Scenario-based development
of human-computer interaction. San Francisco: Morgan Kaufmann 2002
Rosson, M.B. & Carroll, J.M.: Scenario-Based Design. In: J.A. Jacko & A. Sears
(Eds.), The Human-Computer Interaction Handbook (pp. 1032–1050).
Mahwah: Lawrence Erlbaum Associates 2003
Sarodnick, F. & Brau, H.: Methoden der Usability Evaluation: wissenschaftliche
Grundlagen und praktische Anwendung. 1. Aufl. Bern: Hans Huber 2006
Scheier, C & Heinsen, S.: Aufmerksamkeitsanalyse. In: S. Heinsen & P. Vogt
(Hrsg.), Usability praktisch umsetzen (S. 172–187). München: Hanser 2003
Schwabe, G. & Löber, A.: Personalisierbare elektronische Gruppenräume. In:
M. Herczeg, W. Prinz & H. Oberquelle (Hrsg.), Mensch & Computer 2002:
Vom Werkzeug zu Kooperativen Arbeits- und Lernwelten (S. 65–74). Stuttgart: B.G. Teubner 2002
Schweibenz, W. & Thissen, F.: Qualität im Web: benutzerfreundliche Webseiten
durch Usability Evaluation.Berlin: Springer-Verlag 2003
Sears, A. & Young, M.: Physical Disabilities and Computing Technologies: An
Analysis of Impairments. In: J.A. Jacko & A. Sears (Eds.), The HumanComputer Interaction Handbook (pp. 482–503). Mahwah: Lawrence Erlbaum Associates 2003
Seifert, K. & Rötting, M.: Sonderheft: Blickbewegung. MMI-interaktiv Journal.
Zugriff am 23.02.2004 unter
http://www.useworld.net/servlet/handleiss?obj_id=558&cat_id=40&vie=tru
(2003)
Shneiderman, B. & Plaisant, C.: Designing the User Interface. Bosten: Pearson 2004
Snyder, C.: Paper Prototyping. Amsterdam: Morgan Kaufmann 2003
Sutcliffe, A.: User centred requirements engineering.1. Publ. London: SpringerVerlag 2002
Sutcliffe, A.: Multimedia Interfaces. In: J.A. Jacko & A. Sears (Eds.), The HumanComputer Interaction Handbook (pp. 245–262). Mahwah: Lawrence Erlbaum Associates 2003
Svanæs, D. & Seland, G.: Putting the Users Center Stage: Role Playing and Low-Fi
Prototyping Enabled End Users to Design Mobile Systems. In: Proceedings
of CHI Conference (pp. 479–486), April 24–29, 2004 in Vienna 2004
Tamborello II, F.P. & Byrne, M.D.: Information Search: The Intersection of Visual
and Semantic Space (1821–1824). In: Proceedings of CHI 2005, April 2–7,
2005, Portland, Oregon, USA. New York: ACM 2005
Tekom: Heuristiken zur Webkommunikation. Zugriff am 6.09.2006 unter
http://www.tekom.de/index_neu.jsp?url=/servlet/
ControllerGUI?action=voll&id=289 (2001)
Tidwell, J.: Designing Interfaces – Patterns for Effective Interaction Design. Beijing: O’Reilly 2006
Thissen, F: Kompendium Screen-Design. Berlin: Springer-Verlag 2003
Thomas, C. & Bevan, N.: Usability Context Analysis – A Practical Guide, Version
4.04. Letzter Zugriff am 15.09.06 unter
http://www.usabilitynet.org/papers/UCA_V4.04.doc. (1996)
Tudor, L.-G.: A participatory design technique for high-level task analysis, critique
and redesign: The CARD method. In: Proceedings of the Human Factors
and Ergonomics Society (pp. 295–299). Meeting, Seattle, October 1993

5.5 Literatur

■
■
■

301

Tullis, T. & Wood, L.: How Many Users Are Enough for a Card-Sorting Study?
Proceedings UPA’2004 (Minneapolis, MN, June 7–11, 2004) 2004
Ulich, E.: Arbeitspsychologie. 3. Aufl. Stuttgart: Schäffer-Poeschel 1994
van Duyne, D.K., Landay, J.A. & Hong, J.I.: The design of sites. Boston: AddisonWesley 2003
van Welie: Interaction Design Patterns. Letzter Zugriff am 26.09.2006 unter
http://www.welie.com/patterns (2002)
Vredenburg, K., Mao, J.Y., Smith, P.W. & Carey, T.: A Survey of User-Centered
Design Practice. In: Proceedings of CHI 2002, April 20–25, 2002, Minneapolis, Minnesota, USA. New York: ACM 2002
Wahlster, W.: SmartKom: Symmetric Multimodality in an Adaptive and Reusable
Dialogue Shell. In: R. Krahl & D. Günther (Eds), Proceedings of the Human
Computer Interaction Status Conference 03.06.2003 (S. 47–62). Berlin: DLR
2003
Wandmacher, J.: Software-Ergonomie. Berlin: Walter de Gruyter 1993
Ware, C.: Design as Applied Perception. In: J.M. Carroll (Ed.), HCI Models, Theories, and Frameworks – Toward a Multidisciplinary Science (pp. 11–26).
Amsterdam: Morgan Kaufmann 2003
Weisbecker, A.: Ein Verfahren zur automatischen Generierung von softwareergonomisch gestalteten Benutzungsoberflächen. Berlin: Springer-Verlag
1995
Weiss, S.: Handheld Usability. New York, Chichester: Wiley 2002
Wessler, R., Geier, J. & Koller, F.: Using Server Log files to Assess a Web Site’s
Usability: The ErgoMind Indices. In: H. Luczak, A.E. Çakir & G. Çakir
(Eds.), WWDU 2002 Work With Display Units World Wide Work (pp. 305–
306). Berlin: Ergonomic 2002
Westerlund, B.: Design of Communication Interface Together with Family Members in interLiving. I-COM, 1, 54–58 (2006)
Wharton, C., Rieman, J., Lewis, C. & Polson, P.: The Cognitive Walkthrough
Method: A Practitioners’s Guide. In: J. Nielsen & R.L. Mack (Eds), Usability
Inspection Methods (pp. 105–140). New York: John Wiley 1994
Wood, L.E.: User interface design: bridging the gap from user requirements to
design. Boca Raton: CRC Press 1998
Wottawa, H. & Thierau, H.: Lehrbuch Evaluation. 3. Aufl. Bern: Hans Huber 2003
Ziegler, J. & Burmester, M.: Structured Human Interface Validation Technique –
SHIVA. In: Y. Anai, K. Ogawa & H. Mori (Eds.), Symbiosis of Human and
Artifact (pp. 899–906). Proceedings of the 6th International Conference on
Human-Computer-Interaction. Tokio, Japan, 9.–14. July 1995, Volume 2.
Amsterdam: Elsevier 1995
Ziegler, J. & Burmester, M.: Besondere EDV-Eingabegeräte. In: H. Luczak &
W. Volpert (Hrsg.), Handbuch Arbeitswissenschaft (S. 567–572). Stuttgart:
Schäffer – Poeschel 1997.

302

■
■
■

5 Usability und Design

Autorenverzeichnis

Prof. Dr. Roland Schmitz (Herausgeber)
Prof. Schmitz studierte von 1986 bis 1991 Mathematik an der TU Braunschweig und war danach wissenschaftlicher Mitarbeiter am Institut für
Analysis der TU Braunschweig.
Nach der 1994 erfolgten Promotion zum Dr. rer. nat. ging er als
wissenschaftlicher Mitarbeiter an das Technologiezentrum der Deutschen Telekom in Darmstadt (heute ein Teil der T-Systems). Dort war
er zunächst in der Abteilung für Software-Engineering tätig und wechselte 1997 in die Abteilung Sicherheitskonzepte und Kryptologie, mit
den Hauptarbeitsgebieten Sicherheit mobiler Kommunikation sowie
Standardisierung digitaler Signaturen. Seit 2000 ist er Professor für
Internet – Security an der Hochschule für Druck und Medien in Stuttgart, wo er auch das Amt des Datenschutzbeauftragten wahrnimmt.
Im Februar 2007 wurde Prof. Schmitz zum Studiendekan des Studienbereichs Medieninformatik an der Hochschule der Medien gewählt.

Prof. Dr. Michael Burmester
studierte Psychologie an der Süddeutschen Universität Regensburg. Er
begann seine Karriere als Wissenschaftler am Fraunhofer-Institut für
Arbeitswirtschaft und Organisation (IAO) in Stuttgart. 1997 wechselte
er zu Siemens Corporate Technology als Usability Consultant und
Forscher für Usability Engineering. Ab März 2000 leitete er das
Münchner Büro ebenso wie den Bereich Usability Engineering der
User Interface Design GmbH, eines beratenden Software- und Usability-Unternehmens. Seit September 2002 hat Michael Burmester die
Professur für Ergonomie und Usability im Studiengang Informationsdesign an der Hochschule der Medien in Stuttgart übernommen und
leitet das Usability Labor der Hochschule der Medien. Neben der Arbeit als Usability Consultant war Herr Burmester in mehreren nationalen und europäischen Forschungsprojekten als Projektmanager

Autorenverzeichnis

■
■
■

303

beteiligt. Ergebnisse und Erfahrungen seiner Forschungsarbeit und
Arbeit als Usability Consultant sind in über 70 wissenschaftlichen
Veröffentlichungen dokumentiert. Seine Forschungsinteressen liegen
in der Weiterentwicklung des Usability Engineerings in Richtung auf
eine umfassende Gestaltungsdisziplin, die die Mensch-Technik- Interaktion zu einem für den Menschen positiven Erlebnis macht. Er ist
Mitglied der European Association for Cognitive Ergonomics (EACE),
Mitglied der Deutschen Gesellschaft für Informatik (GI), der Usability
Professionals Association (UPA) und der Association for Computing
Machinery (ACM).

Prof. Dr. Bernhard Eberhardt
studierte von 1984 bis 1991 Mathematik an der Eberhard-Karls-Universität in Tübingen und an der University of Massachusetts in Amherst. 1994 promovierte er an der Eberhard-Karls-Universität in Tübingen. Anschließend arbeitete er als Postdoc am WSI/GRIS an der
Universität Tübingen und am iMAGIS an der Université Joseph Fourier in Grenoble. Seit 2000 ist er Professor im Fachbereich Elektronische Medien an der Hochschule der Medien in Stuttgart. Seine Lehrund Forschungsgebiete sind Computeranimation und Medieninformatik.

Ansgar Gerlicher
Dipl.-Ing. (FH) Ansgar Gerlicher studierte Medieninformatik an der
Hochschule der Medien (HdM) in Stuttgart. Während und nach seinem Studium war er bei verschiedenen Firmen als Softwareentwickler,
Projektleiter und Lehrbeauftragter tätig.
Von 2002 bis 2005 war er Assistent und Doktorand im Studiengang
Medieninformatik an der HdM. Seit Oktober 2005 arbeitet er als Berater und Softwarearchitekt für die Automobilbranche. Ein Schwerpunkt seiner Arbeit und das Forschungsgebiet seiner Dissertation ist
die computerunterstützte Zusammenarbeit, engl. Computer Supported Cooperative Work (CSCW).

Prof. Dr. Martin Goik
Dr. Martin Goik studierte theoretische Physik an der Universität
Karlsruhe und promovierte am Institut für angewandte Informatik
am Forschungszentrum Karlsruhe im Bereich Mustererkennung. Im
Anschluss an eine mehrjährige Industrietätigkeit im Bereich ERP Sys-

304

■
■
■

Autorenverzeichnis

teme nahm er eine Professur an der Hochschule der Medien an. Zu
seinen Interessen zählt die Entwicklung von Applikationen zur Verarbeitung strukturierter Dokumente.

Prof. Dr. Jens-Uwe Hahn
studierte von 1989 bis 1995 Mathematik an der Eberhard-KarlsUniversität in Tübingen und an der Louisiana State University in Baton
Rouge. Anschließend arbeitete er als Wissenschaftlicher Mitarbeiter am
WSI/GRIS an der Universität Tübingen, wo er im Jahre 2000 im Bereich
Computergrafik promovierte. Nach mehrjähriger Industrietätigkeit ist
er seit 2004 Professor im Studiengang Medieninformatik an der Hochschule der Medien in Stuttgart. Seine Lehr- und Forschungsgebiete sind
Softwareentwicklung, Computergrafik und Virtual Reality.

Dipl.-Ing.(FH) Marko Hedler, MInfTech
Der gelernte Schriftsetzer Marko Hedler studierte von 1998 bis 2002
Medieninformatik an der Stuttgarter Hochschule der Medien (HdM).
An der Swinburne University in Melbourne, Australien, erwarb er im
Anschluss den Master of Information Technology. Nach seinem Studium war er als Assistent im Studiengang Medieninformatik sowie als
Berater und Projektingenieur im Bereich Satzherstellung und XMLLösungen tätig. Seit 2006 ist er Professurvertreter für Publishing und
Cross-Media-Systeme an der HdM. Seine Schwerpunkte liegen dabei
auf den Bereichen automatisierte Satzherstellung und XML-Technologien. Neben seiner Lehrtätigkeit promoviert Marko Hedler an der
Bergischen Universität Wuppertal im Bereich „XML-Sprachen“.

Prof. Dr.-Ing. Oliver Kretzschmar
Dr.-Ing. Oliver Kretzschmar studierte von 1983 bis 1990 an der Universität Stuttgart Maschinenbau mit den Schwerpunkten Steuerungstechnik und Angewandte Informatik. Danach arbeitete er als Stipendiat am Institut IKE der Universität Stuttgart und promovierte 1994.
Im Zeitraum von 1994 bis 2004 war Dr.-Ing. Oliver Kretzschmar als
Unternehmer in leitenden Positionen wie Vorstandsvorsitzender,
Produkt- und Projekt-Manager im Umfeld der Medien-Logistik und
des Content-Management tätig. Seit 2001 war Dr.-Ing. Oliver Kretzschmar als Lehrbeauftragter in der Medieninformatik engagiert. Seit
2004 lehrt Dr.-Ing. Oliver Kretzschmar als Professor an der Hochschule der Medien in Stuttgart im Studiengang Medieninformatik. Seine

Autorenverzeichnis

■
■
■

305

Lehr- und Forschungsgebiete sind Mediendatenbanken, MedienLogistik-Systeme sowie Content-, Produkt- und Dokumenten-Management-Systeme.
Email: kretzsch@hdm-stuttgart.de

Prof. Dr. Jörg Westbomke
Jörg Westbomke studierte von 1991 bis 1996 Informatik mit Nebenfach Betriebswirtschaftslehre an der Universität Dortmund. Nach
seinem Studium war er als wiss. Mitarbeiter am Lehrstuhl Informatik I
der Universität Dortmund in verschiedenen Projekten zu der Thematik „Digital Libraries“ tätig. Nach der Promotion im Bereich der XMLbasierten Implementierung strukturierter Hypermedia-Dokumente
wechselte er als stv. Bereichsleiter zu dem Forschungsinstitut für anwendungsorientierte Wissenverarbeitung nach Ulm. Seit 2003 hat er
die Professur “Werkzeuge für Inter-, Intranet und Multimedia“ im
Studiengang Informationsdesign der Hochschule der Medien inne.
Seine Schwerpunkte liegen im Bereich Internettechnologien, barrierefreies Webdesign, Datenbanken, XML und Multimedia.

306

■
■
■

Autorenverzeichnis

Index

3
3D-Maus 94

A
Abtastfehler 66
activity scenario 277
Ad-hoc-Workflows 225
AIIM (Association for Information
and Image Management) 209
Ajax 153
Ambientes Licht 54
Anaglyphen-Verfahren 87
Analysing 233
Anforderungen 251, 253–255, 257,
269, 272–274, 280, 284, 285, 287,
288, 294
Annodex
Continuous Media Web 154
Anschlußbedingungen 45
ANSI NCITS 354 287
AO (Allgemeine Abgabenordnung)
236
Application Sharing 155
Arbeitsmittel 247
Archivierung 234
Assets 199
Asynchrone Groupware 150
Asynchrone Systeme 143
AttrakDiff 2 285
Attraktivität 249, 254, 264–267
Aufgabe 247, 272
Aufgabenanalyse 274
Ausgabegeräte 91
Austauschformate 117

Autorensysteme 210
Autostereoskopische Displays 90
Awareness 144, 186
Awareness-Mechanismen 188

B
Backup 234
Barizentrische Koordinaten 47
Beleuchtungsgleichung 50
Beleuchtungsmodell 52
Benutzer 247, 257, 268
Benutzerfreundlichkeit 246
Benutzergruppen 272
Benutzerprofile 274
Benutzerzentrierte Gestaltung
250, 268, 288, 289
Benutzerzentrierter
Gestaltungsprozess 247, 269
Benutzungsschnittstelle 246, 253,
255, 258, 259, 268, 276, 278, 279,
281, 283, 285, 286, 292–295
Berechtigungskonzepte 240
Bernsteinpolynom 19
Bewußtheit Siehe Awareness
Beziehungsmodelle 222
Bézierkurve 19
Bézierpflaster 42
Bézierspline 27
Bézier-Tensorproduktfläche 42
Bidirektionale Reflexionsfunktion 51
Bilddatenbanken 209
Bildpaar 86
Bildschirmarbeitsplatz 245
Binäre Formatierung 200
BMEcat 237

Index

■
■
■

307

Branching 161
BRDF 51
Bridging the gap 276
B-Spline-Basisfunktionen 29
B-Splines 29
Bump-Mapping 63
Bündelung 206
Business Process Execution Language
(BPEL) 225
Business Process Modeling Language
(BPML) 225
Business-Process-ManagementSysteme (BPM) 211

C
CARD 279, 301
Card-Sorting 280, 302
Catmull-Rom-Spline 19
Cg 84
Change-Management 152
Channeling 233
Chat 157
Check-In-Vorgang 214
Check-Out-Vorgang 214
CI 217
CIELAB-Farbraum 218
Cocoon 229
Cognitive Walkthrough 284, 285, 302
COLD-Verfahren (Computer Output
to Laser Disk) 217
Collaboration 213
Collaborative Anaysis of
Requirements and Design Siehe
CARD
Collaborative Filtering 233
Common Industry Format for
Usability Test Reports 287
Composing-Objekte 223
Computer 245
Computer Supported Cooperative
Work
CSCW 143, 145, 146, 191
Computer-Supported-CooperativeLearning 153
concurrency control 170
Content 198
Content-Aggregation 226

308

■
■
■

Index

Content-based Filtering 233
Content-based-Image-Retrieval 221
Content-Broking 216
Content-Delivery 226
Content-Management-Systeme
(CMS) 210
Content-Personalisierung 232
Content-Publishing 227
Content-Related-Technologien 197
Content-Rendering 228
Content-Repository 217
Content-Rotation 240
Content-Strategie 205
Content-Syndication 216
Content-Templating 227
Contextual Design 274
Cooperation
Collaboration 146, 147
Copy-Merge 159, 170, 171
Credibility Siehe Glaubwürdigkeit
Cross-Media-Publishing 241

D
Daten 198
Datenhandschuh 94
Deadlock 173
De-Boor-Algorithmus 32
De-Boor-Punkte 31
De-Casteljau-Algorithmus 22
Dialogbaustein 276, 287, 295
Diffuse Reflexion 54
DIN EN ISO 13407 247, 253, 268, 269,
275, 288, 294
DIN EN ISO 14915 255
DIN EN ISO 14915 Teil 1-3 278
DIN EN ISO 9241 Teil 10 278
DIN EN ISO 9241 Teil 11 247
DIN EN ISO 9241 Teil 12 bis 17 278
DIN EN ISO 9241-11 249, 256,
264, 294
DIN EN ISO 9241-110 253
DIN ISO/IEC 12119 249
Direct3D 82
dirty-reads 175
dirty-writes 175
discount usability methods 286
Distribution 206

Divergenz 165–167, 179
Dokument 201
Dokumenten-Management-Systeme
(DMS) 210
Dokumenttyp-Definition 119
DublinCore 220
Dynamischer Content 230
Dynamisches Publishing 231

E
Ease of Learning 246
Ease of Use 246
ebXML (Electronic Business using
eXtensible Markup Language) 237
eCl@ss 238
ECM-Modell 211
E-Learning 156
Electronic Whiteboard 154
Elektromagnetisches Tracking 93
E-Mail 150
Enabling-Technologien 215
Enterprise-Content-ManagementSysteme (ECMS) 211
Entscheidungsfindung 158
Entwurf und Gestaltung 276
Entwurfsmuster 278, 279
ErgoNorm 285
Erlernbarkeit 246
ETIM 238
Evaluation 247, 258, 268, 270, 271,
275, 278, 283–287, 291, 293, 296,
298–302
Erfolgskriterien 286
formativ 284
Güte 285
summativ 284
Evaluationsmethoden 283–285, 291
Evaluationsziele 280, 282, 286
Expertenleitfäden 285
Expertise 263
Explizites Profilieren 232
Extreme Programming 290–292

F
Farben 52
Fehlerbewältigung 250

Fernnäherung 74
Fläche 38
Flat-Shading 57
Fokusgruppe 274
Footprint 66
Footprint Assembly 67
Formfaktor 72
Fragebögen 285
Fragmentierung von Content 219
Fragment-Prozessor 82
Fragment-Shader 83
Full-Winged-Edge 7

G
GDPdU (Grundsätze des Datenzugriffs und der Prüfbarkeit
digitaler Unterlagen) 236
Gebrauchstauglichkeit 246, 247
Definition 247
Geometrische Stetigkeit 11
Geschäftsprozess 203
Gestaltung als Prozess 269
Gestaltungswissen 278–280
Gewichte 37
Glaubwürdigkeit 263
Globale Beleuchtung 68
GLSL 84
GoBS (Grundsätze ordnungsmäßiger
DV-gestützter Buchführungssysteme) 236
Gouraud-Shading 58
GPU 81
Graderhöhung 23
Grafikprogrammierung 81
Groupware 143–150, 152–155, 170,
181, 188, 190, 191
Workgroup Computing 148
Gruppenbewusstsein
Awareness 147, 186
Gruppenkalender 154

H
Halbbild 86
Haptische Ausgabegeräte 92
HCI Siehe Human-Computer
Interaction

Index

■
■
■

309

Head Mounted Display 87, 91
Hemicube-Verfahren 74
Hermitekurve 17
Hermitepolynom 18
Hermite-Spline 18
Heuristische Evaluation 285
HGB (Handelsgesetzbuch) 236
Hierarchien 219
History-Buffer 179
HLSL 84
Homonym-Suche 221
Hornerschema 12
Human Computer Interaction 188
Hybrid-Architektur 184
Hypermedia 153
Hypertext 152

I
ICE-Standard (Information and
Content Exchange) 216
Identifizierung 232
Image-Mining 221
immediate restart 173
ImmersaDesk 92
Immersion 84
Implizites Profilieren 233
Industriestandard 278, 284
Infinity Wall 92
Infitec 88
Information 197
Information Scent 262, 294
Information-Architect 289
Information-Foraging-Theorie
260, 262
Kosten 261
Information-Scent 261
Informationsraum 261
Informationssuche 262
Inkludierung von Content 220
Intellectual-Property-Management
(IPM) 216
Intentionsverletzung 165, 167
Interaction Pattern 278, 279
Interaction-Designer 289
Interaktives System 258
Interpolation 13, 41
IPTC 220

310

■
■
■

Index

ISO/FDIS 20282-1 279
ISO/IEC 18035 279
ISO/IEC 18036 279, 297
ISO/IEC 25062 287
ISONORM10 285

J
JSR-170 (Java Specification Request
170) 219

K
Kantenorientierte Datenstrukturen
5
Katalog-Management-Systeme
210
Kausalitätsverletzung 165, 167
klassisches Radiosity 72
Knoten 13, 34
Knowledge-Management-Systeme
(KMS) 211
Kollaborative Betriebssysteme 159
Konfliktauflösung 170, 178
Konfliktprävention 170
Konsistenzerhaltung 161, 179
Kontext-Checklist 274
Kontextinterview 274
Kontextsitzung 274
Kontrollnetz 42
Kontrollpunkt 31, 33
Konvergenz Siehe Divergenz
Konvexe Hüllen-Eigenschaft 33
Krümmungsvektor 28

L
Lagrangekurve 16
Lagrangepolynom 16
Länge einer Kurve 10
Langzeitarchivierung 235
Layout 200
Layout vor Redaktion (Text) 214
Lichtquelle 53
Live-Specification 287
locking Siehe Sperrverfahren
Log-File-Analyse 285
Lokale Beleuchtungsmodelle 52

M

O

Magnetisches Tracking 93
Mapping 61
Matching 233
Media-Asset-Management-Systeme
(MAM) 209
Media-Mining 221
Medien 198
Mediendatei 198
Medien-Logistik-Systeme 210
medienneutrale Datenhaltung 218
medienneutraler Farbraum 218
Medienobjekte 198
Mehrbenutzer Editoren 143, 144,
146, 158, 162, 164, 168, 170, 178,
181, 184, 190
Mehrbenutzer Spiele
Multiplayer Games 158
Mehrfachverwertung 204
Mehrsprachigkeit 240
Merging 161
Meshing 79
Metadaten 198, 200, 220
Mipmap 67
Modalitäten 259
Modell der Attraktivität 267
Monombasis 12
Monome 9
Monte-Carlo-Radiosity 79
Multi-Channeling 241
Multimedia-Objekte 198
Multisite-Management 240
Multisynchrone Systeme 144

Oberflächenmodelle 2
Objektorientierter Entwurf
graphischer Benutzungsschnittstellen 276
OCR/ICR (Optical Character
Recognition und Intelligent
Character Recognition) 217
ODMA API (Open Document
Management API) 215
OpenGL 81
OpenTRANS 238
Operational Transformation
178–180, 184
opportunistische
Mehrfachverwertung 205
Optimistisches Sperren 174
Optisches Tracking 93
Ordnungssystem 201
Organisatorisches Umfeld 272

N
Nachbarschaftsinformationen 4
NCI 217
Nebenläufigkeitskontrolle 170, 171
Newsgroups 151
Normale 39
NURBS 36
Nutzungskontext 247, 260
Eigenschaften 272
Nutzungskontextanalyse 270, 271,
273–276, 283, 286, 288, 290
Nutzungsqualität 246

P
Painters Algorithmus 60
Papierprototyp 281
Parameterlinien 42
Parametrische Stetigkeit 10
Parametrisierte Fläche 39
Parametrisierte Kurven 9
Parser 119
Partizipatives Gestalten 279
PDF/A 235
Peer-to-Peer 156, 184, 185
P2P 157
Persuasive Aspekte 262
Pessimistisches Sperren 172
Pfad-Tracing 70
Phong’sches Beleuchtungsmodell
56
Phong-Shading 58
Photon-Tracing 70
Physikalisches Umfeld 272
PICTIVE 279, 299
Pixel-Shader 83
Plastic Interface for Collaborative
Technology Initiatives through
Video Exploration Siehe PICTIVE

Index

■
■
■

311

Pluralistic Usability Walkthrough 285
Polarisation 88
Polygonnetz 3
Portal-Systeme 210
PostFlight-Werkzeuge 215
Power Wall 92
preclaiming 173
PreFlight-Werkzeuge 215
Primärstrahl 69
Problem Scenario 274
Problemszenario 277
Produkt-Informations-Systeme 210
Profilierung 232
Progressive-Refinement 76
Prominence-Interpretation Theory
263
Prototyping 281
Taxonomie 281
Zielgerichtet 282
Punktlichtquelle 53
Push-to-Talk 158

Reflexion 54
Reflexions-Mapping 64
Regelbasierte Verfahren 233
Reguläre Fläche 38
Reguläre Kurve 10
Rendering-Formatierung 200
Reparametrisierung 10
Replizierte Architektur 183
Requirements-Management 152
Retrieval 220
Return of Investment 250
Revisionssichere Archivierung 235
Reziprozität 189
Richtungslichtquelle 54
RITE Siehe Rapid Iterative Test and
Evaluation
ROI Siehe Return of Investment
Rollbacks 174
RSS 153
Rule-based Filtering 233
RUP Siehe Rational Unified Process

Q

S

QOC 280
Qualität der Nutzung 246, 247, 254,
265, 268, 291
Querdisparation 85

Scenario Based Design 276
Scenario Machine 282
Scenario-Based Design 277, 301
Schattenstrahl 69
Schema-Definition 119
Screen-Design 279, 301
Seiten- und Blattplanung 240
serielle Äquivalenz 164
Severity Rating 287
Shader 82
Shading 57
Sharing 155, 161, 190
Shutterbrille 88
SIP 158
Software-Architektur 181
Software-Engineering 288–290,
297, 299
Source Code Control
SCC 162
Spekulare Reflexion 55
Sperrgranularität 176
Sperrverfahren 160, 161, 163,
164, 170, 171, 173–175, 177,
178, 182, 185

R
Radiosity 71
Radiosity-Gleichung 71
Randrepräsentierungen 2
Rapid Iterative Test and Evaluation
291
Rapid Prototype 282
Rational Unified Process
288, 290, 298
Rationale Kurven 35, 45
Raytracing 68, 75
Real-Time Collaborative Editing 163
Records-Management-Systeme
(RMS) 209
Redaktion (Text) vor Layout 214
redaktioneller Prozess 213
Redaktionssysteme 210
Referenzierung von Content 220

312

■
■
■

Index

Spezifikations- und Style-GuideRedakteur 289
Sphere-Map 65
Spiegelnde Reflexion 55
Spline 27
Split-Combine 159, 170, 171
Staging-Konzepte 231
starvation 175
static locking 173
Statischer Content 230
Statisches Publishing 231
Stereoskopie 85
Stetigkeit von Flächen 38
Storyboard 281
Struktur 198, 200
Stützstellen 13
Style-Guide 276, 287, 289
Suchfunktionen 220
Synchrone Groupware 154
Synchrone Systeme 143, 149
Synonym-Suche 221
Systemanalytiker 289
systematische Wiederverwendung
205

T
Tagging 161, 201
Taktile Geräte 92
Tangente 38
Tangentenvektor 28
Taxonomien 219
Taylorbasis 12
Technisches Umfeld 272
Telepointing 188
Teleporting 188
Tensorproduktfläche 38, 39, 46
Texturfilterung 66
Texturkoordinaten 62
Textur-Mapping 62
timestamp ordering Siehe
Zeitstempelordnungsverfahren
Total Cost of Ownership – TCO 208
Tracking 93
Translation-Memory-Systeme (TMS)
217
trustworthiness Siehe
Vertrauenswürdigkeit

Turn-Taking 159, 170, 171
two phase locking Siehe ZweiPhasen-Sperren

U
Ubiquitous Computing 188
Ultraschall-Tracker 93
Umgebung Siehe Nutzungskontext
Umgebungslicht 54
Umgebungs-Mapping 64
uncommited dependency 173
Unterhaltungselektronik 249
Usability 145, 147, 148, 153, 168,
188–190, 245, 246
Definition 247
Differenzierung 252
effektiv 247
Effizienz 248
Gesetze 253
Gesundheit 252
Innovationsfaktor 252
Internet 246
Kostenersparnis 251, 252
Kundenloyalität 252
Neue Kunden 251
Nutzen 249
Produktivität 252
Umsatz & Gewinne 251
Zeitersparnis 251
Zielorientierung 247
Zufriedenheit 252
Zufriedenstellung 248
Usability Evaluator 289
Usability-Engineering 250, 268, 269,
276, 288, 290–293, 295–297, 299,
301
Definition 253
Usability-Probleme 251, 271,
287, 291
Usability-Ziel 269–271, 275, 283, 286,
287, 291
Usage-Centred Software Lifecycle
290
Use Case Specifier 289
Usefullness 246
User Centred Design 268
User Interface Designer 289
Utility 246

Index

■
■
■

313

V
Validierung 215
Validierungsphase 174, 176
Varianten 223
Vector-Logical Clock 179
Verallgemeinerte Bernsteinpolynome
47
Verdeckung 59
Vergleichsbasiertes Verfahren 233
Versionen 222
Versionsverwaltungssysteme
146, 147, 159–162, 181
Vertexliste 4
Vertex-Prozessor 82
Vertex-Shader 83
Vertrauenswürdigkeit 263
Video Prototyp 282
Videokonferenzsysteme 156
Virtual Reality 84
VoIP 158
Volltextsuche 221

W
Wahrgenommene hedonische
Qualität – Evocation (HQ-E) 266
Wahrgenommene hedonische
Qualität – Identität (HQ-I) 266
Wahrgenommene hedonische
Qualität – Stimulation (HQ-S) 266
Wahrgenommene hedonische
Qualität (HQ) 265
Wahrgenommene pragmatische
Qualität (PQ) 265
wait depth limited 173
Wavelet-Radiosity 79
Web 2.0 153
Web Service 153
Web-Content-Management-Systeme
(WCMS) 210

314

■
■
■

Index

WebDAV 153, 162
WebDAV-Schnittstelle (Web-based
Distributed Authoring and
Versioning) 216
Weblogs 152
Wellenlängenmultiplex-Verfahren 88
Widgets 188
Wiki 152
Winged-Edge 5
Wissen 199
Wizard of Oz Prototyp 281
WML 228
Workflow 203
Workflow Management Coalition
(WfMC) 225
Workflow-Definition 224
Workflow-Enactment-Service 225
Workflow-Engine 225
Workflow-Management-Systeme
(WfMS) 203
Workflow-Modellierung 224
Workspace Awareness 186
WYSIWID 188
WYSIWIS 155

X
XHTML MP/CSS 228
XML-Publishing-Frameworks 229
XMP 220
XSL-FO 229
XSLT (Extensible Stylesheet Language
Transformation) 229

Z
z-Buffer 59
Zeitmultiplex-Verfahren 87
Zeitstempelordnungsverfahren 177
zentralisierte Architektur 181
Zwei-Phasen-Sperren 173