Diplomarbeit: Generische und dynamische Hypertexte (2001)

Implementierung eines Editors zur Erstellung
generischer und dynamischer Hypertexte
Diplomarbeit zur Erlangung des akademischen Grades Diplom-Ingenieur
in der Studienrichtung Informatik
Angefertigt am Institut für Technische Informatik und Telematik,
Abteilung Telekooperation
Von:
Mag. Arno Hütter
Betreuung:
o.Univ.-Prof. Dipl.-Ing. Dr. J. Volkert
Mitbetreuung:
Dipl.-Ing. T. Kopetzky
Linz, Juli 2001

Eidesstattliche Erklärung
„Ich erkläre an Eides Statt, daß ich die Diplomarbeit mit dem Titel 'Implementierung eines
Editors zur Erstellung generischer und dynamischer Hypertexte' selbständig und ohne
fremde Hilfe verfaßt, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und
alle den benutzten Quellen wörtlich oder sinngemäß entnommenen Stellen als solche kennt-
lich gemacht habe.“
Linz, den 30. Juli 2001 (Arno Hütter)

Zusammenfassung
Seit Vannevar Bush 1945 in seinem visionären Artikel "As we may think" mit der Idee eines
"Memex" eine Maschine beschrieb, welche gigantische Informationsmengen adäquat zu orga-
nisieren und damit den menschlichen Intellekt zu unterstützen suchte (und bereits alle wesent-
lichen Eigenschaften des heute gültigen Hypertext-Paradigmas enthielt), hat das anbrechende
Informationszeitalter tatsächlich sämtliche technische Voraussetzungen geschaffen, um diese
Idee umzusetzen und einer breiten Allgemeinheit zugänglich zu machen. Inwieweit der Hy-
pertext-Ansatz in der Zwischenzeit selbst konzeptionelle Weiterentwicklung erfahren hat, ist
jedoch kritisch zu hinterfragen.
Der im Zuge dieser Diplomarbeit entwickelte Hypertext-Editor geht auf einen Ansatz zur Er-
weiterung des Hypertext-Konzepts zurück, einen Formalismus namens "WebStyles", welcher
von Martin Richartz von der Universität Karlsruhe in seiner Dissertationsschrift (dort noch
unter dem Namen "PreScript") vorgelegt wurde. Das WebStyles Modell ermöglicht eine effi-
zientere Erstellung von Hypertexten durch Ableitung generischer Vorlagen und enthält dane-
ben ein regelbasiertes System zur Unterstützung des Benutzers bei Navigation durch den Hy-
pertext.
Der Editor wurde mit dem Ziel realisiert, dem Hypertext-Autor ein möglichst einfach zu
handhabendes Werkzeug zur Verfügung zu stellen, das dennoch die gesamte Mächtigkeit des
WebStyles-Ansatzes unterstützt. Eine Voraussetzung dafür ist eine intuitive graphische Be-
nutzeroberfläche, wobei der Hypertext in abstrakter Weise und losgelöst von etwaigen kon-
kreten Hypertext-Architekturen bearbeitet werden kann. Es werden unterschiedliche Export-
Formate unterstützt, als Referenzimplementierung wurden Java Servlets unter Verwendung
von HTML-Vorlagen gewählt.

Abstract
In 1945, Vannevar Bush described a machine called "Memex" in his visionary article "As we
may think". The Memex was able to organize an enormous amount of information in order to
encourage the human intellect. The concept included all essential properties of today's hyper-
text paradigms. Since then the information technology era has laid the basis to implement
these ideas and share them among a large community of individuals. But from a critical point
of view it is questionable whether the hypertext approach has conceptually improved from the
early days until present.
The hypertext editor implemented in this diploma thesis is based on an approach to enrich the
hypertext concept with a formalism called "WebStyles", introduced by Martin Richartz in his
doctoral thesis at the University of Karlsruhe (originally under the name "PreScript"). The
WebStyles model allows an efficient construction of hypertexts derived from generic tem-
plates and includes a controller-based system to support the user during navigation in the hy-
pertext.
The editor has been developed to provide the hypertext author with a tool that on the one hand
is simple to use and on the other hand contains all the power that the WebStyles approach
offers. An intuitive graphical user interface forms the preliminary for editing hypertext in an
abstract way, independent of any concrete hypertext architecture. Different export formats are
supported. Java Servlets and HTML-templates were chosen as a reference implementation.

Inhaltsverzeichnis
Inhaltsverzeichnis
1. Einleitung ___________________________________________1
1.1 Motivation _________________________________________________________1
1.2 Ausgangspunkt dieser Arbeit__________________________________________3
1.3 Gliederung _________________________________________________________4
2. Hypertext - Geschichte und gegenwärtige Systeme__________5
2.1 Begriffsbestimmung _________________________________________________5
2.2 Historischer Hintergrund _____________________________________________7
2.2.1 Vorgeschichte__________________________________________________7
2.2.2 Pionierarbeiten _________________________________________________8
2.2.2.1 Vannevar Bush: Memex __________________________________8
2.2.2.2 Douglas C. Engelbart: NLS/Augment_______________________11
2.2.2.3 Theodor Nelson: Xanadu_________________________________12
2.2.3 Hypertext im Zeitalter des Personal Computers ______________________15
2.2.3.1 HyperCard ____________________________________________16
2.2.3.2 NoteCards ____________________________________________17
2.2.3.3 Intermedia ____________________________________________18
2.2.3.4 Dexter Hypertext-Referenzmodell _________________________19
2.2.3.5 Digital LinkWorks______________________________________20
2.2.3.6 World Wide Web_______________________________________20
2.2.3.7 Hyper-G / HyperWave___________________________________25
2.2.3.8 Aktuelle Technologien und Werkzeuge _____________________27
2.2.3.9 Schlußfolgerungen______________________________________29
3. Das WebStyles Modell ________________________________31
3.1 Überblick _________________________________________________________31
3.2 Benutzerrollen _____________________________________________________32
3.3 Hypertext-Komponenten ____________________________________________32

Inhaltsverzeichnis
3.3.1 Hypertext-Objekt ______________________________________________33
3.3.2 Hypertext-Knoten______________________________________________33
3.3.3 Aggregat-Knoten ______________________________________________34
3.3.4 Hypertext-Link________________________________________________34
3.3.5 Hypertext-Anker_______________________________________________35
3.4 Generische Netze ___________________________________________________36
3.4.1 Generische Knoten_____________________________________________36
3.4.2 Generische Links ______________________________________________39
3.4.3 Stränge ______________________________________________________41
3.4.4 Hypertext-Konstruktion _________________________________________46
3.5 Navigationsmodell __________________________________________________48
3.6 Prozeduren________________________________________________________51
3.7 Zusammenfassung__________________________________________________53
4. Implementierung ____________________________________54
4.1 Wahl von Entwicklungssprache und -umgebung_________________________54
4.2 Systemarchitektur __________________________________________________55
4.2.1 Java Packages_________________________________________________58
4.3 Objektorientierte Entwurfsmuster ____________________________________59
4.3.1 Observer_____________________________________________________59
4.3.2 Singleton ____________________________________________________62
4.3.3 Model-View-Controller _________________________________________65
4.3.4 Memento ____________________________________________________67
4.4 Ausgewählte Implementierungsproblemstellungen _______________________68
4.4.1 Interaktive Bearbeitung des WebStyles-Graphen _____________________68
4.4.2 Vorschau-Ansicht in Dateidialogen ________________________________69
4.4.3 Hypertext-Dokumenteditor ______________________________________71
4.4.4 WebStyles-Laufzeitumgebung____________________________________73
5. Anwendung _________________________________________77
5.1 Graphische Benutzeroberfläche_______________________________________77

Inhaltsverzeichnis
5.1.1 Menü File ____________________________________________________78
5.1.2 Menü Edit____________________________________________________79
5.1.3 Menü View___________________________________________________79
5.1.4 Menü Tools __________________________________________________80
5.1.5 Symbolleiste__________________________________________________81
5.1.6 Knoten- und Link-Kontextmenüs _________________________________82
5.1.7 Knoten-Properties _____________________________________________83
5.1.7.1 Generischer Knoteninhalt ________________________________84
5.1.8 Hypertext-Dokumenteditor ______________________________________87
5.1.9 Link-Properties________________________________________________88
5.2 Beispiele für Hypertext-Entwürfe _____________________________________90
5.2.1 Konstruktionsbeispiel Firmenpräsentation___________________________90
5.2.2 Konstruktionsbeispiel Computer Based Training (CBT)________________93
6. Resümee und Ausblick_______________________________102
Quellenverzeichnis_____________________________________104

Abbildungsverzeichnis
Abbildung 1: Die Idee des Memex im Verständnis seiner Zeit________________________10
Abbildung 2: Historische Notizen von Theodor Nelson: Links zwischen Dateien_________13
Abbildung 3: Xanadu: Paralleles Bearbeiten mehrerer Dokumente, graphische Darstellung
von Links _________________________________________________________________14
Abbildung 4: Hypertext-Browser, Hypertext-Server und Hypertext-Gateway ____________22
Abbildung 5 : Generische Knotentypen und mögliche Ableitungen____________________37
Abbildung 6: Generische Linktypen und mögliche Ableitungen ______________________40
Abbildung 7: Markierungen des Strang-Algorithmus _______________________________42
Abbildung 8: Mehrfachinstantiierung von Sequenzknoten ___________________________43
Abbildung 9: Mehrfachinstantiierung von Fächerlinks______________________________44
Abbildung 10: Zusammenführung von Strängen über einen Fächerlink_________________45
Abbildung 11: Beispiel für eine Strang-Instantiierung ______________________________46
Abbildung 12: Klassendiagramm (Ausschnitt) ____________________________________56
Abbildung 13: Java-Packages des WebStyles-Editors ______________________________58
Abbildung 14: Das Observer-Entwurfsmuster ____________________________________60
Abbildung 15: Das Model-View-Controller Schema _______________________________65
Abbildung 16: Dateidialog mit Vorschau-Ansicht _________________________________69
Abbildung 17: Graphische Benutzeroberfläche des WebStyles-Editors _________________77
Abbildung 18: Das Menü File _________________________________________________78
Abbildung 19: Das Menü Edit_________________________________________________79
Abbildung 20: Das Menü View________________________________________________79
Abbildung 21: Das Menü Tools _______________________________________________80
Abbildung 22: Symbolleiste __________________________________________________81
Abbildung 23: Knoten-Kontextmenü ___________________________________________82
Abbildung 24: Link-Kontextmenü _____________________________________________82
Abbildung 25: Knoten-Properties ______________________________________________83
Abbildung 26: Generischer Knoteninhalt ________________________________________85
Abbildung 27: Der Hypertext-Dokumenteditor____________________________________87
Abbildung 28: Link-Properties ________________________________________________88

Abbildung 29: Hypertext-Konstruktion Firmenpräsentation (Schritt 1) _________________90
Abbildung 31: Definition von Inhaltsschablonen __________________________________92
Abbildung 33: Hypertext-Konstruktion CBT (Schritt 1)_____________________________94
Abbildung 37: Definition von Navigationsregeln __________________________________98
Abbildung 38: Festlegung von Links im Hypertext-Dokumenteditor___________________99
Abbildung 39: Kontextabhängige Sichtweise des Knoteninhalts (1) __________________100
Abbildung 40: Kontextabhängige Sichtweise des Knoteninhalts (2) __________________101

Einleitung 1
1. Einleitung
1.1 Motivation
Das World Wide Web (WWW) ist zwar das mit Abstand meistgenutzte Hypertext-System -
und damit ein De-facto-Standard - aber bei weitem nicht das ausgereifteste. Die Ansprüche an
moderne Hypertexte können von den dem WWW zugrundeliegenden Bausteinen Hypertext
Markup Language (HTML) und Universal Resource Locator (URL) alleine nicht erfüllt
werden. Einige über die bestehenden Konzepte hinausgehende Forderungen sind von besonde-
rer Bedeutung: [TRTJ97]
Bei der Erstellung von Hypertexten
• Umfassende Styleguides (Entwurfsrichtlinien) für die Konstruktion von Hypertexten
• Mächtigere Entwicklungs- und Beschreibungssprachen (über aktuelle Ansätze wie JavaSc-
ript oder Cascading Style Sheets hinausgehend)
• Autoren-Werkzeuge, deren Einsatz tatsächliche Effizienzsteigerungen mit sich bringt
• Systematische Testmethoden
Bei der Verwendung von Hypertexten
• Navigationsunterstützung für den Benutzer (Stichwort: "Lost in Hyperspace")
• Verknüpfungshilfen
• Integrierte Suchfunktionen
• Informationsrepräsentierung durch den Hypertext in Form eines semantischen Netzwerks

Einleitung 2
Vor der Globalisierung des Hypertexts durch das WWW wurden Hypertext-Dokumente all-
gemein als eine in sich geschlossene Menge von Knoten und Links aufgefaßt (so bedeutet
auch der Begriff "Website" nicht nur den physischen Standort, sondern eine Menge von mit-
einander in Beziehung stehenden Links und Knoten). Unter HTML sind Links jedoch darauf
beschränkt, von einem Dokument bzw. Dokumentabschnitt zum nächsten zu führen. Das
World Wide Web kann - kritisch betrachtet - als eine Sammlung von lose verknüpften Sub-
netzen (in der Folge als "Hypertexte" bezeichnet) gesehen werden.
Es gab bisher kaum Anstrengungen, das Potential einer einheitlichen Strukturierung und Typi-
sierung von Hypertexten zu nutzen - es fehlen auch die dazu nötigen Standards. Bemühungen,
Aufbau und Funktionalität von HTML-Hypertexten zu verbessern, beschränkten sich bisher
hauptsächlich auf die Einführung neuer Typen von HTML-Tags (Marken) und einige enga-
gierte Ansätze wie RDF (Resource Description Framework, dient der Beschreibung und dem
Austausch von Metadaten). Die Wiederverwendung und Aufbereitung von Inhalten kann
durch geeignete serverbasierte Ansätze (Content Management Systeme, Datenbank/Web-
Gateways, etc.) verbessert werden. Eines der Hauptprobleme des WWW liegt jedoch weiter-
hin in der mangelnden Struktur, was neben der fehlenden konzeptuellen Unterstützung auch
auf die manuelle Erstellung und Wartung von HTML-Dokumenten zurückzuführen ist. Viele
Web Authoring Werkzeuge sind im Grunde Textverarbeitungsprogramme, die um das Kon-
zept des Universal Resource Locator erweitert wurden [MHK98]. Erst in letzter Zeit finden
auch vermehrt umfassendere Site-Management Tools Verwendung.
Unter HTML gibt es bereits eine primitive Form der Typisierung, indem Knoteninhalten Me-
dientypen und Dateiformate zugeordnet werden können. Auch Attributierung, wie sie im Fall
von HTML durch das sogenannte Meta-Tag erreicht wird, kann als eine Art von Typkonzept
betrachtet werden. Fortgeschrittenere Systeme unterstützen einen objektorientierten Ansatz
durch die Spezifikation von Methoden auf Objekttypen. In offenen Hypertextsystemen sind
Ankertypen von besonderer Bedeutung, da dadurch die Integration von Anwendungen (E-
Mail, Kalender, etc.) bewerkstelligt werden kann. Typisierung ermöglicht die Klassifizierung
und Indizierung der Hypertext-Elemente und eine nahtlose und konsistente Integration in ei-
nen größeren Kontext.

Einleitung 3
Auf Hypertextebene müssen Knoten- und Linktypen zu einer aussagekräftigen Gesamtstruktur
zusammengefügt werden. Ein einfacher Ansatz zur Lösung dieses Problems wäre eine Klassi-
fikation von Tupeln in der Form Knoten-Link-Knoten. Die Anforderungen an moderne Hyper-
text-Systeme gehen jedoch darüber hinaus: Hypertext-Typen sollten einen Bauplan für korres-
pondierende konkrete Hypertexte repräsentieren.
Die Vorteile eines solchen Konzepts sind vielfältig. Wann immer Wissen in einen Hypertext-
Typ einfließt, kann dieses Know-How bei jeder folgenden Konstruktion wiederverwendet
werden. Dies führt zu konsistenten Hypertext-Strukturen, da die Ersteller gewissen Vorgaben
folgen müssen. Neue Hypertext-Netze können durch komponentenweises Zusammenfügen
existierender Netze entstehen. Ein solches Modell erlaubt die Entfaltung eines gemeinsamen
"Look & Feels" von Hypertexten innerhalb einer Organisation. Der dadurch gewonnene Wie-
dererkennungseffekt reduziert den kognitiven Overhead beim Benutzer. Indizierung und
Suchstrategien werden verbessert, da darin nun Struktur- und Inhaltsaspekte einfließen. Ganze
Anwendungen können auf Basis der Kenntnis des Hypertext-Typs entstehen, etwa lernende
Systeme, die ausgehend von Strategievorschriften benutzerspezifische Navigationsmuster
unterstützen. [MHK98]
Bei der Erweiterung bestehender Hypertext-Paradigmen ist aber auch Vorsicht geboten. Denn
die Idee des Hypertexts lebt von ihrer konzeptionellen Schlichtheit. Sie stellt einen Mecha-
nismus dar, in dem der Informationsmodellierung praktisch keine Grenze gesetzt sind, und
den auch Computer-Laien in kürzester Zeit erlernen können.
1.2 Ausgangspunkt dieser Arbeit
1995 veröffentlichte Martin Richartz an der Universität Karlsruhe seine Dissertation über ein
erweitertes Hypertext-Konzept namens "PreScript". PreScript geht auf ein gemeinsames For-
schungsprojekt mit der Firma Digital Equipment zurück, in dem Hypertexte zur Informati-
onsmodellierung im computergestützten Unterricht eingesetzt wurden.

Einleitung 4
PreScript enthält Strukturierungs- und Orientierungshilfen für Autoren und Benutzer von Hy-
pertexten durch
• ein Konstruktionsprinzip für Hypertexte durch Ableitung von Hypertexttypen,
• ein regelbasiertes System zur Unterstützung bei der Navigation durch den Hypertext, und
• ein prozedurales Paradigma durch einen Scripting-Ansatz.
Das Projekt wurde an der Abteilung für Telekooperation der Universität Linz unter dem Titel
"WebStyles" weitergeführt, und resultierte schließlich in der konkreten Implementierung im
Rahmen dieser Arbeit.
1.3 Gliederung
Kapitel 2 beschäftigt sich mit den Ursprüngen und der Geschichte von Hypertext, und unter-
zieht bestehende Hypertext-Modelle einer kritischen Betrachtung. In Kapitel 3 wird der
WebStyles-Ansatz in einem für das Verständnis dieser Arbeit adäquaten Detaillierungsgrad
erläutert. Das darauffolgende Kapitel skizziert die bei der Implementierung des WebStyles-
Editors eingesetzten Softwaretechniken. Kapitel 5 beschreibt die Anwendung des Editors an-
hand einiger konkreter Beispiele. In Kapitel 6 werden die gewonnenen Erkenntnisse zusam-
mengefaßt, und die Arbeit mit einem kurzen Ausblick abgeschlossen.

Hypertext - Geschichte und gegenwärtige Systeme 5
2. Hypertext - Geschichte und gegenwärtige Systeme
2.1 Begriffsbestimmung
Der Versuch, eine allgemein akzeptierte Definition des Begriffs des Hypertexts zu finden,
gestaltet sich schwierig. Es lassen sich jedoch zwei Kategorien von Beschreibungsansätzen
identifizieren, nämlich jene, die typischerweise in populärwissenschaftlichen Medien oder
Marketingschriften verwendet werden, und jene der technisch-wissenschaftlichen Literatur
[Bardini97].
Folgende Auslegungen sind der ersten Gruppe zuzuordnen:
• Hypertexte funktionieren eher über Assoziation als Indizierung.
• Hypertexte sind ein Format für die nicht-sequentielle Darstellung von Ideen.
• Hypertexte sind die Aufhebung des traditionellen, linearen Ansatzes der Informationsdar-
stellung und -verarbeitung.
• Der Inhalt von Hypertexten ist nicht an Strukturen oder Organisationen gebunden.
Wissenschaftliche Definitionsansätze sind:
• Hypertext ist ein Ansatz zur Erstellung von Systemen zur Repräsentation und zum Mana-
gement von Informationen über ein Netzwerk von Knoten, die durch typisierte Links mit-
einander verbunden sind. [Halasz88]
• Hypertext ist ein elektronisches Dokument, ein Ansatz des Informationsmanagements,
wobei Daten in einem Netz von Knoten und Links abgelegt werden. Ein Hypertext kann

durch interaktive Browser betrachtet, und durch Struktureditoren manipuliert werden.
[SM88]
• Hypertext stellt eine Technik zur Organisation von textuellen Informationen auf eine kom-
plexe, nicht-lineare Weise und zur raschen, explorativen Zugänglichmachung von großen
Wissensbasen zur Verfügung. [WS88]
Konzeptuell kann ein Hypertext als ein gerichteter Graph betrachtet werden, wobei jeder Kno-
ten ein Textstück darstellt, und die Kanten des Graphen miteinander in Beziehung stehende
Textstücke verbinden. Dem Benutzer wird eine Schnittstelle angeboten, über welche Text
betrachtet und Links überquert werden können, wenn neue Interessensbereiche in den Vorder-
grund rücken
Die Wortschöpfung "Hypertext" geht auf Theodor H. Nelson zurück. Für Nelson war Hyper-
text ursprünglich ein für seine Arbeit als Autor gedachtes Werkzeug, das er wie folgt be-
schrieb:
"[A tool that] allows you to see alternative versions on the same screen on
parallel windows and mark side by side what the differences are. Not by scan-
ning but by analysis of data structure. Now the system I started designing in
the 1960s, allows you, would have allowed you, will allow you to see connec-
tions between the contents of different windows, like rubber bands between the
middles of the windows" [Bardini97]
Geprägt wurde der Begriff auch von der Bedeutung des Worts "hyper" in der Mathematik, wo
es oftmals als Synonym für "erweitert" und "verallgemeinert" verwendet wird.
Die Abkehr von der traditionellen Linearität war für Nelson eines der wichtigsten Merkmale
von Hypertexten - er sprach selbst nannte sie auch eine Form des "Non-Sequential Writings".
Nelson sah darin die Automatisierung von in der gedruckten Literatur üblichen Querverwei-

sen, mit dem Unterschied, daß diese nunmehr zum Hauptstrukturmerkmal von Texten wur-
den.
In einem Hypertext werden Informationen eines engeren Sinnzusammenhangs zu überschau-
bare Einheiten aufgesplittet, die als Knoten bezeichnet werden. Diese Informationseinheiten
können durch Links erreicht werden. Links sind gerichtete Verweise zwischen den Knoten,
und stellen den strukturellen Teil der Information dar.
Ein Link kann zu vertiefenden, übergeordneten oder verwandten Informationen führen. Diese
Allgemeinheit ist es auch, die beim praktischen Einsatz des Hypertextkonzepts Probleme ver-
ursacht.
Als Anker bezeichnet man den Zielpunkt eines Links. Dieser Zielpunkt muß nicht notwendi-
gerweise immer ein ganzer Knoten sein, vielmehr kann auch eine Teilmenge des Knotenin-
halts als Anker fungieren.
2.2 Historischer Hintergrund
2.2.1 Vorgeschichte
Bemühungen, Wissen zu sammeln und in einer für den Menschen geeigneter Form zugänglich
zu machen, gibt es schon lange, ebenso wie die Tradition des Einsatzes technischer Hilfsmittel
zu diesem Zweck.
Die geschichtlichen Wurzeln des Hypertext-Konzepts liegen in einem für die Informatik prä-
historischen Zeitalter. Im Mittelalter wurde das stetig wachsende Wissen der Menschheit
hauptsächlich in klösterlichen Bibliotheken verwaltet. Während der Renaissance konstruierten
Mönche ein Gerät, welches aus einem Räderwerk bestand, auf dem mehrere Bücher befestigt

wurden. Somit war es möglich, beim Lesen schnell zwischen verschiedenen Werken hin- und
herzuspringen. Nicht umsonst bedeutet der Begriff "Enzyklopädie" wörtlich übersetzt "Rad
des Lernens".
2.2.2 Pionierarbeiten
2.2.2.1 Vannevar Bush: Memex
Vannevar Bush war während des Zweiten Weltkriegs Präsident des Massachusetts Institute for
Technology (MIT) in Cambridge und einer der hochrangigsten Militärberater der US-
Regierung. Als das Ende des Krieges absehbar war, veröffentlichte er 1945 den visionären
Artikel "As We May Think", in dem er die Idee eines "Memex" (Memory Extenders) be-
schrieb, das den Menschen bei sich wiederholenden Denkvorgängen unterstützen sollte.
Bushs akademisches Hauptinteresse galt dem Gebiet der wissenschaftlichen Kommunikation.
Seine Sorge war, daß die stetig wachsende Menge an wissenschaftlicher Literatur nicht mehr
richtig genutzt werden könnte.
"The real heart of the matter of selection, however, goes deeper than a lag in
the adoption of mechanisms by libraries, or a lack of development of devices
for their use. Our ineptitude in getting at the record is largely caused by the ar-
tificiality of systems of indexing. When data of any sort are placed in storage,
they are filed alphabetically or numerically, and information is found (when it
is) by tracing it down from subclass to subclass. It can be in only one place,
unless duplicates are used; one has to have rules as to which path will locate
it, and the rules are cumbersome. Having found one item, moreover, one has to
emerge from the system and re-enter on a new path. The human mind does not
work that way. It operates by association. With one item in its grasp, it snaps
instantly to the next that is suggested by the association of thoughts, in accor-
dance with some intricate web of trails carried by the cells of the brain. It has

other characteristics, of course; trails that are not frequently followed are
prone to fade, items are not fully permanent, memory is transitory. Yet the
speed of action, the intricacy of trails, the detail of mental pictures, is awe-
inspiring beyond all else in nature." [Bush45]
Bush kritisierte, daß die meisten existierenden Indexmöglichkeiten auf hierarchischen, alpha-
betischen oder numerischen Strukturen basierten. Diese Strukturen wären aber nicht auf spezi-
fische menschliche Fähigkeiten zugeschnitten, wie etwa jene, Assoziationen zu knüpfen. Nach
Bush's Auffassung benötigte man anstelle der traditionellen Lagerungs- und Indizierungsme-
thoden der Bibliotheken ein natürlicheres System, welches eher der Funktionsweise des
menschlichen Gehirns entsprechen sollte. Das Memex war ein solches fiktives System, um
große Mengen von Informationen zu verwalten. Eine der Ideen dahinter bestand in der Nut-
zung von „Natural human principles“ für die Ablage und das Wiederfinden von Dokumen-
ten. In seinem Manuskript bezeichnete Bush dieses Prinzip als "Selection by association".
Das Memex selbst beschrieb Bush wie folgt:
"Consider a future device for individual use, which is a sort of mechanized
private file and library. It needs a name, and, to coin one at random, 'memex'
will do. A memex is a device in which an individual stores all his books, re-
cords, and communications, and which is mechanized so that it may be con-
sulted with exceeding speed and flexibility. It is an enlarged intimate supple-
ment to his memory.
It consists of a desk, and while it can presumably be operated from a distance,
it is primarily the piece of furniture at which he works. On the top are slanting
translucent screens, on which material can be projected for convenient read-
ing. There is a keyboard, and sets of buttons and levers. Otherwise it looks like
an ordinary desk.

In one end is the stored material. The matter of bulk is well taken care of by
improved microfilm. Only a small part of the interior of the memex is devoted
to storage, the rest to mechanism. Yet if the user inserted 5000 pages of mate-
rial a day it would take him hundreds of years to fill the repository, so he can
be profligate and enter material freely." [Bush45]
Abbildung 1: Die Idee des Memex im Verständnis seiner Zeit [HT98]
Die Idee des Memex basiert auf den damals aktuellen Technologien der Feinmechanik und der
Mikrophotographie. Wesentlicher als dieser Umstand ist jedoch, daß das Memex in einem

direkten Schritt assoziative Verknüpfungen erlaubt, indem aus einem Dokument heraus ohne
Verzögerung ein anderes ausgewählt werden kann. Der Benutzer kann diese Verbindungen
herstellen, indem er sie mit einem Namen versieht und in ein Codebuch einträgt. Über eine
Tastatur wird die Verknüpfung bestätigt und besteht von da an dauerhaft.
Wird später eines der beiden verknüpften Dokumente erneut aufgerufen, kann direkt über ei-
nen Tastendruck auf das andere zugegriffen werden. Ganze Listen von verketteten Dokumen-
ten können in beliebiger Geschwindigkeit durchgesehen werden, und ergeben in ihrer Ge-
samtheit wiederum neue Dokument. Das Memex erlaubt auch das Einfügen persönlicher No-
tizen, und verfügt damit über alle wesentlichen Eigenschaften, die der heutige Hypertext-
Ansatz vorsieht. Einen Versuch, das von Vannevar Bush beschriebene System zur Unterstüt-
zung des menschlichen Intellekts zu verwirklichen, hat es jedoch nie gegeben. Es hat aller-
dings allein durch seine Konzeption die Entwicklung vieler späterer Hypertextsysteme maß-
geblich beeinflußt.
2.2.2.2 Douglas C. Engelbart: NLS/Augment
Inspiriert von Vannevar Bushs Artikel begann Douglas C. Engelbart Anfang der fünfziger
Jahre eine bis heute andauernde Arbeit an der Vision eines "Conceptual Framework for the
Augmentation of Man’s Intellect". Am Stanford Research Institute in Palo Alto, Kalifornien
entwickelte er später das System NLS/Augment. Es enthielt bereits eine Vielzahl von Elemen-
ten, die heute ganz selbstverständlich auf modernen Arbeitsplatzrechnern eingesetzt werden.
Dokumente und Informationen wurden in drei Bereichen, die mit unterschiedlichen Zugriffs-
arten versehen waren, abgelegt: einem Bereich für Wegwerfnachrichten, Briefe und Notizen,
einem weiteren für gemeinsam benutzte Dokumente, und einem dritten Bereich für eingefro-
rene, bibliotheksähnliche Dokumente. Zwischen den Dokumente und über die Grenzen der
einzelnen Bereiche hinaus bestanden Querverweise. Jeder Benutzer verfügte über einen per-
sönlichen Arbeitsplatz, von dem aus er auf die Dokumente zugreifen und sie parallel mit an-
deren Benutzern betrachten konnte.

Engelbart wird berechtigterweise als geistiger Vater des Personal Computers und von Compu-
ter Supported Cooperative Work (CSCW) bezeichnet. Von ihm stammt u.a. die erste Imple-
mentierung eines Fenstersystems, er erfand die Maus als Eingabegerät, in seinem System gab
es erstmals elektronische Post, Textverarbeitung und die integrierte Darstellung von Grafiken.
Vieles was nicht von ihm selbst stammt, wurde von seinen ehemaligen Mitarbeitern später am
XEROX Palo Alto Research Center entwickelt [Richartz95].
2.2.2.3 Theodor Nelson: Xanadu
Theodor H. Nelson begann Mitte der sechziger Jahre Beiträge zu seiner Vorstellung eines
Hypertexts zu veröffentlichen. Eine wegweisende Arbeit aus dem Jahr 1965 trug den Titel
"The Hypertext". Weiters beschäftigte sich Nelson mit der verteilten Speicherung großer Da-
tenmengen, und mit durch den verbreiteten Computereinsatz entstehenden Liberalisierungsef-
fekten.
Nelsons Ansätze zum Thema Hypertext sind die ambitioniertesten der drei Pioniere, und des-
halb wohl auch am schwersten umzusetzen. Das von Nelson initiierte Xanadu Projekt steht für
ein Netzwerk eines weltumspannenden elektronischen Docuverse (Dokumenten-Universum),
in dem alle Dokumente publiziert werden. Ähnlich wie unter NLS/Augment gibt es persönli-
che und öffentliche Dokumentenbereiche, ebenso wie persönliche und öffentliche Links.
Links sind gerichtet, aber immer von beiden Seiten aus sichtbar und verfolgbar.
"A link is simply a connection between parts of text or other material. It is put
in by a human. Links are made by individuals as pathways for the reader's ex-
ploration; thus they are part of the actual document, part of a writing." [Nel-
son99]

Abbildung 2: Historische Notizen von Theodor Nelson: Links zwischen Dateien [Maurer01]
Später entwickelte Nelson Links zu sogenannten Transclusions weiter. Transclusions erlauben
es, Dokumente oder Teile von Dokumenten in andere Dokumente einzubetten, ohne sie zu
kopieren. Dies vermeidet redundante Speicherung und garantiert, dass die eingebetteten Do-
kumente immer auf aktuellem Stand sind. Das Prinzip der Transclusions entspricht in etwa
eingebetteten Dokumenten in modernen Textverarbeitungssystemen.

Abbildung 3: Xanadu: Paralleles Bearbeiten mehrerer Dokumente, graphische Darstellung
von Links [Nelson99]
Xanadu ist bisher nur in Teilbereichen realisiert. Durch den Siegeszug des World Wide Web
gerieten Nelsons Arbeiten etwas in Vergessenheit, dennoch verfolgt er mit unverminderter
Vehemenz die Verwirklichung seiner Idee weiter. Einer eventuellen Zusammenführung von
Xanadu und World Wide Web steht Nelson kritisch gegenüber:
"The World Wide Web was not what we were working toward, it was what we
were trying to 'prevent'. The Web displaced our principled model with some-
thing far more raw, chaotic and short-sighted. Its one-way breaking links glo-
rified and fetishized as 'websites' those very hierarchical directories from

which we sought to free users, and discarded the ideas of stable publishing,
annotation, two-way connection and trackable change." [Nelson99]
2.2.3 Hypertext im Zeitalter des Personal Computers
In den siebziger Jahren beschäftigten sich nur sehr wenige Arbeiten mit Hypertext. Erwäh-
nenswert sind das auf Andries van Dams zurückgehende Projekt FRESS (File Retrieval and
Editing), ein im Lehrbetrieb eingesetztes Hypertextsystem, mit dem Studenten in einer verteil-
ten Umgebung Texte am Bildschirm studieren und mit Kommentaren versehen konnten. Die
Bedienung war allerdings relativ umständlich und ausschließlich textbasiert. Ein Prototyp von
FRESS wurde später an die NASA verkauft, und dort tatsächlich für die Dokumentation der
Apollo-Raumfahrtmissionen eingesetzt.
ZOG war ein Hypertext-System, in dem erstmals Menüs eingesetzt wurden, um Links mit
schneller Antwortzeit zu verfolgen und weitere Dokumente abzurufen. 1980 wurde es an Bord
eines amerikanischen Flugzeugträgers auf 28 Workstations installiert, wo es zu Dokumentati-
onszwecken, als Wartungshandbuch und als Schnittstelle zu einem Expertensystem für die
Einsatzplanung von Flugzeugen verwendet wurde.
Das Jahr 1987 bedeutete den Durchbruch von Hypertext in Wissenschaft und Forschung. Jeff
Conklin veröffentlichte den Artikel "Hypertext: An Introduction and Survey" [Conklin87]. Er
gab darin einen Überblick über alle wesentlichen, bis dahin in der Forschung entstandenen
Systeme, und wies auch auf Probleme beim Hypertext-Einsatz hin. Conklin prägte auch den
Term des "Getting lost in hyperspace" - so bezeichnete er das Problem der Desorientierung
beim Navigieren durch den Hypertext, und identifizierte damit den kognitiven Mehraufwand
der entsteht, wenn verschiedene Aufgaben bzw. Wege durch den Hypertext gleichzeitig zu
bewältigen sind. [Richartz95]

Ein weiterer wichtiger Meilenstein war eine erstmals im November 1987 auf Initiative der
ACM (Association for Computing Machinery) an der Universität von North Carolina abgehal-
tene Konferenz namens "Hypertext ’87". Diese sollte alle wesentlichen Forschungsanstren-
gungen in diesem Bereich zusammenführen, und aus den Kleinprojekten einiger Forscher und
Utopisten ein weitverbreitetes populäres Thema machen. Praktisch alle namhaften Wissen-
schafter dieses Gebiets waren anwesend, die Hälfte aller potentiell interessierten Teilnehmer
mußte aus Platzmangel abgewiesen werden. Diese Hypertext-Konferenz findet seither alle
zwei Jahre statt. [Nielsen95]
2.2.3.1 HyperCard
Das erste wirklich populäre Hypertext-System ist das auf Bill Atkinson zurückgehende Hy-
perCard. HyperCard wurde 1987 von Apple für seine Macintosh-Rechner vorgestellt und kos-
tenlos mit den Rechnern ausgeliefert. Dies war vermutlich auch der entscheidende Grund für
dessen hohe Popularität. Ein simples Benutzerinterface gestattete es, auf relativ einfache Wei-
se multimediale Präsentationen zu gestalten. Die Informationen wurden als Stapel von elekt-
ronischen Karten organisiert. Das System enthielt eine einfach zu erlernende, nicht allzu kom-
plexe Programmiersprache (Hypertalk), die es zu einem universellen System machte. Es man-
gelte allerdings an ausgereiften Strukturierungswerkzeugen zur Unterstützung der Hypertext-
Autoren, so daß sich HyperCard kaum für komplexe Anwendungen anbot, sondern eher für
kleine Informationssysteme, zum Prototyping und Experimentieren [Weinreich97].

2.2.3.2 NoteCards
NoteCards wurde am XEROX Palo Alto Research Center entwickelt, und auf einem Xerox
Lisp-System realisiert. Ziel war es, Autoren und Wissenschafter dabei zu unterstützen, zu-
nächst unstrukturierte Gedanken und Ideen zu ordnen. NoteCards besteht aus den Komponen-
ten NoteCards, Links, Browser und Fileboxes.
Eine NoteCard ist das elektronische Pendant einer Karteikarte, und mit ähnlichen Einschrän-
kung behaftet: ihr Inhalt wird durch die Größe ihrer Bildschirmdarstellung begrenzt.
Quell- und Zielkarten werden über unidirektionale Links miteinander verbunden. Links sind
an der Quellkarte durch ein Symbol gekennzeichnet, durch das Anklicken wird die Zielkarte
auf den Bildschirm gebracht. Benutzer können Links mit einem Etikett versehen, das den Typ
des Links zeigt.
Browser bieten eine graphische Darstellung eines NoteCard-Netzes durch Knoten und Kanten
an, und können für die Navigation verwendet werden. Die Diagramme werden automatisch
durch das System erstellt. Fileboxes sind selbst wiederum NoteCards, die der Organisation
von Kartenkollektionen dienen. Auch eine einfache Suchmöglichkeit nach Karteninhalten ist
vorgesehen.
NoteCards ist voll in die XEROX Lisp Programmierumgebung eingebettet, und verfügt damit
über eine umfangreiche Funktionsschnittstelle. Dieser ermöglicht die Erstellung neuer Karten-
typen, die Manipulation von Hypertext-Netzen und die Integration anderer Lisp-Programme.

2.2.3.3 Intermedia
Intermedia wurde zwischen 1984 und 1992 an der Brown University entwickelt, und stellt
eines der umfassendsten Projekte der frühen Hypertext-Phase der achtziger Jahre dar. Es ori-
entiert sich an der damaligen Software-Architektur der Macintosh-Computer, ist objektorien-
tiert aufgebaut und trennt strikt zwischen Struktur und Inhalten.
Inhalte werden als Dokumente im Dateisystem des zugrundeliegenden Betriebssystems abge-
legt. Da Intermedia als Hypermedia-System konzipiert ist, können Texte, Zeichnungen, Bil-
dern, Zeitachsen und 3D-Modelle als Knoteninhalte erstellt werden.
Die Navigation wird durch eine graphische Darstellung der Hypertext-Netze (sogenannte
Web-Views) vereinfacht. Verweisstrukturen befinden sich in eigenen Web-Dokumenten, und
werden graphisch visualisiert und manipuliert. Auf diese Weise können persönliche und ge-
meinsam genutzte Netze erstellt werden. Eine Erweiterung von Intermedia erlaubte die Ver-
wendung von Templates zur Unterstützung der Hypertext-Konstruktion. Templates sind Teil-
netze eines Hypertextes, von denen durch Kopieren Instanzen erzeugt werden.
Intermedia sieht ein Hypertext-Austauschformat vor, das von den Inhalten des Hypertexts
abstrahiert, und ausschließlich auf den Austausch der Verweisstrukturen ausgerichtet ist. Für
den Austausch von Dokumenteninhalten wurde auf existierende Standards zurückgegriffen.

2.2.3.4 Dexter Hypertext-Referenzmodell
Das Dexter Hypertext-Referenzmodell ist das Ergebnis mehrerer von der Dexter-Gruppe or-
ganisierter Workshops, und stellt eine umfassende Referenzarchitektur für Hypertexte dar. Es
basiert auf einer Drei-Schichten-Architektur:
• Runtime Layer: Darstellung des Hypertexts, Benutzerinteraktion, Dynamik
• Storage Layer: Datenbasis für ein Netz von Knoten und Links
• Within-Component Layer: Inhalt bzw. Struktur eines Knotens
Auf der Ebene des Storage Layers sind die Knoteninhalte opak. Ihre innere Struktur offenbart
sich erst im Within-Component Layer. Als Schnittstelle dieser beiden Schichten dient das
sogenannte Anchoring. Es ermöglicht über indirekte Adressierung, daß Verweise innerhalb
von Knoten entspringen und Ziele innerhalb von Knoten haben können, ohne daß im Storage
Layer Information über die Struktur der Knoteninhalte vorhanden sein muß.
Ein zweiter wichtiger Aspekt ist ein Hypertext-Datenmodell. Es benennt atomare Komponen-
ten, Links und zusammengesetzte Komponenten als fundamentale Objekte. Das Modell trennt
klar zwischen dem Inhalt der Knoten und der Bildung des Hypertext-Netzes aus diesen Kno-
ten.
Diese Trennung ist Voraussetzung für die Offenheit des Modells. Offenheit bedeutet hier die
Möglichkeit, das System um neue Typen von Knoteninhalten zu erweitern. Wie Intermedia
macht auch das Dexter-Modell bewußt keine Vorgaben für die Darstellung der Knoteninhalte.
[HS94]

2.2.3.5 Digital LinkWorks
Digital LinkWorks ist eine konkrete Umsetzung des Dexter-Referenzmodells. Die Trennung
von Struktur und Inhalt wird gewährleistet, indem ein Strukturdienst quasi auf Ebene des Be-
triebssystems agiert, und von Applikationen in Anspruch genommen werden kann. Über eine
offene Programmier-Schnittstelle können bereits existierende, weitverbreitete Applikationen
integriert, und damit der Bedarf an speziellen Editoren für Inhaltsdokumente abgedeckt wer-
den. Die Applikation hinterlegt bei LinkWorks die Identität von Dokumenten sowie den An-
ker innerhalb des Dokuments als Surrogat, und kann so Dokument und Anker bei Bedarf spä-
ter wiederfinden. LinkWorks selbst speichert nur die Links, von denen der Benutzer beliebig
viele erzeugen kann. Linkdokumente lassen sich zu einer gemeinsamen Sicht überlagern.
Wenn der Benutzer einen Link verfolgt, der zu einem Dokument führt, dessen zugehörige
Applikation noch nicht gestartet ist, so startet LinkWorks diese. Über eine Ereignisnachricht
erhält die Anwendung den Befehl zur Darstellung des entsprechenden Dokuments, wobei ge-
gebenenfalls auf den Zielanker positioniert wird. [Richartz95]
2.2.3.6 World Wide Web
Tim Berners-Lee arbeitete 1980 als Consultant am europäischen Teilchenphysik Zentrum
CERN in Genf. In seiner täglichen Arbeit frustrierte ihn der Umstand, daß sein Terminkalen-
der, sein Telefonbuch und seine Dokumente in unterschiedlichen Datenbasen abgelegt waren,
was einen simultanen Zugriff unmöglich machte. Heute erinnert er sich: "I wanted a program
that could store random associations between arbitrary pieces of information" [Feizabadi96].
Sein erster Lösungsansatz war ein Programm namens "Enquire", das aber bald wieder in Ver-
gessenheit geriet.
Berners-Lee verließ in der Zwischenzeit das CERN, arbeitete im Bereich des Networking und
lieferte Beiträge zu RPC-Systemen (Remote Procedure Call). 1984 wurden am CERN TCP/IP
und das Internet eingeführt. Anfang 1989 kehrte Berners-Lee an das CERN (das mittlerweile
über die größte Internet Site in Europa verfügt) zurück. Die dortige Computerkultur war gera-

de im Umbruch begriffen und wurde nunmehr durch neue verteilte, objektorientierte Soft-
wareparadigmen wie jene von NeXT Software, und durch den Einsatz weiterentwickelter
UNIX Umgebungen geprägt.
Berners-Lee verfaßte einen Artikel unter dem Titel "Information Management: A Proposal".
Darin führt er die Nachteile der existierenden hierarchischen Informationssysteme an, und
schlägt als Alternative ein verteiltes, hypertext-basiertes System vor:
"[...] a single user-interface to many large classes of stored information such
as reports, notes, data-bases, computer documentation and on-line systems
help [...]" [Berners89]
Und weiter:
"Let us see what components a hypertext system at CERN must have. The only
way in which sufficient flexibility can be incorporated is to separate the infor-
mation storage software from the information display software, with a well-
defined interface between them. Given the requirement for network access, it is
natural to let this clean interface coincide with the physical division between
the user and the remote database machine." [Berners89]

Hypertext
Server
Dummy hypertext server
makes existing database
look like hypertext to the browser
Generic browser
Abbildung 4: Hypertext-Browser, Hypertext-Server und Hypertext-Gateway [Berners89]
Berners-Lee's Vorschlag enthält folgende Komponenten:
• Ein einfaches Protokoll für den Netzwerk-Zugriff auf für den Menschen lesbare Informa-
tionen in verteilten Systemen.
• Ein Protokoll für den automatischen Datenaustausch zwischen Informationsanbieter und -
konsument.
• Anzeigefunktionen für Text und Graphik unter Verwendung der diesbezüglich bereits am
CERN existierenden Technologien.
• Erstellung und Wartung von Dokumentensammlungen, in welche die Benutzer selbst Do-
kumente ablegen können.

• Verknüpfung von Dokumenten oder Dokumentensammlungen durch vom Benutzer er-
stellte Hyperlinks.
• Eine Option, welche die Suche von Inhalten nach Schlüsselworten ermöglicht, und über
Hyperlinks erreichbar ist.
• Den Einsatz von frei verfügbarer Software wo immer möglich, Bereitstellung von Schnitt-
stellen zu existierenden, proprietären Systemen.
• Die kostenlose Bereitstellung der benötigten Programme.
"As it happened many times in the history of science, the most impressive re-
sults of the super-large scale scientific efforts were far from the main direc-
tions of these efforts. I hope you agree that Web was a side effect of the CERN's
scientific agenda. After World War 2, the nuclear centers of [...] developed
countries around the world became the places with highest rate of the concen-
tration of talented people per square of Labs. Some of the most talented per-
sons among the national scientists usually were invited to the international
CERN's Laboratories. The specific kind of the CERN's intellectual 'entire cul-
ture' was constantly growing from one generation of the scientists and engi-
neers to another during about four decades." [Feizabadi96]
1990 wurde der Vorschlag Berners-Lees unter dem Projekttitel "World Wide Web" umge-
setzt. Die ersten WWW-Server und ein Browser wurden unter Verwendung von NeXTSTEP
implementiert. Der Browser erlaubte neben der Anzeige auch WYSIWYG-Editierung von
Hypertexten. Als Kommunikationsprotokoll zwischen Client und Server wurde das Hypertext
Transport Protocol (HTTP) eingesetzt, Hyper Text Markup Language (HTML) und Universal
Resource Locator (URL) dienten der Erstellung von Web-Dokumenten. Die Software wurde
1991 auf andere Plattformen portiert und schließlich für die Öffentlichkeit freigegeben.
Marc Andreesen war zu dieser Zeit am National Center for Supercomputing Applications
(NCSA) der University of Illinois beschäftigt. Er leitete eine kleine Gruppe von Diplomanden,

die im Februar 1993 eine Alpha-Version ihrer Weiterentwicklung des CERN Browsers veröf-
fentlichten: "Mosaic for X". Im August desselben Jahres folgten frei erhältliche Versionen von
Mosaic für Windows und Apple Macintosh. Zum ersten Mal in der Geschichte des World
Wide Web existierte ein Webclient mit einem konsistenten und einfach zu handhabenden
"Point-And-Click" Benutzerinterface für die drei häufigsten Betriebssysteme. Im Herbst 1993
machte der WWW Netzwerkverkehr dennoch erst etwa 1% des Gesamtverkehrs auf dem NSF
(Nation Science Foundation) Backbone aus.
Andreesen plante ursprünglich keine Weiterentwicklung von Mosaic. Anfang 1994 initiierte
er dann aber gemeinsam mit Eric Bina und dem Gründer von SGI, Jim Clark, die "Mosaic
Communications Corporation", die heute als Netscape bekannt ist.
Dem World Wide Web liegt die Idee eines Universum von Dokumenten zugrunde, wobei
jedes Dokument über einen Universal Resource Locator eindeutig referenzierbar ist. Dieser
Mechanismus baut auf den Namensdiensten des Internet auf.
HTML basiert auf den Konzepten von SGML (Standard Generalized Markup Language), ist
aber stark vereinfacht. Verschiedene Arten von Klienten, meist graphische Browser wie Inter-
net Explorer oder Netscape, lösen URI-Adressen auf und fordern HTML-Dokumente und dar-
in eingebundene Objekte von HTTP-Servern an. HTML-Dokumente enthalten eingebettete
Links in Form von weiteren URIs, die vom Benutzer angewählt werden können.
Dieses Konzept nimmt große Einschränkungen zugunsten eines weltweiten, einfach zu erwei-
ternden Dokumenten-Universums in Kauf. So gibt es keinen Mechanismus zur Konsistenzer-
haltung. Die Folge sind Links, deren Ziel einfach nicht mehr existiert. Links sind keine eigen-
ständigen Objekte, sondern lediglich in Form von Ankern in das Quell-Dokument eingebettet.
Die Zurückverfolgung von Links vom Ziel zu Quelle ist demzufolge nicht möglich. Ebenso-
wenig können Teilnetze manipuliert oder graphisch dargestellt werden.

Als einzige Navigationshilfe machen die WWW-Klienten Links auf Dokumente, die bereits
einmal gesehen wurden, kenntlich - allerdings unabhängig davon, ob sie zwischenzeitlich ge-
ändert wurden. Außerdem wird eine einfache Navigationshistorie mitgeführt. Ein weiteres
Problem ist die unbekannte Kommunikationsbandbreite. Der Benutzer kann von einem Link
aus oft nicht erkennen, was mit der Selektion des Links ausgelöst wird. Ein Verweis von ei-
nem lokalen Dokument kann durchaus das Laden mehrerer Megabyte von Informationen von
der anderen Seite des Erdballs auslösen. [Richartz95]
2.2.3.7 Hyper-G / HyperWave
Hyper-G / HyperWave wurde in der ersten Hälfte der neunziger Jahre am Institut für Informa-
tionsverarbeitung und computergestützte Medien (IICM) der Technischen Universität Graz
entwickelt. 1996 wurde Hyper-G in HyperWave umgetauft, und wird seither auch kommer-
ziell angeboten.
Der Entwurf von Hyper-G verlief weitgehend parallel und unabhängig vom World Wide Web,
wobei aber zweifellos einige Konzepte verschiedener Internet-Dienste miteingeflossen sind.
Hyper-G ist verteiltes, mehrbenutzerfähiges Client/Server System. Dabei kommt ein eigenes,
verbindungsorientiertes Protokoll zum Einsatz.
Hyper-G Dokumente werden in Form einer SGML-Variante namens Hyper-G Text Format
(HTF) kodiert, und in hierarchischen Kollektionshierarchien (Dokumentensammlungen) ge-
speichert. Links werden in einer eigenen Datenbasis abgelegt. Sie sind von beiden Seiten aus
sichtbar und traversierbar, können graphisch veranschaulicht und auf Konsistenz geprüft wer-
den. Darüber hinaus ist eine Suche über Attribute und Inhalt von Dokumenten vorgesehen.
Hyper-G Server ermöglichen den Zugriff auf Dokumente und Links, und stehen untereinander
in Verbindung. Jeder Server besitzt ein HTTP-Gateway, so daß auch mit WWW-Browsern auf
die Informationen eines Hyper-G Servers zugegriffen werden kann. Dabei gehen aber einige

Orientierungs- und Navigationshilfen verloren, die in den systemeigenen Clients angeboten
werden.
Der am weitesten entwickelte Client für HyperWave heißt "Harmony" und ist für verschiede-
ne Unix-Plattformen erhältlich. Der Client für Microsoft Windows wird "Amadeus" genannt
und bietet im Vergleich zu Harmony etwas eingeschränkte Navigations- und Orientierungshil-
fen. Ein Herzstück von Harmony ist der sogenannte Session Manager, der die augenblickliche
Position in der Kollektionshierarchie anzeigt. Eine Besonderheit ist die Unterstützung von
dreidimensionalen Szenen als Hyper-G Dokumente, in denen der Benutzer navigieren und
Dokumente auswählen kann.
Harmony wird durch verschiedene Anzeige-Programme ergänzt. Das am häufigsten benutzte
ist der Hypertext-Viewer, der auch HTML-Dokumente anzeigen kann. Dazu kommen Postsc-
ript-Viewer, MPEG- und Audio-Decoder, usw.
Gegenüber dem World Wide Web läßt sich Hyper-G wie folgt abgrenzen [Weinreich97]:
• Sitzungen sind verbindungsorientiert. Benutzer können sich anmelden, und verfügen über
eine persönliche Konfiguration.
• Es werden zu jedem Zeitpunkt Hilfestellungen zur Orientierung und zur Navigation durch
das Informationsangebot angeboten.
• Inhalte können nur in strukturierter Form und unter Verwendung der Hyper-G Clients in
einen Server eingebracht werden.
• Alle Dokumente werden in einer objektorientierten Datenbank erfaßt und dabei gleich
voll-textindiziert.
• Links bestehen als unabhängige Einträge in einer eigenen Datenbank und sind bidirektio-
nal.

• Links sind nicht an einen Objekttyp gebunden, sondern können von allen Dokumenttypen
ausgehen, also auch von Tondokumenten, Bildern, Videos und 3D-Szenen.
• Das System unterstützt Mehrsprachigkeit. Benutzer können eine bevorzugte Sprache wäh-
len.
• Es existiert ein hierarchisches Benutzer- und Gruppenkonzept, wodurch ein granuliertes
Zugriffsrecht-System ermöglich wird.
• Die Netzbelastung durch Verwendung von Caches reduziert.
Hyper-G war von den Entwicklern als das Internet-Informationssystem der zweiten Generati-
on gedacht. Trotz der zahlreichen Vorteile konnte es sich jedoch nicht durchsetzen - bis heute
gibt es weltweit nur einige hundert Server.
2.2.3.8 Aktuelle Technologien und Werkzeuge
Heute existiert eine Vielzahl von Authoring-Systemen, welche die Erstellung professioneller
WWW-Seiten vereinfachen. Traditionellerweise sind diese Werkzeuge entweder für Power-
User gedacht und ermöglichen die komfortable Kodierung und Prüfung von HTML, oder aber
es wird eine bequeme WSYIWYG-Benutzerschnittstelle ("What you see is what you get")
angeboten, sodaß keinerlei HTML-Kenntnisse erforderlich sind. In letzter Zeit ist zu beobach-
ten, daß diese beiden konträren Ansätze wieder vermehrt zusammenwachsen, indem etwa
zwischen WSYIWYG- und reiner Code-Ansicht hin- und hergeschaltet werden kann. Die De-
signarbeit kann außerdem durch die Verwendung von übergeordneten Layouts, vorgefertigten
Komponenten für Navigation oder für Messageboards, und die Integration von externen Da-
tenquellen vereinfacht werden.
Moderne Webauthoring-Programme benötigen aber auch zahlreiche Funktionen, die über das
Erstellen und Modifizieren einzelner Seiten hinausgehen. Selbst für wenig komplexe Hyper-
text-Strukturen ist eine effiziente Site-Verwaltung und die werkzeugunterstützte Aktualisie-

rung von Inhalten und Links ein Muß. Oft wird auch ein automatischer Abgleich mit dem
Web-Server angeboten.
Zu den meistverwendeten Tools zählen Macromedia Dreamweaver (intuitiver graphischer
Designer, Unterstützung vieler Standards, Kompatibilität zu allen wichtigen Web-Browsern,
Datenaustausch mit anderen Macromedia Produkten), NetObjects Fusion (integriertes Site-
Management, Link-Prüfung, konsistente Visualisierung, automatische Erstellung von Naviga-
tions-Leisten) und Microsoft Frontpage (einfache Handhabung, Wizards und Vorlagen, In-
tegration mit Microsoft Office).
Der Arbeitsaufwand für die Entwicklung, aber vor allem auch die Pflege von WWW-Seiten,
ist beim Einsatz klassischer Web-Publishing Werkzeuge dennoch beträchtlich. Die dynami-
sche Erstellung von Hypertexten - etwa über eine Datenbankanbindung - war ein erster Ansatz
zur Entkopplung von Daten und deren Darstellung. Content Management Systeme beruhen
auf einem ähnlichen Prinzip, gehen aber noch darüber hinaus. Sie ermöglichen die Abdeckung
des gesamten Entwicklung- und Wartungsprozesses, inklusive Versionierung, Link-
Management, Internationalisierung, Einhaltung von Corporate Identity und Abbildung des
Publishing-Workflows.
Innerhalb von Content Management Systemen werden Vorlagen und Inhalte (Texte, Bilder
und andere Bestandteile) separat in einer Datenbank abgelegt. Der Ablauf der Seitenerstellung
wird durch ein Rollenkonzept und ein Berechtigungssystem unterstützt, wodurch die ver-
schiedenen Mitarbeiter konfliktfrei in Teilbereichen (Layout, Sitestruktur oder an einzelnen
Dokumenten) arbeiten können. Weitere wichtige Merkmale sind Importfähigkeiten, die Er-
weiterbarkeit mittels Skriptsprachen und Modulen, Personalisierung vom Webinhalten, XML-
Fähigkeiten, Content Syndication (der Austausch von Inhalten zwischen Websites) und Re-
portingfunktionen.
Besonders interessant ist Content-Syndication für Websites, die ihr Angebot mit unterneh-
mensrelevanten Informationen aufwerten wollen, beispielsweise mit Branchen-News, Börsen-

kursen oder aktuellen Nachrichten, oder die bestimmte Inhalte von anderen Sites automatisch
beziehen. Grundlage dafür ist das sogenannte Information and Content Exchange Protokoll
(ICE). Dieses bidirektionale Protokoll versendet zur Übertragungssteuerung XML-basierte
Nachrichten zwischen den beteiligten Systemen. ICE ist formatunabhängig, das heißt, es kön-
nen Texte, Bilder oder andere Binärdaten übertragen werden. ICE wird voraussichtlich auch
als Standard durch das W3C (WWW Konsortium) ratifiziert. [Eike00]
Bekannte Content Management Produkte sind Vignette Storyserver (Highend-Lösung),
Gauss VIP (Integration externer Datenbanksysteme, Verwendung von professionellen Web-
Editoren) und Network Productivity System (Design-Vorlagen, Datenbankanbindung über
Common Gateway Interface, Verwaltung und Bedienung via Web-Browser). [Zschau01]
2.2.3.9 Schlußfolgerungen
Während bei den Ansätzen von HyperCard, NoteCards und Intermedia Knoteninhalte in ei-
nem bestimmten Format vorliegen müssen, wird in den Konzepten von Dexter und Link-
Works von den Datentypen der Knoteninhalten abstrahiert - somit kann jede nur denkbare
Applikation angebunden werden. Diese Hypertextsysteme befassen sich vorrangig mit der
Repräsentation der Hypertextstruktur, wobei die Bedeutung des Knotens mehr (LinkWorks)
oder weniger (Dexter) weit zurücktritt. Auch werden hier Links konsequent als eigenständige
Objekte im Hypertextsystem behandelt, so daß ihnen Attribute zugeordnet werden können und
sie von beiden Seiten sichtbar sind.
Das World Wide Web macht die Problematik der Link-Sichtbarkeit und Aktualität besonders
deutlich. In verteilten Systemen wird es mit zunehmender Größe immer schwerer möglich,
Links speziell zu verwalten. Im WWW werden Links in Dokumente eingebettet. Daraus resul-
tiert ein weiteres Problem: wird ein Knoten gelöscht, können hängende Links entstehen, die
auf ein nicht existierendes Ziel zeigen.

Norman Meyrowitz, der Entwickler von Intermedia, formulierte dies - in Analogie zu Edger
Dijkstras Bemerkungen über unstrukturierte Programmiertechnik - so: "Pure hypertext is like
spaghetti code with GOTOs". Laura de Young ging noch einen Schritt weiter und wählte für
einen Artikel den provokanten Titel "Linking Considered Harmful" [DeYoung90].
Es ist festzustellen, daß viele bestehende Hypertextsysteme vornehmlich für die Entwicklung
informeller (unstrukturierte Daten) bzw. semi-formaler Strukturen geeignet sind. Regelmäßig
wiederkehrende Strukturmuster müssen oftmals manuell erzeugt werden. Dies ist vor allem
bei der Erstellung von umfangreichen Hypertexte problematisch. Zweifellos ist ein strukturier-
tes Vorgehen bei der Erstellung von Hypertexten unabdingbar. [Richartz95]
"Betrachtet man die im praktischen Einsatz befindlichen sog. Autorensysteme,
so fallen hier starke Defizite auf. Die meisten Systeme erlauben zwar das Edi-
tieren der monomedialen Medien [...] sie erlauben die Verwendung von Scrip-
ting-Sprachen oder Icon-basierte Kontrollfluß-Sprachen. Der Hauptar-
beitsaufwand liegt in der Implementierung der Hypermedia-Anwendung, d.h.
der Erzeugung und Synchronisation multimedialer Daten, dem Schreiben von
Scripte, dem Entwurf von Layouts etc. Der Rückgriff auf bestehende Strukturen
wird nicht unterstützt, allenfalls der Rückgriff auf einzelne Elemente früherer
Projekte; insofern fängt jedes Projekt mit einem weißen Blatt Papier an." [Ri-
chartz95]

Das WebStyles Modell 31
3. Das WebStyles Modell
3.1 Überblick
Das WebStyles-Modell erfüllt die Forderung nach verbesserter Benutzerunterstützung bei
Konstruktion von und Navigation in Hypertexten durch:
• Effiziente Erstellung von Hypertext-Dokumenten und -Anwendungen.
• Verbessertes Navigationsverhalten.
• Strukturkonsistenz von Hypertext-Dokumenten durch Typbeschreibungen.
• Trennung von Navigation und Inhalt.
• Wiederverwendbarkeit unabhängiger Hypertext-Typen und der darin enthaltenen Naviga-
tionsstrategien.
Das WebStyles-Modell umfaßt drei wesentliche Bestandteile. Generische Netze, regelbasier-
te Navigationsunterstützung und Prozeduren. Eine konkrete Kollektion dieser drei Kom-
ponenten stellt eine Typdefinition für Hypertext-Anwendungen dar. Ergänzt wird der Ansatz
durch eine Einbettung in ein klassen- oder prototypbasiertes Objektmodell und die Abbildung
auf existierende Hypertext-Architekturen.

3.2 Benutzerrollen
Drei Benutzerrollen sind für den Einsatz von WebStyles charakteristisch:
Der WebStyles-Autor erstellt Hypertext-Typdefinitionen einschließlich Navigationsregeln
und Prozeduren. Er spezifiziert Attribute und Regeln, und zwar überall dort, wo später bei der
Erstellung der konkreten Hypertext-Anwendung Vererbung stattfindet. Damit legt er den
Grundstein für die Qualität der daraus entstehenden Hypertexte.
Der Hypertext-Autor verfaßt Hypertexte auf Basis einer von ihm ausgewählten Hypertext-
Typdefinition, die sämtliche Struktur- und Inhaltsvorgaben enthält, durch sukzessives Erwei-
tern. Er erzeugt also hauptsächlich Inhalt. In den meisten Szenarien wird diese Rolle von ei-
nem Fachexperten eingenommen.
Der Hypertext-Benutzer konsumiert den entstandenen Hypertext, indem er durch ihn navi-
giert. Im Hintergrund wertet das WebStyles-Laufzeitsystem Navigationsregeln und Prozedu-
ren aus, und aktualisiert das Benutzer-Modell. Die Existenz der WebStyles nimmt der Benut-
zer jedoch nur durch das dynamische Navigationsverhalten des Hypertexts wahr.
3.3 Hypertext-Komponenten
Der WebStyles-Ansatz basiert auf einem formalen Modell, auf dem alle weiteren Elemente
aufbauen. Aus diesem Modell ergeben sich auch die Anforderungen an konkrete Hypertext-
systeme, auf deren Grundlage das WebStyles-Modell realisiert werden kann.
Eine wichtige Eigenschaft von WebStyles ist die Objektorientierung. Hypertext-Objekte re-
flektieren immer Zustand und Verhalten. Die Realisierung kann auf einem prototyp- oder ei-
nem klassenbasierten Objektmodell beruhen.

3.3.1 Hypertext-Objekt
Das Hypertext-Objekt ist das grundlegende Element von Hypertexten. Es stellt den Basistyp
für alle in Hypertexten enthaltenen Objekte dar. In einem klassenbasierten Modell ist dies eine
abstrakte Klasse, das heißt es können keine Instanzen von Hypertext-Objekten erzeugt, son-
dern nur Unterklassen abgeleitet werden. Ein Hypertext besteht aus den vom Hypertext-
Objekt abgeleiteten Knoten und Links.
Das WebStyles-Modell setzt voraus, daß Hypertext-Objekten eine Menge von Attributen zu-
geordnet werden können. Ein Attribut ist ein Name/Wert-Paar. Als Namen werden Bezeichner
verwendet, wie sie auch in Programmiersprachen üblich sind, als Werte müssen zumindest
Ganzzahlen, Wahrheitswerte, Zeichenketten, Arrays und Referenzen auf Hypertext-Objekte
zulässig sein.
Hypertext-Objekte entsprechen damit den in objektorientierten Systemen üblichen Dictiona-
ries, das heißt der Attributname stellt einen eindeutigen Schlüssel für den zugehörigen Wert
dar. Dieser Umstand kommt auch einer Realisierung mit einem prototyp-basierten Objektmo-
dell entgegen, da die Attribute als "Slots" der Objekte modelliert werden können.
Die von Hypertext-Objekten abgeleiteten Knoten- und Link-Objekte können beliebig viele
zusätzliche Attribute besitzen. Durch bestimmte Attribute wird der anwendungsbezogene Typ
des Hypertext-Objekts definiert. Somit ergibt sich die Möglichkeit, eine Reihe von Typinfor-
mationen anzugeben, welche von der Hypertextanwendung unterschiedlich interpretiert wer-
den.
3.3.2 Hypertext-Knoten
Ein Knoten ist ein Hypertext-Objekt, das durch ein spezielles Inhaltsattribut ausgezeichnet
ist. Da der WebStyles-Ansatz unabhängig von der Art des Inhalts von Knoten anwendbar ist,

ist auch eine nähere Betrachtung des Wertebereichs für den Knoteninhalt nicht relevant. Es ist
auch unwesentlich, ob der Knoten selbst die Inhaltsinformation enthält oder nur einen Ver-
weis auf eine externe Inhaltsinformation darstellt. Knoten haben außerdem die Eigenschaft,
daß ihnen für die Darstellung des Inhalts ein Präsentationsobjekt zugeordnet werden kann.
Für die Modellierung der Navigation benötigt man die Definition der Adjazenzmengen eines
Knotens. Diese enthalten alle aus- und eingehenden Links eines Knotens, repräsentieren also
die lokale Nachbarschaft eines Knotens.
3.3.3 Aggregat-Knoten
Eine Sonderstellung nimmt der Aggregat-Knoten ein. Er besitzt als Knoteninhalt einen wei-
teren Hypertext. Aggregat-Knoten können auch als Abstraktion oder Generalisierung des ent-
haltenen Hypertextes verstanden werden. Ein Aggregat-Knoten ist also ein spezieller Knoten
mit einem eingebetteten Hypertext und einer Menge von Zugangslinks des eingebetteten Hy-
pertexts, die in weiterer Folge auf ein- und ausgehende Links des Aggregat-Knoten abgebil-
det werden.
3.3.4 Hypertext-Link
Ein Link ist ein spezielles Hypertext-Objekt, das vereinfacht betrachtet genau einen Quell-
knoten mit einem Zielknoten assoziiert. Nach dieser Definition besteht zunächst keine weitere
Beziehung zwischen dem Inhalt des Quell- bzw. Zielknotens, das heißt Links sind lediglich
am Knoten als Ganzes angebracht. Für die meisten Anwendungen reicht dies nicht aus. Es
wird gefordert, daß Links an bestimmten Punkten des Knoteninhalts angebunden werden. Sol-
che Teilmengen sind üblicherweise Selektionen innerhalb des Knoteninhalts. Die Adjazenz-
Knotenmenge eines Links besteht aus den beiden Knoten, die über den Link verbunden sind.

3.3.5 Hypertext-Anker
Die Anbindung von Links an Knoten wird über Anker realisiert. Ein Anker ist ein Anbin-
dungspunkt, abgebildet als Surrogat der Selektion innerhalb des Inhalts des Knotens. Dieses
Surrogat wird durch die WebStyles-Umgebung nicht interpretiert, sondern nur als transparente
Information gehalten. Bei der Aktivierung des Knotens wird das Surrogat unverändert an die
Inhaltsdomäne der konkreten Anwendung zurückgegeben, so daß diese den Anbindungspunkt
entsprechend identifizieren und darstellen kann.
Ein Anker ist im übrigen kein vollwertiges Hypertext-Objekt im oben angeführten Sinne, das
heißt er kann keine weiteren Attribute besitzen. Durch die Einbeziehung von Ankern ändert
sich die Definition von Links. Links können als spezielle Hypertext-Objekte mit einem Quell-
anker und einem Zielanker betrachtet werden, wobei Quellknoten und Zielknoten des Links
über die Anker identifiziert werden. Ein Link gilt dann als konsistent, wenn Quell- und Ziel-
anker definiert sind. Ein Link, der diese Bedingung nicht erfüllt, wird als hängender Link be-
zeichnet.

3.4 Generische Netze
Der Verwendung generischer Netze zur Hypertext-Typdefinition ist eine zentrale konzeptio-
nelle Idee des WebStyles-Modells. Ein generisches Netz ist ein Hypertext, der aus einer Men-
ge von generischen Knoten und einer Menge von generischen Links besteht. Diese bestim-
men, welche Knoten und Links in einem gültigen, vom generischen Netz abgeleiteten Hyper-
text vorkommen können, und wie oft.
3.4.1 Generische Knoten
Jeder generische Knoten ist Stellvertreter für einen, mehrere oder keinen Knoten in einem
abgeleiteten Hypertext. Diese Klassifizierung entspricht den anschließend dargestellten obli-
gatorischen Knoten, Sequenzknoten und optionalen Knoten. Die Abbildung verdeutlicht auch
Hypertextfragmente, wie sie von den generischen Knotentypen abgeleitet werden können. Zur
visuellen Unterscheidung der generischen Hypertext-Objekte von den davon abgeleiteten kon-
kreten Knoten und Links werden die generischen Objekte grau dargestellt. Die Raute in einem
Link kennzeichnet ihn als vollständig (Quelle und Ziel sind definiert).

Generischer Knotentyp Graphische Darstellung Mögliche Ableitungen
Obligatorischer Knoten
REQ
Optionaler Knoten
OPT
Sequenzknoten
SEQ
Abbildung 5: Generische Knotentypen und mögliche Ableitungen
Ein generischer Knoten spezifiziert auch Attribute für alle abgeleiteten Knoten, insbesondere
• Typ und Name
• Vorgabe für den Inhalt (Schablone)
• Regeln für die Navigationsunterstützung im abgeleiteten Hypertext
• Weitere anwendungsspezifische Attribute, die vom WebStyles-Autor festgelegt werden.
Die drei generischen Knotentypen unterscheiden sich durch die jeweils unterschiedliche unte-
re und obere Grenze für die abzuleitenden konkreten Knoten. Es wird jedoch an der für den
Benutzer verständlicheren Bezeichnung von obligatorischem, optionalem und Sequenzknoten
festgehalten.

Somit ergibt sich für den obligatorischen Knoten als minimale und maximale Anzahl der
Instanzen der Wert eins. Der optionale Knoten, der als konkreter Knoten auftreten kann, hat
als Untergrenze den Wert Null und als Obergrenze den Wert Eins. Beim Sequenzknoten sind
die beiden Werte frei wählbar und entscheiden darüber, ob die Sequenz eventuell ganz ver-
schwindet und wie viele Knoten in der Sequenz maximal vorkommen können.
Die Instantiierung von Sequenzknoten und optionalen Knoten erfordert eine spezielle Behand-
lung. Jeweils ein eingehender und ein ausgehender Link von generischen Sequenzknoten und
optionalen Knoten werden als Sequenzlinks ausgezeichnet (in den Abbildungen durch
schwarze Punkte zwischen Link und Knoten dargestellt). Bei einem möglichen Wegfall des
Knotens im konkreten Hypertext werden die beiden Sequenzlinks durch einen Link ersetzt.
Bei der mehrfachen Instantiierung des Knotens werden Links zu Sequenzen von Links einge-
fügt, so daß jeweils der ausgehende Sequenzlink des vorhergehenden Knotens mit dem einge-
henden Sequenzlink des folgenden Knotens zu einem neuen, gemeinsamen Link zusammen-
geführt wird.
Alle anderen Links, die bei denen solchen Knoten ein- und ausgehen, fallen weg, wenn der
betreffende generische Knoten nicht instantiiert wird. Bei mehrfacher Instantiierung von gene-
rischen Knoten werden die von ihnen ausgehenden Stränge mitdupliziert. Dieses Prinzip wird
in weiterer Folge noch näher erläutert.
Zur Beschreibung hierarchischer bzw. baumförmiger Strukturen sind Aggregatknoten vorge-
sehen, die bei der Ableitung nicht durch einen konkreten Knoten, sondern durch das enthalte-
ne generische Netz ersetzt werden. Zu diesem Zweck wird jeweils ein ein- und ein ausgehen-
der Link des eingebetteten generischen Netzes als Standard-Zugangslink gekennzeichnet, und
mit einem ein- und ausgehenden Link des Aggregatknoten verknüpft. Die Zuordnung der rest-
lichen Links erfolgt über Gleichheit der Namensattribute.

3.4.2 Generische Links
Analog zu den generischen Knoten stehen generische Links stellvertretend für einen, mehrere
oder keinen Link im abgeleiteten Hypertext. Dies entspricht den Typen des obligatorischen
Links, des sich wiederholenden Links (Fächerlink) und des optionalen Links. Ebenso wie der
generische Knoten legt der generische Link die Attribute für die von ihm abgeleiteten konkre-
ten Links fest, und zwar:
• Typ und Name des abgeleiteten konkreten Links
• Regeln für die Navigationsunterstützung im abgeleiteten Hypertext
• Weitere, anwendungsspezifische Attribute, die vom WebStyles-Autor festgelegt werden

Die folgende Abbildung veranschaulicht die verschiedenen generischen Linktypen.
Generischer Linktyp Graphische Darstellung Mögliche Ableitungen
Obligatorischer Link
Optionaler Link
Fächerlink
Abbildung 6: Generische Linktypen und mögliche Ableitungen
Auch hier werden die drei generischen Linktypen durch die untere und obere Grenze für die
zu instantiierenden Links definiert.

Fächerlinks haben zwei wichtige Eigenschaften, die beim obligatorischen bzw. beim optio-
nalen Link fehlen:
• Die Auffächerung der Instanzen erfolgt in der Richtung von der Quelle zum Ziel. Bei einer
mehrfachen Instantiierung haben alle Instanzen den gleichen Knoten als Quelle.
• Durch die mehrfache Instantiierung werden auch die Knoten am Ziel des Fächerlinks wie-
derholt instantiiert. Dieses Verhalten bei der Instantiierung ähnelt jenem des Sequenzkno-
tens. Dies impliziert, daß zusätzliche Links, die am generischen Zielknoten angebracht
sind, bei der Instantiierung auch dupliziert werden.
3.4.3 Stränge
Bei der mehrfachen Instantiierung von Sequenzknoten und Fächerlinks werden bestimmte
Teile des generischen Netzes, welche vom generischen Sequenzknoten bzw. vom Fächerlink
ausgehen, mitdupliziert. Diese mehrfach zu instantiierenden Teilnetze werden als Stränge
bezeichnet. Stränge können auch von optionalen Knoten und Links ausgehen, wo sie bei
Nicht-Instantiierung wegfallen.
Solcherart definierte Stränge erlauben die Konstruktion verschiedener Hypertext-Strukturen
durch generische Netze:
• Sackgassenartige Teilnetze, etwa als Vertiefung der Instanzen eines Sequenzknotens oder
Fächerlinks.
• Links, die von jeder Instanz eines Sequenzknotens zu einem gemeinsamen Ausgangskno-
ten führen.
• Hypertexte, die mehrfach verzweigen und später, jeweils nach mehreren Knoten und Links
in jedem Zweig, wieder an einem oder mehreren gemeinsamen Zielknoten zusammenge-
führt werden.

Ein spezieller Strang-Algorithmus dient der Ermittlung alle Hypertext-Objekte, die zu dem
Strang gehören, der von einem Sequenzknoten bzw. einem Fächerlink ausgeht. Der Algorith-
mus durchwandert ausgehend von jenen Links, die am Sequenzknoten hängen (mit Ausnahme
der beiden Sequenzlinks), bzw. vom Zielknoten des Fächerlinks, rekursiv alle Teile des gene-
rischen Netzes, die mit dem Sequenzknoten bzw. Fächerlink verbunden sind. Alle so besuch-
ten generischen Hypertext-Objekte sind Teil des Stranges. Abbruchkriterium ist das Erreichen
eines der folgenden Hypertext-Objekte:
• Links, die bei denen das Instantiierungsattribut join mit dem Wert true belegt ist, und die
in Vorwärtsrichtung erreicht werden. Durch diese Join-Links werden Strang-Instanzen
wieder zusammengeführt.
• Fächerlinks, die in Rückwärtsrichtung erreicht werden; auch sie dienen der Zusammenfüh-
rung von Strang-Instanzen.
• Sequenzknoten, die nicht über die Sequenzlinks erreicht werden, werden zu einer Kette
verknüpft, welche die einzelnen Strang-Instanzen miteinander verbindet. Eine derartige
Kette führt gewissermaßen als Querstraße durch die Strang-Instanzen.
Der Strang-Algorithmus markiert in Tiefensuche rekursiv die zum Strang gehörenden Teile
des generischen Netzes. Dabei werden vier Markierungen verwendet:
Markierung Knoten Links Bedeutung
F Fächermarke Feststellung von Widersprüchen
S Sequenzmarke Zum Strang gehörig, Sequenz-Instanz
ist zu erzeugen
J Zusammenführung Link führt Strang-Instanzen zusammen
D Duplizierung Zum Strang gehörig, Duplikat ist zu
erzeugen
Abbildung 7: Markierungen des Strang-Algorithmus

Der Algorithmus hat die Komplexität O(n), wobei n die Anzahl der Hypertext-Objekte im
generischen Netz bezeichnet. Er terminiert immer, da die Rekursion nur dann aufgerufen
wird, wenn tatsächlich eine Markierung am betreffenden Hypertext-Objekt gesetzt wurde.
Zur Verdeutlichung zeigt die folgende Abbildung die Auswirkung des Instantiierungsattributs
join eines generischen Links, der Teil eines Stranges ist, welcher von einem Sequenzknoten
oder einem Fächerlink ausgeht. Der Wert des Attributs join legt fest, ob mehrere Strang-
Instanzen durch diesen Link wieder zu einem gemeinsamen Zielknoten zusammengeführt
werden, oder nicht.
Generischer Sequenzknoten Mögliche Ableitungen
Ohne Join-Link
SEQ
Mit Join-Link
SEQ
J
Abbildung 8: Mehrfachinstantiierung von Sequenzknoten

Generischer Fächerlink Mögliche Ableitungen
Ohne Join-Link
Mit Join-Link
J
Abbildung 9: Mehrfachinstantiierung von Fächerlinks
Das Zusammenführen von Strängen über einen Link in umgekehrter Richtung, also vom Ziel
zur Quelle, erfolgt über einen Fächerlink, wie Abbildung 10 zeigt. Der Fächerlink ist also das
Gegenstück zu einem Join-Link.

Generisches Netz Abgeleitetes Netz
Abbildung 10: Zusammenführung von Strängen über einen Fächerlink
Enthält ein generisches Netz mehrere Sequenzknoten und/oder Fächerlinks, so können sich
die dadurch definierten Stränge überlappen. Dies führt dazu, daß bei der Konstruktion unter-
schiedliche Ergebnisse erzielt werden können, abhängig davon, an welcher Stelle der Hyper-
text-Autor das generische Netz zuerst expandiert.
Mit dem Strang-Algorithmus lassen sich auch noch komplexere Formationen als die eingangs
beschriebenen definieren. Es ist jedoch nicht Sinn dieses Mechanismus, beliebig komplizierte
Konstruktionen zu unterstützen, sondern die Strukturen Vertiefung, Verzweigung und Zu-
sammenführung zu ermöglichen.

Strang Graphische Darstellung
Generischer
Strang B
seq
A C DJ
Abgeleiteter
Strang
Bc1 Cc
Bb1
CaBa1
Ba2
A1
D1
Abbildung 11: Beispiel für eine Strang-Instantiierung
In generischen Netzen können aber auch widersprüchliche Strangdefinitionen enthalten sein.
Die Prüfung auf Widerspruchsfreiheit erfolgt bereits bei der Erstellung des generischen Net-
zes, indem ausgehend von jedem optionalen Knoten, Sequenzknoten, optionalen Link und
Fächerlink der Markierungsalgorithmus aufgerufen wird.
3.4.4 Hypertext-Konstruktion
Unter Ableitung oder Instantiierung eines konkreten Hypertextes versteht man den Vorgang
der Erzeugung eines Hypertextes nach den Vorschriften eines generischen Netzes. Dies ist die
typische Aufgabe des Hypertext-Autors. Dabei sind für die Instantiierung generischer Knoten
Alternativen vorgegeben, über die der Hypertext-Autor entscheidet. Die Alternativen für einen
Knoten können verschiedene Typen von konkreten Knoten, aber auch Aggregat-Knoten sein.
Wenn von einem generischen ein konkretes Hypertext-Objekt abgeleitet wird, wird letzteres
mit einer Reihe von Attributen versehen, die im generischen Hypertext-Objekt definiert sind.

Die Gruppe dieser Instantiierungsattribute ist eine ausgezeichnete Teilmenge der Attribute des
generischen Hypertext-Objekts. Dazu gehört gegebenenfalls eine Schablone für den Inhalt von
Knoten.
Die Attribute der generischen Hypertext-Objekte lassen sich wie folgt ordnen:
• Instantiierungsattribute, die die Instantiierung der Hypertext-Objekte kontrollieren.
• Navigationsattribute, welche die Navigation im generischen Netz steuern (im Gegensatz
zu den Navigationsregeln für den abgeleiteten Hypertext, welche zu den Instantiierung-
sattributen gehören).
• Konsistenzattribute, die Regeln zur weitergehenden Prüfung der Vollständigkeit des ab-
geleiteten Hypertextes enthalten. Sie werden nach Fertigstellung der Hypertext-
Konstruktion ausgewertet.
Der Ansatz zur Konstruktion von Hypertext-Graphen sollte einfach genug sein, um auch von
Laien verstanden zu werden. Nicht zuletzt deshalb sollten generische Netze aus einigen weni-
gen, dafür etwas größeren Produktionen bestehen, so daß die Hypertext-Autoren einen relativ
großen Teil des zu konstruierenden Hypertextes auf einmal überblicken können. Das Modell
der generischen Netze unterstützt auch intuitive Strukturierungsprinzipien wie Reihung, Ag-
gregation und Auswahl, die so auf die Strukturierung von Hypertexten übertragen werden
können.

3.5 Navigationsmodell
Die Navigationsunterstützung von WebStyles basiert auf einem einfachen Regelsystem. Ein
Benutzer navigiert in einem Hypertext, wenn er damit ein bestimmtes Ziel verfolgt. Doch
auch ein nicht zielgerichtetes Durchblättern oder Durchstöbern (Browsing) eines Hypertextes,
wird mit Hilfe des WebStyles-Navigationsmodells unterstützt.
Das Navigationssziel kann unterschiedliche Ausprägungen haben:
• Abdecken aller Informationsknoten oder bestimmter Teile davon.
• Auffinden einer bestimmten Information unter vielen.
• Befriedigung eines bestimmten Informationsbedürfnisses (wobei möglicherweise nicht
alle Informationsknoten des Hypertexts konsumiert werden müssen)
Ein Hypertext-Benutzer bewegt sich entlang von Links von Knoten zu Knoten. Dabei befindet
er sich wiederkehrend in verschiedenen Navigationssituation. Unter einer Navigationssituati-
on versteht man einen Zustand, in dem der Benutzer aus der Adjazenz-Linkmenge des Kno-
tens, an dem er sich gerade befindet, einen Link für die Ausübung des nächsten Navigations-
schritts auswählen muß. Ein Benutzer kann sich gleichzeitig in mehreren Navigationssituatio-
nen befinden, wenn das Hypertextsystem zuläßt, daß er mehrere Knoten zur gleichen Zeit ak-
tiviert.
Zu einem Navigationsschritt kommt es, wenn der Benutzer in einer Navigationssituation
einen Link gewählt hat und über diesen den Zielknoten aktiviert. Resultat des Navigations-
schritts ist eine neue Navigationssituation.

Der durch den Benutzer ausgelöste Navigationsschritt hat zwei mögliche Semantiken:
• Bei der Follow-Semantik wird der Ausgangsknoten der Navigationssituation durch den
Zielknoten des Navigationsschritts ersetzt. Die Verwendung des Ausgangsknotens gilt als
abgeschlossen. Die bisherige Navigationssituation existiert danach nicht mehr.
• Bei der Visit- oder Branch-Semantik bleibt die Aktivierung des Ausgangsknotens erhal-
ten, der neue Knoten wird zusätzlich aktiviert. Es entsteht also eine zusätzliche, neue Na-
vigationssituation. Die Visit-Semantik wird typischerweise bei der Navigation zu Blatt-
knoten eingesetzt, von denen keine weiteren Links ausgehen.
Darüberhinaus kann der Benutzer eine Navigationssituation auch aufgeben, indem er einen
aktivierten Knoten deaktiviert. Navigationsschritte werden von den Benutzern nacheinander
ausgeübt, so daß sich eine geordnete Menge von Links, die der Benutzer zur Navigation ver-
wendet hat, ergibt. Dies führt uns zum Begriff des Navigationspfads, welcher bei der Naviga-
tion des Benutzers entsteht: Der Navigationspfad ist eine geordnete Menge von Links, die ein
Benutzer zur Ausübung von Navigationsschritten benutzt hat. Da sich ein Benutzer in mehre-
ren Navigationssituationen befinden kann, ist durch den Navigationspfad nicht notwendiger-
weise ein Pfad vom Ausgangsknoten der ersten Navigationssituation zum Ausgangsknoten der
letzten Navigationssituation definiert.
Die Navigationsunterstützung des WebStyles-Ansatzes setzt als Entscheidungshilfe an der
Navigationssituation an, also genau dort, wo der Benutzer sich für einen Link für die Ausfüh-
rung des nächsten Navigationsschritts entscheidet. Die Unterstützung erfolgt durch Anwen-
dung von Navigationsregeln, die vom Hypertext-Autor als Teil des Hypertexts spezifiziert
werden. Resultat ist eine Menge von Links, auf die der Benutzer für seinen nächsten Naviga-
tionsschritt zurückgreifen kann.

Dabei sind zwei Strategien denkbar:
• Strikte Benutzerführung: Die Entscheidung über den nächsten Navigationsschritt wird
durch das Unterstützungssystem übernommen. Dem Benutzer bleibt allenfalls die Wahl
aus einer Menge von empfohlenen Links, die das Unterstützungssystem ermittelt hat.
• Freie, unterstützte Navigation: Dem Benutzer bleibt die Entscheidung über seinen
nächsten Navigationsschritt überlassen, die vom Navigationssystem ermittelten Linkmen-
gen gelten dabei nur als Empfehlungen.
Diese Navigationsunterstützung ist
• dynamisch, wenn sie immer bei Erreichen einer neuen Navigationssituation bzw. bei Ver-
änderung der Voraussetzungen, unter denen sie erfolgt, durchgeführt wird, also zu unter-
schiedlichen Zeitpunkten unterschiedliche Ergebnisse produziert.
• adaptiv, wenn dabei der bisherige Navigationsablauf des individuellen Benutzers mit ein-
bezogen wird.
Jeder Navigationsschritt des Hypertext-Benutzers, insbesondere die Aktivierung von Knoten,
kann eine Änderung des Benutzermodells und damit des Navigations-Kontexts hervorrufen.
Die Navigationsregeln werden jeweils als Attribute der an der Navigationssituation beteiligten
Hypertext-Objekte spezifiziert. Dabei werden gegebenenfalls mehrere Regeln zu einem Attri-
but zusammengefaßt. Die Menge der Regeln in einem Attribut kann aber auch leer sein.
Bei der Klärung der Frage, ob ein Link im Rahmen einer bestimmten Strategie benutzbar sein
soll oder nicht, spielt auch die Richtung eine Rolle, in der er passiert wird. Differierende Na-
vigationsrichtungen drücken unterschiedliche Semantiken aus. Deshalb können zusätzlich zu
den Regeln, die für beide Richtungen gleichermaßen gelten, für jede Richtung jeweils unter-
schiedliche Regeln spezifiziert werden. Bei der Zusammenstellung der aktuellen Regelbasis

werden also die Vorwärts-Navigationsregeln der ausgehenden Links und die Rückwärts-
Navigationsregeln der eingehenden Links in die Auswertung einbezogen.
Die wichtigsten Aufgaben des im WebStyles-Laufzeitsystem enthaltenen Regelinterpreters
sind:
• Dynamische Zusammenstellung von Anfragen an die Regelbasis unmittelbar vor der Er-
mittlung der für die Navigation möglichen Linkmengen
• Einbeziehung von Objekten und Attributen des Hypertext-Modells bei der Regelauswer-
tung
Der Benutzerkontext spielt in diesem Zusammenhang eine wesentliche Rolle. Er dient dazu,
alle global für einen Benutzer geltenden Informationen abzulegen.
3.6 Prozeduren
Während Regeln die Bedingungen festlegen, unter denen ein Benutzer im Hypertext navigie-
ren kann, definieren Prozeduren Aktionen, die bei der Navigation ausgeführt werden. So kann
etwa die Wissensbasis für die Link-Auswahl, insbesondere das Benutzermodell, aktualisiert
werden.
Navigationsprozeduren werden - wie Navigationsregeln - von WebStyles-Autoren als Be-
standteil generischer Hypertext-Objekte erstellt und bei der Instantiierung auf die konkreten
Hypertext-Objekte übertragen. Hypertext-Autoren haben die Möglichkeit, Prozeduren gege-
benenfalls noch anzupassen. Darüberhinaus sind Teile des WebStyles-Laufzeitsystems durch
Prozeduren realisiert. Da dem WebStyles-Modell ein objektorientiertes Hypertextmodell zu-
grunde liegt, definieren WebStyles-Prozeduren das Verhalten von Hypertext-Objekten. Sie
sind Methoden der Hypertext-Objekte.

Ein Knoten kann zwei Methoden besitzen, die bei der Navigation aufgerufen werden:
• Die activate()-Methode wird jedes Mal aufgerufen, wenn der Knoten durch Ausführen
eines Navigationsschritts über einen Link aktiviert wird. Die Ausführung erfolgt, bevor
der Knoteninhalt tatsächlich präsentiert wird, das heißt bevor die Anwendung Kontrolle
über den Inhalt erhält.
• Die deactivate()-Methode kommt zur Ausführung, wenn ein Knoten deaktiviert wird,
entweder durch explizite Deaktivierung durch den Benutzer oder durch die implizit ausge-
löste Deaktivierung eines Navigationsschritts mit der Follow-Semantik.
Analog dazu existieren auch Prozeduren für Links:
• Die traverseforward()-Methode wird aufgerufen, wenn ein Link vom Hypertext-Benutzer
zu einem Navigationsschritt in der Richtung von der Quelle zum Ziel betreten wird.
• Die traversebackward()-Methode wird aufgerufen, wenn ein Link vom Hypertext-
Benutzer zu einem Navigationsschritt in umgekehrter Richtung, vom Ziel zur Quelle, ver-
wendet wird.
Ein wichtiges Bestreben des WebStyles-Ansatzes ist es, daß das vorliegende Modell auch auf
Standard-Hypertext-Architekturen abgebildet werden kann. Dem wird unter anderem dadurch
Rechnung getragen, daß die generischen Netze selbst durch Hypertexte dargestellt werden.
Das WebStyles-Modell stützt sich dabei auf die Möglichkeit, Hypertext-Objekte mit einer
beliebigen Anzahl von Attributen auszustatten. Es kommen daher nur solche Hypertextsyste-
me als Basis in Frage, die beliebige Attribute an Knoten und Links zulassen.

3.7 Zusammenfassung
In diesem Kapitel wurde die formale Definition des WebStyles-Modell beschrieben. Grundle-
gender Bestandteil ist das eingangs erläuterte formale Hypertext-Modell. Zentrale Komponen-
te sind dabei generische Netze, die in der Form spezieller Hypertexte durch die Vorgabe obli-
gatorischer, optionaler und sich wiederholender Knoten und Links Typen von Hypertexten
beschreiben. Bei der Instantiierung der generischen Netze, also der Erzeugung konkreter Hy-
pertexte durch den Autor, werden Instantiierungsattribute der generischen Hypertext-Objekte
als Attribute an die abgeleiteten konkreten Hypertext-Objekte vererbt.
Der zweite Bestandteil des WebStyles-Modells ist die auf einem formalen Navigationsmodell
beruhende Navigationsunterstützung, die den Benutzer durch Link-Auswahlmengen unter-
stützt, welche durch Auswertung von Navigationsregeln ermittelt werden. Die Navigationsre-
geln sind Instantiierungsattribute der Hypertext-Objekte und werden vom WebStyles-Autor
als Attribute der generischen Hypertext-Objekte definiert.
Schließlich kann der WebStyles-Autor Prozeduren als Instantiierungsattribute vorsehen, die
bei der Navigation ausgeführt werden, etwa um das in die Auswertung der Navigationsregeln
einfließende Benutzermodell zu aktualisieren.

Implementierung 54
4. Implementierung
4.1 Wahl von Entwicklungssprache und -umgebung
Die Wahl der Implementierungssprache fiel in diesem Projekt auf Java. Als Vorteile von Java
etwa gegenüber C++ werden oftmals Plattformunabhängigkeit, einfachere Sprachsyntax und
Stabilität genannt. Im Falle des WebStyles-Editors waren diese Kriterien allerdings letztlich
nicht entscheidend. Vielmehr empfahl sich Java vor allem durch seine standardisierten APIs
(Application Programing Interfaces) im Umfeld von Hypertexten. Folgende Standard Java
Bibliotheken fanden Verwendung:
• Java 2D API für die graphische Darstellung von WebStyles-Graphen
• Java Foundation Classes (Swing) für die graphische Benutzeroberfläche und die interak-
tive Erstellung von WebStyles-Graphen
• Java Servlet API für die Referenz-Implementierung der WebStyles-Laufzeitumgebung
• Der HTML-Parser des javax.text.html Packages für die Implementierung des Hyper-
text-Dokumenteditors und die dynamische Modifikation der damit erstellten HTML-
Seiten im Rahmen der WebStyles-Laufzeitumgebung
Ein Schwachpunkt von Java ist das schlechte Laufzeitverhalten, vor allem was Applikationen
mit graphischer Benutzeroberfläche betrifft. Der WebStyles-Editor stellt in dieser Hinsicht
jedoch relativ geringe Anforderungen. Selbst bei Graphen mit hunderten Knoten und Links
(dieser Fall tritt in der Realität kaum auf) ist auf einem heutigen Standard-PC das interaktive
Bearbeiten ohne merkbare Verzögerung möglich.
Die eingesetzte Entwicklungsumgebung war Symantec Visual Cafe 3.0c, da diese IDE (In-
tegrated Development Environment) an der Abteilung für Telekooperation verfügbar war.

Implementierung 55
Visual Cafe enthält einen schnellen und relativ ausgereiften Compiler, die Umgebung ist
leicht zu bedienen und belastet den Entwickler nicht mit unnötigem Overhead. Als Defizite
stellten sich die geringe Stabilität, der mangelhafte GUI (Graphical User Interface)-Editor
und das Fehlen einer integrierten Java Servlet Engine, welche für die Implementierung der
Laufzeitumgebung benötigt wurde, heraus.
4.2 Systemarchitektur
Der WebStyles-Editor besteht aus 138 Klassen, der unkomprimierte Bytecode hat einen Um-
fang von 371kB. Ein graphisches Klassendiagramm inklusive sämtlicher Relationen wäre
unübersichtlich und würde zudem den Rahmen dieser Arbeit sprengen. Aus diesem Grund
beschränkt sich die folgende Darstellung auf die wichtigsten Anwendungsklassen rund um das
WebStyles-Paradigma.

Implementierung 56
model
WebStyles
javax.swing.JComponent
PSView
PSAbstractObject
PSObject
PSGraphPSComponent
PSNodePSLink
PSController
PSGraphControllerPSComponentController
PSNodeControllerPSLinkControllerPSNodeViewPSLinkView
PSGraphViewPSComponentView
PSNestedGraphNodeViewPSNestedGraphNodePSNestedGraphNodeCtrl
model
model
modelmodel
model
model
model
controller
propertyListenerpropertyListener
view
view
view
view
componentscomponentControllers
links
nodes
Abbildung 12: Klassendiagramm (Ausschnitt)

Implementierung 57
Da der Editor als SDI-Applikation (Single Document Interface) konzipiert wurde, referenziert
die Hauptanwendungsklasse zu jedem Zeitpunkt genau einen PSGraphController, an
dem wiederum ein PSGraphModel und eine PSGraphView hängen. Die PSGraphView
im ContentPane des Fensters dargestellt.
Beim Anlegen (und äquivalent beim Löschen) von Graph-Komponenten wird jeweils ein
Controller, ein Model und eine View instantiiert, und dem Graph-Controller, dem Graph-
Model bzw. der Graph-View hinzugefügt (bzw. entfernt).
Datenpersistenz eines WebStyles-Dokuments kann erreicht werden, indem der PSGraph-
Controller serialisiert wird. Die von dort ausgehende "Referenzwolke" enthält sämtliche
Objekte, die einen Graph definieren.
Diese Systemarchitektur entstand nicht im Zuge eines abgeschlossenen Entwurfsschrittes,
sondern vielmehr iterativ während der ersten Monate der Implementierung. Nachdem die erste
lauffähige Version des Editors lediglich einen Prototyp darstellte, erfüllte diese bei weitem
noch nicht die Anforderungen bezüglich objektorientierter Designqualität. Vor der Umsetzung
der komplexeren Funktionen des WebStyles-Modells wurde der Editor einem eingehenden
Redesign unterzogen, so daß danach eine gute Basis für die weiteren Entwicklungsschritte
vorlag.

Implementierung 58
4.2.1 Java Packages
Die Anwendungskomponenten wurden in folgende Packages untergliedert:
Package Bedeutung
at.ac.uni_linz.tk.webstyles Haupt-Anwendungsklassen wie WebStyles-
Graph, Hypertext-Objekte, Applikation
at.ac.uni_linz.tk.webstyles.action Java Swing Action-Klassen (auch: Kommandos)
für Menü- und Toolbar-Befehle
at.ac.uni_linz.tk.webstyles.engine Referenzimplementierung der WebStyles-
Laufzeitumgebung
at.ac.uni_linz.tk.webstyles.generic API-Schnittstellen für das Einklinken beliebiger
Knoteninhalte (auch zur Laufzeit)
at.ac.uni_linz.tk.webstyles.gui Graphische Benutzeroberfläche (Dialoge, Me-
nüs, Toolbar, etc.)
at.ac.uni_linz.tk.webstyles.util Utility-Klassen
at.ac.uni_linz.tk.webstyles.xml Basisklassen für den XML-Export von WebSty-
les-Graphen
at.ac.uni_linz.tk.webstyles.xml.memory Klassen für den XML-Export einer speziellen
Anwendungsdomäne (Generic Game Engine,
ebenfalls ein Projekt an der Abteilung für Tele-
kooperation)
Abbildung 13: Java-Packages des WebStyles-Editors

Implementierung 59
4.3 Objektorientierte Entwurfsmuster
In objektorientierten Sprachen lassen sich wiederkehrende Muster von Klassen und kommu-
nizierenden Objekten finden, welche spezifische Entwurfsprobleme lösen und objektorientier-
te Architekturen flexibler, eleganter und wiederverwendbar machen. Diese Muster sind kei-
neswegs neu, sondern haben sich großteils über Jahre hinweg in verschiedenen Projekten be-
währt. 25 bewährte Entwurfsmuster wurden erstmals in [GHJV95] eingehend dokumentiert.
Im Zuge der Implementierung des WebStyles-Editors wurde eine Vielzahl dieser und anderer
Entwurfsmuster eingesetzt, zum Teil auch Muster, die der Java-API inhärent sind. Die folgen-
den Ausführungen stellen lediglich einen Auszug der verwendeten Muster dar, und zwar jene,
welche die Gesamtarchitektur des Systems besonders prägen.
4.3.1 Observer
In einem System mit einer großen Menge von interagierenden Objekten ergibt sich häufig das
Problem, daß die Konsistenz zwischen den miteinander in Beziehung stehenden Objekten
aufrechterhalten werden muß, ohne daß die Klassen enger gekoppelt werden als unbedingt
nötig.
So trennen viele Klassenbibliotheken Darstellungsaspekte der Benutzerschnittstelle von den
dahinterliegenden Anwendungsdaten. Klassen, die Daten bzw. Datenrepräsentierung definie-
ren, können somit zusammenarbeiten, oder aber auch unabhängig voneinander verwendet
werden (siehe auch: Model-View-Controller). Über das Observer-Muster kann diese lose
Kopplung etabliert werden.

Implementierung 60
Subject
Attach(Observer)
Detach(Observer)
Notify()
Observer
Update()
for all o in observers {
o->Update()
}
ConcreteSubject
GetState()
SetState()
subjectState
return subjectState
ConcreteObserver
Update()
observerState
observerState =
subject->GetState()
subject
Abbildung 14: Das Observer-Entwurfsmuster
Zentrale Komponenten dieses Konzepts sind die Klassen Observable und Observer. Bei ei-
nem Objekt vom Typ Observable kann eine beliebige Anzahl von Observer-Objekten regist-
riert werden. Die Observer werden benachrichtigt, wenn das Observable-Objekt seinen Zu-
stand ändert.
Man erreicht dadurch eine unabhängige Verwendung von Observables und Observern. Das
Observable kennt lediglich eine Liste von Objekten, welche die Observer-Schnittstelle imp-
lementieren, aber keine Details der Implementierung. Benachrichtigungen über Zustandsände-
rungen werden vom Observable an die registrierten Observer verschickt, und es liegt am Ob-
server, eine derartige Nachricht zu ignorieren oder zu bearbeiten.
Das Observer-Konzept wird von Java direkt unterstützt. Im Package java.util existieren
dafür die Klassen Observer und Observable. Die Klasse PSGraphView des WebSty-
les-Editors besitzt einige Observer-Instanzvariablen für Zustandsattribute der Hauptansicht
des bearbeiteten WebStyles-Graphen, z.B. SELECTION_OBSERVABLE, an dem sich Ob-
server registrieren können, die an Selektionsänderungen interessiert sind. Einer dieser Ob-
server ist die Hauptanwendungs-Klasse WebStyles. WebStyles aktualisiert den e-
nabled-Status sämtlicher Action-Instanzen (und somit aller Menü- und Toolbar-Befehle) in

Diplomarbeit: Generische und dynamische Hypertexte (2001)

Diplomarbeit: Generische und dynamische Hypertexte (2001)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Arno Huetter

Mehr von Arno Huetter (13)

Diplomarbeit: Generische und dynamische Hypertexte (2001)