Diplomarbeit: Generische und dynamische Hypertexte (2001)

732 Aufrufe

Veröffentlicht am

Generische und dynamische Hypertexte

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
732
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Diplomarbeit: Generische und dynamische Hypertexte (2001)

  1. 1. 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
  2. 2. 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)
  3. 3. 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.
  4. 4. 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.
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Abbildungsverzeichnis 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
  9. 9. Abbildungsverzeichnis Abbildung 29: Hypertext-Konstruktion Firmenpräsentation (Schritt 1) _________________90 Abbildung 30: Hypertext-Konstruktion Firmenpräsentation (Schritt 2) _________________91 Abbildung 31: Definition von Inhaltsschablonen __________________________________92 Abbildung 32: Hypertext-Konstruktion Firmenpräsentation (Schritt 3) _________________93 Abbildung 33: Hypertext-Konstruktion CBT (Schritt 1)_____________________________94 Abbildung 34: Hypertext-Konstruktion CBT (Schritt 2)_____________________________95 Abbildung 35: Hypertext-Konstruktion CBT (Schritt 3)_____________________________96 Abbildung 36: Hypertext-Konstruktion CBT (Schritt 4)_____________________________97 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
  10. 10. 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
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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
  15. 15. Hypertext - Geschichte und gegenwärtige Systeme 6 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-
  16. 16. Hypertext - Geschichte und gegenwärtige Systeme 7 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
  17. 17. Hypertext - Geschichte und gegenwärtige Systeme 8 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
  18. 18. Hypertext - Geschichte und gegenwärtige Systeme 9 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.
  19. 19. Hypertext - Geschichte und gegenwärtige Systeme 10 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
  20. 20. Hypertext - Geschichte und gegenwärtige Systeme 11 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.
  21. 21. Hypertext - Geschichte und gegenwärtige Systeme 12 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]
  22. 22. Hypertext - Geschichte und gegenwärtige Systeme 13 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.
  23. 23. Hypertext - Geschichte und gegenwärtige Systeme 14 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
  24. 24. Hypertext - Geschichte und gegenwärtige Systeme 15 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]
  25. 25. Hypertext - Geschichte und gegenwärtige Systeme 16 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].
  26. 26. Hypertext - Geschichte und gegenwärtige Systeme 17 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.
  27. 27. Hypertext - Geschichte und gegenwärtige Systeme 18 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.
  28. 28. Hypertext - Geschichte und gegenwärtige Systeme 19 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]
  29. 29. Hypertext - Geschichte und gegenwärtige Systeme 20 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-
  30. 30. Hypertext - Geschichte und gegenwärtige Systeme 21 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]
  31. 31. Hypertext - Geschichte und gegenwärtige Systeme 22 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.
  32. 32. Hypertext - Geschichte und gegenwärtige Systeme 23 • 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,
  33. 33. Hypertext - Geschichte und gegenwärtige Systeme 24 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.
  34. 34. Hypertext - Geschichte und gegenwärtige Systeme 25 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
  35. 35. Hypertext - Geschichte und gegenwärtige Systeme 26 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.
  36. 36. Hypertext - Geschichte und gegenwärtige Systeme 27 • 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-
  37. 37. Hypertext - Geschichte und gegenwärtige Systeme 28 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-
  38. 38. Hypertext - Geschichte und gegenwärtige Systeme 29 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.
  39. 39. Hypertext - Geschichte und gegenwärtige Systeme 30 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]
  40. 40. 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.
  41. 41. Das WebStyles Modell 32 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.
  42. 42. Das WebStyles Modell 33 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,
  43. 43. Das WebStyles Modell 34 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.
  44. 44. Das WebStyles Modell 35 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.
  45. 45. Das WebStyles Modell 36 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).
  46. 46. Das WebStyles Modell 37 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.
  47. 47. Das WebStyles Modell 38 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.
  48. 48. Das WebStyles Modell 39 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
  49. 49. Das WebStyles Modell 40 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.
  50. 50. Das WebStyles Modell 41 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.
  51. 51. Das WebStyles Modell 42 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
  52. 52. Das WebStyles Modell 43 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
  53. 53. Das WebStyles Modell 44 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.
  54. 54. Das WebStyles Modell 45 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.
  55. 55. Das WebStyles Modell 46 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.
  56. 56. Das WebStyles Modell 47 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.
  57. 57. Das WebStyles Modell 48 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.
  58. 58. Das WebStyles Modell 49 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.
  59. 59. Das WebStyles Modell 50 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
  60. 60. Das WebStyles Modell 51 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.
  61. 61. Das WebStyles Modell 52 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.
  62. 62. Das WebStyles Modell 53 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.
  63. 63. 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.
  64. 64. 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.
  65. 65. 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)
  66. 66. 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.
  67. 67. 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
  68. 68. 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.
  69. 69. 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

×